The world in which IPv6 was a good design (2017)

https://apenwarr.ca/log/20170810

by beefhash • 7 years ago

589 238 7 years ago

ktpsns• 7 years ago

tl,dr; QUIC is solving shortcomings of IPv6, amongst others the badness of remaining Ethernet and IPv4, by replacing TCP.

This is one of the most beautiful and deep articles about our networking/IP world I've ever read. It's so helpful to hear background stories from the early years of networking (like IPX, I still remember it but was too young to really make us of it)!

fulafel4• 7 years ago

This is a fair summary of the latter part of the article but I think the argument is flawed:

1. Mobile IP isn't actually IPv6's raison d'etre

2. Even for the mobile IP case, QUIC only addresses the HTTP client part of it - but HTTP didn't need mobile ip to begin with

wahern2• 7 years ago

Edit 2017-08-16: It turns out that nothing in this section requires IPv6. It would work fine with IPv4 and NAT, even roaming across multiple NATs.

That's not quite fair. IPv4 and NAT require maintaining a lot of state at critical intermediate routers. I'm sure we've all experienced (perhaps regularly) a NAT'ing router losing state because of a reboot, state tables overflowing, or similar hiccups.

The one absolutely redeeming quality of IPv6 is that with 128 bits routing can be kept much more hierarchical and stateless. Fragmentation will occur and is occurring because we now apply trust metrics to IP addresses (thanks, spammers!) so there's value in owning transferable subnets, but I think IANA and major ISPs can keep the fragmentation process slow enough that hardware/software capabilities can stay apace, preserving a largely stateless, hierarchical routing infrastructure.

That doesn't solve the mobility problem, but it does provide significant benefits to mobility solutions. Don't underestimate the cost of NAT'ing in terms of systems complexity. NAT'ing isn't the type of layer, like ethernet MAC addressing, that we'll always be stuck with.

It's also worth pointing out that some of the [now] unnecessary complexity of IPv6 will fall away over time. IPv6 will get simpler as time progresses, as it already has.

jsn• 7 years ago

IPv4 and NAT require maintaining a lot of state at critical intermediate routers. I'm sure we've all experienced (perhaps regularly) a NAT'ing router losing state because of a reboot, state tables overflowing, or similar hiccups.

As far as I can see, that state is not very important for the mobile IP design describe in the article. A router reboot or other hiccups are handled more or less the same way as an address change (there is a temporary connectivity loss, and when it's restored, you create a new mapping on the Y server between the existing connection, identified by the same old uuid, and the new external/internal addresses/ports of the client X).

wahern2• 7 years ago

Exactly, it's not necessary. All it does is add complexity and unnecessary failure points.

Mobile providers use IPv6 for a reason. CGNAT is still used because, among other reasons, the internet (at least in the U.S. and Europe) is still predominately IPv4. If IPv4 disappeared tomorrow CGNAT (and the centralization of mobile network egress points) might be able to go away, too. If, additionally, QUIC completely replaced TCP, I can't think of any reason for maintaining such choke points.

In as much as IPv6 provides a faster, more reliable network, it benefits QUIC. And the more ubiquitous QUIC becomes the easier IPv6 will become to manage.

QUIC won't be a panacea any more than IPv6 was. But they're both important improvements to the network.

thaeli• 7 years ago

The one absolutely redeeming quality of IPv6 is that with 128 bits routing can be kept much more hierarchical and stateless.

For now. Yes, 128 bits is a lot. Yes, even the 64 bit host-part is a lot. But the old-fashioned, pre-CIDR allocation strategy of IPv6 is _incredibly_ wasteful of address space. There are advantages, and for a single-planet, pre-IoT Internet, that's plenty. But IPv6 has taken so long to adopt, and future major stack changes will only be harder, that we really do need to think about what will work for the Internet a hundred years from now.

jandrese6• 7 years ago

I don't think you realize just how big 64 bits for the network address is. It's one of those things where the scale is so large it's outside of normal human experience and we just can't hold it in our minds. There is no danger of running out of addresses for hundreds of years unless we decide it is necessary to give every single atom in the Earth its own /64. Even then we would have plenty of room to spare in the address space.

It's just an absurdly large number. Giving out a few thousand to anybody who asks will never be a problem until humans have literally filled the galaxy.

zAy0LfpBZLC8mAC5• 7 years ago

But the old-fashioned, pre-CIDR allocation strategy of IPv6 is _incredibly_ wasteful of address space.

What would be wasteful would be keeping even more address space unallocated, as that would cause all kinds of costs, from administrative overhead, incentives to build unnecessarily suboptimal networks, delays due to address allocation processing, to more fragmented and thus larger routing tables and renumbering.

Saving address space for the sake of saving address space is not useful.

stordoff• 7 years ago

You could give every single IPv4 host its own complete IPv4 address space, and you would _still_ have enough addresses for 2 * 10^19 planets[1]. 2^128 is _absurdly_ large.

[1] 2^128 / (2^32 * 2^32) = 1.84 * 10^19

Dylan1680710• 7 years ago

for a single-planet, pre-IoT Internet, that's plenty

The main assignment blocks right now are some /12s. We can easily split off a /8 for every planet and moon, or whatever. Communication between stars won't work with IP, let's worry about that issue later.

Internet of things isn't an issue at all here. You can cram as many as you want into a single subnet. If you desperately need an enormous pile of subnets for IoT for some reason, it's straightforward to take a /64 and chop it into a billion subnets that hold a billion devices each.

pdkl958• 7 years ago

IPv4 and NAT require maintaining a lot of state at critical intermediate routers.

Far worse than the maintenance costs, NAT has has prevented (modulo a few niche environments) the development of any network software that isn't client-server. NAT is a party line[1]. Anyone that thinks NAT is useful for anything other than an address space hack (or a few other less common uses[2]): why aren't you replacing all of your household (or small business) phone numbers with a single party line? Surely you could implement a local PBX if you needed to support more than one kind of incoming call. Or what if the phone company offered a new type of line: 10% cheaper, no way to receive incoming calls. Well, sometimes you can get some incoming calls if you convince whomever actually controls the inbound phone number for your phone line to forward calls that come from certain numbers or some other criteria, like they did with the old party lines: just get people calling you at the shared number to pause after connecting and dial you per-arranged ring code[4]. (warning the phone calls might still be answered by whomever picked up first)

NAT keeps us on the client/increasingly-centralized-server model. NAT removed one of the most important benefits IP-based internetworking: no discrimination between different types of network host. Each addressable host has the power to publish - using any protocol, including new protocols - without needing an imprimatur[5]: the permission to publish from granted by some other party.

If we are very lucky, we might regain some of the lost capability with IPv6.

[preemptive response: no, NAT does NOT provide any security benefits. NAT just rewrites packet address/ports. Dropping packets is the job of the (probably stateful) firewall. Nobody wants to change that part, firewalls are important. And if you think NAT hides your internal addresses... really? Is it 192.168.x.y? Can I send GET requests to your router with a webpage full of hidden/obscured img tags with src="http{,s}://192.168.1.{1..254}/whatever?i=want"?]

[1] https://en.wikipedia.org/wiki/Party_line_%28telephony%29

[2] Most of the time, when people say "NAT", they are only referring to the many-to-one ip masquerading similar to what is implemented in most home routers, or perhaps the "carrier grade" extensions of the same basic idea. They are probably not referring to the other flavors of NAT[3].

[3] https://tools.ietf.org/html/rfc2663#section-4.0

[4] https://en.wikipedia.org/wiki/Party_line_%28telephony%29#Sel...

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

userbinator• 7 years ago

[preemptive response: no, NAT does NOT provide any security benefits. NAT just rewrites packet address/ports.

NAT automatically prevents attackers from scanning for and attacking listening ports on the hosts behind it. Given that those who want a service to listen to the Internet should also know enough to forward the ports, I'd say it's a pretty important security benefit and one that has greatly slowed the spread of worms.

Can I send GET requests to your router with a webpage full of hidden/obscured img tags

That requires extra action on the part of the "attackee", whereas without NAT the attacker would be able to directly connect to a port, to any machine anywhere on the Internet.

ComodoHacker3• 7 years ago

Each addressable host has the power to publish - using any protocol, including new protocols

OK, you remove NAT but if firewall remains with default DROP ALL policy, what's the difference? Even worse, the firewall now isn't in your home, it's in ISP network and out of your control. So you need imprimatur as before.

floatboth2• 7 years ago

if you think NAT hides your internal addresses

More like cgNAT makes you share the external address between many people. It gives you plausible deniability: "dear $forum admin, it's not me creating multiple accounts for trolling from the same IP address, it's the guy from the next building, I swear!" / "it's my neighbor's porn visible on https://iknowwhatyoudownload.com/en/peer/ not mine!"

Of course that's Not Security, that's just obscurity, but damn, it kinda does feel good :D

dang• 7 years ago

Discussed at the time: https://news.ycombinator.com/item?id=14986324

azernik9• 7 years ago

This... doesn't really describe the motivations for IPv6 well.

Working in networking, it was much-beloved because it eased the address allocation problem by giving you an enormous, equally-sized address space for every subnet, and included a potentially-simpler, stripped-down version of DHCP for non-router nodes. (Edge routers usually use DHCPv6, but only to learn what prefixes they should hand out to other nodes.)

For core network administrators, the additional address space lets them organize their routing tables hierarchically, which makes them smaller and easier to optimize for latency.

Plus, while they were breaking compatibility anyway, fixing up a bunch of annoying things with IPv4 that had been bugging implementers forever, like dropping (ugh) fragmentation, rearranging the header information to make it easier to do routing in hardware, and adding support for metadata in the form of extensions (useful for ISPs tagging traffic with routing instructions). Mobile IP was part of this, and was indeed IMO misguided, but is not the only or (in my experience as an implementer) the main motivation.

That whole digression into the semi-mess that is edge networks over the 802 suite (ethernet + wifi) is irrelevant to this core-network motivation. And in any case, ARP is (again, speaking as an implementer) a very tidy and useful abstraction layer. It's even used on non-ethernet networks!

tl;dr the big "killer app" of IPv6 is that it makes the lives of router makers and network-stack coders easier. Writing new IPv6 code is harder than just using your IPv4 code, but for green-field projects IPv6 is so much more pleasant to work with.

jefftk• 7 years ago

The post isn't "Why did people want IPv6" but "Why is IPv6 such a complicated mess compared to IPv4? Wouldn't it be better if it had just been IPv4 with more address bits?"

api2• 7 years ago

IPv6 is a complicated mess because it was designed by enterprise networking people. Everything in networking is always more complex than it needs to be. Always. Network engineers love to overthink everything and they've never heard of YAGNI.

azernik9• 7 years ago

Except it doesn't actually get the reasons right. The complication is because IPv6 is optimized for implementers, not for users or students.

decnet• 7 years ago

@jefftk: ‘Why is IPv6 such a complicated mess’

Because it was designed by a committee?

Zrdr• 7 years ago

IPv4 address with more address bits would have worse, because it would have the same incompatibility problem as IPv6, without its benefits.

Actually, IPv6 is good design. Adoption is slow because most people and companies always prefer a cheap short term inferior solution compared to the good long term one.

Now, IPv6 is 25% of traffic. It will continue to grow, and at a point the network effect will be on IPv6 side. Not long after that, IPv4 will only be a niche for a few legacy systems.

Abekkus2• 7 years ago

Why isn't TLS client auth a turnkey solution for maintaining a single web session as a client moves between network segments?

kelnos3• 7 years ago

Aside from the fact that TLS client auth is currently a usability nightmare... well, it could be, but you'd be building that session-resume capability into a higher layer than would be ideal. Meaning that anything that isn't TLS would have to build their own session resumption system.

Conceptually, you want to push things as low in the stack as is feasible.

Abekkus2• 7 years ago

Session is a higher OSI layer than transport, and any secure session management would probably be as complicated as TLS in the end.

tptacek4• 7 years ago

What a great post, about something I've been working on almost as long as Avery. I'm sad I missed it the first time it came around.

I was going to write a long response here, but I think I'll save that for a blog post (short summary: I disagree vehemently with what I believe the premise here to be, think that people shouldn't be waiting for the IETF to give them permission to build new network layers, am fairly certain there's no such thing as a "layering violation", and think overlay networks are/will-ultimately make IPv6 irrelevant). So on this thread I'll just pick some nits.

Ethernet networking is not as gross as it's made out here. ARP isn't entirely pointless! For instance, at the ISP I ran tech for in the 1990s, I was able to pretty seamlessly move our "data center" and corporate offices across Chicago without renumbering just by exploiting ARP (I wrote a dumb proxy ARP policy router). We did similar things to route traffic to the particular terminal services customers were dialing into, or to the ISDN router who's PRI happened to service a particular customer. An IP purist would object that we weren't using OSPF the way God intended us to, but it worked and was probably more reliable than the bona fide routing protocols we replaced that with.

This narrative also, I think, gives short shrift to DHCP, which does a lot more than pick IP addresses out for new endpoints, but also pretty much fully configures their IP connection. If you had to tech support 10,000 random customers in the era before DNS servers were transparently assigned at connection, you're not pining for the simple elegance of RARP.

Also: nobody should care about "IGMP-snooping bridges", since IP multicast is and always was hopeless.

socraticmethod• 7 years ago

| IP multicast is and always was hopeless.

Out of curiosity what do you mean by this? Are you referring to all Multicast solutions? Can I just be specific -- what do you think of Dante, Audio/Video-over-IP or other time sensitive an synced services that use Multicast?

throwaway20482• 7 years ago

He means multicast over the internet at large, not tightly controlled networks.

It is basically a completely unstoppable DDOS and abuse tool.

azernik9• 7 years ago

ARP is also nice and abstract and well-defined; it can bridge from any multi-endpoint subnet's layer-2 address to an IP address. Not sure if anyone actually uses it for non-802, but the generality has forced a clean design.

To add to your praises of DHCP - it can also configure routers, and is in fact the standard solution for that in IPv6. Instead of giving you one or several addresses for NAT through DHCP, it gives the router an address for itself, and also a prefix to assign to clients on its internal network. Super neat stuff, and a boon to administrators.

Also to nitpick your summary, because nitpicking is what I do - layering violations are a thing, but only in the same way that violating software abstraction barriers are a thing. Not a hard-and-fast rule, and sometimes if you're doing weird enough stuff you just have to do it.

mcguire7• 7 years ago

To go further off the rails, layering violations are not a thing, because "layers" are a remarkably poor abstraction for a network protocol "stack".

runjake2• 7 years ago

Good points.

One issue, though "nobody should care about "IGMP-snooping bridges". I so wish this were true, but (first-hand knowledge) tons of infrastructure these days utilizes IP multicast, including building lighting, HVAC, intercom, VoIP, etc.

ChuckMcM• 7 years ago

I was going to say the same thing, so I won't :-). That said, I was in the Sun Systems group when Bob Hinden ("Boss Bob" (there were three Bobs in the group) of the network group was proposing SIPP as the "next generation IP." It has been illustrative (but I don't think educational alas) to see how much more easily this protocol would have managed to be implemented and deployed.

That said, as Thomas points out (indirectly) in the parent to this comment, the Internet was deployed across a pre-existing network (the telephone switching network) without any co-operation from the people who defined or wrote or deployed the protocols the implement telephone switching. As long as the connection from point A to point B worked, the packets could figure out how to get from A to B. There is absolutely nothing preventing a suitably motivated group from creating their own elegant "network" that they layer on top of the existing broadband networks of today, without having to either consult, or get permission from, any standards organization.

cure• 7 years ago

There is absolutely nothing preventing a suitably motivated group from creating their own elegant "network" that they layer on top of the existing broadband networks of today, without having to either consult, or get permission from, any standards organization.

And there are numerous groups doing that, e.g. https://yggdrasil-network.github.io/ and https://github.com/cjdelisle/cjdns.

mrkstu• 7 years ago

That is essentially what most SD-WAN devices do- treat the Internet as an 'underlay' network- most of them are using proprietary code to create their own network infrastructure that isn't standards based.

otterley• 7 years ago

Here's the SIPP paper, in case anyone is interested: https://datatracker.ietf.org/doc/rfc1710/?include_text=1

tssva2• 7 years ago

In the early to mid 80s "layer 3 switching" was becoming a thing and each switch vendor had their own method for implementation. Cabletron was a large switch vendor then and their method of layer 3 switching depended upon ARP. Each host would be assigned a /32 ip address and their default gateway would be their own ip address. There was a registry setting available on Windows NT server that would cause the DHCP server to provide hosts with DHCP address and router assignments that met these requirements.

Ports that had routers connected to them were designated as router ports and needed to have proxy arp enabled.

Whenever a host wanted to talk to any IP address which was not already in it's arp cache it would send an arp request. The management system of the switch, which in this case was software running on a server outside the switch, would look up in it's tables if it knew the IP address from another switch port. If so and all policies allowed the host sending the request to speak to the port the destination was associated with the manager would respond to the arp request with the mac of the destination. If the requested IP address didn't exist in it's tables the request would be flooded out all router ports.

sandos• 7 years ago

"Windows NT is a family of operating systems produced by Microsoft, the first version of which was released on July 27, 1993"

NT did not exist in the early 80s, maybe just a typo?

lolc4• 7 years ago

I remember sitting in the sun ten years ago, wondering about all the layers and how there's no need for a MAC address when you have an IP6 address. Then I wondered why it's not like that. So that was a depressing read in the sense that there is no a priori reason it shouldn't be that way. Just hacks after hacks as usual.

tzakrajs• 7 years ago

IPv6 (L3) still uses MAC addresses because it relies on frames (L2) to encapsulate the packet. For example, the multicast address ff02::1 is really just 33:33:00:00:00:01. It allows for the coexistence of multiple network layer (L3) protocols.

lolc4• 7 years ago

Such are the sad details of how IP6 over Ethernet is implemented today.

jandrese6• 7 years ago

It's like that so you can send your IPv6 packets over 20 year old switches and have them still work. Switches don't care about the IP layer, all they look at is the MAC layer.

lolc4• 7 years ago

Wouldn't it be nice if modern switches could properly route packets without them being framed in legacy protocols? This could be negotiated when you connect to them. But because it's only marginal gain and needs dual-stack switches we just keep the hacks.

Maybe one day.

lisper• 7 years ago

My first startup, back in the early 90s, was called FlowNet [1]. It was an incredibly cool design invented by my co-founder, Mike Ciholas. It was fast, cost-effective (10x price-performance improvement over the contemporary competition), self-configuring, scalable, and included advanced features like quality-of-service guarantees.

Needless to say, it did not succeed. But the world would have been a better place if it had.

[1] https://www.linuxjournal.com/article/3293

sneakernets• 7 years ago

"Bridging is still, mostly, hardware based and defined by IEEE, the people who control the Ethernet standards. Routing is still, mostly, software based and defined by the IETF, the people who control the Internet standards. Both groups still try to pretend the other group doesn't exist. "

I laughed so hard it hurts. Stories like this make me realize that the eggheads and boffins can be just as dumb and stubborn as I am.

walshemj4• 7 years ago

you know the old old joke that the 8th layer of the OSI stack is "politics"

mcguire7• 7 years ago

See also https://archive.org/details/elementsofnetwor00padl The Elements of Networking Style.

Dunedan• 7 years ago

As this post talked a bit about the history of computer networks I have to jump in and highly recommend "Where Wizards Stay Up Late: The Origins Of The Internet" (https://www.amazon.com/Where-Wizards-Stay-Up-Late-ebook/dp/B...) to everybody curious about how that thing called internet came to be. It's such a great book about an era not so long ago, but often already forgotten.

RyanShook2• 7 years ago

Reading it now and highly enjoying it! I’ve recently shared some of the early specs from BBN and RFCs here on HN if anyone is interested in early internet as well.

BlueTemplar• 7 years ago

So, why haven't the relevant people started working on IPv7/NewProtocol, like... 10 years ago, when it started to become clear that mobile Internet was going to become big and that IPv4/6 and TCP/UDP coudln't work well with it?

kelnos3• 7 years ago

Probably because they noted the terrible time they were having getting people to migrate from IPv4 to IPv6, and had no desire to repeat it.

dcbadacd• 7 years ago

It'll only take another 50 years :')

fanf2• 7 years ago

They did! https://www.schneier.com/blog/archives/2010/06/darpa_researc...

The problem is that the economic situation makes it very difficult to replace the Internet. Wholesale protocol replacements only work if they are backwards compatible and incrementally deployable and they provide new capabilities even when there is partial deployment.

basch2• 7 years ago

With most of the population buying a new phone every two years, 5G, and the carriers being able to be a compatibility layer, it seems like it wouldnt be hard at all to do something like QUiC/IP7 and have massive adoption within a couple years. Apple, Microsoft, Samsung, Google, ATT, and Verizon could force it on their own.

icedchai2• 7 years ago

These things take a very, very long time. Consider that IPv6 has been a thing since the late 90's. It is now older than the IPv4 internet was when it started taking off around 1995. IPv6 is it. I very much doubt we will see an IPv7 in our life times, if ever.

walshemj4• 7 years ago

I think it was obvious in the mid to late 90's that ipv6 was flawed once the internet for civilians really started to take off, not having a seamless migration path was not on.

Dagger211• 7 years ago

A seamless migration path (in the sense that you seem to be wanting it) was impossible. v4's design doesn't allow for it.

bdamm2• 7 years ago

From my experience, it's because some of the people that would need to be doing that have their heads in the sand about e.g. the necessity of middleboxes and application-layer proxies. Network-layer folks still seem to think that the Internet must not have application-layer proxies, and some actively resist good efforts to expand the application-layer protocols to better deal with the reality of application-layer middleboxes, such as those widely used in IoT applications. And some try to eliminate good mechanisms that otherwise would work, such as CONNECT over TLS.

h2odragon3• 7 years ago

"Layers are only ever added."

Vernor Vinge had "Software Archeology" as a thing, it's already too real.

We've already given up the pretense of privacy, let's use a geophysical coordinate for the basis of our addressing and routing system. All the problems of mesh networking and mobilty are, if not solved, at least exposed as what they are, and not hidden behind "and then we tunnel through 4 layers of protocol to emulate the lack of 7".

cesarb8• 7 years ago

let's use a geophysical coordinate for the basis of our addressing and routing system

Networking does not follow geography. My phone is right next to my laptop; but if I disable my phone's wifi, the network path between them takes a detour through the next city.

h2odragon3• 7 years ago

then the indirection that ties your mobile device to its nearest fixed forwarding point is an exposed layer. This happens now, you just have several layers of emulating old circumstances in between, as this article details.

kortilla5• 7 years ago

Hopefully nobody ever needs a cell phone that moves.

kazinator9• 7 years ago

There was no such world.

IP could be easily widened just by taking IP addresses to 64 bits, allocating some new protocol numbers for that, and keeping everything exactly the same. In applications, the same old quad dot notation would work textually: 0.0.0.0 to 65535.65535.65535.65535, the latter being the broadcast address and so on.

The IPv4 space could be embedded such that 1.2.3.4 is both an IPv4 address made of octets, and an "IPv5" made of four hexadecades. Gateways and protocol stacks could convert the packet formats on the fly: a wide packet with addresses whose four values are below 256 could be narrowed, and then received received by IPv4. An IPv4 packet could be widened to "IPv5".

No stupid "neighbor" protocol; just good old ARP, widended to 64 bit IP addresses.

Machines now have native integers that can hold a 64 bit IP address; great for all the masking operations in routing logic and whatnot.

dboreham3• 7 years ago

Like TUBA.

phs2501• 7 years ago

TUBA was TCP, UDP, and the Internet protocols on top of the OSI network stack (CLNP). It's about as from from IPv4 as you could imagine.

https://tools.ietf.org/html/rfc1347

cesarb8• 7 years ago

"Just widen the addresses" ideas like that are easy to come up with (though they usually keep the IPv4 address as either the prefix or the suffix of the "new" address), but the elephant in the room is always the same: how would a legacy host which only understands classical IPv4 (with 32-bit addresses) talk to a host which only has "new" (wider than 32-bit) addresses?

kazinator9• 7 years ago

how would a legacy host which only understands classical IPv4 (with 32-bit addresses) talk to a host which only has "new" (wider than 32-bit) addresses?

Hosts with 64 bit addresses would have to support 32 bit addresses also, just like is the case with IPv6 hosts that have to have IPv4 stacks.

Under 64 bit addresses, it's conceivable that in fact there would not necessarily have to be an entire IPv4 stack; just protocol conversion to widen and unwiden the data format.

The stack would have to know that certain connections have IPv4 peers, and so it would parse IPv4 datagrams coming from those hosts, and likewise send them IPv4 datagrams.

It could be designed such that if the source and destination addresses (A.B.C.D) of a connection are such that A <= 255 && B <= 255 && C <= 255 && D <= 255, then the hosts may optionally use the smaller IPv4 packet format.

lmm5• 7 years ago

The IPv4 space could be embedded such that 1.2.3.4 is both an IPv4 address made of octets, and an "IPv5" made of four hexadecades. Gateways and protocol stacks could convert the packet formats on the fly: a wide packet with addresses whose four values are below 256 could be narrowed, and then received received by IPv4. An IPv4 packet could be widened to "IPv5".

What problem do you imagine this would solve?

IPv4 and IPv6 need to be completely independent, because if an IPv4 router were ever to route an IPv6 packet it would send it to the wrong place, likely into a loop. Worse, such misrouting would be unpredictable as BGP tables shifted, links failed over, etc; you might have packets go around a loop several times and then eventually reach their final destination, you might have packets going fine in one direction but misrouted in the other, etc.. It would be a nightmare to debug.

Given that IPv6 packets can never be routed by IPv4 routers, what value is gained by making it easy to embed IPv4 in IPv6? Hosts where both ends have IPv4 addresses ("narrow" in your terminology) are just going to talk IPv4 anyway. And it's not like 4over6 is particularly complex or delaying deployment.

stingraycharles3• 7 years ago

I guess you can have clients that purely talk IPv6 talk with destinations (edge locations) that only talk IPv4, without requiring the whole end-to-end connection and intermediate routers to talk IPv4? You'll just have a router at the end which translates this IPv4-in-IPv6 packet into a pure IPv4 packet and everything will work.

wmf2• 7 years ago

Here's a detailed explanation of why that isn't useful: https://hackerfall.com/story/ipv6-non-alternatives-djbs-arti... and the HN discussion: https://news.ycombinator.com/item?id=10854570

XorNot• 7 years ago

No it can not be. Routing hardware is hardware. 32 bits is physically etched into the ASIC chips which do it.

If all it took was a software upgrade then IPv6 would be done by now.

The IPv4 space is already embedded in the IPv6 space as part of the spec.

You can't negotiate a middle ground with hardware.

kazinator9• 7 years ago

If all it took was a software upgrade then IPv6 would be done by now.

Even if the routers were upgradable, there is the problem that IPv4 applications contain hard-coded uses of types like struct sockaddr_in.

In some cases, entire programs are replicated just for IPv6: e.g. ping6, telnet6, ...

These things don't write themselves.

paulcarroty• 7 years ago

Practice says good design isn't effective against greedy ISPs.

mcguire7• 7 years ago

"To do that pointless intermediate step [converting a router's IP address to its MAC address], you need to add ARP (address resolution protocol), a simple non-IP protocol whose job it is to convert IP addresses to ethernet addresses."

Well, technically, ARP is how every IP address is converted to a MAC address. If the IP address is not local (determined by the address, the host's own address, and the subnet mask), the host ARPs for the router interface; if it is local, it ARPs for the destination address.

"They're nowadays almost inseparable. It's hard to imagine a network interface (except ppp0) without a 48-bit MAC address, and it's hard to imagine that network interface working without an IP address."

Well, technically, it's not: CAN (11-bit "address"/priority/identifier thingy), ZigBee (16-bit? 64-bit? I dunno.), Bluetooth, etc.

In case you're wondering, there is a long tradition of these kinds of rants. Everything would be perfect if the IETF had done X instead of Y, if FOO had happened instead of BAR, if Steve Deering had tripped over his own wineglass model and received a traumatic brain injury (or not tripped over the wineglass and not received the brain injury; I'm not clear on that).

There's even people who argue we should have gone with the OSI protocols from the start, although they are literally evil cultists who prefer the worst possible option. (Wait, why does that sound appealing?)

walshemj4• 7 years ago

The evil OSI overlord sits on his Thone and smiles "very good sub :-)"

I used to work in OSI and at one point had Level 6 (root) on the UK's main ADMD oh and Level 7 (beyond root) on the billing systems.

pdkl958• 7 years ago

there is a long tradition of these kinds of rants. Everything would be perfect if the IETF had done X instead of Y

https://tools.ietf.org/html/rfc1925

see (10), (11)

[and (11a) always applies]

mcguire7• 7 years ago

"(7a) (corollary). Good, Fast, Cheap: Pick any two (you can't have all three)."

Hell, you're exceptionally lucky to have one.

zamadatix5• 7 years ago

"Bridging is still, mostly, hardware based and defined by IEEE, the people who control the ethernet standards. Routing is still, mostly, software based and defined by the IETF"

I disagree, the dataplane of each is usually hardware and the control plane of each is usually software. I think the dismissal of things like broadcast learning, ARP, and even DHCP to an extent, leads to the confusion.

You know these "IP" headers are nonsense because the DHCP server has to open a raw socket and fill them in by hand; the kernel IP layer can't do it.

What the kernel IP layer exposes has little to do with whether something is a "real" IP packet. Under the guise of security anything that wasn't UDP or TCP bound to an OS configured IP interface isn't part of kernel IP sockets anymore. This historical conflation of IP = place to bind layer 4 socket is one reason why QUIC is UDP based.

mcguire7• 7 years ago

Slide 14 of the BBR deck: "PROBE_RTT drains queue to refresh min_RTT: Minimize packets in flight for max(0.2s, 1 round trip) after actively sending for 10s. Key for fairness among multiple BBR flows."

Suddenly, I'm scared.

beagle35• 7 years ago

2010 saw the introduction of CurveCP[0], and 2011 its first implementation. It solves a most of what IPv6 does (and then some). The thing it does give up is complete symmetry - there IS a difference between client and server.

But we've effectively already given that up with NATs (and CGNATs), with essentially nothing lost[1], so I'd much rather have given that up willfully and get all the great things CurveCP has to offer, rather than the mess that is IPv6

An evolved version called MinimalT (published 2013[2], implemented then and e.g. in 2014[3]) goes much farther, with DNS integration, some DoS protection, and a few other nice properties while being faster than TCP/IP, and still being IPv4.

Instead we have QUIC and IPv6.

[0] http://www.curvecp.org/addressing.html

[1] And that's unfortunate - but peer to peer is essentially irrelevant now, when every communication service people actually like uses a server these days.

[2] http://cr.yp.to/tcpip/minimalt-20130522.pdf

[3] https://github.com/nimbus-network/minimalt

simias2• 7 years ago

but peer to peer is essentially irrelevant now, when every communication service people actually like uses a server these days.

That's true but it's sort of a self-fulfilling prophecy the way you put it. Maybe what we lost is actually the potential to develop alternative, peer-to-peer, decentralized systems.

Take something like Dropbox, it's been very successful solving a very practical problem people are having, sharing files over the internet. Widespread NATing and publicly unreachable computers have a big role in that. Of course that's not to say that with IPv6 Dropbox would be irrelevant, there's also the problem of having the files always available, not having to worry about hardware failures and security issues. Still, I'm sure that in many cases if people could easily share files directly from their device without middle-man they would. It's just a pain to get to work reliably without going through "the cloud".

Of course nowadays that's almost an absurd concept. Everything gets uploaded on somebody's server and the decentralized web is long behind us.

beagle35• 7 years ago

Maybe what we lost is actually the potential to develop alternative, peer-to-peer, decentralized systems.

For this to work properly one needs (a) mostly reliable addressing and routing, and (b) mostly online systems.

IPv4 and IPv6 were indeed developed for both (a) and (b). But both started to disappear when laptops overtook desktops, which would be over a decade now, and became completely irrelevant when mobiles overtook computers (laptops + desktops).

It's the world that has changed; it cannot come back in IPv4 due to address exhaustion, and won't come back in IPv6 because (a) requires stable addresses -- meaning VPNs for everyone -- and (b) requires the physically impossible "access to data when phone is out of battery and/or in a Farady cage".

The server-in-the-middle is a must for reliability; People who seriously use Syncthing or btsync instead of Dropbox have to set up at least one "constantly on" server because of both (a) and (b) above.

The last remaining use case for peer-to-peer is, I think, live (chat/voice/video) one on one conversations - and while it's an interesting and important use case, it can (and has) been solved with stable servers-in-the-middle, and I don't believe it is significant enough (or was, or will be) to stop progress; MinimalT makes much more sense than IPv6 or QUIC as a way forward, but we're unlikely to ever have that at scale.

__jal• 7 years ago

P2P will stay irrelevant insofar that we don't fix networking to make it easy again. And we really want it to be, for values of "we" that != carriers.

NAT and related IPv4 hacks hand a great deal of power to people who want to meter you by the byte, inspect your content for compliance with their business model, and generally define how you are "allowed" to use the internet.

It doesn't have to be that way.

beagle35• 7 years ago

for values of "we" that != carriers.

It's everyone except technical end users. Google - not a carrier unless you use FI/Fiber - wants to intermediate everything. So do Facebook, Microsoft, Slack, Discord and everyone else - you can't be monetized if they don't control the flow. The government wants that too, by the way - it makes stuff like Prism realistic and so much easier.

NAT and related IPv4 hacks hand a great deal of power to people who want to meter you by the byte, inspect your content for compliance with their business model, and generally define how you are "allowed" to use the internet.

They do no such thing; They already have all that power by virtue of your pipe going through them - even before the CGNAT days, my ISP would require extra payment to let you listen on e.g. TCP ports 25 and 80. Every packet you send or receive goes through your carrier, whether or not they fudge the IP address on it to a different space.

It doesn't have to be that way.

And yet it can't be any other way because 99.9% of users are indeed better off if their incoming data is filtered. That doesn't have to be that way either - we just have to have secure software so being on the internet without a firewall is not a risk.

The internet is becoming a health-like thing: You need enough people around you to be vaccinated so that you don't suffer viruses/ddos attacks yourself. But most of the population is worse than antivaxers - they don't even know that they can be (or have been) infected, and there's no clinic to just go to even if they did.

... so it effectively does have to be that way, unfortunately.

runjake2• 7 years ago

I was an early adopter implementing and administering IPv6 in a large enterprise, and I still am administering it. It was a shit show for years but in recent years client support has stabilized.

However, I've recently, I've come to my own conclusion that IPv6 is largely doomed and that it will be usurped by IPv4 NATs/CGNATs and >L3 improvements like QUIC, DTLS, etc. Why?

IPv6 is complex and unfamiliar and has a big learning curve. People aren't going to "put up with it". They're going to adapt what they have (skills/tools/etc) and they're doing a good job of it.

I always get asked by people about IPv6 and how they should get started and my present advice is to "hold off, for now". I'm not even sad about that. The world is evolving and when framed properly, it doesn't seem that bad.

betterunix2• 7 years ago

I find IPv6 to be simpler than IPv4 -- once I stopped trying to reason about things in IPv4 terms. The only real complexity I have encountered is in the various efforts to maintain compatibility with IPv4.

One way or another IPv4 will go away. The limits of scale were hit years ago and the workarounds break applications (NAT is basically a violation of the end-to-end principle and the results are predictable), and merging IPv4 private networks is a nightmare.

kortilla5• 7 years ago

I don’t see it. No users care that NAT breaks the end to end principle. That’s only something users care about that want to accept connections, which is <1%.

TCP and UDP have been running over NAT for so long that they work completely fine. People who make the mistake of assuming asymmetric ports or putting IPs in the payload fail so early that they quickly learn.

There is so little actual pressure to implement ipv6 that it’s starting to look pretty doomed.

xvilka2• 7 years ago

IPv6 already succeeded. So far the many corporations already work very hard to perform even internal networks transition. And with new hardware upgrades IPv6 comes for free almost. For example, China recently did a huge leap, where many networks switched at once, along with mobile and web applications. And more is planned in the near future [1].

[1] https://blog.apnic.net/2019/06/06/100-by-2025-china-getting-...

wmf2• 7 years ago

IPv6 is largely doomed and that it will be usurped by IPv4 NATs/CGNATs...

This argument could have worked ten years ago but now it has been falsified. Cellular carriers have already deployed IPv6 and there's no motivation for them to switch back to IPv4, especially given the high cost of CGN.

simias2• 7 years ago

I don't find IPv6 complicated, if anything it's a lot easier to grasp than IPv4 and it basically comes with batteries included.

The difficulty in my experience stems from one thing and one thing only: you can almost never go full IPv6. You always have to dual stack IPv4/IPv6, and of course IPv4 + IPv6 is always strictly more complicated than just IPv4.

I've had the opportunity to develop a solution using an IPv6-only environment and it was a pleasure to work with. No need to worry about the size of your subnets or clashing with 3rd party tools using the same address space etc...

Wouldn't it be better if it had just been IPv4 with more address bits?

I often hear that but I genuinely don't get it. This change would effectively give you all the problems with IPv6 (i.e. you have to make sure all your hardware and software equipment can deal with the new, backward-incompatible format) without all the niceties that IPv6 provides. It's genuinely the worst of both worlds. NAT is probably the best compromise you can get, using the port number to sort-of extend the address information to identify several computers with the same IP, but it's obviously an ugly hack with many limitations.

zAy0LfpBZLC8mAC5• 7 years ago

The difficulty in my experience stems from one thing and one thing only: you can almost never go full IPv6. You always have to dual stack IPv4/IPv6, and of course IPv4 + IPv6 is always strictly more complicated than just IPv4.

But it isn't? I mean, yes, every machine that requires both v4 and v6 is more complicated than just v4, sure. But potentially, you can get away with not having everything double stacked. You can run all your application and infrastructure servers on IPv6 only, and only have a load balancer speak IPv4, for example--that way, you get most of the benefit of IPv6 with only very little extra effort required for double stacking.

rstuart4133• 7 years ago

But it isn't? I mean, yes, every machine that requires both v4 and v6 is more complicated than just v4, sure.

You don't need to do that. I've set up IPv6 only networks at conferences. If throw in a IPv6->IPv4 NAT (eg, tayga) the only machine that requires a dual stack is the router. We didn't have a single complaint about connectivity issues from over 500 delegates. Modern clients (phones, tablets, Mac's and so on) just slide seamlessly into an IPv6 environment without the user even being aware they are using IPv6.

kortilla5• 7 years ago

IPv6 pretty much requires DNS. There are tons of dead simple networks out there that administrators just memorize IP addresses on trivially.

PopeDotNinja4• 7 years ago

0.0.0.0

1.1.1.1

8.8.8.8

192.168.0.1

^^^ burned into my brain

2001:0db8:0000:0000:0000:ff00:0042:8329

^^^ say what now?!

pdkl958• 7 years ago

http://www.hungry.com/~jamie/hacker-test.html

From the Hacker Test:

    0361 Have you memorized the HOSTS.TXT table?
    0362 ... Are you up to date?

skrause• 7 years ago

IPv6 doesn't prevent you from using memorizable addresses. You can configure your hosts with the ULA addresses fd::1, fd::2, fd::3 etc.

fulafel4• 7 years ago

It's of course better to use DNS, but if you like plain IP addresses you can still memorize them in v6 pretty easily: just memorize your prefix, which in theory is ~ 50-bit but is usually rather regular-shaped and is no harder than a phone numer, and you can use easy to remember numbering g in the rest of the /56 or /48.

dboreham3• 7 years ago

Much history rewriting here. The author is wrong about mobile use cases not being thought about when IPng was being worked on. I remember hearing talks about how to interoperate across wireless lans and WANs, seamlessly, at the same IETF meeting events. Wireless LANs existed back then and so did Wireless WAN services. They were just slower and more expensive than today's and of course not widely used. The first wireless WAN I used with TCP/IP on a laptop was in 1994 FWIW. 8kbits/s.

mrfusion• 7 years ago

I’m embarrassingly out of the loop. What happened with ipv6? Weren’t we supposed to run out of IP addresses the years ago? Will ipv6 still happen?

toast0• 7 years ago

We've sort of run out of IPv4 addresses; you can't get new ones direct from ARIN in a timely fashion anymore. You can still get IPs from most of the other regional authorities though. You can also get IPv4 addresses from other people who aren't using them; there's still a lot of addresses that are assigned, but not BGP advertised, so there's some slack.

However, IPv6 is happening. Primarily in two places:

a) mobile ISPs; T-Mobile is big on IPv6, so is Jio in India. This tends to be related to new investments or wealthy countries. Existing networks work enough, so where there's not a lot of money, adding or upgrading CGNAT is small incremental cost, and enabling IPv6 is a project. OTOH, a big new network like Jio has to pick from building out IPv6 with a small amount of IPv4 or buying a bunch of IPv4 to build out a lot of IPv4 -- it makes sense to push hard on IPv6.

b) big content sites. IPv6 networks currently don't have the same kind of junky middleboxes that IPv4 has --- serving as many customers as possible without junk in the way is a big deal.

Where you don't see a lot of movement is residential ISPs in wealthy countries. They've generally got enough IPv4 for their customers, so they don't care that much about IPv6. However, Comcast has done a good job of rolling out, and AT&T and CenturyLink do have something.

mindcrime3• 7 years ago

Will ipv6 still happen?

Yes.

https://www.google.com/intl/en/ipv6/statistics.html

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

I think we're clearly past the point of no return. How long it will take to achieve near 100% adoption I have no idea... but with ipv6 already at over 33% adoption in large countries like India and the US... yeah, it's gonna happen.

All we really need is for Russia and China to get moving on adoption...

xvilka2• 7 years ago

China already did. For obvious reasons it just not shown on the Google statistics page.

Ericson2314• 7 years ago

During networking class it sort of dawned on me that the internet people and LAN people were different and ignoring each other, but they never actually said this. Doing so would have made things a lot clearer.

systemBuilder3• 7 years ago

Thing about IPv6 is that it's designers didn't understand the internet. They didn't understand that in a client-server architecture only the servers need full-scale IP addresses because of the 64K ports. They had apparently never heard of the end to end argument. They saw 16-bit computers being wiped out by 32-bit and figured bigger = always better. xerox predicted 2^48 was all that we would ever need and as a Xerox protocol designer myself, I think it's still true. The IPv6 designers thought bigger = better = more router sales ( hey I'm looking at you, Steve Deering! )

I was asked by Qualcomm to determine when IPv6 would completely replace IPv4. This was in 2003 and they expected 2006 or 2007 at the latest! But, Qualcomm never hired internet visionaries ... When I told them "never" I almost got fired !!

When I left Google search 6 months ago, 15 years later, IPv6 was less than 0.1% of the crawled websites.

It's horribly wasteful for sensor networks and IOT.

It's only useful if you have more than 2^24 addresses because IANA hasn't added another class A private network range like 10.x.y.z (hint: there is exactly ONE company that needs a /7 private subnet). 3GPP uses it to give a unique ID to every phone but that's because they think like Qualcomm.

It will never replace IPv4.

IPv4 is like the roman chariot axle width. It was the right answer, and all roads today follow Rome's standard.

kalleboo• 7 years ago

It's horribly wasteful for sensor networks and IOT.

What's horribly wasteful for IoT isn't IPv6, it's streaming my baby monitor video to some server in China because my home internet is behind CGNAT. Of course, streaming it to some server is more profitable since now you can charge money for access/storage, so there's no incentive to optimize for efficiency.

systemBuilder3• 7 years ago

And an impractical security mess to tunnel into your home network. There are a hundred arguments against IPv6 and 3 or 4 - at most - in favor of it.

RyanShook2• 7 years ago

I think the heart of all networking issues is that it’s hard to imagine a system more complex than the one you have today. IPv6’s main weakness is the lack of mobile IP and even as we work to solve that problem we are creating new problems that will only be clear in another decade or two.

RandomTisk• 7 years ago

I'd like to propose IPv7. Exactly like IPv4, but 48 bit addresses and must accept IPv4 traffic and treat addresses as beginning with 0's for first two octets. You're welcome.

asdfasgasdgasdg• 7 years ago

That's more or less what the article says in its first section. Then it goes on to tell why that didn't happen. In short, it isn't that simple.

AFascistWorld• 7 years ago

IPv6 opens up the possibility of comprehensive government surveillance, govs now can attribute every device fixed set of IPs, which link to your ID.

astrange• 7 years ago

https://tools.ietf.org/html/rfc4941

Dagger211• 7 years ago

That's not how v6 works. v6 addresses aren't linked to devices or IDs; typically your devices will generate themselves a random address, and generate a new one every day or so.

On the other hand, the extreme shortage of v4 addresses combined with pervasive use of NAT basically requires services to become more centralized, which makes surveillance easier. It's true there are other incentives for companies to centralize things, but surely removing the requirement to do so will make the situation better, rather than worse?

stingraycharles3• 7 years ago

Ok so here's a question for the HN community: I have IPv6 from my ISP, and as an experiment, I want to primarily use IPv6 to connect to my different home servers.

I use automatic address selection, so no DHCP. So this means that when a server reboots, chances are their address changes.

Other than setting up a custom DNS server and $somehow ensuring that each server registers itself at this DNS server at boot, are there any elegant solutions to this?

starfox64_2• 7 years ago

Is there anything preventing you from assigning static IPv6 addresses on your machines?

stingraycharles3• 7 years ago

Not necessarily. How would I go about making these IPs easily discoverable by other hosts? DNS again?

magicalhippo2• 7 years ago

In my case, I get a new prefix every time my router reboots or otherwise loses connection.

Then there's the case of firewall rules. My router gets a new prefix which causes my server to get a new IP, how do I get my firewall (pfSense) to update my firewall pass rules to point to the new IP?

I must admit I haven't tried really hard, so there might be some obvious ways I'm missing.

cesarb8• 7 years ago

I use automatic address selection, so no DHCP.

This means you're using SLAAC instead of DHCPv6, right? In that case, your servers should have a fixed IPv6 address derived from their MAC address. Even if they also have privacy addresses (and prefer to use them for outbound connections), they should still have the non-privacy address which you could use for inbound connections.

Or is it the problem that, when your router reboots, the IPv6 prefix changes? That is a harder problem (and would be the same in IPv4).

zamadatix5• 7 years ago

If you want outside-of-your-home things to reach dynamically assigned public IP space then DDNS is your only option (there are public servers you can use if you're willing to make that trade as well).

If you just want your local stuff to have public IPv6 outbound and static IPv6 inside your home then you can just multinet. That is add a static private IPv6 to the same interface you get your public IPv6 via SLAAC.

stjohnswarts• 7 years ago

I'd be willing to bet that QUIC will not replace TCP in our lifetimes.

tinus_hn• 7 years ago

You definitely couldn't write something like traceroute for bridging, because none of the tools you need to make it work - such as the ability for an intermediate bridge to even have an address - exist in plain ethernet.

Doesn’t Windows 10 come with a network mapping tool that does just that (when not on a domain)?

The world in which IPv6 was a good design (2017)

Related Stories