http://geocities.datacellar.net/wuttichate7"> IPv6 THE NEW INTERNET PROTOCOL
 

บทนำ

เนื่องจากการขยายตัวอย่างรวดเร็วของเครือข่ายอินเตอร์เน็ตในปัจจุบัน ทาง Internet Engineering Task Force (IETF) ได้ลงความเห็นว่าจะใช้ Internet Protocol, Version 6 (IPv6) [RFC 1883] ให้เป็น โพรโตคอลใหม่ที่จะมาแทนที่ Internet Protocol, Version 4 (IPv4) ซึ่งไม่สามารถรองรับการขยายตัวของเครือข่ายในปัจจุบัน

โฮมเพจนี้ได้ให้รายละเอียดบางประการซึ่งไม่ใช่ทั้งหมดเกี่ยวกับรายละเอียดของโพรโตคอลเวอร์ชัน 6 ซึ่งพัฒนาจากโพรโตคอลเวอร์ชัน 4 เช่น รูปแบบของ Header , การ Routing และ Addressing ฯลฯ ดังได้แสดงไว้ตามหัวข้อต่อไปนี้

รูปแบบของ IPv6 Header

สิ่งที่เปลี่ยนแปลงอย่างเห็นได้ชัดจากรูปคือขนาดของฟิลด์ที่อยู่ต้นทางกับปลายทางที่มีขนาดใหญ่ขึ้นจากเดิม 32 บิต ไปเป็น 128 บิต

เมื่อทำการเปรียบเทียบกับ format ของ IPv4 แล้วจะเห็นว่าจะตัดฟิลด์ที่ไม่จำเป็นออกไปหลายฟิลด์ ดังต่อไปนี้

  • IHL (header length field) เป็นฟิลด์ที่บอกจุดเริ่มต้นของข้อมูลหรือความยาวของ Header
  • Header Checksum เนื่องจากเกือบทุกเครือข่ายที่ packet จะผ่านนั้นมักจะทำการ encapsulate พร้อมทั้ง checksum ให้แล้ว ดังนั้นการเอาฟิลด์นี้ออกจึงไม่มีผลกระทบมากนัก
  • Identification , Flags , Fragment Offset เนื่องจาก IPv6 มีวิธีการในการตรวจสอบขนาด ของ segment ที่สามารถส่งได้ไว้ก่อน จึงไม่มีความจำเป็นที่จะต้องทำการ fragment ข้อมูลระหว่างทาง
  • TOS โดยปกติ application จะไม่ทำการ set ฟิลด์นี้ด้วยตนเอง IPv6 จึงมีวิธีการอื่นในการจัดการเรื่องนี้อยู่

ฟิลด์เดิมที่ยังคงอยู่คือ version , Source Address และ Destination Address ส่วน ฟิลด์ที่ถูกทำการ เปลี่ยนชื่อใหม่มี 3 ฟิลด์ดังนี้

  • hop limit มาแทนที่ฟิลด์ TTL เนื่องจากเดิมทีการบันทึก TTL นั้น บันทึกในหน่วยของเวลา แต่ทว่าการ ลบค่าเมื่อ packet ผ่าน router นั้นมักจะลบที่ละ 1 เพราะ delay ภายใน router นั้นมีหน่วยเป็น millisecond จึงเปลี่ยนชื่อใหม่เพื่อให้สื่อความหมายได้ตรง
  • payload length มาแทน total length แต่การจัดการจะต่างกัน ตัวอย่างเช่น ใน IPv4 เมื่อข้อมูลขนาด 400 ไบต์ถูกส่งแบบ TCP ความยาวของ segment จะเท่ากับ 400+20 (TCP header) เมื่อทำการส่ง segment นี้มาให้ IP จัดการ IP จะทำการปะหัว segment ด้วย IP header จะได้ datagramขนาดเท่ากับ 440 ไบต์ แต่ใน IPv6 จะทำการปะ header ขนาด 40 ไบต์ ให้กับข้อมูล 400 ไบต์เลย
  • next header จะทำหน้าที่เหมือนกับ protocol type โดยจะบอกชนิดของ protocal ที่มาต่อ IPv6 header

IPv6 มี ฟิลด์ใหม่เพิ่มขึ้นมา 2 ฟิลด์คือ

  • Prio. มีอยู่ทั้งหมด 16 ค่า ใช้จัดการเกี่ยวกับ priority ของ packet
  • flow label ใช้ในการกำหนดสิ่งที่ต้องใช้ในการส่งข้อมูล เช่น delay ต่างๆ การรอการกดแป้น หรือคลิกเมาส์

การเปลี่ยนแปลงจากฟิลด์ Option ไปเป็น Extension Header

จากการศึกษาพบว่า option field ใน IPv4 นั้นไม่ค่อยได้ใช้บ่อยนัก เพราะมักเป็นตัวก่อปัญหาที่ทำให้ การส่งข้อมูลนั้นช้าลงกว่าเดิม เนื่องจาก router จะต้องทำการประมวลผลกับ field นี้ก่อนจะทำการส่ง IPv6 จึง ตัดปัญหาโดยการตัด option field ออก แต่ทว่าหน้าที่บางอย่างใน option field นั้นก็สำคัญและมีประโยชน์จึง เปลี่ยนจาก option field มาใช้ extension header แทน

โดยจากปกติ การส่งข้อมูลใน IPv4 จะประกอบด้วย IP header + payload แต่ใน IPv6 สามารถ ทำการเพิ่ม extension header เข้าระหว่าง IP header กับ payload ได้ ดังตัวอย่าง ซึ่งก่อให้เกิดเป็นสายโซ่ ของ header ที่ต่อกัน ดังรูป

IPv6 ได้ระบุ extension header ไว้ 6 ชนิด ดังนี้
  • Hop-by-hop options header
  • Routing header
  • Fragment header
  • Authentication header
  • Encrypted security header
  • Destination options header

การหาเส้นทางและรูปแบบของหมายเลขที่อยู่

สถาปัตยกรรมในการ Addressing ของ IPv6 นั้นมีรากฐานมาจาก IPv4 ยกตัวอย่างเช่น multihomed ใน IPv4 นั้น subnet 1 subnet นั้นมีได้หลาย interface โดยแต่และ interface ก็จะให้มีหมาย เลข address ที่แตกต่างกันได้ ทำให้ subnet นั้นมีหมายเลข address ได้มากกว่า 1 address แต่ IPv6 นั้นต่างกันตรง ที่ 1 interface สามารถกำหนดค่า address ให้ได้หลายค่าเลยทีเดียว

IPv6 Address นั้นแบ่งเป็น 3 แบบ ดังนี้

  • Unicast ซึ่งคล้าย ๆ กับ point-to-point นั้นเอง โดยข้อมูลจะถูกส่งไปยัง interface ที่ถูกระบุเป็นจุดหมายปลายทาง เพียงจุดเดียวเท่านั้น
  • Multicast นั้นเป็นการจับกลุ่มสถานี(station) หรือ interface ที่ต้องการทำ multicast ให้อิงกับ address หนึ่ง คือ multicast address แล้วเมื่อข้อมูลถูกส่งเข้ามาที่ address นี้ router ที่สนับสนุนการ multicast ก็จะทำการตรวจสอบและส่งข้อมูลไปให้กับสมาชิกในกลุ่มของ multicast address นั้นทั้งหมด
  • Anycast จะคล้ายกับ Multicast แต่ต่างกันในขั้นตอนการส่งข้อมูล (transmission process) คือแทนที่จะให้ router กระจายข้อมูลส่งให้กับสมาชิกในกลุ่มแบบ Broadcast แต่จะทำการส่งแบบ Unicast ให้กับสมาชิกภายในกลุ่มทีละ node โดยสถานีที่ได้รับข้อมูลจะจัดการส่งข้อมูลต่อให้กับสถานีข้างเคียงไปเรื่อย ๆ

การเขียนหมายเลข Address ของ IPv6

IPv6 address นั้นสามารถเขียนในรูปแบบของเลขฐาน 16 กับ collon(:) ได้ดังตัวอย่างต่อไปนี้
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
ซึ่งเป็นรูปแบบที่ยากต่อการพิมพ์ ถึงแม้ว่าส่วนใหญ่แล้วผู้ใช้ จะข้องเกี่ยวกับชื่อของสถานีมากกว่าจะจัดการ กับหมายเลข address โดยตรง แต่ system manager นั้นต้องจัดการกับหมายเลข address เหล่านี้ จึงต้องมีวิธีการเขียนแบบย่นย่อดังนี้
  • 0 ตัวเดียว แทน 0000 ได้
  • 0 ที่อยู่นำหน้าเลขฐาน 16 อยู่สามารถละไว้ได้ในฐานที่เข้าใจ
  • ในกรณีที่ 0 อยู่ติดกันเป็นแผง สามารถใช้ :: แทน 0 เหล่านี้นได้ทั้งหมด ดังตัวอย่างของ 1080:0000:0000:0000:0008:0800:200C:417A เขียนย่อได้เป็น 1080::8:800:200C:417A

แต่การใช้ :: นั้นให้ใช้ได้เพียงครั้งเดียว เพื่อหลีกเลี่ยงความกำกวม ดังตัวอย่างเช่น 0:0:0:BA98:7654:0:0:0 เขียนเป็น ::BA98:7654:: ไม่ได้ ต้องเป็น ::BA98:7654:0:0:0 หรือ 0:0:0:BA98:7654:: อย่างใดอย่างหนึ่ง

สำหรับ IPv4 address ที่จะเขียนให้อยู่ในรูปของ IPv6 address นั้นจะใช้วิธีเติม 0 นำหน้าหมายเลข address เดิม เช่น A00:1 เขียนเป็น 0:0:0:0:0:0:A00:1 หรือ ::A00:1 หรือ จะเขียนด้วยเลขฐานสิบได้ดังนี้ ::10.0.0.1

ส่วน high-order bits ซึ่งใช้ในการ routing นั้น ยังไม่ได้กำหนดรูปแบบของการเขียนไว้ ในที่นี้จะขอใช้ IPv6 address ตามด้วย /จำนวน high-order bit ดังตัวอย่างเช่น FECD:BA98:7600::/40 หมายถึง high-oreder 40 bit จากหมายเลข address ที่กำหนดให้

การกำหนดหมายเลขที่อยู่เริ่มต้น

IPv6 แยก address พิเศษไว้ซึ่ง host และ router จะต้องแยกแยะ address เหล่านี้ออกจาก address ปกติทั่วไปได้ Address พิเศษแสดงไว้ดังตารางต่อไปข้างล่างนี้

หมายเลข Address ของ Provider

รูปแบบของ Provider Address โดยพี้นฐานจะให้เป็นดังรูป
- registry ID นั้นวางแผนไว้ว่าจะใช้ 5 บิต ในการแทนค่าดังตัวอย่างต่อไปนี้
  • 10000 multiregional (IANA:Internet Assigned Numbers Authority)
  • 01000 RIPE NCC(Reseaux IP Europeens Network Coordination Center) เป็น องค์กรเครือข่ายในแถบยุโรป
  • 11000 INTERNIC(The Internet's Network Information Center) ทำงานโดย NSI ภายใต้สัญญาขององค์กรในประเทศสหรัฐ
  • 10100 APNIC (Asia-Pacific Network Information Center) เป็นองค์กรในประเทศแถบ เอเชียแปซิฟิก

- provider ID เป็นหมายเลขที่ Internet Service Provider ได้รับมาจาก registry ที่สังกัดอยู่ โดยวางแผนไว้ว่าจะใช้ทั้งหมด 16 บิตในการแสดง และจะสงวนไว้อีก 8 บิต ไว้ใช้ในภายภาคหน้า ซึ่งจะแทนค่า 0 ไว้

- subscriber ID เป็นหมายเลข address ที่ subscriber ได้รับจาก provider อีกที โดยวางแผน ไว้ว่าจะใช้ 24 บิตในการแสดง และจะสงวนไว้ 8 บิต ซึ่งจะแทนค่า 0 ไว้
- subnetwork ID 16 บิ
- station ID 48 บิ

ผลที่ได้ก็จะได้รูปแบบของ provider address ที่มีโครงสร้างดังรูป

รูปแบบของหมายเลข Address แบบพิเศษ

  • unspecified address หรือ 0:0:0:0:0:0:0:0 ใช้กับสถานีที่ยังไม่ถูกตั้งค่า address และใช้ ในส่วนของ protocol ที่ทำการสอบถาม address โดยให้สถานีปลายทางทำการแก้ไขฟิลด์ 0::0 นี้
  • loopback address หรือ 0:0:0:0:0:0:0:1 ใช้ในการส่งดาต้าแกรมให้กับตนเอง
  • IPv4-based address เป็นการเขียน IPv4 address ในรูปของ IPv6 โดยทำการเติม 0 นำหน้า address เดิ

    ** จะเห็นได้ว่า prefix 0000 0000 ในตารางสงวนไว้เพื่อใช้กับ 3 กรณีที่กล่าวมานี้

  • site locol address นั้นสงวนไว้ให้กับองค์กรที่ใช้ TCP/IP แต่ไม่ต้องการเชื่อมต่อกับเครือข่าย อินเตอร์เน็ต เนื่องจากเกรงว่าขาดความปลอดภัยหรือไม่บางทีทางองค์กรต้องการใช้งานภายในโดยไม่มีการเสีย เวลากับการเชื่อมต่อกัลภายนอก โดยรูปแบบของ address จะเป็นดังนี้
    โดยที่ site local address ไม่สามารถทำการหาเส้นทาง ภายในอินเตอร์เน็ตได้ แต่ออกแบบมาเพื่อใช้แลกเปลี่ยนข้อมูลระหว่างเครื่องภายใน site เดียวกันเท่านั้น
  • link local address นั้นใช้กับสถานีที่ต่อเข้ากับ link หรือ local network เดียวกัน โดย packet ที่ส่งให้กับ address เหล่านี้จะไม่ถูกหน่วงไว้โดย router รูปแบบของหมายเลข address จะเป็นดังนี้

การ Multicasting และการ Anycasting

ความสามารถในการทำ multicasting นั้นเริ่มมีบทบาทมาตั้งแต่ปี 1988 ใน IPv4 แต่ทุกวันนี้ยังไม่แพร่หลายเนื่องจากบางโหนดทำ multicasting ไม่ได้ เพื่อเป็นการรับประกันว่าทุก node สามารถทำ multicasting ได้ จึงรวมบทบาทของ IGMP(Internet Group Management Protocol) ที่ใช้กับ IPv4 เข้ากับ ICMP (Internet Control Message Protocol) ของ IPv6 โดยโครงสร้างของ multicast address เป็นดังรูป
- multicast prefix = 1111 1111
- flag (4 บิต) จะใช้แค่บิตที่ 4 เท่านั้น ที่เหลือสงวนไว้ได้ใส่ค่า 0 ดังรูป
โดย T ย่อมาจาก Transient เนื่องจาก multicast address มี 2 แบบ คือ
  • แบบถาวร (permanent) ซึ่งต้องได้รับการกำหนดเลข address จาก IANA
  • แบบชั่วคราว (transient) ซึ่งเป็นเลขที่ได้จากการสุ่มค่าจาก โปรแกรม session directory ซึ่งเป็น tool ตัวหนึ่ง โดย address ที่ได้มาหลังจากการ random จะถูกตรวจสอบอยู่ตลอดเวลา โดยอัลกอริทึมที่เรียกว่า collision detection

- scope (4 บิต) เป็นดังตาราง โดยเป็นตัวจำกัดขอบเขตของ multicast group

หมายเลข Address ของ multicast ที่ถูกสงวนไว้ใช้

IPv6 ได้ระบุ group ID ถาวรไว้ใช้แล้วดังนี้
  • group ID = 0 สงวนไว้
  • group ID = 1 ระบุไว้ใช้สำหรับทุก ๆ IPv6 node address อาจใช้คู่กั
    scope = 1 (FF01::1) หมายถึง โหนดทุกโหนดบน โหนดที่อ้างอิง
    scope = 2 (FF02::1) หมายถึง โหนดทุกโหนด ที่อยู่บน link
  • group ID = 2 ระบุไว้ใช้สำหรับทุก ๆ IPv6 router address อาจใช้คู่กั
    scope = 1 (FF01::2) หมายถึง router ทุกตัวบน โหนด นี้
    scope = 2 (FF02::2) หมายถึง router ทุกตัวที่อยู่บน link
  • group ID = 100000(hex) ระบุไว้ใช้กับกลุ่มของ DHCP (Dynamic Host Configuration Servers)ทุก server

อีกทั้งยังสงวนช่วง FF02::1:0:0 - FF02::1:FFFF:FFFF ไว้ใช้กับ IPv6 ARP (Address Resolution Protocol)

การดูแลรักษากลุ่มของ Multicast

IPv6 ได้ทำการเพิ่ม ICMP ขึ้นอีก 3 ชนิดไว้จัดการเกี่ยวกับสมาชิกในกลุ่มไว้ดังนี้
  • Type 130 , Group Membership Query
  • Type 131 , Group Membership Report
  • Type 132 , Group Membership Termination

โดย ICMP ทั้ง 3 ตัวนี้จะทำหน้าที่เหมือนกับ IGMP ของ IPv4 โดยทุก ๆ message จะมีรูปแบบเดียวกัน ดังรูป

- Type field = 130,131,132
- code = 0 เสมอ
- checksum ทำหน้าที่ error checking เหมือน ICMP ทั่วไป

การ Anycast

แทนที่จะทำการส่งแพ็กเกจ ให้กับ server ที่เป็นสมาชิก multicast address พร้อมกัน แต่ anycast จะทำการ ส่งแพ็กเกจให้กับ server ที่เป็นสมาชิกแล้วให้ server เหล่านั้นจัดการส่งแพ็กเกจ ให้กับ sever ซึ่งเป็นสมาชิกกลุ่มที่อยู่ใกล้ที่สุดแทน ทำให้ anycasting สามารถนำมาใช้หา name server ที่อยู่ใกล้ที่สุด , file server ที่อยู่ใกล้ที่สุดหรือ time server ที่อยู่ใกล้ที่สุด ได้

Interdomain Routing

เนื่องจากทุก ๆ วันนี้ การคำนวนเส้นทางของข้อมูลนั้นต้องใช้ตารางหาเส้นทาง (routing table) แต่การที่จะบันทึกเส้นทางทั้งหมดนั้น จะต้องใช้ขนาด table ที่ใหญ่มาก จึงมักจะย่นย่อโดยใช้ default route เป็นเส้นทางหลักที่ใช้ในการ route ไปยังเครือข่ายอื่น ที่ไม่ได้บันทึกไว้ในตารางหาเส้นทาง แต่ตารางหาเส้นทาง ของ backbone นั้นใช้วิธีนี้ไม่ได้ จำเป็นต้องบันทึกเส้นทางทั้งหมด

ผลที่ตามมาก็คือ เมื่อ IPv6 สนับสนุน address 128 บิต ดังนั้น เมื่อ address จำนวนมากขึ้น ก็ต้องมีการเปลี่ยน แปลงการหาเส้นทางใหม่ เพื่อให้ขนาดของตารางเก็บเส้นทางมีขนาดเล็กลงด้วย โดยจะใช้ provider address ควบคู่ไปกับ โพรโตคอล IDRP (Interdomain Routing Protocol) ซึ่งใช้ในการแลกเปลี่ยนข้อมูลระหว่าง router

การเปลี่ยนแปลงจากเดิมซึ่งใช้ CIDR ไปเป็นการขึ้นกับ Providers

แต่เดิมที IPv4 ใช้ CIDR (Classless Interdomain Routing) ในการแก้ปัญหาขนาดของ ตารางหาเส้นทาง แต่หลัง จากทดลองใช้และทำการศึกษาดูแล้ว ก็พบว่า เครือข่ายอินเตอร์เน็ตที่อยู่ในแต่ละประเทศนั้น ไม่ได้ใช้ prefix ที่เหมือนกันในแต่ละ ประเทศ เช่น เครือข่ายในฝรั่งเศส บางเครือข่ายก็ไปเช่าสายจาก provider ในสหรัฐ จึงมี prefix ไม่เหมือนกัน ดังนั้น IPv6 จึงหัน มาใช้ provider address แทน เนื่องจากช่วยสะท้อนให้เห็นถึงโทโพโลยีของเครือข่ายได้อีกด้วย

การหาเส้นทางก็จะทำภายใน provider เดียวกัน ส่วนแพ็กเกจ ที่จะถูก route ไปยังต่าง provider นั้น ภายในตารางหาเส้นทางก็จะบันทึกเพียง 1 สาย ต่อ 1 provider เท่านั้นทำให้ขนาดของตารางหาเส้นทางมีขนาดเล็กลง แต่ทว่าปัญหาที่เกิดขึ้นก็คือ การใช้ provider-based addressing นั้นจะทำให้ ลูกค้า(customer) ต้องขึ้นกับ provider ดังตัวอย่าง

ในกรณีที่ลูกค้าต้องการเปลี่ยนจาก provider A ไปเป็น B มี 2 วิธีในการจัดการ

1. บอกกับ provider A และ B ว่า มีความประสงค์ที่จะใช้หมายเลข address เดิ
2. ทำการเปลี่ยนแปลงหมายเลข address ของทุก ๆ สถานีในเครือข่ายให้เป็นของ B

ในข้อ 1 นั้นถ้าต้องการจะคงหมายเลข address เดิมไว้ แต่ต่อเข้ากับ provider B นั้นคงทำไม่ได้ เพราะจะทำให้ขนาดของตารางหาเส้นทางใหญ่ขึ้นเช่นเดิม หรือในอีกกรณีหนื่

ถ้าลูกค้าต้องการต่อเครือข่ายของตนเข้ากับทั้ง 2 provider จะมีวิธีดังนี้

1. ให้ provider A เป็น default server แล้วบอก provider B ว่าจะขอใช้หมายเลข address ที่ถูกระบุโดย A
2. แบ่งเครือข่ายออกเป็นเครือข่ายย่อย (subnetwork) แล้วแบ่งใช้ระหว่าง A และ B
3. กำหนดหมายเลข address ที่ได้จากทั้ง 2 provider ให้กับสถานีเลย ซึ่งวิธีนี้ทำไม่ได้ใน IPv4

จะเห็นว่าการเปลี่ยน provider นั้นยุ่งยาก IPv6 จึงมี automatic configuration procedures มาช่วยในการแก้ปัญหา เหล่านี้

การเปลี่ยนแปลงโพรโตคอลจาก BGP-4 ไปเป็น IDRP

ในปัจจุบัน เครือข่ายอินเตอร์เน็ตแบ่งออกเป็น Autonomous System (AS) หลาย ๆ กลุ่ม โดยภายใน AS ประกอบด้วยเครือข่ายย่อยจำนวนมาก และมีโพรโตคอลที่ใช้ในการ route ข้อมูลที่แตกต่างกันในแต่ละระบบ แต่การแลกเปลี่ยนข้อมูลกันระหว่าง AS นั้นจะใช้ EGP (Exterior Gateway Protocol) ซึ่งได้ถูกพัฒนามาเป็น BGP (Border Gateway Protocol) และ BGP-4 ตามลำดับ

เหตุที่ BGP สนับสนุน CIDR นั่นเองทำให้ช่วยแก้ปัญหาขนาดของตารางหาเส้นทางได้ แต่ทว่า BGP นั้นไม่สามารถใช้กับ IPv6 ได้ IPv6 จึงออกแบบโพรโตคอลใหม่ขึ้นมาคือ IDRP โดยที่ IDRP นั้นเป็น superset ของ BGP ทั้งยังมีความสามารถในการทำ multiprotocol routing คือ ประมวลผลกับ address ได้หลายตระกูล ถึงแม้ว่า IDRP จะเป็นโปรโตคอลในตระกูลของ OSI แต่ก็ไม่ได้ขึ้นกับ OSI เลย

ช่วงของการเปลี่ยนแปลงโพรโตคอลให้กับเครือข่ายอินเตอร์เน็ต

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

กลวิธีการใช้ Dual-Stack

ในกรณีที่ทางสถานีต้องการปรับเปลี่ยนไปใช้โพรโตคอล IPv6 แต่ว่าเครือข่ายที่เชื่อมต่ออยู่ด้วยไม่สนับสนุน IPv6 ตัวสถานีจะใช้ Dual-Stack ในการจัดการแก้ปัญหา โดย Dual-Stack จะสนับสนุนโพรโตคอลทั้ง IPv4 และ IPv6 ลักษณะของ Dual-Stack จะเป็นดังรูป
จากรูปจะเห็นว่า Stack ที่อยู่ภายในสถานี้แบ่งออกเป็น 2 Stack ทำงานขนานกันโดยเมื่อมีแพ็กเกจของข้อมูลส่งมายังสถานี ทางสถานีจะทำการเลือก Stack มาจัดการกับแพ็กเกจให้ตรงกับชนิดของโพรโตคอล เพื่อคงความสามารถให้สถานีทำการติดต่อกับเครือข่ายเดิมได้อยู่เหมือนไม่มีอะไรเปลี่ยนแปลง

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

  • เปลี่ยนแปลงให้สถานีสนับสนุนโค้ดของ IPv6 , สนับสนุน ICMP ตัวใหม่ และ โค้ดในส่วนของการทำ neighbor discovery
  • เปลี่ยนแปลงการส่งข้อมูลแบบ TCP และ UDP ให้ใช้กับ IPv6 ได้
  • ปรับปรุงคลังเก็บ socket หรือ winsock ให้สนับสนุนหมายเลข Address ของ IPv6 และ interface ใหม่ที่เพิ่มขึ้น
  • เปลี่ยนแปลง interface ในส่วนของ Name Service

รายการข้างต้นนี้สามารถทำการปรับเปลี่ยนได้โดยการโปรแกรมโค้ดเพียงไม่กี่กิโลไบท์ ซึ่งไม่ใช่ปัญหาหลักสำคัญ ส่วนที่สำคัญจะเน้นเกี่ยวกับรูปแบบของ Address ที่ไม่เหมือนกัน เนื่องจาก IPv4 ใช้ขนาด Address เพียง 4 ไบต์ แต่ IPv6 ใช้ขนาด Address ถึง 16 ไบต

การปรับเปลี่ยน router ให้สนับสนุนแพ็กเกจของ IPv6 จะมีความซับซ้อนมากกว่าการปรับเปลี่ยนในส่วนของสถานี เนื่องจากจะต้องติดตั้งสิ่งต่อไปนี้ลงไปใน router

  • โค้ดที่ใช้การรับและส่งแพ็กเกจของ IPv6 (packet forwarding)
  • โปรโตคอลที่ใช้ในการหาเส้นทางของ IPv6
  • โปรโตคอลที่ใช้จัดการเกี่ยวกับการดูแลรักษาระบบของ IPv6 (IPv6 Management Protocols)
  • รับทราบถึงความเปลี่ยนแปลงของสถานีที่ต่ออยู่ว่าสถานีใดใช้ Dual-Stack และสถานีใดไม่ใช้

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

การติดต่อกับ Name Server และการค้นหาข้อมูลภายใน Name Server

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

ในส่วนของ IPv6 ก็เช่นกัน เนื่องจากหมายเลข Address มีขนาดยาวมาก การใช้ชื่อจึงเป็นสิ่งจำเป็นอย่างยิ่งในการทำงานติดต่อกับผู้ใช้ การจัดการกับ Name Server ให้สนับสนุนการสอบถามของหมายเลข Address ของ IPv6 จะเพิ่มเรคอร์ด ชนิดใหม่ลงในตารางของ DNS โดยปกติ IPv4 จะใช้เรคอร์ด A เพื่อบ่งบอกว่าหมายเลข Address เป็นชนิดของ IPv4 ในขณะที่ IPv6 จะใช้เรคอร์ด AAAA ในการบ่งบอกว่าเป็นหมายเลข Address ของ IPv6

ในการสอบถามแต่ละครั้ง IPv4 จะสอบถามผ่านทาง gethostbyname interface ดังนั้นการที่จะให้การสอบถามนั้น สนับสนุนทั้ง Address แบบ IPv4 และ IPv6 ด้วย จึงได้มีการออกแบบ hostname2addr interface มาแทนของเดิม เพื่อให้การสอบถามนั้นสามารถใช้ได้กับหมายเลข Address ของ IPv6

ข้อแตกต่างของ interface ทั้งสองอยู่ที่ gethostbyname จะส่งผ่านอาร์กิวเมนต์เพียงตัวเดียวคือชื่อของสถานีที่ต้องการสอบถามในขณะที่ hostname2addr จะส่งผ่านอาร์กิวเมนต์ 2 ตัว คือ ชื่อของสถานีปลายทางและตระกูลของ Address ต้องการสอบถาม เช่น สอบถามหมายเลข Address ที่เป็นของ IPv4 จะใช้ตระกูล AF_INET แต่ถ้าเป็นหมายเลข Address ของ IPv6 จะใช้ตระกูล AF_INET6

ในส่วนของขั้นตอนการสอบถาม ถ้าใช้ตระกูล AF_INET ในการสอบถาม การค้นหาจะค้นในส่วนของเรคอร์ดที่มีชนิด A ในตาราง DNS แล้วส่งคำตอบกลับไปให้กับผู้ร้องขอ ถ้าสอบถามด้วยตระกูลของ AF_INET6 การค้นหาจะค้นหาในส่วนของเรคอร์ดชนิด AAAA ถ้าพบคำตอบที่ตรง ก็จะตอบกลับไปให้กับผู้ร้องขอ แต่ถ้าไม่ตรงจะทำการค้นหาในเรคอร์ดชนิด A ซึ่งคำตอบที่ได้จะเป็นหมายเลข Address ที่สามารถแปลงเป็น IPv6 แล้วตรงกับคำตอบที่ต้องการได้

เมื่อได้หมายเลข Address เพื่อจะทำการสถาปนาการเชื่อมต่อ ปัญหาที่ตามมาก็คือถ้าสถานีที่จะเชื่อมต่ออยู่ในอีกแห่งซึ่งถูกแยกโดยเครือข่ายที่ไม่สนับสนุน IPv6 จะทำการเชื่อมต่อได้อย่างไร การแก้ปัญหาโดเมนย่อยของ IPv6 ที่แยกออกจากกัน จะใช้อุโมงค์ (tunnel) หรืออุปกรณ์ Bridge ในการแก้ปัญหา เพื่อให้เครือข่ายซึ่งถูกแยกออกจากกันสามารถติดต่อกันได้ แนวความคิดนี้ได้มาจาก MBONE ที่ใช้ในการทำ multicast ในปัจจุบัน

การสร้าง 6-BONE

ในกรณีของการเพิ่มสถานีที่จะใช้ IPv6 เข้าไปในเครือข่ายนั้นเป็นเรื่องง่าย เพียงแค่ติดตั้งซอฟแวร์ที่จัดการเกี่ยวกับโปรโตคอลของ IPv6 ลงไปในเครื่องและเชื่อมต่อเครื่องเข้ากับ router ที่สนับสนุนโพรโตคอลเวอร์ชั่น 6 ระบบจะทำการ Dynamic address Configuration และ neighbor discovery ให้ทันทีโดยไม่ต้องกังวลกับการจัดการเองด้วยมือ

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

โดยเทคนิกของการส่งแพ็กเกจผ่านทางอุโมงค์นั้นจะใช้วิธีการเดียวกันกับการส่งแพ็กเกจ ของ multicast คือการ Encapsulate แพ็กเกจของ IPv6 ไว้ภายใน IPv4 Header แล้วทำการส่งแพ็กเกจนั้นไปยัง router ที่สนับสนุน IPv6 ดังรูป
ในการสร้างอุโมงค์เพื่อใช้ในการส่งแพ็กเกจ จะต้องมีการตั้งค่าต่าง ๆ อย่างระมัดระวังเพื่อประสิทธิภาพในการส่งข้อมูล ส่วนใน Header ของ IPv4 ได้มีการเพิ่มหมายเลข Protocal Identifier หมายเลข 41 เพื่อบ่งบอกว่าในส่วนของข้อมูลที่ส่งมานั้นเป็นแพ็กเกจของ IPv6 การจัดการกับอุโมงค์เพื่อสร้าง 6-BONE นั้นมีปัจจัยที่ต้องกำหนดดังหัวข้อต่อไปนี้

การเลือกค่า MTU (Media Transmission Unit)

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

การที่จะลดปริมาณครั้งที่จะต้องแบ่งแพ็กเกจให้เกิดน้อยที่สุดทำได้โดย router ทั้งสองฝ่ายคอยตรวจสอบ MTU ในเส้นทางนั้นแล้วทำการตั้งค่าให้เหมาะสม การตรวจสอบนั้น IPv4 สามารถทำได้โดยการส่งแพ็กเกจหลาย ๆ ขนาดออกไปทางช่อง interface ที่ต้องการตรวจสอบ แล้วรอรับ ICMP แพ็กเกจที่ตอบกลับมา ว่าแพ็กเกจมีขนาดใหญ่เกินไปหรือไม่ จากนั้น router จะทำการปรับลดค่า MTU ประจำช่อง interface นั้นลง อีกทั้งขนาดของ MTU สามารถปรับเพิ่มค่าได้เพื่อให้ได้ขนาด MTU ที่เหมาะสมที่สุด

ตราบใดที่ MTU ของอุโมงค์มีขนาดใหญ่กว่าแพ็กเกจที่เล็กที่สุดของ IPv6 ( 576 octets ) จะไม่มีการแบ่งแพ็กเกจโดย IPv4 ซึ่งถ้าขนาด แพ็กเกจของ IPv6 ใหญ่กว่า MTU ของอุโมงค์ แพ็กเกจจะถูกทิ้งและจัดส่ง ICMP ไปเตือนผู้ส่งว่าแพ็กเกจใหญ่เกินไป แต่โอกาสที่ขนาด MTU ของอุโมงค์จะมีขนาด เล็กกว่า 576 octets นั้นเป็นไปได้ ซึ่งจะทำให้ router ของ IPv6 ต้องพิจารณาเหตุการณ์ต่อไปนี้

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

โพรโตคอลในการหาเส้นทางผ่านอุโมงค์

หลังจากอุโมงค์ถูกตั้งค่าต่าง ๆ เรียบร้อยแล้ว การหาเส้นทางระหว่าง router ผ่านอุโมงค์จะทำเหมือนกับเครือข่ายเดิมทุกประการ โดยถ้าอุโมงค์นั้นอยู่ ภายในโดเมนเดียวกัน โพรโตคอลหาเส้นทางที่ใช้ก็จะเป็นโพรโตคอล IGP จำพวก RIP หรือ OSPF แต่ถ้าอุโมงค์นั้นเป็นอุโมงค์เชื่อมระหว่างโดเมน โพรโตคอลหาเส้นทางที่ใช้ก็อาจเป็น IDRP เป็นต้น

แต่อุโมงค์ไม่เหมือนกับการเชื่อมต่อโดยตรงภายในเครือข่าย การใช้หน่วยวัดที่เหมือนเดิมอาจจะทำให้เกิดการหาเส้นทางที่ผิดเพี้ยนไปจากความต้องการได้ เพราะภายในอุโมงค์เกิดจากเส้นทางที่ IPv4 สร้างขึ้น

จากประสบการณ์ที่ได้จากการใช้ MBONE ของ multicast ในปัจจุบันทำให้ทราบว่าการเลือกหน่วยวัดเพื่อใช้กับอุโมงค์นั้นจะต้องเลือกอย่างระมัดระวัง โดยหน่วยวัดที่ใช้อาจได้มาจากการวัดค่า throughput จากการใช้โพรโตคอลหาเส้นทางจำพวก RIP หรือ OSPF กับเส้นทางในอุโมงค์นั้น หรืออีกวิธีหนึ่งอาจได้ค่าหน่วยวัดมาจากความไม่คงที่ของเส้นทางและความเร็วในการส่งภายในอุโมงค์ก็ได้ ยกตัวอย่างของ เราท์เตอร์ A และ B ซึ่งส่งผ่านข้อมูลระหว่างอุโมงค์ที่ไปตามเส้นทาง T และ U เมื่อเกิดเหตุขัดข้องระหว่าง T และ U ทำให้ไม่สามารถส่งข้อมูลผ่านเส้นทางนี้ได้ ข้อมูลอาจเปลี่ยนไปยังเส้นทาง T - V - W - U ซึ่งไกลกว่าเส้นทางเดิม และอาจจะมีความแออัดมาก ดังนั้นค่าหน่วยวัดที่ได้อาจพิจารณาจากความเป็นไปได้ของเส้นทางที่ต้องเปลี่ยนแปลงบ่อย ๆ ด้วยก็ได้

ถ้าเป็น MBONE เมื่อมีเหตุขัดข้องภายในอุโมงค์ เส้นทางที่เปลี่ยนจะถูกใช้จนกว่าเส้นทางเดิมจะกลับมาดีดังเดิม หรือสามารถเปลี่ยนไปใช้อุโมงค์อื่นได้โดยการแก้ค่าหน่วยวัดประจำอุโมงค์ แตกต่างกับ Ipv6 ที่มีแนวความคิดที่ว่า การเลือกเส้นทางและหาค่าหน่วยวัดที่เหมาะสมให้กับอุโมงค์นั้นน่าจะทำโดยอัตโนมัติมากกว่าจะตั้งด้วยมือ ซึ่งการคำนวณอาจจะได้จากการนำข้อมูลจากตารางหาเส้นทางของ IPv4 มามีส่วนร่วมในการคำนวณด้วยก็ได้

ช่วงชีวิตของแพ็กเกจภายในอุโมงค์

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

การควบคุมการเข้าใช้อุโมงค์

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

ปัญหาแบบเดียวกันนี้ได้เกิดกับเครือข่าย MBONE ของ multicast มาก่อนแต่เป็นเหตุผลที่ต่างกับที่กล่าวมา โดย แพ็กเกจของ Multicast จะใช้แอปพลิเคชั่นที่เป็นแบบ real-time ในการจัดการไม่ให้ router มาทำการควบคุมการจัดส่งแพ็กเกจได้ ถึงแม้ว่าเส้นทางที่จะส่งนั้นจะมีความแออัดของข้อมูลก็ตาม

ด้วยหลักการนี้เอง ทาง IPv6 จึงได้ใช้หลักการเดียวกับ MBONE ในการจัดการควบคุมการส่งแพ็กเกจผ่านทางอุโมงค์ซึ่งมีประโยชน์ดังนี้

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

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

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

การเชื่อมต่อจากสถานีผ่านทางอุโมงค์

ในการเชื่อมต่อโดยใช้อุโมงค์ที่กล่าวมาก่อนหน้านี้ เน้นที่ router ทำการเชื่อมต่อกับ router ผ่านอุโมงค์ แต่ตัวสถานีเองก็สามารถเข้าใช้อุโมงค์ได้โดยตรงโดยไม่ต้องผ่าน router ก่อนก็ได้ ซึ่งตัวสถานีจะมี IPv4 virtual interface ซึ่งจำลองว่าตัวสถานีเองนั้นเป็นสถานีของ IPv4 เพื่อที่จะทำการส่งแพ็กเกจออกไปยัง router หรือ สถานีอื่นได้ โดยหมายเลข Address ที่ใช้จะเป็น link local address หรือ IPv4-compatible address ก็ได้ โดยถ้าเป็น IPv4-compatible Address ทำได้โดยการเติม 0 หน้าหมายเลข Address ของ IPv4

การเชื่อมต่อจากตัวสถานีไปยังเครือข่ายที่เป็น IPv6

พิจารณาตัวอย่างกรณีที่สถานี X ต้องการส่งแพ็กเกจไปให้กับสถานี Y ซึ่งแยกกัน ตัวสถานี X จะใช้ IPv4compatible address ส่งแพ็กเกจให้กับสถานี Y โดยการส่งแพ็กเกจจะส่งให้กับ router ที่สนับสนุน IPv6 ซึ่งตามหลักการควรจะเป็น router ที่อยู่ใกล้สถานี Y ที่สุด การส่งนั้นทางสถานีจะทำการ encapsulate แพ็กเกจ IPv6 ไว้ภายใน IPv4 Header แล้วจัดส่งผ่านอุโมงค์ไปให้กับ router R1 ดังรูป ตัว router จะทำการถอดข้อมูลออกมาประมวลผลเพื่อตรวจสอบหมายเลข Address แล้วทำการจัดส่งไปให้กับสถานี Y ต่อไป การหาว่า router ตัวใดใกล้สถานีปลายทางที่สุดนั้นอาจได้จากการสอบถามจาก DHLC server ก็ได้
ส่งที่จำเป็นต่อวิธีการนี้มีดังนี้
  • ทางสถานีต้องรู้หมายเลข Address ของ router ที่สนับสนุน IPv6
  • router ต้องสามารถประมวลผลกับแพ็กเกจที่ได้รับและทำการส่งต่อได้
  • ต้องมีอุโมงค์ที่ใช้ส่งแพ็กเกจไปยัง router ซึ่งทำการตั้งค่าพารามิเตอร์ต่าง ๆ ไว้แล้ว

การเชื่อมต่อจากสถานีต้นทางซึ่งสนับสนุน IPv6 ไปยังสถานีปลายทางซึ่งสนับสนุน IPv6

ในกรณีที่สถานีปลายทางเป็นสถานีของ IPv4 ที่สนับสนุน IPv6 และสถานีต้นทางที่จะทำการส่งมีการเชื่อมต่อกับสถานีหรือเส้นทางที่สนับสนุนแต่ IPv4 การส่งข้อมูลจะทำการส่งได้โดยตรงผ่านทางอุโมงค์เลย โดยหมายเลข Address ของสถานีปลายทางที่จะส่งจะเป็น หมายเลขของสถานีซึ่งเป็น IPv4 ที่แปลงเป็นรูปแบบของ IPv6 ด้วยการเติม 0 ข้างหน้าหมายเลข Address ดังรูป สถานี Y ทำการส่งแพ็กเกจไปให้กับสถานี X ผ่านทางอุโมงค์
ในกรณีที่ตัวสถานีที่ต้องการส่งแพ็กเกจไม่มีส่วนเชื่อมต่อกับเครือข่ายแบบ IPv4 การส่งแพ็กเกจจะจัดส่งไปยัง router ซึ่งสนับสนุน IPv6 ที่อยู่ใกล้กับปลายทางที่สุด แล้วให้ router จัดการส่งข้อมูลไปยังปลายทางต่อไป ดังรูป สถานี Y จะทำการส่งแพ็กเกจให้กับ router R2 ก่อนที่จะให้ R2 ทำการส่งแพ็กเกจให้กับสถานี X ต่อไป

บทสรุป

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

จากการเปลี่ยนแปลงของฟิลด์ที่อยู่เพื่อให้สามารถอ้างที่อยู่ได้มากขึ้น โพรโตคอลและแอปพลิเคชั่นที่ใช้อยู่ในปัจจุบัน ต้องรองรับกับโพรโตคอลเวอร์ชัน ใหม่ ผลก็คือต้องมีการปรับปรุง โพรโตคอลและแอปพลิเคชั่นเหล่านี้ให้สามารถใช้ได้กับ Ipv6 อาทิเช่น โพรโตคอลการหาเส้นทาง แบบ IDRP, การเพิ่มชนิดของ ICMP ขึ้นมาใหม่เพื่อรองรับการเปลี่ยนแปลง การจัดการเกี่ยวกับ Name Service และการเปลี่ยน socket ให้เหมาะสมกับ โพรโตคอลเวอร์ชันใหม่นี้

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

เอกสารอ้างอิง

1 1 1