[HN Gopher] India is leading IPv6 migration with 61.67% adoption
___________________________________________________________________
India is leading IPv6 migration with 61.67% adoption
Author : quaintdev
Score : 253 points
Date : 2021-08-15 13:45 UTC (9 hours ago)
(HTM) web link (www.aelius.com)
(TXT) w3m dump (www.aelius.com)
| blueblisters wrote:
| OT: does IPv6 make it easier/harder for websites to track you?
| mrweasel wrote:
| NAT is no longer a thing, all devices just have a globally
| unique IP. So your IP allow is a pretty strong indicator, it
| seems like that alone would make tracking easier.
|
| There's nothing in IPv6 to prevent tracking or offer more
| anonymity.
| rk06 wrote:
| NAT can be used in conjunction with IPv6 for security
| purposes. It is still a thing
| Dagger2 wrote:
| It was never a thing. NAT isn't security.
| tsimionescu wrote:
| How do you think NAT gives you security?
| techsupporter wrote:
| As I recall, this was seen as a concern in the early days so
| "privacy extensions" were added to the implementation
| standard for IPv6. Macintosh, Windows, iOS, and Android all
| rotate their auto-configured IPv6 addresses at a regular
| interval. It used to be a day but I think I've seen it as
| short as an hour:
| https://www.internetsociety.org/blog/2014/12/ipv6-privacy-
| ad...
| mistaken wrote:
| That's not quite true. IPv6 has privacy extensions which
| generate randomized suffixes. A website would still be able
| to track you with the common prefix. Tracking the prefix is
| more or less the same as tracking an IPv4 address. If you're
| worried about tracking than you're better off using a VPN
| than a NAT gateway (both of which is also possible with
| IPv6).
| gruez wrote:
| Assuming your ISP gives you a /64 (and not /128), easier. With
| ipv4, all the traffic coming out of your house is from one ip,
| so the ip provides household level granularity. With ipv6 each
| device has a distinct address, which means the ip provides
| device-level granularity.
| stephen_g wrote:
| That's not true, all serious devices (except maybe IoT
| crapware) implement privacy extensions, so your computers and
| devices make requests from different, randomised address
| (within your allocated subnet obviously).
| saurik wrote:
| They don't make literally every single request from a
| different address off a fully shared prefix (as if you just
| randomize the final bits but also maintain some unique
| prefix bits, you still lost), so it is still worse than
| IPv4 with NAT, _much worse_ than CGNAT, and AFAIK in most
| cases isn 't much (if at all) better than assigning
| everyone a unique sticky address.
| shakna wrote:
| IPv6 has a few extensions, that have been implemented in just
| about every OS, to make things more private. [0][1][2]
|
| To put it simply, badly implemented IPv6 makes it easier, but
| all the ways to make it on-par with IPv4 have been widely
| deployed since 2016.
|
| [0] https://datatracker.ietf.org/doc/html/rfc4941
|
| [1] https://datatracker.ietf.org/doc/html/rfc7217
|
| [2] https://datatracker.ietf.org/doc/html/rfc7721
| gruez wrote:
| >To put it simply, badly implemented IPv6 makes it easier,
| but all the ways to make it on-par with IPv4 have been widely
| deployed since 2016.
|
| Not really. According to the wikipedia article[1], you still
| have an unique address per device. It rotates daily, but you
| still can uniquely identify a device on a daily basis. This
| wouldn't be possible with ivp4 with NAT.
|
| [1] https://en.wikipedia.org/wiki/IPv6#Stateless_address_auto
| con...
| shakna wrote:
| If you read RFC7721 which I linked above, you'll find that
| "SLAAC temporary addresses" is the bare minimum (from
| 2012), but not the recommended process (over a decade
| later). And is therefore not what most platforms use today.
|
| > DHCPv6 temporary addresses have the same properties as
| SLAAC temporary addresses (see Section 4.6). On the other
| hand, the properties of DHCPv6 non-temporary addresses
| typically depend on the specific DHCPv6 server software
| being employed. Recent releases of most popular DHCPv6
| server software typically lease random addresses with a
| similar lease time as that of IPv4. Thus, these addresses
| can be considered to be "stable, semantically opaque".
| [DHCPv6-IID] specifies an algorithm that can be employed by
| DHCPv6 servers to generate "stable, semantically opaque"
| addresses. [0]
|
| The very last line of that Wikipedia paragraph points you
| to RFC8064 [1], which is a standard, and completely
| obsoletes the early "SLAAC temporary addresses", and makes
| the rest of the paragraph nothing but historical
| information. (The mention of Windows XP should stand out as
| a red flag, there.)
|
| > By default, nodes SHOULD NOT employ IPv6 address
| generation schemes that embed a stable link-layer address
| in the IID.
|
| [0]
| https://datatracker.ietf.org/doc/html/rfc7721#section-4.7
|
| [1] https://datatracker.ietf.org/doc/html/rfc8064
| gruez wrote:
| Is there a tl;dr description as to how the current
| address generation/randomization process works?
| IgorPartola wrote:
| And here I am with a brand new Frontier fiber install and not
| only do they not offer IPv6, not only do they not allow me access
| to their 6rd relays because those are "legacy" from AT&T, but
| they also fucking block protocol 41 so I can't even use a tunnel
| broker.
| ipv6_or_nat wrote:
| The interesting question is, does India have enough critical mass
| to actually launch local IPv6-only services?
|
| A large carrier could even use IPv6 as a competitive moat by
| offering/sponsoring/investing in popular local IPv6-only
| services.
|
| Competitor's customers would be locked out because they don't
| have IPv6, not because they were blocked. Kinda hard for
| competitors to cry foul to the regulator, since the only reason
| their customers can't reach the service is that they themselves
| haven't been keeping up with the times.
| [deleted]
| mritzmann wrote:
| Imagine if Google penalised websites that did not have IPV6. Then
| it would suddenly happen very quickly.
| 2fastpost wrote:
| As stated in the other thread suggesting the same, what's in it
| for Google?
| Havoc wrote:
| Not a half bad idea. Helped with ssl
| noasaservice wrote:
| The whole issue surrounding IPv4 and 6 is a racism issue.
|
| Why does India and China both have high implementations of IPv6?
| Because most of Europe and the US have all the big blocks, and
| either refuse to sell them or are actively hoarding them (like
| the real estate crisis right now).
|
| Except... Racism?
|
| Countries that US, UK, etc have invaded and camped on for decades
| or centuries are only beginning to recover. So, those countries
| got on the internet much later. And because of orgs grabbing
| every block they can, it leaves little to none for the countries
| who were late to the internet game.
|
| Is there a good reason why the DOD is hoarding 5% of ALL IP4's?
| Or had Ford (vehicle company) pivoted to tech for their 16
| million IP's? Why does Apple hold on to theirs - what are they
| doing with it?
|
| The "first world" owns the primary means of the internet, which
| leaves the "third world" with scraps. And in this case, scraps
| are the few IP4's they can get, and have to make do with IP6,
| with its 2^128 IP space.
|
| But, I think the worst insult, is all the 'first world' services
| as posted by quaintdev (google.co.in amazon.in paytm.com
| twitter.com flipkart.com hotstar.com primevideo.com) that plainly
| aren't accessable without using the 'first world internet' aka
| IPv4.
|
| Theres only enough of these coincidences that line up, before I
| believe that there's something more sinister going on. And
| keeping 'those people' away from the IPv4 euro-centric network is
| I believe the primary intent... AWS/GCE/Azure here in the States
| has never had an IPv4 allocation problem with machines I build.
| Hmm.
| ajaimk wrote:
| The main reason for this is Jio, a new mobile phone network that
| began in 2010s. They built a 4G only network (not 5G) and used
| IPv6 from day 1 for their phones. Reference:
| https://conference.apnic.net/50/assets/files/APCS790/Harness...
| [deleted]
| [deleted]
| john_moscow wrote:
| The problem with IPv6 is the yield curve. Adopting IPv6 currently
| yields you some good PR, extra maintenance costs from
| troubleshooting minor compatibility problems right now, and a
| great advantage of not losing IPv6-only customers at some distant
| time in the future, when IPv6-only hosts become a thing.
|
| So, from a business perspective, the optimal strategy is to delay
| the transition (and the ongoing maintenance costs) until
| IPv6-only customers become a quantifiable number (e.g. you could
| say that in 5 years about 5-10% of your target audience would not
| have IPv4, so switching to IPv6 would increase your sales by X%).
| You can't blame businesses for doing that. You don't play by
| these rules, you end up one of those companies blogging how they
| are forced to shut down despite having a marvelous and very
| sophisticated product.
|
| That said, you can change it very easily. Just offer IPv6 traffic
| at a slightly lower rate than IPv4. So every IPv6 packet costs
| you less than the IPv4 one. For unlimited connections, offer some
| rebate based on the fraction of IPv6 packets, or something. This
| will immediately put the incentives in the right places and the
| switch will happen at exponential rate.
| ipv6_or_nat wrote:
| >That said, you can change it very easily. Just offer IPv6
| traffic at a slightly lower rate than IPv4.
|
| How many cents per month will make you or anybody care?
|
| ISPs don't even pay for the majority of their bandwidth, they
| get it for free via settlement free peering. Where's the rebate
| going to come from that?
|
| On the fraction of bandwidth ISPs pay for, the wholesale rates
| are less than 5 cents per Mbps. On average a subscriber uses a
| few Mbps on average.
|
| Would 15 cents per month really motivate you to go all in on
| IPv6?
|
| On average bandwidth costs for an ISP are single digit
| percentages or less of all costs. Even if their wholesalers
| would fully discount _all_ their IPv6 traffic (why would they
| do that?!) there's only so much there to work with.
| [deleted]
| faraaz98 wrote:
| With the amount of people coming online, India also probably
| needs it the most
| thrower123 wrote:
| They don't have giant DARPA allocated IP4 blocks handed out for
| free to companies and universities in the early days of the
| internet either.
| newsclues wrote:
| How does China manage?
| patchtopic wrote:
| they are trying to catch up:
|
| https://www.scmp.com/tech/policy/article/3143180/china-
| hatch...
| ipv6_or_nat wrote:
| Layers upon layers of NAT from what I hear.
| zahrc wrote:
| Exactly. And as a developing country, they (hard guess) do not
| have the widespread pre-existing infrastructure like developed
| countries; and therefore can easier to adopt to it.
|
| Another factor - mobile has a way greater market share in
| India, than mobile has in Europe. It's easier to enforce IPv6
| as a mobile carrier
|
| (https://gs.statcounter.com/platform-market-share/desktop-
| mob...)
| KoftaBob wrote:
| Any particular reason China's adoption rate is so low?
| Sayrus wrote:
| A few years ago, IPv6 in China was reserved to universities and
| it bypassed the golden shield (at least censorship, added
| packet loss on long-running connections, added latency, ...).
|
| 2.28% is already impressive if the situation is still the same
| nowadays.
| khuey wrote:
| They use massive amounts of NAT instead AIUI.
| thaumasiotes wrote:
| > India is leading IPv6 migration with 61.67% adoption
|
| This data doesn't show that at all. It's based on traffic to
| Google. According to this, IPv6 adoption in China is just over
| 2%.
|
| Which of course has absolutely nothing to do with reality.
| riobard wrote:
| True. All three major mobile carriers in mainland China have
| deployed Dual Stack. And the government is pushing for
| IPv6-only stack by 2030, with pilot starting as early as 2025.
| tumblewit wrote:
| I think the most obvious factor here is the mobile networks. I
| have two fiber ISPs and neither have IPv6 support for consumers.
| tsjq wrote:
| mainly Jio :)
| pragnesh wrote:
| jio effect
| hannob wrote:
| If anything this message says something about the abysmal state
| of IPv6.
|
| Ultimately the goal of IPv6 is to end IP scarcity. But it can
| only do this if close to 100% of users and services use IPv6.
| Seeing it like that it doesn't really matter much if IPv6
| adoption is 30% or 60% or 90%. In none of these situations would
| an ISP connect its customers via IPv6 only or would anyone
| provide any service that requires IPv6.
|
| I really wonder how IPv6 should ever become mainstream without
| any deployment strategy. "Let's tell everyone that IPv6 is nice
| and we need it due to lack of v4 addresses" obviously hasn't
| worked for more than 20 years.
| betterunix2 wrote:
| "Ultimately the goal of IPv6 is to end IP scarcity"
|
| That is _a_ goal, and perhaps the primary goal, but there are
| other goals as well. IPv6 makes the Internet itself more
| efficient by reducing routing overhead and it simplifies
| network management.
|
| Of course, what will ultimately force ISPs and services to
| switch to IPv6 is IPv4 address space exhaustion. As the price
| of a public IPv4 address rises people will begin to more
| seriously consider an IPv6-only approach, even if it means
| losing a few users (especially since ISPs will have to make
| IPv6 available once such services become popular). It has taken
| longer than expected as various approaches have squeezed the
| last bits of utility out of IPv4, but it will eventually happen
| as several billion more people are connected to the Internet.
| [deleted]
| tialaramex wrote:
| > In none of these situations would an ISP connect its
| customers via IPv6 only or would anyone provide any service
| that requires IPv6.
|
| It's _so much cheaper and faster_ already today that it makes
| sense to do v6-only internally and deliver IPv6 to the large
| fraction of customers who can have IPv6 and deploy a transform
| layer for the (gradually shrinking) class of have-nots.
|
| Your IPv4-only competitors are spending more money to deliver a
| worse service. Maybe they'll wake up and realise, but the story
| of the past couple of decades suggests most such outfits are
| not too bright and when offered IPv6 on new links they'll
| smugly decline. Meanwhile you get to keep the difference. Your
| competitor thinks this service costs 86C/ per dollar revenue
| and you're only spending 84C/ per dollar revenue that's a _lot_
| of extra profitability.
|
| Fighting this is a losing battle, and I imagine that decades
| from now somebody is going to write a book about how it was
| cognitively possible for "leaders" to champion an idea that
| couldn't possibly work, that they intellectually _knew_ couldn
| 't work, and all the actual evidence said wasn't working, and
| yet they believed in it anyway. Or that book might be about
| climate change denial, either way.
|
| Eventually by the way - and 90% global is close to and even
| perhaps at the threshold where that's plausible for some of
| them - many general ISPs won't bother providing actual IPv4
| networking. If you want IPv4 you're a niche customer, go find a
| bespoke IPv4 Internet Service Provider. If you're IPv6 capable
| but you want to reach an IPv4 host you'll go via a translation
| box automatically. As the interest in global IPv4 shrinks, the
| transit companies will lose interest in that service too, and
| eventually - decades from now - the IPv4 Internet literally
| goes away, the RIRs stop "managing" the now largely unused
| space and the residual pockets of IPv4 cease to interoperate.
| goodpoint wrote:
| > It's so much cheaper and faster already today that it makes
| sense to do v6-only internally
|
| Absolutely not. Routers, OSes and applications still have
| much better support for IPv4 than IPv6.
|
| Replacing large routers, fighting bugs and running pure IPv6
| on internal networks is very expensive.
| fulafel wrote:
| There haven't been ipv4-only routers sold in such a long
| time that they've been retired from service by now. v6 was
| a new router feature something like 15 or 20 years ago (and
| same for operating systems).
| goodpoint wrote:
| As 2fastpost wrote, basic IPv6 support is far from
| enough.
|
| Also I'm not talking about routers worth 50 euro/$, but
| DC and carrier grade, worth 500K euro/$
| 2fastpost wrote:
| IPv6 support is such a low bar. Now try IPv6 support
| _and_ feature complete without bugs and get back to me.
| I'll wait.
| ipv6_or_nat wrote:
| Can we have source to go with the IPv6 is "cheaper and
| faster" claim? Like actual facts stated in dollars and
| milliseconds.
|
| I'm also going to humor you on the IPv6-only thing. Can you
| actually point to a _single_ ISP that is even _considering_
| IPv6-only?
| tialaramex wrote:
| What did we read right here on HN recently about IP blocks
| changing hands for about $40 per address? IPv6 addresses
| are approximately 100% cheaper than that.
|
| But it doesn't stop there, you also no longer need subnet
| planning -- where under IPv4 it's very important whether
| this new subnet is 60 machines or 64 machines, in IPv6 you
| don't care and so nobody needs to manage that. Which
| translates to lower costs in your network team. Negligible
| when your "network team" is just the CTO doing a Google
| search, but significant at scale.
|
| Your route costs fall too. Because of exhaustion (and
| because years ago nobody had any idea what they were doing,
| not having had an Internet before) IPv4 is now badly
| fragmented, which means a trivial route ("All the East
| Coast stuff") may become six or sixteen or sixty separate
| address blocks, but IPv6 blocks were deliberately assigned
| so as to reduce fragmentation, chances are "All the East
| Coast stuff" is one or two blocks.
|
| As to speed, Facebook reports IPv6 is about 10% faster for
| them.
|
| They did exactly what I described, they're v6-only
| internally and have translation at the edge for "legacy"
| IPv4 clients.
| 2fastpost wrote:
| > What did we read right here on HN recently about IP
| blocks changing hands for about $40 per address? IPv6
| addresses are approximately 100% cheaper than that.
|
| This is just silly. If you are an ISP then you already
| have an IPv4 allocation.
|
| If you don't then you join the waiting list and/or apply
| for a /24.
|
| Once you have your allocation, RIR fees are the same
| regardless of IPv4 or IPv6 allocations.
|
| > But it doesn't stop there, you also no longer need
| subnet planning -- where under IPv4 it's very important
| whether this new subnet is 60 machines or 64 machines, in
| IPv6 you don't care and so nobody needs to manage that.
| Which translates to lower costs in your network team.
| Negligible when your "network team" is just the CTO doing
| a Google search, but significant at scale.
|
| If you believe this is in any way meaningful then I have
| a bridge to sell you.
|
| > Your route costs fall too. Because of exhaustion (and
| because years ago nobody had any idea what they were
| doing, not having had an Internet before) IPv4 is now
| badly fragmented, which means a trivial route ("All the
| East Coast stuff") may become six or sixteen or sixty
| separate address blocks, but IPv6 blocks were
| deliberately assigned so as to reduce fragmentation,
| chances are "All the East Coast stuff" is one or two
| blocks.
|
| You can't buy smaller routers just because you deploy
| IPv6, so I have no idea what cost saving there are to be
| had here.
|
| > As to speed, Facebook reports IPv6 is about 10% faster
| for them.
|
| I fail to see how this is universally applicable to all
| ISPs.
|
| > They did exactly what I described, they're v6-only
| internally and have translation at the edge for "legacy"
| IPv4 clients.
|
| Having an IPv6 core is not the same thing as being
| IPv6-only.
|
| Speaking of IPv6-only, you have yet to name even a
| _single_ ISP that is even _considering_ going IPv6-only.
| Cat got your tongue?
| tialaramex wrote:
| I think the main thrust of your objection is that you
| believe I was claiming this makes sense for _any ISP_
| when I was instead saying it makes sense for _lots of
| companies providing services on the Internet_
|
| Still, while we're here:
|
| > This is just silly. If you are an ISP then you already
| have an IPv4 allocation.
|
| Due to exhaustion in fact you can't get new allocations
| _in IPv4_ in most of the developed world. If you want to
| expand, you 're going to need to buy addresses on the
| open market for that sort of $40 price we talked about.
|
| > ... Once you have your allocation, RIR fees are the
| same regardless of IPv4 or IPv6 allocations.
|
| Nope. Let's take ARIN, suppose you're a large
| international company, hundreds of local corporate
| networks. With IPv4 this is quite a struggle, _maybe_ you
| can get away with a /17 for which ARIN will charge you
| $4000 per year.
|
| But with IPv6 this is easy, you'll qualify for their
| "3X-small" category with a /40 at only $250 per year,
| even if you choose a relatively wasteful address layout.
|
| It gets worse! Unless you already had that /17 from years
| ago, chances are you had to cobble the addresses together
| from several distinct allocations. ARIN charges $150 per
| block aggregated in this way, if you need a dozen blocks
| that's $1800 extra because of the fragmentation. In
| contrast IPv6 isn't fragmented, it was deliberately
| allocated sparsely so it's easy to give you adjacent
| blocks to grow. Not that they'll need to when you're just
| an international company with a few hundred sub-networks,
| IPv6 is so wide.
| DanAtC wrote:
| RE: v6-only ISP, there's this crazy story that came up last
| IPv6 article: https://old.reddit.com/r/ipv6/comments/n5y5oo
| /update_on_not_...
| 2fastpost wrote:
| Most likely fake. Posted from a throwaway account with no
| posting history before or since. ISP not named, no
| details given, no proof.
| throw0101a wrote:
| AFAICT, IPv4 addresses are currently going for about US$ 40/IP.
| At some point if ISPs run out of addresses and need more, it
| may be cheaper to simply implement IPv6 with a one-time, up-
| front project than having to go back to the well/market for
| more IPv4 blocks.
|
| Similarly for hosting providers: as IPv4 addresses get more
| expensive, they may have to start charging their customers more
| and more for each one, at which point the customers may simply
| go only-/mostly-IPv6.
| hannob wrote:
| That's not how it works.
|
| A single ISP can't do anything about the situation. They can
| provide IPv6 to their customers, but they still need IPv4 so
| their customers so they have a usable internet connection. It
| doesn't help them at all.
|
| Which is part of the problem here: As long as IPv6 is not
| implemented by everybody the people who do implement it have
| no advantage.
| throw0101a wrote:
| An ISP probably already has IPv4 addresses, but needs more
| addresses for basic connectivity. They can become IPv6-only
| and then use their IPv4 block/s for CGNAT. The money would
| go to either buying more addresses or more CGNAT.
|
| This is how a lot of mobile/cell telcos already work. A
| T-Mobile presentation from 2018 (PDF):
|
| * https://pc.nanog.org/static/published/meetings/NANOG73/16
| 45/...
| ipv6_or_nat wrote:
| Running an IPv6 core and offering IPv4-as-a-service
| doesn't really make you IPv6-only.
| throw0101a wrote:
| I'm not sure what you're referring to.
|
| Here's a dude from T-Mobile explaining how they have (in
| 2017) over ten million end-customer devices without any
| IPv4 addresses assigned:
|
| * https://www.youtube.com/watch?v=nNMNglk_CvE
|
| For reaching services that are IPv6 only they use(d)
| DNS64 (with and without 464XLAT).
| ipv6_or_nat wrote:
| The problem with the above is that it isn't a viable
| solution.
|
| You cannot just deploy IPv6, take your IPv4 ball and go home.
|
| ISPs will still need those IPv4 addresses, no matter how much
| they cost. ISPs may delay by deploying CGNAT, but once those
| IPv4 addresses run out there is no other option than to get
| out your checkbook or scale back your business.
|
| Likewise with hosters. There is no choice but to use IPv4,
| damn the cost. It simply isn't viable to go IPv6-only, as
| IPv4 is where the money/customers are.
|
| This will not change until IPV6 somehow reaches critical
| mass.
| throw0101a wrote:
| > _ISPs will still need those IPv4 addresses, no matter how
| much they cost. ISPs may delay by deploying CGNAT, but once
| those IPv4 addresses run out there is no other option than
| to get out your checkbook or scale back your business._
|
| Yes, that's what I'm saying. At some point going IPv6-only
| and paying for (CG)NAT64 may be cheaper than trying to buy
| more and more IPv4 addresses. ISPs would already have IPv4
| addresses, but they'd simply use them for reaching the
| 'legacy' Internet, and they wouldn't be assigned to
| people's routers WAN interface.
|
| > _Likewise with hosters. There is no choice but to use
| IPv4, damn the cost._
|
| It will probably not be the hosting company paying for the
| IPv4, but rather it will be the end customer, and they may
| not want to pay.
|
| The first address _may_ be free, but if you want multiple,
| then you could be charged for the 'extra' ones. Depending
| on the number of public services needed, some people may
| find it cheaper to use the IPv4 address(es) on the front-
| end of a load balancer and have their actual system be
| IPv6.
| ipv6_or_nat wrote:
| You are confusing IPv6-only and running an IPv6 core.
| Those are not equivalent.
|
| >It will probably not be the hosting company paying for
| the IPv4, but rather it will be the end customer, and
| they may not want to pay.
|
| Of coarse it will be the hosting company paying for the
| IPv4 addresses as they will be the ones owning them.
|
| Of coarse the end customers will complain and not want to
| pay, but pay they will as they have no other choice.
|
| It's neither here nor there whether the end customers run
| IPv4 or IPv6 internally, it's the public IPv4 addresses
| that matter.
| xony wrote:
| fake news
| quaintdev wrote:
| It's crazy that major web sites still do not support IPv6.
|
| https://www.amazon.in
|
| https://www.paytm.com
|
| https://twitter.com
|
| https://www.flipkart.com
|
| https://www.hotstar.com
|
| https://www.primevideo.com
|
| https://news.ycombinator.com
|
| https://www.reddit.com
|
| Edit: Removed google.co.in, the website[1] reported it that it
| does not support ipv6, Now I tried again and google is in green.
|
| [1] https://ipv6-test.com/validate.php
| distalx wrote:
| ELI5: Why does IPv6 adoption matter? What would happen if these
| sites don't migrate to IPv6?
| darzu wrote:
| From a game developer/player perspective: there's a crazy
| amount of complexity in connecting between two computers that
| wouldn't need to be there in an ipv6 world. See all the NAT,
| TURN, STUN nonsense that webrtc has to deal with:
| https://developer.mozilla.org/en-
| US/docs/Web/API/WebRTC_API/... Today to use webrtc, u need a
| neutral server to help establish the connection like PeerJS
| does. This wouldn't be needed in an ipv6 world. It's nearly
| impossible to do pure peer to peer connections today.
| nsizx wrote:
| Letting machines connect directly to each other in any
| context, and especially in the context of an online game,
| is a massive security and privacy risk.
| rjsw wrote:
| You can (and should) still have a firewall that only
| allows connections to specific ports when using IPv6.
| nsizx wrote:
| Still you are revealing your IP address to the other
| parties, which will be more than happy to DoS you to
| force you to disconnect, exploit 0-days in the game
| networking code to crash your game or get your private
| info, know where you are located by IP geolocation...
|
| The idea of P2P in competitive videogames strikes me as
| absolutely insane
| ClumsyPilot wrote:
| "The idea of P2P in competitive videogames strikes me as
| absolutely insane"
|
| What's insane, is the idea that you want me to use and
| pay for some crappy AWS server that spies on my data
| instead of directly connecting to my friend using my own
| equipment
| onei wrote:
| When using NAT, you're revealing the IP address of your
| router. I don't know about you, but I don't have so many
| devices running on my home network that would drown out
| what I'm doing.
|
| With NAT, you can still receive DoS attacks, still have
| your game networking exploited, and still be geolocated.
| The only remotely security-related benefit is that
| instead of your ports being exposed to the wild internet,
| they're exposed to your router which is more of a side-
| effect rather than an actual benefit. Its not a reason to
| not bother having a firewall.
| nsizx wrote:
| I didn't mention NAT at all. Practically all multiplayer
| games use a central server. It's impossible to know the
| IP addresses of your peers.
| billytetrud wrote:
| Nothing about IPv6 prevents continuing to do that when it
| makes sense (eg to prevent cheaters from dosing their
| opponents).
| kibwen wrote:
| When it comes to DoS or geolocation, attackers can just
| as easily work with your router's address.
| kaliszad wrote:
| Well, have fun guessing 2^64 possibilities. YouTube lists
| even private videos "secured" using 11 BASE64 characters
| (66 bits in theory, but they seem to use just 64 bits).
| You can watch Tom Scott explain it:
| https://www.youtube.com/watch?v=gocwRvLhDf8
|
| CG-NAT doesn't really prevent geolocation. Better
| services will still pin-point you to the nearest city.
| There are perhaps easier ways to get your private info or
| your money - phishing and ransomware seem to be still
| very popular. Don't have to hack games that only
| relatively few people have. It is more profitable to
| attack a bigger market or more wealthy institutions or
| companies in foreign countries. Also, if you hack the
| central game server, you will have a lot more victims...
| Choose your poison.
|
| I guess, there are no games or other software that cannot
| be audited in high security installations. At home,
| having a work computer and a game computer (or a VM with
| GPU pass through or whatever) might be a safer choice in
| any case independent of IPv4 or IPv6 usage or the quality
| of your firewall.
| josephcsible wrote:
| Getting rid of NAT doesn't mean that you have to let
| every machine connect to every other machine. It just
| means that if you choose to let machines connect, they
| can do so without their packets needing to be rewritten.
| anthropodie wrote:
| No. Please stop spreading this nonsense that NAT is
| solution for security and privacy. NAT was solution for
| getting systems online without increasing address space.
| It served that well. Now it needs to die.
|
| If you have security issues that is because you failed to
| configure your firewall properly. Besides Internet was
| always supposed to work the way IPv6 would allow.
| nsizx wrote:
| I didn't mention NAT. I'm comparing direct connections
| between peers with using a centralised server.
| ClumsyPilot wrote:
| Enjoy playing an online shooter with extra 200ms of
| delay, or crappy calls on Teams where massive delay
| causes you to interrupt each other
| nsizx wrote:
| I play counter strike with a delay of around 10 ms with
| servers that are hosted hundreds of kilometres away.
| billytetrud wrote:
| You mean without? Well you're wrong. It's not a security
| concern at all. Allowing anyone from the outside to
| connect to any port they want is a security concern,
| simply because there's a lot of insecure software people
| run that doesn't account for malicious connections.
| However, allowing a user to intentionally let a piece of
| software listen for outside connections is in no way
| insecure.
| oefrha wrote:
| > However, allowing a user to intentionally let a piece
| of software listen for outside connections is in no way
| insecure.
|
| It is. Considering the kernel access often given to
| multiplayer games for anti cheat, and the abysmal
| attention to security and ability to write secure code by
| the average application developer, letting Internet
| randos send arbitrary instructions directly to your
| machine may not be the best idea.
| kortilla wrote:
| > However, allowing a user to intentionally let a piece
| of software listen for outside connections is in no way
| insecure.
|
| Unless you care about security of course. "A user" in
| your sentence can quite frequently be vulnerable or
| malicious software.
| kortilla wrote:
| It's not nonsense though. The implementation of NAT
| literally implies a stateful firewall.
|
| I want ipv4 dead as well but to bury your head in the
| sand and pretend NAT doesn't offer the protections it
| does only hurts your argument.
|
| > Besides Internet was always supposed to work the way
| IPv6 would allow.
|
| Yep, but the real world - where all of the unpatched IoT
| devices are running - has NAT at basically every home
| protecting devices from unsolicited connections.
| linksnapzz wrote:
| "Beware of appeals to the 'real world'; and to what it
| supposedly demands. It is always an invitation to leave
| unchallenged the speaker's tacit assumptions."
| 10000truths wrote:
| NAT doesn't imply stateful firewall at all. NAT is
| literally just rewriting IP addresses on
| incoming/outgoing packets. I could have a single machine
| behind a middlebox, and the middlebox could just rewrite
| the IP source/destination of egress/ingress packets, and
| that would be NAT - and I'd still be able to successfully
| receive incoming packets from the big bad web. In fact,
| you can do this without the middlebox using an iptables
| MASQUERADE rule.
|
| But even then, the added security of a stateful firewall
| as provided by a router is dubious. You know what else
| has a "stateful firewall"? Your kernel's TCP/IP stack. It
| isn't gonna accept random connections from the Internet
| unless there is an application actively listening to a
| port and accepting packets. And I trust the Linux/NT/BSD
| kernel to be more secure with ensuring that than a binary
| firmware blob from a router manufacturer.
| supertrope wrote:
| NAT is not security. If some people need a relay because
| gamers commit harassment that can used on top of IPv6.
| Everyone else can connect directly to lower latency.
|
| https://help.steampowered.com/en/faqs/view/1433-AD20-F11D
| -B7...
| toast0 wrote:
| NAT and especially CGNAT has a tendancy to cause problems.
|
| I vividly recall an incident where Jio's CGNAT was dropping
| idle TCP connections after 10 seconds of idle. (They fixed
| it, but I don't know if they fixed it for all destinations or
| only special destinations).
|
| And, of course, I say dropping, rather than closing, because
| NAT usually doesn't send FINs to close sessions when they're
| dropped. So you only find out when you try to send more data.
| Some NATs don't even send RST when you send data on a
| connection it dropped, so you have to wait for a timeout.
|
| There's also a capacity issue. If you're serving your website
| via a single IP (common with load balancers), you can only
| have 65535 connections from each client IP (assuming https on
| port 443 only, using non default ports is often a non-
| starter); if the user's ISP is sharing a very limited pool of
| IPs with a large number of users, it's conceivable that all
| the connections to your site could fill up.
| kortilla wrote:
| > if the user's ISP is sharing a very limited pool of IPs
| with a large number of users, it's conceivable that all the
| connections to your site could fill up.
|
| Unless each of your users is establishing 600 connections
| to your site, this isn't a realistic issue. I don't know of
| ISPs that go beyond 1000:1 over-subscription.
| [deleted]
| TchoBeer wrote:
| We eventually run out of IPv4 addresses and have to switch
| anyway
| zinekeller wrote:
| That doesn't work as an explanation.
|
| NAT was developed. CGNAT was developed. HTTP Host
| differentiation was developed. SNI was developed. STUN was
| developed. TURN was developed.
|
| The main problem with IPv4 to IPv6 migration is the,
| frankly, overzealous utopia that "they will migrate
| anyway". Worse, it's very different that doesn't allow for
| a simple upgrade option of "IPv4, but longer addresses"
| because IPv6 is designed to be fundamentally different.
|
| Which is more insulting considering that BGP was seamlessly
| upgraded from 65536 ASes to more than a million because
| they only changed the bits in an AS and nothing more. As a
| router developer, you only need to do the relatively minute
| changes of extended ASes than the (relative) mess that is
| IPv6.
| wbl wrote:
| IPv6 implementations are everywhere so the extra changes
| don't really impact networks.
| zinekeller wrote:
| Regardless of monentary charges (and I'm very aware of
| them, APNIC is even considering grants to help in IPv6
| because it's in limbo for so long), even if we activate
| IPv6 synchronously there's still many, many problems with
| it, even when you permanently dual-stack it.
|
| One is connectivity. Even theoretically we should have
| the same network connectivity (so to speak), you can feel
| the pettiness when Hurricane-Electric and Cogent fought
| exclusively on IPv6 (https://www.theregister.com/2018/08/
| 28/ipv6_peering_squabble...) I can't believe I'm saying
| this, but IPv6 isn't free (or at least costs the same as
| IPv4).
|
| Second is security. Yes, the world is no longer
| scannable, but consumer routers are a dud when it comes
| to IPv6 security. This router
| (https://pierrekim.github.io/blog/2021-01-12-fiberhome-
| ont-0d...) has _serious_ problems at IPv6 security, and
| because it 's suffix is always at ::0000:0000:0000:0001
| and you've eliminate around 18 bits more because of how
| networks are laid, you've got yourself an IPv6 botnet,
| which speaking by, how do you block them? A /64 would be
| a good start, but OVH provides a single address per
| server (https://www.ovhcloud.com/vps/compare/). That's
| it. Don't forget that fiasco with MAC addresses
| (https://datatracker.ietf.org/doc/html/rfc8981), but at
| least that's solved.
|
| Third, IPv6 should just work as you said. I wish that's
| true, but embedded devices will trip you up badly. Some
| don't fallback to IPv4 and instead try and try again
| using IPv6. This would be a concern while transitioning,
| but even after that, some would be still stuck because
| their servers are only operating on IPv4!
|
| Implementing IPv6 is not free lunch if you know the
| gritty details.
| ikiris wrote:
| tell me you're bad at math without telling me you're bad
| at math.
| pixl97 wrote:
| >NAT was developed. CGNAT was developed. HTTP Host
| differentiation was developed. SNI was developed. STUN
| was developed. TURN was developed
|
| And every one of those has introduced its own security
| flaws and implementation bugs increasing the complexity
| of applications.
| zinekeller wrote:
| I'm advocating and helping networks to migrate to IPv6,
| but I'll say that IPv6 was rather a rats-nest design that
| shot itself in the foot. It's elegant sure, but as
| Torvalds would say to critics about his frequent use of
| goto, it's theoretically good but not sound engineering
| practice.
|
| The thing is we would be addressing in 128-bit IP already
| _if_ it was done the BGP way: just minimising the
| necessary changes to implement it. Look at the
| effectiveness of Itanium versus AMD64 at migrating
| customers: IPv6 feels like Itanium, while extended ASes
| work more like AMD64. Whoever designed IPv6 was focused
| too much at the theoreticals, than looking at what the
| real world is and then designing around it.
| ksec wrote:
| Do we have anything for IPv4 similar to AMD64?
|
| Or are we forever stuck with either going all in to IPv6
| or the current hybrid?
| zinekeller wrote:
| Nope, but we're deep in IPv6 anyways so the best course
| of action is to finish that, just be careful of the
| pitfalls and not devolving into silliness like this
| peering fight: https://www.theregister.com/2018/08/28/ipv
| 6_peering_squabble...
| neurostimulant wrote:
| And now the internet got worse because you're no longer
| have technical freedom due to these NAT popping up
| everywhere. For example, previously if you want to
| release a video/voice chat app, you just release it and
| be done with it. Now it won't work like that due to NAT,
| so you'll have to maintain some STUN and TURN servers
| just to make your app usable to general public. Think
| about how many potential innovation got stifled because
| of added costs and complexity turned some people away
| before they even started.
| Sunspark wrote:
| I agree. It makes things much harder than it should be.
|
| I wanted to try installing the module into my router so
| it would pass the WebRTC test for STUN/TURN and perhaps
| make video even more efficient to allow point to point
| connection instead of having everything be relayed
| through a tertiary server, but there was no documentation
| and having never set up a STUN/TURN server before I
| couldn't get it to work. So I am dependent on what a
| third party has set up to facilitate connectivity.
|
| In the old days, you'd just connect to an IP address and
| that was it.
| throw0101a wrote:
| Because there are 'only' 2^32, roughly four billion, IPv4
| addresses. There are also over eight billion people on this
| planet, and many of them have multiple computers
| (smartphones, tablets, laptops, desktops, etc).
|
| As a 'temporary' measure, Network Address Translation (NAT)
| was introduced so people could get one public IPv4 address
| and have multiple machines on the Internet behind it.
|
| The trade-off was the machines behind the NAT mechanism
| couldn't be reached from the Internet. This isn't a big deal
| for _most_ consumption-based computing (fetching mail,
| watching videos), but there are use cases where you want to
| be able to talk to the other system, so yet another set of
| technologies had to be invented to allow punching holes
| through NAT (UPnP, NAT-PMP, PCP, STUN).
|
| But we're at the point in some place where there aren't even
| enough IPv4 addresses to give to ISP customers _even if_ they
| 're using NAT. So you have a private IP address for your home
| system, and then your router gets a _private IP_ address on
| its "public" WAN connection, and you end up going _two
| layers_ of NAT. There is an entire segment of IPv4 addresses
| (100.64.0.0 /10) reserved for telco use and doubel-NATing:
|
| * https://en.wikipedia.org/wiki/Private_network#Dedicated_spa
| c...
|
| * https://en.wikipedia.org/wiki/IPv4_shared_address_space
|
| We can continue this NAT-upon-NAT(-upon-NAT) silliness, or we
| can simply make the up-front investment and start pushing out
| IPv6 in more places. Your router still provides firewall
| protection, but reachability is a lot more straight-forward
| because the (potentially double) address translation goes
| away.
|
| Edit: fix a bunch of typos.
| osrec wrote:
| In your first line, I guess you mean to say ipv4 not ipv6.
| ugjka wrote:
| there's also NAT64, 464XLAT that do ipv6 to ipv4 sorcery
| throw0101a wrote:
| Beyond an ELI5, but correct.
|
| If you are on an IPv4-only or IPv6-only network, you can
| reach the other through various mechanisms.
|
| A lot of mobile/cell networks are IPv6-only, and so the
| telcos need a way to allow clients to reach IPv4-only
| systems.
| WanderPanda wrote:
| > NAT-upon-NAT(-upon-NAT)
|
| But there is also a fundamental limit of 2^16 = 65536
| concurrent connections, right?
| 2fastpost wrote:
| Yes, from one NAT IP using the same protocol to a single
| public IP using a particular port. Change any of those
| and you can do 2^16 concurrent connections more per
| change.
|
| In other words, NAT works on the five-tuple of: protocol,
| source IP, source port, destination IP and destination
| port.
| swsieber wrote:
| Playing Nintendo Switch online doesn't work if you're
| double NAT'd unless you go through some router hoops. It
| seems small, but it's quite aggravating if you're not tech
| oriented like the majority of the people on this forum.
| TuringNYC wrote:
| Totally silly question, but isn't the NAT-upon-NAT(-upon-
| NAT) a bit of protection in the sense of additional
| privacy, and hence a good thing? Doesn't this mean the
| website cannot directly tie back an incognito user back to
| a specific IP but instead to just a pool?
| kortilla wrote:
| ISPs log all of the translations and can reverse a
| (public IP, source port, time stamp) tuple to the user.
| wolverine876 wrote:
| > ISPs log all of the translations
|
| On my personal router?
| vetinari wrote:
| They don't need that much granularity; it is enough to
| being able to point fingers at someone responsible.
|
| But otherwise, it is possible to enumerate devices behind
| NAT (obviously, only those that communicate with the
| world in front of NAT) and assign traffic to them.
| snovv_crash wrote:
| For a purely "consumer" internet, yes. But I'd like to
| think that at some point we move back to a more
| decentralised model, where addressibility in more
| contexts than a response to a request become important
| again. To some degree the NAT issues have even killed a
| lot of this, making P2P more difficult and unreliable
| than would be otherwise.
| kaliszad wrote:
| Depends, but really IPv6 and IPv4 seems to be more or
| less comparable in practice. If you use an app with a
| login, you are basically screwed anyway. Even on a random
| website, you can be reliably fingerprinted:
| https://amiunique.org/
| Saris wrote:
| Yes, but you could also randomize your IPv6 address
| constantly too.
|
| Downside of CGNAT and NAT at home is difficulty of
| getting some services to work, or hosting a server.
| beerandt wrote:
| It still boils down to everyone gets an identifying
| number, whether it's an ipv4 address or an ipv6 block.
|
| Any randomized ipv6 address from that block is still as
| "unique" an identifier as an ipv4 address.
| rollcat wrote:
| Also, creating/using P2P applications. I needed to look
| up UDP hole punching and now I wish I hadn't.
| r3muxd wrote:
| out of curiosity, what did you end up going with? I had
| to host a UDP game server recently and couldn't find a
| good solution. If only ngrok supported UDP...
| ClumsyPilot wrote:
| "a bit of protection in the sense of additional privacy,
| and hence a good thing?"
|
| The more dysfunctional is your internet connection, the
| more prova you youve got
| tsaoutourpants wrote:
| > But we're at the point in some place where there aren't
| even enough IPv4 addresses to give to ISP customers even if
| they're using NAT.
|
| Er, that's a slight exaggeration. It's not uncommon to have
| 2,000 or more NAT clients behind a single public IP
| address. 2K * 4B = 8 trillion possible hosts... about 1,000
| hosts per living person.
| kaliszad wrote:
| Well, it has limits. You can hide 2000 people behind an
| address but they might have sporadic connection issues,
| long held connections such as SSH sessions will be very
| annoying to support [0] or the users will have to resort
| to frequent keepalives to make it work regardless, which
| produces more traffic to destinations you probably don't
| have in a cache. In some jurisdictions you have to log
| which customer used what IP (and port) at which point.
| You can do static assignments but you will have customers
| (customer homes, e.g. family with perhaps 10 devices or
| so could be realistic) for which 1000 ports just will not
| be enough do you will have to dynamically assign spare
| ports and log those. You might also get more support
| calls, because the NAT is dropping connections to
| radically in a peak e.g. a soccer match or whatever. Also
| the CG-NAT gateway isn't for free and the bigger it needs
| to be, the pricier it is. Also you might still need to
| buy some IPv4, perhaps more than you would need to buy if
| you deployed IPv6 and used it for the connections, where
| it is possible, taking e.g. almost the full load to
| Google/ YouTube and Facebook off your gateway.
|
| [0] https://anderstrier.dk/2021/01/11/my-isp-is-killing-
| my-idle-...
| betterunix2 wrote:
| IPv4 address space exhaustion. NAT breaks end-to-end
| connectivity, making entire classes of applications difficult
| to deploy, and this is made worse when the NAT gateway is not
| under a user's control. NAT gateway deployed by ISPs
| represent a violation of the end-to-end principle and have to
| be even more complex and stateful than the NAT gateways users
| often deploy. If you are looking for a _specific_ problem NAT
| introduces, one good one is that NAT forces users and
| application developers to use protocols that the NAT gateway
| properly supports (e.g. TCP, UDP) and to only use those
| protocols in ways that are "NAT-friendly" (e.g. easy-to-
| track client-server sessions that are initiated from the
| private side the gateway) or else to use some NAT-specific
| protocol as a crutch (UPnP/IGD, STUN, etc.). When both ends
| of a two-party protocol are behind NAT gateways it can become
| even more painful and possibly require a third party to be
| introduced to an application that is otherwise unnecessary
| for the application.
|
| So at a minimum IPv6 gets us back to the end-to-end principle
| where Internet peers connect directly to each other without
| having to negotiate with the network itself. There are a few
| other advantages, like the fact that users can get large,
| publicly-routed addresses spaces for their own use (e.g. ISPs
| giving users a /56 prefix), simplified bridging of private
| networks (very low probability of collisions in the private
| IPv6 range), simplified router configuration (link-local
| addresses are always available so there is no need to assign
| numbers to every link), and other assorted niche benefits. In
| theory IPv6 should mean routers become more efficient because
| it is easier to aggregate prefixes, which should generally
| benefit Internet users by reducing latency (though at this
| point there is not much room left for improvement there).
| norenh wrote:
| I would argue that the main reason is that we are stuck with
| a centralized Internet with a somewhat large initial step to
| start a new service. If everyone get IPv6 we are all able to
| be a first class citizen on the Internet, meaning I can run a
| webserver or whatever from home. Once I am ready I can move
| on to a hosting provider with all the extra costs and hassle
| it comes with. Without IPv6, we are stuck with a two tier
| system of Internet users. Basically consumers and providers
| where the step to become a provider is larger than when you
| can simply start from home with whatever scrap you have in
| your garage.
|
| IPv6 will also simplify a lot of things (being able to scrap
| NAT (note, you will still need a firewall) and avoid protocol
| issues for End-to-End services) but that is just a bonus.
| tambre wrote:
| Amazon enabled IPv6 for various CDN endpoints serving images
| and static assets this year. At least they've made progress.
|
| A few years ago when forcing Reddit to IPv6 through /etc/hosts
| many pages resulted in 500 errors, but they gradually fixed
| them.
| vbezhenar wrote:
| Why is it crazy? They don't gain anything by supporting IPv6.
| belorn wrote:
| I all the studies I have seen, ipv6 enabled networks
| outperform ipv4 only networks in term of latency.
|
| Improved latency mean improved responsiveness, and that in
| turn has companies claiming improved user retention and
| sales.
|
| If you need an argument to support ipv6, those seems like
| good reasons to support ipv6.
| ipv6_or_nat wrote:
| I can't see any difference in latency in the services I use
| between IPv4 and IPv6.
|
| What I want to know is do all these studies take into
| consideration the "happy eyeballs" algorithm that prefers
| IPv6 over IPv4 in web browser requests, thus delaying the
| IPv4 request?
| betterunix2 wrote:
| The latency in question has to do with routers. IPv6
| packets have a simpler header that does not force routers
| to recompute a checksum for each hop, and IPv6 allows
| better route aggregation which reduces the CPU overhead
| of route selection in some cases.
| 2fastpost wrote:
| I am unaware of any router forwarding IPv4 packets slower
| than IPv6 packets. Can you back up this claim with any
| sources?
|
| Route aggregation or selection does not impact forwarding
| performance on a router.
| miohtama wrote:
| If you can do direct consumer mobile phone IPv6 to server
| IPv6 there are benefits in latency, throughput, congestion
| control, analytics and so on. A better user experience.
| Depending on the hosting setup and networks, this may or may
| not be significant.
| vbezhenar wrote:
| carrier NAT is unlikely to introduce measurable latency,
| especially in wireless networks. I agree that IPv6 allows
| for better user tracking, probably that's one of the
| reasons to adopt it. For example iPhones are virtually
| indistinguishable from each other, so the only reliable way
| to track them is cookie or IP address.
| supertrope wrote:
| It costs money to buy and maintain CG NAT infrastructure.
| Local authorities will demand you log who had what IP
| address at the time of interest.
| ipv6_or_nat wrote:
| IPv4 or CGNAT costs are not optional. You will have to
| pay them regardless of if you deploy IPv6 or not.
| supertrope wrote:
| Less racks of CG NAT. Deploying IPv6 gets Netflix,
| YouTube, Facebook and other popular traffic to connect
| directly.
| toast0 wrote:
| IPv4 and CGNAT costs scale with usage. The more traffic
| you offload to IPv6, the less CGNAT capacity you need and
| the less IPv4 space you need; you need enough IPv4
| addresses so you can give out unique IP:Ports for all
| concurrent connections to popular destination IP:Ports.
| 2fastpost wrote:
| None of those are arguments for why IPv4 or CGNAT costs
| are optional; you cannot run an ISP without IPv4 or
| CGNAT, therefore the IPv4 or CGNAT costs are not
| optional. You will incur them regardless of if you deploy
| IPv6 or not.
|
| If you deploy IPv6, you might not deploy CGNAT, but
| unless you are dual stacking, something functionally
| equivalent is required.
|
| As to scaling costs, IPv6 offload isn't a 1:1 replacement
| for IPv4 or CGNAT capacity. You need enough capacity to
| carry the IPv6 traffic over IPv4 in case your IPv6
| transport, transit or peers fail. Again, not optional.
| supertrope wrote:
| Parent commenter wasn't saying that CG NAT costs could be
| avoided entirely. Deploying IPv6 gets Netflix, YouTube,
| Facebook and other popular traffic to connect directly.
| That means less racks of CG NAT.
| 2fastpost wrote:
| Like I said, you can only avoid CGNAT costs if you accept
| the failure modes inherent if/when your IPv6 fails.
|
| Thus in a properly designed network these are not
| optional costs.
| toast0 wrote:
| > You need enough capacity to carry the IPv6 traffic over
| IPv4 in case your IPv6 transport, transit or peers fail.
| Again, not optional.
|
| Surely you need enough IPv6 capacity incase your IPv4
| transit fails as well. If JIO could have built enough
| IPv4 capacity to run their network over IPv4, they would
| have, but they can't, so they've been pushing IPv6 hard.
| 2fastpost wrote:
| You are likely to be unable to source the missing IPv4
| traffic over IPv6.
|
| I'm not familiar with JIO's setup, but that's an
| interesting question. If their IPv6 was down, would their
| network still be able to deliver? Would they run out of
| CGNAT capacity or IPv4 translations?
| toast0 wrote:
| If their IPv6 failed, they would almost certainly run
| with significant service disruption.
|
| IPv6 is no longer optional for them. I suspect it's not
| optional for T-Mobile USA either. Or
| Facebook/Google/Netflix.
| 2fastpost wrote:
| Don't think IPv4 is optional for any of them either.
| somerandomqaguy wrote:
| Wouldn't that cost be easy to pass along to the customers
| though? Assuming the authorities aren't discriminating
| against a single ISP, then all the ISP's can just raise
| their price at the same time.
|
| Or have I been living with Canadian ISPs too long and
| that sort of thing doesn't happen in the rest of the
| world?
| billytetrud wrote:
| It's super weird you think passing costs onto consumers
| makes the problem go away. When a company passes costs to
| their consumers, consumers buy their product less, so
| that company loses money anyway.
| ClumsyPilot wrote:
| Sorry, i am concerned about me, the consumer, loosing
| money
| tpxl wrote:
| You do lose money because they raised the prices.
| pixl97 wrote:
| CGNAT is a consumer nightmare that makes them a second
| class citizen dependent on large providers to offer
| services.
| amjd wrote:
| You're right about other sites, but Hotstar does support IPv6:
| $ dig +short AAAA www.hotstar.com www.hotstar.com-
| sni.edgekey.net. e35862.dscj.akamaiedge.net.
| 2600:140f:7800::1730:f420 2600:140f:7800::1730:f421
| 2600:140f:7800::17d7:d7b9 2600:140f:7800::17d7:d7a9
| 2600:140f:7800::1730:f449
| praseodym wrote:
| github.com doesn't support IPv6 either, which is annoying
| because a lot of software uses GitHub for artifact
| distribution.
| nsizx wrote:
| In what way does getting your artefacts through ipv4 annoy
| you?
| lazide wrote:
| It means I can't do a fully ipv6 backend, which is a bit
| irritating.
| ikiris wrote:
| Why do you need ipv4 on your backend to reach ipv4
| destinations?
| eqvinox wrote:
| NAT64 is NAT with all its associated annoyances and bugs,
| and proxies/caches are just annoying to maintain and a
| needless added point of failure for small installations.
| Pet_Ant wrote:
| If you have an bunch of servers using ipv6 to avoid NAT
| issues.
| paulcarroty wrote:
| Yeah, and Heroku too. Don't know how they going now, but 5-7
| years ago were their popularity was crazy.
| judge2020 wrote:
| https://dns.google/query?name=www.google.co.in&rr_type=AAAA&...
| est31 wrote:
| The pain is most felt by the ISPs which need to supply lots of
| ip addresses to their customers, while you need only few ip
| addresses for running an internet service (compared to the
| number of users/customers). There is little improvement in user
| experience and you need to change a lot of infrastructure to
| also support ipv6 addresses. So websites don't do it, sadly.
| tzs wrote:
| Some of those sites have mobile apps on the Apple app store.
| How does not supporting IPv6 on their site reconcile with
| Apple's requirement that apps that support networking work when
| on an IPv6-only network?
|
| I would have thought that an app that is purportedly an app for
| site X but that cannot actually talk to site X when on an
| IPv6-only network would fail that requirement, but maybe I'm
| overestimating what Apple actually checks. Are they only
| checking that the app will correctly attempt an IPv6 connection
| to the site?
| realityking wrote:
| The App Store only requires Apps to work on networks
| employing DNS64/NAT64 [0].
|
| That means the app internally needs to be able to handle IPv6
| addresses and not hardcore any IPv4 addresses as those can't
| be reached. There's no requirement that the service
| underlying the app is directly reachable via IPv6.
|
| 0: https://developer.apple.com/support/ipv6/
| rynes wrote:
| Once upon a time I had an original iPhone and a router that
| did nor have ipv6, but the App Store worked. So I don't
| understand your "ipv4 addresses can't be reached" part.
| tialaramex wrote:
| On _some people 's phones_ IPv4 addresses can't be
| reached. Their carrier doesn't bother moving IPv4 over a
| network that doesn't need IPv4. It does translation at
| the edge, and the iPhone is OK with that.
|
| Apple's requirement is that even though you know your
| server is definitely 10.20.30.40+ on the public network,
| and you hate IPv6 you _must not_ hard code 10.20.30.40
| inside the app and ship that to the App Store.
|
| Once you reluctantly change it to a DNS name ten-twenty-
| thirty-forty.fuck-off-apple.example that resolves to
| 10.20.30.40 - Apple allows that.
|
| Because _now_ when your app is used on some IPv6-only
| carrier network, the carrier goes "ten-twenty-thirty-
| forty.fuck-off-apple.example ?" and it gets 10.20.30.40
| and it says that's an IPv4 address, don't use those
| around here, and it adds a translator step, it gives the
| phone an _IPv6 address_ for ten-twenty-thirty-forty.fuck-
| off-apple.example and the phone connects to that address,
| which is a translator that connects to 10.20.30.40 on the
| IPv4 Internet.
|
| This stuff _happens all the time_ and you don 't notice.
| But if Apple allowed app vendors to just scribble IPv4
| addresses inside their app software it would break.
|
| + No that isn't a public IP address. It's an example.
| nikkinana wrote:
| Just do the needful.
| aloknnikhil wrote:
| This seems to be particularly because of Reliance Jio (the
| largest Mobile network in India?)
| https://conference.apnic.net/50/assets/files/APCS790/Harness...
|
| The adoption timeline matches Google's stats here
| tumblewit wrote:
| I believe so. They use a dual stack model and last I checked
| Airtel doesn't support IPv6 yet and neither does Vi which
| leaves Jio to be the only ones contributing to the stats.
| gopkarthik wrote:
| Airtel does dual stack model. I've been using it for about 2
| years now.
| amjd wrote:
| Airtel doesn't seem to support IPv6 for their broadband
| services yet, at least in my state. Have you experienced
| this with broadband or mobile services?
| asaddhamani wrote:
| Airtel mobile supports IPv6
| quaintdev wrote:
| Airtel supports dual stack as well. I have been using Airtel
| Internet with IPv6 for a year or two now.
| tumblewit wrote:
| I tried on my iPhone SE (2020) 3 months ago and I could not
| get iPv6. Could be location specific. Because I
| specifically tested for iPv6 support.
| crims0n wrote:
| Ah yes... the IPv6 migration. Been hearing about this for two
| decades now. The reason it isn't ubiquitous in 2021 is because
| there are fundamental issues with the protocol, not least of
| which is incompatibility with what the entire rest of the world
| is current running. If we are ever going to get the world on the
| same protocol, we need something new.
| onefortree wrote:
| Do you mind describing what those issues are? Or linking some
| reading about it?
| vetinari wrote:
| Nah, as protocol the IPv6 is fine.
|
| What is not fine is the real-world implementations. ISPs that
| give you a /64 subnet? ISPs that insist, that with IPv6 you
| must use their CPE as a router, where you have almost zero
| control? ISPs that give you /56, but prefix delegation on the
| router they force on you is broken?
|
| There's so much brokenness, that even as a IPv6 fan, I keep my
| IPv4 addresses. And if it means DS-Lite or IPv4, then IPv4 is
| it.
| moonchrome wrote:
| IPv6 is a perfect example of where a legislator can make a
| positive market impact. I like market principles, but relying on
| market alone for this just leads to local optimum (squeezing
| every last drop from IPv4 with various hacks).
|
| Just mandate that every ISP must provide IPv6 for new contracts
| within a year and then for all existing contract within two - or
| whatever reasonable timeline - and be done with it.
| techsupporter wrote:
| Didn't the US government require that all cloud services
| provided to and by the government be done over IPv4 and IPv6
| some time ago?
|
| In opening another tab to answer my own question, I see that
| they've broadened the scope and that the US government networks
| should be IPv6-only, with some caveats I'm sure, by 2023:
| https://fedtechmagazine.com/article/2021/03/how-make-progres...
| ipv6_or_nat wrote:
| The cynic in me wants to know if all government cloud
| services support IPv6 as mandated, on paper only or in
| practice? :)
|
| The linked article isn't as ambitious as to claim IPv6-only
| government networks by 2023, only that _new_ systems should
| support IPv6 by 2023.
|
| I'd also be _very_ surprised if the government was able to
| hit _any_ of the IPv6-only targets put forth in the article.
| tzs wrote:
| Simpler: put a cap on the number of IPv4 addresses that can be
| transferred per quarter, and lower that cap each quarter.
| ipv6_or_nat wrote:
| This just cements the IPv4 incumbents as winners.
| tzs wrote:
| I think you might be overlooking network effects (pun
| intended).
|
| Yes, the current incumbents will buy up all the IPv4
| addresses they can before trading stops. That will cement
| them as the permanent winners for IPv4 services.
|
| But with IPv4 addresses no longer tradable, hosting
| companies and ISPs will have no choice but to adopt IPv6 if
| they want to grow. New hosting companies and ISPs will be
| IPv6-only.
|
| I'd expect at that point most large mobile networks, which
| are largely IPv6 already with IPv6 compatibility bolted on
| so customers can reach IPv4-only sites, to go IPv6-only.
|
| There will be legacy applications that still need a real
| IPv4 address on the server side. The current incumbents
| will end up cemented as the winners of that service.
| 2fastpost wrote:
| You assume new entrants or smaller entities would have a
| fighting chance in this scenario. They would not.
|
| The incumbents would become king makers. They would
| decide which services would be allowed on the IPv4
| Internet, which would be the only Internet, and which
| services would be allowed to prosper.
|
| The incumbents would either acquire all successful
| startups and smaller companies or clone their services.
|
| New entrants would wither on the wine on this obscure
| IPv6-only network that hardly anybody knows about or is
| able to access.
|
| This would also kill off IPv6 completely. The incumbents
| would have a collective interest in maintaining and
| propping up their position. IPv6 would be a threat to
| this, so it would be given the axe.
|
| This isn't some far out fantasy either. This is how
| mobile phone services worked during the SMS era before
| the Internet was a thing.
| matheusmoreira wrote:
| Don't force IPv6. Make IPv4 illegal. Now they can't half-ass
| the IPv6 support.
| 2fastpost wrote:
| Hard pass. Nobody wants more government involvement. Not to
| mention the unspeakable amount of waste and chaos this would
| entail.
| matheusmoreira wrote:
| If regulation is to be attempted, we gotta do it right.
| Can't leave loopholes around to make things cheaper for
| them and worse for everybody else. They should have
| literally no choice but the right one. Waste and chaos
| don't matter. Do things right or give up.
|
| Letting them keep IPv4 resulted in them dragging their ass,
| implementing NAT everywhere and killing end-to-end
| conectivity on the internet, repurposing IPv4 as a
| reputation system, god knows what else. We gotta get rid of
| it.
| ipv6_or_nat wrote:
| Forcing IPv6 upon ISPs by decree will only make them do the
| very least possible in order to be able to check a box.
|
| To truly drive IPv6 adoption there has to be a real need for
| IPv6 and/or a revenue driver.
|
| Very large ISPs and mobile carriers _need_ IPv6 because they
| are simply running out of IPv4 addresses, even non-public IPv4
| addresses!
|
| This still does not mean they can go IPv6-only, they still need
| IPv4 and translation technologies to reach the Internet.
|
| The core problem of IPv6 adoption is that insensitive do not
| align across the whole Internet ecosystem.
| ClumsyPilot wrote:
| "Forcing IPv6 upon ISPs by decree will only make them do the
| very least possible in order to be able to check a box."
|
| Which is more than they are doing now.
|
| What real-world issues do you forcee. IPv6 either works, or
| doesn't
| 2fastpost wrote:
| > IPv6 either works, or doesn't
|
| Oh, you sweet summer child! :)
|
| IPv6 "just works" only if you completely control the
| routing stack end-to-end.
|
| Once end user equipment and hosts are introduced into the
| network all bets are off.
|
| In a mobile network, where the carrier controls what user
| terminals are allowed on the network, it is at least
| nominally possible to achieve "just works" status.
|
| So, in the real world, forcing IPv6 would result in IPv6
| being supported only in a particular configuration used in
| a particular way. Everybody will be told to go pound sand
| and no effort will be made to keep IPv6 working or prevent
| breakage.
| citrin_ru wrote:
| IPv6 is a bad technical standard to begin with (which is on of
| the reasons behind slow adoption). Forcing it with legislation
| would only make everyone involved to hate it more.
| throw0101a wrote:
| > _IPv6 is a bad technical standard to begin with_
|
| Can you expound on why you think this is the case?
| snuxoll wrote:
| Not GP, but I think IPv6 is generally fine. The big issue
| is around mid sized enterprises, where multi homing becomes
| a need and for so long PI address space was reserved for
| peering-sizes entities. This makes sense from the
| perspective of reducing routing table size, but to date
| there's no good way to do multihoming with multiple PA
| blocks (there are ways, but they all suck).
|
| The IETF really needs to fix this issue in particular, it's
| the last big hurdle in seeing adoption IMO.
| ikiris wrote:
| PI was never reserved for peering sized entities... just
| get PI space.
| throw0101a wrote:
| > _but to date there's no good way to do multihoming with
| multiple PA blocks (there are ways, but they all suck)._
|
| Is using ULA and NPTv6 any worse than using NAT44?
| snuxoll wrote:
| It's not - but that doesn't mean it's a good solution.
| Clients should be able to know their globally routable
| address and ULA with NPTv6 seriously fucks with that, so
| I'm not a fan.
| magila wrote:
| What would a good solution to that even look like? Giving
| every mid-sized company it's own PI block would massively
| bloat the routing table so that's not going to happen.
| The solution space that's left basically comes down to
| some form of NAT/NPT or multi-home support at the
| endpoints. The IETF's preferred solution is the latter
| which seems reasonable to me.
| snuxoll wrote:
| I fully agree that giving PI blocks out like candy is not
| the ideal solution - but the solutions for dealing with
| multiple PA spaces are woefully inadequate right now. I'd
| really like to see the IETF step in here and come up with
| some workable proposals before we ruin IPv6 while it's
| still possible to fix these issues.
| magpi3 wrote:
| I'm not the person you are responding to, but from what I
| understand the main issues are:
|
| ipv6 is not backwards compatible with ipv4.
|
| Consequently adding support for ipv6 requires a dual stack
| solution (since supporting ipv4 is a must).
|
| An alternative solution to the problem of the limited
| number of ipv4 addresses has been reliance on NATs. This is
| much simpler than supporting ipv6 and is already widely
| adopted everywhere, and so that's what people are choosing
| to do.
|
| The obvious conclusion (from a casual observer like
| myself): the successor to ipv4 has to be backwards
| compatible with it, similar to how UTF-8 is backwards
| compatible with ASCII.
|
| EDIT: I should note that I am not a network engineer, so if
| anything I have written is incorrect, I hope someone
| corrects me.
| throw0101a wrote:
| > _ipv6 is not backwards compatible with ipv4._
|
| I've seen this objection, and I do not see how it could
| be otherwise.
|
| If all the code out there was for 32-bit-only addresses
| (of IPv4), then expanding the addresses space to
| something >32 bits would entailed updating every single
| IP-capable code. Which is exactly that needed to be done
| for IPv6: every device needed to have code updated (and
| this included 'hardware code' of things like ASICs).
| magpi3 wrote:
| Again, I am not a network engineer and so I am a little
| of my depth. But I will respond in the hopes someone will
| educate me if I am wrong.
|
| While UTF-8 is backwards compatible with ASCII, it did of
| course require programmers to add support for it just
| like you are suggesting any successor to IPV4 would. But
| once that support was added, ASCII could be treated as
| part of UTF-8 standard.
|
| From what I understand, this is not the case with IPV6
| and IPV4. The former requires its own software stack and
| the IPV6 standard was written (from what I have read)
| without any attempt to make it possible for IPV4 and IPV6
| addresses to coexist in the same software stack easily.
| betterunix2 wrote:
| Actually, IPv4 address can be mapped to the IPv6 address
| space and routed across an IPv6-only network; you have
| stateless NAT gateways at the edges. That allows network
| operators to manage a single-stack network while still
| giving users an IPv4 network. 464XLAT adds one more
| component to the picture, which is a stateful NAT gateway
| that allows a network operator to provide limited IPv4
| service without giving each user a public IPv4 address.
| For reference:
|
| https://en.wikipedia.org/wiki/IPv4_mapped_address#IPv4-ma
| ppe...
| throw0101a wrote:
| Yes, and all software had to be rewritten to use UTF-8.
| If you tried sending UTF-8 bits through an ASCII-only
| system, you'd display a bunch of garbage and even cause
| larger issues (as some bit sequences could have been
| interpreted as control/escape characters).
|
| So, just like expanding address space (IP: 32-bit to
| 128-bit; ASCII: 8-bit/1-byte to multi-byte), you had to
| rewrite all the software to handle things.
| magicalhippo wrote:
| The problem is packets flow both ways in a network.
|
| It's not like an actual pipe where one end doesn't care
| where the other end is. The recipient of a packet has to
| know where to send the reply.
|
| So while a host with a larger address could easily talk
| to a legacy host with an older, smaller address, the
| legacy host couldn't reply because it wouldn't know how
| to address it.
| citrin_ru wrote:
| It's too late to discuss alternatives to IPv6, so I haven't
| spend time collecting what I think wrong with it (and below
| just random thoughts).
|
| The main reason I don't like it - it is much more complex
| than IPv4 and this complexity provides from little to now
| real benefits (but a lot of advertised by IPv6
| evangelists). The only reason networks migrate to IPv6 is
| the scarcity of IPv4 addresses, not other features which
| was envisioned as improvements over IPv4, but on practice
| turned out to be not very useful.
|
| 128bit per address from which usable only 64bit looks like
| a waste of resources (CPU/RAM) to me. Idea was to embed
| MAC-address in lower 64bit, but it turned out to be a bad
| idea because of privacy implications and for most end-user
| devices lower 64bit are now random. Given that /64 prefix
| in most cases used by single host a 64bit address would be
| sufficient. If we had 64bit addresses we would save RAM for
| routers and OS kernels and simplify implementation (64bit
| integers are available in practically all modern
| programming languages and 64bit operations are fast, while
| 128bit is a slower extension which is not universally
| available).
|
| For me IPv6 is an example of the second-system effect:
| https://en.wikipedia.org/wiki/Second-system_effect
| betterunix2 wrote:
| In my experience IPv6 is much simpler to deal with than
| IPv4; in fact the large address space with a 64-bit
| prefix as the network number greatly simplifies
| management and configuration and theoretically improves
| the CPU performance of routers by allowing allowing more
| aggressive route aggregation. When ISPs give /56 prefixes
| to users, users can easily set up subnets according to
| their own needs without requiring extra coordination and
| without breaking end-to-end connectivity. You are wrong
| that /64 prefixes are usually assigned to a single host;
| in fact the number of Internet-connected devices in a
| typical home has grown over time and can easily be a
| dozen or more.
|
| If I were running an ISP, I would migrate the backbone
| network to IPv6 and just use embedded IPv4 addresses to
| avoid the headaches that come with router-to-router IPv4
| links. With IPv6 you always have a link-local address on
| every port that can be used by routing protocols without
| relying on proprietary solutions that are not
| interoperable between vendors or having to assign an IPv4
| address (and hoping that you assigned a large enough
| subnet for future growth). It is much easier to scale up
| an IPv6-only network and much easier to connect one
| IPv6-only network to another.
|
| Of course IPv6 is not perfect. SLAAC did not really work
| out as planned and now we are stuck with an annoying mix
| of SLAAC and DHCPv6. Reverse-DNS is still a bit of a
| pain. IPSec is not what it should have been and too many
| IPv6 standards rely on IPSec for security/authentication.
| Even so, the core of IPv6 is a huge improvement over IPv4
| for individual users, small network operators, large
| network operators, and the Internet as a whole.
| magicalhippo wrote:
| > In my experience IPv6 is much simpler to deal with than
| IPv4
|
| My experience is the complete opposite. Lot of software
| is still very immature when it comes to IPv6. A prime
| example is that I had to abandon pfSense because it just
| didn't handle prefix delegation. And no, switching ISP is
| not an option for me.
|
| I'm now on OpenWRT which is miles better, but getting
| IPv6 to play nice is still lot more work. For example
| there were a lot more steps to getting split-horizon DNS
| working compared to regular IPv4.
|
| > Even so, the core of IPv6 is a huge improvement over
| IPv4 for individual users, small network operators, large
| network operators, and the Internet as a whole.
|
| Maybe in another decade or two when IPv6 and the
| ecosystem around it has matured a bit. Though it still
| seems to have a lot of moving parts compared to IPv4,
| thus requiring more to keep track of.
| Dagger2 wrote:
| All 128 bits are usable, it's not limited to just 64.
|
| A total length of 64 bits would be too small for the
| eventual size of the internet. Our choice was between
| deploying something with too many addresses or something
| with too few addresses, and the former is by far better
| than the latter. We _do not_ want to be going through
| another IP family transition to increase the bit length
| again, so we need to get it right the first time.
|
| v6 mostly just took v4 and made the addresses longer, so
| I'm not sure it's reasonable to describe it as bloated.
| About the only thing it actually adds over v4 is SLAAC
| (and IPsec, but that was immediately backported to v4).
| tsimionescu wrote:
| > A total length of 64 bits would be too small for the
| eventual size of the internet.
|
| Even home consumers are getting at least a /64. Unless
| you're expecting consumers to start having ~2^64 devices,
| it doesn't seem like anyone is concerned with the public
| internet needing more than ~2^64 addresses.
| Dagger2 wrote:
| Don't think in terms of addresses. In a hierarchically-
| allocated and aggregated space like IP addresses, there's
| a massive difference between 64 bits of address space and
| 2^64 usable addresses.
|
| By the time you've gone through six levels of allocations
| (IANA -> RIR -> ISP -> Customer -> Network -> Device) the
| vast majority of the total address space will be unused
| -- or rather: used for the purpose of aggregation, but
| not used for end machines. A 64-bit address space might
| only reasonably be able to handle something like
| 2^40-2^48 devices in total, which isn't that much more
| than we already have today.
|
| > Unless you're expecting consumers to start having ~2^64
| devices
|
| You'd definitely need something longer than 64 bits long,
| _long_ before this point.
| throw0101a wrote:
| To illustrate the scale, 2^32:
|
| * is roughly equal to 4 300 000 000 (4e9, 4B)
|
| * it is also the maximum number of IPv4 addresses
|
| Going back to math class:
|
| * 2^64 = 2^(32+32) = 2^32 * 2^32 = (4B) * (IPv4 Internet)
|
| So a _single_ /64 IPv6 subnet can hold _four billion_
| IPv4 Internets worth of systems.
| throw0101a wrote:
| > _128bit per address from which usable only 64bit looks
| like a waste of resources (CPU /RAM) to me._
|
| I would recommend you check out Tom Coffeen, who wrote a
| book on IPv6 address planning for O'Reilly. Even with
| half the bits going to the subnet, there is a
| astronomical amount of addresses available:
|
| * https://www.youtube.com/watch?v=7Tnh4upTOC4&t=27m
| novok wrote:
| How google would start a wave of ip6 migration: give a search
| penalty for being ip4 only.
| ipv6_or_nat wrote:
| How would this benefit Google?
| pixl97 wrote:
| Less individual users behind NAT so they can track them
| better?
| 2fastpost wrote:
| Between search, gmail, YouTube, maps, Chrome and Android I
| don't think Google needs help tracking anybody on the
| planet.
|
| Even so, IPv6 privacy extensions more or less bring things
| up to par with NAT in terms of trackability.
|
| I guess there could be some small benefit, but very few it
| applied to would be outside the Google dragnet to begin
| with.
| miyuru wrote:
| Did the https migration benefit Google?
|
| https://developers.google.com/search/blog/2014/08/https-
| as-r...
| 2fastpost wrote:
| Https prevents ad injection.
| novok wrote:
| Could make future software plans more viable if the world is
| majority of the world is ipv6
| 2fastpost wrote:
| This view I could endorse.
| miyuru wrote:
| In theory, having IPv6 website enabled should give a slight
| boost to the ranking if the latency is lower.
|
| But still Google crawls dualstack sites with IPv4 so it is yet
| to be seen.
| sgt wrote:
| An idea (perhaps silly one) that I had to boost IPv6 adoption -
| remember the old web 1.0? Interesting web sites and stuff you
| don't easily find today? Let's create a unique experience that's
| only accessible on sites that are IPv6 only. Not to exclude
| people - even with IPv4 only from your ISP you can tunnel in.
| Ideas?
| nsgi wrote:
| Do you mean restricting new web features to IPv6 sites? Or
| something else?
| bradfitz wrote:
| Not an entirely new idea...
|
| https://itwire.com/business-technology/good-news-bad-news-an...
|
| > And the free porn? According to Labovitz, it's just one
| incentive being offered to promote IPV6 "...IPv6 proponents
| offer free high quality IPv6 porn (the porn-free, IPV4 home
| page is https://www.ipv6porn.co.nz/ )
___________________________________________________________________
(page generated 2021-08-15 23:02 UTC)