IPv6 Expander: expand และ compress ที่อยู่ IPv6 สู่รูปแบบมาตรฐาน RFC 5952

ลองให้วิศวกรสามคนเขียนที่อยู่ IPv6 เดียวกันลงกระดาษ คำตอบที่ได้อาจมีสามแบบ ที่อยู่ 2001:db8:85a3::8a2e:370:7334, รูปแบบเต็ม 2001:0db8:85a3:0000:0000:8a2e:0370:7334 และแบบตัวพิมพ์ใหญ่อย่าง 2001:DB8:85A3::8A2E:370:7334 ล้วนถูกต้องตามมาตรฐานทั้งหมด เพราะ IPv6 อนุญาตให้ compress ช่วงศูนย์ด้วย :: และไม่สนใจตัวพิมพ์เล็กใหญ่ของเลขฐานสิบหก ทุกสายอักขระเหล่านี้ชี้ไปที่ค่า 128 บิตเดียวกัน แต่ไม่มีสายอักขระไหนเหมือนกันทีละตัวอักษรเลย

ความยืดหยุ่นแบบนี้กลายเป็นปัญหาเชิงความถูกต้องทันทีที่ระบบเอาที่อยู่มาเทียบกันแบบข้อความ ระบบ configuration management จะมองว่า fe80::1 กับ fe80:0:0:0:0:0:0:1 เป็นข้อความต่างกัน แล้วสร้าง firewall rule ซ้ำขึ้นมาอย่างเงียบ ๆ การ grep log ด้วยสะกดหนึ่งแบบจะพลาดรายการที่ถูกบันทึกด้วยอีกแบบ และ ACL ที่ไม่ยอม match traffic ที่ตั้งใจไว้เพราะระบบหนึ่งเก็บแบบย่อ อีกระบบเก็บแบบเต็ม มักใช้เวลาไล่หลายชั่วโมง ทั้งที่ที่อยู่เท่ากันจริง แค่ข้อความไม่เท่ากันเท่านั้น

IPv6 Expander ตัดปัญหาพวกนี้ทิ้งไปได้ในการ paste ครั้งเดียว วางที่อยู่ IPv6 ลงไปแล้วเครื่องมือจะ expand :: ให้เป็นรูปแบบเต็ม 8 group, compress กลับเป็นรูปแบบมาตรฐานตาม RFC 5952, ตรวจสอบความถูกต้องของ input, ตรวจจับประเภทที่อยู่ และแสดง breakdown ราย group ครบทั้ง 128 บิต ทุกอย่างรันในเบราว์เซอร์ของคุณ ที่อยู่ภายในเครือข่ายจึงไม่หลุดออกจากเครื่องไปไหน

ทำไมต้องใช้ IPv6 Expander?

• ที่อยู่หนึ่งหมายเลข สะกดเดียว RFC 5952 กำหนดวิธีเขียนที่อยู่ IPv6 แต่ละหมายเลขไว้เพียงรูปแบบเดียว การ normalize ก่อนเก็บหรือก่อนเทียบจึงตัดบั๊กประเภทข้อความไม่ตรงกันออกไปทั้งตระกูล
• ตรวจสอบก่อนตีความเสมอ :: ซ้อนสองที, group ที่มีเลขฐานสิบหกห้าตัว หรือตัวอักษรแปลกอย่าง g จะถูกจับได้ทันที ไม่ปล่อยให้ค่ามั่วไปแพร่เข้า config, script และกฎการแจ้งเตือน
• ตรวจจับประเภทที่อยู่ให้อัตโนมัติ global unicast, link-local fe80::/10, unique local fc00::/7, multicast, loopback และ IPv4-mapped ถูกระบุให้ระหว่างที่คุณพิมพ์ ซึ่งมักเป็นคำตอบเร็วที่สุดว่าทำไม routing ถึงไม่เป็นไปตามคาด
• มี breakdown ราย group ให้ดูจบ ทั้งแปด group ขนาด 16 บิตถูกแสดงแยกกัน คุณจะเห็นชัดว่า :: ถูกขยายเป็นกี่ group และเส้นแบ่งระหว่าง network prefix กับ interface ID อยู่ตรงไหน
• ทำได้ทั้งสองทิศทาง expand ที่อยู่แบบย่อเมื่อเครื่องมือระดับต่ำหรือ reverse zone ต้องใช้ และ compress แบบยาวให้กระชับสำหรับ config, dashboard และ log
• ไม่อัปโหลดอะไรเลย การ parse และจัดรูปแบบทั้งหมดเกิดขึ้นฝั่ง client ที่อยู่ของ firewall และระบบภายในจึงไม่เคยออกจากเครื่องคุณ

ฟีเจอร์หลัก

• รูปแบบเต็มคือสิ่งที่ reverse DNS zone และเครื่องมือระดับ packet ต้องการ ส่วนรูปแบบ compress แล้วคือสิ่งที่ inventory และไฟล์ configuration ควรใช้
• สองอย่างรวมกันทำให้แท็บเดียวในเบราว์เซอร์ทำหน้าที่เป็นทั้ง linter, formatter และคู่มือฉบับพกสำหรับที่อยู่ที่อยู่ตรงหน้า

วิธีใช้งาน

1. เปิด IPv6 Expander โหลดทันทีในเบราว์เซอร์ทุกยี่ห้อ ไม่ต้องติดตั้ง ไม่ต้องมีบัญชี
2. Paste หรือพิมพ์ที่อยู่ลงไป สะกดแบบไหนก็ได้ ทั้งแบบย่อ แบบเต็ม ตัวพิมพ์ใหญ่หรือผสม ระบบตรวจสอบให้ระหว่างที่คุณพิมพ์
3. อ่านผล expand เต็ม 8 group ทุก group ขนาด 16 บิตถูกแสดงครบสี่หลัก ไม่มีอะไรถูกซ่อนไว้หลัง :: อีกต่อไป
4. คัดลอกรูปแบบ canonical ตาม RFC 5952 สะกดแบบตัวพิมพ์เล็กที่ compress น้อยที่สุดนี่แหละคือแบบที่ควรเก็บลง inventory, template และกฎการแจ้งเตือน
5. ดูประเภทที่อยู่ที่ตรวจพบ การรู้ว่าที่อยู่นี้เป็น global, link-local หรือ unique local มักอธิบายพฤติกรรมแปลก ๆ ของ traffic ได้ในแวบเดียว

เจาะลึก :: shorthand และรูปแบบมาตรฐาน RFC 5952

ที่อยู่ IPv6 คือข้อมูล 128 บิตที่เขียนเป็นแปด group ขนาด 16 บิต แต่ละ group เขียนด้วยเลขฐานสิบหกหนึ่งถึงสี่หลักคั่นด้วยโคลอน ในรูปแบบเต็มทุก group จะมีครบสี่หลัก เช่น 2001:0db8:85a3:0000:0000:8a2e:0370:7334 เพราะที่อยู่จริงส่วนใหญ่มีช่วงศูนย์ยาว ๆ รูปแบบจึงเปิดให้ใช้ทางลัดสองอย่าง คือตัดเลขศูนย์นำหน้าใน group ได้ (0db8 เหลือ db8) และแทนช่วง group ศูนย์ติดกันหนึ่งช่วงด้วยโคลอนคู่ได้

การ expand ก็คือทางกลับกัน :: จะเติมช่องว่าง โดยใส่ group ศูนย์ที่หายไปลงตรงตำแหน่งโคลอนคู่ จนกว่าที่อยู่จะกลับมามีครบแปด group กฎที่ทำให้ทั้งหมดไม่กำกวมคือ :: ต้องมีได้เพียงครั้งเดียวต่อที่อยู่ ถ้ามีสองที่ ความยาวของช่องว่างทั้งสองจะอ่านไม่ออก นั่นคือเหตุผลที่ input แบบนี้ถือว่า invalid และถูกปฏิเสธทันที

RFC 5952 ยุบทุกสะกดที่เป็นไปได้ให้เหลือรูปแบบ canonical เดียวที่คำนวณได้แน่นอน:

• ใช้ตัวอักษรฐานสิบหกแบบตัวพิมพ์เล็ก
• ตัดเลขศูนย์นำหน้าออกจากทุก group
• ยุบช่วง group ศูนย์ที่ยาวที่สุดเท่าที่มี (ตั้งแต่สอง group ขึ้นไป) ถ้าสองช่วงยาวเท่ากันให้ยุบช่วงซ้ายสุด
• ห้ามยุบ group ศูนย์ที่มีตัวเดียว

ประเภทของที่อยู่ดูได้จากบิตนำของ group แรก ที่อยู่ในช่วง 2000::/3 ซึ่งรวม 2001:db8::/32 ที่สงวนไว้ให้งานเอกสาร เป็น global unicast ช่วง fe80::/10 เป็น link-local ที่ถูก auto-configure บนทุก interface และไม่ถูก route ข้ามเครือข่าย ช่วง fc00::/7 คือ unique local address ซึ่งทำหน้าที่คล้าย private IP ของ RFC 1918 ในโลก IPv6 นอกจากนี้เครื่องมือยังจำแนก multicast ff00::/8, loopback ::1 และ IPv4-mapped ::ffff:0:0/96 ได้อีกด้วย

ตัวอย่างจริง ทำครบทั้งสองทิศทาง

เริ่มจาก 2001:db8:85a3::8a2e:370:7334 การ expand จะเติมช่องว่างด้วย group ศูนย์สองตัวและคืนทุก group ให้ครบสี่หลัก:

2001:db8:85a3::8a2e:370:7334
  กลายเป็น 2001:0db8:85a3:0000:0000:8a2e:0370:7334

การ compress กลับใช้กฎของ RFC 5952 คือตัดเลขศูนย์นำหน้า (0db8 เหลือ db8, 0370 เหลือ 370) แล้วยุบช่วงศูนย์ที่ยาวที่สุด นั่นคือ 0000 ติดกันสองตัว ลงเป็น :::

2001:0db8:85a3:0000:0000:8a2e:0370:7334
  กลายเป็น 2001:db8:85a3::8a2e:370:7334

ทั้งสองสายอักขระคือที่อยู่เดียวกัน แต่แบบที่สองเท่านั้นที่เป็นสะกดเดียวที่ระบบที่ยึด RFC 5952 ควร emit, เก็บและนำไปเทียบ

ทำไมการ normalize ถึงสำคัญ

Firewall และกฎ ACL ตัวอุปกรณ์เทียบที่อยู่ แต่ผู้ audit, เครื่องมือ diff และ version control เทียบข้อความ ถ้าไฟล์กฎชุดหนึ่งเขียน prefix เป็น fd12:3456:789a::/48 อีกชุดเขียน fd12:3456:789a:0:0:0:0:0/48 การ review อัตโนมัติจะมองข้ามกฎซ้ำ และคน review ก็จะเถียงกันเรื่องความเท่ากัน รูปแบบ canonical ช่วยปิดประเด็นก่อนจะเริ่มเถียง

DNS reverse zone reverse zone แบบ ip6.arpa เขียนที่อยู่เป็น 32 nibble เรียงย้อนกลับ ซึ่งสร้างได้จากที่อยู่แบบเต็มเท่านั้น เพราะไม่มีทางไล่กลับ :: ได้ การ expand จึงเป็นเงื่อนไขบังคับ ไม่ใช่เรื่องของรสนิยม

การ match ใน log web server, load balancer และ application framework แต่ละตัวพิมพ์ที่อยู่ IPv6 ตามนิสัยของตัวเอง การ grep ด้วยแบบย่อจะพลาดแบบเต็มที่นอนอยู่ในไฟล์เดียวกัน การ normalize ทั้งเข็มและกองหญ้าคือทางเดียวที่เชื่อถือได้ในการ correlate เหตุการณ์ข้ามระบบ

กรณีการใช้งานจริง

Audit กฎ firewall

ส่งออก rule base, expand ที่อยู่ทุกตัวเป็นแบบ 8 group แล้วจัดเรียง กฎซ้ำ กฎที่ถูกบัง และ prefix ที่ต่างกันนิดเดียวจะโผล่มาทันทีเมื่อที่อยู่เดียวกันในที่สุดก็หน้าตาเหมือนกัน breakdown ราย group ยังช่วยจับความผิดพลาดอย่างการเขียน scope เป็น /64 ทั้งที่ตั้งใจระบุเครื่องเดียว เพราะ group ศูนย์ที่เกินมามองเห็นได้ ไม่ถูกซ่อนใน ::

Correlate ข้อมูลจาก log

เมื่อต้องการรู้ว่า client คนเดียวทำอะไรบ้างทั้งใน proxy, web server และ application log ให้ normalize ที่อยู่เป็นรูปแบบ canonical แล้วค้นด้วยสะกดนั้นทุกที่ วิธีนี้ยังใช้คู่กับเครื่องมือวิเคราะห์ log ได้ดี ลองรัน Nginx Log Analyzer กับ access log ก่อน แล้วค่อย expand ที่อยู่ IPv6 ของ client ที่เจอ เพื่อเอาไปเขียนกฎการแจ้งเตือนต่อ

ตั้งค่า DNS

เขียน record AAAA ฝั่ง forward ง่าย แต่การเขียน reverse zone ที่คู่กันไม่ง่าย ให้ expand ที่อยู่ออกมาก่อน หั่นเป็น 32 nibble เรียงย้อนกลับ แล้วต่อท้ายด้วย ip6.arpa การทำมือทีละที่อยู่ผิดง่ายมาก และ nibble ที่สลับตำแหน่งเพียงตัวเดียวก็ทำให้ reverse lookup เงียบไปเลยโดยไม่มี error การเริ่มจากรูปแบบเต็มทำให้ทุกขั้นตอนตรวจสอบย้อนกลับได้

วางแผน subnet

ขอบเขต /64 ที่ใช้กันทั่วไปอยู่กลางที่อยู่พอดี สี่ group แรกเป็น routing prefix และสี่ group หลังเป็น interface identifier ที่อยู่แบบ compress มักกลืนเส้นแบ่งนี้หาย โดยเฉพาะเมื่อ :: กลืนบางส่วนของฝั่งใดฝั่งหนึ่งไป รูปแบบเต็มทำให้ขอบเขตของ prefix มองเห็น ช่วยให้การ review การจัดสรรเร็วขึ้น และภาพหน้าจอในเอกสารก็อ่านเข้าใจได้เอง

แนวปฏิบัติที่ดี

• เก็บที่อยู่ในรูปแบบ canonical ของ RFC 5952 inventory, CMDB และ configuration template ควรมีสะกดเดียวต่อหนึ่งที่อยู่ เพื่อให้ทุกผู้อ่าน ทั้งคนและ script เห็นข้อความชุดเดียวกัน
• Expand ก่อนเทียบเสมอ script ไหนที่ match, ลบซ้ำ หรือ diff ที่อยู่ ควร normalize ทั้งสองฝั่งก่อน เมื่อ normalize แล้ว ความเท่ากันของข้อความจะหมายถึงความเท่ากันของที่อยู่จริง ๆ
• ตรวจสอบที่ด่านหน้า ให้ที่อยู่ที่ผู้ใช้ป้อนผ่านการตรวจสอบก่อนเข้าสู่ระบบ และปฏิเสธแทนการเดาแก้ ที่อยู่ที่เพี้ยนแต่เก็บไว้ "กันลืม" คือรายงานเหตุการณ์ฉุกเฉินฉบับอนาคต
• ใช้ตัวพิมพ์เล็กทุกที่ ตัวพิมพ์ของเลขฐานสิบหกไม่มีผลกับโปรโตคอล แต่มีผลกับ diff, grep และ index แบบสายอักขระทุกตัวในฐานข้อมูลของคุณ
• จำไว้ว่า :: มีได้ครั้งเดียว ถ้าที่อยู่ไหนดูเหมือนต้องใช้สองที่ แปลว่ามันไม่ใช่ที่อยู่ IPv6 ที่ถูกต้อง ให้ flag ไว้ อย่าเดาแทน
• ใช้ช่วง documentation ในตัวอย่าง 2001:db8::/32 ถูกสงวนไว้เพื่อให้ tutorial, ticket และภาพหน้าจอไม่หลุด prefix จริงออกไปสู่โลกภายนอก

เริ่ม normalize ที่อยู่ IPv6 ตัวถัดไปของคุณ

ที่อยู่ที่คุณเขียนไปทั้งสัปดาห์นี้ น่าจะมีอยู่ในหลายสะกดกระจายอยู่ตาม config และ log ของคุณ ลองวางหนึ่งตัวลง IPv6 Expander คัดลอกรูปแบบ canonical ตาม RFC 5952 ออกมา แล้วให้สะกดเดียวนั้นเป็นสะกดที่ระบบของคุณเก็บ เทียบและบันทึกลง log เครื่องมือนี้รันในเบราว์เซอร์ทั้งหมด ฟรี ไม่จำกัด และไม่มีข้อมูลใดออกจากเครื่องคุณ

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• Base Converter — แปลงค่าของแต่ละ group ระหว่าง hex, decimal และ binary เวลาวางแผน subnet IPv6
• URL Parser — แยก URL ทุกแบบ รวมถึงกรณีมี IPv6 literal ในวงเล็บเหลี่ยม ออกเป็น scheme, host, port และ path
• Nginx Log Analyzer — สลาย access log และช่วยจับ traffic IPv6 ที่ซ่อนอยู่หลังสะกดที่ไม่ตรงกัน

ขอให้สนุกกับการ expand!

คำถามที่พบบ่อย

ถ: ใช้ที่อยู่แบบย่อหรือแบบเต็มในไฟล์ config ต่างกันไหม? ตอบ: ในทางฟังก์ชันไม่ต่าง ทั้งคู่ parse ออกมาเป็น 128 บิตเดียวกัน แต่ในทางปฏิบัติต่าง เพราะการเลือกใช้รูปแบบ canonical ตาม RFC 5952 ทำให้การ review, diff และ grep เป็นไปอย่างคาดเดาได้ในทุกระบบที่แตะไฟล์นั้น

ถ: ที่อยู่หนึ่งตัวมีโคลอนคู่ :: ได้กี่ครั้ง? ตอบ: ได้เพียงครั้งเดียว เพราะถ้ามีสองที่ ความยาวของช่องว่างศูนย์แต่ละช่วงจะอ่านไม่ออกว่ากี่ group validator จะ flag input ลักษณะนี้ให้ทันที

ถ: ทำไมตอน expand ยังเก็บ group อย่าง 0db8 แต่พอ compress กลับตัดศูนย์ทิ้ง? ตอบ: เพราะการ expand ต้องแสดงทุก group ครบสี่หลัก นั่นคือรูปแบบ 128 บิตที่ครบและไม่กำกวม ส่วนกฎ compress ของ RFC 5952 ตัดเลขศูนย์นำหน้าออก เพราะมันไม่ได้บอกข้อมูลอะไรเพิ่ม มีแต่ทำให้สายอักขระยาวโดยใช่เหตุ

ถ: เครื่องมือตรวจจับประเภทที่อยู่แบบไหนได้บ้าง? ตอบ: global unicast, link-local, unique local, multicast, loopback, IPv4-mapped และช่วง documentation โดยดูจากบิตนำของ group แรกทั้งหมด

ถ: มีข้อมูลอะไรถูกส่งไปเซิร์ฟเวอร์ไหม? ตอบ: ไม่มี การ parse, ตรวจสอบและจัดรูปแบบทั้งหมดรันในเบราว์เซอร์ของคุณ ที่อยู่ของเครือข่ายภายในจึงไม่มีทางออกจากเครื่องไปไหน