An AAAA-only hostname would sidestep that issue, with the obvious downside.
(This behavior is a deliberate choice from Wireguard. They claim it's not broken, but... it's broken.)
669 karma · joined June 6, 2012
(This behavior is a deliberate choice from Wireguard. They claim it's not broken, but... it's broken.)
They thought about these things and put features into the protocol to support them. This is, once again, the opposite of your belief that they didn't.
Android does now support IA_PD, so the people who need to track IP use via DHCPv6 requests should now be happy. (We'll just put aside the question of whether doing that even makes sense in a world where devices can be told to use any IP.)
What more do you want from it?
What could they have possibly done differently to make you happy with it?
> people who either worked for the likes of Google who were aching for a globally unique identifier per device
v6 doesn't give you globally unique device identifiers. Devices get IPs from the network in v6, just like they do in v4. You're either thinking of MAC addresses or perhaps things like HIP (https://datatracker.ietf.org/doc/html/rfc7401). I guess there is Mobile IPv6 which allows you to take your address to another network, but then there's also privacy extensions which prevent your machine from using the same IP for very long, so it's still not a unique identifier for your device.
How else would you do it? Forcing every packet to reserve space for every possible option (including all future ones) seems obviously worse.
With one exception, extension headers are not examined or processed
by any node along a packet's delivery path, until the packet reaches
the node (or each of the set of nodes, in the case of multicast)
identified in the Destination Address field of the IPv6 header.
None of it does anything particularly amazing, but that's kind of the point -- the programs that people are generating are for the use cases that are too personal, trivial or specific for anyone to have bothered making a software package for.
There are a number of big ISPs in Europe that that have a "new" native v6+CGNATed v4 platform, and an "old" native v4+no v6 one. That's where a lot of the "I had to ask the ISP to disable v6 to get inbound connections" comes from -- the actual relevant part was getting out from behind CGNAT, and the loss of v6 was just a side-effect caused by the ISP moving you to their old platform.
Inbound v6 should generally work on those ISPs. If it didn't... I'd be tempted (perhaps unfairly) to blame the user for not configuring things properly, or their software for not supporting v6. A lot of people will give up and blame a problem on v6 when they would have found and fixed it instead on v4.
I was thinking more along the lines of network namespaces -- although actually, I should have been thinking of TUN interfaces. Any packets sent into one of those are delivered to the attached program, which can do what it likes with them. Those are usually used by e.g. OpenVPN for L3 things, but nothing stops a program from handling the L4 headers.
Note that RFC 7278 doesn't prescribe ND proxy use for the mobile network case. Mobile networks provide the /64 over a point-to-point interface, so they can simply put the /64 and their own address on the LAN interface and it'll work fine, as described in the examples at the end of the RFC.
I don't think it's a good idea to put more of the stack than necessary into each individual program though, because then you're reliant on each program implementing everything correctly and you have to worry about bugs and security issues in every single program you're running rather than just in the kernel.
Considering that even something as simple as opening a socket (which involves calling one function to give you three numbers which you pass unchanged to a second function) is largely a clusterfuck in existing programs, I don't trust them to implement the whole TCP stack.
...it does. You can spend five seconds in tcpdump to see that it does:
$ ping6 fe80::506c:e9ff:fe08:9ba3%eth0
11:58:48.741688 d6:57:10:b8:52:77 > 33:33:ff:08:9b:a3, ethertype IPv6 (0x86dd), length 86: fe80::d457:10ff:feb8:5277 > ff02::1:ff08:9ba3: ICMP6, neighbor solicitation, who has fe80::506c:e9ff:fe08:9ba3, length 32
11:58:48.742459 00:23:6e:5b:b8:2b > d6:57:10:b8:52:77, ethertype IPv6 (0x86dd), length 86: fe80::506c:e9ff:fe08:9ba3 > fe80::d457:10ff:feb8:5277: ICMP6, neighbor advertisement, tgt is fe80::506c:e9ff:fe08:9ba3, length 32
Yes, those bytes can be picked by looking at a MAC address, but that's only one way to pick them and the protocol doesn't treat those bytes as having any particular significance, and in particular it never assumes they contain a MAC or tries to use them as an actual MAC, so it doesn't qualify as a layering violation.
I know you're talking about SLAAC, but SLAAC is just a convenient way of picking a unique address. Changing the address wouldn't result in e.g. the packet being sent to a different MAC. Even sending packets to link-local addresses still does NDP, rather than parse the MAC out of the address.
How do you want to go about doing this? Although, 100% of the time people have asked me to do this they chicken out at actually doing it, so I suppose you will too. You might prefer to test with some network namespaces instead.
You don't need to take that on faith either -- you can just test it.
It doesn't actually do that.
We believe that it is not possible to have a "flag-day" form of
transition in which all hosts and routers must change over at
once. The size, complexity, and distributed administration of the
Internet make such a cutover impossible.
IPng is a new version of IP which is designed to be an evolutionary step
from IPv4. It is a natural increment to IPv4. It can be installed as a
normal software upgrade in internet devices and is interoperable with
the current IPv4. Its deployment strategy was designed to not have any
"flag" days.
> The “you don’t have to use NAT anymore” is great theoretically, but it renders a lot of casual network maintainers mental model of network security obsolete without a clear and simple alternative
If your mental model of security relies on NAT then your mental model was wrong, and obsoleting it was the right thing to do.
If v6 made you realize this, then it seems it's more intuitive than v4+NAT was for you.
You haven't fixed any of the problems involved in deploying v6, and you added a step that was known 35 years ago to be impossible on the Internet. This isn't a useful contribution, it's just a waste of time that you could have spent on doing v6.
Also... service discovery. Needing static addresses is a kludge.
We've mostly decided to go with TCP MSS clamping rather than using the minimum MTU, which is still nonsense but it's nonsense that we already decided to go with for the same problem in v4.
Of course, I don't have enough info to tell if this was the problem or if it was something else, or a mix of the two, but pMTUd does seem to be a leading cause of "fails to load for some weird reason" problems.
Rather than trying to minmax the address length, it makes more sense to sacrifice a few bits per packet to the addresses, wait a week or two on average to get the lost throughput back, and then spend those bits elsewhere to make other things easier. (For example, avoiding NAT is an obvious one, but even just "everything is a /64" removes the need to ever need to think about the size of a network.)
If you can spend a few address bits to make something easier elsewhere, that's a good trade. Maybe start worrying if the addresses were a kilobit long or something, but they aren't even close to that.
"There are a couple of v4-only hosts out there somewhere" would be kind of irrelevant if most ISPs stop bothering to provide v4 service.
> You can use the 8-byte addresses earlier if you want
You can't have both this and "The 8-byte phase only starts when v4 has been abandoned" simultaneously. Decide whether you want a flag day or not and then be consistent about it. (And when you're deciding, bear in mind that flags days on the Internet are impossible.)
$ wget -4 https://github.com/HackerNews/API
Resolving github.com (github.com)... 140.82.114.4
Connecting to github.com (github.com)|140.82.114.4|:443... failed: Network is unreachable.
$ git clone https://github.com/HackerNews/API
Cloning into 'API'...
remote: Enumerating objects: 142, done.
remote: Counting objects: 100% (53/53), done.
remote: Compressing objects: 100% (21/21), done.
remote: Total 142 (delta 38), reused 32 (delta 32), pack-reused 89 (from 2)
Receiving objects: 100% (142/142), 67.87 KiB | 668.00 KiB/s, done.
Resolving deltas: 100% (39/39), done.
> Ipv5 would share routing tables, DHCP, DNS, NAT, and various middleboxes with ipv4
Which is great, but all of these things are 4 bytes only. You need a separate set of tables etc for the longer addresses. Also v6 already shares all of these things and works with them instantly when working with 4-byte addresses, so this isn't new.
> Then those get patched or replaced to support longer addresses. Importantly, the upgraded versions easily support ipv4 too, so there's no reason not to upgrade.
Yes, like with v6. I would expect people to find endless excuses to never do the patch or replace part or to just refuse to configure their gear to enable longer addresses, like they do with v6.
All this leaves me wondering why this approach is bad when v6 came up with it but good when you came up with it.
I'd also like to note that being worried about accidental overbanning in v6 but then being dismissive of it in v4 is a double standard.
At some point or another, you have to do the work to support longer addresses. In your proposal, where is that work being done? Because right now it looks like you're either massively underestimating how much work it is or you're just outright ignoring it, but only for your own proposal and not for v6.
> If it were as easy as you're saying, all those things like Github would already at least support v6.
This isn't the "turn it on" stage, it's the "people can start putting something besides 0 into that last byte" stage.