ใช้อินเทอร์เน็ตโดยไม่ต้องมีการเชื่อมต่อ IPv4

 (jamesmcm.github.io)
3 คะแนน โดย GN⁺ 2025-06-30 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังไฟดับเกิดสถานการณ์ที่ การเชื่อมต่อ IPv4 ฝั่ง ISP หลุดไปแต่ IPv6 ยังใช้งานได้ จึงใช้ Hetzner VPS ที่มีทั้ง IPv4/IPv6 และอุโมงค์ WireGuard เพื่อกู้การเข้าถึงเว็บไซต์ที่รองรับเฉพาะ IPv4
  • ปัญหาน่าจะเกิดที่ชั้น CG-NAT ซึ่งแปลงแพ็กเก็ต IPv4 ได้ไม่ถูกต้องจนถูกทิ้ง ทำให้บริการที่รองรับ IPv6 อย่าง Google และ Meta ยังเข้าได้ตามปกติ
  • เมื่อตั้ง WireGuard server ไว้บน VPS และให้ไคลเอนต์ใช้ ที่อยู่ IPv6 ของ VPS เป็น endpoint ก็สามารถส่งทราฟฟิก IPv4 ผ่าน VPS เพื่อกู้การท่องเว็บทั่วไปกลับมาได้
  • VPN สำหรับงานและ Docker ต้องจัดการแยกต่างหาก จึงรันภายใน network namespace ที่อิงกับ vopono พร้อมวิธีอ้อมด้วย unshare และ bind mount /sys
  • อาการที่มีเพียงบางเว็บไซต์โหลดไม่ขึ้นเกิดจาก WireGuard MTU ใหญ่เกินไป และแก้ได้ทันทีเมื่อปรับลงเป็น 1280 ซึ่งเป็นค่า MTU ขั้นต่ำของ IPv6

ปัญหาที่หลังไฟดับ IPv4 หลุดไปอย่างเดียว

  • หลังไฟดับและยกเบรกเกอร์กลับขึ้นมาแล้ว ไม่สามารถเข้า GitHub และเว็บไซต์หลายแห่งได้ แต่ Google กับ Meta ยังทำงานปกติ
  • จากการตรวจด้วย ping -6 และ traceroute ทั้งบนเครื่องโลคัลและหน้าวินิจฉัยของเราเตอร์ พบว่าปัญหาเกิดเฉพาะกับการ เชื่อมต่อไปยังเซิร์ฟเวอร์ IPv4
  • ISP แจ้งว่าอาจต้องให้ช่างเข้ามาดูและอาจใช้เวลาหลายวันหลังสุดสัปดาห์ ซึ่งรอไม่ได้เพราะต้องเข้าระบบงานและทำงานวิจัย
  • เดิมมี Hetzner VPS ที่มีที่อยู่ IPv4 แบบคงที่และ IPv6 อยู่แล้ว และเว็บไซต์ของ Hetzner ก็รองรับ IPv6 จึงเข้า console ไปตั้งค่าได้

การพึ่งพา IPv4 ที่เกิดจาก NAT และ CG-NAT

  • ที่อยู่ IPv4 มีขนาด 32 บิต และเมื่อตัดบล็อกที่สงวนไว้แล้ว จะมี public IPv4 address เพียงประมาณ 3.7 พันล้าน ที่อยู่ จึงไม่สามารถแจกให้ทุกอุปกรณ์ที่เชื่อมต่ออินเทอร์เน็ตมีที่อยู่ตรงได้
  • NAT ทำให้อุปกรณ์หลายตัวแชร์ public IP เดียวกันได้
    • เราเตอร์ที่บ้านจะแปลง local IP เช่น 192.168.1.xxx ของอุปกรณ์ภายใน ให้เป็น public IPv4 ของตัวเอง
    • conntrack ของ Linux จะเก็บ mapping ของ source IP และพอร์ตเดิม กับพอร์ตที่ถูกแปลงไว้
    • เมื่อแพ็กเก็ตตอบกลับมาที่พอร์ตนั้น conntrack จะเปลี่ยนปลายทางกลับเป็น IP และพอร์ตภายในเดิม
    • บน Linux สามารถดู mapping ที่เก็บไว้ได้ด้วย conntrack -L จาก conntrack-tools
  • NAT ทำงานคล้ายไฟร์วอลล์โดยปริยาย ทำให้บริการบนเครื่องภายในหลังเราเตอร์เข้าถึงจากภายนอกได้ยาก หากไม่มี port forwarding แบบระบุชัดเจน
  • เนื่องจาก IPv4 ขาดแคลน ISP อาจทำ NAT ซ้ำอีกชั้นภายในเครือข่ายของตัวเอง ซึ่งเรียกว่า Carrier Grade NAT (CG-NAT)
    • เช่นเดียวกับที่เราเตอร์บ้านทำ NAT ให้หลายอุปกรณ์ภายใน เราเตอร์ของ ISP ก็ทำ NAT ให้เราเตอร์บ้านหลายตัว
    • ขึ้นกับจำนวน IPv4 ที่ ISP มีและนโยบายจัดสรร อาจซ้อนกันหลายชั้นในระดับภูมิภาคหรือรูปแบบอื่น
  • ความขัดข้องครั้งนี้ดูเหมือนเกิดจากแพ็กเก็ต IPv4 ถูก NAT ไม่ถูกต้องและถูกทิ้งอยู่ที่ชั้นใดชั้นหนึ่งของ CG-NAT จนทราฟฟิก IPv4 ขาดหายทั้งหมด
  • วิธีอ้อมสำหรับ NAT traversal ดูเพิ่มได้จาก How NAT Traversal Works ของ Tailscale

ทำไม IPv6 ยังทำงานต่อได้

  • ที่อยู่ IPv6 มีขนาด 128 บิต และแม้คำนึงถึงบล็อกที่สงวนไว้ก็ยังมีที่อยู่ประมาณ 3.4E38
  • เป็นเรื่องปกติที่เราเตอร์ตามบ้านจะได้รับ subnet แบบ /64 ซึ่งหมายถึงที่อยู่จำนวน 1.84E19
  • ใน IPv6 ไม่จำเป็นต้องใช้ NAT บนเราเตอร์บ้าน แต่อุปกรณ์แต่ละตัวสามารถมีที่อยู่ที่เข้าถึงได้ตรงจากอินเทอร์เน็ต
    • ปัญหาเรื่อง port forwarding จึงลดลง
    • แต่เราเตอร์หรืออุปกรณ์แต่ละตัวจำเป็นต้องมี firewall rule ที่เหมาะสม เพื่อกันการเชื่อมต่อใหม่จากภายนอกโดยไม่ตั้งใจ
  • เนื่องจาก IPv6 ไม่ได้อยู่ภายใต้ CG-NAT จึงไม่ได้รับผลกระทบจากปัญหาครั้งนี้
  • ยังมีเว็บเซิร์ฟเวอร์อย่าง GitHub ที่เข้าไม่ได้ผ่าน IPv6 ทำให้การมีแต่การเชื่อมต่อ IPv6 อย่างเดียวไม่พอสำหรับใช้อินเทอร์เน็ตทั้งหมดโดยตรง

สร้างอุโมงค์ IPv4 บน IPv6 ด้วย WireGuard

  • วิธีแก้คือ ติดตั้ง WireGuard บน VPS แล้วให้ไคลเอนต์สร้างอุโมงค์โดยใช้ที่อยู่ IPv6 ของ VPS เป็น endpoint
  • เมื่ออุโมงค์ตั้งสำเร็จ ทราฟฟิก IPv4 จะวิ่งผ่าน VPS และกลับมาใช้งานได้ตามปกติ
    • latency จะเพิ่มขึ้นเพราะต้องวิ่งผ่าน VPS
    • รูปแบบการทำงานคล้าย Dual-Stack Lite ที่ตั้งเอง
  • เซิร์ฟเวอร์เป็น Hetzner VPS เดิมที่ติดตั้ง Arch Linux ไว้ด้วย vps2arch และใช้งานบนพื้นฐานของ Debian image รุ่นล่าสุดของ Hetzner
  • การตั้งค่า WireGuard อ้างอิงจาก ตัวอย่าง VPN server แบบเฉพาะใน ArchWiki โดยเพิ่มการรองรับทราฟฟิก IPv6 เข้าไป
  • การตั้งค่าเซิร์ฟเวอร์มีองค์ประกอบดังนี้
    • Address = 10.200.200.1/24, fd42:42:42::1/64, 2001:db8:abcd:1234::1/128
    • ส่งต่อ IPv4 ด้วย MASQUERADE ของ iptables
    • ทำ NAT ให้ IPv6 ULA ด้วย SNAT --to-source ของ ip6tables
    • เปิดใช้งาน IPv4/IPv6 forwarding
    • peer แยกเป็นตัวอย่าง foo ที่ใช้ IPv6 Global Unicast Address โดยตรง และ bar ที่ใช้ IPv6 ULA ที่ถูก NAT
  • wg-quick ต่างจากไฟล์ตั้งค่าแบบ .ini ตรงที่สามารถกำหนด PostUp และ PostDown ได้หลายครั้ง และจะรันคำสั่งตามลำดับ
    • ดู implementation ที่เกี่ยวข้องได้ใน wg-quick linux.bash

IPv6 NAT, SNAT และการตั้งค่าไคลเอนต์

  • IPv6 ไม่จำเป็นต้องทำ NAT เสมอไป และถ้า VPS มีบล็อก IPv6 แบบ /64 อย่าง Hetzner ก็สามารถแจก Global Unicast Address (GUA) ให้ peer โดยตรงได้
  • หากใช้วิธีแจกที่อยู่ตรง ต้องเปลี่ยน Unique Local Address (ULA) ของ peer และ interface ให้เป็น public IPv6 address และลบกฎ ip6tables MASQUERADE ออก
    • peer แต่ละตัวจะถูกอ้างถึงจากอินเทอร์เน็ตได้โดยตรงด้วย IPv6 ที่ได้รับ
    • เหมาะกับกรณีที่ต้องการ forward บริการของตัวเองจากหลายอุปกรณ์
    • ไฟร์วอลล์ของ VPS ต้องจัดการทราฟฟิกขาเข้าให้ถูกต้อง
  • ถ้ามั่นใจว่า IP ของ VPS เป็นแบบคงที่และไม่เปลี่ยน สามารถใช้ SNAT แทน MASQUERADE ได้
    • MASQUERADE จะตรวจ IP ของ interface ตอน runtime
    • SNAT ระบุที่อยู่ไปตรง ๆ จึงมีประสิทธิภาพดีกว่าเล็กน้อย
  • ในการตั้งค่าไคลเอนต์ ต้องครอบที่อยู่ IPv6 ของเซิร์ฟเวอร์ด้วยวงเล็บเหลี่ยม เช่น Endpoint = [2001:db8:abcd:1234::1]:51820
  • ใช้ AllowedIPs = 0.0.0.0/0, ::/0 เพื่อส่งทราฟฟิก IPv4/IPv6 ทั้งหมดผ่านอุโมงค์
  • หลังรันทั้งสองฝั่งแล้ว การท่องเว็บทั่วไปกลับมาเป็นปกติ และยัง SSH เข้าเซิร์ฟเวอร์ได้โดยตรงผ่าน IPv4 และ IPv6 ภายในอุโมงค์
  • บน Linux ยังติดตั้ง WireGuard client บนเครื่องของภรรยาได้ง่ายด้วย

แยก VPN สำหรับงานด้วย network namespace

  • เมื่อลองต่อ VPN สำหรับงานทับบนการเชื่อมต่อ WireGuard โดยตรง พบว่าเกิดการชนกันจนใช้งานไม่ได้
  • จึงใช้ vopono เพื่อรัน VPN สำหรับงานและแอปที่ต้องใช้ภายใน network namespace
  • หัวใจสำคัญคือทำให้กฎ MASQUERADE ส่งทราฟฟิกไปยัง WireGuard interface ที่กำลังใช้งานจริง (foo หรือ bar) ไม่ใช่ไปยัง network interface จริงของเครื่อง
  • ทราฟฟิกภายใน namespace ไม่ได้รับรู้กฎ nftables ของ WireGuard บนโฮสต์โดยตรง แต่ในทางปฏิบัติก็ยังถูก route ผ่านอุโมงค์ WireGuard
  • wg-quick จะ เลือกใช้ nftables ก่อน iptables หากใช้งานได้ และยังช่วยเลี่ยงการชนกับกฎ iptables มาตรฐานของ Docker
  • ตัวอย่างการรัน vopono มีดังนี้
$ vopono -v exec --create-netns-only --provider None --protocol None -i bar bash
$ sudo ip netns exec vo_none_none bash
$ (inside netns) ./vpn.sh
  • /etc/netns/vo_none_none/ จะถูก mount เป็น /etc โดย ip netns exec ทำให้สามารถมี resolv.conf เฉพาะ namespace ได้
  • ถ้าต้องการให้การ resolve DNS แบบ IPv4 มาก่อน ก็สามารถปรับ gai.conf ในลักษณะเดียวกันได้
    • ผู้เขียนใช้ระหว่างดีบักปัญหาทราฟฟิก IPv6 ในอุโมงค์
    • ตัวอย่างอ้างอิงจาก คำตอบบน AskUbuntu
  • หลังเชื่อมต่อ VPN สำหรับงานแล้ว หากใส่ internal DNS server ลงใน /etc/netns/vo_none_none/resolv.conf แอปที่รันใน namespace นั้นก็จะทำงานได้ตามปกติ
  • สามารถรันแอปอย่าง Chrome ภายใน namespace ได้ด้วยสิทธิ์ผู้ใช้ทั่วไป
$ vopono -v exec -i bar --provider None --protocol None google-chrome-stable

รัน Docker ใน namespace เดียวกัน

  • Docker ไม่สามารถทำงานได้เพียงแค่รันใน network namespace เหมือนแอปทั่วไป
    • เพราะ Docker socket ที่ถูกเปิดใช้งานผ่าน systemd ถูกสร้างไว้นอก namespace
    • ทำให้การเชื่อมต่อภายในไม่ครบถ้วน
  • แม้จะหยุด Docker ภายนอกแล้วพยายามสร้าง dockerd และ socket ใหม่ภายใน namespace ก็ยังไม่จบง่าย ๆ
    • ip netns exec จะสร้าง mount namespace และ remount /sys
    • ทำให้มองไม่เห็น /sys/fs/cgroup ของโฮสต์
  • ในกรณีนี้อาจเจอ error ต่อไปนี้
Error: OCI runtime error: runc: runc create failed: no cgroup mount found in mountinfo
  • วิธีอ้อมคือใช้ unshare ทำ bind mount ให้ /sys แล้ว unmount /sys ภายในที่ ip netns exec สร้างขึ้น
    • วิธีนี้อ้างอิงจาก โพสต์บน Unix StackExchange
    • จากนั้น /sys ภายใน mount namespace จะกลายเป็น bind mount ของ /sys บนโฮสต์
  • คำสั่งตัวอย่างมีดังนี้
$ sudo systemctl stop docker && sudo systemctl stop docker.socket
$ sudo -E unshare -m sh -c 'mount --bind /sys /sys; exec ip netns exec vo_none_none sudo --user youruser --preserve-env bash'
$ sudo umount /sys
$ sudo dockerd --host=unix:///var/run/docker-netns.sock --data-root=/var/lib/docker-netns
$ DOCKER_OPTS="--dns=YOURDNSHERE" DOCKER_HOST=unix:///var/run/docker-netns.sock sudo --user youruser --preserve-env docker ...
  • เมื่อรัน dockerd และคำสั่ง Docker อยู่ใน session เดียวกัน ทั้งคู่จะใช้ network namespace และ mount namespace เดียวกัน
  • การตั้งค่า DNS ของ Docker สามารถใส่ใน /etc/netns/vo_none_none/docker/daemon.json ได้เช่นกัน
  • วิธีนี้เพียงพอสำหรับงานที่ต้องใช้ container เสริมและ container ที่เชื่อมผ่าน Docker network แต่กับโครงสร้าง Docker ที่ซับซ้อนกว่านี้ เช่น แบบที่ต้องใช้ bridge อาจไม่ได้ทำงานตรง ๆ

ดีบักปัญหา WireGuard MTU

  • หลังรีบูต แม้การเชื่อมต่อ WireGuard จะดูเหมือนยังอยู่ แต่บางหน้าเว็บโหลดได้เท่านั้น และเว็บไซต์อย่าง GitHub เปิดไม่ขึ้น
  • ping, ping -6, wg show ดูปกติทั้งหมด ทำให้หาสาเหตุได้ยาก
  • เมื่อลองด้วย ping หลายขนาด จึงพบว่าแพ็กเก็ตใหญ่ล้มเหลว
$ ping6 -s 1400 fd42:42:42::1
$ ping6 -s 1200 fd42:42:42::1
$ ping6 -s 800 fd42:42:42::1
  • ขนาด 1400 ล้มเหลว แต่ 1200 และ 800 สำเร็จ จึงยืนยันได้ว่าต้นเหตุคือ การตั้งค่า MTU
  • เมื่อปรับ MTU ของ WireGuard interface ฝั่งโลคัลให้เล็กลง kernel IP stack จะไม่สร้างแพ็กเก็ตที่ใหญ่กว่านี้
    • ส่งผลให้แพ็กเก็ต UDP สุดท้ายที่รวม overhead จากการ encapsulation ของ WireGuard แล้ว ไม่ถูกทิ้งบนลิงก์ที่มี MTU เล็กตามเส้นทาง
  • เราเตอร์แต่ละตัวตามเส้นทางมี MTU ของตัวเอง และแพ็กเก็ตที่ใหญ่กว่าค่าต่ำสุดอาจถูกทิ้งได้
  • ทราฟฟิกในอุโมงค์มี overhead เพิ่มขึ้นประมาณ 32 ไบต์ จากการ encapsulation ของ WireGuard จึงยิ่งทำให้ปัญหา MTU เด่นชัดขึ้น
  • ข้อความ Path MTU Discovery อาจถูกส่งกลับมาด้วย ICMP จากเราเตอร์กลางทาง แต่ไฟร์วอลล์มักทิ้ง ICMP ทำให้ปรับอัตโนมัติไม่ได้เสมอไป
  • ข้อกำหนดของ IPv6 ระบุค่า MTU ขั้นต่ำไว้ที่ 1280 ดังนั้นสำหรับอุโมงค์ WireGuard บน IPv6 ค่านี้ควรใช้ได้เสมอ

ทางเลือกด้านปฏิบัติการที่ยังเหลือหลังระบบกลับมา

  • ผลลัพธ์ของการตั้งค่าประกอบด้วย
    • ตั้งค่า WireGuard VPN server บน VPS ที่มีทั้ง IPv4 และ IPv6
    • รองรับทั้งทราฟฟิก IPv6 แบบตรงและ IPv6 แบบ NAT
    • รัน VPN สำหรับงานใน network namespace
    • รัน Docker ใน network namespace เดียวกันด้วยวิธีอ้อมผ่าน unshare
    • ดีบักปัญหา WireGuard MTU
  • ในการทำงานระยะไกล ปัญหาการเชื่อมต่ออินเทอร์เน็ตเป็นความเสี่ยงเสมอ และกรณีนี้สามารถใช้อุปกรณ์ของ Linux เพื่ออ้อมปัญหาได้โดยไม่ต้องรอให้ ISP แก้ค่าระบบ
  • Hetzner VPS รองรับอุโมงค์ WireGuard และการใช้งานทั่วไปที่ถูกต้องตามกฎหมาย แต่ไม่อนุญาตการสแกนพอร์ต การปลอมแปลงทราฟฟิก หรือการขุดคริปโต
  • VPN อย่าง AirVPN, ProtonVPN และ AzireVPN ที่รองรับ port forwarding ก็อาจเป็นทางเลือกสำหรับ forward พอร์ตโฮมเซิร์ฟเวอร์โดยไม่ต้องพึ่ง ISP
  • หากใช้เราเตอร์ OpenWRT ก็จะดีบักฝั่งเราเตอร์ได้มากขึ้น และสามารถตั้งค่า WireGuard แบบอ้อมนี้บนเราเตอร์ได้โดยตรง แทนที่จะไปตั้งแยกบนแต่ละอุปกรณ์

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

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

 
GN⁺ 2025-06-30
ความคิดเห็นจาก Hacker News

  • ชื่อเรื่องชวนให้เข้าใจผิดเล็กน้อย พูดให้ตรงคือเป็นการ เข้าถึงอินเทอร์เน็ต IPv4 ผ่าน IPv6 tunnel โดยใช้ VPS และมักเรียกว่า 4in6
    ถึงอย่างนั้นก็น่าสนใจอยู่ดี จากมุมมองของ ISP ลักษณะของปัญหาซัพพอร์ตเมื่อ IPv4 พังกับเมื่อ IPv6 พังนั้นต่างกันพอสมควร ปัญหา IPv4 ส่วนใหญ่เป็นสถานะ “ล่ม” ที่ชัดเจน ผู้ใช้จึงไม่พอใจมากแต่เรื่องตรงไปตรงมา ส่วนปัญหา IPv6 มักแสดงออกมาในรูปแบบแปลก ๆ เช่น ล่มบางส่วน เริ่มต้นช้าเพราะ fallback หรือสถานการณ์ที่ gateway เชื่อว่ามี IPv6 อยู่

    • ครั้งก่อนที่ IPv4 ตาย ผมรู้ตัวหลัก ๆ เพราะ Github ใช้ไม่ได้ ทุกวันนี้เว็บไซต์สำหรับผู้บริโภคส่วนใหญ่ ทำงานได้แม้มีแค่ IPv6
      อย่างไรก็ตาม คนที่ตั้งค่า DNS server เป็น IPv4 ไว้เท่านั้นบนเราเตอร์เจอปัญหาล่มสนิท ถ้า Microsoft กำจัดทรัพย์สินที่ไร้ความสามารถออกไปบ้าง ความกังวลใหญ่ที่สุดคงเหลือแค่จำชื่อโฮสต์ mDNS ที่ตั้งไว้กับเราเตอร์เพื่อเข้าไปล็อกอินและตรวจดูว่า IPv4 กลับมาหรือยัง
    • long tail ของ IPv4 มีอยู่แน่นอน แต่ครั้งล่าสุดที่ IPv4 ที่บ้านหลุด ภรรยาผมไม่รู้ตัวเลย เพราะ Google, Facebook, Apple/iCloud และโฮสติ้งส่วนใหญ่ของ CloudFlare ยังทำงานต่อผ่าน IPv6 ได้
    • ตรงกับประสบการณ์ของผมเหมือนกัน ปัญหา IPv6 นั้นจัดหมวดหมู่และทำซ้ำให้เกิดใหม่ได้ยากจนน่าหงุดหงิด และมักมีสถานการณ์แบบ “เครื่องผมใช้ได้นะ” อยู่บ่อย ๆ
    • ISP ส่วนใหญ่ยังคงปิดกั้น IPv6 ไปเลย ผู้ให้บริการรายเล็กมักลองใช้ IPv6 ครั้งหนึ่งแล้วลืมเรื่องอย่าง การอัปเดตระเบียน AAAA ทำให้ผู้ใช้เห็นเหมือนว่าบริการเฉพาะกลุ่มที่ตัวเองชอบใช้ได้บนเครือข่ายอื่น แต่ใช้ไม่ได้กับ ISP ที่ตัวเองจ่ายเงินให้
      เป็นปัญหาประหลาด และผมไม่แน่ใจว่ามีทางแก้ที่ดีหรือไม่ นอกจากหวังว่าสักวัน IPv4 จะหายไป Happy Eyeballs ควรจะมาแก้ปัญหานี้ แต่ปัญหามักโผล่ขึ้นมาเหนือชั้นแอปพลิเคชันไปไกล และแอปพลิเคชันจะทำอะไรก็ได้ จึงแก้ด้วยโปรโตคอลทั่วไปได้ยากโดยไม่เกิด abstraction ที่รั่ว โดยส่วนตัวผมประนีประนอมด้วยการเปิด IPv6 บนเครือข่าย แต่ปิด IPv6 DNS ในเบราว์เซอร์ทั้งหมด ซึ่งก็ค่อนข้างไม่น่าพอใจ

  • ถ้าอยากลองใช้ IPv6 แต่ ISP ไม่ให้บริการ Hurricane Electric มีบริการ tunnel มาหลายปีแล้ว
    https://tunnelbroker.net
    https://ipv6.he.net
    นอกจากนี้ยังมีสคริปต์สำหรับสร้างอุปกรณ์ tun บนระบบหรือเราเตอร์แล้ว route traffic: https://fedoraproject.org/wiki/IPv6_tunnel_via_Hurricane_Ele..., https://brandonrozek.com/blog/obtaining-ipv6-address-hurrica..., https://wiki.dd-wrt.com/wiki/index.php/IPv6_setup_Hurricane_..., https://forum.mikrotik.com/t/auto-update-script-for-hurrican..., https://docs.rockylinux.org/guides/network/hurricane_electri...

    • ข้อควรระวังที่น่ารำคาญของ tunnel แบบนี้คือบริการสตรีมมิงจะบล็อกเหมือนเป็น VPN สำหรับเลี่ยงข้อจำกัดตามภูมิภาค ดังนั้นหากจำเป็นก็ต้องหาวิธีปิด tunnel ให้ได้
      แต่โดยรวมทำงานได้ดี แม้เราเตอร์จะไม่รองรับ HE tunnel คุณก็ยังใส่ที่อยู่ IPv6 ให้กับทุกอุปกรณ์ในเครือข่ายได้ด้วยพลังของ RA อุปกรณ์ใดก็ได้ที่ประกาศ /64 ก็จะกลายเป็นเราเตอร์ IPv6 แน่นอนว่าต้องอยู่ภายใต้สมมติฐานว่าเราเตอร์ไม่ได้กรอง RA ด้วยเหตุผลด้านความปลอดภัย วิธีนี้มีประโยชน์มากเมื่อต้องการโฮสต์บริการในเครือข่ายบ้านโดยไม่ต้องแตะกฎ port forwarding
    • Hurricane Electric นั้นยอดเยี่ยม แต่เมื่อคนที่ใช้ IPv6 ที่ ISP ให้บริการมีจำนวนมากขึ้น ผู้ใช้ “ทั่วไป” ก็ออกจาก tunnel และบริการเครือข่ายต่าง ๆ เริ่ม ทำเครื่องหมาย he.net tunnel ว่าเป็นการใช้งานในทางที่ผิด
      มีเว็บไซต์มากเกินไปที่ตั้งกำแพงหรือถึงขั้นปฏิเสธไม่ให้ทำงาน จนผมต้องหยุดใช้ IPv6 บนเครือข่ายส่วนใหญ่ของผม
    • สิ่งที่ควรรู้คือ HE tunnel เท่าที่ผมทราบจะทำงานก็ต่อเมื่อ ISP จัดสรร IPv4 สาธารณะ ให้เท่านั้น ถ้าคุณอยู่หลัง NAT ระดับผู้ให้บริการ ก็น่าเสียดายที่ต้องหาทางแก้อื่นเพื่อนำ IPv6 เข้าบ้าน
    • เป็น “ลูกค้า” ที่พอใจ ผมใช้ 6in4 tunnel ฟรีกับ OpenBSD มาประมาณ 5 ปีแล้ว และไม่มีปัญหาอะไรที่ควรพูดถึง
      ตั้งค่าด้วยไฟล์อินเทอร์เฟซเครือข่ายของ OpenBSD อย่าง /etc/hostname.gif0 เท่านั้น: tunnel, inet6 128 alias, !route -n add -inet6 default ผมใช้การเชื่อมต่อนี้เพื่อเข้าถึงคลัสเตอร์ VPS บน AWS ที่ตั้งใจจัดไว้โดยไม่มีที่อยู่ IPv4 สาธารณะ ไม่เช่นนั้นมันคงกลายเป็นส่วนใหญ่ของค่าใช้จ่ายรายเดือน เพราะคนอย่าง Jeff Bezos กำลังทำเงินจากพื้นที่ที่อยู่ IPv4 อย่างจริงจัง

  • หากอยู่ในสภาพแวดล้อมแบบ IPv6 ล้วนจริง ๆ แล้วต้องการการเชื่อมต่อ IPv4 อย่างรวดเร็ว สามารถใช้ เกตเวย์ DNS64+NAT64 สาธารณะได้ รายชื่ออยู่ที่ https://nat64.net/public-providers
    ในการใช้งานทั่วไป แค่เปลี่ยน DNS server ก็พอ DNS64 จะสังเคราะห์ AAAA DNS record ที่ชี้ไปยังกล่อง NAT64 สำหรับปลายทางที่ไม่มี AAAA record: $ dig +short @2a00:1098:2c::1 AAAA github.com → 2a01:4f8:c2c:123f:64:5:141a:9cd7 NAT64 จะทำ protocol translation และ NAT ให้กับทราฟฟิกที่มาหาตัวเองเพราะ DNS64: $ curl --resolve github.com:443:[2a01:4f8:c2c:123f:64:5:141a:9cd7] [https://github.com/](<https://github.com/>;)

    • ตั้งใจจะมาบอกเรื่องนี้เลย อย่างน้อยในยุโรป https://nat64.net/ เองก็ค่อนข้างดี มีแต่ประสบการณ์ที่ดี
    • ถ้าใช้ Cloudflare WARP น่าจะเร็วกว่าเยอะ สามารถเชื่อมต่อไปยังที่อยู่ IPv4 ได้โดยตรงผ่าน WARP

  • ผู้ใช้ อินเทอร์เน็ตแบบ IPv6 ล้วน ในตำนานมีอยู่จริงสินะ :) เป็นงานวิศวกรรมเครือข่ายที่ยอดเยี่ยม
    เมื่อก่อนเคยต้องการสิ่งคล้ายกันเพื่อเป้าหมายตรงข้ามที่พบได้บ่อยกว่า คือทำงานเกี่ยวกับ IPv6 จากการเชื่อมต่อแบบ IPv4 ล้วน ถ้าควบคุมเซิร์ฟเวอร์ได้ทั้งหมด วิธีแก้ที่จำกัดกว่าแต่รวดเร็วคือใช้ ssh -D 1080 -N myserver เพื่อสร้าง SOCKS5 proxy แล้วตั้งค่าในเบราว์เซอร์ คิดว่าน่าจะตั้งค่าให้ใช้ทั้งระบบได้ด้วย แต่สงสัยว่าถ้าทำแบบนั้นแล้วการเชื่อมต่อ ssh เดิมพัง ทุกอย่างจะล่มตามไปด้วยหรือเปล่า

  • ผมก็อยู่ในสถานการณ์เดียวกัน ได้ยินแต่คำว่า “เปิด ticket แล้ว และช่างเทคนิคจะมาตรวจสอบเร็ว ๆ นี้” มา 2 สัปดาห์แล้ว ค่อนข้างน่าหงุดหงิด
    ไม่รู้ว่าเพราะ IPv6 ยังทำงานอยู่ เลยไม่ถือว่าเป็นเหตุขัดข้องทั้งหมด จึงถูกจัดลำดับความสำคัญต่ำหรือเปล่า ในเยอรมนีมีกฎหมายรับประกันค่าชดเชยผู้บริโภคในกรณีแบบนี้ และเร็ว ๆ นี้จะลองตรวจดูว่ากรณีนี้เข้าข่ายหรือไม่ วิธีแก้ในบล็อกโพสต์นี้มีปัญหาว่า endpoint หลายแห่งบล็อกช่วง IP ของดาต้าเซ็นเตอร์ทั้งช่วง หรือบังคับให้ผ่าน CAPTCHA หลายครั้ง และผู้ให้บริการ VPN ทั่วไปก็เป็นแบบเดียวกัน ผมอยากแก้ทั้งเครือข่ายในบ้าน จึงต้องจัดการที่เราเตอร์ และบังเอิญมีอุปกรณ์ที่ไม่ค่อยเป็นมาตรฐานอย่าง Ubiquiti EdgeRouter ซึ่งช่วยให้ตั้งค่า Wireguard routing และกฎ NAT ได้ง่าย ไม่รู้ว่าถ้าเป็นอุปกรณ์อย่าง FritzBox จะทำอย่างไร ข้อเสียคือประสิทธิภาพของเราเตอร์ไม่พอรับการเชื่อมต่อจำนวนมาก จึงต้องเปลี่ยนไปใช้ IPSec ที่รองรับ hardware offloading

    • จริง ๆ แล้ว FritzBox ก็มี GUI สำหรับตั้งค่าการเชื่อมต่อ VPN ที่ค่อนข้างดี แม้ฟีเจอร์นี้ตั้งใจไว้สำหรับการเชื่อมต่อระหว่าง FritzBox ด้วยกัน แต่ถ้าเป็น VPN ที่เข้ากันได้ก็ใช้ได้ และยังตั้งค่า static IPv4/IPv6 route ได้ด้วย
      ปัญหาใหญ่ที่สุดน่าจะเป็นการหาว่าฝั่งตรงข้ามคาดหวังการตั้งค่าการเข้ารหัส IPsec แบบไหน Wireguard อาจง่ายกว่ามาก แต่ตอนนั้นอาจเจอปัญหาเรื่อง hardware acceleration ถ้าจำเป็น ก็สามารถสำรองไฟล์ตั้งค่าของ FritzBox แล้วแก้ไข dump เพื่อตั้งค่า VPN endpoint ด้วยมือ จากนั้นคำนวณ checksum ใหม่แล้วนำกลับเข้าไปได้ AVM มีการตั้งค่าจำนวนมากที่ผู้ใช้เข้าถึงไม่ได้และสามารถปรับแบบนี้ได้ แต่ทำให้เข้าถึงยากไว้หน่อยเพื่อไม่ให้เผลอทำเราเตอร์กลายเป็นอิฐ
    • ไม่รู้สถานการณ์ในเยอรมนี แต่ในเนเธอร์แลนด์ ถ้าใช้ทั้งเน็ตบ้านและมือถือกับ ISP เดียวกัน แล้วการเชื่อมต่อเน็ตบ้านมีปัญหา สามารถขอ ดาต้ามือถือฟรี ได้จนกว่าปัญหาจะถูกแก้
      อาจเป็นตัวเลือกที่ควรถาม ISP ดู

  • สิ่งหนึ่งในกฎ App Store ของ Apple ที่ผมชอบคือข้อกำหนดว่าแอปทุกตัวต้อง ทำงานบนเครือข่ายแบบ IPv6 ล้วน ได้ เป็นกฎที่มีมาหลายปีแล้ว
    ในฐานะนักพัฒนา ตอนเจอครั้งแรกอาจตกใจนิดหน่อย แต่ในฐานะผู้ใช้ ดีใจที่มีกฎนี้

    • ถ้าใช้แอป แล้ว Github เข้าผ่าน IPv6 ได้ไหม?
    • แต่ไม่ได้แปลว่าเซิร์ฟเวอร์ต้องมีที่อยู่ IPv6

  • ถ้าเจอเรื่องเดียวกัน สามารถสร้าง ssh proxy ได้ง่ายมากด้วย ssh -D 8080 user@hostname
    เมื่อสร้างการเชื่อมต่อแล้ว ก็แค่กำหนดในเบราว์เซอร์ให้ใช้ localhost:8080 เป็น SOCKS proxy

    • กำลังจะให้คำแนะนำเดียวกันเลย สำหรับปัญหาชั่วคราวนี่เป็นวิธีแก้ที่ง่ายกว่ามาก และยังใช้เป็นเครื่องมือถาวรได้เมื่อต้องใช้ proxy
      หากจะใช้ฟีเจอร์นี้ ต้องเปิดใช้ AllowTcpForwarding ใน sshd_config
    • เวลาใช้ Wi-Fi สาธารณะ ผมทำแบบนี้เสมอ ไม่ต้องจ่ายเงินค่า VPN หรือเชื่อใจ VPN โดย forward ทุกอย่างแบบ SOCKS ไปยัง เซิร์ฟเวอร์ infomaniak ของผม

  • มีจุดที่ติดขัดเมื่อปิด IPv4: ดูเหมือนว่าเสิร์ชเอนจินทางเลือกส่วนใหญ่จะไม่มีการเชื่อมต่อ IPv6 และเท่าที่ตรวจครั้งล่าสุด Github ไม่มี IPv6 เลย
    เป็น Microsoft ก็ไม่ควรคาดหวังสิ่งดี ๆ และควรคาดหวังสิ่งที่แย่ที่สุดด้วยซ้ำ ช่วงหลังยังทำให้ noscript/basic (x)html ใน issues พังด้วย ไม่รู้ว่าตอนนี้ยังสร้างบัญชีด้วยเบราว์เซอร์ noscript/basic (x)html, อีเมลที่โฮสต์เอง และ IP(v6) literal อย่าง mailbox@[ipv6:...] ได้อยู่ไหม Steam หรือเกมต่าง ๆ ก็ไม่ได้ตรวจมาล่าสุด แต่ CDN/เซิร์ฟเวอร์เกมจำนวนมาก หรืออย่างน้อยส่วนสำคัญ น่าจะยังเป็น IPv4 เท่านั้น เซิร์ฟเวอร์อีเมลจำนวนมากก็บล็อกเมลเซิร์ฟเวอร์ที่โฮสต์เอง และมักใช้รายการบล็อกที่ทำออกมาแบบหยาบและไม่เหมาะสมโดยบริษัทน่าสงสัยในสวิตเซอร์แลนด์·อันดอร์ราอย่าง Spamhaus อีกทั้งแอปพลิเคชันเครือข่ายจำนวนมากก็ไม่ได้ใช้ประโยชน์จากข้อดีของ IPv6 เช่น แอปแบบไคลเอนต์-เซิร์ฟเวอร์อย่างเว็บ ควรใช้ที่อยู่ IPv6 ที่สุ่มสร้างต่อแต่ละเซสชัน ถ้า ISP ไม่ได้ให้ prefix ที่เล็กเกินไป ISP IPv6 บนมือถือดูเหมือนจะให้ที่อยู่ IPv6/128 แบบสุ่มใน prefix แต่ควรให้ prefix ที่เสถียร น่าจะประมาณ 96 บิต เพื่อให้แอปบนอุปกรณ์ปลายทางเลือกที่อยู่ IPv6 “คงที่” สำหรับโทรเสียง/วิดีโอโดยตรงได้ โดยไม่ต้องพึ่งการแปลงชื่อกลางแบบออนไลน์ ยังต้องมีบริการระดับผู้ใช้แบบใหม่ของ OS สำหรับประสานที่อยู่ IPv6 ระหว่างแอปของผู้ใช้ด้วย อย่างไรก็ดี ต้องระวังความซับซ้อนโง่ ๆ ที่บางผู้ขายและนักพัฒนาจะพยายามยัดเยียดเพื่อผูกมัดผู้ใช้และนักพัฒนาแอป

    • ในมินิโฮมแล็บของผม IPv6-only เคยทำงานได้ดี แต่พอมีอะไรบางอย่างทำให้ต้องใช้ GitHub ก็พัง เลยตั้ง NAT64+NAT64 ขึ้นมา
      น่าเสียดายจริง ๆ ที่ต้องทำแบบนั้นเพราะ GitHub แค่ตัวเดียว สุดท้ายก็คงต้องใช้เพราะเมลเซิร์ฟเวอร์อยู่ดี แต่เหตุผลที่ทำให้ต้องใช้ NAT64 เร็วขนาดนี้ถือว่าแย่มาก ผมมองว่านี่เป็นหนึ่งในข้อเสียหลายอย่างของการที่คนใช้ GitHub เป็นช่องทางแจกจ่ายซอฟต์แวร์
    • ไม่กี่เดือนก่อนต้องไปงัดข้อกับ Spamhaus ด้วย ไม่รู้เพราะเหตุผลอะไร ที่อยู่ IPv6 ของ VPS ของผมถูกใส่ในรายการบล็อกของ Spamhaus
      ไม่รู้เลยว่าทำไม เครื่องนั้นไม่ได้รันอะไรที่สามารถส่งอีเมลได้ และเท่าที่รู้ Digital Ocean ก็บล็อก SMTP ด้วย ดังนั้นเครื่องนี้จึงส่งอีเมลไม่ได้จริง ๆ ในเชิงตัวอักษร Spamhaus ไม่ช่วยแก้ปัญหาเลย และ DO ก็เหมือนกัน
    • เพราะปัญหาที่ CDN/เซิร์ฟเวอร์เกมจำนวนมากยังเป็น IPv4-only อยู่ จึงทำ DNS proxy ขึ้นมา มันจะเพิ่มระเบียน AAAA ที่ถูกต้องให้โดเมนเหล่านั้น
      https://gitlab.com/miyurusankalpa/IPv6-dns-server
    • ยืนยันได้ว่า Steam ต้องใช้ IPv4 เกมบางเกมที่ต้องยืนยันตัวตนก่อนเล่นก็เช่นกัน
    • ถ้าไม่ใช่กรณีที่มีส่วนลดเมื่อรันแบบ IPv6-only เช่นบริการ VPS ดูเหมือนว่ายังไม่มีใครพิจารณาเลิกใช้ IPv4 อย่างจริงจัง
      ในความเป็นจริง มีแนวโน้มสูงว่าจะยังคงมีการเชื่อมต่อ IPv4 ในรูปแบบใดรูปแบบหนึ่งต่อไป เพียงแต่โอกาสที่การเชื่อมต่อนั้นจะผ่าน CGNAT จะเพิ่มขึ้นเรื่อย ๆ Github ทำให้น่าหงุดหงิดเป็นพิเศษ ทดสอบอยู่หลายสัปดาห์และทุกอย่างดูเหมือนทำงานได้ดี แต่สุดท้ายก็ถอยกลับไปเป็น IPv4-only อีก เซิร์ฟเวอร์อีเมลยังอยู่ในโลกเมื่อ 10–20 ปีก่อนอยู่แล้ว แม้แต่การปิดการรองรับ SSL 3.0 หรือ TLS 1.0 บนเซิร์ฟเวอร์อีเมล ก็ทำได้ยากโดยไม่ต้องยอมเสี่ยงเรื่องการส่งถึงปลายทาง การรองรับและตัวกรองสแปมของ Microsoft Outlook ดูเหมือนจะไม่รู้จักเมลเซิร์ฟเวอร์ที่ใช้ IPv6 ได้เลย ทั้งที่ดูจาก header แล้วภายในน่าจะใช้ IPv6 มานานแล้วก็ตาม อยากให้ IPv6 ถูกใช้งานมากกว่านี้ แต่ความกลัวว่าอาจทำงานแย่ลงเล็กน้อยสำหรับลูกค้าส่วนน้อย ดูเหมือนจะทำให้ทุกความพยายามในการใช้เทคโนโลยีจริง ๆ ถูกแช่แข็งไว้ เหตุผลที่เห็นพฤติกรรม IP แปลก ๆ ในผู้ให้บริการมือถือ น่าจะมาจากวิธีที่ IP ทำงานบนเครือข่ายมือถือ เมื่อกำลังโทรระหว่างขับบนทางด่วนหรือ坐อยู่บนรถไฟความเร็วสูง โทรศัพท์จะทำ handover ต่อเนื่อง และที่อยู่ IP ต้องมีเสถียรภาพในระดับหนึ่ง แม้ข้ามพรมแดนแล้วเปลี่ยนไปใช้เครือข่ายต่างประเทศ สแต็กทั้งหมดก็ต้องรักษาการเชื่อมต่อที่ต่อเนื่องไว้ ภายในเครือข่ายเซลลูลาร์มีระบบ routing พิเศษ และบางส่วนก็ใช้ความสามารถของ IPv6 ได้อย่างยอดเยี่ยม แต่ก็ทำให้การให้ที่อยู่ global unicast แบบ static “ทั่วไป” แก่โทรศัพท์เป็นเรื่องยาก ผู้ให้บริการพยายามทำให้ดูปกติที่สุด แต่การบรรลุเสถียรภาพแบบอินเทอร์เน็ตบ้านมีสายไม่ใช่เรื่องง่าย

  • ที่ทำงานกำลังรัน VPN แบบ IPv6-only หลายตัวสำหรับเข้าถึงโครงสร้างพื้นฐานภายใน
    จนถึงตอนนี้ปัญหาใหญ่ที่สุดคือไคลเอนต์ Windows และ macOS ต้องการเซิร์ฟเวอร์ DNS แบบ IPv6 ไม่อย่างนั้นมันจะไม่แม้แต่พยายาม resolve v6onlyhost.vpn.example.com ไคลเอนต์อาจอยู่บนเครือข่ายที่รองรับ IPv6 หรือไม่ก็ได้ จึงต้องรันเซิร์ฟเวอร์ DNS ไว้ใน VPN แล้ว push ให้ไคลเอนต์ แต่ถ้า VPN หลุดแล้วแอป Wireguard ด้วยเหตุผลบางอย่างไม่สามารถคืนค่า DNS กลับเหมือนเดิมได้ ก็อาจเกิดปัญหาสารพัด

    • แม้ใช้เครือข่าย IPv4-only ของ ISP แต่ macOS ก็สามารถ เชื่อมต่อแบบ IPv6-only ได้โดยไม่มีเซิร์ฟเวอร์ DNS แบบนั้น
      ตอนนี้จำรายละเอียดไม่ได้แล้ว แต่เมื่อหลายปีก่อนไปขุดดูพบว่า macOS ทำงานแบบนั้นได้ดีตราบใดที่มีที่อยู่ IPv6 แค่ใส่ที่อยู่ ULA ให้โฮสต์ก็พอ แน่นอนว่ามีเงื่อนไขว่าผู้ใช้ต้องรู้วิธีนี้ด้วย ขึ้นอยู่กับแอป VPN อาจใส่สคริปต์ให้เพิ่ม ULA ตอนเข้าเครือข่าย IPv6-only ได้ อย่างไรก็ดี หากปล่อย ULA ปลอมค้างไว้เรื่อย ๆ อาจเกิดปัญหาเมื่อผู้ใช้ย้ายไปยังเครือข่ายที่รองรับ IPv6
    • นี่ไม่ใช่ปัญหาของ Windows ผมเองก็เคยเจอปัญหาคล้ายกันในฮอตสปอตแบบสุ่มบางแห่ง แต่ไม่ใช่ทั้งหมด คิดว่าเป็นเพราะ ฮอตสปอตโง่ ๆ ที่ไม่ส่งคืนระเบียน AAAA เมื่อ IPv6 ถูกปิดอยู่

  • ผ่านมานานขนาดนี้แล้ว แต่ผมก็ยังไม่เห็นเหตุผลที่น่าเชื่อพอจะทำให้ต้องปวดหัวอยู่หลายวันเพื่อเปลี่ยนเครื่องทั้งหมดกับโฮมแล็บของผมไปเป็น IPv6
    การทำ port forwarding กับกฎ firewall ยังเข้าใจง่ายกว่าการใช้เวลาหลายสัปดาห์แก้ปัญหาทุกอย่าง จัด firewall ใหม่ และกำหนดหมายเลขที่อยู่เครือข่ายใหม่ ผมพลาดอะไรไปหรือเปล่า?

    • สิ่งที่พลาดไปคือมันไม่ได้ยากอย่างที่คิด ถ้าไม่ใช่เครือข่ายบ้านที่ซับซ้อนมาก การตั้งค่า IPv6 อย่างมากก็ใช้เวลาช่วงเย็นหนึ่งครั้ง
      สำหรับเครือข่ายของผมกับ ISP อย่าง Comcast แค่เปิด IPv6 บนเราเตอร์ ก็จะรับ prefix จาก ISP แล้วประกาศใช้ภายในเครือข่าย จากนั้นเพิ่มกฎ firewall หนึ่งข้อให้สิ่งที่ต้องการเปิดให้เข้าถึงจากภายนอกได้ ก็จบ
    • ไม่ได้พลาดอะไรเลย ในสภาพแวดล้อมองค์กร ประโยชน์ของการนำ IPv6 มาใช้ไม่ได้มากกว่าข้อเสีย
      ผมดูแลอุปกรณ์ประมาณ 3,500 เครื่อง อาคาร 7 หลัง, WAN 10 กิกะบิต 2 เส้น และ WAN 4 กิกะบิต 1 เส้น ใช้ public IPv4 address ประมาณ 26 รายการกับ NAT อยู่ ตอนนี้ก็ยังไม่มีเหตุผลที่หนักแน่นพอให้ใช้ IPv6 การทำ dual-stack มีแต่เพิ่มทราฟฟิกและความซับซ้อนที่ไม่จำเป็นโดยแทบไม่มีประโยชน์ ตอนนี้ก็ยังยากที่จะได้รับการจัดสรรบล็อก IPv6 แบบ static ผมยื่นขอไปสองครั้งแต่ถูกปฏิเสธ ไม่ใช่แค่มีโอกาสได้ประโยชน์เพิ่มน้อย แต่การจะได้บล็อกเองก็ยังยากอยู่ เงื่อนไขคุณสมบัติใน https://www.arin.net/resources/guide/ipv6/first_request/ ก็เป็นทำนองว่าต้องถือครองการจัดสรร IPv4 อยู่ มีแผนจะทำ IPv6 multihome ทันที มี end site 13 แห่งภายใน 1 ปี ใช้ที่อยู่ IPv6 2,000 รายการภายใน 1 ปี ใช้ subnet /64 200 รายการภายใน 1 ปี เป็นต้น
    • ตอนนี้ยังไม่ได้พลาดอะไรใหญ่ ๆ สักวันหนึ่งบริษัทใหญ่ ๆ อย่าง Google, Cloudflare อาจเบื่อกับต้นทุนที่อยู่ IPv4 ที่แพงขึ้นเรื่อย ๆ แล้วให้แรงจูงใจกับ IPv6 เช่น อาจเริ่มจำกัด IPv4
      ตอนนี้ก็มีสัญญาณเริ่มต้นแล้ว เมื่อก่อน AWS คิดค่าบริการเฉพาะ IPv4 Elastic IP address ที่ไม่ได้ใช้งาน แต่ตอนนี้คิดค่าบริการไม่ว่าจะใช้งานหรือไม่ก็ตาม พูดตามตรง แค่เตรียมไว้ตอนอัปเกรดเกตเวย์หรือเราเตอร์ครั้งหน้าก็น่าจะพอ ตอนนี้ยังไม่ได้พลาดอะไรไป IPv4 กับ IPv6 ก็ใช้พร้อมกันได้ ต่อให้เปิดในเราเตอร์ อุปกรณ์ที่รองรับเฉพาะ IPv4 ก็ยังทำงานได้ตามปกติ สิ่งหนึ่งที่ควรระวังคือระบบค้นหาอัตโนมัติของ IPv6 เคยค่อนข้างเละเทะอยู่ช่วงหนึ่ง มีทั้ง SLAAC, การกำหนดที่อยู่ IPv6 อัตโนมัติ และ DHCPv6 และเดิมทีการกำหนดที่อยู่อัตโนมัติไม่รองรับแม้แต่การรับ DNS server ตอนนี้กำลังค่อย ๆ รวมไปทาง SLAAC แต่ ISP คงยังใช้ DHCPv6 ไปอีกนานมาก