1) make everything the same, the good and the bad, just extend the address space, and replace all the networking stacks in all the gear everywhere.
2) if we're already replacing everything, make stuff better
We chose #2, with varying degrees of what is "better".
- “You don’t need NAT”: well, you still need a stable address space for your LAN that survives your ISP randomly changing your prefix (which has happened to me at least a half dozen times over the past year), and the best option for that is ULA, which erodes many of the benefits of “no NAT” because my IP’s are not routable.
- “No DHCP”, well you can’t reliably know the IP address of anything on your network without it: SLAAC with EUI-64 was supposed to make addresses stable and derived from your MAC address, but oops, that’s a privacy nightmare, so we end up randomly generating them (and rotating them!) IMO this is more complicated than DHCP, not less. Oh and DHCP lets you assign dynamic DNS names to every lease you hand out, and you lose that too with SLAAC. You can do mDNS but that doesn’t help with public hosts that you want to access from the internet, you’re left with static IPs there, and god help you if you get re-prefixed (see point #1) because now your static IP won’t route because your ISP changed the prefix.
I’m really rooting for ipv6, trust me, but it feels like all the greenfield rearchitecting they did ultimately doesn’t seem much better than the IPv4 equivalent standards. NAT is here to stay, unfortunately, and so is DHCP.
The randomly changing prefix is really annoying. There's no reason for your ISP to do this other than to try and upsell you on expensive commercial services.
This isn't true. If it were, then home ISPs would never renumber client networks.
You're probably thinking about the larger allocations handed to folks who have ASNs, rather than the small allocations handed small ISP customer sites... and even then, those can totally be reclaimed.
I do ULA+global unicast too, but it would be far simpler if I actually had a reliable stable prefix and could just use that. I put my ULA addresses in local DNS (because that’s why I need ULA, I need to not worry about rewriting my zone file whenever my cable modem reboots), but that means I have to do split horizon DNS. I wish I didn’t have to. (Yes I do mDNS too but I need real DNS for lots of use cases.)
You also said
> NAT is here to stay
Which, uh, it sure sounds like you're not using IPv6 NAT. In fact, it looks like aside from probably being confused about what "split horizon DNS" is [0] your setup is exactly like mine. Address autoconfig for both a annoyingly-frequently-changing global prefix, and a constant ULA prefix with DNS entries for the ULA addresses.
[0] Does your DNS server serve LAN _and_ WAN clients? If it doesn't, and it only serves LAN clients, you're almost certainly confused.
> They pretty clearly talk about public hosts
Thing is, I ALSO have public hosts on my LAN. And they're in both the public DNS and in the DNS on my LAN. But public DNS is not served from my local DNS, so I don't have a split-horizon setup.
The mere act of maintaining (in two entirely unrelated DNS servers) records for the same resource but with different data doesn't make a split-horizon setup. If it did, then I could reasonably claim "I'm running a split-horizon setup for mit.com!" just by adding an A record for "mit.com" to my local DNS server, despite being neither connected to any MIT internal networks, nor in a position to serve any data to MIT's Internet clients.
I do DNS such that the same hostname, which I control, resolves to the ULA address if asking locally, but the public address if asking from an external machine. But it's not literally the same server, I use DNSimple for my public DNS and unbound on my local DNS. You can split hairs about whether split horizon means "the same DNS server serving both views" or not, but that's a needlessly pedantic snipe. But to cut off this argument: Sure, you're right. You score one internet point, I used the word "split horizon" incorrectly. You're very smart.
No, I'm really rock-stupid.
I also happen to be correct about the terminology.
> > NAT is here to stay
It's not generally good form to cherry-pick things I said from other threads and put them out of context. "NAT is here to stay" can for the purposes of this discussion mean "Thinking about global vs local addresses is here to stay", even if it's not NAT per se that is happening (ie. if you're using a ULA + global unicast, like I do.)
> you're almost certainly confused
I'm not confused. I do split horizon DNS. I serve WAN and LAN clients (not currently from the same DNS server, although that's what I'd prefer to do. The same hostnames are currently configured in different DNS systems depending on who's asking, hence "split horizon".)
To be clear, here's my setup. It's not unique or interesting compared to any other "home lab" setup:
- I have multiple machines that I want to be able to access by DNS name externally.
- I also want to be able to use those same DNS names for local configuration, to keep things sane.
To do this, I have two options:
1) Use the publicly-routable global unicast addresses in my DNS, and make a system to keep them updated in a reprefix
2) Use a ULA prefix for local DNS, and the global unicast equivalent addresses for public DNS, and make a system to update only the public DNS when I get reprefixed
I chose option (2) because I want to mitigate the damage that happens when my ISP reprefixes me. (It's happened 6 times over the past year, it's not uncommon.)
When I get reprefixed, any local traffic that's using DNS to lookup the address keeps working as usual, because the ULA address doesn't change. I have to worry about reconfiguring public DNS, but that's the lesser of two evils IMO:
Because if I picked option (1), I'd have to reconfigure public DNS and my local traffic would all be disrupted while the reprefix happened: My hosts would all be trying to communicate with one another via their old prefixes, and failing until DNS reconfigures.
And this is all not to mention that I have to do the exact same reconfiguration dance with my firewall config: When I get reprefixed, my pf.conf is now referencing invalid IP's. I disable-by-default so it's not a security issue, but it's something that I had to solve with automation (in my case, by templatizing my pf.conf and writing dhcpcd hooks that reconfigure it when the prefix changes. It wasn't trivial.)
Now, to get back to my original argument: IPv6's simplicity benefits "erode" when you consider that worrying about internal vs external addresses is still something you have to deal with in the real world, at least in residential deployments where you don't own your own prefix. Granted: These issues are inherent to any system where your ISP is dynamically assigning you IP's, but it's important to understand: Yes you can have real endpoints for all of your hosts simultaneously without dealing with NAT, but you still have complexity to deal with to make this work, due to it being the real world.
What? Press "parent" on the comment of yours that I'm quoting from right now four times. You'll find the comment of yours where you say "NAT is here to stay" right here in this comment tree.
> To be clear, here's my setup.
Yep, that's my setup as well, except I don't screw around with applying per-host inbound traffic firewall rules at my router. Either traffic is worth blocking to an entire subnet, or it gets blocked at the host that cares about it. Saves a ton of maintenance.
> Yes you can have real endpoints for all of your hosts simultaneously without dealing with NAT, but you still have complexity to deal with to make this work...
Yep. It's less complexity than with NAT. Substantially so. That's like the entire point. The additional complexity you keep pointing at is because of a feature that you can't have with typical end-user NAT... the ability for each host on your LAN to have a globally-accessible IP address. And you can get rid of most of what you're complaining about by paying for a static prefix and getting it tunneled to your site, as folks elsewhere in this sprawling conversation tree have mentioned (or getting friendly with a local clued-in ISP and having them statically-assign you one).
I have both globally-routable and ULA addresses assigned to the hosts on my LAN. The ULA addresses are in my local DNS, and I update global DNS whenever the site's global prefix changes. Aside from the fact that the global prefix changes way too frequently (like once a quarter) it works great for me.
> ...so we end up randomly generating them (and rotating them!)...
Yeah, I turn this shit off whenever I have the power to. This was a fucking stupid-ass thing to have on by default. Hella buncha ways you can be tracked that give zero shits about what your IP address is. (This is one time when I wish the Net Heads would have consulted with the Web Heads and learned about how trackers actually work.)
> NAT is here to stay, unfortunately, and so is DHCP.
Nothing wrong with doing DHCPv6 and SLAAC, or just DHCPv6. My network just uses SLAAC, but folks who need more features than that provides have another tool they can deploy. This is a good thing.
And you __can__ use NAT if you choose to, but if you're being assigned a publicly-routable prefix, there's no real reason to. Set up your border firewall to deny inbound unsolicited traffic, and set up uPNP (or similar) to hole-punch and you end up with the same security guarantees.
Originally it was “IPv6 is great, you don’t need dhcp”, but then it became “well you may need DHCP anyway so here’s DHCPv6”, and then that becomes necessary often enough that you can’t really point to that as a benefit of IPv6 any more.
You don’t need NAT but you need a lot of the systems complexity that NAT requires, because you have to manage two sets of addresses in various configurations. Split DNS, etc.
You’re fine if you own the address range and it isn’t provided to you dynamically with DHCP-PD, but that isn’t the case with basically 100% of residential deployments. You need to multihome to even apply as a RIR to get your own prefix.
https://lagrange.cloud/products/lir £15 one-off for an ASN and £7/y for a /48.
Then you just need to find someone to give you a BGP session. https://bgp.services
The Wikipedia explanation is flat-out wrong.
There is no functional difference between PA and PI.
Sorry, what's your point? That having both address autoconfiguration and DHCP is too complex? If so, that's has been the standardized state of the art in IPv4 since 2005 with RFC 3927, and has been non-standard actual practice with Windows and Mac since like 1998.
> ...you need a lot of the systems complexity that NAT requires...
No, all you need is a router that can do IPv6. It doesn't even have to have a firewall, which is absolutely mandatory for consumer-grade border-router NAT.
> ...Split DNS...
I don't run that. My DNS answers local queries for LAN hostnames it knows about and forwards global queries upstream. Just like nearly every consumer edge-router DNS server.
> ...DHCP-PD...
Yep. My ISP runs that on the WAN side of the router. I just do RAs on the LAN side of the router.
I don't think I've ever seen two computers communicate over a 169.254 address. Also, OS network stacks normally don't even try to get a link-local IPv4 address if they can get to a DHCP server or have a static address assigned. The RFC even recommends not using the link-local address if any other address is available. It's quite different from the way IPv6 works (as usual).
I have. Used to do it often in the dorms when the uni's DHCP server was on the fritz. Zeroconf/Avahi wasn't really a thing, so we'd use Network Neighborhood to get people's IP addresses to browse files or play on servers they were hosting or whatever. I have also (as the RFC envisions) done it when connected to ad-hoc WiFi networks, and also while directly connecting two Windows PCs. In those scenarios, I asked my peer what their IP address was, rather than bothering with going to Network Neighborhood.
> Also, OS network stacks normally don't even try to get a link-local IPv4 address if they can get to a DHCP server or have a static address assigned.
Correct. From the second paragraph of the Abstract of RFC 3927: [0]
> IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks).
> The RFC even recommends not using the link-local address if any other address is available. It's quite different from the way IPv6 works (as usual).
No, it's also recommended when using IPv6 to not use link-local addresses if any other address is available. (Both because those addresses are only link-local, and because one usually needs to put an outbound interface specifier on the address when you go to contact another host, which is pretty obnoxious.) It just happens that IPv6's address autoconfiguration has been upgraded to be useful for globally-routable addressing, too.
So, yeah, a usual mode of both IPv4 and IPv6 networks is to have autoconfigured addresses, as well as DHCP-assigned addresses. It just so happens that most of the time IPv4 addresses are not autoconfigured, and most of the time IPv6 addresses are not assigned by DHCP.
That's equivalent complexity.
With what seems to be the recommended IPv6 setup at least for client machines, the Link-local address is the only stable identifier of that machine, as the actual reputable address changes all the time. So, the machine has both a link-local and a routable IPv6 at the same time, and both are going to be used. This is still different from IPv4, where link-local addresses are, again, an obscure feature that almost no one uses.
What? ULA space is the IPv6 equivalent of RFC 1918 space. If you want a prefix you know will not change, then you go generate you a /48 and use that on your internal network(s).
Why on earth would people expect ISPs that have a "We won't give you a guaranteed-static IPv4 address." policy to have a "We will give you a guaranteed-static IPv6 prefix" policy? Thinking that way is madness.
Perhaps you're confused because you're looking at guidance for client machines, when you should be looking at guidance for customer edge routers? Check out RFC 7084, and in particular section 3 and its subsections, and section 4.3 and its subsections. [0]
> ...as the actual reputable address changes all the time
Are you talking about IPv6 address randomization? (AKA "privacy" addresses?) IF you are, then know that it's
a) Controlled by the operator of the computer, rather than the operator of the network it's connected to.
b) Optional, and SHOULD be able to be turned off by the computer operator.
c) RECOMMENDED that a stable address be generated for the machine, in addition to the random ones.
Thing c) is in part to deal with "But what if I want to put a AAAA into the local DNS?" problem, and in part to give expected-to-be-long-lived connections an address that the system knows will hang around for at least as long as the interface is up.
After all, unless you want to tear down the connections associated with it, you can't remove an address from an interface until those connections have closed. More addresses allocated to a host means more multicast groups joined for that host, which eats up resources on the local networking infrastructure... so (if you're using "privacy" addresses) you really, really wanna steer ephemeral connections to addresses that are temporary, and long-lived ones to ones that are not.
My point is very simple: you can’t say “IPv6 is simpler because there’s no DHCP” if there’s DHCP. It’s pretty obvious right?
DHCP is orthogonal to IPv6.
IPv6 deployment is simpler for many reasons. One being that at the typical end-user site you have neither v6 NAT nor v6 DHCP. Another being that you have enough address space (and we have collectively learned from the IPv4 allocation lessons how bad things can get) to have a good chance of setting things up so that routers need not do quite so much work to route v6 packets.
AFAIU it was "just" defining an option type; the IPv4 packet header itself didn't even need to be changed.
1993 was more than 30 years ago.
So people who wanted to keep it backwards-compatible with IPv4 already had a chance.
Each TCP/IP v7 system, whether host or router, must be able to
recognize adjacent systems in the topology that are (only) v4, and
call the appropriate conversion routine just before sending the
datagram.
On networks where ARP is not normally used, the method is to assume
that a remote system is v7. If an IPv7 datagram is received from it,
the assumption is confirmed. If, after a short time, no IPv7
datagram is received, a v7 ICMP echo is sent. If a reply is received
(in either version) the assumption is confirmed.
If no reply is recieved, the remote system is assumed not to
understand IPv7, and datagrams are converted to IPv4 just before
transmitting them.
* https://en.wikipedia.org/wiki/Happy_Eyeballs
And let's not forget about all the function and system calls that need to be updated (§2.4) because various structs are of a fixed sized:
There is a non-trivial amount of software that assumes that an "int"
is the same size and shape as an IP address, and does things like
"ipaddr = *(int *)ptr". This usage has always been incorrect, but
does occur with disturbing frequency. As IPv7 8 byte addresses
appear in the application layers, this software will find those
addresses unreachable; this is preferable to interacting with a
random host.
IPv7 would have had the exact same issues that IPv6 had with rollout.
There is no "just" when trying to expand a fixed-size data structure across the entire planet.
The C programs and network protocols have been implemented for 20+ years.. so why isn't everyone switched yet?
Because IPv6 refused to be IPv4-with-extensions and instead decided to be completely incompatible - so all the admin scripts, all the best practices, all the configuration needs to be rewritten. Instead of fixing a single apache codebase, one needs to fix millions of adhoc network configurations.
IPv7 on the other side, had absolutely different philosophy:
The objective of conversion is to be able to upgrade systems, both
hosts and routers, in whatever order desired by their owners.
Organizations must be able to upgrade any given system without
reconfiguration or modification of any other; and IPv4 hosts must be
able to interoperate essentially forever. (IPv4 routers will
probably be effectively eliminated at some point, except where they
exist in their own remote or isolated corners.)
Okay: so given that gethostbyname(3) only dealt with struct hostent with type of AF_INET:
* https://pubs.opengroup.org/onlinepubs/000095399/functions/ge...
* https://www.akkadia.org/drepper/userapi-ipv6.html
Those had to be rewritten to support AF_INET6 and use use that new address type. See also changing all socket(2) calls.
* https://datatracker.ietf.org/doc/html/rfc3493
* https://datatracker.ietf.org/doc/html/rfc4038
Regardless of what was chosen to be IPng, there would have been a whole bunch of rewriting necessary. If "IPv7" (TP/IX) was chosen as IPng (instead of SIPP(-16) becoming "IPv6") then we would have to add "AF_INET7" everywhere. And the supporting infrastructure (e.g., new DNS record types) would also have needed to be done for AF_INET7, just like it had to be done for AF_INET6.
> The C programs and network protocols have been implemented for 20+ years.. so why isn't everyone switched yet?
Because most programs are written in Western, industrialized countries. And those countries have plenty of IPv4 address to go around since they got to the Internet first. And so there is no (perceived) shortage for the people writing and and running the largest Internet services they feel no pressing need to. ("Address shortage? What address shortage?")
IPv6 has not taken off not because it's "bad" or "worse" than IPv4, or because IPv4 is "better" than IPv6: it has not taken off because of inertia: IPv4 works well enough and its short-coming (e.g., NAT) are known quantities with known workarounds.
> IPv7 on the other side, had absolutely different philosophy:
All IPng had the same criteria, including gradual upgrades ("Technical Criteria for Choosing IP The Next Generation (IPng)" § 5.5 Transition):
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.
Rather, IPng will need to co-exist with IPv4 for some period of
time. There are a number of ways to achieve this co-existence
such as requiring hosts to support two stacks, converting between
protocols, or using backward compatible extensions to IPv4. Each
scheme has its strengths and weaknesses, which have to be weighed.
Furthermore, we note that, in all probability, there will be IPv4
hosts on the Internet effectively forever. IPng must provide
mechanisms to allow these hosts to communicate, even after IPng
has become the dominant network layer protocol in the Internet.
The authors of RFC 1475 themselves 'abandoned' / changed TP/IX and put forward CATNIP:
* https://datatracker.ietf.org/doc/html/rfc1707
You are putting forward an idea (RFC 1475: TP/IX) which the authors themselves did not put forward for evaluation.
And yes, maybe IPv7 in particular is not the best solution, but it's hard to imagine how it could be worse than IPv6.. 20 years since support has been added to all core software and it's _still_ not adopted by end users?
I think the problem with IPv6 is a decision to redo all the management methodology. Your RFC 1726 illustrates it well: there is only one brief mention of backward compatibility in 5.5, listed as "optional" feature, and whole sections about changing the protocol in incompatible way, including 5.8 which starts with:
People complain that IP is hard to manage. We cannot plug and
play. We must fix that problem.
The difficulties encountered with IPv6 would have been the same even if another proposal would have been chosen for IPng because the exact same thing would have needed to be done: new address type for syscalls, new data structures, new surrounding infrastructure.
When your original standards do not allow for address length changes/flexibility, you have to write a new standard with the new address size, and there's no way to stuff >32 bits of data (addresses) into a 32-bit field. IPng would always have been a breaking change, regardless of proposed candidate chosen.
And if you're not going to have a flag day (à la NCP-IP changeover), then you'll need transition mechanisms with tunnels for sparse dispersal between IPng islands in a sea of IPv4.
> And yes, maybe IPv7 in particular is not the best solution, but it's hard to imagine how it could be worse than IPv6.. 20 years since support has been added to all core software and it's _still_ not adopted by end users?
All the proposals for IPng needed to have the same things done. "Technical Criteria for Choosing IP The Next Generation (IPng)":
* https://datatracker.ietf.org/doc/html/rfc1726
New packet type/header, new API options, new records and data structures for DNS, transition mechanisms (tunnelling). All this needs to be rolled out to hosts, routers, firewalls, ASICs, etc.
All the while IPv4 would continued to be used, so what incentive would business and IT departments have had to move to TUBA or TP/IX-CATNIP? ("Our (IPv4) network works, why do we need IPv7?")
> Today, for home networks, IPv6 is even harder to manage than IPv4 was, just try to keep your small office LAN functioning while handling ISP address changes.
Before recently moving ISPs (to go from DSL to GPON) I had IPv6 for several years on the old one and all my hosts (cabled, Wifi), phones, printers, etc, had IPv6 addresses given out by RA by my Asus, and I had no issues.
In fact IPv6 worked "too well" for me at one point: a while ago I was web surfing I had all those little Facebook icons show up that were served from their web site, probably dropping cookies on my system. I didn't want that so I put FB's domain in my hosts(5) file so that it go to "0.0.0.0": the little icons went away.
Then suddenly they appeared. And I checked hosts to make sure things were still there, and I did web browser debugging to see if things changed in the HTML.
And then I remembered that my ISP had activated IPv6, and so the icons were coming from FB's IPv6 address. Once I added "::1" for FB in my hosts file the icons disappeared again.
The IPX/SPX and DECnet folks managed to learn IPv4, so I'm not sure why the IPv4 folks have such a hard time with IPv6. IPv6 is no more difficult a Layer 3 protocol than IPv4.
And there's a lot of software that never got corrected, that explodes when it reads an address that isn't IPv4 even if uses a more modern API.
Meanwhile IPv4 was supposed to be sunsetted in 1990, had been actively pushed to be migrated off in 1990-1995, but the cost of updating software that used the popular BSD Sockets API, introduction of NAT to remove major pain point, and certain major client (read: government and military) giving waivers on upgrading deadlines to vendors[1] meant that nothing really moved.
And everytime people try to push things forward, some big chunk of infrastructure becomes a blocker - like cloud providers[2] - or we get inundated with "why in 1995 they didn't decide to go with something backwards compatible?". Newsflash - it was impossible for BSD Sockets software to be forward-compatible. If your software was build with XTI or similar interface (like Plan9's dial(), which is present in Go), you got IPv6, IPv7, and IPv9 support back in 1996, along with X.25 and who knows what else. In fact, IPv9 aka TUBA was actually implemented in network hardware around 1992 - the original RFC pointed to experiments using nearly unmodified Sun and Cisco hardware.
[1] US government finally learnt though, and if you're selling to them you now have to support v6 or wrap your product in a black-box that will handle v6. No deferrals for products/vendors.
[2] I'd argue AWS, GCP and Azure had significantly hampered global IPv6 migration
1) make everything the same, the good and the bad, just extend the address space, and replace all the networking stacks in all the gear everywhere. ... but don't make anyone learn anything new
2) if we're already replacing everything, make stuff better ... and make everyone learn everything all over again
And there are also other things - more dependence on ICMP, the concept that your LAN IPs are determined by your ISP (unless you also assign ULAs in addition to all the other IPs), and probably others I'm forgetting.
For many years it embedded the idea that every application had to handle exact details of each protocol it wanted to support through its exposure of gory details in sockaddr struct and requiring that as input to connect() and listen() calls.
All the SLAAC, privacy address, etc? That's just an emanation of people cargo-culting some practices that were workable with IPv4 but only by making the network suck.
And ifconfig got deprecated because it didn't fit linux networking API anymore, and nobody wanted to maintain it instead of writing something that fit well - which was iproute2.
IPv6 didn't only impact networking devices, it affected end-user applications that interact with the network in many ways, and this is a big part of the slow adoption.