So if you look at it, if you want to delay investments as long as possible, you wait for IPv4 addresses to run out before moving to IPv6.

And guess what, ARIN ran out only last summer. APNIC ran out almost 5 years.

So for any big company that doesn't really grow, why do IPv6, you have enough IPv4 addresses.

For any small company, in many cases you now have to buy addresses on the open market. Doable, but not nice.

And small companies wanting to become big companies? They are out of luck. Even if they can buy the addresses they need, it will be insanely fragmented.

Even Microsoft found out that for their corporate network, they don't really have enough IPv4 addresses and for some reason they also don't want to buy them in large quantaties. So they are trying to move to IPv6 internally.

Of course, this creates a very complex network effect. Big companies have no real incentive to offer IPv6, and small companies cannot switch to IPv6 only if big comanies don't support it.

Fortunately, some big companies do run out of IPv4 addresses so they do start using IPv6 to offload their carrier grade nat boxes.

For some new markets, say vehicle-to-vehicle communication, IPv4 is not an option. So that is likely to be IPv6 from day one.

If "Internet of Things" takes off, those things will be IPv6. Then you can give an IP address to every thermostat, every light bulb, every fire sprinkler head, every shelf tag price readout (saw some LCD shelf tags at a Whole Foods near Houston), etc. Those things don't care if they can't talk to some legacy Web site.

Then, in twenty years, everything on IPv4 is some creaky obsolete thing...sort of like how we have Windows XP things around now that aren't being replaced for various good reasons.

If you expect to move that server, say to move to a new colo provider, do you get an IPv4 address there? If you have to pay extra each month for IPv4 and get IPv6 for free, do you pay?

Legacy desktops, there are these things like youtube, netflix, they eat huge amounts of bandwidth. As an ISP you don't want that through your carrier grade NAT boxes. Better try to get customers to use IPv6.

These days many web pages are insanely loaded with ads, trackers, etc. Lots of connections, again really bad for CGN.

Big CGN boxes are also really bad for geolocation. IPv6 is better for that.

There is also reason to believe that gaming behind carrier grade NAT is going to be pain.

Finally, if there was one group of products supporting IPv6 early on, it was operating systems. Even XP can do IPv6. Web browsers support IPv6 for a long time now. So as soon as the network provides IPv6, just about all desktops pick it up and start using it.

I think the holdouts will be webservers, which was the other thing listed in the parent post.

While technically true, reason this is the killer feature of IPv6 - by far - is that it removes the need for NAT, restoring the most powerful feature of the internet: being able to publish as an equal peer without requiring the approval of a 3rd party.

Stuck on a "party line", network software was forced to find complicated workarounds[1] and de facto prevented most serious development of entire categories of network software. In practice, you still needed a 3rd party - usually some centralized service - to grant each peer their imprimatur[2].

The power of the internet is that it allowed unrestrained, ad hoc publishing. Entire protocols - such as HTTP - could be developed without first getting the approval of some governing body. We have done a very good job of pretending we still have this capability, IPv4 went the way of cable TV a long time ago.

Why is it taking so long to deploy IPv6? That's easy: a conflict of interest. Why would a big company that controls a scarce resource - IPv4 addresses and the publishing power the represent - want to dilute their power by with IPv6? These companies were based on refining Shannon's ideas bringing the cost of coping data rapidly to zero. They saw what happened when groups like the {RI,MP}AA became obsolete. Why would they want to invest significant amounts of money in their own obsolescence?

APPENDIX:

Whenever this topic is brought up, someone inevitably cries that that NAT is necessary "for security". This misconception happens when NAT/"IP Masquerading" and a statefull firewall are conflated. You can drop packets without changing any addresses (firewall only), and you can rewrite addresses without doing any packet filtering (NAT only). While these features are often used at the same time - especially in cheap home routers - they can be (and are) used independently. A firewall should still be used with IPv6.

Occasionally this "for security" concern is a concern for privacy. The NAT "party line" is seen as a source of anonymity ("you don't know which machine behind the NAT is making a request. First - how many bits of anonymity are you gaining in practice? Second - if HTTP is involved, the browser is probably leaking addresses anyway (WebRTC[3]). Finally, is your source port or TCP timestamp[4] leaking information?

[1] http://www.brynosaurus.com/pub/net/p2pnat/

[2] https://www.fourmilab.ch/documents/digital-imprimatur/

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=959893

[4] 0x03-2 http://phrack.org/issues/63/3.html

edit: grammar

What's amazing is how many companies who buy expensive firewalls for their corporate networks to do this on purpose under the illusion that somehow having LAN computers not being able to access anything besides outbound HTTP and HTTPS on the internet makes you more secure.

Haven't they noticed that everything piggybacks on top of HTTP/HTTPS these days? Even VPNs. You're protecting nothing.

Blocking outbound traffic at layer 3/4 does not require an expensive firewall. It provides protection against certain attack vectors, but as you say, most stuff nowadays uses http/https and in the case of trojans, likely reverse shells. Any firewall should be able to do this.

The expense usually comes in when doing application layer filtering and/or transparent/active proxying, which is the point at which you can block SSL VPN clients and the like. To do this over HTTPS it obviously requires MITMing TLS traffic, which I have mixed feelings about.

The text starts with a question that undermines the whole text: "does every node need direct Internet connection?". Today, with P2P traffic on the uprise, the answer is a striking Yes. If, even with the hurdles of poor performing NATs, there is market pressure for P2P protocols, it's absurdly obvious the Internet must be symmetrical, not server-client.

The text then goes on about the impossible transition plan for IPv6. It's now obvious that moving servers to dual-stack, then clients progressively onto IPv6 (through provider address-space exhaustion) is a sound plan. It's happening, and it's approaching the critical point. 2016 starts at 10% IPv6 traffic, will end at 25% IPv6 traffic. No sound company today will launch its services in IPv4 only and eschew 10%-25% of potential traffic.

The thing is, no sound company has to. No consumers have IPv6 only. Everyone is dual stack. By not deploying on IPv6, you don't lose a potential customer, you just make them use their existing IPv4 connection.

You'd better be on dual stack if you don't want your users to think the competitors feels faster/smoother. Otherwise you'll be the Yahoo of your market.

I work with VOIP and we had to disable v6 for our customers because we were getting complaints about latency issues repeatedly from customers on v6. Disabled IPv6, no more complaints.

IPv6 is more likely to make you "the Yahoo of your market" than the inverse, especially if you work in latency sensitive applications.

http://www.internetsociety.org/deploy360/blog/2015/04/facebo... https://www.youtube.com/watch?v=EfjdOc41g0s

Facebook and many other companies are finding that IPv6 is faster, personally at home I have found that disabling IPv4 allows me to more quickly buffer and stream Netflix, and about 30 - 40% of my traffic is IPv6. My Apple TV is the last hold-out that still seems to use IPv4 over IPv6 for Netflix.

In large part, this just boils down to the fact that less people use it, so less people notice problems and they're addressed less quickly. However, it makes it very unusable for applications like VOIP to customers when there are issues occurring. So while the bandwidth may be better on IPv6, I have no experience with that side of things personally, we're far more concerned with link stability - packet loss, latency spikes, that kind of thing. Again, just anecdotal, but not necessarily contrarian either.

[1]: http://www.urbandictionary.com/define.php?term=WIIFM

more like convincing ISPs to do more than the bare minimum is hard.

Greenfield IPv6-only ISP's are new now, but will be much more common in the future. Comcast kicked this idea around (at either NANOG or the @Scale conference) of not giving end users v4 addresses at all and doing 4to6 NAT in the cloud within 2-3 years.

Despite its overwhelming usage, IPv4 is already a second class citizen.

There are a whole lot of "sound" companies using AWS, which has extremely limited (and in many cases nonexistent) IPv6 support.

https://www.quora.com/Does-Amazon-Web-Services-support-IPv6 https://www.quora.com/Why-doesnt-AWS-EC2-support-IPv6

Fundamentally, why do they have to support ipv6? Especially when they have monopoly power over their customers? Its not like the customers can see the difference, and if a website doesn't work for a network of millions because the site v6 only the only loser is the website.

I'd be surprised if we hit 15% this year. Web services are doing a good job supporting v6, but now you have to get all ISPs to do it as well, and those ISPs are always ranked as some of the most consumer unfriendly companies in a lot of countries because they have no market pressure to improve or serve their customers well.

From: http://meetings.ripe.net/ripe-54/presentations/IPv6_manageme...

In the control plane, all devices need to be remotely managed, so NAT isn’t going to help us, nor is federated Net 10 islands…

IPv6 is the clear solution for us.

It's only separated in that your cable modem gets a non-routable IPv6 address. It's non-routable within the internet but is a stock standard globally unique IP address. This is used for management purposes.

Posit: the rest of the world continues growing and adopts IPv6.

Europe is left behind by stick-in-the-mud ISP's. We're already starting to see this [0]. The exception in Europe is Germany, mainly due to DT.

Discuss.

[0] https://www.google.com/intl/en/ipv6/statistics.html#tab=per-...

It's not obvious. A twenty-year deployment plan is a joke: Maybe this is the best they could come up with, but that doesn't convince me this was a good plan, or IPv8 should be modelled on this deployment.

> No sound company today will launch its services in IPv4 only and eschew 10%-25% of potential traffic

You have that backwards: No sound company would launch its services in IPv6 only because the Internet is IPv4.

It weren't broke, so nobody would ever fix it. A twenty year deployment period has no intrinsic problem, only philosophical ones. IPv6 was not needed, if not for the IPv4 exhaustion. When it became necessary, deployment started.

> You have that backwards: No sound company would launch its services in IPv6 only because the Internet is IPv4.

You read me wrong. I did not mean single stack IPv6. I meant dual stack IPv6/v4. The Internet is no longer IPv4 only. If it isn't clear to you yet, it will become so along the next 12-24 months.

I think there's a fallacy here. IPv6 does not solve this problem. Even if all devices were IPv6, typical homes will still have a router that blocks incoming connections by default, even if it is now a deliberate stateful firewalling decision rather than a consequence of NAT.

Firewalling P2P traffic effectively remains just as hard with IPv6 as with NAT.

The only way to fix this currently is to either stop using firewalls (very dangerous in this era of never-security-updated IoT devices) or to use IPv6 equivalents of the same solutions the IPv4 NAT world has developed (NAT-PMP, uPnP, etc). The latter case won't improve anything in P2P connectivity using IPv6 over anything we have already with IPv4 NAT.

For example, ISPs hand out entire /64 per customer (at a minimum, almost all will give you larger subnets if you ask). This allows you to have a separate IP address per application, which can be allocated from an unfirewalled pool.

There's also the fact that almost all major OSs now come with sane firewall defaults, also allowing applications to punch holes via APIs. (You could also have done this with IPv4 if it had a larger address space.)

If you spend some time thinking about how to solve these problems with IPv6, you will find that there are lots of ways to do it that are simpler and far more secure.

For example, a single IP address per application would be fine, but there is no protocol that allows me to allocate addresses per application on a central home router such that I can then identify them to permit them individually.

And applications punching holes via APIs does exist in uPnP and NAT-PMP, but isn't that the same thing as what you dismissed above as a hack?

The most reliable way is to rely on your system firewall to prompt you to open up a port when an application binds to it (which can be accomplished with the default firewall software on a modern system.) Again, this is technically possible with IPv4 too, it's just impractical due to address space limitations.

> there is no protocol that allows me to allocate addresses per application on a central home router

Correct. But the whole point it to take the router out of the loop for this, and only use it as a coarse firewall. With IPv6 very device gets a separate /64, so it can simply allocate from its own pool of 10^19 addresses.

> And applications punching holes via APIs does exist in uPnP and NAT-PMP, but isn't that the same thing as what you dismissed above as a hack?

Not the same. With IPv6, you do not need to coordinate across multiple NAT devices (or even worse if you're double/triple NATted as in some countries.) You're also not limited by the maximum NAT table sizes (again amplified in the double/triple NATted situations.) Since each system has 10^19 addresses (preallocated out of a global pool of 10^38 addresses), these can now be treated as system resources and managed intelligently by the kernel.

I don't trust, and doubt I'll ever trust, the firewall on my Smart TV, even if it had one. That's because I don't trust that it'll ever receive timely security updates. So I must use [the firewall on] a central router.

I think applications communicating with firewalling is not a hack, but applications communicating with routing is a hack. E.g. I have two friends who share a house (and therefore an internet connection) and I can play a game with one or other of them (via uPnP) but not both at the same time. With IPv6 + uPnP (assuming that's supported), they'd still have the same firewalling they have now, but I'd be able to play a game with both of them. No?

Another way to fix this problem is a personal VPN that only establishes outgoing connections automatically by default but can proxy incoming connections when explicitly requested. This is the same type of thing as used with NAT, except without the expectation that your ISP is the one providing it. Considering how obnoxious ISPs are these days in terms of filtering and such, this would be a major improvement. Since I am currently doing this (minus the proxying so far which I haven't needed but could easily add) for $15/year with a IPv4 address and virtual host that is way overprovisioned for what it needs, it seems likely that this could be done on a large scale for IPv6 at a quite low cost.

Yes, and that would be the sensible thing to do.

This "public/private" distinction doesn't even work: What if you have two LANs that aren't bridged? Possibly because they are connected through a VPN? Or maybe one Ethernet and one WiFi? Can you communicate between them? Or only on "public addresses"? What if the VPN is between two companies, say, who don't trust each other? And why would you make it depend on the "address type" anyhow, why not just have the application drop connections that come from outside the LAN?

Blocking all inbound connections by default is no real problem as long as you have a protocol for telling the firewall which addresses/ports to open to the public - the problem with the "port forwarding" that you need with NAT is that ports collide and that you create asymmetric address translations or bottlenecks and all that crap, a simple protocol that tells the firewall to open a specific port or address would be trivial to implement and to use.

Also, IPv6 has link-local addresses, which are essentially "private addresses for a LAN", so you can actually set up services that are reachable only on a given LAN (and nowhere else) - but that really only makes sense for local LAN management (neighbour discovery and such), not for application protocols, those really should just be reachable from everywhere, as far as the local API is concerned, and access control should then happen based on source addresses, possibly implemented as a stateful packetfilter at the network boundary, as you otherwise severely limit which network architectures can be used.

I think the main additional assumption I have to (part of) what you describe is that applications (on a general purpose system) cannot be trusted to behave reasonably on the network, however users need insecure local networking to work. The public/private disctinction would work the way I imagined it, but only because I was assuming a limited form of source address filtering: essentially one bit on every interface (including VPNs) for "is this local" (I also assume separate addresses per interface). The second address is so that so wildcard listening only listens on local addresses, and explicit public addresses need to be specified (or otherwise enabled) by the user before a server will listen on it. I didn't realize that just doing source address filtering as you suggest could accomplish the same thing with one address in a much simpler way.

This would allow two users to have the same port opened. This makes it easier to communicate with others on the internet.

Nope, it's much easier because the addresses are easy to predict. When both parties are behind NAT, neither side knows which address and port they will appear to be coming from to the other side, while without NAT, both parties know exactly what address the other side will see (it's the one the local socket is bound to ...), that makes it relatively easy to establish a connection through a stateful firewall with a simultaneous connect if both sides can somehow tell each other where their respective sockets are.

It's outright trivial with UDP, not quite that easy with TCP: Assume both sides are behind a stateful firewall, both sides simply send a packet from their socket to the respective remote address/port, which will cause each local firewall to establish a connection tracking entry that will allow packets in the respective opposite direction to pass through. There is a race condition that might cause one of the packets to be rejected by the remote firewall (if it arrives before the locally originated packet passed through the firewall), but that doesn't matter: Afterwards, both firewalls have an entry for the connection, and all subsequent packets will pass through just fine. This is impossible with NAT because you cannot know the remote address that the NAT will assign for the connection, so you cannot send a packet to establish the entry in your firewall, and you cannot learn the address because you would need to receive the packet to see the address on it, which you can't as long as the firewall doesn't know about it.

Also, a protocol for opening ports on the stateful firewall would be much simpler without NAT, as the firewall doesn't need to allocate ports or handle conflicts between multiple clients wishing to be forwarded the same port: The address/port allocation authority is with the client, the client('s kernel/network stack) can simply allocate ports on its assigned addresses and then only needs to tell the firewall that connections to a specific address plus port should be allowed in. This also means that, for example, the firewall forgetting those open ports doesn't cause much trouble: The clients simply can tell it again whith ports to open, and they will be reachable again, at the same address, no need to tell peers a new address because a uPnP gateway forgot which ports it had allocated to which client.

And maybe most importantly: P2P traffic between devices on the same LAN becomes much, much simpler. Currently, if you have two participants of some P2P system in one LAN segment, where both establish an open port on the NAT gateway via uPnP, when one wants to connect to the other, there are roughly three possible scenarios: It can try to connect to the public address/port as established by uPnP, just like any remote client would. If you are unlucky, the NAT gateway only does DNAT, in which case the connection won't work because any responses will come from the local address of the peer instead of from the public address of the NAT gateway, so won't be recognized as belonging to the connection. If you are lucky, the NAT gateway does hairpin NAT, in which case the connection works, but all traffic has to go through the NAT gateway in order to rewrite addresses, instead of directly from one machine to the other at the ethernet level, which usually will be much slower than a direct transfer (even more so when there might be multiple people doing the same thing on the same LAN, where the switch might well be able to forward multiple gigabit flows at once, but your DSL NAT gateway most likely will not, not even if they are both in the same case). Or, if you want to avoid both of that, you'd have to somehow detect that you are in the same LAN and then figure out what the address of the peer on the LAN is in order to connect to that address instead (and note that you can't use the local addresses to decide that, even if you know them, as you might well have addresses in the same private address range, but still be connected to completely different LANs).

Without NAT? You simply connect to whatever address the peer announces. If you are on the same LAN, your machine's routing table will automatically route the packets to your local LAN, directly to the other machine, at full LAN speed. If not, they will be forwarded to your local gateway, through the internet, through the remote stateful firewall, and to the remote peer. No difference at all, apart from the speed, possibly, it just works.

It seems like this is another doomsday prediction. Evidence would make it persuasive.

I do not see the word "direct" in any part of the rant. Am I missing something? Are you sure that is what he meant? The text reads "do these computers really need to be on the Internet?"

Indeed an internetwork like any other network should be symmetric but I am not sure adpoting IPv6 is the only way to achieve that. Nor that adoption of IPv6 would be used for that purpose.

Instead I see asymmetric, data collection motivated ideas like "Internet of Things" being put forth as "the way of the future". Such ill advised ideas would more likley be the justification for using IPv6.

Do all these "things" (computers) need to be on the Internet?

Not that I know of.

There's an argument, not made by me, that some IoT is foolish to which I alluded. Is that what you mean?

The is one advantage of having an active duopoly [1] in the ISP market. Belgacom (38% market share) started migrating customers to dual stack in 2013. Telenet (40% market share) soon followed in 2014.

[1] http://www.broadbandtvnews.com/2015/03/20/telenet-belgacom-s...

Also, I found a simple solution to the fact that neither VM or BT offer IPv6 - use a different ISP.

I don't have any problems running VOIP at home, though.

There aren't any websites that are IPv6-only, and until there are, telling me to vote with my wallet is pointless.

Likewise for gamers. Often IPv6 is lower latency or again easier to configure. For some people that's worth paying money for.

Ultimately as IPv4 addresses get more expensive and IPv6 equipment becomes cheaper, the costs will shift, and the benefits will remain.

There are no games that use IPv6 unless you are on Xbox One which uses IPv6.

> I'm frankly tired of dealing with the incompatibility.

My point is that you have a choice. As lmm correctly points out, it's how you value your time.

I can often get an IPv6 address that fails to work: I'll do DNS lookups and get a huge delay while connectivity fails-over onto the Internet (IPv4). Hotels are worse.

The best solution right now is to disable my OS's IPv6 support which is positively insane if the goal is to get everyone to do the opposite.

The thing is, IPv6 proponents want me to do something (vote? switch? not really sure), but don't equip me with the ability to do it smartly. Instead I get derided by people who judge me for not being smart enough, or valuing my time enough (wtf?) to switch to IPv6. Like I'm somehow holding back progress.

> The thing is, IPv6 proponents want me to do something (vote? switch? not really sure), but don't equip me with the ability to do it smartly. Instead I get derided by people who judge me for not being smart enough, or valuing my time enough (wtf?) to switch to IPv6. Like I'm somehow holding back progress.

I'm not really sure what this means. Everyone values their time differently, I'm certainly not going to judge anyone for that. If IPv6 doesn't solve any problems for you, then great. Don't try and pretend that it's not helping loads of other people solve their problems though.

And: Does your VoIP provider really support IPv6? I have just check the common SIP providers where I live and they are all still on IPv6 … :(

not really. Whether they are reachable via the help of a STUN server or directly doesn't make a difference. They are reachable either way.

Being able to connect to my home machine from anywhere. Presently, I have to manually[1] mess around with NAT to accomplish this, and the obvious ways to set up `ssh machine-a.me.com` and `ssh machine-b.me.com` simply don't work. That alone, to me, is a single user-visible feature.

Further, I've had tons of scenarios proposed by my parents that would be considerably easier to do with IPv6. "Why can't I just transfer this file between these two computers? Why does it need to go through some third party?" (This was really a bit before Drive, but even with Drive, it's still an extra step that doesn't really need to be.) As an engineer, there's plenty of problems I simply cannot solve while it remains impossible to address a computer that's supposedly on the Internet.

> Instead, it's sold a twenty-year clusterfuck of doomsday predictions about running out of IPv4 addresses

I can't actually obtain an IPv4 address for a device on my network. There's absolutely nothing I can do. So, from my perspective, those doomsday predictions appear to be correct. (And when I can, it often costs extra for something that ought to cost nothing.)

[1]: All the while we have standardize protocols that should allow software to automatically configure NAT in a router, except they're supported by nobody…

They all claim to be preparing trials but I wouldn't expect to see any real activity from them until we start seeing IPv6 only sites, which would be unreachable to their subscribers.

What do you mean by this? I have IPv6 and everything seems to work great.

There simply was no technical possibility for backwards compatibility, due to the way IPv4 was designed. So a dual-stack deployment has been pretty much the way to go from the start. It's unfortunate that it takes 20 years, but no better deployment scheme has been proposed during this time, only lots of new tunnel and NAT schemes. The smart phone revolution was really slow, too.

So what? IPv4 took some 25-30 years to get mass adoption, and didn't have an earlier version of itself competing for mindshare.

Except for the several messed-up deployments, IPv6 is progressing well, and even fast. It'll be available as soon as our current crisis becomes undeniable... and judging by your comment, it's still possible to deny it.

I used to ask my ISPs "When will you finally provide ipv6". Then i stopped caring. Now I wish they wouldn't have bothered and consider paying a premium to go back to ipv4.

I am still able to play games and browse the internet and SSH to machines. What's wrong?

In v4, you block the offending address and you block all the NATed devices behind that v4 address.

In v6, you block the offending prefix and you block all the (non-NATed) devices behind that prefix.

In both cases you block an individual compromised subscriber, no matter whether only a subset of their devices are compromised.

- there is concern when you browse the web with a IPv6 address that you create a target for attackers (by revealing your address). Solution ... shadow IP addresses! When I saw this on my Mac, I was shocked!

- IPv6 to IPv4 NAT exists but is stateful. WTF? This significantly increases the cost and lowers the ability to scale. A high performance NAT solution would have been the first thing I would have designed (for interop purposes)

How is this any different to IPv4? An incoming default deny rule on your firewall offers the same protection as the "accidental" protection that NAT provides, and you can translate/proxy/VPN/whatever-else IPv6 addresses/connections in all the same ways you can with IPv4 in order to disguise the source IPv6 address if you really have a need to.

Heck, if you are worried about security having a /64 allocated means that if you aren't providing incoming services you jump around a huge range if you want to so you don't need to be at the same address now as you were an hour ago (unless you have active TCP streams or similar that have been running that long), and even without moving around if you pick your address within the /64 arbitrarily you aren't going to be found by a port scanner in any amount of time that would make scanning a practical option.

> IPv6 to IPv4 NAT exists but is stateful.

Isn't IPv4 NAT stateful when translating potentially many source addresses? Otherwise how do you reverse the translation when response packets arrive?

A one-to-one mapping shouldn't need to be stateful, but where that is useful most people go with being dual-stacked instead.

The state is the NAT table.

Now, there are some "NAT" implementations that don't keep state but they for very specific scenarios. You can't port forward, for example. You can map 1:1 IPv4 to IPv6 though, but why do that when you can give native v6 the whole way?

Are you referring to using the MAC address in the IP? https://en.wikipedia.org/wiki/IPv6_address#Modified_EUI-64

Actually... RFC6145

This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 2765.

As some one who used to wok on international standards for British telecom IPv6 is a total F&^%ing disaster and this was obvious back in the late 80's

When the original ipv6 group is 19 ivory tower academics and 1 guy from Bell labs what do you expect.

Per [0][1] it was:

> The working-group members were J. Allard (Microsoft), Steve Bellovin (AT&T), Jim Bound (Digital Equipment Corporation), Ross Callon (Wellfleet), Brian Carpenter (CERN), Dave Clark (MIT), John Curran (NEARNET), Steve Deering (Xerox), Dino Farinacci (Cisco), Paul Francis (NTT), Eric Fleischmann (Boeing), Mark Knopper (Ameritech), Greg Minshall (Novell), Rob Ullmann (Lotus), and Lixia Zhang (Xerox).

Almost none of which are academics and it wasn't the 1980s.

[0] https://en.wikipedia.org/wiki/IPv6#Working-group_proposals

[1] https://www.rfc-editor.org/rfc/rfc1752.txt (Appendix B)

Your documents are later ones to the initial one I saw which was all academics plus one guy from bell labs.

(hint: there were, lots of them, it's a hard problem, mostly for psychological reasons, technically, it's mostly trivial.)

By the late 80's it was obvious that the way that ipv6 was proposed was not tenable - it should have been killed 20 years ago.

However, what is non-tenable about IPv6, and how was this obvious in the 80s?

IP has on each packet both the source and the destination address, because the destination uses the source address to send back the response. Nothing works if you can't send responses.

If your device has an address from the "extended address space", you cannot talk to any device that doesn't know about that "extended address space" because they won't know how to read your source address and how to send a response back to it. Just as with IPv6: You cannot talk to an IPv4-only device if all you have is IPv6.

Essentially, IPv6 does exactly what you are suggesting. Things just don't work as you imagine them to, but rather one unavoidably ends up with "a completely separate network" if one does things as you suggest.

32 bits was perfectly adequate for routing for decades and would still be if not for the route explosion caused by exhaustion itself.

A similiar problem could still happen inside your mixed IPv4-"IPv4.1" system, but in that case it's your problem to fix and not the fault of the protocol or of some distant sysadmin.

So endpoints would not have publicly routable addresses, and your packets would be sent across the Internet encapsulated as IPv4. Isn't that just NAT? It would work, to the extent that NAT works today, but it wouldn't get us any closer to having a publicly routable network with more addresses (you'd still get undebuggable problems whenever you tried to switch on public routing), and it wouldn't address the real problem which is not just IP address exhaustion but also class A, B and C exhaustion. What do you do when a new datacenter wants to connect to the Internet? Give it a single IP taken from the middle of a block owned by the same company? That's your "route explosion caused by exhaustion itself" right there.

No, the critical difference being that "NAT internal IPs" are now public IPv6s and the NAT mapping, instead of being private to the NAT box is now exposed to the other "NAT boxes" on the internet, for example encapsulated in an IPv4 option that is ignored by legacy systems. This means two IPv6 networks can converse transparently and not care what IPv4 connectivity lies between them.

This further means that:

1. IPv6 deployment is no longer a tragedy of the commons: if I deploy IPv6 I get it's benefits immediately along with my remote peers, no longer dependent of providers, AWS or some remote sysadmin over which I have no control.

2. There are no longer any dual stacks to maintain, timeouts, and switches that plague us today; IPv6 just works on the existing IPv4 infrastructure until it becomes dominant.

3. IPv4-only services are incetivized to upgrade because they can provide better service to IPv6 customers who share a common IPv4 that will presumably revert to a form of NAT when connecting to an IPv4 only server.

In short, a rational and much less risky upgrade path.

>What do you do when a new datacenter wants to connect to the Internet? Give it a single IP taken from the middle of a block owned by the same company?

It's obviously too late now to fix this. What I am saying is we did not have a datacenter explosion, but a route explosion fueled by exhaustion, where the same datacenter needed more public IPs, got them in a myriad of tiny blocks and broadcasted misery to all routers on the planet. An IPv6 success would have allowed us to keep 32 bit routes for a long time.

But IPv4 connectivity can only route according to the IPv4 rules. Which means two "IPv6" networks would have to use the IPv4 rules as well, because a network where half the routers are using one set of rules and half of them are using the others will go terribly wrong. So you're stuck only using "IPv6" at the endpoints, and IPv4 in between - i.e. NAT.

> It's obviously too late now to fix this. What I am saying is we did not have a datacenter explosion, but a route explosion fueled by exhaustion, where the same datacenter needed more public IPs, got them in a myriad of tiny blocks and broadcasted misery to all routers on the planet. An IPv6 success would have allowed us to keep 32 bit routes for a long time.

The estimate I've seen is that fragmentation means there are 3x as many routes as there should be. Which sounds like a lot, but with the exponential growth in the number of internet-connected devices, that would only have covered another ~2 years' growth.

I stress again that when you connect me from behind NAT, I see your public IPv4 but have no idea how to reach you back, nor can you publish such info. When you contact me over an 6:4 encapsulation, I get your globally unique IPv6 which I can use to connect back to you at a later date - connection works end to end as if we were inside an IPv6 Internet, so it's not fair to call it "NAT".

It's more aptly a NAT64-tunneling hybrid, that's transparent, backwards compatible and can be switched to full v6 operation when critical mass is achieved, by symply publishing 128 bit routes. In hindsight, I am convinced the dual stack solution is much, much harder to deploy and was the wrong solution.

I know about the so called transition technologies and their dubious record, however the original context was "an alternative protocol backwards compatible with IPv4", not making IPv6 work on the IPv4 Internet. The former is possible (x) and was preferable circa 1996, while the latter are afterthoughts bound to fail: you obviously can't route true IPv6 on IPv4 hardware without upgrading it, and at that point, why not go dual-stack ?

Unlike a backwards compatible packet format, transition technologies require gateways to the "new" IPv6 Internet, that are checkpoints by definition and need configuration, resources and attack surface, amplifying the chicken and egg problem - why deploy gateways to the IPv6 when there's nothing there ? Add flakiness of the transition technology itself, for example Teredo clients can't even reach one other 25% of the time due to symmetric NATs.

(x) brain fart time:

If I were to redesign IPv6 today in a backwards compatible manner, I would treat the existing NAT hierarchy as a set of different routing realms, and upgrade only these points to do a stateless forwarding of the extended packets, while keeping their existing behavior for regular IPv4 traffic.

For example, to reach host 10.10.10.10 siting behind NAT 2.2.2.2, an IPv4 packet is prepared with an extension field :

IP Header: DEST: 2.2.2.2

Extended Header: DEST: 10.10.10.10, REALM=0

(src omitted etc.)

The IPv4 infrastructure will forward the packet blindly while the upgraded NAT/router will recognize the extended format and instead of dropping it will mangle it and forward it along:

IP Header: DEST: 10.10.10.10

Extended Header: DEST: 2.2.2.2, REALM=1

The destination stack will establish a connection if it recognizes the packet format, or drop it if it's a legacy IPv4 implementation.

You can repeat this for a bunch of chained NATs, incrementing the realm and swapping more routing bits from the Extended header into to the IP header, while reversing the mangling when extended packets exit from the inner routing realms. In an 128 bits address you could do this 4 times, sufficient even when dealing with something like "NAT44444".

So you can keep end to end stateless routability as long as all NATs are cooperant, and fall back to regular IPv4 over NAT when they are not. In time, NATs will transform to routers, simply mangling and forwarding extended packets and do less and less state tracking for legacy packets, until eventually tracking can be turned off.

The idea is to upgrade only key edge infrastructure (NATs), to do a very simple and stateless transformation, and not the whole Internet with a risky and complex technology. NAT clients are incentivised to upgrade (for p2p, voip etc.) without finding themselves in an Internet ghetto with high latency and routing blackholes. It's the same Internet with the same routes. In time, ISPs can release some of the massive SOHO IP space that's no longer justified.

Maybe not an entirely thought out idea, but it's a starting point. Or would have been. Despite it's troubled childhood IPv6 is of course superior, allows easy renumbering and real multicast, etc.

AFAIK this hasn't and will probably never make it out of experimental status.

* Except Kindles.