โลกที่ IPv6 เคยเป็นการออกแบบอันยอดเยี่ยม (2017)

 (apenwarr.ca)
11 คะแนน โดย GN⁺ 2026-04-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในเครือข่ายยุคแรกที่เน้นการเชื่อมต่อแบบ point-to-point แทบไม่จำเป็นต้องมีระบบแอดเดรส แต่เมื่อ bus network แพร่หลายเพื่อลดต้นทุน ความซับซ้อนอย่าง MAC address, bridging และ ARP ก็สะสมเพิ่มขึ้น
  • เมื่อ Ethernet ผสานกับ IP การส่งต่อไปยัง next hop ต้องอาศัย การระบุ MAC address และ ARP broadcast และภาระนี้ก็ขยายใหญ่ขึ้นมากในเครือข่ายเชื่อมต่อขนาดใหญ่และ wifi
  • แนวคิดของ IPv6 สะท้อนความคาดหวังต่อโลกที่เรียบง่ายกว่า โดยทิ้ง physical bus และ layer 2 internetwork รวมถึงตัด broadcast, ARP, DHCP และ MAC address ออกไปด้วย
  • แต่ในสภาพแวดล้อมการใช้งานจริง IPv4 และ framing แบบเดิม ยังคงอยู่ ทำให้มรดกอย่าง neighbor discovery, DHCP, NAT และ layer 2 bridging ยังคงอยู่ตามไปด้วย
  • เพื่อคงการเชื่อมต่อระหว่างการเคลื่อนที่ จึงยังคงใช้ layer 2 bridging และการทำ tunneling ผ่านศูนย์กลางแทน Internet routing และมีการพูดถึงทางเลือกอย่าง QUIC ในฐานะ เส้นทางเลี่ยงปัญหา roaming

จุดที่ bus network ทำให้ทุกอย่างพัง

  • ในยุคแรกของระบบโทรศัพท์แบบ circuit switching และวงจรเช่าเฉพาะที่มีเพียง การเชื่อมต่อแบบ point-to-point ยังไม่จำเป็นต้องมีระบบแอดเดรส เพราะโครงสร้างคือบิตที่ใส่เข้าไปฝั่งหนึ่งจะโผล่ออกมาอีกฝั่งหลังเวลาหนึ่ง
  • แม้หลังจากมี TDM และ virtual circuit switching แล้ว จากมุมมองของผู้ใช้ก็ยังเป็นรูปแบบที่อินพุตด้านหนึ่งเชื่อมกับเอาต์พุตอีกด้านอยู่ดี และในขั้นนี้ก็ยังไม่จำเป็นต้องมีแอดเดรส
  • เมื่อคอมพิวเตอร์ที่มีหลายอินเทอร์เฟซเริ่มส่งต่อบิตระหว่างสายต่าง ๆ จึงเกิด IP address, subnet และ routing ขึ้น แต่บนลิงก์ point-to-point ก็ยังไม่ต้องใช้ MAC address
  • เพื่อลดค่าใช้จ่ายในการเชื่อมต่อภายในไซต์ จึงเกิด bus network ที่ให้อุปกรณ์หลายตัวต่ออยู่บนสายเดียวกัน และนอกเหนือจากตระกูล Internet ก็มีระบบ layer 2 ของตัวเองแยกกันเกิดขึ้น
  • LAN ยุคแรกอย่าง arcnet ใช้ layer 2 address ขนาด 8 บิตที่ต้องตั้งด้วยจัมเปอร์หรือ DIP switch แบบแมนนวล และถ้าซ้ำกันจะทำให้เกิดปัญหาร้ายแรง แต่เพราะเครือข่ายยังเล็ก ความไม่สะดวกจึงยังจำกัดอยู่
  • Ethernet นำ MAC address 48 บิตมาใช้เพื่อแก้ปัญหา address ซ้ำ ด้วยวิธีกำหนดแอดเดรสที่แทบจะไม่ซ้ำกันมาตั้งแต่ขั้นตอนการผลิต
  • เทคโนโลยี LAN อย่าง IPX และ Netware ทำงานได้ดีใน bus network เดี่ยวโดยแทบไม่ต้องตั้งค่าแอดเดรส และถูกพรรณนาว่าเป็นยุคที่สวยงามและเชื่อถือได้
  • แต่เครือข่ายองค์กรและมหาวิทยาลัยขนาดใหญ่ติดคอขวดของ bus เดี่ยว 10 Mbps จึงต้องเชื่อม bus หลายเส้นเข้าด้วยกัน และเลือกขยายด้วย bridging และ switching ที่อิง Ethernet address แทน IP ซึ่งตอนนั้นยังไม่สุกงอม
  • เพราะ Ethernet address ถูกกำหนดเรียงลำดับจากโรงงานจึงไม่มีโครงสร้างแบบลำดับชั้น ทำให้ตาราง bridging ไม่สามารถรวมเส้นทางอย่างมีประสิทธิภาพได้เหมือนตาราง routing ของ IP สมัยใหม่ที่จัดการเป็นระดับ subnet
    • เพื่อให้ bridging มีประสิทธิภาพ จึงต้องจำว่า MAC address แต่ละตัวอยู่บน bus ไหน
    • และเพื่อไม่ต้องตั้งค่าด้วยมือ จึงต้องมีการเรียนรู้อัตโนมัติและปฏิสัมพันธ์ที่ซับซ้อน
  • เครือข่าย bridge ที่ซับซ้อนจึงเชื่อมต่อกันด้วยวิธีอย่าง spanning tree พร้อมปัญหา broadcast flood, เส้นทางที่ไม่เหมาะสม และการดีบักที่ยาก
  • อุปกรณ์ bridge ระหว่างทางไม่มีแนวคิดเรื่องแอดเดรสใน Ethernet ปกติ จึงไม่สามารถสร้างเครื่องมืออย่าง traceroute ได้ และทำให้ bridging แทบเป็นโครงสร้างที่ดีบักไม่ได้เลย
  • ถึงอย่างนั้น bridging ก็ทำงานได้เร็วมากใกล้เคียงความเร็วสาย Ethernet เพราะ การปรับแต่งด้วยฮาร์ดแวร์ ซึ่งในเวลานั้นถือเป็นข้อได้เปรียบใหญ่

Internet ที่วิ่งอยู่บน bus

  • จากโครงสร้างที่เชื่อมคอมพิวเตอร์แต่ละเครื่องด้วยลิงก์ point-to-point ระยะไกล ความต้องการเชื่อม LAN ทั้งชุด เข้าด้วยกันก็ค่อย ๆ เกิดขึ้น จนต้องมีการเชื่อม LAN ระยะไกลเข้าหากัน
  • การทำ bridge ระยะไกลแบบง่าย ๆ ใช้ไม่ได้เพราะปัญหาการควบคุมความแออัด โดย Ethernet bridging ใช้งานได้ก็ต่อเมื่อความเร็วของลิงก์ใกล้เคียงกัน หรือแทบไม่มี congestion
  • การเชื่อม 10 Mbps Ethernet เข้ากับลิงก์ point-to-point 0.128 Mbps แบบ bridge ตรง ๆ แทบไม่มีทางไปรอด และการค้นหาเส้นทางแบบ flooding ก็สิ้นเปลืองเกินไปบนลิงก์ช้า
  • การ routing ที่ไม่เหมาะสม ซึ่งพอทนได้ในสภาพแวดล้อมท้องถิ่น กลับเป็นเรื่องร้ายแรงในลิงก์ระยะไกลที่ช้าและแพง จึงไม่สามารถขยายต่อได้
  • กลุ่มปัญหาเหล่านี้เป็นสิ่งที่ฝั่ง Internet จัดการอยู่แล้ว และการเชื่อม LAN bus ต่าง ๆ ด้วยเทคโนโลยี Internet จึงเป็นโครงสร้างที่ดีกว่ามาก
  • ดังนั้นจึงมีการออกแบบ รูปแบบเฟรม สำหรับบรรทุกแพ็กเก็ต Internet บน LAN อย่าง Ethernet และ arcnet และปัญหาก็เริ่มตรงนี้
  • หากมี IP router หลายตัวใน Ethernet segment เดียวกัน ต้องรู้ว่า router ตัวไหนจะรับแพ็กเก็ตไปส่งต่อ ซึ่งระบุด้วย IP ปลายทางเพียงอย่างเดียวไม่ได้
  • ดังนั้นจึงต้องคงปลายทางสุดท้ายไว้ใน IP header และระบุ next-hop router จริงด้วย MAC address ใน Ethernet frame
  • ข้อมูลที่มนุษย์อยากสื่อจริง ๆ คือ ส่ง destination IP 10.1.1.1 ไปยัง router MAC 11:22:33:44:55:66 แต่ระบบปฏิบัติการกลับจัดการมันในรูปแบบอย่าง ผ่าน router IP 192.168.1.1
  • เพื่อสร้าง abstraction นี้ ระบบปฏิบัติการจึงต้องค้นหา Ethernet address ของ router IP ก่อน และจึงเพิ่มขั้นตอนกลางอย่าง ARP เข้ามา
  • ARP ใช้วิธี broadcast ไปทั้ง Ethernet ภายในเพื่อหาเจ้าของ IP ที่ระบุ และถ้ามี bridge อยู่ มันก็ต้องถูกส่งต่อออกทุกอินเทอร์เฟซเพราะเป็น Ethernet broadcast
  • ใน Ethernet ขนาดใหญ่ที่เชื่อมกันมาก ๆ broadcast ที่มากเกินไปกลายเป็นฝันร้ายอันดับต้น ๆ และรุนแรงยิ่งขึ้นโดยเฉพาะใน wifi
  • หลังจากนั้น bridge และ switch จึงเริ่มใส่การแฮ็กพิเศษเพื่อลดขอบเขตการส่ง ARP และอุปกรณ์บางชนิด โดยเฉพาะ wifi access point ถึงกับสร้าง ARP response ปลอมขึ้นมา แต่ทั้งหมดก็ใกล้เคียงกับการแฮ็กทางเทคนิค

ตายเพราะมรดกตกทอด

  • เมื่อเวลาผ่านไป โปรโตคอลที่ไม่ใช่ IP บน Ethernet แทบหายไปหมด และเครือข่ายก็แข็งตัวเป็นโครงสร้างที่มี bus แบบ layer 2 อยู่บนสาย physical มี bridge เชื่อม bus เข้าหากัน และมี router layer 3 วางอยู่ด้านบน
  • เมื่อความเหนื่อยจากการตั้งค่า IP แบบแมนนวลเพิ่มขึ้น ก็เกิดความต้องการให้ตั้งค่าอัตโนมัติ แต่เครื่องต่าง ๆ ถูกส่งออกจากโรงงานพร้อม Ethernet address อยู่แล้ว และ IPv4 32 บิต ก็มีพื้นที่ไม่พอสำหรับกำหนดแอดเดรสถาวรที่ไม่ซ้ำกันตั้งแต่ขั้นการผลิต
  • ถ้ากำหนด IP แบบเรียงลำดับง่าย ๆ ก็จะย้อนกลับไปสู่โครงสร้างที่ไม่เป็นลำดับชั้นเหมือน Ethernet จึงไม่ใช่คำตอบที่ดี
  • จึงเกิด bootp และ DHCP ขึ้น และมันก็กลายเป็นโปรโตคอลที่ต้องได้รับการปฏิบัติเป็นกรณีพิเศษเหมือน ARP
  • DHCP ต้องถูกส่งโดยโหนดที่ยังไม่มี IP address จึงต้องยัด IP header ที่แทบไร้ความหมายแต่เป็นไปตามรูปแบบที่ RFC กำหนด และฝั่ง DHCP server ก็ต้องเติมข้อมูลเหล่านี้เองผ่าน raw socket แทนที่จะใช้ชั้น IP ของเคอร์เนล
  • ท้ายที่สุด bootp และ DHCP ต้องรู้ Ethernet address ก่อนจึงจะจัดสรร IP address ได้ จึงทำหน้าที่คล้ายด้านกลับของ ARP
  • มีการกล่าวถึงว่า RARP ทำสิ่งเดียวกันนี้ได้ง่ายกว่า แต่แทบไม่ถูกพูดถึงในที่นี้
  • ผลคือ Ethernet และ IP ค่อย ๆ พันกันแน่นขึ้นเรื่อย ๆ จนทุกวันนี้แทบแยกจากกันไม่ได้
  • ตาราง routing ของ IP ทำทีเหมือนระบุ router ด้วย IP address แต่จริง ๆ คือระบุ MAC address แบบอ้อม ๆ, ARP วิ่งข้าม bridge ได้, และ DHCP แม้จะหน้าตาเหมือนแพ็กเก็ต IP แต่โครงสร้างจริงกลับใกล้กับโปรโตคอล Ethernet มากกว่า
  • ขณะเดียวกันทั้ง bridging และ routing ก็ซับซ้อนขึ้นเรื่อย ๆ โดย bridging อยู่ฝั่ง IEEE และฮาร์ดแวร์เป็นหลัก ส่วน routing อยู่ฝั่ง IETF และซอฟต์แวร์เป็นหลัก โดยต่างฝ่ายต่างทำเหมือนอีกฝ่ายไม่มีอยู่
  • ผู้ดูแลเครือข่ายเลือกใช้ bridging หรือ routing ตามความต้องการด้านความเร็วและระดับการ ไม่อยากตั้งค่า DHCP server และมักใช้ bridging ให้มากที่สุด ใช้ routing เฉพาะเมื่อจำเป็น
  • ความซับซ้อนของ bridging นำไปสู่ SDN ที่ยกระดับการตัดสินใจของ layer 2 ขึ้นไปให้โปรโตคอลบน IP จัดการจากศูนย์กลาง
  • SDN ดีกว่าปล่อยให้ switch และ bridge ทำงานตามยถากรรมของตัวเอง แต่ก็ถูกชี้ว่าแปลกในระดับพื้นฐาน เพราะ IP เองซึ่งใช้ซอฟต์แวร์ควบคุมเครือข่ายขนาดมหึมา ก็เป็น software-defined network อยู่แล้ว
  • ในยุคแรก IPv4 เร่งด้วยฮาร์ดแวร์ได้ยาก และในทางปฏิบัติก็ไม่ได้รับการเร่งอย่างเพียงพอ ส่วนการตั้งค่า DHCP ก็ยุ่งยากมาก ผู้ดูแลจึงค่อย ๆ เรียนรู้วิธีทำ bridging ให้ครอบคลุมขอบเขตใหญ่ขึ้นเรื่อย ๆ
  • ทุกวันนี้ data center ขนาดใหญ่จำนวนมากทำงานแทบเหมือน virtual bus network ขนาดมหึมาที่ขับเคลื่อนด้วย SDN และมักไม่ได้ทำ routing แพ็กเก็ตอย่างแท้จริง
โฆษณา

ตอนนี้ลองลืมเรื่องข้างต้นไปสักครู่

  • ตอนที่ IETF ออกแบบ IPv6 ในช่วงต้นทศวรรษ 1990 ความสับสนจำนวนมากเกิดขึ้นไปแล้ว แต่การออกแบบยังเดินหน้าด้วยสมมติฐานว่ายังสามารถหลีกเลี่ยงหายนะที่กำลังจะมาถึงได้
  • หนึ่งในการเปลี่ยนแปลงสำคัญระหว่างนั้นคือ การใช้ physical bus network ได้ยุติลงไปโดยพฤตินัยแล้ว
  • Ethernet ไม่ได้เป็น bus จริงอีกต่อไป มันแค่แสร้งทำเป็น bus และเมื่อความเร็วสูงขึ้นจนรักษา CSMA/CD ไว้ไม่ได้ มันก็ย้อนกลับไปสู่ star topology อีกครั้ง
  • โครงสร้างที่ลากสายแยกจากแต่ละสถานีไปยังสวิตช์กลางกลายเป็นเรื่องปกติ จนผนัง เพดาน และพื้นเต็มไปด้วยมัดสาย Ethernet เส้นใหญ่ราคาแพง
  • แม้แต่ wifi ซึ่งดูเหมือน shared wireless medium อันเป็น bus แบบสุดขั้ว ก็แทบทั้งหมดถูกอธิบายว่าใช้งานแบบ infrastructure mode เพื่อเลียนแบบ star topology ขนาดใหญ่
  • แม้แต่ wifi station สองตัวที่ต่ออยู่กับ access point เดียวกันก็ไม่ได้คุยกันตรง ๆ แต่จะส่งแพ็กเก็ตที่ใส่ MAC address ของอีกฝั่งไปยัง access point แล้ว access point ค่อยส่งออกอีกที
  • หากโหนด X ส่งไปยังโหนด Internet ชื่อ Z ผ่าน IP router Y และผ่าน wifi access point A แล้ว Z จะเป็นปลายทาง IP, Y จะเป็นปลายทาง Ethernet และ A จะเป็นคู่สื่อสารจริงบนคลื่นวิทยุ ทำให้ชั้นแอดเดรสซ้อนทับกันอย่างซับซ้อน
  • เพื่อรองรับสิ่งนี้ 802.11 จึงมี 3-address mode ที่เก็บทั้งปลายทาง Ethernet จริงและปลายทาง Ethernet ระหว่างทาง
  • ยังมีบิต to-AP, from-AP เพื่อบอกทิศทาง station→AP และ AP→station และถ้าทั้งสองบิตเป็นจริงพร้อมกันก็สามารถแสดงการทำงานแบบทวนสัญญาณระหว่าง AP ได้ด้วย
  • หาก A เป็น repeater ที่ต้องส่งต่อไปยังสถานีฐาน B อีกที ผู้ส่งและผู้รับจริงในอากาศก็จะแตกต่างจาก source และ destination ของ Ethernet ทั้งหมด จึงต้องใช้ 4-address mode
  • ใน 802.11s mesh ยังมีถึง 6-address mode และผู้เขียนก็ระบุว่าพอถึงจุดนั้นตนเลิกพยายามทำความเข้าใจแล้ว

โลกที่ IPv6 เป็นการออกแบบที่ดี

  • IETF ที่กำลังครุ่นคิดเรื่อง IPv6 มองเห็นทั้งความวุ่นวายที่เกิดขึ้นแล้วและความวุ่นวายที่กำลังจะตามมา จึงจินตนาการถึง โลกใหม่ที่ทิ้งมรดกเดิมทั้งหมด
  • สมมติฐานของโลกนั้นคือการตัด physical bus network, ตัด layer 2 internetwork, ตัด broadcast, ตัด MAC address, ตัด ARP และ DHCP, ใช้ IP header ที่เรียบง่ายและเร่งด้วยฮาร์ดแวร์ได้, แก้ปัญหาขาดแอดเดรส และเลิกตั้งค่า IP แบบแมนนวลทุกที่ยกเว้นแกนหลัก
  • หาก layer 2 เป็น point-to-point เสมอ ก็จะไม่มีเป้าหมายให้ส่ง broadcast อยู่แล้ว จึงแทนด้วย multicast ได้ และเพราะคู่ส่งรับชัดเจนอยู่แล้ว MAC address ก็ไม่จำเป็น
  • เมื่อ MAC address หายไป ก็ไม่ต้องมีการจับคู่ระหว่าง IP กับ MAC อีก ทำให้ ARP และ DHCP ก็อาจหายไปได้เช่นกัน และยังมีพื้นที่แอดเดรสพอจะกลับไปใช้การ routing subnet ขนาดใหญ่ได้อีกครั้ง
  • ในโลกนั้น มีการจินตนาการว่า wifi repeater, wifi access point, Ethernet switch ไปจนถึง SDN ทั้งหมดจะทำงานเป็น IPv6 router
  • ถ้าเป็นเช่นนั้น ARP storm, IGMP snooping bridge และ bridging loop ก็จะหายไป และปัญหา routing ทั้งหมดก็จะติดตามได้ด้วย traceroute
  • สามารถตัดที่อยู่ MAC ต้นทางและปลายทาง 12 ไบต์ออกจากทุก Ethernet packet และตัดข้อมูลแอดเดรส 18 ไบต์ออกจากทุก wifi packet ดังนั้นแม้ IPv6 จะใช้แอดเดรสใหญ่กว่า IPv4 อยู่ 24 ไบต์ แต่ถ้าหักส่วนหัว Ethernet ออกแล้ว ภาระส่วนเพิ่มจริงจะเหลือเพียง 12 ไบต์
  • มีการเล่าว่าความคาดหวังว่าวันหนึ่งจะ ลบ Ethernet address ออกไปได้เอง เป็นส่วนหนึ่งที่ช่วยทำให้การเลือกความยาวแอดเดรสของ IPv6 ที่ใหญ่เกินไปดูสมเหตุสมผล
  • แต่การออกแบบอันงดงามนี้ไม่เคยเกิดขึ้นจริงในโลกความเป็นจริง

บทไว้อาลัยแด่ความฝัน

  • ประโยคของเพื่อนร่วมงานที่ว่า "ชั้นต่าง ๆ มีแต่จะถูกเพิ่ม ไม่เคยถูกลบ" ถูกใช้เป็นข้อสรุปหลักของเรื่องทั้งหมด
  • จุดแข็งของ IPv6 จะใช้ได้ก็ต่อเมื่อสามารถทิ้ง legacy เดิมแล้วเริ่มใหม่ได้ แต่ในความเป็นจริงสิ่งนั้นแทบเป็นไปไม่ได้
  • ต่อให้การใช้งาน IPv6 สูงถึง 99% ตราบใดที่ IPv4 ยังไม่หายไปหมด Ethernet address และ wifi address ก็จะไม่หายไปด้วย และตราบใดที่ยังคงมาตรฐาน framing ของ IEEE 802.3 และ 802.11 การประหยัดไบต์เหล่านั้นก็ไม่เกิดขึ้นจริง
  • เพราะฉะนั้น IPv6 จึงต้องมี neighbor discovery ที่ซับซ้อนกว่า ARP เสียอีก และถึง bus network จะหายไปแล้ว ก็ยังต้องจำลองพฤติกรรมคล้าย broadcast เพื่อให้กลไกแบบ ARP ทำงานต่อ
  • ในบ้าน ผู้ใช้ยังต้องเปิด DHCP server ภายในต่อไปเพื่อให้หลอดไฟ IPv4 รุ่นเก่าทำงานได้ และถ้าหลอดไฟนั้นจะออกสู่อินเทอร์เน็ตก็ยังต้องมี NAT อยู่ดี
  • ที่แย่กว่านั้นคือทีม IPv6 ทิ้งปัญหา mobile IP ไว้โดยแก้ไม่สำเร็จ ส่งผลให้ยังต้องพึ่ง layer 2 bridging อันน่าหวาดหวั่นต่อไป
  • จากสิ่งที่ผู้เขียนเข้าใจ ตอนนั้นแผนคือกระจายใช้งาน IPv6 ให้เสร็จภายในไม่กี่ปี จากนั้นเมื่อ IPv4 และ MAC address หายไปแล้วค่อยแก้ mobile IP ซึ่งจะง่ายกว่า
  • ในเวลานั้น ยังมองว่ากรณีใช้งานของคอมพิวเตอร์ที่เคลื่อนที่ไประหว่างจุดต่าง ๆ มีน้อยมาก จินตนาการได้เพียงภาพเก้งก้างอย่างการย้ายไปมาระหว่างพอร์ต Ethernet แล้วให้ ftp ทำงานต่อเนื่อง

mobile IP ในฐานะแอปนักฆ่า

  • ต่อมาประวัติศาสตร์กลับทำให้คอมพิวเตอร์พกพาได้หรือก็คือ โทรศัพท์ กลายเป็นกรณีใช้งานปกติที่ต้องเคลื่อนที่ระหว่าง wireless access point หลายจุด
  • ใน LTE การเคลื่อนที่แบบนี้มักทำงานได้ และใน wifi บางครั้งก็ทำงานได้ แต่ความลับไม่ใช่ Internet routing หากเป็น layer 2 bridging
  • Internet routing ไม่รองรับ mobility เลย และเมื่อเคลื่อนที่ในเครือข่าย IP จน IP address เปลี่ยน การเชื่อมต่อที่เปิดอยู่ทั้งหมดก็จะขาดทันที
  • wifi ระดับองค์กรจึง bridge LAN ทั้งหมดในระดับ layer 2 เพื่อให้ DHCP server กลางแจก IP เดิมไม่ว่าจะเชื่อมกับ access point ไหน และยอมรับความวุ่นวายไม่กี่วินาทีช่วงที่ bridge กำลัง reconfigure เพื่อรักษาการเชื่อมต่อไว้
  • wifi ภายในบ้านที่มี extender หรือ repeater หลายตัวก็ใช้วิธีเดียวกัน
  • ในทางกลับกัน หากเดินไปตามถนนแล้วสลับผ่าน เครือข่าย wifi คนละชุด อย่าง wifi สาธารณะของร้านค้าต่าง ๆ ก็จะได้ IP ใหม่ทุกครั้ง และทุกการเชื่อมต่อก็หลุดทุกครั้ง
  • LTE ไปไกลกว่านั้น โดยคง IP address เดิมไว้ได้แม้จะย้ายผ่านสถานีฐานหลายแห่งเป็นระยะทางหลายไมล์ และมีการกล่าวว่าในเครือข่ายมือถือมักใช้ IPv6 address กันเป็นหลัก
  • วิธีทำคือ tunnel ทราฟฟิกกลับไปยังจุดศูนย์กลาง แล้ว bridge ทุกอย่างให้เป็น virtual layer 2 LAN ยักษ์หนึ่งเดียวพร้อม firewall จำนวนมาก ซึ่งแลกมาด้วยความซับซ้อนมหาศาลและ latency เพิ่มเติม ในระดับน่าอับอาย
  • ผู้ให้บริการเครือข่ายอยากแก้ปัญหานี้ แต่ก็ถูกอธิบายว่าแทบเป็นไปไม่ได้

วิธีทำให้ mobile IP ใช้งานได้จริง 1

  • คำตอบว่าทำไม mobile IP ถึงใช้งานไม่ได้ดี ถูกสรุปว่าเป็นเพราะนิยาม 4-tuple ชื่อดังที่ใช้ระบุ session นั้นผิดตั้งแต่ต้น
  • session ของ TCP และ UDP ถูกระบุด้วย (source ip, source port, destination ip, destination port) ซึ่งเป็นโครงสร้างที่ลากข้าม layer 3 และ layer 4 และเปราะบางต่อการเปลี่ยนแปลงของ IP address
  • มีข้อเสนอว่าหากการระบุ session ใช้ข้อมูลของ layer 4 เพียงอย่างเดียว mobile IP จะทำงานได้อย่างสมบูรณ์
  • ตัวอย่างเช่น เมื่อ X:1111 สื่อสารกับ Y:80 แล้ว X เปลี่ยนแอดเดรสเป็น Q แพ็กเก็ตจะกลายเป็น (Q,1111,Y,80) ทำให้ Y จำไม่ได้ว่าเป็น session เดิมจึงทิ้งแพ็กเก็ต และแพ็กเก็ตตอบกลับ (Y,80,X,1111) ก็ไปไม่ถึง X อีกต่อไป
  • ทางเลือกหนึ่งคือขยายหมายเลขพอร์ตจาก 16 บิตในปัจจุบันให้เป็นค่าแฮชเฉพาะตัว ขนาด 128 หรือ 256 บิต และระบุ socket ด้วยแท็กที่ไม่ผูกกับ IP address
  • ในกรณีนี้แพ็กเก็ตยังคงมีข้อมูลแอดเดรส (X,Y) ใน layer 3 เพื่อใช้ routing แต่เมื่อเคอร์เนลรับแพ็กเก็ตแล้วจะไม่ใช้ข้อมูล layer 3 ระบุ socket และจะใช้เพียง uuid
  • destination port 80 จำเป็นแค่ตอนเริ่ม session ใหม่เพื่อบอกว่าเป็นบริการใด หลังจากนั้นจะละเลยหรือไม่ส่งมาก็ได้
  • เคอร์เนลของ Y จะ cache ว่าแพ็กเก็ตของ session (uuid) มาจาก X เมื่อไม่นานมานี้ และเมื่อ X ย้ายไป Q แล้วส่งมาพร้อมแท็ก (uuid,80) เดิม ก็จะจับคู่เข้า session เดิมและอัปเดตปลายทางตอบกลับจาก X เป็น Q ได้
  • วิธีนี้ทำให้การเชื่อมต่อคงอยู่ได้ แต่ก็มีหมายเหตุว่าต้องระวังเพิ่มเพื่อป้องกัน การยึดการเชื่อมต่อโดยผู้แอบอ้าง
  • อย่างไรก็ตาม UDP และ TCP ไม่ได้ทำงานแบบนี้ และการเปลี่ยนมันในตอนนี้ถูกประเมินว่าเป็นโครงการประเภทเดียวกับการเปลี่ยน IPv4 ไป IPv6 ซึ่งตอนแรกดูเหมือนง่ายแต่ผ่านไปหลายสิบปีก็ยังทำได้ไม่ถึงครึ่ง

QUIC และความเป็นไปได้ในการอ้อมปัญหา

  • ในด้านบวก มีการเสนอว่าอาจแก้แบบอ้อม ๆ ได้ด้วยการละเมิดชั้นเพิ่มเติมอีกครั้ง
  • หากเลิกใช้ TCP รุ่นเก่าและใช้ QUIC บน UDP ก็สามารถออกแบบให้ไม่ใช้ 4-tuple ของ UDP เองเป็นตัวระบุการเชื่อมต่อได้
  • หากพอร์ต UDP นั้นเป็นพอร์ตของ mobility layer แบบพิเศษ ก็สามารถแกะ payload ด้านในออกมาเป็นแพ็กเก็ตภายในที่มีแท็ก uuid เหมาะสม แล้วจับคู่เข้ากับ session และ socket ที่ถูกต้องได้
  • มีการระบุว่า โปรโตคอล QUIC เชิงทดลอง อย่างน้อยในทางทฤษฎี มีรูปแบบแพ็กเก็ตที่เหมาะกับโครงสร้างแบบนี้อยู่แล้ว
  • เพราะการเข้ารหัสและการยืนยันตัวตนของแพ็กเก็ตแบบ stateless ที่ QUIC ใช้ ก็จำเป็นต้องมีตัวระบุ session หรือคีย์เฉพาะตัวอยู่แล้ว จึงมีความหวังว่าจะรองรับ roaming แบบโปร่งใสได้ด้วยงานเพิ่มไม่มากนัก
  • ถ้าเป็นเช่นนั้น จากนั้นก็เพียงกำจัด UDP และ TCP ที่เหลือทั้งหมดออกจาก Internet และคราวนี้อาจทำให้ไม่จำเป็นต้องใช้ layer 2 bridging อีกจริง ๆ พร้อมทั้งกำจัด broadcast, MAC address, SDN และ DHCP ได้ด้วย
  • ตอนจบลงด้วยประโยคเรื่อง การฟื้นคืนความสง่างามของ Internet
โฆษณา

การแก้ไขเพิ่มเติม

  • แก้ไข 2017-08-16

    • แนวคิดก่อนหน้านี้เกี่ยวกับ mobile IP ไม่ได้จำกัดอยู่แค่ IPv6
    • มีการแก้ไขว่าแนวคิดนี้ทำงานได้ในสภาพแวดล้อม IPv4 และ NAT รวมถึง roaming ข้าม NAT หลายชั้นด้วย

  • แก้ไข 2017-08-15

    • ตัวอย่างที่ง่ายที่สุดของการป้องกันการยึดการเชื่อมต่อคือการแลกเปลี่ยนแบบ SYN-ACK-SYNACK คล้ายกับตอนเริ่ม TCP
    • หาก Y เชื่อแพ็กเก็ตแรกจากโฮสต์ใหม่ Q ทันที ผู้โจมตีจากที่ใดก็ได้บนอินเทอร์เน็ตก็จะแย่งการเชื่อมต่อ X→Y ได้ง่ายมาก
    • แต่ถ้า Y ส่งคุกกี้ไป แล้ว Q รับและประมวลผลก่อนส่งกลับให้ Y อย่างน้อยผู้โจมตีก็ต้องเป็นระดับคนกลาง ไม่ใช่เพียงผู้โจมตีภายนอกทั่วไป
    • หากใช้ โปรโตคอลเข้ารหัส อย่าง QUIC ก็สามารถปกป้อง handshake นั้นด้วย session key ได้เช่นกัน

  • แก้ไข 2017-10-24

    • นอกจาก QUIC แล้ว ยังมีผู้ท้าชิงโปรโตคอลทดแทน TCP ที่รองรับ roaming ในลักษณะนี้ และยก MinimaLT เป็นตัวอย่าง
    • มีการระบุว่า MinimaLT เป็นโปรโตคอลแรกที่ได้ยินมาว่าแก้ปัญหา roaming ได้อย่างสง่างาม และวิธีแก้ที่ถูกนำมาใช้ในอนาคตก็อาจเลียนแบบโครงสร้างนี้

  • แก้ไข 2020-07-09

    • มีเพียงการกล่าวว่าผู้เขียนได้โพสต์ความคิดเพิ่มเติมเรื่องการย้ายผ่าน IPv4/IPv6 และการทำงานร่วมกันไว้ในบทความอื่น โดยไม่มีคำอธิบายเพิ่มในเนื้อหาหลัก

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

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

 
GN⁺ 2026-04-21
ความเห็นจาก Hacker News

  • ในมุมมองของฉัน แม้ IPv6 จะไม่ใช่จุดสูงสุดของการออกแบบโปรโตคอลที่สมบูรณ์แบบ แต่ทางเลือกที่ผู้คนเสนอว่าดีกว่าก็มักจะค่อย ๆ ลงเอยด้วยรูปแบบที่คล้าย IPv6 อยู่ดี ถ้าทุกคนยังสร้างสิ่งที่ดีกว่านี้ไม่ได้อย่างต่อเนื่อง ก็แปลว่า IPv6 น่าจะเป็นการออกแบบที่ค่อนข้างดีในท้ายที่สุด

    • สำหรับฉัน นี่เป็นคำกล่าวที่แรงกว่านั้นอีก แทบทุก ทางเลือกที่ดีกว่า ที่ผู้คนเสนอ แท้จริงแล้วเป็นแนวคิดที่เคยถูกพิจารณาไปแล้วในกระบวนการออกแบบ IPv6 และส่วนใหญ่ก็ถูกปฏิเสธด้วยเหตุผลที่ดีพอ
    • มองย้อนกลับไปก็เหมือนว่าแค่เพิ่มอีก 16 บิตหรือ 32 บิตให้ IPv4 ก็น่าจะพอแล้ว แต่ถึงอย่างนั้นฉันก็เห็นด้วยว่า IPv6 ก็โอเคและใช้งานได้ดี ข้อบ่นส่วนใหญ่ที่ฉันได้ยินมาจากความไม่รู้ แต่มีข้อยกเว้นอยู่ข้อหนึ่งคือ ที่อยู่ที่ยาว อันนี้ไม่สะดวกจริง และ encoding ที่ให้มนุษย์อ่านก็ไม่ค่อยดี ถ้าแก้แค่รูปแบบการเขียนให้อ่านง่ายขึ้นก็น่าจะช่วยได้มาก
    • ฉันไม่เห็นด้วยกับการตีความแบบนั้น โลกเปลี่ยนไปเรื่อย ๆ และฉันมองว่า IPv6 ถูกออกแบบในปี 1998 โดยเน้นความต้องการของ บริษัทอุปกรณ์เครือข่าย เป็นหลัก มุมมองของผู้ใช้ปลายทาง ผู้ดูแลเครือข่าย และนักพัฒนาแอปไม่ได้ถูกสะท้อนอย่างเพียงพอ ฉันคิดว่าสาเหตุที่มันยังอยู่มาจนถึงตอนนี้ก็เพราะ ต้นทุนจม และหนี้ทางเทคนิคเก่า ๆ อยู่มาก ถ้าออกแบบใหม่วันนี้ ภายใต้เงื่อนไขอย่าง SD-WAN ความต้องการของมือถือ หรือราคาชิปที่เปลี่ยนไป ก็น่าจะได้โปรโตคอลอีกแบบหนึ่ง ฉันคิดว่าควรทบทวนแม้แต่แนวคิดเรื่อง source และ destination address เองด้วย ชั้นเครือข่ายที่ไม่มีการเข้ารหัสแบบ 0RTT โดยปริยายในปี 2026 ให้ความรู้สึกล้าหลังมาก องค์ประกอบที่ตั้งอยู่บนสมมติฐานเรื่องความไว้วางใจอย่าง ND, ARP, RA, DHCP ก็น่ากังวลเพราะไม่มีการยืนยันตัวตน ถ้าอุปกรณ์ข้างเคียงอ้างว่าตนมีที่อยู่บางอย่าง ทำไมอุปกรณ์ของฉันต้องเชื่อไปเลย ไม่ว่าจะเป็นเครือข่ายมีสายหรือไร้สาย เวลาต่อเข้าเครือข่ายก็ชวนหงุดหงิดที่เราไม่ตรวจสอบความปลอดภัยและระบบยืนยันตัวตนของเครือข่ายฝั่งตรงข้ามเลย ประเด็นเรื่องความปลอดภัย ความเชื่อถือได้ และตัวตนควรเป็นแกนกลาง แต่กลับไม่เป็นเช่นนั้น และฟีเจอร์ใหม่ ๆ ก็ดูเหมือนจะถูกผลักตามโครงสร้างรายได้ของผู้ขายเสียมากกว่า นอกจากเรื่องความปลอดภัยแล้ว ฉันคิดว่าทิศทางที่สำคัญคือการขยับจากที่อยู่แบบตัวเลขไปสู่ identity-based addressing ด้วย เทคโนโลยีนี้มีผลกระทบสูงเกินกว่าจะปล่อยไว้โดยไม่มีการแทรกแซงจากภาครัฐ และการส่งต่อปัญหาที่อยู่กับความปลอดภัยแบบปี 2005 ไปให้คนรุ่นต่อไปหรือแม้แต่กับอาณานิคมบนดาวอังคารก็ให้ความรู้สึกขมขื่นอยู่เหมือนกัน
    • ฉันไม่เห็นด้วยกับการตีความแบบที่ว่าพวกเขาทำได้ดีกว่านี้ไม่ได้ มันให้ความรู้สึกเหมือน ปล่อยออกมาแล้วก็จบ มากกว่า แทนที่จะเปลี่ยนใหญ่แบบ IPv6 ฉันคิดว่าควรทำ ipv4+ ที่ขัดเกลาหลายรอบและยังอยู่ในแนวต่อเนื่องของ IPv4 มากกว่า

  • ถ้าลองรวบรวมการถกเถียงเก่า ๆ ใน Hacker News จะเห็นว่าหัวข้อนี้วนกลับมาเรื่อย ๆ ทุกไม่กี่ปี่ เช่น เธรดปี 2017, เธรดปี 2019, เธรดปี 2020, เธรดปี 2023

  • ฉันไม่ชอบที่บทความนี้มอง ARP ในแง่ลบเกินไป ARP ทำให้การทำ IP networking ภายใน LAN เป็นไปได้โดยไม่ต้องมีเราเตอร์ และยังทำให้ default gateway ถูกมองเป็นเพียงกรณีพิเศษของการสื่อสาร IP แบบ LAN ทั่วไปได้ด้วย อย่างไรก็ตาม คำอธิบายประวัติศาสตร์ของเครือข่ายในบทความนี้ยอดเยี่ยมจริง ๆ และตอนนี้ฉันก็กำลังอ่านส่วน IPv6 อยู่

    • แน่นอนว่าฉันไม่ได้คิดว่า ARP เป็นวิธีเดียวในการ resolve ที่อยู่เลเยอร์ 2 ARP ก่อให้เกิด การละเมิดลำดับชั้น และทราฟฟิก broadcast ที่มากเกินไป ซึ่งสร้างปัญหาเพิ่มในสภาพแวดล้อมอย่าง WiFi ตัวอย่างเช่น NDP ของ IPv6 ทำงานอยู่บนแพ็กเก็ต IPv6 จริงที่อิง ICMPv6 จึงไม่มีการละเมิดแบบนั้น และด้วย multicast ก็ทำให้ไม่ต้องกระจาย broadcast ไปทั้งเลเยอร์ 2 มากเท่าเดิม

  • ฉันยังสับสนเล็กน้อยว่าบทความนี้ต้องการจะสื่ออะไรแน่ มันหมายถึงว่าอุปกรณ์เครือข่ายของฉันจะตั้งที่อยู่ IPv6 เองจาก MAC address หรือเปล่า และนั่นคือหัวใจของ stateless IPv6 ใช่ไหม เท่าที่ฉันเข้าใจ IPv6 ก็ถูกสร้างมาเพื่อแก้ปัญหาการหมดของ IPv4 และปัญหา NAT ด้วย แต่ Xbox ของฉันกลับบอกว่าเครือข่ายไม่ค่อยดีถ้าไม่มี IPv6 ซึ่งก็ดูเป็นมุมมองที่ ยึดอเมริกาเหนือเป็นศูนย์กลาง พอสมควร

    • ถ้าจะพูดให้แม่นยำ ทุกวันนี้อุปกรณ์ที่ไม่ใช่เซิร์ฟเวอร์ส่วนใหญ่มีแนวโน้มจะใช้ semantically opaque interface identifiers ตาม RFC8064 และ RFC7217 แทน MAC address หรือ EUI64 โดยปกติที่อยู่แบบคงที่จะใช้สำหรับการรับขาเข้าเป็นหลัก ส่วนขาออกสามารถใช้ privacy address ชั่วคราวที่เปลี่ยนไปตามเวลาได้ และคำว่า stateless ในที่นี้ก็หมายถึงอุปกรณ์สามารถประกอบที่อยู่ได้เองด้วย SLAAC โดยไม่ต้องมีการตั้งค่าจากศูนย์กลางอย่าง DHCPv6
    • ฉันคิดว่าสิ่งที่ Xbox บ่นอาจเป็นการไม่มี UPnP มากกว่าจะเป็น IPv6 เอง แน่นอนว่าถ้ามี IPv6 ก็อาจช่วยลดปัญหาบางส่วนได้ แต่ก็น่าขำเหมือนกันที่ฝั่งคอนโซลกลับรองรับ IPv6 ช้าพอสมควร ดังนั้นฉันเองก็อยากรู้ว่า Xbox รองรับได้ดีแค่ไหนจริง ๆ
    • ในทางกลับกัน ฉันก็สงสัยว่า Xbox จะทำงานได้ดีหรือไม่ถ้า ไม่มี IPv4 เลย อุปกรณ์ Windows ในบริษัทของฉันทำไม่ได้ และฉันก็รู้ว่าคอนโซลเกมอื่น ๆ ก็ยังพึ่งพา IPv4 อยู่บ้าง

  • ฉันเริ่มรู้สึกมากขึ้นเรื่อย ๆ ว่าการมีทั้ง SLAAC และ DHCPv6 ใน IPv6 เป็นความผิดพลาดครั้งใหญ่ ตัว SLAAC เองยอดเยี่ยม แต่การมีสองกลไกสำหรับการตั้งค่านั้นทำให้สับสนเกินไป การที่ Android ไม่รองรับ DHCPv6 ก็ยิ่งเพิ่มความสับสน ฉันเดาว่า SLAAC เป็นผลผลิตจากยุคที่คอมพิวเตอร์แพงและ DHCP server เป็นอุปกรณ์แยกต่างหาก แต่ตอนนี้คอมพิวเตอร์ราคาถูกและเราเตอร์ส่วนใหญ่ก็รัน DHCP ได้แล้ว สถานการณ์จึงต่างออกไป ถ้า DHCPv6 เดินไปในทางแจกที่อยู่แบบอิง MAC เป็นหลักตั้งแต่แรก การตั้งค่าน่าจะง่ายกว่านี้ และในลิงก์โลคัลก็น่าจะยังคงการตั้งค่าอัตโนมัติไว้ได้เหมือนเดิม

    • เพื่ออ้างอิง Android 11 เป็นต้นไปก็มีการรองรับ DHCPv6 แบบ Prefix Delegation อยู่บ้าง แต่ถ้าดู บทความนี้ ฉันก็ยังรู้สึกว่ามีแนวทางแบบ เรารู้ดีกว่า จากฝั่งแพลตฟอร์มอยู่ดี

  • ฉันว่าบทความนี้น่าสนใจมาก แต่มีจุดหนึ่งที่ฉันยังไม่เข้าใจ ผู้เขียนบอกว่าทุกวันนี้แม้แต่บน WiFi ก็ไม่ได้ใช้ CSMA/CD แล้ว ถ้าอย่างนั้นมันทำงานจริง ๆ อย่างไร ผู้เขียนอธิบายว่าสถานี WiFi สองตัวที่เชื่อมกับ access point เดียวกันก็ไม่ได้สื่อสารกันโดยตรง ถ้าเป็นแบบนั้น ไม่ช้าก็เร็วแต่ละสถานีก็น่าจะต้องแยกให้ออกว่าสัญญาณที่ตัวเองได้ยินเป็นของตัวเอง ของอีกสถานีที่ส่งไปยัง AP หรือของ AP ที่ส่งไปยังอีกสถานี ถ้าอย่างนั้นก็ไม่ใช่ว่ายังจำเป็นต้องมีกลไกคล้าย ๆ เดิมอยู่ดี เพียงแค่เรียกคนละชื่อหรือ

    • เท่าที่ฉันรู้ WiFi ใช้ CSMA/CA มาตั้งแต่แรกอยู่แล้ว และตั้งแต่ 802.11ax ก็ใช้ OFDMA ร่วมด้วย พื้นหลังของเรื่องนี้ดูได้ดีจาก คำอธิบายปัญหา Hidden node

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

    • ฉันรู้สึกว่าคำว่า เรา ในที่นี้คลุมเครือตั้งแต่ต้น เมื่อก่อนแค่ยื่นขอก็ได้ /24 แต่ตอนนี้กลับต้องไปซื้อช่วงไอพีมือสองที่เคยถูกใช้โดยเครือข่ายสแปมที่ปิดไปแล้ว จน ชื่อเสียงของ IP เละเทะไปหมด ต่อให้แค่อยากโฮสต์อะไรสักอย่างเอง ถ้าไม่ใช่เครือข่ายขนาดใหญ่ก็มักลงเอยด้วยการต้องเช่า IPv4 หนึ่งหมายเลขจากบริษัทอเมริกันอยู่ดี สำหรับฉันมันคล้ายกับการบอกว่ายูเรเนียมมีอยู่ในตลาดตามทฤษฎี แต่ในทางปฏิบัติกลับหามาได้ยากอย่างยิ่ง
    • ฉันคิดว่าปัญหานั้นยังสำคัญมาก การที่มีวิธีแก้ขัดอย่าง NAT อยู่ก็เป็นหลักฐานของมัน ผู้คนแค่ค่อย ๆ ชินกับสภาพแวดล้อมที่แย่ลงเรื่อย ๆ และยอมรับว่าคุณภาพการโทรที่หน่วงสูงหรือสถานการณ์ที่การสื่อสารทั้งระบบหยุดชะงักเมื่อโครงสร้างพื้นฐานอย่าง Cloudflare ล่มเป็นเรื่องปกติ แต่เดิมอินเทอร์เน็ตถูกออกแบบมาเพื่อหลีกเลี่ยงการพึ่งพาศูนย์กลางแบบนั้น สำหรับฉัน การบอกว่าไม่มีปัญหาอะไรเลยก็เหมือนกับการบอกว่า รถติด ไม่ใช่ปัญหาเพียงเพราะวันนี้ฉันยังไปทำงานถึง ต้องมองให้นานขึ้นและมองภาพใหญ่กว่านั้น