Enabling IPv6 support for GitHub Pages(github.blog)
github.blog
Enabling IPv6 support for GitHub Pages
https://github.blog/changelog/2021-09-30-enabling-ipv6-support-for-github-pages/
147 comments
I don’t really understand the benefits, would you mind explaining them to me ?
> I don’t really understand the benefits, would you mind explaining them to me ?
Want to run a public service with end-to-end connectivity? Go to your RIR to request an IPv4 block and be put on a waiting list.
Or break out your cheque book and be prepared to cough up $35+/IP for the privilege:
* https://auctions.ipv4.global
* https://ipv4marketgroup.com/ipv4-pricing/
* https://ipv4connect.com/marketplace
Or get an IPv6 address block right away for $0.
Want to run a public service with end-to-end connectivity? Go to your RIR to request an IPv4 block and be put on a waiting list.
Or break out your cheque book and be prepared to cough up $35+/IP for the privilege:
* https://auctions.ipv4.global
* https://ipv4marketgroup.com/ipv4-pricing/
* https://ipv4connect.com/marketplace
Or get an IPv6 address block right away for $0.
You'd still need IPv4 to connect with the Internet.
With the IPv4 internet, that is. You don't need IPv4 to connect to most GitHub pages anymore.
Admittedly, IPv4 internet is a good chunk of the Internet, but maybe not the part of interest to you at a given point in time. http://www.delong.com/ipv6_alexa500.html
Admittedly, IPv4 internet is a good chunk of the Internet, but maybe not the part of interest to you at a given point in time. http://www.delong.com/ipv6_alexa500.html
Plenty of folks are IPv6-only. Mobile on T-Mobile for example:
* https://www.youtube.com/watch?v=nNMNglk_CvE
* https://www.youtube.com/watch?v=nNMNglk_CvE
the Internet is almost out of IPv4 addresses, and the ones that are left are becoming expensive to obtain. Rather than hide whole blocks of users behind NAT, they can just use IPv6.
>Rather than hide whole blocks of users behind NAT,
... which creates all sorts of routing issues.
If you don't have your own publicly accessible IP address it creates all sorts of connection issues.
... which creates all sorts of routing issues.
If you don't have your own publicly accessible IP address it creates all sorts of connection issues.
I don't want to have my own IP, at least not without frequent changes. My servers should have static IPs but having static IPs at home or for mobile devices only makes tracking easier..
for some use cases. for example, most home users are behind ipv4 NAT because of their wifi routers. nobody really notices a problem.
Mostly because we've invested huge amounts of engineering effort to work around the problems. The result is that for the most common use cases, things mostly work.
NAT systems are optimized for a few devices to be active at a time. As the number grows they might not co-operate well. Game consoles are infamous for networking problems when you have anything other than a single machine.
NAT systems are optimized for a few devices to be active at a time. As the number grows they might not co-operate well. Game consoles are infamous for networking problems when you have anything other than a single machine.
And the Wifi router is at least under my control (although depending on where you live and which ISP you use even that isn't necessarily true), so I can still set up some port forwarding for my internal devices as required. Because of the shortage of IPv4 addresses however carrier-grade NAT is becoming more and more common, which is truly an abomination.
The big one is the address space expansion, which in addition to solving "can't get addresses" also makes routing cheaper and faster (can allocate addresses based on network topology, rather than on what's available).
Whole they were breaking backwards compatibility anyway, they also introduced a faster way of getting initial addresses, changed headers and dropped some features to make routing easier to implement in hardware, and added some features to make annotation of packets in the network backbone during transit easier.
[deleted]
IPv6-only hosts will be able to connect to github pages now, if configured properly.
There are a couple use-cases for that, but it should allow cheaper VPSes, or less complicated network configuration by eliminating NAT.
If a host only needs to access GitGub and a few select hosts, it can be granted an IPv6 without setting up DHCP, NAT, IPv4 routing tables, etc.
I've been considering using NAT64 as a way to eliminate the need for dedicated IPv4 configuration at home, unfortunately I recently moved, and the current provider is IPv4-only. This infuriates me to no end.
There are a couple use-cases for that, but it should allow cheaper VPSes, or less complicated network configuration by eliminating NAT.
If a host only needs to access GitGub and a few select hosts, it can be granted an IPv6 without setting up DHCP, NAT, IPv4 routing tables, etc.
I've been considering using NAT64 as a way to eliminate the need for dedicated IPv4 configuration at home, unfortunately I recently moved, and the current provider is IPv4-only. This infuriates me to no end.
It boggles my mind that IPv6 has such a slow roll out (it's been a thing since the early 2000s = twenty years ago).
I would have thought that all the major tech companies supported it years ago on all their infrastructures, websites and apps. But there are still a lot of hold outs.
What about IPv6 makes it such a chore to become widespread?
I would have thought that all the major tech companies supported it years ago on all their infrastructures, websites and apps. But there are still a lot of hold outs.
What about IPv6 makes it such a chore to become widespread?
I recall being at Amazon some years ago when we were running out of IP addresses internally. A natural answer was "Why don't we all just switch to IPv6?".
The senior principle project manager in charge put it very simply: "The number of routers that don't support IPv6 that we'd need to replace exceeds the world-wide yearly production of IPv6 routers capable of replacing them. At our current rate of growth, we have less than a year until we run out of IPs." (I'm badly quoting a brilliant person many years after the fact, but that's roughly my memory of the talk she gave.)
Major tech companies often have constraints like that which the rest of us wouldn't even imagine.
The senior principle project manager in charge put it very simply: "The number of routers that don't support IPv6 that we'd need to replace exceeds the world-wide yearly production of IPv6 routers capable of replacing them. At our current rate of growth, we have less than a year until we run out of IPs." (I'm badly quoting a brilliant person many years after the fact, but that's roughly my memory of the talk she gave.)
Major tech companies often have constraints like that which the rest of us wouldn't even imagine.
I don't know how long ago that was, but I kinda have to call bullshit on her claim (even if it was hyperbole for the sake of making a point). Companies exist to make bespoke solutions for this very purpose, and nowadays outsourcing that kind of work is just natural for Amazon. Hell, they made a deal with Rivian to get a fleet of electric delivery trucks, getting some Chinese manufacturer to slap a Cortex m53 into a shitty plastic enclosure with Ethernet ports can't be that difficult. I bet there are AmazonBasics products that have required more forethought than that.
A core or edge router in a terabit+ scale network is a far cry from getting someone in China to make you a bunch of Netgear clones.
The Cisco 5500 series chassis is about 21 rack units (or about 3 feet) tall to give you an idea of the scale of these devices in the real world. They are also jam packed with custom ASICs that allow packet switching at extremely high speeds, which would need to be redesigned to handle 16 byte addresses.
The Cisco 5500 series chassis is about 21 rack units (or about 3 feet) tall to give you an idea of the scale of these devices in the real world. They are also jam packed with custom ASICs that allow packet switching at extremely high speeds, which would need to be redesigned to handle 16 byte addresses.
> The Cisco 5500 series chassis is ... jam packed with custom ASICs
Assuming you’re talking about the NCS 5500, I thought the whole point of that platform was that it wasn’t using Cisco proprietary ASICS and was just using Broadcom chips with IOS-XR wedged on it anyway to give it the appearance of being a budget competitor to the ASR9K while lacking the majority of the feature set because ... it’s not using Cisco’s proprietary ASICS that support all those features.
Also, they have full ipv6 routing and switching support. So does the C6500, which is ancient (and still in production in many places)
Assuming you’re talking about the NCS 5500, I thought the whole point of that platform was that it wasn’t using Cisco proprietary ASICS and was just using Broadcom chips with IOS-XR wedged on it anyway to give it the appearance of being a budget competitor to the ASR9K while lacking the majority of the feature set because ... it’s not using Cisco’s proprietary ASICS that support all those features.
Also, they have full ipv6 routing and switching support. So does the C6500, which is ancient (and still in production in many places)
Most real large scale is actually white box clos switch networks.
[deleted]
So tell your vendor you expect them to have that redesign in 4 years.
Fat lot of good that will do you with your project that needs to be completed next year or your company is hosed no? And once you do the fix - which won’t require ipv6 or will use a different vendor - then you won’t be talking to them anyway.
The underlying issue is that there is a lot of momentum with v4, and hacks mostly work and work faster and easier, so most people end up going that way. So it keeps the momentum.
And v6 has some serious second system syndrome going on (aka we’ll dramatically fix all the stuff we wanted to do better last time, ignoring real world constraints), and the adoption shows. It was clearly designed to be a either or replacement (aka cleanroom, start fresh with this), but that’s not how real world upgrades tend to work. I keep wanting to use v6, but every time I do, it quickly ends up having to get turned off because of something broken somewhere in some product I have little choice in using or interacting with and v4 (even with tons of terrible NAT) still keeps chugging along.
Momentum is shifting of course - this isn’t a steady state forever thing - but man, ugh.
The underlying issue is that there is a lot of momentum with v4, and hacks mostly work and work faster and easier, so most people end up going that way. So it keeps the momentum.
And v6 has some serious second system syndrome going on (aka we’ll dramatically fix all the stuff we wanted to do better last time, ignoring real world constraints), and the adoption shows. It was clearly designed to be a either or replacement (aka cleanroom, start fresh with this), but that’s not how real world upgrades tend to work. I keep wanting to use v6, but every time I do, it quickly ends up having to get turned off because of something broken somewhere in some product I have little choice in using or interacting with and v4 (even with tons of terrible NAT) still keeps chugging along.
Momentum is shifting of course - this isn’t a steady state forever thing - but man, ugh.
> Fat lot of good that will do you with your project that needs to be completed next year or your company is hosed no?
You can do both.
> And once you do the fix - which won’t require ipv6 or will use a different vendor - then you won’t be talking to them anyway.
It depends on whether you actually want to fix it.
> The underlying issue is that there is a lot of momentum with v4, and hacks mostly work and work faster and easier, so most people end up going that way. So it keeps the momentum.
Yes, which is very different from being unable to get the equipment you'd need.
You can do both.
> And once you do the fix - which won’t require ipv6 or will use a different vendor - then you won’t be talking to them anyway.
It depends on whether you actually want to fix it.
> The underlying issue is that there is a lot of momentum with v4, and hacks mostly work and work faster and easier, so most people end up going that way. So it keeps the momentum.
Yes, which is very different from being unable to get the equipment you'd need.
That’s nice, but clearly not how the majority of the purchasing departments work right now, correct?
And if most people don’t buy that way - then it isn’t easy to get solid equipment that can do things that way - which makes it hard to get the equipment you need.
And if most people don’t buy that way - then it isn’t easy to get solid equipment that can do things that way - which makes it hard to get the equipment you need.
> That’s nice, but clearly not how the majority of the purchasing departments work right now, correct?
The question was about what the company can do, talking about external constraints, so I don't really care how purchasing departments work for that topic.
> And if most people don’t buy that way - then it isn’t easy to get solid equipment that can do things that way - which makes it hard to get the equipment you need.
For smaller companies, yes. Except the argument was that smaller companies could get them already, while Amazon would exhaust the world supply.
Once we move into the realm of companies that make their own markets, it doesn't matter what "most people" do. Those companies can make their own choices and get whatever they want made.
The question was about what the company can do, talking about external constraints, so I don't really care how purchasing departments work for that topic.
> And if most people don’t buy that way - then it isn’t easy to get solid equipment that can do things that way - which makes it hard to get the equipment you need.
For smaller companies, yes. Except the argument was that smaller companies could get them already, while Amazon would exhaust the world supply.
Once we move into the realm of companies that make their own markets, it doesn't matter what "most people" do. Those companies can make their own choices and get whatever they want made.
It could very well be.
But how many of those routers could they make, and how quickly? And for how much? And could they really handle the kind of load that Amazon needed to handle? And how quickly could these bespoke solutions be installed, tested at scale, verified to work? Would the manufacturer provide support if they don't work as expected?
The solution that was done was to split the network into sub-networks with just the few proxy gateways between them that were needed. And it worked- I think it's still working that way. That's not free to do (every service owner had to do some networking work), but it's also perhaps less expensive than switching out all the hardware, overall.
And rest assured, Amazon always chooses the option that maximizes profit in the long run. Other than that stupid phone.
But how many of those routers could they make, and how quickly? And for how much? And could they really handle the kind of load that Amazon needed to handle? And how quickly could these bespoke solutions be installed, tested at scale, verified to work? Would the manufacturer provide support if they don't work as expected?
The solution that was done was to split the network into sub-networks with just the few proxy gateways between them that were needed. And it worked- I think it's still working that way. That's not free to do (every service owner had to do some networking work), but it's also perhaps less expensive than switching out all the hardware, overall.
And rest assured, Amazon always chooses the option that maximizes profit in the long run. Other than that stupid phone.
Facebook's answer was "fine, we'll build our own routers" (in the datacenter, which is where quantity comes in, and is now v6-only (with few exceptions): https://www.internetsociety.org/resources/deploy360/2014/cas...
Major tech companies have constraints, but when they decide to move, they can move almost anything. It would be cool to see how constraints and problem solving approaches differed among the FANG companies as they grappled with these issues.
Major tech companies have constraints, but when they decide to move, they can move almost anything. It would be cool to see how constraints and problem solving approaches differed among the FANG companies as they grappled with these issues.
Great story; I don't buy it. I haven't purchased a commercial-grade router (for values of more than just 'Cisco' or 'Juniper') that couldn't support IPv6 (admittedly for better and worse levels of 'support') since the early 2000s. If Amazon wanted them, they would have been supplied. Maybe it's "no one can supply routers with the IPv6 support we want (snowflake emoji)" or "we can't deploy the routers fast enough operationally". But not enough v6 capable routers is a stretch.
And even so...this anecdote is/was 'many years after the fact', so what's the issue now? Easy: they don't need it enough to spend the money to operationalize it.
And even so...this anecdote is/was 'many years after the fact', so what's the issue now? Easy: they don't need it enough to spend the money to operationalize it.
Which router produced in the last 10 years does not support IPv6?
Cisco still produces brand new equipment without IPv6 support. It's not only routers, much of the rest of the networking stack needs IPv6 to be enabled as well.
We mistakenly had the same notion that "why would a new line of Cisco wireless equipment not have IPv6". That pushed back a network upgrade of a remote office a few months. Our mistake really, we should have checked.
Of manufacturers, like Kyocera, have equipment that technically supports IPv6, but no-one really knows who to configure it. IBM have a software product which is IPv6 capable, or it was when they did the initial implementation in 2012. Later versions just sort of shipped with broken IPv6, because IBM doesn't actually test in new releases.
We mistakenly had the same notion that "why would a new line of Cisco wireless equipment not have IPv6". That pushed back a network upgrade of a remote office a few months. Our mistake really, we should have checked.
Of manufacturers, like Kyocera, have equipment that technically supports IPv6, but no-one really knows who to configure it. IBM have a software product which is IPv6 capable, or it was when they did the initial implementation in 2012. Later versions just sort of shipped with broken IPv6, because IBM doesn't actually test in new releases.
I think its more of a matter of perception than anything. IPv6 adoption has gone pretty smoothly imho, there hasn't been any major blowbacks or anything; for example the Google IPv6 adoption chart trend is steadily increasing.
Another thing you can see from Google IPv6 charts that before 2011 IPv6 adoption was near zero. This matches pretty well with IPv4 exhaustion; IANA pool was exhausted in 2011, and APNIC followed later that year. Before that anyone could get IPv4 address pretty liberally, so there was very little reason to think about IPv6. Especially in western world (RIPE/ARIN) where consumption was slower than e.g. APNIC; notably ARIN reached exhaustion only in 2015.
https://www.google.com/intl/en/ipv6/statistics.html
In summary, I feel that having third of internet become ipv6 in about a decade seems pretty decent result, considering how complex and especially diverse internet is.
Another thing you can see from Google IPv6 charts that before 2011 IPv6 adoption was near zero. This matches pretty well with IPv4 exhaustion; IANA pool was exhausted in 2011, and APNIC followed later that year. Before that anyone could get IPv4 address pretty liberally, so there was very little reason to think about IPv6. Especially in western world (RIPE/ARIN) where consumption was slower than e.g. APNIC; notably ARIN reached exhaustion only in 2015.
https://www.google.com/intl/en/ipv6/statistics.html
In summary, I feel that having third of internet become ipv6 in about a decade seems pretty decent result, considering how complex and especially diverse internet is.
Someone pointed out recently on NANOG the thing that probably killed a TON of IPv6 momentum was when they missed the deadline to get it included in Windows 95. Approximately no one was on the internet before then.
(Yes yes you nerds were, but most people weren't)
(Yes yes you nerds were, but most people weren't)
Seems pretty far fetched to me that there would have ever been a chance to have IPv6 in Win9x. For comparison, afain FreeBSD was the forerunner with IPv6 support, and they got it in 2000. So I'd say they "missed the deadline" by 5+ years. It was probably around 2005 when we realistically had somewhat usable IPv6 support at base OS level.
I think the point was that it changed the whole demand curve. If the major consumer OS at the time had v6 support things like FreeBSD would have added it earlier.
> It boggles my mind that IPv6 has such a slow roll out (it's been a thing since the early 2000s = twenty years ago).
IPv4 had just as slow a roll out in some ways. TCP/IP had its flag day in 1983:
* https://en.wikipedia.org/wiki/Flag_day_(computing)
There was early commercialization of the Internet around ±1990, but it didn't really start taking off until around 1994:
* https://en.wikipedia.org/wiki/Commercialization_of_the_Inter...
The Dot-com bubble peaked in 2000:
* https://en.wikipedia.org/wiki/Dot-com_bubble
RFC 1918 was published in 1996, and the kludge of NAPT was documented in RFC 2663 in 1999.
Given all of the above, I would say it took IPv4 about 15 years to reach the mainstream.
IPv4 had just as slow a roll out in some ways. TCP/IP had its flag day in 1983:
* https://en.wikipedia.org/wiki/Flag_day_(computing)
There was early commercialization of the Internet around ±1990, but it didn't really start taking off until around 1994:
* https://en.wikipedia.org/wiki/Commercialization_of_the_Inter...
The Dot-com bubble peaked in 2000:
* https://en.wikipedia.org/wiki/Dot-com_bubble
RFC 1918 was published in 1996, and the kludge of NAPT was documented in RFC 2663 in 1999.
Given all of the above, I would say it took IPv4 about 15 years to reach the mainstream.
That's a different concern though - Promoting the whole use case of the internet vs migration from one protocol to another.
If we compare the http to https migration, Firesheep in 2010 demonstrated that maybe migration was the right thing to do rather than just an optional security feature for banks, Lets Encrypt was released to the public in 2014 and by like... 2019 basically all of the internet was HTTPS. There is a long tail to go for the last few sites, and some that have objections to the CA system and are holding out, but really https is just expected these days, which is a much better place than IPv6.
If we compare the http to https migration, Firesheep in 2010 demonstrated that maybe migration was the right thing to do rather than just an optional security feature for banks, Lets Encrypt was released to the public in 2014 and by like... 2019 basically all of the internet was HTTPS. There is a long tail to go for the last few sites, and some that have objections to the CA system and are holding out, but really https is just expected these days, which is a much better place than IPv6.
Introducing HTTPS to existing infrastructures is easy. Just terminate it at some point. It also adds a big advantage to users that their traffic can't be read by network operators. Introducing ipv6 is harder, as you need to change all your routing, logging, banning, etc. facilities to support ipv6. It doesn't add any direct advantages for users, as all ISPs still have to support ipv4.
> Lets Encrypt was released to the public in 2014 and by like... 2019 basically all of the internet was HTTPS
Google's ranking bonus had also been a great incentive.
Google's ranking bonus had also been a great incentive.
> Lets Encrypt was released to the public in 2014 and by like... 2019 basically all of the internet was HTTPS.
This is apples and oranges: absolutely zero software upgrades needed to be done to get HTTPS going and/or Let's Encrypt running.
I was able to get LE going on our F5 appliances in a few working days with zero changes to the base system/appliance software by simply installing the dehydrated ACME client and all of a sudden dozens of sites where we previously didn't want to pay for a cert were "secure".
Network hardware can stay in place for quite a while. Our previous generation of core switches lasted us 7 years before we swapped them out.
I wouldn't be surprised some of the mega-chassis routers in ISPs and other telcos sit around as long.
This is apples and oranges: absolutely zero software upgrades needed to be done to get HTTPS going and/or Let's Encrypt running.
I was able to get LE going on our F5 appliances in a few working days with zero changes to the base system/appliance software by simply installing the dehydrated ACME client and all of a sudden dozens of sites where we previously didn't want to pay for a cert were "secure".
Network hardware can stay in place for quite a while. Our previous generation of core switches lasted us 7 years before we swapped them out.
I wouldn't be surprised some of the mega-chassis routers in ISPs and other telcos sit around as long.
7 years for a core router is on the low end aswell. High end routers consist of a chassis which can last a decade or more easily. usually the line cards inside the chassis are replaced to allow higher band with, but the control plane can stay in place for a very long time.
I believe that ARPANET was 100% TCP/IP at most a year after it was rolled out in 1983. Its predecessor NCP only supported 256 nodes. So, yes, things take time but likely for different reasons.
So it took 15 years to build the entire Internet from scratch but it's taking over 20 years to upgrade to a new version.
It is a lot bigger now. I wonder how much IPv6 growth is net new hardware vs replacing old hardware
Easy, India vs USA stats show that. India had an internet boom after exhaustion so its adoption is new hardware. USA's boom predates IPv6 so its mostly replaced.
India's visible adoption stats are over-represented by lte deployment. Lots of broadband providers still don't have ipv6 and some major ones deployed it very recently.
Lots of IPv6 growth is by new ISPs that don't have the IPv4 resources that legacy ISPs have, like Reliance Jio in India.
Yep. Think about how long it took to get the whole country on dialup / ADSL, but how long it’s taking the whole country on FTTP (fibre to the premises). It’s a similar issue, as it’s not just a software upgrade, it’s a hardware upgrade as well.
How often were people upgrading computers in the 1990s and 2000s? How often are people upgrading now?
For a lot of folks when they get to good enough they stop. Understandable.
But the "good enough" of IPv4 has taken a lot of effort in the last few years. How much gnashing of teeth has NAT caused and having to invent TURN and STUN and a bunch of others things?
Anyone remember Skype supernodes?
With IPv6 you "just" have to do firewall hole punching without all the drama of packet tuple munging.
And good luck with double-(CG-)NAT hole punching.
For a lot of folks when they get to good enough they stop. Understandable.
But the "good enough" of IPv4 has taken a lot of effort in the last few years. How much gnashing of teeth has NAT caused and having to invent TURN and STUN and a bunch of others things?
Anyone remember Skype supernodes?
With IPv6 you "just" have to do firewall hole punching without all the drama of packet tuple munging.
And good luck with double-(CG-)NAT hole punching.
What does one have to do with the other?
I dug into IPv6 a few weeks ago. If you learn it from the ground up, as if you were first learning IPv4, it truly is not more complicated than IPv4+ARP. Length of address may be a reason people don't look at it at first, but if you look at it from an engineering perspective, it makes sense.
The only thing I don't like about it, is how they created SLAAC (a way for a client to auto-configure its own IP address without DHCP) - but didn't enable routers to provide DNS information.
Therefore, in any useful deployment, you need to deal with SLAAC for IP allocation, and DHCPv6 for DNS information.
Outside of that, the spec is pretty decent.
----
Also, damn every ISP and every router company that doesn't 100% support IPv6. Shockingly, this includes Ubiquiti, which is "supposed" to be medium-enterprise grade.
ISPs and endpoint network devices are the only reason we don't have IPv6 more prevalent, combined with NAT, CGNAT etc. being good enough to keep the net hobbling along.
The only thing I don't like about it, is how they created SLAAC (a way for a client to auto-configure its own IP address without DHCP) - but didn't enable routers to provide DNS information.
Therefore, in any useful deployment, you need to deal with SLAAC for IP allocation, and DHCPv6 for DNS information.
Outside of that, the spec is pretty decent.
----
Also, damn every ISP and every router company that doesn't 100% support IPv6. Shockingly, this includes Ubiquiti, which is "supposed" to be medium-enterprise grade.
ISPs and endpoint network devices are the only reason we don't have IPv6 more prevalent, combined with NAT, CGNAT etc. being good enough to keep the net hobbling along.
> Also, damn every ISP and every router company that doesn't 100% support IPv6.
It's extra development and extra testing (in fact it's way more testing due to the combinatorial explosion of IPv4/IPv6 interface schemes).
That comes at a cost.
> ISPs and endpoint network devices are the only reason we don't have IPv6 more prevalent, combined with NAT, CGNAT etc. being good enough to keep the net hobbling along.
ISPs & endpoint devices are the majority of the Internet, as far as complexity is concerned. Upgrading the equipment for HW-acceleration of IPv6 (parity with IPv4) is very costly.
It's extra development and extra testing (in fact it's way more testing due to the combinatorial explosion of IPv4/IPv6 interface schemes).
That comes at a cost.
> ISPs and endpoint network devices are the only reason we don't have IPv6 more prevalent, combined with NAT, CGNAT etc. being good enough to keep the net hobbling along.
ISPs & endpoint devices are the majority of the Internet, as far as complexity is concerned. Upgrading the equipment for HW-acceleration of IPv6 (parity with IPv4) is very costly.
> The only thing I don't like about it, is how they created SLAAC (a way for a client to auto-configure its own IP address without DHCP) - but didn't enable routers to provide DNS information.
there is RDNSS for router advertisments used with slaac. although it wasnt there initially and support for it might be lacking yet.
there is RDNSS for router advertisments used with slaac. although it wasnt there initially and support for it might be lacking yet.
How important is it for networks to provide DNS servers? Couldn't a device usually get away with just using 2606:4700:4700::1111 or 2001:4860:4860::8888 all the time with SLAAC? Also, what about RDNSS?
DNS is even more crucial with v6.
So, I was less aware of RDNSS. That makes one of my complaints moot.
DNS is critical. I'm not talking about registering an endpoint into a local DNS server (mydesktop.local), I'm talking about the endpoint knowing who to ask about google.com.
DNS is critical. I'm not talking about registering an endpoint into a local DNS server (mydesktop.local), I'm talking about the endpoint knowing who to ask about google.com.
I know DNS itself is critical. I'm asking whether network-provided DNS is critical, or if using well-known DNS servers like Google's or Cloudflare's would be good enough on most networks.
Do those return the correct CDN servers matching your geographical location and/or ISP?
I didn't try Google or Cloudflare specifically, but I did experimentally used some other DNS provider for a while, until I eventually ran into the problem that by doing so I got the "wrong" set of servers for anything hosted on Akamai, where the route between my ISP and those specific Akamai servers was grossly overloaded in the evenings.
Switching back to my ISP's DNS meant getting a more suitable set of Akamai servers and reasonable download speeds again.
Switching back to my ISP's DNS meant getting a more suitable set of Akamai servers and reasonable download speeds again.
> The only thing I don't like about it, is how they created SLAAC (a way for a client to auto-configure its own IP address without DHCP) - but didn't enable routers to provide DNS information.
That complexity is also part of why the Linux kernel's built-in support for IP autoconfig at boot time for network-based root filesystems (without using a userspace DHCP client) only supports IPv4.
That complexity is also part of why the Linux kernel's built-in support for IP autoconfig at boot time for network-based root filesystems (without using a userspace DHCP client) only supports IPv4.
As of a few years ago you don’t need DHCPv6 to announce DNS servers.
Router advertisements can announce a recursive DNS server (RDNSS) which local clients might like to use, eg:
https://github.com/radvd-project/radvd/blob/master/radvd.con...
Bad luck though if you are using, ahem, AIX or Windows Phone:
https://en.m.wikipedia.org/wiki/Comparison_of_IPv6_support_i...
Router advertisements can announce a recursive DNS server (RDNSS) which local clients might like to use, eg:
https://github.com/radvd-project/radvd/blob/master/radvd.con...
Bad luck though if you are using, ahem, AIX or Windows Phone:
https://en.m.wikipedia.org/wiki/Comparison_of_IPv6_support_i...
> Therefore, in any useful deployment, you need to deal with SLAAC for IP allocation, and DHCPv6 for DNS information.
Until Windows 10 this was correct, but now that Windows also supports RDNSS in Router Advertisements that is no longer the case.
My home network has been running SLAAC without DHCPv6 for years now.
Until Windows 10 this was correct, but now that Windows also supports RDNSS in Router Advertisements that is no longer the case.
My home network has been running SLAAC without DHCPv6 for years now.
In what way doesn't Ubiquity sorry it? I'm using only Ubiquity gear at home, and my network is fully IPv6.
My router is an Edgerouter by the way.
I do recall seeing some of the configuration wizard stuff not having options for IPv6 in the past, but that's just for initial configuration anyway. Once you are done with that you do everything from the config tree anyway.
My router is an Edgerouter by the way.
I do recall seeing some of the configuration wizard stuff not having options for IPv6 in the past, but that's just for initial configuration anyway. Once you are done with that you do everything from the config tree anyway.
If you configure an EdgeRouter completely through the command line then yes it does support it. The web UI though, is completely missing things like IPv6 firewall if you just quickly want to add a rule with a few clicks.
On the Unifi gear, the IPv6 UI that is there is marked "beta"
On the Unifi gear, the IPv6 UI that is there is marked "beta"
Thanks for the information. Since my firewall configuration is a bit more complex than what was supported by the simplified UI I never really used it.
Just to be clear, one can configure the IPv6 firewall through the UI. One just has to use the config-tree rather than the easy firewall configuration.
Just to be clear, one can configure the IPv6 firewall through the UI. One just has to use the config-tree rather than the easy firewall configuration.
The unifi UI can't even display the IPv6 addresses of WAN interfaces!
> Also, damn every ISP and every router company that doesn't 100% support IPv6.
Such as Verizon who still doesn't support it on FIOS
Such as Verizon who still doesn't support it on FIOS
Verizon FIOS does support IPv6 in some areas. IPv6 support has been available in my area for a couple of years.
It was, at some point, routing. Not all (inter)continental data highways are/were IPv6-enabled, meaning that IPv6 does/did not have the performance of IPv4 (latency, bandwidth). Global websites with no global distribution of servers thus kept using IPv4-only to prevent significant performance regressions for the early adopter clients.
Similarly, IPv6 hardware accelleration was not very common on consumer/prosumer routing hardware, making it very resource-intensive (much more so than IPv4), resulting in low throughput.
... based on personal research in ~2015-2016
Similarly, IPv6 hardware accelleration was not very common on consumer/prosumer routing hardware, making it very resource-intensive (much more so than IPv4), resulting in low throughput.
... based on personal research in ~2015-2016
Years ago, the French ISP `Free`, after much dragging of feet, enabled IPv6 support for their customers.
Performance was abysmal, 2x-10x slower than IPv4.
Turns out many of the routers out there can perform IPv4 table lookups in the data-plane (fast-path), but IPv6 is delegated to the control-plane (slow-path), for much slower performance.
Performance was abysmal, 2x-10x slower than IPv4.
Turns out many of the routers out there can perform IPv4 table lookups in the data-plane (fast-path), but IPv6 is delegated to the control-plane (slow-path), for much slower performance.
I see the opposite right now, with transfer rates being about the same but latency over IPv4 being quite bad compared to IPv6:
Pinging www.google.com with IPv6:
Pinging www.google.com with IPv6:
$ ping www.google.com
PING www.google.com(sc-in-x67.1e100.net (2404:6800:4003:c02::67)) 56 data bytes
64 bytes from sc-in-f103.1e100.net (2404:6800:4003:c02::67): icmp_seq=1 ttl=108 time=4.46 ms
64 bytes from sc-in-x67.1e100.net (2404:6800:4003:c02::67): icmp_seq=2 ttl=108 time=3.73 ms
64 bytes from sc-in-f103.1e100.net (2404:6800:4003:c02::67): icmp_seq=3 ttl=108 time=3.73 ms
$ ping -4 www.google.com
PING (142.250.186.100) 56(84) bytes of data.
64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=1 ttl=107 time=317 ms
64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=2 ttl=107 time=317 ms
64 bytes from fra24s06-in-f4.1e100.net (142.250.186.100): icmp_seq=3 ttl=107 time=317 ms
Looks like you've got some geolocation issues, because you went across the globe for that v4 route lol.
theoretically, ipv6 routing itself is far faster because the header is far simpler to parse.
also, the ipv6 space is far less fragmented then ipv4. this could lead to more direct routing aswell.
also, the ipv6 space is far less fragmented then ipv4. this could lead to more direct routing aswell.
> Years ago, the French ISP `Free`, after much dragging of feet, enabled IPv6 support for their customers.
And quite a quick deployment AFAICT:
> Free deployed the IPv6 infrastructure in only 5 weeks, from 7 November to 11 December 2007, thanks to an innovative 6rd (IPv6 rapid deployment) proposal by Rémi Després.[44]
* https://en.wikipedia.org/wiki/Free_(ISP)#Internet_access
* https://en.wikipedia.org/wiki/IPv6_rapid_deployment
And quite a quick deployment AFAICT:
> Free deployed the IPv6 infrastructure in only 5 weeks, from 7 November to 11 December 2007, thanks to an innovative 6rd (IPv6 rapid deployment) proposal by Rémi Després.[44]
* https://en.wikipedia.org/wiki/Free_(ISP)#Internet_access
* https://en.wikipedia.org/wiki/IPv6_rapid_deployment
Hmm, my experience in the US with CenturyLink Fiber's 6rd implementation suggests it's also slower than IPv4 (I went from ~900/900 to ~500/500 when I enabled it). I decided I could live with that, but it's still a little disappointing.
The main fiber network here in Japan (NTT) had the opposite development - their old PPPoE-based IPv4 core network was under-dimensioned for modern traffic patterns, so instead of upgrading it they build the next generation core network on IPv6.
So the first troubleshooting step when someone complains their home internet is slow is to say "have you enabled IPv6 service?"
Switching from PPPoE to IPv4-over-IPv6 means you get switched to CGNAT so if you want to host anything it's a downgrade, but in reward you get far greater performance.
So the first troubleshooting step when someone complains their home internet is slow is to say "have you enabled IPv6 service?"
Switching from PPPoE to IPv4-over-IPv6 means you get switched to CGNAT so if you want to host anything it's a downgrade, but in reward you get far greater performance.
For me it's a few things that keep me from fully embracing it, & largely the problem is perception, as others have noted.
1. I'm a small-time self hoster. I need/want to control access to geographic locations and using IPv4 makes that pretty easy. Last time I checked, IPv6 was just so wrong that it's no good to use at all, and most IPv6 addresses were "unknown" in origin.
2. I'm used to the pseudo security that a NAT gives. I hear (ad nausea) about how NAT gives you no security. The simple truth is that obscurity does give yet another layer of protection, especially for machines that you're busily configuring to become secure. Of course, a real sysadmin here will be able to scoff and laugh, but for this homebrew old timer it's true.
But also, there's the obfuscation of your IP address when you're behind a NAT. This is pretty important in these ad tracking days. AFAIK (which is almost zero), doesn't IPv6 give adware companies a very good fingerprint on you?
3. All those ICMPv6 messages sniffing (and snooping?) really don't fill me with joy joy happiness. The only recourse is to read some dead boring RFC that my poor overloaded brain doesn't really want to have anything to do with. With IPv4, if you don't want PING, you turn it off, with IPv6.... it's subtle.
4. Firewalls require two sets of independent entries for the same service.
So, IPv4 is an address space that's understood. IPv6 really does feel like a Godzillian monstrosity and a chore to type in: double colons between every number and it's in Hex? At least with IPv4 you can type the numbers in pretty rapidly on a numpad.
So, I know this answer will be unpopular, especially to professionals, but for everyone I've encountered that's turned it off, the above list is pretty accurate.
Every few years I search around for a true "IPv4 to IPv6 for noobs" and every time I only find "It's the same... with these gajillion subtle differences". So, yeah, perception is definitely an issue, but scoffing at NAT doesn't help uptake at all. I really do try to be a good netizen, but it's hard. (that said, I do have a mail server set up to use ipv6 and all is good... except for the lists of unknown sources who hammer away at its security all day, every day)
1. I'm a small-time self hoster. I need/want to control access to geographic locations and using IPv4 makes that pretty easy. Last time I checked, IPv6 was just so wrong that it's no good to use at all, and most IPv6 addresses were "unknown" in origin.
2. I'm used to the pseudo security that a NAT gives. I hear (ad nausea) about how NAT gives you no security. The simple truth is that obscurity does give yet another layer of protection, especially for machines that you're busily configuring to become secure. Of course, a real sysadmin here will be able to scoff and laugh, but for this homebrew old timer it's true.
But also, there's the obfuscation of your IP address when you're behind a NAT. This is pretty important in these ad tracking days. AFAIK (which is almost zero), doesn't IPv6 give adware companies a very good fingerprint on you?
3. All those ICMPv6 messages sniffing (and snooping?) really don't fill me with joy joy happiness. The only recourse is to read some dead boring RFC that my poor overloaded brain doesn't really want to have anything to do with. With IPv4, if you don't want PING, you turn it off, with IPv6.... it's subtle.
4. Firewalls require two sets of independent entries for the same service.
So, IPv4 is an address space that's understood. IPv6 really does feel like a Godzillian monstrosity and a chore to type in: double colons between every number and it's in Hex? At least with IPv4 you can type the numbers in pretty rapidly on a numpad.
So, I know this answer will be unpopular, especially to professionals, but for everyone I've encountered that's turned it off, the above list is pretty accurate.
Every few years I search around for a true "IPv4 to IPv6 for noobs" and every time I only find "It's the same... with these gajillion subtle differences". So, yeah, perception is definitely an issue, but scoffing at NAT doesn't help uptake at all. I really do try to be a good netizen, but it's hard. (that said, I do have a mail server set up to use ipv6 and all is good... except for the lists of unknown sources who hammer away at its security all day, every day)
I've adopted IPv6 for a small business network I run and it's been great being able to punch small holes in the firewall for certain services without dealing with NAT, port conflicts for software that makes it hard to configure ports, etc. I have a bunch of services that I access there that are configured IPv6-only just because it's so much easier to configure than NAT.
2. MacOS and Windows use IPv6 Privacy Extensions to randomize your address https://en.wikipedia.org/wiki/IPv6_address#Temporary_address...
3. They work great though, I always had weird MTU issues with IPv4 and had to hard-code one in my router, with IPv6 Path-MTU just works. It really annoys me when people turn off ping, stop doing that.
4. Poor UI for firewalls/routers that is not optimized for dual-stack IPv4/IPv6 is indeed a problem. And not just that, home or small business routers often have no IPv6 UI at all for stuff like firewall.
With IPv4 I always had trouble remember exactly what number was what device, with IPv6 it kind of forced my hand to set up DNS entries for everything and that short-term pain (what, 15 minutes?) paid back every time I had to connect to some printer I couldn't remember if it was .218 or .215
2. MacOS and Windows use IPv6 Privacy Extensions to randomize your address https://en.wikipedia.org/wiki/IPv6_address#Temporary_address...
3. They work great though, I always had weird MTU issues with IPv4 and had to hard-code one in my router, with IPv6 Path-MTU just works. It really annoys me when people turn off ping, stop doing that.
4. Poor UI for firewalls/routers that is not optimized for dual-stack IPv4/IPv6 is indeed a problem. And not just that, home or small business routers often have no IPv6 UI at all for stuff like firewall.
With IPv4 I always had trouble remember exactly what number was what device, with IPv6 it kind of forced my hand to set up DNS entries for everything and that short-term pain (what, 15 minutes?) paid back every time I had to connect to some printer I couldn't remember if it was .218 or .215
> I'm used to the pseudo security that a NAT gives.
In consumer routers, port forwarding is the exact same thing as an inbound traffic firewall. But when I turn on IPv6, what is the equivalent? Is my printer still protected from random inbound internet traffic?
On my Netgear R6700, I can't figure it out from the UI or from forum posts/help content. And without being certain, I don't want to turn on IPv6. Even though I'm technical enough to understand IPv6. Because my printer or my light bulb being exposed to the internet is a huge risk that my router is supposed to stop.
In consumer routers, port forwarding is the exact same thing as an inbound traffic firewall. But when I turn on IPv6, what is the equivalent? Is my printer still protected from random inbound internet traffic?
On my Netgear R6700, I can't figure it out from the UI or from forum posts/help content. And without being certain, I don't want to turn on IPv6. Even though I'm technical enough to understand IPv6. Because my printer or my light bulb being exposed to the internet is a huge risk that my router is supposed to stop.
IPv6 firewalls work the same as IPv4 firewalls.
You just remove the NAT from the equation.
The default is deny.
You have to explicitly enable inbound ports.
The difference is that you connect to the device address, not the NAT gateway address.
No more port conflicts.
No more split DNS.
Etc...
You just remove the NAT from the equation.
The default is deny.
You have to explicitly enable inbound ports.
The difference is that you connect to the device address, not the NAT gateway address.
No more port conflicts.
No more split DNS.
Etc...
> In consumer routers, port forwarding is the exact same thing as an inbound traffic firewall. But when I turn on IPv6, what is the equivalent? Is my printer still protected from random inbound internet traffic?
Copy-pasting from a previous discussion a little while ago:
---
IPv4+NAT does not remove any more classes of problems than IPv6+firewall. Firewalls under IPv6 work exactly the same way as they do with IPv4.
An IP connection is started from the 'inside' to the 'outside', and the source-destination tuple is recorded. When an 'outside' packet arrives the firewall checks its parameters to see if it corresponds with an existing connection, and if it does it passes it through. If the parameters do not correspond with anything in the firewall's table/s it assumes that someone is trying to create a new connection, which is generally not allowed by default, and therefore drops it.
The main difference is that with IPv4 and NAT the original (RFC 1918?) source address and port are changed to something corresponding to the 'outside' interface of the firewall.
With IPv6 address/port, rewriting is not done. Only state tables are updated and checked.
New connections are not allowed past the firewall towards the inside with either protocol, and only replies to connections opened from the inside are passed through.
There's no magical security behind NAT: tuples and packet flags are read, looked up in a state table, allowed or not depending on either firewall rule or state presence.
The security comes from the state checking.
[…]
I have a printer with an IPv6 stack. I also have IPv6 addresses from my ISP. Yet somehow my Asus AC-68U prevents the public Internet from reaching my printer.
---
* https://news.ycombinator.com/item?id=28390634
IPv6 firewall on my Asus:
* https://www.asus.com/us/support/FAQ/1013638/
If you want to test, find the IPv6 address of your printer and try pinging it:
* https://tools.keycdn.com/ipv6-ping
Copy-pasting from a previous discussion a little while ago:
---
IPv4+NAT does not remove any more classes of problems than IPv6+firewall. Firewalls under IPv6 work exactly the same way as they do with IPv4.
An IP connection is started from the 'inside' to the 'outside', and the source-destination tuple is recorded. When an 'outside' packet arrives the firewall checks its parameters to see if it corresponds with an existing connection, and if it does it passes it through. If the parameters do not correspond with anything in the firewall's table/s it assumes that someone is trying to create a new connection, which is generally not allowed by default, and therefore drops it.
The main difference is that with IPv4 and NAT the original (RFC 1918?) source address and port are changed to something corresponding to the 'outside' interface of the firewall.
With IPv6 address/port, rewriting is not done. Only state tables are updated and checked.
New connections are not allowed past the firewall towards the inside with either protocol, and only replies to connections opened from the inside are passed through.
There's no magical security behind NAT: tuples and packet flags are read, looked up in a state table, allowed or not depending on either firewall rule or state presence.
The security comes from the state checking.
[…]
I have a printer with an IPv6 stack. I also have IPv6 addresses from my ISP. Yet somehow my Asus AC-68U prevents the public Internet from reaching my printer.
---
* https://news.ycombinator.com/item?id=28390634
IPv6 firewall on my Asus:
* https://www.asus.com/us/support/FAQ/1013638/
If you want to test, find the IPv6 address of your printer and try pinging it:
* https://tools.keycdn.com/ipv6-ping
Ping will still likely work. At least I can ping all my machines on my private network. However, I'm not able to ssh into it or anything else, because all traffic is dropped.
It all depends on firewall configuration, but I think you may unnecessarily scare people by suggesting they're wide open just because ping works.
It all depends on firewall configuration, but I think you may unnecessarily scare people by suggesting they're wide open just because ping works.
ICMP should be allowed anyways because of MTU path discovery.
stop disabling ping
stop disabling ping
> ping
True. There are IPv6 port scanners available:
* http://www.ipv6scanner.com/cgi-bin/main.py
* https://www.subnetonline.com/pages/ipv6-network-tools/online...
True. There are IPv6 port scanners available:
* http://www.ipv6scanner.com/cgi-bin/main.py
* https://www.subnetonline.com/pages/ipv6-network-tools/online...
All right, but assuming I have a dynamic DNS setup, how do I connect to one of the hosts in my network?
I think most OSes do that privacy thing where they periodically randomize the suffix of their v6 address.
I think most OSes do that privacy thing where they periodically randomize the suffix of their v6 address.
Your hosts will also use SLAAC to determine their permanent 'management' address, that's the one you use for connecting _to_ them.
The 'management' address won't be used as the source addrrss packets originating _from_ the host unless the use of temporary/privacy addresses is disabled.
The 'management' address won't be used as the source addrrss packets originating _from_ the host unless the use of temporary/privacy addresses is disabled.
I need to remove IPv4 from my home network so that I can finally try and understand all mechanics around it properly.
If you've not seen it before - check out https://ipv6.he.net/certification/ - it's a pretty neat basic IPv6 training course.
As a matter of fact I'm an "enthusiast" already, but since I was using the HE tunnelbroker I was banned from several services, I'll have to get a VPS with a /56 or smth and wireguard over it. I'm a bit uncertain still about MTU so I'm thinking about just fragmenting stuff on 1500 and take the penalty hit (still can't get v6 in most of residential Sweden)
Given the number of addresses available in a /64 IPv6 subnet, pick a value to statically assign to it and use that. If you have a SSH bastion host / jump box, perhaps pick ::22 as the end address part.
A friend assigned ::25 for the service vIP of his SMTP server/process, and ::143 for IMAP. Your web(mail) host could be ::80 and/or ::443. All on the same host (if you wish). If you have an HA setup you can have the vIP failover by using (e.g.) keepalived.
Using tokens may be of some interest as well:
* https://man7.org/linux/man-pages/man8/ip-token.8.html
You can have a public prefix address, as well as a local 'private' ULA address at the same time. In some ways I wish the best practice would be for IoT devices and appliances (like printers) only have link-local addresses, and perhaps ULA if advertised, with global addresses only configured via config switch. It would perhaps allay some the concerns that people have (like you do).
A friend assigned ::25 for the service vIP of his SMTP server/process, and ::143 for IMAP. Your web(mail) host could be ::80 and/or ::443. All on the same host (if you wish). If you have an HA setup you can have the vIP failover by using (e.g.) keepalived.
Using tokens may be of some interest as well:
* https://man7.org/linux/man-pages/man8/ip-token.8.html
You can have a public prefix address, as well as a local 'private' ULA address at the same time. In some ways I wish the best practice would be for IoT devices and appliances (like printers) only have link-local addresses, and perhaps ULA if advertised, with global addresses only configured via config switch. It would perhaps allay some the concerns that people have (like you do).
Home routers (and even small business routers from companies you'd expect better from like Ubiquiti) are often completely missing the UI for stuff like IPv6 firewall and it's a real tragedy and definitely something that is holding back adoption.
> 2. I'm used to the pseudo security that a NAT gives.
If you wish to do this with IPv6 you can with ULA and NPTv6:
* https://en.wikipedia.org/wiki/Unique_local_address
* https://en.wikipedia.org/wiki/IPv6-to-IPv6_Network_Prefix_Tr...
> 3. All those ICMPv6 messages sniffing (and snooping?) really don't fill me with joy joy happiness.
For those wondering: ping works by sending ICMP(v4) echo request packets. If you wish to block v4 ping you block echo requests (Type 8) and echo replies (Type 0):
* https://en.wikipedia.org/wiki/Internet_Control_Message_Proto...
ping6 works by sending ICMP(v6) echo request packets. In IPv6-land block Types 128 and 129:
* https://en.wikipedia.org/wiki/Internet_Control_Message_Proto...
To block traceroute block Types 11 (v4) and 3 (v6): TTL/hop exceeded notifications.
> IPv6 really does feel like a Godzillian monstrosity and a chore to type in: double colons between every number and it's in Hex? At least with IPv4 you can type the numbers in pretty rapidly on a numpad.
We've run out of IPv4 addresses. We need a larger address space with more bits. More bits mean more typing. Get over it? ¯\_(ツ)_/¯
If you wish to do this with IPv6 you can with ULA and NPTv6:
* https://en.wikipedia.org/wiki/Unique_local_address
* https://en.wikipedia.org/wiki/IPv6-to-IPv6_Network_Prefix_Tr...
> 3. All those ICMPv6 messages sniffing (and snooping?) really don't fill me with joy joy happiness.
For those wondering: ping works by sending ICMP(v4) echo request packets. If you wish to block v4 ping you block echo requests (Type 8) and echo replies (Type 0):
* https://en.wikipedia.org/wiki/Internet_Control_Message_Proto...
ping6 works by sending ICMP(v6) echo request packets. In IPv6-land block Types 128 and 129:
* https://en.wikipedia.org/wiki/Internet_Control_Message_Proto...
To block traceroute block Types 11 (v4) and 3 (v6): TTL/hop exceeded notifications.
> IPv6 really does feel like a Godzillian monstrosity and a chore to type in: double colons between every number and it's in Hex? At least with IPv4 you can type the numbers in pretty rapidly on a numpad.
We've run out of IPv4 addresses. We need a larger address space with more bits. More bits mean more typing. Get over it? ¯\_(ツ)_/¯
Please don't block ttl exceeded packets... It will cause some very hard to troubleshoot network issues for someone somewhere sometime.
Amen, brother. Someone like your CEO at somewhere like his lake house at the end of a dodgy DSL line from Cletus's ISP and Bait Shop.
I kid, I kid...they didn't sell bait.
There are a lot of unpleasant failure modes to blocking ICMP without completely understanding the implications.
I kid, I kid...they didn't sell bait.
There are a lot of unpleasant failure modes to blocking ICMP without completely understanding the implications.
I agree… but some folks seem to think blocking ping and traceroute give you some kind of extra security.
Your arguments regarding NAT only make sense when considering carrier grade NAT.
With IPv6 you can set up your machine to use "temporary" addresses which will use random addresses from your router's subnet instead of a fixed one (based off of the NIC's mac address) and for a limited duration. The duration is normally some number of hours, but you could make it 10 seconds if you preferred.
With IPv6 you can set up your machine to use "temporary" addresses which will use random addresses from your router's subnet instead of a fixed one (based off of the NIC's mac address) and for a limited duration. The duration is normally some number of hours, but you could make it 10 seconds if you preferred.
> Last time I checked, IPv6 was just so wrong...
> I'm used to the pseudo security that a NAT gives
> my poor overloaded brain doesn't really want to have anything to do with
You've certainly made the point that you are too lazy to learn. Otherwise, you haven't made a case against IPv6 at all.
> I'm used to the pseudo security that a NAT gives
> my poor overloaded brain doesn't really want to have anything to do with
You've certainly made the point that you are too lazy to learn. Otherwise, you haven't made a case against IPv6 at all.
The point is that many people are too lazy to learn a more complicated alternative to something simple they've used for a long time. And that's why ipv6 still hasn't taken off in many areas.
> 4. Firewalls require two sets of independent entries for the same service.
Depends on the exact rule you're writing, but nftables can remove a lot of duplication. Many rules cover both IPv4 and IPv6. It's the default since Debian 11.
Depends on the exact rule you're writing, but nftables can remove a lot of duplication. Many rules cover both IPv4 and IPv6. It's the default since Debian 11.
Agree with every single point. I guess that is the difference from user perspective to engineering perspective.
I often wished there was just a simple IPv5.
I often wished there was just a simple IPv5.
Don't touch ICMP, just don't.
http://shouldiblockicmp.com
https://rachelbythebay.com/w/2015/05/15/pmtud/
> sniffing (and snooping?)
Nothing is new here. ND is basically what ARP was. You don't disable ARP, do you?
http://shouldiblockicmp.com
https://rachelbythebay.com/w/2015/05/15/pmtud/
> sniffing (and snooping?)
Nothing is new here. ND is basically what ARP was. You don't disable ARP, do you?
technically, you cannot even disable ARP because of it inherent reliance on ethernet...
Atleast ND is a proper layer 3 seperation of link-layer discovery..
Atleast ND is a proper layer 3 seperation of link-layer discovery..
> What about IPv6 makes it such a chore to become widespread?
IPv6 is not just a straightforward extension of IPv4 to bigger addresses (plus some cleverness for how to route between them, if at all).
There's a whole lot of other complexity in the protocol. There's a way you're supposed to get addresses that's not DHCP, and a good chunk of clients don't have or only recently got a DHCPv6 implementation. You're supposed to have an efficient hardware multicast implementation. Addresses are structured (unlike IPv4 CIDR), and an entire /64 is supposed to be assigned to a single customer / subnet so they can auto-configure addresses based on that. In turn, the way to auto-configure your (NAT-less) IPv6 address was to use your MAC address, i.e., give advertisers a free permanent third-party cookie, and the RFC to do something else only came out in 2007.
And, of course, for better or worse people have designs that involve NAT, and until very recently IPv6 basically demanded that you rip all of it out.
Regardless of whether you think these changes are good or not, they are certainly a chore.
IPv6 is not just a straightforward extension of IPv4 to bigger addresses (plus some cleverness for how to route between them, if at all).
There's a whole lot of other complexity in the protocol. There's a way you're supposed to get addresses that's not DHCP, and a good chunk of clients don't have or only recently got a DHCPv6 implementation. You're supposed to have an efficient hardware multicast implementation. Addresses are structured (unlike IPv4 CIDR), and an entire /64 is supposed to be assigned to a single customer / subnet so they can auto-configure addresses based on that. In turn, the way to auto-configure your (NAT-less) IPv6 address was to use your MAC address, i.e., give advertisers a free permanent third-party cookie, and the RFC to do something else only came out in 2007.
And, of course, for better or worse people have designs that involve NAT, and until very recently IPv6 basically demanded that you rip all of it out.
Regardless of whether you think these changes are good or not, they are certainly a chore.
Having implemented SLAAC and address anonymization:
These are very, very simple protocols.
These are very, very simple protocols.
Oh, sure, but my point isn't about implementation complexity, it's about network architecture.
SLAAC doesn't work the way DHCP works. Do you have an IPAM tool that assigns addresses? Do you have a VMM/private cloud where addresses are in a database and you set up firewall rules? Do you have a guest wifi network where you assign a quarantine IP with a short lease and then a real IP once they authenticate? None of that works with SLAAC.
Especially if you have an existing IPv4 network and are rolling out dual-stack and have no interest in breaking IPv4, adding IPv6 via SLAAC is hardly a matter of adding another column in your schema. It's an architectural change.
Again, maybe that change is good, but that's the chore - not implementing the protocol (which is basically ip link | sed | ip addr add).
For privacy addresses, if you were considering implementing IPv6 before they were widespread, you'd have to figure out a way to keep from leaking them. The obvious approach is NAT, but that's effectively not an option. So you decide not to make IPv6 available to clients, only servers that already have fixed IPv4 addresses and don't roam. Or you do manual (non-SLAAC, non-DHCPv6 because that wasn't an option) configuration. Once they became available and common in people's clients, sure, but that means we didn't have "20 years" for people to offer IPv6 on guest wifi networks, we had a lot less.
Same with NATs. Implementing "not using a NAT" is absolutely trivial; you just... don't. Redesigning your network architecture not to use one, however meritorious it may be, is a massive task.
SLAAC doesn't work the way DHCP works. Do you have an IPAM tool that assigns addresses? Do you have a VMM/private cloud where addresses are in a database and you set up firewall rules? Do you have a guest wifi network where you assign a quarantine IP with a short lease and then a real IP once they authenticate? None of that works with SLAAC.
Especially if you have an existing IPv4 network and are rolling out dual-stack and have no interest in breaking IPv4, adding IPv6 via SLAAC is hardly a matter of adding another column in your schema. It's an architectural change.
Again, maybe that change is good, but that's the chore - not implementing the protocol (which is basically ip link | sed | ip addr add).
For privacy addresses, if you were considering implementing IPv6 before they were widespread, you'd have to figure out a way to keep from leaking them. The obvious approach is NAT, but that's effectively not an option. So you decide not to make IPv6 available to clients, only servers that already have fixed IPv4 addresses and don't roam. Or you do manual (non-SLAAC, non-DHCPv6 because that wasn't an option) configuration. Once they became available and common in people's clients, sure, but that means we didn't have "20 years" for people to offer IPv6 on guest wifi networks, we had a lot less.
Same with NATs. Implementing "not using a NAT" is absolutely trivial; you just... don't. Redesigning your network architecture not to use one, however meritorious it may be, is a massive task.
Modern IPAMs do work with IPv6 - routers know what hosts have performed SLAAC and can report that (see e.g. https://documentation.solarwinds.com/en/success_center/ipam/...)
If addresses are in a database and you set up firewall rules, you set up your clients to consistently use the same local suffix. This is approximately the same amount of work as setting up a fixed DHCP lease for a host, or setting up a static IPv4 address. Once this is done, firewall configuration is exactly the same as v4, just with a different address format.
Using a quarantine IP for new clients is a really weird way of doing things that I never saw in 5 years of working on mostly-v4 SMB enterprise environments. Clients don't support it well and never have, and revoking the lease on demand is a pain. Everyone already uses plain old firewall rules plus DNS hijacking to force people onto splash pages. If you do something that deeply weird, you're going to run into problems every time Apple slightly changes (shudder) iOS DHCP expiration logic, let alone during transition to IPv6.
You can still NAT if you want to on IPv6; you just don't have to. (In fact, NAT between an internal v6 and an external v4 network is a very widely deployed transition technology!)
If addresses are in a database and you set up firewall rules, you set up your clients to consistently use the same local suffix. This is approximately the same amount of work as setting up a fixed DHCP lease for a host, or setting up a static IPv4 address. Once this is done, firewall configuration is exactly the same as v4, just with a different address format.
Using a quarantine IP for new clients is a really weird way of doing things that I never saw in 5 years of working on mostly-v4 SMB enterprise environments. Clients don't support it well and never have, and revoking the lease on demand is a pain. Everyone already uses plain old firewall rules plus DNS hijacking to force people onto splash pages. If you do something that deeply weird, you're going to run into problems every time Apple slightly changes (shudder) iOS DHCP expiration logic, let alone during transition to IPv6.
You can still NAT if you want to on IPv6; you just don't have to. (In fact, NAT between an internal v6 and an external v4 network is a very widely deployed transition technology!)
Ah, well, I'll just modernize my IPAM, no big deal....
I have actually seen quarantine IPs for new clients, if memory serves - it was on MIT's wifi network in the late '00s, back when MIT still had all of 18/8 and gave everyone a public un-NATted IP (just firewalling port 25/445/etc.). You'd get a 10/8 address to connect to the captive portal, and then once you authenticated you'd have to renew your IP lease to get on the network. (They eventually switched to 802.1x and no captive portal.)
Long story short, my experience is that everyone is doing at least one silly thing with their networking ("write your own IPAM" is distressingly common, for instance), and even if everyone agrees is in fact silly, it requires some sizable project planning and expense to stop doing it. Certainly a lot of people have managed to implement IPv6 just fine - a good chunk of the internet is on IPv6. But a lot of people haven't, and I don't think the primary cause is laziness.
I have actually seen quarantine IPs for new clients, if memory serves - it was on MIT's wifi network in the late '00s, back when MIT still had all of 18/8 and gave everyone a public un-NATted IP (just firewalling port 25/445/etc.). You'd get a 10/8 address to connect to the captive portal, and then once you authenticated you'd have to renew your IP lease to get on the network. (They eventually switched to 802.1x and no captive portal.)
Long story short, my experience is that everyone is doing at least one silly thing with their networking ("write your own IPAM" is distressingly common, for instance), and even if everyone agrees is in fact silly, it requires some sizable project planning and expense to stop doing it. Certainly a lot of people have managed to implement IPv6 just fine - a good chunk of the internet is on IPv6. But a lot of people haven't, and I don't think the primary cause is laziness.
I mean. When it's stuff people have to do for work and they're not doing it, and that happens on a systemic level? Usually it's not "laziness", it's just that there's always lots of work and there's never enough money/man-hours.
The main point I'm trying to make is that this has nothing to do with the technical characteristics of IPv6 itself. By definition, a layer 3 protocol interacts with every single piece of network-related software out there. You have to update everything, and that's a whole lot of work no matter how you cut it. It only takes one awful hack like that MIT thing you described (whyyyyyyyyyyy) to hold up an entire migration.
(If I were MIT, I would suggest turning off router advertisements ie the infrastructure side of SLAAC, and only serving addresses over DHCPv6. Gets you an easier port of hacky shit like that.)
The main point I'm trying to make is that this has nothing to do with the technical characteristics of IPv6 itself. By definition, a layer 3 protocol interacts with every single piece of network-related software out there. You have to update everything, and that's a whole lot of work no matter how you cut it. It only takes one awful hack like that MIT thing you described (whyyyyyyyyyyy) to hold up an entire migration.
(If I were MIT, I would suggest turning off router advertisements ie the infrastructure side of SLAAC, and only serving addresses over DHCPv6. Gets you an easier port of hacky shit like that.)
Having done some work on implementation/migration:
EVERYTHING needs to work.
There's a hell of a lot of software (and, even worse, hardware) that encodes assumptions about IPv4. Everything from userspace asking specifically parsing only IPv4 addresses, to only listening for IPv4 incoming connections, to variables using the IPv4-only type, &c. And let's not even start on the L3 hardware acceleration built into so much networking equipment.
You can't flip the switch when 75% of the stuff on your device is ready. The remaining 25% will break, badly. You need to switch over every single piece of code. And then before you get any benefit out of it, you need to do the same on every remote system you want to talk to.
This is the magic and the terror of internetworking. Before IP, you had to go through this nightmare for changes at many different layers of the stack. With the clean-ish separation of IP, only one layer was make-or-break like this: layer 3. Any change to layer 3 is horrifically difficult, purely as a deployment/management challenge.
EVERYTHING needs to work.
There's a hell of a lot of software (and, even worse, hardware) that encodes assumptions about IPv4. Everything from userspace asking specifically parsing only IPv4 addresses, to only listening for IPv4 incoming connections, to variables using the IPv4-only type, &c. And let's not even start on the L3 hardware acceleration built into so much networking equipment.
You can't flip the switch when 75% of the stuff on your device is ready. The remaining 25% will break, badly. You need to switch over every single piece of code. And then before you get any benefit out of it, you need to do the same on every remote system you want to talk to.
This is the magic and the terror of internetworking. Before IP, you had to go through this nightmare for changes at many different layers of the stack. With the clean-ish separation of IP, only one layer was make-or-break like this: layer 3. Any change to layer 3 is horrifically difficult, purely as a deployment/management challenge.
this comments hit up a good point,
the lower in the OSI stack you go, the harder it is to initiate change.
There is still some (mostly industrial) hardware that has lackluster TCP/IP support at best (for instance, assuming the netmask is always a /24...).
migrating these networks to ipv6 is not possible, and doing 6to4 adds a crapton of complexity.
the lower in the OSI stack you go, the harder it is to initiate change.
There is still some (mostly industrial) hardware that has lackluster TCP/IP support at best (for instance, assuming the netmask is always a /24...).
migrating these networks to ipv6 is not possible, and doing 6to4 adds a crapton of complexity.
It's not about "lower".
We can, and do, make massive , non-backwards-compatible changes in layers 1 and 2 every few years and no one is the wiser. Layer 3 is special. It makes that flexibility in all the other layers possible, but keeps none for itself.
We can, and do, make massive , non-backwards-compatible changes in layers 1 and 2 every few years and no one is the wiser. Layer 3 is special. It makes that flexibility in all the other layers possible, but keeps none for itself.
mind you though, that layer 3 and 4 are somewhat interlinked.
Give it another 20 years...
https://www.google.com/intl/en/ipv6/statistics.html
https://www.google.com/intl/en/ipv6/statistics.html
looks like another 10 years at most going by the current rate. And I expect it will speed up at the end when we reach something like 90% and some sites go v6 only.
Note that this is measuring clients of Google services. It's useful for tracking consumer ISPs, but applications that really benefit from e2e connectivity have been and will be moving faster.
IPv6 adoption is slowing and may never converge with v4. It halved from 2019 to 2020. See "Counting IPv6 users":
https://blog.apnic.net/2021/02/08/ipv6-in-2020/
https://blog.apnic.net/2021/02/08/ipv6-in-2020/
>What about IPv6 makes it such a chore to become widespread?
Partly some protocol choices which are quite different from IPv4, but much more importantly - existing users see relatively little benefit from conversion, so most new IPv6 installs are new installations.
Eventually the monetary pressure would be enough to get a critical mass to switch, but this hasn't happened yet.
Partly some protocol choices which are quite different from IPv4, but much more importantly - existing users see relatively little benefit from conversion, so most new IPv6 installs are new installations.
Eventually the monetary pressure would be enough to get a critical mass to switch, but this hasn't happened yet.
> What about IPv6 makes it such a chore to become widespread?
Any code storing an IPv4 address in a uint32_t can be hard to port to IPv6. Likewise, many codebases have their own ad hoc parsers for IPv4 dotted quads and would choke on anything else.
Any code storing an IPv4 address in a uint32_t can be hard to port to IPv6. Likewise, many codebases have their own ad hoc parsers for IPv4 dotted quads and would choke on anything else.
The additional 12 bytes to store the v6 address might not be trivial to find as well (connection state tables in kernels, additional space in DBs). There's also MTU issues.
It's all about incentive I guess. What do they win by supporting ipv6?
From the service provider point of view, as long as their customers can reach them with ipv4, they have no reasons to switch.
From the customer ISP point of view, as long as services people use provide an ipv4 option, there is no reasons to switch.
Maybe the ones that have the most reasons to switch are new internet services and new ISP which might have a hard time getting ipv4 blocks. But that's just one more reason for established services not to move too fast :/
From the service provider point of view, as long as their customers can reach them with ipv4, they have no reasons to switch.
From the customer ISP point of view, as long as services people use provide an ipv4 option, there is no reasons to switch.
Maybe the ones that have the most reasons to switch are new internet services and new ISP which might have a hard time getting ipv4 blocks. But that's just one more reason for established services not to move too fast :/
Not only do you have to support ipv6, ipv4 will never go away on any meaningful timescale. So even if you do the right thing and deploy it you still have the same ipv4 address constraints. There is no winning.
Even at organizations that have considerably smaller networks than Google, Amazon, Facebook and Co there are just seemingly insurmountable numbers of "small" problems that discourage all the involved parties to adopt.
We had IPv6 at our research area 10 years ago. Admins changed, and it was wind down bit by bit, because "it made problems". Not only that, I learned that the the general view over all of the admin-staff in our organization (a larger "Technical university" in Europe) agreed that IPv6 "makes problems" and nobody wants it.
Change is painful...? It is a shame, but what can you do?
We had IPv6 at our research area 10 years ago. Admins changed, and it was wind down bit by bit, because "it made problems". Not only that, I learned that the the general view over all of the admin-staff in our organization (a larger "Technical university" in Europe) agreed that IPv6 "makes problems" and nobody wants it.
Change is painful...? It is a shame, but what can you do?
Why change something that works?
HTTP/1.1 also "works", yet we are moving to v2 (edit: more smoothly).
Same for many other (low level) techs.
But maybe IPv6 is so low level that it has a lot more inertia...
But maybe IPv6 is so low level that it has a lot more inertia...
Because we're running out of IPv4 addresses, and in a lot of cases, NAT doesn't work.
> Because we're running out of IPv4 addresses, and in a lot of cases, NAT doesn't work.
We have run out of IPv4 addresses. Past tense. Go to a RIR for some and you'll be put on a waiting list.
If you want a block of IPv4 space you'll be paying about US$ 30 per IP at the moment.
We have run out of IPv4 addresses. Past tense. Go to a RIR for some and you'll be put on a waiting list.
If you want a block of IPv4 space you'll be paying about US$ 30 per IP at the moment.
Video chat. File transfers without a third party host. Cell phones almost always only offer a public address over v6. Internet gaming. VPNs without address conflicts. Not being banned from Wikipedia because someone else with the same CGNAT ISP got banned.
For the average consumer they don't notice a difference. Both my home and mobile ISPs have said they have no plans to offer IPv6 connectivity because it's not a requirement.
Users don't care, and until a lot of them do ISPs won't do anything.
People can still video chat, play games and use VPNs without v6.
Users don't care, and until a lot of them do ISPs won't do anything.
People can still video chat, play games and use VPNs without v6.
It usually manifests as gamers asking about "strict NAT":
https://support.xbox.com/en-US/help/hardware-network/connect... https://kb.netgear.com/19844/Why-does-my-Xbox-say-NAT-is-set...
Part of why video chat quality sucks is because the RTP traffic has to be sent through a proxy to deal with NAT, doubling load on the Internet and increasing latency.
https://support.xbox.com/en-US/help/hardware-network/connect... https://kb.netgear.com/19844/Why-does-my-Xbox-say-NAT-is-set...
Part of why video chat quality sucks is because the RTP traffic has to be sent through a proxy to deal with NAT, doubling load on the Internet and increasing latency.
Because you want to use something better?
> Why change something that works?
Because it does not work.
Want to run a public service with end-to-end connectivity? Go to your RIR to request an IPv4 block and be put on a waiting list.
Or break out your cheque book and be prepared to cough up $35+/IP for the privilege of global connectivity:
* https://auctions.ipv4.global
* https://ipv4marketgroup.com/ipv4-pricing/
* https://ipv4connect.com/marketplace
Because it does not work.
Want to run a public service with end-to-end connectivity? Go to your RIR to request an IPv4 block and be put on a waiting list.
Or break out your cheque book and be prepared to cough up $35+/IP for the privilege of global connectivity:
* https://auctions.ipv4.global
* https://ipv4marketgroup.com/ipv4-pricing/
* https://ipv4connect.com/marketplace
A friends company that was able to buy two /24s under $2K each and get them pretty quick.
When I signed up for a new data center internet connection, both my ISPs charged me something like $25/month for a /24.
IPv4 addresses are still relatively cheap to get.
When I signed up for a new data center internet connection, both my ISPs charged me something like $25/month for a /24.
IPv4 addresses are still relatively cheap to get.
Remember when IPv4 addresses were assigned/given out for free? Pepperidge Farms remembers. :)
When did the company purchase them? Was it a private sale or through a broker(?)? I'm curious as to the process, especially if it was more recent.
When did the company purchase them? Was it a private sale or through a broker(?)? I'm curious as to the process, especially if it was more recent.
Two reasons. First, it's just inertia and backward compatibility. Same reason we still use the x86 instruction set in spite of its issues. Second reason is that long IPs really are kind of inconvenient for IT and network administrator people.
IT and network admin people gripe about the long addresses, but when push comes to shove they don't actually make decisions based on that.
That is a pleasantly concise announcement.
We have created perhaps an easier documentation on how to make it all work on your own domain, with many screenshots and such. Here it is: https://www.orgpad.com/s/cjzpkTRIK_L
One interesting observation about IPv6 I've made is that in Europe IPv6 and FTTx seem inversely correlated. For example Spain is one of the leaders in FTTx with 87% of homes covered, but have only 3% IPv6 adoption according to Google. Meanwhile Germany has one of the highest IPv6 adoptions in Europe, 52%, and one of the lowest FTTx coverages (16%). Latvia, Lithuania, Belarus, and Iceland all have 90% FTTx and 10% IPv6. UK, Finland, Belgium, and Netherlands on the other hand seem to be having better IPv6 adoption than FTTx.
My guess is that ISPs must have needed to choose if to invest to core network or to last mile, and that is visible here. But at the same time it seems bit weird that you'd in 2020s deploy fancy new fiber networks without IPv6.
My guess is that ISPs must have needed to choose if to invest to core network or to last mile, and that is visible here. But at the same time it seems bit weird that you'd in 2020s deploy fancy new fiber networks without IPv6.
[deleted]
[deleted]
I wouldn't count it like that.
Germany's top provider Deutsche Telekom has a market share of around 40% and has enabled IPv6. Vodafone as well.
> My guess is that ISPs must have needed to choose if to invest to core network or to last mile, and that is visible here. But at the same time it seems bit weird that you'd in 2020s deploy fancy new fiber networks without IPv6.
Well there's no real value connecting to an IPv6 island. The Internet is still IPv4.
Well there's no real value connecting to an IPv6 island. The Internet is still IPv4.
Took way too long for this to happen
Offtopic, but still relevant: Github pages could also use to get a newer Jekyll version...
Now how about GitHub itself?
I know it’s all the rage to say “gee why no v6 yet?”, but that’s a LOT of infrastructure and testing to overhaul…
The effort is much appreciated!