Google के IPv6 कनेक्शन अनुपात ने 50% हासिल किया

 (blog.apnic.net)
2 पॉइंट द्वारा GN⁺ 4 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • 23 अप्रैल 2026 को Google के IPv6 आँकड़े पहली बार 50% तक पहुँचे, जिससे Google सेवाओं तक होने वाली आधी पहुँच IPv6 पर होने के चरण में प्रवेश कर गई
  • उसी दिन APNIC Labs की वैश्विक IPv6 capability 42% दर्ज हुई, इसलिए इन दोनों आँकड़ों को मापन पद्धति और weighting model के अंतर के साथ देखना चाहिए
  • APNIC, Google Ads-आधारित measurement data को सीधे जोड़ता नहीं है, बल्कि अलग-अलग economies में internet users के आकार को दर्शाने वाले weights लागू करता है
  • India, Viet Nam, Saudi Arabia जैसी economies में adoption curve बहुत अलग है, इसलिए केवल वैश्विक औसत से क्षेत्रीय वास्तविकता समझाना मुश्किल है
  • IPv6 अब fixed network, mobile, personal device और data center services में रोज़ाना इस्तेमाल होने वाला internet operations का हिस्सा बन चुका है

Google IPv6 आँकड़ों का 50% मील का पत्थर

  • Google के IPv6 आँकड़ों ने 23 अप्रैल 2026 को पहली बार 50% दर्ज किया
    • यह आँकड़ा Google सेवाओं तक IPv6 के ज़रिए पहुँचने वाले users के अनुपात को दर्शाता है
    • यह Google users की IPv6 connectivity को लगातार देखने वाला एक संकेतक है
  • IPv6 50% तक पहुँचा: {p:50}
  • इस आँकड़े को इस बात के मील के पत्थर के रूप में देखा जा सकता है कि IPv6 अब वैश्विक वास्तविक networks में इस्तेमाल होने वाला एक mature protocol बन चुका है

केवल वैश्विक औसत से न दिखने वाले क्षेत्रीय अंतर

  • IPv6 adoption में region और economy के हिसाब से बड़ा अंतर है, इसलिए केवल एक वैश्विक trend line के आधार पर निष्कर्ष निकालना कठिन है
  • Google region-wise IPv6 आँकड़े सार्वजनिक नहीं करता, और economy-wise data भी कुल योग तक सीमित रखता है
  • APNIC Labs data में economy-wise adoption curve वैश्विक औसत से काफ़ी अलग हो सकती है

APNIC Labs का मापन 42%

  • APNIC के अपने मापन के अनुसार 23 अप्रैल 2026 तक वैश्विक IPv6 capability 42% थी
    • APNIC Labs वैश्विक मापन: Source
  • APNIC IPv6 capability: {p:42}
  • Google के 50% और APNIC के 42% के बीच स्पष्ट अंतर है
  • अलग-अलग economies के स्तर पर APNIC Labs का मापन आम तौर पर Google, Cloudflare, Akamai, Cisco आदि के data से मेल खाता है
  • वैश्विक स्तर पर बड़ा अंतर मूल measurement से ज़्यादा APNIC के weighting model के अंतर से उत्पन्न होने की संभावना है
  • व्यावहारिक रूप से APNIC का मापन Google के मापन से कम आने की प्रवृत्ति रखता है
  • दोनों datasets को साथ देखकर इन्हें किसी समय-बिंदु पर वास्तविक IPv6 capability की सीमा को दोनों ओर से घेरने वाले मानों की तरह समझा जा सकता है

APNIC की ads-आधारित मापन पद्धति

  • APNIC का measurement program, APNIC Labs द्वारा संचालित है और Google Ads के माध्यम से end-user web browsers, games और apps तक पहुँचने वाले online ads का उपयोग करता है
  • यह किसी खास user को चुनकर मापन नहीं करता, बल्कि सभी economies में 24/7 जितना संभव हो उतना व्यापक exposure पाने की कोशिश करता है
  • सामान्य ad tracking system के साथ APNIC Labs logic को जोड़कर एक विशिष्ट test set चलाया जाता है
    • इसमें IP, BGP routing, DNS और अन्य तकनीकी विकल्पों को मापा जाता है
  • end users की personally identifiable information (PII) संग्रहीत नहीं की जाती
  • raw measurements साझा नहीं किए जाते, केवल ISP, economy और region स्तर की aggregated information प्रकाशित की जाती है
  • यह measurement कार्य Google Research, ICANN और अन्य संस्थाओं के funding और support से किया जाता है

raw samples को सीधे जोड़कर कुल न बनाने का कारण

  • APNIC, collected data पर statistical weights लागू करता है और World Bank statistics जैसे external data के आधार पर economy-wise internet usage का model बनाता है
  • APNIC Labs को हर दिन मिलने वाले measurement samples की संख्या समान नहीं होती
  • Google की ad placement delivery और revenue को अधिकतम करने के लिए optimized होती है, इसलिए कुछ दिनों में कुछ economies से ads और measurement samples ज़्यादा आ सकते हैं
    • उदाहरण के लिए Egypt या Tunisia जैसी North African economies में ad demand अधिक होने वाले दिन वहाँ से अधिक measurements इकट्ठा हो सकते हैं
    • उसी दिन South America या Asia में तुलनात्मक रूप से कम samples मिल सकते हैं
  • APNIC Labs raw sample count को सीधे जोड़ता नहीं है
    • पहले प्रत्येक economy की measured IPv6 capability को aggregate किया जाता है
    • उसके बाद उस economy में internet users की अनुमानित संख्या के अनुसार weight दिया जाता है
  • India, China, Indonesia और अन्य बड़ी economies, जहाँ internet population बहुत अधिक है, किसी खास दिन raw sample count चाहे जो हो, वैश्विक परिणाम में अधिक हिस्सेदारी रखती हैं
  • इस पद्धति का उद्देश्य यह है कि अंतिम measurement value, दैनिक ad distribution pattern की तुलना में वैश्विक internet usage को बेहतर ढंग से दर्शाए

IPv6 transition में इतना समय क्यों लगा

  • कुछ लोग IPv6 के 50% adoption milestone तक पहुँचने में लगे लंबे समय को IPv6 की प्रणालीगत विफलता का प्रमाण मानते हैं
  • IPv6 deployment के लिए काफ़ी तकनीकी प्रयास और बड़े पूँजी निवेश की आवश्यकता थी
  • region और economy के हिसाब से प्रगति का अंतर, ISP और economies द्वारा network growth, user expectations और internet infrastructure संचालन की वास्तविकताओं के बीच किए गए अलग-अलग आकलन का परिणाम था
  • वैश्विक internet कोई planned economy नहीं है, बल्कि यह market-driven परिस्थितियों में collaboration और cooperation के माध्यम से विकसित होता है
  • कई providers ने अतीत में IPv4 में भारी पूँजी निवेश किया था और वे उस निवेश पर अधिकतम प्रतिफल चाहते थे
    • इस प्रक्रिया में उन्होंने मौजूदा service range के भीतर टिकाऊ और व्यावसायिक रूप से व्यवहार्य IPv4-आधारित networks बनाए
  • नए market entrants के लिए कई बार IPv6 को default protocol के रूप में अपनाना अधिक तर्कसंगत था
    • IPv6 total cost of ownership (TCO) कम कर सकता है
    • यह पैटर्न mobile sector में विशेष रूप से अधिक स्पष्ट है
    • India के Reliance Jio network को बड़े पैमाने पर IPv6 deployment के उदाहरण के रूप में दिखाया गया है

IPv4 और IPv6 साथ-साथ चलाने वाला आज का internet

  • आज का वैश्विक internet दो protocol worlds में काम करता है
  • logistics के लिहाज़ से single protocol पर संचालन करना आसान होता, लेकिन वास्तविक दुनिया में ऐसा नहीं हुआ
  • आज internet में कई तरह की connectivity एक साथ मौजूद हैं
    • direct IPv4 connection
    • home network NAT या carrier-grade Carrier-Grade NAT(CGNAT) के माध्यम से IPv4
    • IPv6
  • NAT के माध्यम से address translation को manage करना, protocol translation, IPv6 पर IPv4 encapsulation, या अन्य transition/proxy mechanisms की तुलना में मूल रूप से कम जटिल नहीं है
  • “IPv4 is working fine” जैसी बात अक्सर इस वास्तविकता को नज़रअंदाज़ कर देती है कि आधुनिक IPv4 networks पहले से ही कई स्तरों की operational complexity पर निर्भर हैं
  • केवल IPv4 अपने आप में न तो स्वाभाविक रूप से अधिक सस्ता है और न ही अधिक सरल approach

IPv4·IPv6 interoperability वास्तव में कहाँ बनती है

  • IPv4 और IPv6 के बीच direct interoperability न होना शुरुआत से ही हल किए जाने वाले मुद्दे के रूप में समझा गया था
  • शुरुआती दौर में ऐसे protocol ideas तलाशे गए थे जो IPv4 को बदले बिना समाहित कर सकें और दोनों worlds के बीच direct connection संभव बना सकें, लेकिन वे व्यवहार्य रूप में सिद्ध नहीं हुए
  • interoperability ऊपर की layer में TCP, UDP, QUIC जैसे transport protocols के माध्यम से बनती है, जो IP version से स्वतंत्र रूप से काम करते हैं
  • इस model में किसी न किसी रूप में intermediary की आवश्यकता होती है
  • Cloudflare जैसे बड़े content और caching providers, backend systems में दोनों protocols के support की स्थिति चाहे जो हो, dual-stack service देने के लिए जिस तरीके का उपयोग करते हैं, उसमें यह संरचना देखी जा सकती है

कुछ services में dual-stack क्यों नहीं है

  • कुछ services में native dual-stack capability का न होना अक्सर IPv6 प्रगति में बड़ी बाधा माना जाता है
  • उदाहरण के रूप में किसी विशेष Git platform या राष्ट्रीय स्तर के TV broadcaster का उल्लेख किया जाता है
  • ऐसी स्थिति IPv6 के प्रति प्रतिरोध से ज़्यादा operational complexity को दर्शा सकती है
  • राष्ट्रीय broadcaster के मामले में data access और geolocation से जुड़े कानूनी तथा regulatory requirements जैसे व्यावहारिक constraints असर डाल सकते हैं

IPv6 अब रोज़मर्रा के संचालन का हिस्सा है

  • IPv6 अब वैश्विक स्तर पर deploy हो चुका है
  • Google को दिखने वाले internet users में लगभग आधे पहले से Google services तक IPv6 के ज़रिए पहुँचते हैं
  • विकसित और विकासशील देशों, fixed और mobile networks, personal छोटे devices और बड़े data-center आधारित services में IPv6 हर दिन, हर घंटे इस्तेमाल हो रहा है
  • IPv6 अब कोई प्रयोगात्मक या हाशिये की तकनीक नहीं, बल्कि internet के दैनिक संचालन का हिस्सा है

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

2 टिप्पणियां

 
purely4959 4 시간 전

कोरिया में घरेलू इंटरनेट पर IPv6 कब लागू होगा?
 
GN⁺ 4 시간 전
Hacker News की राय

  • “ISP अब भी यह नहीं कर रहे” वाले उदाहरण में एक और जोड़ें: UK के बड़े ISP Virgin Media ने 2011 के World IPv6 Day पर सार्वजनिक रूप से कहा था कि वह 2012 के अंत तक IPv6 को पूरी तरह support करेगा, लेकिन 15 साल बाद भी अब तक switch on नहीं कर पाया है
    https://havevirginmediaenabledipv6yet.co.uk/
    उस समय की घोषणा: https://ispreview.co.uk/story/2011/06/08/uk-isp-fluidata-hai...

    • ISP पर IPv6 support करने का दबाव बनाने का तरीका भले ही बेवकूफी भरा लगे, लेकिन असरदार हो सकता है। Shopping comparison sites IPv6 non-supporting ISP पर बड़ा लाल warning लगा सकती हैं, और websites भी “आपका ISP इस site द्वारा उपयोग किए जाने वाले सामान्य internet connection को support नहीं करता” वाला banner दिखा सकती हैं
      उपभोक्ता शायद IPv6 क्या है यह न जानते हों, लेकिन बड़ा लाल warning और परेशान करने वाले banner को समझते हैं
    • पहले मैंने Virgin Media से पूछा था कि क्या 1Gb DIA line पर IPv6 enable किया जा सकता है, तो जवाब मिला: “हम line को IPv6 पर switch कर सकते हैं, लेकिन फिर आपको IPv4 छोड़ना होगा”
      उसके बाद दोबारा पूछने का मन ही नहीं हुआ
    • पूरी तरह business के नज़रिए से देखें तो VM के पास इसे करने की खास वजह नहीं है। IPv4 addresses पर्याप्त हैं, और बहुत छोटे technical user base को छोड़ दें तो ग्राहक IPv6 के फायदे महसूस नहीं करते
      ऊपर से दूसरे ISP के IPv6 implementations द्वारा random चीज़ें टूटने के उदाहरण भी हैं, इसलिए इसके न करने की वजह भी समझ आती है
    • नीदरलैंड्स में https://heeftodidoipv6.nl जैसी site है
      इस ISP के core network में IPv6 है, लेकिन ग्राहकों को नहीं दिया जाता, और डच telecom market में इसकी हिस्सेदारी 17% है
    • अमेरिका कम से कम अब काफ़ी करीब पहुँच रहा है। Top ASNs में IPv6-capable ratio 75% से ऊपर है
      लेकिन Optimum Communications और Frontier क्रमशः लगभग 15% पर रहकर आँकड़े को काफ़ी नीचे खींच रहे हैं; Frontier बहुत धीरे-धीरे सुधार कर रहा है, जबकि Optimum की तरफ़ बदलाव के सबूत कम दिखते हैं

  • दो महीने पहले भी 626 comments वाला एक thread था: https://news.ycombinator.com/item?id=47777894

  • “Pure” IPv6 server set up करके देखा तो यह जानकर हैरानी हुई कि GitHub IPv6 support नहीं करता। https://nat64.xyz/ पर मौजूद voluntary NAT64 operators न हों तो IPv6 environment से GitHub तक पहुँचना संभव नहीं है

    • GitHub का IPv6 non-support बिल्कुल भी माफ़ करने लायक नहीं है
    • Internet ने फिर एक बार इस समस्या को bypass कर लिया। यह 2020s में भी इस बात का अच्छा उदाहरण है कि व्यवहार में कई internets नहीं, बल्कि सिर्फ़ एक internet ही मौजूद है

  • अरे नहीं, मेरा /22 IPv4 subnet तो private 401k की तरह है, इसे retirement fund के तौर पर इस्तेमाल करना है

    • मज़ाक लगता है, लेकिन housing को लेकर समाज का नज़रिया भी बिल्कुल ऐसा ही है
    • क्या अब cash out करने का समय आ गया है?
    • 2100 तक आते-आते सच में मुश्किल हो सकती है

  • नीदरलैंड्स का T-Mobile/Odido कई सालों से काम चल रहा है ऐसा वादा करता आया है, लेकिन अब भी IPv6 support नहीं करता
    Ubiquiti gateway में भी support कुछ कमज़ोर लगता है, और Hurricane Electric tunneling जैसी सुविधा support होनी चाहिए

    • यहाँ Ubiquiti gateway के ज़रिए news.ycombinator.com के IPv6 address 2606:7100:1:67::26 तक पहुँच ठीक से हो रही है
    • HE tunnel address ranges को अब non-residential/non-office addresses के रूप में काफ़ी सख़्ती से penalize किया जाता है, इसलिए आखिरकार मुझे इसे बंद करना पड़ा
      उदाहरण के लिए, YouTube बिना login वाले HE range users को आम तौर पर block करता दिखता है, और अंतहीन CAPTCHA भी अक्सर देखने को मिले
    • दिलचस्प बात यह है कि US का T-Mobile इसका ठीक उलटा करता है: वह IPv4 support नहीं करता, सिर्फ़ IPv6 assign करता है, और IPv4 के लिए 464XLAT के ज़रिए “fake NAT” देता है
    • T-Mobile US लगभग 2018 से IPv6-only था: https://www.youtube.com/watch?v=d6oBCYHzrTA
    • सभी ISP को Hurricane Electric tunnel की लागत चुकानी चाहिए, इसलिए यह users के लिए free हो। अगर काफ़ी लोग HE tunnel इस्तेमाल करने लगें, तो ISP native IPv6 देने लगेंगे
      लेकिन व्यवहार में, जिन websites पर आप जाते हैं वहाँ block हो जाना आसान है, और अगर आप CGNAT के पीछे हों या home router में DMZ न हो तो इसका इस्तेमाल करना भी कठिन है

  • मैं AWS को public IPv4 addresses की लागत देना बंद करना चाहता हूँ, लेकिन ग्राहक पक्ष के कई ISP इसे support नहीं करते, इसलिए पूरी तरह IPv6 migration संभव नहीं है
    अभी ISP पर IPv6 की ओर जाने का कोई दबाव नहीं है, बल्कि स्थिति उलटी है। ISP को fixed IP के लिए शुल्क लेना पसंद है

    • निष्पक्ष रूप से कहें तो अगर Google IPv4 support बंद कर दे, तो यह ISP को लाइन में लाने के लिए काफ़ी मजबूत incentive होगा

  • अगर खासकर वीकेंड पर IPv6 का अनुपात बढ़ता है, तो यह संकेत लगता है कि enterprise/work networks की तरफ implementation टाली जा रही है

    • असली milestone हमेशा वह बिंदु होता है जहाँ यह लगातार 50% से ऊपर रहे
    • लोग कहते हैं, “आलस की वजह से नहीं करते”, लेकिन IPv6 ऐसा काम नहीं है जो एक checkbox on करते ही खत्म हो जाए
      आखिर कुछ नंबर बदलने के लिए organizational restructuring तक करके इतना सारा काम क्यों किया जाए? जब IPv4 चल रहा है तो क्यों?

  • Google का IPv6 50% तक पहुँचना website access के लिहाज़ से बहुत अच्छी बात है
    लेकिन मेरा TP-Link router डिफ़ॉल्ट रूप से incoming IPv6 connections को block करता है, और कोई setting option भी नहीं देता, इसलिए pure IPv6 two-way streaming, gaming, और home network services के लिए यह अब भी अच्छा नहीं है

    • उस डिवाइस पर OpenWRT डाल दें तो इसे मनचाहे तरीके से चलाया जा सकता है। IPv4 के port forwarding rules की जगह, लगभग उन्हीं ports के लिए IPv6 access rules जोड़ने का आनंद मिलता है
    • मैं WireGuard VPN पर, जिसमें free VPS इस्तेमाल हो रहा है, web और email self-host कर रहा हूँ। OCI पर यह free में किया था, और AWS Lightsail पर भी सस्ते में हो सकता था
      Tailscale जैसी easy-to-configure solution भी इस्तेमाल की जा सकती है, और इससे home network को सीधे internet पर expose नहीं करना पड़ता
    • consumer router makers आम तौर पर ज़्यादा अच्छे नहीं होते, इसलिए फ़र्क बहुत बड़ा नहीं है, लेकिन TP-Link वाकई बहुत खराब है। उस hardware का इस्तेमाल न करने की मैं ज़ोरदार सलाह दूँगा
    • ये systems अपने design के दौर को reflect करते हैं। IPv6 30 साल पुरानी technology है, और उस समय आज जैसी कई threats मौजूद नहीं थीं
      उदाहरण के लिए, default को /64 block रखने का फ़ैसला इस सोच पर आधारित था कि 48-bit MAC address का कुछ हिस्सा इस्तेमाल किया जाएगा, लेकिन अब हम जानते हैं कि privacy के लिहाज़ से यह एक दुःस्वप्न है, इसलिए अब कोई ऐसा नहीं करता। फिर भी उससे निकली 128-bit address scheme से हम अब भी बँधे हुए हैं
      IPv6 ने NAT को पर्याप्त addresses से replace करने की कोशिश की, लेकिन दिलचस्प रूप से इससे intent expression की समस्या पैदा हुई। NAT में जब किसी कंप्यूटर की service incoming connection के लिए port मांगती थी, तो service owner की मंशा साफ़ होती थी, लेकिन IPv6 में ऐसा कोई intent signal नहीं है। इसलिए home router makers डिफ़ॉल्ट रूप से addresses को block करने पर मजबूर हैं, वरना बाहर से PC scan करके अनजाने services को public internet पर expose किया जा सकता है
      बड़ा address space तकनीकी रूप से बेहतर हो सकता है, लेकिन defaults और user intent को ध्यान में रखना ज़रूरी है। एक अच्छा technical solution भी इस मोड़ पर खराब solution बन सकता है या ढेर सारी समस्याएँ पैदा कर सकता है

  • Cloudflare में IPv6 40% से ऊपर दिखता है, लेकिन कुल traffic बढ़ने के बावजूद पिछले एक साल में यह ज़्यादा नहीं बढ़ा है। APNIC पोस्ट की observation की तरह, वास्तविक overall adoption शायद Google और Cloudflare के बीच कहीं होगा
    https://radar.cloudflare.com/adoption-and-usage#ipv4-vs-ipv6
    हालाँकि, यह client-side adoption को reflect करता है। बड़े services में भी अब तक कई सिर्फ IPv4-only हैं, इसलिए public internet पर बहने वाले वास्तविक IPv6 traffic का हिस्सा काफ़ी कम हो सकता है
    अब जबकि नए IPv4 allocation बहुत पहले ही खत्म हो चुके हैं, ऐसा लगता है कि पहले से अलग migration incentives की ज़रूरत है

    • traffic share के हिसाब से देखें तो high-bandwidth बड़े services, यानी video streaming sites और CDN, ज़्यादातर IPv6 पर हैं। IPv4-only long-tail services आम तौर पर कम bandwidth इस्तेमाल करती हैं
    • आजकल rate limiting एक बड़ा reverse incentive हो सकता है। IPv4 में range blocking कुछ हद तक असरदार है, लेकिन IPv6 में बहुत कम
      HE Tunnelbroker को आजकल खराब reputation मिलने की एक वजह यही है। Discord music bots YouTube audio data लाने के लिए tunnelbroker IPs के बीच load balancing करते थे, और /64 को block करने पर भी /48 या उससे बड़े range से bypass कर सकते थे। मेरा मानना है कि Discord ने IPv6 को disable करने की मुख्य वजह भी IP-based blocking और API rate limiting ही थी

  • देशवार अनुपात देखें तो यह दिलचस्प है। फ़्रांस शायद 85% तक पहुँच गया है
    https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...

    • mobile traffic जितना ज़्यादा होगा, IPv6 ratio भी उतना ही ऊँचा होगा। भारत को देखें तो यहाँ हर कोई ऐसी fiber line इस्तेमाल नहीं कर रहा जो IPv6 देती हो
    • यह जानने की उत्सुकता है कि उस graph में long-term trend के ऊपर चढ़ा हुआ high-frequency signal क्यों दिखता है
      https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...
    • भारत का 75% पर होना सचमुच अच्छी खबर है। अगर ऐसा न होता, तो IPv4 address pricing pressure बेहिसाब ज़्यादा होता