Is it just me or did we actually start regressing in terms of moving things off IPv4? A couple of years ago I had a working IPv6 connection at home with a static /64 delegation. I had full IPv6 connectivity at work. Since I had IPv6 connectivity on my laptop ~90% of the time I actually moved a lot of my own private services to be IPv6 only, since that helped a lot with the usual background of port scans and other random annoyances.
Now I'm forced to move these things back to IPv4. My home ISP has first moved off static delegations in favor of dynamic ones via DHCPv6, and then broke IPv6 routing completely [1] and after a few weeks of me complaining still seemingly has no interest in fixing it. The place I work for now has no IPv6 connectivity and has no plans for it in the future. Many people I talk with don't believe that IPv6 is the future and I commonly hear that they have forcibly disabled it on their computers due to this or that random problem.
I'm not sure about regressing, but I think we've almost reached peak IPv6: everyone who planned to support IPv6 have upgraded their software and infrastructure, those that were sceptical, lazy or downright opposed to IPv6 have no plans to support it, now or ever.
Having an "ipv6" configuration option in your software, which defaults to false, falls into the latter group. (Hello, Docker!)
Having IPv6 turned off by default is not the only Docker problem with IPv6. When I tried to use IPv6 in Docker couple of years ago I found it to be unusable for my use case. I don't remember details, but remember finding tickets in github issue tracker with long discussions which went nowhere.
It's been a steady linear increase for the past three years, now over 30%.
Interestingly, zoom in to 2020, and you'll see the effect of the coronavirus lockdown--all those home workers and people in self-isolation on IPv6 rather than on IPv4-only work networks.
With the increase in dependence upon cloud computing and containers, I believe that one of the big blockers today is the poor support for IPv6 by cloud providers and by docker and other virtualisation/container systems. Their lack of IPv6 support is what precludes wider adoption on client systems and internally in companies. Pervasive IPv6 support would be reason to use it, but right now it's a hindrance.
My ISP had a page about IPv6, but they've since removed it and when asked now say IPv6 is only supported by their own router box. They do DHCPv6 as well, with a single /64. Which makes IPv6 a PITA.
Of course it doesn't help that a lot of software (hello pfSense) is written around the idea that everybody will get a static /56 or similar that'll never ever change. Which is a pretty silly assumption IMHO.
My ISP (Telenet in Belgium) may just be unusually good, but, while there's fairly sparse documentation on IPv6 and their DHCPv6 only gave me a /64 by default, all I needed to do to get more was to configure my router's DHCP client to request a larger delegation. I didn't need to even contact their support line.
At the moment I'm only asking for a /60, because that's all I need, but I strongly suspect that a /56 or even larger is easily available.
I do blame "Happy Eyeballs". Broken IPv6 has become invisible and therefore unimportant for ISPs.
Disabling IPv6 because of some -maybe imagined- problem is akin to disabling every new tech because it might be to blame. Tech will just progress one admin funeral at a time here.
> Disabling IPv6 because of some -maybe imagined- problem
I've had very real IPv6 problems at home, which has caused me to disable it for long stretches. I turn it back on every now and then to see if life has improved though.
Most of my issues have been down to my ISP only handing out a dynamic /64 prefix. Apparently that's not how you do it and the software side doesn't seem to want to accommodate that, but that's what I got so...
> Most of my issues have been down to my ISP only handing out a dynamic /64 prefix.
Yes, this is my biggest issue with the move to dynamic prefix delegation as well. Delegated prefix change seems to be handled very badly in the stack. It basically breaks all your IPv6 connectivity until LAN hosts get to renew their DHCPv6 leases and/or SLAAC autoconfiguration. Even connectivity between hosts on the LAN will break, since their addresses will slowly change while they update.
The funny part is that I now have a static IPv4 and a dynamic IPv6 - a situation I would never imagine could happen.
Agreed. ISPs only handing out /64 is very aggravating, because one can not subdivide them without breaking SLAAC. One can hand out smaller subnets with DHCPv6, but that is broken in a lot of clients that assume /64 subnets blindly somewhere.
For me it basically breaks all connectivity, because pfSense tells LAN clients to use the public IPv6 address for DNS. So when the prefix changes pfSense updates its public IP, but LAN clients still try to use the old address for DNS resolution.
I've tried to get pfSense to only use IPv4 for DNS address, but I've so far been unsuccessful.
There's also the issue of updating firewall rules.
I'd recommend using ULA addresses for things like local dns servers.
When I was with my old ISP, we'd have our prefix dynamically delegated so I gave important servers ULA addresses. I then used some iptables scripts to allow traffic to my IPv6 services by looking only at the host part of the address, so if the prefix changed, the firewall rules would still be valid and allow access. That coupled with dynamic dns made it possible to still have a reasonably good network.
Since my new ISP gives us static everything, it's all so much easier. I really don't get the point of PD for IPv6. Or atleast, do PD but always assign the same prefix.
> I really don't get the point of PD for IPv6. Or atleast, do PD but always assign the same prefix.
IPv6 allocation rules. They wanted to avoid the situation that happened with IPv4, so the address block are licensed for use and renewed on regular basis, so they can change. There's no such thing as fixed or static IPv6 address, it is dynamic, turtles all the way down. Hence DHCP-PD.
> They wanted to avoid the situation that happened with IPv4,
This is directly contrary to what I've heard. Maybe my information is bad, or out of date, but I had thought that IPv6 addresses were meant to be static. I thought one of the selling points was that we couldn't run out of IPv6 addresses, as they were so numerous. If we're going to keep them dynamic, why even force this monstrous 128-bit number on us?
As far as I've understood, they wanted a little of everything.
IPv6 addresses should be more static short to medium term, because you don't have to reassign. Your local pool is basically infinite, so e.g. a client logging off the WiFi doesn't mean you immediately have to recycle the address. The local part (the latter 64 bits) is enough for everything and everyone.
Now, the first 64 bits should be used for routing, which should preferably be more hierarchical than with IPv4. The idea was that a customer/company/small ISP would get a prefix assigned that was below the hierarchy of the upstream ISP (with IPv4, that hierarchy isn't possible because there aren't enough address bits, and lots of lower-tier customers got their own subnets). So a large ISP might be assigned 2345::/16, assign 2345:6789::/32 to a smaller ISP who might assign 2345:6789:abcd::/48 to a customer (who then will do more subnetting with that). That keeps the global and local routing table small, since everyone just needs to look at the address prefix to know where to route to. If the customer now moves to another ISP, he is assigned a new prefix (e.g. 4711:f0f0:666::/48) by the new ISP and needs to renumber, meaning that all the customers addresses keep their suffix but change their prefix. Protocols like SLAAC where designed as stateless to support (among other things) quick and easy renumbering. Just announce the new prefix, wait a TTL and you are done. Clients automatically switch over to the new addresses, in an ideal world this is mostly transparent to the end user.
In the new millenium, especially after Snowden, the argument of privacy got stronger, meaning that randomised local /64 suffixes are now en vogue, as opposed to the earlier MAC-based static suffixes.
Therefore everything is more dynamic and also more static ;)
Yeah I looked at setting up v6 on all my home boxes a few years ago, and the situation sucked. I basically can't get a static IPv6, in spite of the fact that though I technically have a dynamic IPv4 from my ISP, it never changes. So now I'd have to go setup dynamic DNS and a bunch of other stuff to get it working. With the size of IPv6 address space, I figure ISPs should have no problem handing out static IPv6 addresses.
I don't think we're regressing as a whole, but current penetration is fairly low, so odds of moving to a company with IPv6 is low, and if you moved from a company with IPv6, you're likely to lose it.
Some ISPs consider it critical, but most don't. If they have enough IPv4 addresses, given that there's no high profile IPv6 only things, and that Happy Eyeballs is fairly well implemented, only a couple people are going to notice. Also, given the success some large networks are having with deploying IPv6, there's less pressure on IPv4 resources.
Happy Eyeballs itself is a compromise --- it hides broken configurations, so people who could fix things might not notice / be told IPv6 is broken, but it also hides broken configurations so people who can't fix things don't just turn off IPv6 forever, which leads to higher use when it does work.
"Many people I talk with don't believe that IPv6 is the future and I commonly hear that they have forcibly disabled it on their computers due to this or that random problem."
It is their choice to make not anyone else's. They could be right. It might not be the future. I am one of those non-believers. I would love an improved protocol but I do not see IPv6 as the right fit. I think it is no coincidence that the providers are having problems with offering it to customers. Networking is complex and error-prone enough without IPv6. It is less so with IPv6? We know what the IPv6 zealots will say. Beware of "analyses" that focus solely on benefits without considering costs.
I think GP was criticizing that this might be the correct choice for them, given that the rest of the world seems to randomly break v6 and somehow it's acceptable.
That also means that you should beware of "analyses" that ignore the costs of staying on v4 and not doing v6.
NAT, split DNS, VPNs, RFC1918 clashes and renumbering... this stuff isn't free, and most of it is totally unnecessary when you have enough address space.
While the above are real costs, beware of promises that IPv6 will remove, reduce or even lower the cost of doing NAT. As long as there is an IPv4 Internet, NAT will be an integral part of any IPv6 deployment.
It will do all of those things in the right circumstances though.
Dual-stacked eyeball ISPs see over 50% of their traffic go via native v6. If they're CGNATing then that corresponds to a substantial drop in the amount of traffic that needs to be CGNATed, and therefore also a corresponding drop in the cost of the hardware needed to do it.
I had similar problems. I decided to take the dive to IPv6, but it turned out I was getting regularly-changing dynamic IPv6 addresses. I wasn't succeeding in getting ULAs to work, and it was starting to look like IPv6 was a lot of headache with no benefit that I could identify.
The frustrating thing is that they mostly believe IP 4 can be salvaged and stretched to the limit using NAT, but they often forget that we're running out of IPv4 addresses and that's just gonna make thing even more painful over time.
yeah. My ISP actually have a deccent IPv6 implementation (but uses CGNAT unless you pay extra for a fixed IP) but their default router is crappy so I replaced it with a ubiquity ampliFI which is great on IPv4, can more or less fill my gigabit fiber, but on IPv6 it maxes out at 250 megabits. So I get better performance disabling IPv6 :( The isp router have no such issue, just bad WIFI and bad NAT performance for IPv4.
DHCPv6 is broken. Addresses are assigned not based on MAC addresses like in DHCPv4, but based on UUIDs. Whether the UUID is per host, hardware, boot or phase of the moon or just random is essentially random, making it totally useless for any kind of managed network. One might as well just go with the simpler alternative of using SLAAC. Any admin claiming DHCPv6 is somehow better for a managed network than the "anarchy" of SLAAC is deluding themselves.
There are patches and extensions doing MAC address based assignments, but those are only sparsely supported in network hardware and software.
For the configuration tasks that DHCP also is used for beyond address assignment, there are better alternatives like anycast, zeroconf and SLAAC extensions. The only thing that would make DHCP useful again in 2020 would be strong cryptographic authentication for devices, maybe tied in with 802.1x and MAC layer encryption.
Therefore I think android is just ahead of the curve in getting rid of DHCPv6.
From RFC8415: DUID used by a client or server SHOULD NOT change over time if at all possible.
Read the fine article. The reasons are mostly the same as DHCP on v4. The ability to assign a specific IP to a specific device for what ever reason: Adding reverse DNS, tracking given IP to specific device etc.
It might not be useful against hostile actors (just like ipv4 DHCP) but its perfectly fine for everyone else.
And the specific argument that "Using it might encourage nat on ipv6" is about as condescending as saying "Using your computer might encourage you to look at naughty pictures".
Android is now the ONLY operating system that doesn't support this and in many ways is harming the uptake of IPV6 because of this. Not being able to use DHCPv6 for Android reduces the chances of an organisation using DHCPv6 for everything else which reduces the pressure on vendors to fix any DUID bugs.
The reasons are the same, agreed. However, the mechanisms DHCPv6 provides are broken beyond what DHCPv4 has historically provided: With DHCPv4, I can deploy a device by scanning the MAC address barcode and configure the autoinstall/autoconfiguration. With IPv6, I can't, the DUID and IAID is assigned on OS installation for the OS DHCPv6 client. The PXE DHCPv6 client will use a different set of DUID and IAID which sometimes, but not always will be based on the system GUID. Also, the system GUID will sometimes be printed on the packaging, often it won't. So the "enterprise unboxing" experience is atrocious with DHCPv6 anyways. For android devices things are similarly broken, there is no PXE, however, one can't correlate the IPv4 and IPv6 addresses for one device because the mac address as a shared identifier isn't usable in DHCPv6 in most cases anyways.
Things could be fixed, but since historically the DHCPv6 standard has not included those fixes and just added them later as extensions, things look rather grim for boot firmware and network equipment.
If you need a proper device identification that cannot be faked, you are out of luck in any case. Therefore my suggestion of a possible next-generation protocol that would also solve the problem of confirming device identity by proper cryptographic authentication.
Also, DUID behaviour is not buggy, your own post cites DUID stability as "SHOULD NOT change". So all the changing DUIDs are conformant. The standards were broken from the beginning and it is too late to change them now.
> With DHCPv4, I can deploy a device by scanning the MAC address barcode and configure the autoinstall/autoconfiguration. With IPv6, I can't, the DUID and IAID is assigned on OS installation for the OS DHCPv6 client.
DUID-LL is link layer address based and if your link layer address is a burned-in MAC you can definitely just scan a barcode, generate a DUID-LL from it and look for that DUID in your DHCP traffic. Your product could use a run-time generated DUID-UUID or some other scheme that can't practically be printed on the product, but on the other hand a DHCP (v4) using product could randomize its link layer address on every boot to the same effect.
That conclusion fundamentally invalidates your original conclusion, though. The problem isn't that "DHCPv6 is broken" but that you have a use case which a certain product someone wants to bring onto the network doesn't satisfy.
The "product" is DHCPv6 and it doesn't solve the use case it is supposed to solve: managed networks and enterprises.
As for random hardware and software products on the network: It would be nice for criteria like "proper IPv6 support" to be blockers, but they aren't for lack of choice. Almost no product out there has anything resembling proper IPv6 support. Just try some fresh deployment of anything in a IPv6-only network, I dare you :)
I run my home desktop and many of my VMs as v6-only and almost everything works fine.
There are a few things that have a problem (mostly games, for some reason), but not many. Though I could imagine "enterprise-grade" software, which often seems to be worse than open-source software, having similar problems.
This is all correct, but is it an argument for never supporting DHCPv6 as an alternative in Android for those who want it and are prepared to deal with the brokenness (assuming it's broken for them)?
Well, most arguments in the original article for DHCPv6 in android are based on things that either do not apply to android or are better solved without DHCPv6:
- DNS search paths can be set with RFC8106 RA options
- Changing DNS servers can be done the same way via RA options or via Anycast addresses
- tracking IP-host-assignments are better done with 802.1x, MAC filters and ARPwatch/NDwatch (One might use DHCP snooping, but that is usually broken with DHCPv6, also in this case, the security is in the snooping and blocking part, not the DHCP part). Everything else is really easy to fake and therefore useless.
- WLC options are only relevant in the control network of your WIFI which shouldn't really be shared with any android device
- VoIP phones should be a separate ESSID/VLAN/network because of QoS and security anyways. Also, most VoIP equipment doesn't properly handle IPv6 anyways, Let alone IPv6-only.
The only arguments left are: hostname registration and "everybody else is doing DHCPv6". Those are not bad arguments, but maybe don't justify the added support complexity for the android devs.
> Addresses are assigned not based on MAC addresses like in DHCPv4, but based on UUIDs.
> Whether the UUID is per host, hardware, boot or phase of the moon or just random is essentially random
Should we fault the protocol for its implementations failing to satisfy what I think are very clear MUSTs and SHOULDs in RFC3315? A DUID is used by anything that wants to be uniquely identified as a DHCP client or server. The basis of the assignment must not matter to either the server or client and the value should be treated as opaque. It should not change over time if at all possible. It could be based on a MAC address (as DUID-LL or DUID-LLT) but it shouldn't matter to anyone consuming the DUID, because they MUST NOT be interpreted and only ever be compared for equality. A unique DUID should simply be considered as a unique client.
I don't know what about these requirements is so fundamentally hard that "DHCPv6 is broken" because of it. Plain DHCP essentially has the same limitation in that there is no guarantee that a client will consistently use the same link layer address.
The non-interpretation-requirement makes DUIDs useless. If I must not compare it to a MAC address, I can't identify the IPv4 address assigned to the same host. I can't identify the box with the MAC address printed on. "It should not change over time" has been trumped by "it's impossible to implement privacy without changing it". Those things make DHCPv6 as useless as SLAAC: I can't look up a corresponding v4 address and I can't predict what DUID/IAID a new device will use, or rather what v6 address it will get.
> The non-interpretation-requirement makes DUIDs useless. If I must not compare it to a MAC address, I can't identify the IPv4 address assigned to the same host.
You don't need to interpret a DUID. You can take a MAC address and generate a DUID-LL from it according to RFC 3315, then look for that in the DHCP traffic without ever interpreting DUIDs by simple equality comparison, while simultaneously scanning the DHCP (v4) traffic for the MAC you derived the DUID from.
And if the thing you're looking for is not using DUID-LL, you're just as screwed as if your IPv4 product is randomizing its MAC address.
But that is not really "treating the DUID as opaque", is it?
Also, there is still the problem of forcing devices into DUID-LL mode which is neither the default nor common. This requires manual configuration which is very bad for any large-scale use case.
> But that is not really "treating the DUID as opaque", is it?
Yes it is. Nowhere in this process do I need to take an existing DUID and treat it as anything other than an arbitrary sequence of bytes to be compared to another arbitrary sequence of bytes.
> Also, there is still the problem of forcing devices into DUID-LL mode which is neither the default nor common.
So maybe your use-case simply isn't common, perhaps because there are numerous ways to solve it that don't involve relying on ideal behavior in both DHCP v4 and v6 servers and clients. Take RFC 6939 for example, or just plain hostname based name assignments.
> Will it even be set? The hostname field is optional ;)
Then of course, so is printing a barcode sticker representing the MAC address of the box you're installing. The basis for any solution that is going to let you install hundreds of hosts comfortably is the manufacturer going out of their way to support that, regardless of whether you're using plain DHCP or DHCPv6.
As long as the DUID does not change, though, is it really important how the DHCP address is mapped? MAC addresses can be spoofed, even randomised at every boot if one is so inclined. They are not any more unique as the DUID in the end of the day.
The MAC address can be obtained from the outside of the box of your system, so deployment is "scan the MAC barcode, register for autoinstall on boot, done". "Big enterprise" deployment for which one is supposed to need DHCPv6.
Also, DHCPv4 still uses MAC addresses, if one uses dual stack as opposed to v6-only, one might want to correlate the v4- and v6-address given to a device.
In DHCPv6 it is perfectly fine to use MAC-based DUID-LL, though, if you want to support a "figure it out from the outside of the box" use case in your product. Just as someone can choose to use DUID-LLT or DUID-UUID in their DHCPv6 product, someone can not to print the MAC address and to randomize the MAC address on any basis in their DHCP (v4) product.
Of course one could do those things. However, those things are uncommon, so one cannot rely on them working in most cases, making the whole situation painful and DHCPv6 useless. If it were just my one product, things would be fine. But reality consists of hundreds of hardware and software products by different vendors, from different ages, etc.
With DHCPv4 I can rely on the mac address being used and forwarded in a DHCPv4 request and I can rely on the MAC address sticker to be present and accurate. And while it is possible for an operating system to randomise MAC addresses, it is uncommon enough. Most OSes also won't randomise MACs if the network "looks enterprisey" (e.g. uses WPA2-Enterprise) to them.
DHCPv6 dropped the ball right at the start and is now unable to pick it up again. The reality of DHCPv6 implementations has developed into a thicket of opaqueness and uselessnes, which cannot be unravelled I fear.
> I can rely on the MAC address sticker to be present and accurate.
That is not a property of the DHCP (v4) protocol. My argument isn't that the situation is messy; it's that DHCPv6 is not broken. The only extent to which anything you've said has supported that conclusion is that yes, it's as broken as plain DHCP.
The use case you describe (consistent addressing based on MAC and simple correlation of IPv4 and IPv6 addresses) can be solved in numerous ways, for example using MAC derived name assignment or multicast DNS. It's solved in my home network, why isn't it in your enterprise network? Why make yourself dependent on what's printed on the box?
DHCPv6 is broken in that it allowed anything beyond DUID-LL to be used. DHCPv4 always relied on MAC addresses, so this works where DHCPv6 doesn't.
DUID-LL in DHCPv6 usually doesn't work, except with special configuration, for which I have to boot, configure the PXE firmware (if it is even configurable) and the OS (which isn't even installed yet). This doesn't fly in an enterprise network, where I don't want to unpack, boot and manually configure each and every device. Ideally, I never open the box, scan some printed-on barcodes and pass it on to the future user of the new device. After unpacking and cabling, installation and setup is automatic. This is totally different from home networks, where manual configuration is acceptable and usually easier.
> DUID-LL in DHCPv6 usually doesn't work, except with special configuration, for which I have to boot, configure the PXE firmware (if it is even configurable) and the OS (which isn't even installed yet). This doesn't fly in an enterprise network, where I don't want to unpack, boot and manually configure each and every device.
So again, this happens when you're using products in an enterprise network that don't "fly in an enterprise network". Instead of addressing these products directly for what is obviously a flaw in their implementation that concerns you, you say that this is DHCPv6 at fault. If PXE and your OS don't offer defaults that would make them fly in an enterprise network, they're to blame.
> This is totally different from home networks, where manual configuration is acceptable and usually easier.
Regardless, when a host connects to my home network and starts talking DHCP, v6 or v4, it gets a name assignment corresponding to its hostname. Thanks the RFC 6939 option this could just as easily be based on the MAC address. Whether manual configuration would have been acceptable in my home network case is completely irrelevant to the point.
The flaw can be argued to be in the products' implementation of the standard or the standard itself. I do argue for the flaw to be in the standard because the standard doesn't do what it's name suggests: standardize. Instead it has balkanized (not on its own of course, but by allowing implementers too much of a choice and too few hard rules, too much SHOULD instead of MUST).
There is a cycle in many enterprises where someone asks "could we implement IPv6?". Then things like these come up, everybody looks at discussions like ours where there are pie-in-the-sky arguments about "you could just pick the right software/hardware" and "you could change it like that".
The conclusion will inevitably be: IPv6 isn't there yet, because it's too much work for little benefit. Too many changes in existing processes, too much risk. Then the IPv6 topic is dead again, maybe for two or three years until someone asks again. This has been going on for almost 20 years now. If you have ever been wondering why enterprises usually don't do IPv6, there is your reason. The braindamage that is DHCPv6 along with the false claims of "if you want 'enterprise' and 'managed networks' you need DHCPv6" is a large part of it.
I have no idea how things would get any better, however, DHCPv6 is recognizably a dead end.
> The flaw can be argued to be in the products' implementation of the standard or the standard itself. I do argue for the flaw to be in the standard because the standard doesn't do what it's name suggests: standardize. Instead it has balkanized (not on its own of course, but by allowing implementers too much of a choice and too few hard rules, too much SHOULD instead of MUST).
So you call people out for their shoddy products until the SHOULDs are practically adopted as MUSTs. Is there a legitimate reason for some network appliance with any form of persistent storage that you can write to once or more to use different DUIDs through its lifetime? Nope. If it does it's badly implemented. Do burn-in, just like you do with MAC and print the DUID on the box, just like you do with MAC. How you achieve that is no concern of the DHCPv6 protocol, just as how the MAC address is derived or whether it's printed on the box is no concern of the DHCP (v4) protocol.
Perhaps one can say that there is a lack of standardization in the area of human friendly physical machine to address mapping. DHCPv6 and DHCP (v4) are not those standards. Instead we have the ad-hoc practice of printing MAC address stickers which could just as easily be the ad-hoc practice of printing DUID stickers if not for an apparent complete lack of imagination on the implementers' part.
> The conclusion will inevitably be: IPv6 isn't there yet, because it's too much work for little benefit. Too many changes in existing processes, too much risk.
Of course if there is little benefit to you, replacing your existing infrastructure and processes is going to be a high relative cost. This is true of any new technology, especially for an enterprise where existing infrastructure and processes were not exactly conjured in a day.
> Is there a legitimate reason for some network appliance with any form of persistent storage that you can write to once or more to use different DUIDs through its lifetime?
Even the operating systems, with persistent storage in the form of harddisks get this wrong: a DUID is reassigned on every reinstall, at least. MAC addresses are convenient since they are basically global serial numbers in the form of ROM, fuses or similar. Only later were MAC addresses generated on the device by a RNG. There is just no hope for the DUID situation to ever get better, meaning DHCPv6 will never get useful.
> Of course if there is little benefit to you, replacing your existing infrastructure and processes is going to be a high relative cost. This is true of any new technology
No, it isn't. There are technologies that are designed to be easy to migrate to newer versions. Usually one doesn't notice those, because of the lack of problems. E.g. going from Ethernet to WiFi is relatively simple because of the intentional huge similarities. Upgrading a HTTP server from 1.0 to 1.1 to 2 doesn't change a lot in your processes, although there are huge differences especially from 1.1 to 2. TLS 1.3 looks completely different from 1.2 on a protocol level, but it was designed with upgrades in mind. To an admin or end user, it is practically the same.
Other technologies, e.g. POP3 vs. IMAP or cloud-based vs. physical computing can easily run side-by-side.
IPv6 is lacking in both methods of migration. You can't transparently upgrade (which would be hard to accomplish because of the different addresses). And you can't run it side-by-side easily, because of problems like the lacking DHCPv4/DHCPv6 correspondence. I would argue that IPv6 would be much more of a success if designers had not purposefully ignored that.
You can run v4 and v6 side by side easily though -- they work pretty much the same way as each other, and that's the standard deployment model. From an end-user perspective, there is no difference: you go to Google, search for "facebook" or whatever and click on the first link. All of this happens over v6 in exactly the same manner as it does over v4.
As for v6 autoconf not working exactly the same as DHCPv4 does, it's not like they purposely ignored it. Remember that DHCPv4 was being standardized at about the same time IPv6 was, and it wasn't really ubiquitous until a good half a decade afterwards. The RFC for router advertisements in v4 was published two years before even DHCP was, and there were various other ways of doing autoconf. It's not reasonable to expect them to have known that DHCP would win.
> Android still has a broken IPv6 implementation in 2020. By design. They are not going to fix it. There are a couple of valid arguments from Google and Lorenzo Colitti, but they are pretty weak.
Any care to substantiate, why they are weak?
I'm going to substantiate, why their argument is strong:
1) With DHCPv6, the network operator can force your device to obtain only single IP address. With SLAAC, you can invent your own, any amount you want, it just has to be within the same subnet; the /64, smallest subnet, is pretty huge.
2) For tethering with IPv6, you need multiple IP addresses. You cannot do NAT as you do with IPv4.
Therefore, with IPv6, telcos could disable the tethering function of the phones / charge extras, just by suitably configuring their network. It is obvious, that the major supplier of mobile OS won't allow doing that. Hence, no DHCPv6.
NAT66 is indeed possible, and it actually happened to me to use it, but it's really ugly and clunky to use.
This is mostly because you are forced to use ULAs, which almost every IP stack by default rightfully considers as private addresses (see RFC 3484). So, if a host has a valid IPv4 route for 0.0.0.0/0 and one for the IPv6 internet that refers to an ULA, its resolver will almost always prioritise the former route unless you configure it to do otherwise (i.e. on Glibc you can change how getaddrinfo() works by editing its label table in /etc/gai.conf).
Since running wireguard with algo.sh seems to be popular now, this is the situation you'll end up in with most ipv6 supporting cloud hosting providers. Digital Ocean only gives 16 ipv6 addresses to the best of my knowledge, others are probably limited to only 1.
I moved from OWH because they only assigned a /128 to VPSes, so you're sharing a /64 with other servers. That was problematic because I run my own email server, and blacklists for IPv6 tend to be specific to a /64, meaning neighbouring servers landed my own server on blacklists (i.e. they blanket blacklist the whole /64). And obvs cloud providers sadly host a lot of spammers.
In the end, since OVH even after being asked for years offer no option for /64s on VPSes, I moved to Hetzner, where a VPS gets it's own /64, so only I am responsible for my mail server's reputation.
yeah, I also give out ULAs to my clients in VPNs (both OpenVPN and WireGuard), but it's mostly for local, in LAN traffic. I still haven't figured out how to convince Windows to actually prefer ULAs to IPv4 like I can do on Linux.
Its also in active use by some styles of server load balancers. Keepalived in nat mode is one that springs to my mind.
The "nat is evil" objection was a moral high horse in the IETF around the time that Android adopted this policy. They may have a point but its largely irrelevant in the real world.
1 & 2 are related and false. It's nice to have multiple addresses but nothing about v6 says you can't tether in the same way as you did on v4 it's just simpler to avoid if you can.
That being said these arguments are very narrow focused anyways and that's the real reason they are weak - phones connect to more than just the telco provider which is what the article covers.
> With DHCPv6, the network operator can force your device to obtain only single IP address.
So if your network admin does that, surely they have good reason, they basically want to stop you using 464xlat. Any good network admin should allow a device to ask for as many IPv6 addresses as it needs. Or is there a reason why that is not possible?
I think IPv6 is quite complicated, people don't fully understand it (it's not the same as IPv4 with a bigger address space) which means lots of conversations like this where it seems easy to just implement IPv6 but the nuances of the protocol mean it isn't. There is also lots of code that is broken because of this same lack of understanding meaning more workarounds to get everything to work.
>Therefore, with IPv6, telcos could disable the tethering function of the phones / charge extras, just by suitably configuring their network.
Most carriers count tethering traffic from packets received with a TTL decremented by 1, whether or not you NAT it is irrelevent. This was the case for ipv4 and looks to be the case for ipv6 thanks to this very recent commit: https://github.com/aosp-mirror/platform_frameworks_base/comm...
I mean, there are two sets of standards. Google picked one, the author picked the other. The other 2000 words of the article seems to be a rant about how Google makes money off of ads.
Isn't it more like "Google picked one, and Microsoft/Apple/IBM/Linux/*BSD/Cisco/Oracle/HP/... picked the other"? Besides Google's, the only OSs I see which support IPv6 but not DHCPv6 are VMS, Symbian, and z/OS.
It's a bit much to call something "broken" because it won't support the configuration you want, particularly when that configuration itself could reasonably be called "broken".
It sounds like DHCPv6 means giving up most of the benefits of IPv6. In which case better to migrate right than migrate twice.
> "Initially, Microsoft operating systems did support SLAAC but not RDNSS, Android did not want to support DHCPv6. That meant that you couldn’t support these two operating systems on the same subnet."
This is incorrect. You can run SLAAC (with or without RDNSS) and stateless DHCPv6 on the same subnet.
Even more, running DHCPv6 correctly actually requires sending RAs with the O or M bit set, so you're almost doing SLAAC anyway (setting M disables SLAAC, O does not.)
Sensible (= stateless) DHCPv6 is an addition to SLAAC/RDNSS to allow pushing additional config. It is not a replacement.
It looks like the setup they want will be pretty crap for home users if that got implemented by ISPs.
You won't be able to tether if ISPs / Mobile networks decide to use the DHCP to give you a single IP.
This stance of Google's benefits consumers. Howv many consumers are there of mobile phones and broadband are there in the world compared to workers in a corporate LAN?
I feel like the question that needs to be asked sometimes is:
Will this enterprise feature negatively affect normal home users.
Imagine your mobile phone network gave you 1 IPv6 address rather than a subnet.
That is bad. But Google standing firm on not implementing the ability to do so, has meant that they gotta implement prefix delegation.
Ok IPV6 is one of those ideas that was obsolete by the time it was deployed. 12 bytes? Why not 16? Why not a UUID for each node? No management; no guessing who's is who's. Heck, use a new one for every connection.
Without a system with prefixes every router needs to hold the next step for every single ip address in use in memory all the time and needs to be able to look them up fast.
And today we can't do that? That's what I mean by, obsolete before it was deployed. IPV6 was designed in an age of lesser storage/higher cost memory and embedded processor power.
And no, not every one. Store the ones routed thru you. That's all you need. Look them up and keep a cache.
Every node on a local network would need to be able to know whether another node is on the local network (unless you want all traffic to go through a router). So do you send arp requests for every ip you try to contact? Distribute a list through DHCP?
All upstream routers needs to know about your node. So every time someone somewhere in the world connects a new device a message gets sent up to the core routers of the internet? And the core routers needs to keep track of routing tables in the size of billions and be able to look entries up in nano seconds.
Thanks, yes those seem like possible algorithms that would work great with today's technology.
And yes, every time new traffic appears at a 'core' router, entering it into a cache would be another great algorithm. But they do that now, so no patents for us.
I love it when somebody 'objects' to a plan, then proceeds to describe the solution succinctly.
> every time new traffic appears at a 'core' router, entering it into a cache
How does that new traffic appear in the core router? I has to appear in every core router, otherwise hosts connected to a a core router which didn't receive that traffic recently wouldn't know how to route to your host. So the answer would be flooding, which is extremely wasteful of bandwidth and processing power. Also, it's a cache, which means it expires, so you have to flood the host announcements constantly (and even if it doesn't expire, you have core routers going down and being replaced). Once you think over all the details on how to fix these issues, what you end up with is basically a routing algorithm, like BGP or others, only replacing the "network" by a single host.
And once you arrive at a routing algorithm, consider that routing algorithms have a long history, and have already received a lot of research. That naive "flooding" algorithm is basically RIP, one of the oldest routing algorithms; there are good reasons why most people don't use RIP anymore.
Sure, lots of history. Which is why new solutions are such a hard sell - everybody quote an authority and concludes 'it has to be this way'.
Traffic appears at core routers because it already gets send there by peripheral routers as a gateway. Sharing routing information between peer routers is not unsolvable nor likely onerous.
Strawman solutions (flood constantly) are being deliberately dense. I suspect because, folks are so very comfortable with what they know, and so very unwilling to extend themselves. How we got IPV6 in the first place. Which isn't working either.
> Traffic appears at core routers because it already gets send there by peripheral routers as a gateway. Sharing routing information between peer routers is not unsolvable nor likely onerous. Strawman solutions (flood constantly) are being deliberately dense.
If by "sharing routing information between peer routers" you mean that, when a router learn of a new host, it shares that information with its peer routers, which then share that information with their peer routers, that is flooding. Without flooding, the traffic would not appear at every core router, which means most routers would not know of your host.
> I suspect because, folks are so very comfortable with what they know, and so very unwilling to extend themselves.
I once seriously considered how to make an Internet-scale non-hierarchical routing protocol, where the host identifier was a cryptographic hash of its cryptographic public key. The reverse path is easy; once A has successfully sent a packet to B, all routers in the middle know how to get from B to A. The forward path (from A to B) is the hard one. Every router knowing every host is non-viable; consider, for instance, what happens when my phone roams from the WiFi to the LTE and back (which happens many times per day) - if every router had to know of that change, for every roaming phone in the world, it would be enough to overwhelm all the links between them, not to mention their CPUs. I came to the conclusion that the amount of propagation of the route updates must be limited for it to be viable, so having every router know of every host is not possible. Either the routing information must be summarized somehow (which is what the hierarchical routing used with IPv4 and IPv6 does), or some other way which does not involve the routers (for instance, path routing, like MPLS) must be used.
That is, I'm not rejecting your idea because I "feel comfortable" with hierarchical routing, I'm rejecting your idea because I've already given it (or something like it) serious consideration, and found it harder than what I had initially thought.
No I don't mean the worst interpretation thinkable, when I say 'share that information'.
Glad to see you've thought of the issues. Now lets brainstorm solutions.
A DNS-style authority with the answer to the routers' questions perhaps. Updated by the leaf router with some route coloring info for a new leaf node perhaps. Inquired upon cache miss by core routers? Aged out for frequent updating (roaming, unique ID per connect, and other short-lived routes).
lookup complexity is a very real cost factor for routing equipment and it's increasing faster (because interface speeds are increasing and prefixes are getting smaller) than hardware capabilities are .
so no, we can't make every router cache every host id.
Sure we can. Especially UUIDS. They have a normal distribution of values (bits are random) so an associative cache would match entries faster than current devices can match highly-repetitive prefixes.
This is an example of what the IPV6 folks suffered from. They could only see the issues of previous implementations, and took an incremental step along those solution axes. Instead of considering future trends (cheaper memory/processing power) and "skating toward the puck". Instead they followed the puck, and ended up well behind.
A cache with a few billion devices in it will be too large, and as soon as your cache may be large enough you will have even more devices.
Also, for routing an address hierarchy is nice because of the O(log n) properties the address tree gives you. UUIDs do not do that, but subnets do. For the endpoints and smaller routers near the edges it is even more advantageous, those only need to know a few local prefixes, the rest goes to the next gateway. With UUIDs, every devices needs to learn all the addresses behind it, quite an impossible task, even if the lookup were fast and small enough for its cache.
Again, for core routers, not at all. The UUID is random; it has the same order of lookup or better; endpoints need only the local routing info in the same way. Caches need only hold active routes, which is orders of magnitude smaller.
The idea that its 'impossible' is 20 year old thinking. That's my whole point. We've wandered into a disappointing, underpowered solution that's not gaining traction. While real future-proof solutions exist right in front of us.
It doesn't, prefix lookup is solved faster and cheaper in hardware via CAM or TCAM, maybe combined with hashing, because you can limit yourself to a prefix, discarding the rest of the address.
Even if you are right about the endpoints (which only need to know all devices in their specific subtree), as soon as you get to a part of the network where there is no longer just a limited tree below a given router hierarchically, you need a global view of all addresses. This view has to be current, correct and total. That is impossible to achieve, even if the lookup itself would work (which it won't, a conservative estimate of 4 billion active internet devices take up 64GB just for their addresses, not even including routes and metrics). You just cannot search those 64GB fast enough for each packet you are passing through your links (remember, even saturating 10GE in software is hard, and routers do have a lot of those ports in 40 or 100GE...).
Nobody suggests 'just searching' 64GB (which is not an unreasonable amount of memory today for a core router). Associative lookup is required, as is the case today. Nothing very new is required to create even larger (hashed) associative memories to manage this problem.
> Caches need only hold active routes, which is orders of magnitude smaller.
What do you do when there's no active route? If a router receives a packet from 192.0.2.1 to 198.51.100.2, but the router has never received a packet from 198.51.100.2, how does it know to which of its neighbors it should send the packet?
We resolve arbitrary names with DNS to a global identifier (an IP address), but for routing, what you need is a local identifier (which neighbor router to send the packet to), which means every router or set of routers would need its own database, and each database would need to know about every host in the world. This is exactly what we have nowadays with BGP, only with networks instead of hosts: every core router or set of core routers has a database which knows about every network in the world, and tells which neighbor AS to send the packet to.
Also, DNS caches are just locally used small subsets. Global lookups are again hierarchical, thats why it is called _domain_ name system. Thats why there are dots in the adresses. Also, DNS lookups are rare compared to IP route lookups, you look at DNS for every connection at most, limited by the TTL for caches. Route lookups happen for every packet.
Now I'm forced to move these things back to IPv4. My home ISP has first moved off static delegations in favor of dynamic ones via DHCPv6, and then broke IPv6 routing completely [1] and after a few weeks of me complaining still seemingly has no interest in fixing it. The place I work for now has no IPv6 connectivity and has no plans for it in the future. Many people I talk with don't believe that IPv6 is the future and I commonly hear that they have forcibly disabled it on their computers due to this or that random problem.
[1] https://www.tablix.org/~avian/blog/archives/2020/05/on_missi...