AWS ग्राहक IPv4 से बच नहीं सकते

 (tty.neveragain.de)
1 पॉइंट द्वारा GN⁺ 2023-09-24 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AWS फरवरी 2024 से dedicated public IPv4 address के लिए प्रति घंटे $0.005 चार्ज करेगा, लेकिन AWS सेवाओं की सीमाओं के कारण ग्राहकों के लिए IPv6 अपनाकर लागत से बचना मुश्किल है
  • बिलिंग का दायरा व्यापक है: Elastic Load Balancer, EC2/Elastic IP, public IP सेट किए गए ECS Fargate tasks, Global Accelerator, Site-to-site VPN, RDS, Managed NAT Gateway आदि
  • EC2, VPN, Transit Gateway, Direct Connect, Network Firewall आदि IPv6 आधारित वातावरण में काम करते हैं, लेकिन API Gateway, Lambda, ECS, App Runner जैसी मुख्य सेवाएँ IPv6-only subnet को अस्वीकार करती हैं या ठीक से support नहीं करतीं
  • internal setup को dual-stack बनाने पर भी service API endpoints के 90% से अधिक IPv6 support नहीं करते, इसलिए VPC में public IPv4 के बिना S3, Systems Manager, SQS आदि का उपयोग करना कठिन है
  • बड़े ग्राहकों के लिए यह अक्सर बिल के 1% से कम होता है, इसलिए migration की प्रेरणा कमजोर है; वहीं SMB, hobby users और startups को 10–30% लागत वृद्धि झेलनी पड़ सकती है, जिससे बोझ अधिक होता है

फरवरी 2024 से dedicated public IPv4 पर शुल्क

  • AWS फरवरी 2024 से हर dedicated public IPv4 address के लिए प्रति घंटे $0.005 चार्ज करेगा
    • यह लगभग $4 प्रति माह और $40 से अधिक प्रति वर्ष के बराबर है
    • यह AWS-owned IPs पर लागू होता है; ग्राहक द्वारा लाए गए routable public IPv4 blocks यानी BYOIP addresses पर शुल्क नहीं लगेगा
  • शुल्क उन प्रमुख resources पर व्यापक रूप से लागू है जो public IPv4 का सीधे उपयोग करते हैं
    • Elastic Load Balancer
      • प्रति Availability Zone 1 address का उपयोग करता है
      • कम से कम 2 की जरूरत होती है और IPv4 बंद नहीं किया जा सकता
    • EC2 instances और Elastic IP
    • public IP सेट किए गए ECS Fargate tasks
    • Global Accelerator IP
    • Site-to-site VPN IP
    • RDS
    • Managed NAT Gateway
  • shared IPv4 addresses को बाहर रखा गया है
    • CloudFront distributions या API Gateway endpoints में उपयोग होने वाले shared addresses शुल्क के दायरे में नहीं हैं
    • VPC के बाहर Lambda functions द्वारा उपयोग किए जाने वाले public IPv4 addresses भी बाहर हैं

वे configurations जिनमें लागत काफी बढ़ती है

  • 3 Availability Zones में configured public Elastic Load Balancer की base price 50% से अधिक बढ़ जाती है
  • Managed NAT Gateway की base price लगभग 10% बढ़ती है
    • NAT Gateway Availability Zone स्तर की redundancy प्रदान नहीं करता
    • outbound connectivity महत्वपूर्ण हो तो हर Availability Zone के लिए NAT Gateway चाहिए
  • खासकर address ज्यादा waste करने वाले दो patterns पर बड़ा असर पड़ता है
    • हर VPC में कई Load Balancers रखने वाली configuration
      • यह तब होता है जब कई CloudFormation templates या Terraform modules को मिलाया जाता है, या Kubernetes ingress controller हर service के लिए Load Balancer बनाता है
      • एक Load Balancer कई URLs और services को संभाल सकता है
    • Managed NAT Gateway से बचने के लिए EC2 instances और Fargate tasks पर जानबूझकर public IPv4 लगाने वाली configuration
      • विडंबना यह है कि प्रति Availability Zone public IPv4 addresses लगभग 10 तक पहुँचने से पहले तक यह तरीका अभी भी सस्ता है

मौजूदा usage कैसे देखें

  • public IPv4 address usage पहले से account में aggregate हो रहा है
    • अभी यह $0 दिखता है, लेकिन फरवरी 2024 से प्रति घंटे $0.005 charge होगा
  • देखने का path इस प्रकार है
    • Billing Dashboard > Bills
      • Virtual Private Cloud section में PublicIPv4:InUseAddress के रूप में दिखता है
    • Cost Explorer
      • केवल PublicIPv4:InUseAddress शामिल करने के लिए filter करके daily/hourly usage देखा जा सकता है
      • member account के हिसाब से grouping भी संभव है
    • VPC > VPC IP Address Manager > Public IP insights
      • public IPv4 usage overview देखा जा सकता है
      • IPAM का यह हिस्सा free है
      • यह सिर्फ account और region-level data दिखाता है, और अस्थायी रूप से उपयोग हुए addresses capture नहीं करता, इसलिए data अधूरा है

IPv6 adoption के दो तरीके

  • IPv4 addresses पर cost लगती है और IPv6 addresses free हैं, इसलिए ऊपर से IPv6 migration एक स्वाभाविक विकल्प लगता है
  • IPv6 में private address की अवधारणा नहीं है, इसलिए Managed NAT Gateway और उसकी cost से बचा जा सकता है
  • IPv6 adoption के मोटे तौर पर दो तरीके हैं
    • dual-stack
      • सभी systems में IPv4 और IPv6 addresses साथ में configure करना
    • internal IPv6-only
      • internal side पर केवल IPv6 उपयोग करना, और आम users से जुड़े edge या CDN पर ही IPv4 connectivity देना
  • अमेरिकी राष्ट्रपति कार्यालय के memorandum में कहा गया है कि dual-stack operation maintain करने के लिए बहुत complex और अनावश्यक हो गया है, और standards bodies व प्रमुख tech companies IPv6-only deployments की ओर बढ़ना शुरू कर चुकी हैं
  • AWS का बुनियादी IPv6 network support खुद अपेक्षाकृत अच्छा है
    • IPv6-only subnet में IPv6-only EC2 instance configure किया जा सकता है
    • local DNS, time service, host configuration, security आदि IPv6 network से अपेक्षित functions काम करते हैं
    • VPN, Transit Gateway, Direct Connect, Network Firewall भी IPv6 support करते हैं

AWS services के उपयोग के चरण में IPv6 अटकता है

  • bottleneck network खुद से ज्यादा दूसरी AWS services से connect करने के चरण में दिखता है
  • API Gateway, Lambda, ECS, App Runner जैसी core services IPv6-only subnet configuration को reject करती हैं या errors देती हैं
    • Elastic Load Balancer Not enough IP space available जैसा error दे सकता है
  • internal setup को dual-stack बनाना भी पर्याप्त नहीं है
    • कई services subnet में IPv6 configured होने पर भी उसे ignore करती हैं
    • अक्सर वे केवल IPv4 targets से connect कर सकती हैं
  • VPC में public IPv4 address के बिना service APIs का उपयोग करना कठिन या असंभव होने के कई उदाहरण हैं
    • EC2 instance से aws s3 ls चलाना fail हो जाता है
    • instances में access और management के लिए recommended method Systems Manager काम नहीं करता
    • ECS Task से SQS access संभव नहीं होता
  • AWS IPv6 support status के अनुसार service API endpoints के 90% से अधिक IPv6 support नहीं करते
  • SES SMTP और ECR repository endpoints भी काम नहीं करते, और CloudFront IPv6 origin से connect नहीं कर सकता
    • ECR से ECS task शुरू नहीं किया जा सकता, लेकिन IPv6 support करने वाले Docker Hub से संभव है
    • Docker Hub pulls पर rate limit लागू करता है

PrivateLink एक alternative है, लेकिन cost constraints बड़े हैं

  • कई services को PrivateLink से connect किया जा सकता है
    • यह customer VPC से direct connection देता है, इसलिए public IP address की जरूरत नहीं होती
    • यह सभी services support नहीं करता
  • PrivateLink पर service-wise और Availability Zone-wise billing होती है
    • प्रति endpoint लगभग $9 प्रति माह
    • उदाहरण के लिए Secrets Manager, EC2, SSM, SSM-Messages को 3 Availability Zones में connect करने पर प्रति VPC सालाना $1,200 से अधिक हो जाता है
    • additional traffic charges भी लगते हैं

IPv4 billing का IPv6 migration में बदलना मुश्किल क्यों है

  • बड़े पैमाने के ग्राहकों के लिए IPv4 charges आम तौर पर bill के 1% से कम होते हैं, इसलिए यह बड़ा बदलाव महसूस नहीं होता
    • सिर्फ इस cost से meaningful engineering investment होना मुश्किल है
  • SMB, hobby users और startups के लिए charges bill को 10–30% तक बढ़ा सकते हैं
    • उनके पास cost से बचने के लिए IPv6 अपनाने की मजबूत प्रेरणा है
    • लेकिन AWS services के IPv6 support gaps के कारण IPv4 cost से बचने के तरीके सीमित हैं
  • हाल के IPv4 acquisition costs को देखते हुए IPv4 address billing खुद जरूरी हो सकती है
  • अगर AWS services में overall IPv6 support mature होता, तो अधिक ग्राहक IPv6-only environments में migrate कर सकते थे
  • अभी AWS में IPv6 को first-class citizen मानना मुश्किल है, और इस स्थिति में IPv4 billing personal accounts, learning, certification preparation और open source support के उद्देश्य से AWS usage को कम आकर्षक बनाती है

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

1 टिप्पणियां

 
GN⁺ 2023-09-24
Hacker News की राय

  • बहुत पहले जब मैं Amazon में junior developer था, तब एक बड़ा internal project था जिसमें सभी internal systems को region-specific versions में तोड़ा जा रहा था और regions के बीच calls को केवल सीमित gateways के ज़रिए अनुमति दी जा रही थी
    वजह यह थी कि internal IPv4 addresses खत्म हो रहे थे
    “बस IPv6 पर क्यों नहीं बदल देते?” इस सवाल पर जिम्मेदार Principal PM ने कुछ इस तरह जवाब दिया था: “हमारे पास मौजूद internal network equipment में से बहुत सारा IPv6 support नहीं करता, इसलिए बदलना हो तो दुनिया भर के लगभग सालाना production जितना equipment खरीदकर सब install करना पड़ता”
    यह मान लेना आसान है कि Amazon IPv4 के मामले में खराब नीयत से काम कर रहा है, लेकिन AWS systems के scale को देखते हुए यह भी पूरी तरह believable है कि पुराने network hardware को कम समय में पूरी तरह replace करना बहुत बड़ा project रहा होगा

    • उत्सुकता है कि क्या याद है वह कौन-सा साल था
      थोड़ा शक होता है कि यह कुछ हद तक बकवास था, या कम-से-कम facts को creative तरीके से package किया गया था। उदाहरण के लिए असल में शायद सबमें IPv6 support था, लेकिन डर, अनिश्चितता और संदेह से भरे network engineers उसे enable नहीं करना चाहते थे
      मैंने जो ज्यादातर network equipment देखा है, वह आसपास IPv6 के वास्तविक इस्तेमाल से काफी पहले से dual stack था, और मैं हमेशा सोचता था कि यह US government या military requirements की वजह से आया था
    • वह regionalisation याद है। बाहर से देखते हुए भी वह “दिलचस्प” काम था। मैं ऐसी नई service वाली तरफ था जो शुरू से ही region-wise बनाई गई थी
      मुझे याद नहीं कि उस project का PM कौन था, लेकिन उसी समय मुझे सच में यह सम्मान हुआ कि TPM कितना value create कर सकता है
      यह बात सही है कि cost और network equipment replacement की जरूरत IPv6 पर न जाने की मजबूत वजहों में से एक थी। Amazon कई कारणों से खुद design और manufacture किया हुआ network equipment इस्तेमाल करता था, और शायद अब भी करता होगा
      उन devices में सभी में fixed memory capacity थी, इसलिए IPv6 routing tables वगैरह संभालने लायक memory बढ़ानी हो तो उन्हें replace करना पड़ता। अगर IPv6-only चुना भी जाता तो existing equipment काफी नहीं होता, और वैसे भी IPv4/IPv6 dual stack के बिना मंजूरी मिलना मुश्किल था
    • वह PM शायद Laura Grit रही होंगी, और मुझे लगता है कि असल में TPM रही होंगी। Laura अब Distinguished Engineer हैं
      लगता है वे हमेशा जबरदस्त scale वाले projects करती हैं, और IPv4 अब उनमें छोटा हिस्सा है। अभी चल रहे कुछ बड़े projects अफसोस कि share नहीं कर सकता
      उन्होंने कई बार समय निकालकर समझदारी भरी सलाह दी है, जिसके लिए मैं आभारी हूं
    • अगर पुराने network hardware को कम समय में पूरी तरह replace करना बहुत बड़ा project है, तो Amazon को internal तौर पर हर जगह IPv6 support कर सकने लायक replacement पूरा होने तक short timeline में IPv4 charging push नहीं करनी चाहिए
    • इसका मतलब यह नहीं कि IPv6 का phased rollout न किया जाए। इस समस्या को हमेशा के लिए टाला नहीं जा सकता
      निश्चित रूप से उन्होंने process शुरू कर दी होगी
      है न? यह कल्पना करना मुश्किल है कि AWS सिर रेत में डालकर इसे ignore कर रहा है

  • AWS का ठीक से काम करने वाला IPv6 देना incentives के साफ तौर पर खिलाफ लगता है। AWS के influence tools, जैसे Well-Architected criteria या certifications, end-to-end addressing वाली internet-style architecture के बजाय, अस्पष्ट addresses वाले 10.x RFC1918 networks की maze बनाने की ओर जोर से धकेलते हैं
    AWS recommendations की दुनिया में “public IP address” की अवधारणा ही red flag है, और AWS ऐसे addresses को दिखाने और “mitigate” करने वाले tools भी अतिरिक्त शुल्क लेकर recommend करता है
    customers को security के नाम पर complex infrastructure बनाने में effort लगवाने से strong lock-in effect बनता है। असल में यह unnecessary complexity और address ambiguity वगैरह के जरिए security को नुकसान पहुंचाता है, फिर भी ऐसा होता है

    • Azure भी इसे पूरी तरह copy कर रहा है
      “Private Endpoints”, “Private Links”, “Service Endpoints”, “Private Resolvers”, “Virtual WAN” जैसे कितने products आ चुके हैं, गिनना मुश्किल है, और ये सब बड़े scale पर IPv4 चलाने के लिए हैं
      अगर IPv6 को ठीक से काम करने लायक बना दिया गया होता, तो ऐसे products की सचमुच एक भी जरूरत नहीं होती
      इसके बजाय Azure IPv6 को भी NAT करता है, इसलिए IPv4 की वजह से मजबूरन होने वाले NAT से बचने के लिए IPv6 भी इस्तेमाल नहीं कर सकते। 2023 में भी ऐसे नए products ला रहा है जो IPv6 support नहीं करते और आगे भी शायद नहीं करेंगे
      documentation में अभी भी limitations का पूरा एक page बचा है: https://learn.microsoft.com/en-us/azure/virtual-network/ip-s...
      अगर सोचें कि यह IPX से IPv4 पर जाने वाला transition होता, तो दिखता है कि यह कितना बेतुका है। मानो इस page पर लिखा हो “IPv4 limitations: सभी VMs में कम-से-कम एक IPX address होना चाहिए”
      अजीब नहीं लगता? 1999 में customers को IPX से IPv4 पर migrate कराया जा रहा था, और IPv6 support लगभग 2001–2003 में दिखने लगा था। दशकों बाद भी यह Novell NetWare migration से पहले के दौर जैसा लगता है, जब कहा जाता था “अभी सब कुछ IPv4 support नहीं करता, इसलिए IPX+IPv4 चाहिए”
      यह list बिल्कुल भी पूरी limitations list नहीं है। ज्यादातर PaaS products IPv6 support नहीं करते, इसलिए IaaS+PaaS solutions को आखिरकार ज्यादातर IPv4 ही इस्तेमाल करना पड़ता है
    • यह सिर्फ AWS की समस्या नहीं है। Microsoft, security auditors, penetration testers, cyber insurers आदि भी आम तौर पर publicly addressable endpoints न रखने की मांग करते हैं
      क्यों, यह समझ नहीं आता, लेकिन जब तक कोई बड़ी tech company end-to-end addressing को best practice के तौर पर push नहीं करती, red flags से बचने के लिए existing conventional wisdom ही follow करनी पड़ेगी
    • मैं Azure में काम करता हूं, और मेरे अनुभव में customers यही चाहते हैं और इसके अच्छे कारण भी हैं
      customers उन machines पर भी intrusion और data leaks रोकने के लिए अपना private network चाहते हैं जिनके वे मालिक नहीं हैं। उससे आगे, वे battery-included अच्छी तरह तैयार PaaS services को भी उस network के अंदर रखना चाहते हैं
    • मुझे यकीन नहीं कि ये दोनों related हैं। अगर AWS चाहता, तो वह IPv6 को internal network problems की रामबाण दवा के तौर पर promote कर सकता था, और अगर यह सच में काम करता तो competitors के लिए catch up करना मुश्किल होता
      मेरा अनुमान है कि वजह ज्यादा साधारण है। AWS की services की संख्या तक देखें तो IPv4 support बस ज्यादा आसान है
    • internal services तक external access रोकना security को कैसे नुकसान पहुंचाता है, यह मुझे समझ नहीं आता

  • AWS ग्राहक के तौर पर मैं IP से ही दूर जाना चाहता हूं। IP, BGP, DNS जैसे पुराने protocols से बने जटिल networking system को manage करना समय की बर्बादी है
    workloads से मजबूत पहचान जोड़ दी जाए, और policy के जरिए सिर्फ यह लागू करने दिया जाए कि कौन-सा workload किस workload के साथ data का लेन-देन कर सकता है
    data एक workload से दूसरे workload तक कैसे पहुंचता है, यह मेरी चिंता नहीं होनी चाहिए; बस वह काम कर जाना चाहिए

    • पूरी तरह सहमत। वैसे, इसी भावना की वजह से आजकल ऐसे काम करने वाले कई cloud “platforms” बन रहे हैं
      virtualized datacenter, यानी नकली networking के components zoo में फंसने के बजाय सब कुछ abstract कर देते हैं
    • यह भावना सही है, लेकिन ऐसी दलील वैसी ही लगती है जैसी लोग low-code solutions की बात करते समय देते हैं
      असल दुनिया में यह कभी ठीक से काम नहीं कर पाया और आगे भी नहीं कर सकता। वास्तविक workloads चलाने और optimize करने के लिए बहुत सारी बारीकियां और details ध्यान में रखनी पड़ती हैं
    • “बड़ा picture देखने वाले” लोग भी जब वह बड़ा picture details हल नहीं कर पाता, तो अचानक details की चिंता करने लगते हैं
    • Heroku जैसा कुछ? मैंने कई सालों से Heroku इस्तेमाल नहीं किया, इसलिए अभी उसकी स्थिति नहीं पता
    • मतलब Internet Protocol के बिना internet चाहिए?

  • AWS में IPv6-only जाने पर मेरे अनुभव में सबसे बड़ी समस्या यह है कि GitHub अभी भी IPv6 नहीं कर पाता। बहुत सारे software यह मानकर चलते हैं कि कुछ लेने के लिए वे GitHub से connect कर सकते हैं
    public NAT64 service इस्तेमाल की जा सकती है, लेकिन गंभीर use के लिए यह बहुत भरोसेमंद नहीं है: https://nat64.xyz/
    AWS NAT gateway traffic के लिए बहुत ज्यादा charge करता है, और मुझे नहीं पता कि इसे सिर्फ IPv4-only hosts की ओर जाने वाले traffic को intercept करने के लिए configure किया जा सकता है या नहीं। अगर मैं गलत हूं तो बताएं
    इसके अलावा AWS पर IPv6-only इस्तेमाल करना बिना किसी खामी के काम करता है और सस्ता भी है। private network के लिए egress gateway free है। बेशक, शर्त यह है कि आपको IPv4 की परवाह न हो

    • अफसोस है कि GitHub अपनी parent company Microsoft के IPv6 deployment की रफ्तार के साथ नहीं चल पाया
    • AWS में dual-stack network इस्तेमाल करने पर DNS में IPv6 को prefer करते हुए भी IPv4 अभी भी काम नहीं करता क्या? जिन्हें सामान्य internet egress चाहिए, उनमें से ज्यादातर चीजों को मैंने इसी तरह set कर रखा है

  • मेरे हिसाब से असली समस्या Lambda और S3 का IPv6 support न करना है, और AWS को price change करने से पहले इन्हें dual-stack बनाकर IPv6 से accessible करना चाहिए था
    technically S3 के लिए अलग dual-stack endpoint तो है, लेकिन इस change से निपटने के लिए वैसे भी application configuration बदलनी पड़ेगी, इसलिए इससे खास मदद नहीं मिलती

  • शुरुआत में ही AWS के IPv6 support में आगे होने की आधी वजह अमेरिकी सरकार की वह policy mandate है, जिसमें migration शुरू करने को कहा गया था
    cost के नजरिए से यह सही है कि नया cost बड़े customers के लिए मामूली है, लेकिन सबसे बड़े customers के policy mandates की ताकत को कम करके नहीं आंकना चाहिए। compliance के लिए अपना alternative बनाने की धमकी भर भी AWS को आखिरकार support priority बढ़ाने पर मजबूर कर सकती है

    • सही। यह विचार मुझे बहुत पसंद नहीं, लेकिन “server side” पर IPv6 को encourage करने के और तरीके अब कम ही दिखते हैं
      client, यानी end-user side, ठीक चलती दिख रही है। Google आजकल end-user IPv6 traffic को लगभग 50% बता रहा है, यह देखकर ऐसा लगता है

  • व्यक्तिगत रूप से सबसे खराब बात यह है कि CloudFront custom origins के IPv6 को support नहीं करता
    अगर आप origin के रूप में कई अलग Fargate containers चला रहे हैं, तो public IPv4 address चालू करना पड़ेगा, और जल्द ही छोटे container का cost दोगुना हो जाएगा
    Amazon को legacy IPv4 usage पर extra fee लगाने से पहले अपनी infrastructure को सच में IPv6 support कराने लायक बनाना चाहिए

    • सही। अजीब तरह से यही सबसे ज्यादा चुभता है
      मुझे पता है कि Amazon ने एक विशाल beast बना लिया है और असंख्य services में IPv6 deploy करना बहुत बड़ा काम है, लेकिन CloudFront आज ही नहीं, कल से भी IPv6 origin support क्यों नहीं कर सकता—इसकी वजह समझ नहीं आती
      तुलनात्मक रूप से यह इतना मुश्किल भी नहीं लगता, और दूसरी limitations को bypass करने का अच्छा tool भी हो सकता है
      सच कहूं तो अब तक मुझे लगता था कि Amazon के decisions आखिरकार customers के best interest को ध्यान में रखकर होते हैं, लेकिन अब ऐसा नहीं लगता। आगे के लिए यह अच्छा संकेत नहीं है

  • अगर अमेरिका में सच में ISP competition होती तो बहुत मदद मिलती
    मैं Seattle के पास suburb में किराए पर रहता हूं, फिर भी असली broadband ISP सिर्फ एक है। किसी भी definition से यह rural area नहीं है, लेकिन Comcast ही एकमात्र option है। price और service इसी reality को साफ दिखाते हैं

    • इस क्षेत्र में कानून से enforce किए गए monopoly को संभव बनाने वाली अंतहीन lobbying का शुक्रिया अदा करना चाहिए। phone companies के साथ भी यही किया गया था
      यह संयोग से “सिर्फ Comcast” नहीं है; legal regulation के कारण “सिर्फ Comcast” है
    • Comcast IPv6 support करता है। 2016 में यह 98% IPv6 support rate तक पहुंच गया था
    • consumers IPv6 को न जानते हैं, न उसकी परवाह करते हैं, इसलिए competition ISP implementation को drive नहीं कर पाएगी
      Comcast की शिकायत करना मजेदार इसलिए है कि जब मैं Comcast इस्तेमाल करता था, तब मेरे पास native IPv6 था। मेरे मौजूदा provider के पास NAT46 के जरिए ही IPv6 है
    • Starlink दूसरा option हो सकता है
      तेज बारिश में performance degradation जैसे downsides हैं, लेकिन मैंने कुछ positive reviews भी देखे हैं
    • IPv6 adoption customers को बड़े monopolies की तरफ और धकेलेगा। क्योंकि इसे reliably चलाने के लिए dedicated network engineering staff afford कर पाने वाले वही हैं
      ज्यादातर लोगों को यह पता ही नहीं कि अभी दो IPv6 internets हैं। एक Cogent वाला और एक Hurricane Electric वाला; दोनों लगभग एक जैसे बड़े हैं और एक-दूसरे से connect करने से मना करते हैं। इसलिए यह जानकर दोनों से transit खरीदना होगा, या ऐसे network से खरीदना होगा जो दोनों से transit खरीदता हो
      मेरी जानकारी में कम से कम एक बड़ा operator अभी भी tunnel के ऊपर v6 चला रहा है। कई जगहों पर v6 traffic suboptimal routes से जाता है, और enterprise networks में हर datacenter के लिए v4 connection हो सकता है, लेकिन v6 सब कुछ “Dave की desk के नीचे वाले उस box” पर भेजा जाता है
      फिर भी Google या Cloudflare जैसी जगहें, जहां packets पहुंचना सुनिश्चित करने के लिए dedicated teams हैं, v6 adoption rate नापती हैं और खुद की पीठ थपथपाती हैं

  • “IPv4 से बाहर नहीं निकल सकते” कहना सही है। IPv6-only VPC बनाया जा सकता है, लेकिन कई AWS services से लेकर package repositories तक बहुत कुछ टूट जाता है: https://blog.devopstom.com/ipv6-only-ec2/
    आखिर में या तो IPv4 चालू करना पड़ता है, या अपना NAT64 gateway खुद चलाना पड़ता है, या किसी और के चलाए NAT64 पर भरोसा करना पड़ता है: https://nat64.net और http://v4-frontend.netiter.com

  • “IPv6 में private address की अवधारणा नहीं है, इसलिए Managed NAT Gateway और उसकी भव्य pricing को अलविदा” — यह बात AWS के अंदर शायद सही हो, लेकिन IPv6 में fc00::/7 के Unique Local IPv6 addresses हैं, और अगर आपको NAT से सच में बहुत प्यार है तो NAT66 भी है

    • सही है, बात AWS के संदर्भ में थी और इसे साफ़ करना चाहिए था
      हालांकि ULA की अक्सर सिफारिश नहीं की जाती, और NAT66 तो… बस नहीं
      हाल ही में सुना कि Microsoft ने Azure के IPv6 को पूरी तरह NAT-centric बना दिया है। सच में अजीब है