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

 (apenwarr.ca)
11 คะแนน โดย GN⁺ 9 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เครือข่ายยุคแรกที่เน้น การเชื่อมต่อแบบจุดต่อจุด แทบไม่ต้องมีระบบที่อยู่ แต่เมื่อ เครือข่ายแบบบัส แพร่หลายเพื่อประหยัดต้นทุน ความซับซ้อนอย่าง MAC address, bridging และ ARP ก็สะสมเพิ่มขึ้น
  • เมื่อ Ethernet กับ IP ถูกผูกเข้าด้วยกัน จึงจำเป็นต้องมี การระบุ MAC address และ ARP broadcast เพื่อส่งต่อไปยัง next hop และภาระนี้ยิ่งขยายใหญ่ขึ้นมากในเครือข่ายที่เชื่อมต่อกันขนาดใหญ่และ 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

จุดเริ่มต้นที่เครือข่ายแบบบัสทำให้ทุกอย่างพัง

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

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

  • จากโครงสร้างที่เชื่อมคอมพิวเตอร์แต่ละเครื่องด้วยลิงก์จุดต่อจุดระยะไกล ความต้องการก็ขยับไปสู่การเชื่อม ทั้ง LAN เข้าด้วยกัน ทำให้ต้องมีการเชื่อมต่อระยะไกลระหว่าง LAN
  • การทำ bridge ระยะไกลง่าย ๆ ใช้ไม่ได้เพราะปัญหาการควบคุมความแออัด และ Ethernet bridging จะทำงานได้ก็ต่อเมื่อความเร็วลิงก์ใกล้เคียงกันหรือแทบไม่มีความแออัด
  • การ bridge Ethernet 10 Mbps เข้ากับลิงก์จุดต่อจุด 0.128 Mbps โดยตรงนั้นแทบไร้ความหวัง และการค้นหาเส้นทางด้วย flooding ก็สิ้นเปลืองเกินไปบนลิงก์ช้า
  • Routing ที่ไม่เหมาะที่สุด ซึ่งพอทนได้ในสภาพแวดล้อมท้องถิ่น กลับเป็นเรื่องร้ายแรงบนลิงก์ระยะไกลที่ช้าและแพง จึงไม่สามารถขยายได้
  • กลุ่มปัญหาเหล่านี้เป็นสิ่งที่ฝั่ง Internet รับมืออยู่ก่อนแล้ว และการเชื่อม LAN bus ด้วยเทคโนโลยี Internet ย่อมให้โครงสร้างที่ดีกว่ามาก
  • จึงมีการออกแบบ frame format สำหรับบรรจุแพ็กเก็ต 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 จึงเริ่มใส่ hack พิเศษเพื่อลดขอบเขตการส่งต่อ ARP และอุปกรณ์บางชนิด โดยเฉพาะ wifi access point ถึงกับสร้าง ARP reply ปลอมขึ้นมาเอง แต่ทั้งหมดก็ใกล้เคียงกับการ hack ทางเทคนิคมากกว่า

ตายเพราะมรดกเก่า

  • เมื่อเวลาผ่านไป โปรโตคอลที่ไม่ใช่ IP บน Ethernet ก็แทบหายไปหมด และเครือข่ายก็แข็งตัวเป็นโครงสร้างที่มี layer 2 แบบบัสอยู่บนสาย physical layer มี bridge เชื่อมบัสเหล่านั้น และมี layer 3 router วางอยู่ด้านบน
  • เมื่อความเหนื่อยล้าจากการตั้งค่า IP ด้วยมือเพิ่มขึ้น ก็เกิดความต้องการการตั้งค่าอัตโนมัติ แต่เครื่องถูกส่งมาพร้อม Ethernet address อยู่แล้ว และ IPv4 32 บิต ก็ไม่พอสำหรับกำหนดที่อยู่ถาวรไม่ซ้ำกันตั้งแต่ขั้นผลิต
  • หากกำหนด IP address แบบเรียงลำดับง่าย ๆ ก็จะย้อนกลับไปสู่โครงสร้างไม่เป็นลำดับชั้นแบบ Ethernet จึงไม่ใช่คำตอบที่เหมาะสม
  • จึงเกิด bootp และ DHCP ขึ้นมา และมันก็กลายเป็นโปรโตคอลที่ต้องได้รับการปฏิบัติแบบพิเศษคล้าย ARP
  • DHCP ต้องเริ่มส่งข้อมูลจากโหนดที่ยังไม่มี IP address จึงต้องใส่ IP header ที่แทบไร้ความหมายแต่เป็นไปตามรูปแบบที่ RFC กำหนด และ DHCP server ก็ต้องเขียนสิ่งนี้เองผ่าน raw socket แทนชั้น IP ของ kernel
  • ท้ายที่สุด bootp และ DHCP ก็ต้องรู้ Ethernet address เพื่อแจก IP address อยู่ดี จึงทำหน้าที่คล้ายด้านกลับของ ARP
  • มีการกล่าวว่า RARP ทำสิ่งเดียวกันได้เรียบง่ายกว่า แต่แทบไม่ถูกพูดถึงในที่นี้
  • ผลลัพธ์คือ Ethernet กับ IP พันกันแน่นขึ้นเรื่อย ๆ จนวันนี้แทบแยกจากกันไม่ได้
  • routing table ของ IP ทำเหมือนระบุ router ด้วย IP address แต่จริง ๆ แล้วคือการระบุ MAC address แบบอ้อม ๆ, ARP วิ่งผ่าน bridge, และ DHCP แม้ดูเหมือน IP packet แต่ในโครงสร้างจริงกลับใกล้เคียงโปรโตคอล 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 ขนาดใหญ่ถูกบรรยายว่าทำงานคล้าย เครือข่ายบัสเสมือนขนาดมหึมาที่ขับเคลื่อนด้วย SDN และหลายครั้งไม่ได้ทำ routing แพ็กเก็ตอย่างแท้จริง

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

  • ตอน IETF ออกแบบ IPv6 ในต้นทศวรรษ 1990 ความสับสนจำนวนมากได้เกิดขึ้นแล้ว แต่การออกแบบก็ดำเนินไปภายใต้สมมติฐานว่ายังหลีกเลี่ยงหายนะที่กำลังมาถึงได้
  • ในกระบวนการนั้น การเปลี่ยนแปลงสำคัญอย่างหนึ่งคือแทบจะ เลิกใช้เครือข่ายบัสทางกายภาพ ไปแล้ว
  • Ethernet ไม่ได้เป็นบัสจริงอีกต่อไป แค่แกล้งทำตัวเหมือนเป็นบัส และเมื่อความเร็วเพิ่มจนรักษา CSMA/CD ไว้ไม่ได้ มันก็ย้อนกลับไปสู่ star topology อีกครั้ง
  • โครงสร้างที่ลากสายเฉพาะจากแต่ละสถานีไปยังสวิตช์กลางกลายเป็นเรื่องปกติ และผนัง เพดาน และพื้นก็เต็มไปด้วยมัดสาย Ethernet ขนาดใหญ่ราคาแพง
  • แม้แต่ wifi ซึ่งดูเหมือนสื่อไร้สายที่ใช้ร่วมกันอันเป็นบัสสูงสุด ก็ถูกอธิบายว่าในทางปฏิบัติเกือบทั้งหมดทำงานแบบ 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 และถ้าทั้งสองบิตเป็นจริงพร้อมกันก็สามารถแสดงการทำงานแบบ repeater ระหว่าง AP ได้
  • หาก A เป็น repeater ที่ต้องส่งต่อไปยัง base station B อีกครั้ง ผู้ส่งผู้รับจริงบนอากาศกับ source·destination ของ Ethernet จะต่างกันทั้งหมด จึงต้องใช้ 4-address mode
  • ใน 802.11s mesh ยังมีถึง 6-address mode และข้อความต้นฉบับก็บอกว่าพอถึงจุดนั้นผู้เขียนยอมแพ้ที่จะทำความเข้าใจ

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

  • IETF ที่กำลังพิจารณา IPv6 มองเห็นทั้งความสับสนที่เกิดขึ้นแล้วและความสับสนที่ใหญ่กว่านั้นในอนาคต จึงจินตนาการถึง โลกใหม่ที่ทิ้ง legacy เดิมทั้งหมด
  • สมมติฐานของโลกนั้นคือ การเลิกใช้เครือข่ายบัสจริง, การเลิกใช้ layer 2 internetwork, การกำจัด broadcast, การกำจัด MAC address, การกำจัด ARP และ DHCP, มี IP header ที่เรียบง่ายและเร่งด้วยฮาร์ดแวร์ได้, แก้ปัญหาที่อยู่ไม่พอ และยกเลิกการตั้งค่า IP ด้วยมือยกเว้นใน core
  • หาก layer 2 เป็นจุดต่อจุดเสมอ ก็จะไม่มีเป้าหมายให้ส่ง 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 source/destination 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 อยู่ดี และแม้เครือข่ายแบบบัสจะหายไปแล้ว ก็ยังต้องจำลองสิ่งคล้าย broadcast ต่อไปเพื่อให้การทำงานแบบ ARP ยังเกิดขึ้นได้
  • ในบ้าน ผู้ใช้ยังต้องเปิด local DHCP server ต่อไปเพื่อให้หลอดไฟ IPv4 รุ่นเก่าทำงานได้ และถ้าจะให้หลอดไฟนั้นออกสู่อินเทอร์เน็ตก็ยังต้องใช้ NAT อยู่ดี
  • ที่แย่กว่านั้นคือทีม IPv6 ปล่อยให้ปัญหา mobile IP ค้างไว้โดยไม่แก้ ทำให้ยังคงต้องพึ่ง layer 2 bridging อันน่าหวาดหวั่นต่อไป
  • มีการอธิบายว่าในเวลานั้นดูเหมือนแผนคือรีบ deploy IPv6 ภายในไม่กี่ปี แล้วค่อยแก้ mobile IP ให้ง่ายขึ้นหลังจาก IPv4 และ MAC address หายไปแล้ว
  • ตอนนั้นยังเชื่อกันว่ากรณีใช้งานคอมพิวเตอร์ที่เคลื่อนที่ระหว่างใช้งานมีน้อยมาก จึงจินตนาการได้เพียงภาพประหลาดอย่างย้ายเครื่องที่ต่อ ftp อยู่จากพอร์ต Ethernet หนึ่งไปอีกพอร์ตหนึ่งเท่านั้น

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 address เดิมไม่ว่าจะต่อกับ access point ไหน และยอมรับความโกลาหลไม่กี่วินาทีระหว่างที่ bridge ปรับโครงสร้างใหม่เพื่อรักษาการเชื่อมต่อไว้
  • wifi ในบ้านที่มี extender หรือ repeater หลายตัวก็ใช้แนวทางเดียวกัน
  • ในทางกลับกัน หากเดินไปตามถนนแล้วเปลี่ยนผ่าน เครือข่าย wifi คนละชุด เช่น public wifi ของร้านค้าต่าง ๆ จะได้รับ IP address ใหม่ทุกครั้ง และทุกการเชื่อมต่อจะถูกตัด
  • LTE ไปได้ไกลกว่านั้น โดยทำให้ยังคงใช้ IP address เดิมแม้จะเคลื่อนที่หลายไมล์ระหว่างสถานีฐาน และมีการกล่าวว่าในเครือข่ายมือถือมักใช้ IPv6 address อยู่แล้ว
  • วิธีทำคือ tunnel traffic ไปยังจุดศูนย์กลางก่อน แล้ว bridge รวมกับ firewall จำนวนมากให้เป็น virtual layer 2 LAN ขนาดมหึมาชุดเดียว ซึ่งต้องแลกมากับความซับซ้อนอย่างมหาศาลและ 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 แต่ kernel จะไม่ใช้ข้อมูล layer 3 ในการระบุ socket ตอนรับข้อมูล และจะใช้เพียง uuid
  • destination port 80 จะจำเป็นเฉพาะตอนเริ่ม session ใหม่เพื่อแยกว่าต้องการบริการใด และหลังจากนั้นก็อาจละเลยหรือตัดออกได้
  • kernel ของ Y จะ cache ว่าแพ็กเก็ต session (uuid) เพิ่งมาจาก X และเมื่อ X ย้ายไป Q แล้วส่งมาพร้อมแท็ก (uuid,80) เดิม ระบบก็จะจับคู่เข้ากับ session เดิมและอัปเดตปลายทางตอบกลับจาก X เป็น Q ได้
  • วิธีนี้ช่วยให้การเชื่อมต่ออยู่ต่อได้ แต่มีข้อแม้ว่าต้องเพิ่มความระมัดระวังเพื่อป้องกัน การยึดการเชื่อมต่อโดยผู้ปลอมตัว
  • อย่างไรก็ตาม UDP และ TCP ไม่ได้ทำงานแบบนี้ และการเปลี่ยนมันตอนนี้ก็ถูกมองว่าเป็นโครงการประเภทเดียวกับการเปลี่ยน IPv4 เป็น IPv6 ซึ่งตอนแรกดูเหมือนง่ายแต่ผ่านไปหลายสิบปีก็ยังเสร็จไม่ถึงครึ่ง

QUIC และความเป็นไปได้ของทางอ้อม

  • ในด้านบวก มีการเสนอว่าการละเมิดชั้นอีกแบบหนึ่งอาจเป็น ทางอ้อมในการแก้ปัญหา
  • หากทิ้ง TCP แบบเก่าแล้วใช้ QUIC บน UDP ก็อาจทำให้ไม่ต้องใช้ 4-tuple ของ UDP เองเป็นตัวระบุการเชื่อมต่อ
  • หาก UDP port เป็นพอร์ตสำหรับ mobility layer โดยเฉพาะ ก็สามารถแกะเนื้อหาข้างในอีกชั้นแล้วตีความเป็นแพ็กเก็ตภายในที่มีแท็ก uuid ที่เหมาะสม และจับคู่เข้ากับ session และ socket ที่ถูกต้องได้
  • มีการอธิบายว่าโปรโตคอล QUIC แบบทดลอง อย่างน้อยในทางทฤษฎี ก็มีรูปแบบแพ็กเก็ตที่เข้ากับโครงสร้างนี้อยู่แล้ว
  • เนื่องจากการเข้ารหัสและการยืนยันตัวตนของแพ็กเก็ตแบบไร้สถานะที่ 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 อย่างน้อยผู้โจมตีก็ต้องเป็นระดับ man-in-the-middle ไม่ใช่แค่ผู้โจมตีภายนอกทั่วไป
    • หากใช้ โปรโตคอลที่เข้ารหัส อย่าง QUIC ก็สามารถปกป้อง handshake ดังกล่าวด้วย session key ได้เช่นกัน

  • แก้ไขเมื่อ 2017-10-24

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

  • แก้ไขเมื่อ 2020-07-09

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

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

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

 
GN⁺ 9 일 전
ความเห็นจาก 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 ล่มเป็นเรื่องปกติ แต่เดิมอินเทอร์เน็ตถูกออกแบบมาเพื่อหลีกเลี่ยงการพึ่งพาศูนย์กลางแบบนั้น สำหรับฉัน การบอกว่าไม่มีปัญหาอะไรเลยก็เหมือนกับการบอกว่า รถติด ไม่ใช่ปัญหาเพียงเพราะวันนี้ฉันยังไปทำงานถึง ต้องมองให้นานขึ้นและมองภาพใหญ่กว่านั้น