# NAT64 & DNS64 คืออะไร? คู่มือ IPv6 Transition สำหรับ SME ไทย 2026
IPv4 Address Pool ของ APNIC หมดมาตั้งแต่ปี 2011 และต้นทุนการเช่า IPv4 Public IP ในตลาดรองพุ่งทะลุ 60 USD ต่อ IP ในช่วงปี 2024-2026 องค์กรไทยจึงเริ่มหันไปใช้ IPv6-only Network เพื่อลดต้นทุน แต่ปัญหาคือ Internet ส่วนใหญ่ยังเป็น IPv4-only โดยเฉพาะระบบเก่าและบริการพันธมิตรที่ไม่รองรับ IPv6
NAT64 + DNS64 คือคำตอบที่ใช้ในวงการ ISP, Mobile Operator, Cloud Provider และตอนนี้กำลังลงสู่ระดับ SME ผู้ใช้ปลายทางบน IPv6 Network สามารถเรียกใช้บริการ IPv4 ได้โดยอัตโนมัติ ไม่ต้องแก้แอพและไม่ต้องตั้งค่าฝั่ง Client
บทความนี้จะอธิบาย Architecture, การ Config Jool/Tayga, ความแตกต่างระหว่าง NAT64 / Dual Stack / 464XLAT, ปัญหา Edge Case และ Roadmap 6 เดือนสำหรับ SME ไทยที่ต้องการเปลี่ยนผ่าน IPv6
NAT64 และ DNS64 ทำงานร่วมกันอย่างไร
NAT64 (RFC 6146) คือกลไกแปลง IPv6 Packet เป็น IPv4 Packet ส่วน DNS64 (RFC 6147) ทำหน้าที่ Synthesize AAAA Record ขึ้นจาก A Record เดิมเพื่อให้ Client IPv6 สามารถ Resolve ชื่อโดเมน IPv4-only ได้ การทำงานเป็นคู่สำคัญมาก เพราะถ้ามี NAT64 อย่างเดียวแต่ DNS ตอบกลับเฉพาะ A Record, Client IPv6 จะไม่รู้จะส่ง Packet ไปที่ไหน
ขั้นตอน Resolve และ Forward สำหรับ Client IPv6-only เรียก example.com ที่ขึ้นเฉพาะ A Record:
| ขั้น | Component | การทำงาน |
|-----|-----------|----------|
| 1 | DNS64 Resolver | Client query AAAA → ไม่มี → Fallback ไป A Record → Synthesize เป็น 64:ff9b::A.B.C.D |
| 2 | Client | เห็นว่ามี AAAA Record เลยส่ง Packet ผ่าน IPv6 ไปยัง 64:ff9b::A.B.C.D |
| 3 | NAT64 Gateway | ถอด Prefix 64:ff9b::/96 ออก ได้ IPv4 ปลายทางเดิม แปลง Packet IPv6 → IPv4 + แปลง Source IP เป็น Pool IPv4 ของ Gateway |
| 4 | Server IPv4 | ตอบกลับมาที่ NAT64 Gateway ระบบแปลงกลับและส่งกลับให้ Client IPv6 |
Prefix 64:ff9b::/96 คือ Well-known Prefix ที่ IANA จัดสรรไว้ แต่บางองค์กรใช้ Network-Specific Prefix ของตัวเอง เช่น 2001:db8:64::/96 ซึ่งช่วยลด Hijacking risk และทำ Routing ง่ายกว่า
เปรียบเทียบ NAT64 vs Dual Stack vs 464XLAT
| ประเด็น | Dual Stack | NAT64 + DNS64 | 464XLAT |
|--------|-----------|---------------|---------|
| Client มี IPv4 ส่วนตัว | มี | ไม่มี | มี (CLAT จำลอง IPv4) |
| รองรับ IPv4 Literal | รองรับ | ไม่รองรับ | รองรับ |
| ต้นทุน IPv4 Address | สูง | ต่ำสุด | ต่ำ |
| ความซับซ้อนของ DNS | ต่ำ | สูง (ต้อง DNS64) | กลาง |
| เหมาะกับ | Enterprise LAN | Mobile, IPv6-only | Mobile, IoT |
| Application Compatibility | สูงสุด | กลาง | สูง |
ปัจจุบัน Carrier ใหญ่ใน EU และเอเชียส่วนมากใช้สถาปัตยกรรม 464XLAT (CLAT บนมือถือ + PLAT/NAT64 บน Core) เพราะรองรับ Legacy App ที่เรียก IPv4 Literal ได้ ส่วน SME ขนาดเล็ก-กลางมักเริ่มจาก NAT64 + DNS64 บน Datacenter ก่อนแล้วค่อย Pilot 464XLAT เมื่อมีคนใช้งานเยอะขึ้น
วิธี Deploy NAT64 ด้วย Jool บน Linux
Jool เป็น Open-source NAT64/SIIT Implementation ที่ทำงานเป็น Linux Kernel Module ใช้บน Production ในหลาย ISP ขั้นตอน Deployment โดยสรุป:
หลังจากนั้นต้องตั้ง Route ให้ Prefix 64:ff9b::/96 ส่งผ่าน NAT64 Gateway, และตั้ง DNS64 บน BIND9, Unbound หรือใช้ public DNS64 ของ Google (2001:4860:4860::6464)
ทางเลือกอื่น ๆ คือ Tayga (User-space, ทำงานบน TUN device, ตั้งง่ายแต่ Throughput ต่ำกว่า), หรือ Hardware ASIC บน Cisco IOS XR / Juniper MX series สำหรับ ISP Scale
ปัญหา Edge Case ที่ต้องเฝ้าระวัง
แม้สถาปัตยกรรม NAT64 + DNS64 จะดูสมบูรณ์ในทฤษฎี แต่ใน Production มี Edge Case ที่ทีม IT ต้องเตรียมรับมือ:
Roadmap 6 เดือน สำหรับ SME ที่ย้ายขึ้น IPv6
สรุปและก้าวต่อไป
NAT64 + DNS64 เป็นเครื่องมือสำคัญสำหรับองค์กรที่ต้องการลดต้นทุน IPv4 และเตรียมพร้อมยุค IPv6-only แต่ไม่ใช่กระสุนเงิน ทุกองค์กรควรเริ่มจาก Dual Stack Production ก่อน แล้วค่อย Layer NAT64 เข้ามาเพื่อรองรับ Client IPv6-only
สิ่งที่ทำให้โครงการพังบ่อยคือ DNSSEC, IPv4 Literal และการเก็บ Log สำหรับ Compliance ต้องวางแผนให้ครบทั้ง 3 จุด แนะนำให้ทำ Pilot 8-12 สัปดาห์ก่อน Rollout วงกว้าง
> CTA: หากทีม IT ของคุณต้องการ Workshop วาง IPv6 Address Plan + Pilot Jool NAT64 ติดต่อ ADS FIT เพื่อรับคำปรึกษา และอ่านต่อบทความ Subnetting & CIDR หรือ NetFlow vs sFlow vs IPFIX สำหรับการ Monitor Traffic IPv6 อย่างมีประสิทธิภาพ