IPv4 कनेक्शन के बिना इंटरनेट इस्तेमाल करना

 (jamesmcm.github.io)
3 पॉइंट द्वारा GN⁺ 2025-06-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • बिजली कटने के बाद ISP की तरफ सिर्फ IPv4 कनेक्शन बंद हो गया था जबकि IPv6 चालू था; IPv4-only साइटों तक पहुंच बहाल करने के लिए IPv4/IPv6 दोनों वाले Hetzner VPS और WireGuard tunnel का उपयोग किया गया
  • समस्या CG-NAT layer में IPv4 packets के सही से translate न होकर drop होने जैसी दिखी, और Google·Meta जैसी IPv6 support करने वाली services पर access जारी रहा
  • VPS पर WireGuard server रखकर, अगर client VPS के IPv6 address को endpoint के रूप में इस्तेमाल करे, तो IPv4 traffic को VPS के जरिए भेजकर सामान्य web browsing बहाल की जा सकती है
  • work VPN और Docker के लिए अलग handling की जरूरत थी, इसलिए उन्हें vopono-based network namespace और unshare·/sys bind mount workaround जैसे namespace के अंदर चलाया गया
  • कुछ sites के load न होने का कारण WireGuard MTU का बहुत बड़ा होना था; इसे IPv6 minimum MTU 1280 तक घटाते ही समस्या तुरंत हल हो गई

बिजली कटने के बाद सिर्फ IPv4 बंद होने वाली समस्या

  • बिजली कटने के बाद breaker restore किया गया, लेकिन GitHub और कई websites तक access नहीं हो पा रहा था, जबकि Google और Meta सामान्य रूप से काम कर रहे थे
  • local machine और router diagnostics page पर ping -6, traceroute जांचने पर पता चला कि समस्या सिर्फ IPv4 server access में थी
  • ISP ने कहा कि technician visit की जरूरत हो सकती है और weekend के बाद इसमें कुछ दिन लग सकते हैं; work access और paper work के कारण outage का इंतजार करना मुश्किल था
  • मौजूदा Hetzner VPS के पास static IPv4 और IPv6 addresses थे, और Hetzner website IPv6 support करती थी, इसलिए console तक पहुंचकर configuration किया जा सका

NAT और CG-NAT से बनी IPv4 dependency

  • IPv4 addresses 32-bit होते हैं, और reserved blocks हटाने के बाद public IPv4 addresses सिर्फ करीब 3.7 billion हैं, इसलिए हर internet-connected device को direct address देना संभव नहीं है
  • NAT कई devices को एक public IP share करने देता है
    • home router internal devices के 192.168.1.xxx जैसे local IP को अपने public IPv4 में बदलता है
    • Linux का conntrack original source IP और port, और translated port को mapping के रूप में store करता है
    • जब response packet उस port पर आता है, तो conntrack destination को original internal IP और port पर वापस बदल देता है
    • Linux में conntrack-tools के conntrack -L से stored mappings देखे जा सकते हैं
  • NAT implicit firewall की तरह काम करता है, जिससे router के पीछे local devices की services तक explicit port forwarding के बिना बाहर से access करना मुश्किल होता है
  • IPv4 shortage के कारण ISP अपने internal network में भी एक और NAT layer लागू कर सकता है; इसे Carrier Grade NAT(CG-NAT) कहते हैं
    • जैसे home router कई local devices को NAT करता है, वैसे ही ISP router कई home routers को NAT करता है
    • ISP के पास मौजूद IPv4 addresses की संख्या और allocation policy के आधार पर यह regional level आदि में कई layers में repeat हो सकता है
  • इस outage में ऐसा लगा कि CG-NAT layer में कहीं IPv4 packets सही तरीके से NAT न होकर drop हो रहे थे, जिससे IPv4 traffic पूरी तरह बंद हो गया था
  • NAT traversal workaround के लिए Tailscale का How NAT Traversal Works reference के तौर पर उपयोगी है

IPv6 क्यों चलता रहा

  • IPv6 addresses 128-bit होते हैं, और reserved blocks को ध्यान में रखने पर भी करीब 3.4E38 addresses देते हैं
  • home routers को अक्सर /64 subnet मिलता है, जिसका मतलब 1.84E19 addresses है
  • IPv6 में home router पर NAT इस्तेमाल किए बिना भी हर device के पास internet पर direct address हो सकता है
    • port forwarding की समस्या कम हो जाती है
    • इसके बजाय router या हर device को random external new connections रोकने के लिए सही firewall rules चाहिए
  • IPv6 पर CG-NAT लागू नहीं था, इसलिए इस outage का उस पर असर नहीं पड़ा
  • GitHub जैसे web servers अब भी हैं जिन्हें IPv6 से access नहीं किया जा सकता, इसलिए सिर्फ IPv6 connection से पूरा internet सीधे इस्तेमाल नहीं हो पा रहा था

WireGuard से IPv6 के ऊपर IPv4 tunnel बनाना

  • solution था VPS पर WireGuard install करना और client द्वारा VPS के IPv6 address को endpoint के रूप में इस्तेमाल करके tunnel configure करना
  • tunnel establish होने के बाद IPv4 traffic VPS के जरिए सामान्य रूप से काम करता है
    • VPS के जरिए जाने से latency बढ़ती है
    • working model खुद configure किए गए Dual-Stack Lite जैसा है
  • server एक Hetzner VPS था जिस पर पहले vps2arch से Arch Linux install किया गया था, और Hetzner की latest Debian image को base के रूप में इस्तेमाल किया गया था
  • WireGuard configuration ArchWiki के WireGuard specific VPN server example पर आधारित था, जिसमें IPv6 traffic add किया गया था
  • server configuration में ये शामिल थे
    • Address = 10.200.200.1/24, fd42:42:42::1/64, 2001:db8:abcd:1234::1/128
    • IPv4 forwarding iptables के MASQUERADE से
    • IPv6 ULA के लिए ip6tables के SNAT --to-source से NAT
    • IPv4/IPv6 forwarding enable करना
    • peers को foo example, जो direct IPv6 Global Unicast Address इस्तेमाल करता है, और bar example, जो NATed IPv6 ULA इस्तेमाल करता है, में बांटा गया
  • .ini style configuration के उलट wg-quick में PostUp और PostDown कई बार specify किए जा सकते हैं, और यह हर command को क्रम से execute करता है

IPv6 NAT, SNAT, client configuration

  • IPv6 में NAT जरूरी नहीं है, और Hetzner की तरह अगर VPS के पास /64 IPv6 block हो तो peer को direct Global Unicast Address(GUA) दिया जा सकता है
  • direct address method इस्तेमाल करने के लिए peer और interface के Unique Local Address(ULA) को public IPv6 address से बदलें और ip6tables MASQUERADE rule हटाएं
    • हर peer अपने assigned IPv6 address से internet पर direct addressable हो जाता है
    • कई devices से अपनी services forward करनी हों तो यह तरीका उपयुक्त है
    • VPS firewall को incoming traffic सही तरीके से handle करना चाहिए
  • अगर पक्का हो कि VPS का IP address static है और बदलता नहीं है, तो MASQUERADE की जगह SNAT इस्तेमाल किया जा सकता है
    • MASQUERADE runtime पर interface IP lookup करता है
    • SNAT address को direct specify करता है, इसलिए थोड़ा ज्यादा efficient है
  • client configuration में server के IPv6 address को Endpoint = [2001:db8:abcd:1234::1]:51820 की तरह square brackets में रखना चाहिए
  • AllowedIPs = 0.0.0.0/0, ::/0 से पूरा IPv4/IPv6 traffic tunnel में भेजा जाता है
  • दोनों sides पर चलाने के बाद सामान्य browsing ठीक हो गई, और tunnel local IPv4 और IPv6 addresses से server पर direct SSH access भी संभव था
  • Linux पर पत्नी की machine में भी WireGuard client आसानी से install किया जा सका

work VPN को network namespace से अलग करना

  • WireGuard connection के ऊपर work VPN को directly connect करने पर conflict हुआ और वह इस्तेमाल नहीं किया जा सका
  • vopono का उपयोग करके work VPN और जरूरी applications को network namespace के अंदर चलाया गया
  • मुख्य बात यह है कि MASQUERADE rule traffic को actual network interface के बजाय running WireGuard interface (foo या bar) तक forward करे
  • namespace के अंदर का traffic host के WireGuard nftables rules को directly aware नहीं होता, लेकिन वास्तव में WireGuard tunnel के जरिए route होता है
  • wg-quick available होने पर iptables से ज्यादा nftables को prefer करता है, लेकिन Docker के standard iptables rules से conflict से बचता है
  • vopono चलाने का example इस तरह है
$ 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/ को ip netns exec द्वारा /etc के रूप में mount किया जाता है, इसलिए उस namespace के लिए dedicated resolv.conf रखा जा सकता है
  • अगर IPv4 DNS resolution को prefer करना हो, तो इसी तरह gai.conf भी adjust किया जा सकता है
    • यह setting IPv6 tunnel traffic issue debug करते समय इस्तेमाल हुई
    • example AskUbuntu answer पर आधारित है
  • work VPN connect होने के बाद internal DNS server को /etc/netns/vo_none_none/resolv.conf में डालने पर, बाद में उस namespace में चलाए गए applications सामान्य रूप से काम करते हैं
  • Chrome जैसी applications को normal user privileges से namespace के अंदर चलाया जा सकता है
$ vopono -v exec -i bar --provider None --protocol None google-chrome-stable

Docker को उसी namespace में चलाना

  • Docker को सिर्फ किसी दूसरी application की तरह network namespace में चलाने से काम नहीं चलता
    • क्योंकि systemd से activated Docker socket namespace के बाहर create हुआ था
    • internal connectivity मिलती नहीं है
  • बाहरी Docker को stop करके namespace के अंदर नया dockerd और socket बनाने की कोशिश करने पर भी तुरंत समाधान नहीं मिला
    • ip netns exec mount namespace बनाता है और /sys को फिर से mount करता है
    • इस वजह से host का /sys/fs/cgroup दिखाई नहीं देता
  • इस स्थिति में यह error आ सकता है
Error: OCI runtime error: runc: runc create failed: no cgroup mount found in mountinfo
  • workaround है unshare से /sys को bind mount बनाना और ip netns exec द्वारा बनाए गए internal /sys mount को unmount करना
    • यह तरीका Unix StackExchange post पर आधारित है
    • इसके बाद mount namespace के अंदर /sys host /sys का bind mount बन जाता है
  • example commands इस तरह हैं
$ 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 command को same session में चलाने पर वे समान network namespace और mount namespace share करते हैं
  • Docker DNS setting /etc/netns/vo_none_none/docker/daemon.json में भी रखी जा सकती है
  • यह तरीका helper containers और Docker network से connected containers तक की जरूरत वाले काम के लिए पर्याप्त था, लेकिन bridge आदि की जरूरत वाले ज्यादा complex Docker configuration में वैसे ही काम न कर सकता है

WireGuard MTU issue debug करना

  • reboot के बाद WireGuard connection जिंदा जैसा दिख रहा था, लेकिन कुछ pages ही load हो रहे थे और GitHub जैसी sites नहीं खुल रही थीं
  • ping, ping -6, wg show normal थे, इसलिए कारण ढूंढना मुश्किल था
  • अलग-अलग sizes के ping से जांचने पर पता चला कि बड़े packets fail हो रहे थे
$ ping6 -s 1400 fd42:42:42::1
$ ping6 -s 1200 fd42:42:42::1
$ ping6 -s 800 fd42:42:42::1
  • 1400 size fail हुआ और 1200, 800 सफल रहे, जिससे confirm हुआ कि कारण MTU setting थी
  • local WireGuard interface का MTU घटाने पर kernel IP stack इससे बड़े packets नहीं बनाता
    • WireGuard encapsulation overhead जुड़ने के बाद final UDP packet भी path पर छोटी MTU link में drop नहीं होता
  • path पर हर router का अपना MTU होता है, और सबसे छोटे MTU से बड़े packets drop हो सकते हैं
  • tunnel traffic में WireGuard encapsulation से करीब 32 bytes overhead जुड़ता है, जिससे MTU issue और बढ़ सकता है
  • Path MTU Discovery messages intermediate routers से ICMP के जरिए deliver हो सकते हैं, लेकिन firewalls अक्सर ICMP drop करते हैं, इसलिए auto-adjustment नहीं हो पाता
  • IPv6 specification का minimum MTU 1280 है, इसलिए IPv6 के ऊपर WireGuard tunnel में यह value हमेशा काम करनी चाहिए

recovery के बाद बचे operational options

  • configuration result में ये शामिल थे
    • IPv4 और IPv6 दोनों वाले VPS पर WireGuard VPN server configuration
    • direct IPv6 और NATed IPv6 traffic दोनों का support
    • network namespace में work VPN चलाना
    • unshare workaround से Docker को उसी network namespace में चलाना
    • WireGuard MTU issue debug करना
  • remote work में internet connectivity issue हमेशा risk factor होता है, और इस मामले में Linux tools से ISP configuration recovery का इंतजार किए बिना workaround किया जा सका
  • Hetzner VPS WireGuard tunnel और legitimate general use support करता है, लेकिन port scanning·traffic spoofing·cryptocurrency mining allowed नहीं हैं
  • AirVPN, ProtonVPN, AzireVPN जैसे port forwarding support करने वाले VPN भी home server ports को ISP पर निर्भर किए बिना forward करने का alternative बन सकते हैं
  • OpenWRT router इस्तेमाल करने पर router side debugging ज्यादा की जा सकती है, और ऐसे workaround configuration को हर device पर अलग-अलग configure करने के बजाय router से सीधे WireGuard के जरिए handle किया जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-06-30
Hacker News की रायें

  • शीर्षक थोड़ा गलतफहमी पैदा करता है। सही कहें तो यह VPS के जरिए IPv6 tunnel से IPv4 इंटरनेट तक पहुंचना है, और आम तौर पर इसे 4in6 भी कहते हैं
    फिर भी यह दिलचस्प है। ISP के नजरिए से देखें तो IPv4 टूटने पर और IPv6 टूटने पर support issues की प्रकृति काफी अलग होती है। IPv4 outage आमतौर पर साफ़ “डाउन” स्थिति होती है, इसलिए users बहुत नाराज़ होते हैं लेकिन मामला सीधा होता है। वहीं IPv6 outage आंशिक failure, fallback की वजह से धीमी शुरुआत, gateway का यह मानना कि IPv6 मौजूद है जैसी अजीब शक्लों में दिखता है

    • पिछली बार जब IPv4 बंद हुआ था, तो मुख्य रूप से Github न चलने से पता चला। आजकल ज्यादातर consumer websites सिर्फ IPv6 पर भी काम करती हैं
      हालांकि जिन लोगों के router में केवल IPv4 DNS servers सेट थे, उन्हें पूरी तरह outage झेलना पड़ा। अगर Microsoft ने अपनी कुछ निकम्मी assets साफ़ कर दी होतीं, तो सबसे बड़ी चिंता शायद router से जुड़े mDNS hostname को याद करके login करना और यह जांचना होती कि IPv4 वापस आया या नहीं
    • IPv4 की लंबी tail निश्चित रूप से है, लेकिन घर पर आखिरी बार IPv4 कटने पर मेरी पत्नी को बिल्कुल पता नहीं चला। वजह यह थी कि Google, Facebook, Apple/iCloud, और CloudFlare hosting का बड़ा हिस्सा IPv6 पर चलता रहा
    • मेरा अनुभव भी यही है। IPv6 issues को classify और reproduce करना झुंझलाहट भरा मुश्किल है, और “मेरे computer पर तो चलता है” जैसी स्थितियां बहुत आती हैं
    • ज्यादातर ISP अभी भी IPv6 को पूरी तरह block कर देते हैं। छोटे operators अक्सर IPv6 एक बार try करने के बाद AAAA record update जैसी चीजें भूल जाते हैं, जिससे user को ऐसा लगता है कि उसकी पसंदीदा niche service दूसरे network पर तो चलती है, लेकिन जिस ISP को वह पैसे दे रहा है उस पर नहीं चलती
      यह अजीब समस्या है, और IPv4 के किसी दिन गायब हो जाने की उम्मीद करने के अलावा कोई अच्छा हल है या नहीं, पता नहीं। Happy Eyeballs को यह समस्या हल करनी थी, लेकिन समस्या अक्सर application layer से काफी ऊपर सामने आती है, और applications कुछ भी कर सकती हैं, इसलिए leaking abstraction के बिना general protocol से इसे हल करना मुश्किल है। निजी तौर पर मैं network पर IPv6 चालू रखकर और सभी browsers में IPv6 DNS बंद करके समझौता कर रहा हूं, लेकिन यह काफी असंतोषजनक है

  • अगर आप IPv6 इस्तेमाल करना चाहते हैं लेकिन आपका ISP नहीं देता, तो Hurricane Electric कई सालों से tunnel service दे रहा है
    https://tunnelbroker.net
    https://ipv6.he.net
    system या router पर tun device लाकर traffic route करने के scripts भी हैं: 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...

    • ऐसे tunnels की झुंझलाने वाली चेतावनी यह है कि streaming services इन्हें region restriction bypass करने वाले VPN की तरह block करती हैं, इसलिए जरूरत पड़ने पर tunnel बंद करने का तरीका पता होना चाहिए
      फिर भी यह अच्छी तरह काम करता है। भले ही router HE tunnel support न करे, RA की ताकत से network के अंदर सभी devices को IPv6 address दिया जा सकता है। कोई भी device /64 advertise करे तो वह IPv6 router बन जाता है। बेशक शर्त यह है कि router security के लिहाज से RA filter न कर रहा हो। port forwarding rules छुए बिना home network के अंदर services host करने के लिए यह बहुत उपयोगी है
    • Hurricane Electric शानदार है, लेकिन जैसे-जैसे ISP-provided IPv6 इस्तेमाल करने वाले बढ़े, “सामान्य” users tunnels से हट गए, और network services ने he.net tunnels को abuse के रूप में flag करना शुरू कर दिया
      बहुत सारी sites ने दीवारें खड़ी कर दीं या बिल्कुल काम करने से मना कर दिया, इसलिए मुझे अपने network के ज्यादातर हिस्से में IPv6 इस्तेमाल करना बंद करना पड़ा
    • ध्यान रखने वाली बात यह है कि मेरी जानकारी में HE tunnel तभी काम करता है जब ISP आपको public IPv4 assign करता है। अगर आप carrier-grade NAT के पीछे हैं, तो अफसोस, घर में IPv6 लाने के लिए कोई दूसरा समाधान चाहिए
    • मैं एक संतुष्ट “customer” हूं। OpenBSD के साथ मुफ्त 6in4 tunnel करीब 5 साल से इस्तेमाल कर रहा हूं, और बताने लायक कोई समस्या नहीं आई
      इसे सिर्फ OpenBSD network interface files जैसे /etc/hostname.gif0 से set किया है: tunnel, inet6 128 alias, !route -n add -inet6 default। इस connection का इस्तेमाल AWS के उस VPS cluster से connect करने के लिए करता हूं जिसे जानबूझकर public IPv4 address के बिना configure किया गया है। Jeff Bezos जैसे लोग IPv4 address space को सक्रिय रूप से monetize कर रहे हैं, इसलिए वरना यह monthly cost का बड़ा हिस्सा बन जाता

  • अगर असली IPv6-only environment में जल्दी से IPv4 connectivity चाहिए, तो public DNS64+NAT64 gateway इस्तेमाल किया जा सकता है। सूची https://nat64.net/public-providers पर है
    सामान्य उपयोग में सिर्फ DNS server बदलना काफी है। DNS64 उन targets के लिए, जिनके पास AAAA record नहीं है, NAT64 box की ओर जाने वाला AAAA DNS record synthesize करता है: $ dig +short @2a00:1098:2c::1 AAAA github.com → 2a01:4f8:c2c:123f:64:5:141a:9cd7। NAT64, DNS64 की वजह से अपनी तरफ आए traffic का protocol conversion और NAT processing कर देता है: $ curl --resolve github.com:443:[2a01:4f8:c2c:123f:64:5:141a:9cd7] [https://github.com/](<https://github.com/>;)

    • मैं यही बात कहने आया था। यूरोप में कम से कम https://nat64.net/ खुद काफी अच्छा है। मेरा अनुभव सिर्फ अच्छा रहा है
    • Cloudflare WARP इस्तेमाल करें तो यह कहीं ज्यादा तेज होगा। WARP के जरिए IPv4 addresses से भी सीधे connect कर सकते हैं

  • तो वह मिथकीय IPv6-only internet user सच में मौजूद है :) बढ़िया network engineering है
    पहले मुझे ज्यादा आम उल्टे उद्देश्य के लिए, यानी IPv4-only connection पर IPv6 से जुड़े काम करने के लिए, कुछ ऐसा ही चाहिए था। अगर server पर पूरा control हो, तो एक ज्यादा limited लेकिन fast solution के तौर पर ssh -D 1080 -N myserver से SOCKS5 proxy बनाकर browser में set किया था। शायद system-wide भी set किया जा सकता है, लेकिन सोचता हूं कि क्या इससे original ssh connection टूटकर सब कुछ ढह जाएगा

  • मेरी भी यही स्थिति है। 2 हफ्ते से बस यही सुन रहा हूं कि “ticket open है और technician जल्द ही देखेगा,” इसलिए काफी frustration है
    पता नहीं क्या IPv6 काम कर रहा है, इसलिए इसे complete outage नहीं माना जा रहा और priority कम है। जर्मनी में ऐसे मामलों में consumer compensation की guarantee देने वाला कानून है, और जल्द ही check करूंगा कि यह मामला भी उसके तहत आता है या नहीं। इस blog post के solution में समस्या यह है कि कई endpoints data center IP ranges को पूरा block कर देते हैं या कई CAPTCHA मांगते हैं, और सामान्य VPN providers के साथ भी यही है। मैं पूरे home network को ठीक करना चाहता था, इसलिए router पर ही इसे handle करना पड़ा। Ubiquiti EdgeRouter जैसी non-standard device होने से Wireguard routing और NAT rules set करने में फायदा हुआ। FritzBox जैसे equipment पर कैसे करता, पता नहीं। downside यह है कि router performance बहुत सारे connections handle करने के लिए कम है, इसलिए hardware offloading support करने वाले IPSec पर switch करना पड़ेगा

    • FritzBox में भी दरअसल VPN connection setup के लिए GUI काफी अच्छा है। यह feature FritzBox-to-FritzBox connection के लिए बनाया गया है, लेकिन compatible VPN हो तो चल जाता है। static IPv4/IPv6 routes भी set किए जा सकते हैं
      सबसे बड़ी समस्या शायद यह पता लगाना होगा कि दूसरी तरफ कौन-सा IPsec encryption configuration expect किया जा रहा है। Wireguard काफी आसान हो सकता है, लेकिन तब hardware acceleration की समस्या आ सकती है। जरूरत हो तो FritzBox config file का backup लेकर dump edit करके VPN endpoint manually set कर सकते हैं, फिर checksum दोबारा calculate करके import कर सकते हैं। AVM में कई settings हैं जिन तक users की direct access नहीं होती और इन्हें इस तरह tweak किया जा सकता है, लेकिन router को गलती से brick न कर दें इसलिए access थोड़ा कठिन रखा गया है
    • जर्मनी की स्थिति नहीं पता, लेकिन Netherlands में अगर उसी ISP से wired और mobile दोनों use कर रहे हों और wired connection में outage हो जाए, तो outage ठीक होने तक free mobile data मांगा जा सकता है
      ISP से पूछने लायक option हो सकता है

  • Apple के App Store rules में मुझे पसंद आने वाली बात यह है कि सभी apps के लिए IPv6-only network पर काम करना जरूरी है। यह rule कई सालों से है
    developer के तौर पर पहली बार सामने आए तो थोड़ा surprise होता है, लेकिन user के तौर पर अच्छा है कि यह मौजूद है

    • app इस्तेमाल करें तो क्या Github भी IPv6 से access हो सकता है?
    • लेकिन इसका मतलब यह नहीं कि server के पास IPv6 address होना जरूरी है

  • अगर ऐसा ही कुछ झेलना पड़े, तो ssh -D 8080 user@hostname से ssh proxy बहुत आसानी से बना सकते हैं
    connection बन जाने पर browser में localhost:8080 को SOCKS proxy के तौर पर use करने के लिए specify कर दें

    • मैं भी यही सलाह देने वाला था। temporary problem के लिए यह कहीं ज्यादा simple solution है, और proxy की जरूरत हो तो permanent tool के तौर पर भी इस्तेमाल हो सकता है
      इस feature का use करने के लिए sshd_config में AllowTcpForwarding enabled होना चाहिए
    • public Wi-Fi use करते समय मैं हमेशा यही करता हूं। VPN के लिए pay करने या VPN पर trust करने की जरूरत नहीं; सब कुछ अपने infomaniak server पर SOCKS forwarding कर देता हूं

  • IPv4 बंद करने में कुछ अटकने वाली जगहें हैं: लगता है ज़्यादातर वैकल्पिक search engines IPv6 connectivity नहीं देते, और Github में आख़िरी बार चेक करने पर IPv6 बिल्कुल नहीं था
    Microsoft है तो अच्छी चीज़ की उम्मीद नहीं करनी चाहिए, बल्कि सबसे ख़राब की उम्मीद करनी चाहिए। हाल में उन्होंने issues में noscript/basic (x)html भी तोड़ दिया। पता नहीं noscript/basic (x)html browser और self-hosted email से, mailbox@[ipv6:...] जैसे IP(v6) literal के साथ, अभी भी account बनाया जा सकता है या नहीं। Steam या games भी हाल में चेक नहीं किए, लेकिन कई CDN/game servers या उनका बड़ा हिस्सा शायद अभी भी सिर्फ़ IPv4 पर है। Email servers में भी कई self-hosted mail servers को ब्लॉक करते हैं, और Spamhaus जैसी Switzerland/Andorra की संदिग्ध कंपनियों की बनाई अनगढ़ और अनुपयुक्त blocklists इस्तेमाल करते हैं। साथ ही कई network applications IPv6 के फ़ायदों का उपयोग नहीं करतीं। उदाहरण के लिए, web जैसी client-server applications को, अगर ISP बहुत छोटा prefix न दे, तो हर session के लिए random generated IPv6 address इस्तेमाल करना चाहिए। Mobile IPv6 ISP लगता है prefix के भीतर arbitrary IPv6/128 address देते हैं, लेकिन उन्हें stable prefix, शायद करीब 96-bit, देना चाहिए ताकि endpoint applications बिना central online name resolution के direct voice/video calls के लिए “fixed” IPv6 address चुन सकें। User applications के बीच IPv6 address coordination के लिए नया user-level OS service भी चाहिए। हालांकि कुछ vendors और developers users और app developers को lock-in करने के लिए जो बेवकूफ़ाना complexity थोप सकते हैं, उससे सावधान रहना होगा

    • मेरे mini homelab में IPv6-only ठीक चल रहा था, लेकिन किसी वजह से GitHub की ज़रूरत पड़ते ही टूट गया। इसलिए NAT64+NAT64 खड़ा किया
      सिर्फ़ GitHub की वजह से ऐसा करना पड़ा, यह सच में अफ़सोसजनक था। Mail server के कारण कभी न कभी ज़रूरत पड़ती, लेकिन इतनी जल्दी NAT64 चाहिए होने की वजह के तौर पर यह बहुत खराब था। मेरे हिसाब से यह लोगों द्वारा GitHub को software distribution के माध्यम की तरह इस्तेमाल करने की कई कमियों में से एक है
    • कुछ महीने पहले Spamhaus से जूझना पड़ा। किसी कारण मेरे VPS का IPv6 address Spamhaus blocklist में चला गया था
      ऐसा क्यों हुआ, बिल्कुल नहीं पता। उस machine पर email भेजने की क्षमता वाली कोई चीज़ नहीं चल रही थी, और मेरी जानकारी में Digital Ocean SMTP भी ब्लॉक करता है, इसलिए इस machine के लिए email भेजना सचमुच असंभव था। Spamhaus ने समाधान में बिल्कुल मदद नहीं की, और DO ने भी नहीं
    • कई CDN/game servers अभी भी IPv4-only होने की समस्या की वजह से DNS proxy बनाया। यह ऐसे domains में सही AAAA records जोड़ देता है
      https://gitlab.com/miyurusankalpa/IPv6-dns-server
    • पुष्टि कर सकता हूँ कि Steam को IPv4 चाहिए। जिन कुछ games को खेलने के लिए authentication चाहिए, उनके साथ भी यही है
    • VPS services की तरह IPv6-only चलाने पर discount मिलने वाले मामलों को छोड़ दें, तो लगता है अभी कोई भी IPv4 से हटने पर गंभीरता से विचार नहीं कर रहा
      असल में संभावना ज़्यादा है कि किसी न किसी रूप में IPv4 connectivity बनी रहेगी, बस यह connectivity CGNAT के ज़रिए होने की संभावना बढ़ती जाएगी। Github खास तौर पर ग़ुस्सा दिलाता है। उन्होंने कई हफ़्तों तक testing की और सब कुछ ठीक चलता दिख रहा था, फिर वापस IPv4-only पर लौट गए। Email servers तो वैसे भी 10–20 साल पुराने संसार में जी रहे हैं। Email server पर SSL 3.0 या TLS 1.0 support बंद करना भी deliverability issues का जोखिम लिए बिना मुश्किल है। Microsoft Outlook का support और spam filter तो IPv6-capable mail servers को पहचानते भी नहीं लगते। Headers देखें तो internally वे बहुत पहले से IPv6 इस्तेमाल करते आए हैं, फिर भी ऐसा है। अच्छा होगा अगर IPv6 का ज्यादा इस्तेमाल हो, लेकिन लगता है थोड़े ग्राहकों के लिए कुछ कम ठीक चलने के डर से technology को सच में इस्तेमाल करने की हर कोशिश जम जाती है। Mobile carriers में अजीब IP behaviour दिखने की वजह शायद mobile networks में IP के काम करने के तरीके से जुड़ी है। Highway पर call करते हुए या high-speed train में बैठे हुए phone लगातार handover करता रहता है, और IP address को एक हद तक stability चाहिए। Border पार कर foreign network पर switch होने पर भी पूरे stack को seamless connection बनाए रखना होता है। Cellular network के भीतर special routing systems होते हैं, जिनमें से कुछ IPv6 features का शानदार उपयोग करते हैं, लेकिन phone को “normal” static global unicast address देना मुश्किल बना देते हैं। वे इसे जितना हो सके सामान्य जैसा दिखाते हैं, लेकिन wired home internet जैसी stability हासिल करना आसान नहीं है

  • काम पर internal infrastructure access के लिए कुछ IPv6-only VPN चला रहे हैं
    अब तक सबसे बड़ी समस्या यह है कि Windows और macOS clients को IPv6 DNS server चाहिए। नहीं तो वे v6onlyhost.vpn.example.com resolve करने की कोशिश भी नहीं करते। Client IPv6-capable network पर हो भी सकता है और नहीं भी, इसलिए VPN के अंदर DNS server चलाकर client में push करना पड़ता है, लेकिन VPN disconnect होने के बाद अगर Wireguard app किसी वजह से DNS को पहले जैसा वापस न कर पाए, तो तरह-तरह की समस्याएँ हो सकती हैं

    • ISP के IPv4-only network का इस्तेमाल करते हुए भी macOS ऐसे DNS server के बिना IPv6-only connection कर पा रहा था
      अब details याद नहीं हैं, लेकिन कुछ साल पहले खोदकर देखने पर पता चला कि macOS सिर्फ़ IPv6 address होने पर भी उस तरह ठीक चलता था। Host को ULA address दे देना होता है। बेशक यह मानकर कि user को तरीका पता हो। VPN application के हिसाब से IPv6-only network में जाते समय ULA जोड़ने वाली script डालना भी संभव है। हालांकि fake ULA को लगातार छोड़ देने से, जब user IPv6-capable network पर जाए, तो समस्या हो सकती है
    • यह Windows की समस्या नहीं है। मुझे भी random hotspots पर ऐसी मिलती-जुलती समस्या हुई थी, लेकिन सभी पर नहीं। मेरे हिसाब से वजह IPv6 बंद होने पर AAAA records return न करने वाले बेवकूफ़ hotspots हैं

  • इतना समय बीत जाने के बाद भी मुझे अब तक कोई ऐसा ठोस कारण नहीं दिखता कि मैं अपनी सभी मशीनों और homelab को IPv6 पर बदलने के लिए कई दिन सिर खपाऊँ
    हफ्तों तक सब कुछ troubleshoot करने, firewall को फिर से configure करने और network addresses को फिर से नंबर देने की बजाय port forwarding और firewall rules ज़्यादा intuitive लगते हैं। मैं क्या मिस कर रहा हूँ?

    • आप जो मिस कर रहे हैं, वह यह है कि यह उतना मुश्किल नहीं है जितना लगता है। अगर आपका home network बहुत जटिल नहीं है, तो IPv6 setup ज़्यादा से ज़्यादा एक शाम में हो जाना चाहिए
      मेरे network और मेरे ISP Comcast के हिसाब से, router पर IPv6 चालू करने से ISP से prefix मिल जाता है और वह local network में advertise हो जाता है; फिर जिन चीज़ों को बाहर से accessible बनाना है, उनके लिए एक firewall rule जोड़ दें, बस
    • आप कुछ मिस नहीं कर रहे हैं। enterprise environment में IPv6 adoption के फायदे, नुकसान से ज़्यादा नहीं हैं
      मैं करीब 3500 devices, 7 buildings, दो 10-gig WAN और एक 4-gig WAN manage करता हूँ, और लगभग 26 public IPv4 addresses तथा NAT इस्तेमाल कर रहा हूँ। अभी भी IPv6 अपनाने की कोई मजबूत वजह नहीं है। Dual-stack configuration बिना खास लाभ के सिर्फ unnecessary traffic और complexity जोड़ता है। आज भी static IPv6 address block आवंटित कराना मुश्किल है; मैंने दो बार apply किया, लेकिन reject हो गया। upside कम है ही, block मिलना भी अब तक कठिन है। https://www.arin.net/resources/guide/ipv6/first_request/ की eligibility conditions भी कुछ ऐसी हैं: IPv4 allocation होना, तुरंत IPv6 multihoming की योजना, 1 साल के भीतर 13 end sites, 1 साल के भीतर 2,000 IPv6 addresses का उपयोग, 1 साल के भीतर 200 /64 subnets का उपयोग
    • फिलहाल आप कोई बड़ी चीज़ मिस नहीं कर रहे हैं। किसी दिन Google, Cloudflare जैसी बड़ी कंपनियाँ लगातार महंगे होते जा रहे IPv4 address costs से परेशान होकर IPv6 के लिए incentives दे सकती हैं। उदाहरण के लिए, वे IPv4 को limit करना शुरू कर सकती हैं
      शुरुआती संकेत पहले से हैं। AWS पहले unused IPv4 Elastic IP addresses के लिए ही charge करता था, लेकिन अब usage से फर्क पड़े बिना charge करता है। सच कहूँ तो अगली बार gateway या router upgrade करते समय इसे तैयार रख लेना काफी है; अभी तुरंत आप कुछ मिस नहीं कर रहे। IPv4 और IPv6 साथ-साथ भी इस्तेमाल किए जा सकते हैं। router में इसे चालू करने पर IPv4-only devices वैसे ही ठीक चलते रहेंगे। एक बात ध्यान रखने लायक है कि IPv6 auto-discovery एक समय काफी messy थी। SLAAC, IPv6 automatic addressing और DHCPv6 सभी मौजूद थे, और originally automatic addressing DNS server हासिल करने को support भी नहीं करता था। अब चीज़ें SLAAC की तरफ consolidate हो रही हैं, लेकिन ISPs बहुत लंबे समय तक DHCPv6 इस्तेमाल करते रहेंगे