สัดส่วนการเชื่อมต่อ IPv6 ของ Google แตะ 50%

 (blog.apnic.net)
2 คะแนน โดย GN⁺ 4 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อวันที่ 23 เมษายน 2026 สถิติ IPv6 ของ Google แตะ 50% เป็นครั้งแรก เข้าสู่ช่วงที่ครึ่งหนึ่งของการเข้าถึงบริการ Google เกิดขึ้นผ่าน IPv6
  • ในวันเดียวกัน IPv6 capability ทั่วโลกของ APNIC Labs อยู่ที่ 42% ซึ่งต่ำกว่า ดังนั้นควรพิจารณาค่าทั้งสองร่วมกับความแตกต่างของวิธีการวัดและโมเดลการถ่วงน้ำหนัก
  • APNIC ไม่ได้นำข้อมูลการวัดที่อิงกับ Google Ads มาบวกรวมแบบตรง ๆ แต่ใช้ น้ำหนักถ่วง ที่สะท้อนขนาดของผู้ใช้อินเทอร์เน็ตในแต่ละเขตเศรษฐกิจ
  • มีเขตเศรษฐกิจอย่าง India, Viet Nam และ Saudi Arabia ที่มีเส้นโค้งการยอมรับแตกต่างกันมาก ทำให้ค่าเฉลี่ยทั่วโลกเพียงอย่างเดียวอธิบาย สภาพจริงรายภูมิภาค ได้ยาก
  • ตอนนี้ IPv6 ได้กลายเป็น ส่วนหนึ่งของการดำเนินงานอินเทอร์เน็ต ที่ใช้งานทุกวันแล้ว ทั้งในเครือข่ายประจำที่ มือถือ อุปกรณ์ส่วนบุคคล และบริการดาต้าเซ็นเตอร์

หมุดหมาย 50% ของสถิติ IPv6 ของ Google

  • สถิติ IPv6 ของ Google บันทึก 50% เป็นครั้งแรกเมื่อวันที่ 23 เมษายน 2026
    • สถิตินี้สะท้อนสัดส่วนผู้ใช้ที่เข้าถึงบริการ Google ผ่าน IPv6
    • เป็นตัวชี้วัดที่ใช้ติดตามความสามารถในการเชื่อมต่อ IPv6 ของผู้ใช้ Google อย่างต่อเนื่อง
  • การแตะ 50% ของ IPv6: {p:50}
  • ตัวเลขนี้สามารถมองได้ว่าเป็นหมุดหมายที่แสดงว่า IPv6 ได้กลายเป็น โปรโตคอลที่เติบโตเต็มที่ และถูกใช้งานอยู่ในเครือข่ายจริงทั่วโลก

ความต่างรายภูมิภาคที่มองไม่เห็นจากค่าเฉลี่ยทั่วโลก

  • การยอมรับ IPv6 มีความแตกต่างกันมากตามภูมิภาคและเขตเศรษฐกิจ จึงยากที่จะตัดสินจากเส้นแนวโน้มทั่วโลกเพียงเส้นเดียว
  • Google ไม่เปิดเผยสถิติ IPv6 แยกตามภูมิภาค และข้อมูลแยกตามเขตเศรษฐกิจก็จำกัดอยู่ที่ยอดรวมทั้งหมด
  • ในข้อมูลของ APNIC Labs เส้นโค้งการยอมรับของแต่ละเขตเศรษฐกิจอาจแตกต่างจากค่าเฉลี่ยทั่วโลกอย่างมาก

ค่าการวัดของ APNIC Labs อยู่ที่ 42%

  • การวัดของ APNIC เองบันทึก IPv6 capability ทั่วโลกไว้ที่ 42% ณ วันที่ 23 เมษายน 2026
    • การวัดทั่วโลกของ APNIC Labs: Source
  • IPv6 capability ของ APNIC: {p:42}
  • มีความแตกต่างอย่างชัดเจนระหว่าง 50% ของ Google กับ 42% ของ APNIC
  • ในระดับแต่ละเขตเศรษฐกิจ การวัดของ APNIC Labs โดยทั่วไปสอดคล้องกับข้อมูลจาก Google, Cloudflare, Akamai และ Cisco
  • ความต่างขนาดใหญ่ในระดับโลกมีแนวโน้มว่าจะมาจากความแตกต่างของ โมเดลการถ่วงน้ำหนัก ของ APNIC มากกว่าตัวการวัดพื้นฐานเอง
  • ในทางปฏิบัติ ค่าการวัดของ APNIC มักออกมาต่ำกว่าค่าของ Google
  • เมื่อนำชุดข้อมูลทั้งสองมาดูร่วมกัน สามารถตีความได้ว่าเป็นค่าที่ประกบช่วงของ IPv6 capability จริงในช่วงเวลาหนึ่งจากคนละด้าน

วิธีการวัดแบบอิงโฆษณาของ APNIC

  • โปรแกรมการวัดของ APNIC ดำเนินการโดย APNIC Labs และใช้โฆษณาออนไลน์ที่เผยแพร่ผ่าน Google Ads ไปยังเว็บเบราว์เซอร์ เกม และแอปของผู้ใช้ปลายทาง
  • ไม่ได้เลือกวัดผู้ใช้เฉพาะราย แต่พยายามให้มีการเข้าถึงที่กว้างที่สุดเท่าที่ทำได้ตลอด 24/7 ในทุกเขตเศรษฐกิจ
  • ใช้ตรรกะของ APNIC Labs ร่วมกับระบบติดตามโฆษณาทั่วไปเพื่อรันชุดทดสอบเฉพาะ
    • วัด IP, BGP routing, DNS และตัวเลือกทางเทคนิคอื่น ๆ
  • ไม่เก็บ ข้อมูลระบุตัวบุคคล (PII) ของผู้ใช้ปลายทาง
  • ไม่เผยแพร่ค่าการวัดดิบ แต่เปิดเผยเฉพาะข้อมูลสรุประดับ ISP เขตเศรษฐกิจ และภูมิภาค
  • งานวัดนี้ดำเนินการด้วยเงินทุนและการสนับสนุนจาก Google Research, ICANN และองค์กรอื่น ๆ

เหตุผลที่ไม่บวกรวมตัวอย่างดิบตรง ๆ

  • APNIC ใช้น้ำหนักทางสถิติกับข้อมูลที่เก็บได้ และทำแบบจำลองการใช้อินเทอร์เน็ตของแต่ละเขตเศรษฐกิจด้วยข้อมูลภายนอก เช่น สถิติของ World Bank
  • จำนวนตัวอย่างการวัดที่ APNIC Labs ได้รับในแต่ละวันไม่เท่ากัน
  • การวางโฆษณาของ Google ถูกปรับให้เหมาะกับการเพิ่มการส่งมอบและรายได้สูงสุด ดังนั้นในบางวันบางเขตเศรษฐกิจอาจมีโฆษณาและตัวอย่างการวัดมากกว่า
    • ตัวอย่างเช่น ในวันที่มีความต้องการโฆษณาสูงในเขตเศรษฐกิจแอฟริกาเหนืออย่าง Egypt หรือ Tunisia ก็อาจมีการเก็บการวัดจากพื้นที่นั้นมากขึ้น
    • ในวันเดียวกัน South America หรือ Asia อาจมีตัวอย่างน้อยกว่าเมื่อเทียบกัน
  • APNIC Labs ไม่ได้นำจำนวนตัวอย่างดิบมาบวกรวมแบบตรง ๆ
    • ก่อนอื่นจะสรุปค่า IPv6 capability ที่วัดได้ของแต่ละเขตเศรษฐกิจ
    • จากนั้นจึงถ่วงน้ำหนักตามจำนวนผู้ใช้อินเทอร์เน็ตโดยประมาณของเขตเศรษฐกิจนั้น
  • เขตเศรษฐกิจที่มีประชากรใช้อินเทอร์เน็ตขนาดใหญ่ เช่น India, China, Indonesia และอื่น ๆ จะมีสัดส่วนต่อผลลัพธ์ทั่วโลกมากกว่า โดยไม่ขึ้นกับจำนวนตัวอย่างดิบในวันนั้น
  • แนวทางนี้มีเป้าหมายเพื่อให้ค่าการวัดสุดท้ายสะท้อน การใช้อินเทอร์เน็ตทั่วโลก ได้ดีกว่าแบบแผนการปล่อยโฆษณาในแต่ละวัน

เบื้องหลังที่ทำให้การเปลี่ยนผ่านสู่ IPv6 ใช้เวลานาน

  • มีมุมมองว่าการที่ IPv6 ใช้เวลานานกว่าจะถึงหมุดหมายการยอมรับ 50% เป็นหลักฐานของความล้มเหลวเชิงระบบของ IPv6
  • การปรับใช้ IPv6 ต้องใช้ทั้งความพยายามทางเทคนิคอย่างมากและการลงทุนด้านทุนจำนวนมาก
  • ความแตกต่างของความคืบหน้าในแต่ละภูมิภาคและเขตเศรษฐกิจเป็นผลจากการตัดสินใจของ ISP และแต่ละเขตเศรษฐกิจภายใต้ความเป็นจริงของการเติบโตเครือข่าย ความคาดหวังของผู้ใช้ และการดำเนินงานโครงสร้างพื้นฐานอินเทอร์เน็ต
  • อินเทอร์เน็ตทั่วโลกไม่ใช่ เศรษฐกิจแบบวางแผนจากส่วนกลาง แต่ค่อย ๆ พัฒนาผ่านความร่วมมือและการประสานงานภายใต้เงื่อนไขที่ขับเคลื่อนโดยตลาด
  • ผู้ให้บริการจำนวนมากเคยลงทุนมหาศาลกับ IPv4 มาก่อน และต้องการทำให้ผลตอบแทนจากการลงทุนนั้นสูงที่สุด
    • ในกระบวนการนั้นได้สร้างเครือข่ายที่ใช้ IPv4 ซึ่งยั่งยืนและมีความคุ้มค่าทางธุรกิจภายในขอบเขตบริการเดิม
  • สำหรับผู้เล่นรายใหม่ในตลาด หลายกรณีการเลือกใช้ IPv6 เป็นโปรโตคอลพื้นฐานกลับสมเหตุสมผลกว่า
    • IPv6 สามารถลด ต้นทุนรวมในการเป็นเจ้าของ (TCO) ได้
    • รูปแบบนี้เด่นชัดเป็นพิเศษในภาคมือถือ
    • Reliance Jio network ของ India ถูกยกเป็นกรณีตัวอย่างของการปรับใช้ IPv6 ในวงกว้าง

อินเทอร์เน็ตปัจจุบันที่ IPv4 และ IPv6 ทำงานร่วมกัน

  • ปัจจุบันอินเทอร์เน็ตทั่วโลกทำงานอยู่ในโลกของสองโปรโตคอล
  • แม้การดำเนินงานด้วยโปรโตคอลเดียวจะง่ายกว่าในเชิงลอจิสติกส์ แต่สภาพแวดล้อมจริงไม่ได้เป็นเช่นนั้น
  • ทุกวันนี้อินเทอร์เน็ตประกอบด้วยรูปแบบการเชื่อมต่อหลายแบบผสมกัน
    • การเชื่อมต่อ IPv4 โดยตรง
    • IPv4 ผ่าน NAT ของเครือข่ายบ้านหรือ Carrier-Grade NAT(CGNAT) ของผู้ให้บริการ
    • IPv6
  • การจัดการการแปลงที่อยู่ผ่าน NAT ไม่ได้ซับซ้อนน้อยกว่าโดยเนื้อแท้ เมื่อเทียบกับการแปลงโปรโตคอล การห่อหุ้ม IPv4 บน IPv6 หรือกลไกการเปลี่ยนผ่านและพร็อกซีอื่น ๆ
  • คำพูดว่า “IPv4 is working fine” มักมองข้ามความจริงที่ว่าเครือข่าย IPv4 สมัยใหม่พึ่งพาความซับซ้อนเชิงปฏิบัติการหลายชั้นอยู่แล้ว
  • ไม่มีแนวทางที่ถูกกว่าหรือเรียบง่ายกว่าตามธรรมชาติโดยใช้แค่ IPv4 เพียงอย่างเดียว

ตำแหน่งจริงของการทำงานร่วมกันระหว่าง IPv4·IPv6

  • การที่ไม่มีการทำงานร่วมกันโดยตรงระหว่าง IPv4 กับ IPv6 เป็นสิ่งที่ถูกเข้าใจมาตั้งแต่ต้นว่าเป็นโจทย์ที่ต้องแก้
  • ในช่วงแรกมีการสำรวจแนวคิดโปรโตคอลที่สามารถครอบรับ IPv4 ได้โดยไม่ต้องเปลี่ยนแปลง และทำให้ทั้งสองโลกเชื่อมต่อกันได้โดยตรง แต่ไม่สามารถพิสูจน์ได้ว่าใช้ได้จริงในทางปฏิบัติ
  • การทำงานร่วมกันจึงเกิดขึ้นที่ชั้นสูงกว่า ผ่านโปรโตคอลขนส่งอย่าง TCP, UDP และ QUIC ที่ทำงานโดยไม่ขึ้นกับเวอร์ชันของ IP
  • โมเดลนี้ต้องการ ตัวกลาง ไม่ทางใดก็ทางหนึ่ง
  • โครงสร้างนี้เห็นได้จากวิธีที่ผู้ให้บริการคอนเทนต์และแคชรายใหญ่อย่าง Cloudflare ให้บริการแบบ dual-stack โดยไม่ขึ้นกับว่าระบบ backend จะรองรับทั้งสองโปรโตคอลหรือไม่

เหตุผลที่บางบริการไม่มี dual-stack

  • การที่บางบริการไม่มี native dual-stack capability มักถูกมองว่าเป็นอุปสรรคใหญ่ต่อความก้าวหน้าของ IPv6
  • มีการยกตัวอย่างแพลตฟอร์ม Git บางแห่งหรือสถานีโทรทัศน์ระดับประเทศบางราย
  • สถานการณ์เช่นนี้อาจสะท้อน ความซับซ้อนด้านการปฏิบัติการ มากกว่าการต่อต้าน IPv6
  • ในกรณีของผู้แพร่ภาพระดับประเทศ อาจมีข้อจำกัดเชิงปฏิบัติ เช่น ข้อกำหนดทางกฎหมายและกฎระเบียบที่เกี่ยวข้องกับการเข้าถึงข้อมูลและ geolocation

IPv6 เป็นส่วนหนึ่งของการดำเนินงานประจำวัน

  • ตอนนี้ IPv6 ถูกปรับใช้ในระดับทั่วโลกแล้ว
  • ในบรรดาผู้ใช้อินเทอร์เน็ตที่ Google มองเห็น ประมาณครึ่งหนึ่งเข้าถึงบริการ Google ผ่าน IPv6 อยู่แล้ว
  • IPv6 ถูกใช้งานทุกวันทุกชั่วโมง ทั้งในประเทศพัฒนาแล้วและประเทศกำลังพัฒนา ในเครือข่ายประจำที่และมือถือ รวมถึงในอุปกรณ์ส่วนบุคคลขนาดเล็กและบริการขนาดใหญ่ที่อยู่บนดาต้าเซ็นเตอร์
  • IPv6 ไม่ใช่เทคโนโลยีเชิงทดลองหรืออยู่ชายขอบอีกต่อไป แต่เป็นส่วนหนึ่งของ การดำเนินงานอินเทอร์เน็ตในชีวิตประจำวัน

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
purely4959 4 시간 전

อินเทอร์เน็ตบ้านในเกาหลีจะเริ่มรองรับ IPv6 เมื่อไหร่กันนะ
 
GN⁺ 4 시간 전
ความเห็นจาก Hacker News

  • ถ้าจะยกตัวอย่างเพิ่มให้กับกรณี “ISP ยังไม่ทำกันอยู่ดี” ผู้ให้บริการอินเทอร์เน็ตรายใหญ่ของสหราชอาณาจักรอย่าง Virgin Media เคยประกาศต่อสาธารณะในงาน World IPv6 Day ปี 2011 ว่าจะรองรับ IPv6 อย่างสมบูรณ์ภายในสิ้นปี 2012 แต่ผ่านไป 15 ปีแล้วก็ยังเปิดสวิตช์ไม่ได้
    https://havevirginmediaenabledipv6yet.co.uk/
    ประกาศในตอนนั้น: https://ispreview.co.uk/story/2011/06/08/uk-isp-fluidata-hai...

    • วิธีบีบให้ ISP รองรับ IPv6 อาจฟังดูงี่เง่า แต่ก็อาจได้ผลดี คือให้เว็บเปรียบเทียบบริการติดคำเตือนสีแดงตัวใหญ่กับ ISP ที่ไม่รองรับ IPv6 และให้เว็บไซต์ขึ้นแบนเนอร์ว่า “ISP ของคุณไม่รองรับการเชื่อมต่ออินเทอร์เน็ตแบบปกติที่เว็บไซต์นี้ใช้งาน”
      ผู้บริโภคอาจไม่รู้ว่า IPv6 คืออะไร แต่เข้าใจคำเตือนสีแดงตัวใหญ่กับแบนเนอร์น่ารำคาญได้
    • เคยถาม Virgin Media มาก่อนว่าในวงจร 1Gb DIA สามารถ เปิดใช้งาน IPv6 ได้ไหม แล้วได้รับคำตอบว่า “เปลี่ยนวงจรเป็น IPv6 ได้ แต่ต้องยอมทิ้ง IPv4”
      หลังจากนั้นก็หมดอารมณ์จะถามอีก
    • ถ้ามองในมุมธุรกิจล้วน ๆ VM ก็ไม่มีเหตุผลจำเป็นต้องทำ IPv4 address ยังมีพอ และนอกจากกลุ่มผู้ใช้เชิงเทคนิคเล็กมาก ๆ แล้ว ลูกค้าก็แทบไม่รู้สึกถึงประโยชน์ของ IPv6
      พอรวมกับกรณีที่การติดตั้ง IPv6 ของ ISP อื่น ๆ ทำให้บางอย่างพังแบบสุ่ม ก็พอเข้าใจได้ว่าทำไมถึงไม่ทำ
    • ในเนเธอร์แลนด์มีเว็บไซต์อย่าง https://heeftodidoipv6.nl
      ISP รายนี้มี IPv6 ในโครงข่ายแกนหลัก แต่ไม่เปิดให้ลูกค้าใช้ ทั้งที่มีส่วนแบ่งตลาดโทรคมนาคมในเนเธอร์แลนด์ถึง 17%
    • อย่างน้อยในสหรัฐฯ ก็ดูเหมือนใกล้จะไปถึงแล้ว ในบรรดา ASN อันดับต้น ๆ นั้น สัดส่วนที่ใช้ IPv6 ได้เกิน 75%
      แต่ Optimum Communications กับ Frontier กดตัวเลขลงแรง โดยทั้งคู่ยังอยู่แถว ๆ 15% Frontier ดีขึ้นอย่างช้ามาก ส่วนฝั่ง Optimum แทบไม่มีหลักฐานของความเปลี่ยนแปลง

  • เมื่อสองเดือนก่อนก็มีเธรดที่มีถึง 626 คอมเมนต์: https://news.ycombinator.com/item?id=47777894

  • พอลองตั้งค่าเซิร์ฟเวอร์ IPv6 แบบ “ล้วน ๆ” ก็แปลกใจที่ GitHub ไม่รองรับ IPv6 ถ้าไม่มีผู้ให้บริการ NAT64 อาสาสมัครที่อยู่บน https://nat64.xyz/ ก็จะเข้าถึง GitHub จากสภาพแวดล้อม IPv6 ไม่ได้

    • การที่ GitHub ไม่รองรับ IPv6 เป็นเรื่องที่ยกโทษให้ไม่ได้เลยจริง ๆ
    • อินเทอร์เน็ตก็หาทางอ้อมปัญหาได้อีกแล้ว เป็นตัวอย่างที่ดีว่าแม้ในยุค 2020s ก็ยังมีอยู่จริงเพียง อินเทอร์เน็ตเดียว ไม่ใช่อินเทอร์เน็ตหลายอัน

  • ไม่เอานะ /22 IPv4 subnet ของฉันก็เหมือน 401k ส่วนตัว ต้องเก็บไว้ใช้เป็นเงินเกษียณ

    • ฟังเหมือนมุก แต่จริง ๆ แล้วสังคมก็มองที่อยู่อาศัยแบบนี้เป๊ะเลย
    • ถึงเวลาขายทำเงินหรือยัง?
    • พอถึงราวปี 2100 คงลำบากจริง ๆ

  • T-Mobile/Odido ในเนเธอร์แลนด์ก็สัญญามาหลายปีแล้วว่ากำลังทำอยู่ แต่จนถึงตอนนี้ก็ยัง ไม่รองรับ IPv6
    ส่วน Ubiquiti gateway ก็ดูรองรับได้ไม่ดีนัก และน่าจะดีถ้ารองรับฟีเจอร์อย่าง Hurricane Electric tunneling

    • ที่นี่ผ่าน Ubiquiti gateway แล้วเข้า news.ycombinator.com ที่ IPv6 address 2606:7100:1:67::26 ได้ปกติดี
    • ช่วง address ของ HE tunnel ตอนนี้มักโดนปฏิบัติในทางเสียเปรียบค่อนข้างหนักเหมือนเป็นที่อยู่ที่ไม่ใช่ที่พักอาศัย/ไม่ใช่สำนักงาน สุดท้ายเลยต้องปิด
      ตัวอย่างเช่น YouTube ดูเหมือนจะบล็อกผู้ใช้ HE range ที่ไม่ได้ล็อกอินเป็นส่วนใหญ่ และยังเจอ CAPTCHA ไม่รู้จบอยู่บ่อย ๆ
    • น่าสนใจที่ T-Mobile ในสหรัฐฯ กลับตรงกันข้าม คือไม่รองรับ IPv4 แต่แจกเฉพาะ IPv6 แล้วใช้ 464XLAT ทำ “NAT ปลอม” สำหรับ IPv4
    • T-Mobile US เป็นแบบ IPv6-only มาตั้งแต่ราวปี 2018: https://www.youtube.com/watch?v=d6oBCYHzrTA
    • ISP ทุกเจ้าควรต้องจ่ายค่าท่อ Hurricane Electric และเพราะงั้นสำหรับผู้ใช้จึงฟรี ถ้ามีคนใช้ HE tunnel มากพอ สุดท้าย ISP ก็คงยอมให้บริการ IPv6 แบบ native
      แต่ในความเป็นจริงมักโดนบล็อกจากแทบทุกเว็บไซต์ที่เข้าเยี่ยมชม และถ้าอยู่หลัง CGNAT หรือไม่มี DMZ บนเราเตอร์ที่บ้านก็ใช้งานได้ยาก

  • อยากเลิกจ่าย ค่าที่อยู่ IPv4 สาธารณะ ให้ AWS แต่ฝั่งลูกค้ายังมี ISP จำนวนมากที่ไม่รองรับ จึงเปลี่ยนเป็น IPv6 แบบสมบูรณ์ไม่ได้
    ตอนนี้ยังไม่มีแรงกดดันที่ทำให้ ISP ต้องย้ายไปใช้ IPv6 ตรงกันข้ามกลับเป็นอีกแบบ ISP ชอบเก็บค่าบริการ IP คงที่

    • พูดกันอย่างเป็นธรรม ถ้า Google เลิกรองรับ IPv4 ก็จะเป็นแรงจูงใจที่ค่อนข้างแรงให้ ISP ต้องทำตาม

  • โดยเฉพาะถ้าสัดส่วน IPv6 สูงขึ้นในช่วงสุดสัปดาห์ ก็ดูเหมือนเป็นสัญญาณว่าฝั่ง เครือข่ายองค์กร/เครือข่ายงาน ยังเลื่อนการติดตั้งใช้งานอยู่

    • หลักไมล์ที่แท้จริงคือจุดที่เกิน 50% ตลอดเวลา
    • มักพูดกันทำนองว่า “ขี้เกียจเลยไม่ทำ” แต่ IPv6 ไม่ใช่เรื่องที่แค่ติ๊กเช็กบ็อกซ์เดียวแล้วจบ
      ทำไมต้องปรับองค์กรและทำงานสารพัด เพียงเพื่อเปลี่ยนตัวเลขไม่กี่ตัว? ในเมื่อ IPv4 ก็ยังใช้งานได้อยู่ แล้วจะทำไปทำไม?

  • การที่ IPv6 ของ Google แตะ 50% ถือว่าดีมากในแง่ของการเข้าถึงเว็บไซต์
    แต่ เราเตอร์ TP-Link ของฉันบล็อกการเชื่อมต่อ IPv6 ขาเข้าเป็นค่าเริ่มต้น แถมไม่มีตัวเลือกให้ตั้งค่า จึงยังไม่เหมาะกับการสตรีมสองทาง เกม และบริการโฮมเน็ตเวิร์กแบบ IPv6 ล้วน

    • ถ้าลง OpenWRT บนอุปกรณ์นั้น ก็ทำได้ตามต้องการ แล้วจะได้พบกับความสนุกของการเพิ่มกฎการเข้าถึง IPv6 สำหรับพอร์ตที่แทบจะเหมือนเดิม แทนกฎ port forwarding ของ IPv4
    • ฉันโฮสต์เว็บกับอีเมลเองบน WireGuard VPN ที่ใช้ VPS ฟรี ทำฟรีบน OCI และบน AWS Lightsail ก็ทำได้ในราคาถูก
      จะใช้โซลูชันที่ตั้งค่าง่ายแบบ Tailscale ก็ได้ และแบบนี้ก็ไม่ต้องเปิดเผยเครือข่ายบ้านสู่สาธารณะอินเทอร์เน็ตโดยตรง
    • ผู้ผลิตเราเตอร์สำหรับผู้บริโภคส่วนใหญ่ก็แย่พอๆ กันจนไม่ค่อยต่างมาก แต่ TP-Link แย่จริงๆ ขอแนะนำอย่างยิ่งว่าอย่าใช้งานฮาร์ดแวร์ของเจ้านี้
    • ระบบพวกนี้สะท้อนยุคที่มันถูกออกแบบมา IPv6 เป็นเทคโนโลยีอายุ 30 ปี และตอนนั้นภัยคุกคามหลายอย่างในปัจจุบันยังไม่มี
      ตัวอย่างเช่น การตั้งค่าเริ่มต้นเป็น บล็อก /64 เกิดจากความเชื่อว่าจะใช้บางส่วนของ MAC address 48 บิต แต่ตอนนี้เรารู้แล้วว่านั่นเป็นฝันร้ายด้านความเป็นส่วนตัวและไม่มีใครทำแบบนั้นแล้ว ถึงอย่างนั้นเราก็ยังติดอยู่กับโครงสร้างที่อยู่ 128 บิตซึ่งเป็นผลตามมาจากแนวคิดนั้น
      IPv6 พยายามแทนที่ NAT ด้วยการมีที่อยู่มากพอ แต่ที่น่าสนใจคือสิ่งนี้กลับสร้างปัญหาเรื่องการแสดงเจตนา ใน NAT เมื่อบริการบนคอมพิวเตอร์ร้องขอพอร์ตสำหรับการเชื่อมต่อขาเข้า ก็แสดงเจตนาของเจ้าของบริการออกมา แต่ IPv6 ไม่มีสัญญาณเจตนาแบบนั้น ดังนั้นผู้ผลิตเราเตอร์บ้านจึงแทบไม่มีทางเลือกนอกจากบล็อกที่อยู่ไว้เป็นค่าเริ่มต้น ไม่เช่นนั้นคนนอกอาจสแกนพีซีและทำให้บริการที่ไม่ตั้งใจเปิดเผยหลุดไปสู่สาธารณะอินเทอร์เน็ตได้
      พื้นที่ที่อยู่ที่ใหญ่ขึ้นอาจดีกว่าในเชิงเทคนิค แต่ก็ต้องคำนึงถึงค่าเริ่มต้นและเจตนาของผู้ใช้ด้วย วิธีแก้ที่ดีทางเทคนิคอาจกลายเป็นวิธีแก้ที่แย่หรือก่อปัญหาจำนวนมากได้ตรงจุดนี้

  • ที่ Cloudflare สัดส่วน IPv6 ดูเหมือนจะอยู่ที่ มากกว่า 40% แต่แม้ทราฟฟิกโดยรวมจะเพิ่มขึ้น ก็แทบไม่ขยับมากนักในช่วง 1 ปีที่ผ่านมา ตามข้อสังเกตในบทความของ APNIC อัตราการยอมรับใช้งานจริงโดยรวมคงอยู่สักแห่งระหว่าง Google กับ Cloudflare
    https://radar.cloudflare.com/adoption-and-usage#ipv4-vs-ipv6
    อย่างไรก็ตาม นี่สะท้อนอัตราการยอมรับฝั่งไคลเอนต์ บริการดังๆ จำนวนไม่น้อยก็ยังรองรับเฉพาะ IPv4 ดังนั้นสัดส่วน IPv6 ที่แท้จริงบนอินเทอร์เน็ตสาธารณะอาจต่ำกว่านี้มาก
    ตอนนี้การจัดสรร IPv4 ใหม่หมดลงมานานแล้ว จึงดูเหมือนว่าต้องมี แรงจูงใจในการเปลี่ยนผ่าน แบบใหม่ที่ต่างจากเดิม

    • หากดูตามสัดส่วนทราฟฟิก บริการขนาดใหญ่ที่ใช้แบนด์วิดท์มาก เช่น เว็บไซต์สตรีมวิดีโอและ CDN ส่วนใหญ่ทำงานบน IPv6 อยู่แล้ว ส่วนบริการปลายหางยาวที่ยังเป็น IPv4 ล้วนมักใช้แบนด์วิดท์น้อยกว่า
    • ทุกวันนี้ การจำกัดความเร็ว อาจเป็นแรงจูงใจเชิงลบที่สำคัญ บน IPv4 การบล็อกเป็นช่วงยังพอได้ผลในระดับหนึ่ง แต่บน IPv6 ได้ผลน้อยกว่ามาก
      นี่ก็เป็นเหตุผลที่ HE Tunnelbroker ถูกมองไม่ดีในช่วงนี้ บอตเพลงของ Discord ทำ load balancing ระหว่าง IP ของ tunnelbroker เพื่อดึงข้อมูลเสียงจาก YouTube และถึงจะบล็อก /64 ก็ยังอ้อมด้วย /48 หรือใหญ่กว่านั้นได้ ฉันคิดว่าเหตุผลหลักที่ Discord ปิดใช้งาน IPv6 ก็เพราะการบล็อกตาม IP และการทำ API rate limiting

  • ถ้าดูสัดส่วนรายประเทศก็น่าสนใจ ฝรั่งเศสดูเหมือนจะขึ้นไปถึง 85% แล้ว
    https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...

    • ยิ่งมีทราฟฟิกมือถือมากเท่าไร สัดส่วน IPv6 ก็ยิ่งสูงขึ้น ดูอินเดียก็ได้ ไม่ใช่ว่าทุกคนจะใช้ไฟเบอร์ที่เป็น IPv6 ทั้งหมด
    • ฉันสงสัยว่าทำไม สัญญาณความถี่สูง ที่ซ้อนอยู่บนแนวโน้มระยะยาวในกราฟนั้นถึงเกิดขึ้น
      https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
    • การที่อินเดียอยู่ที่ 75% เป็นข่าวดีมาก ไม่อย่างนั้น แรงกดดันด้านราคา IPv4 address คงรุนแรงจนเกินรับไหว