Hacker News new | past | comments | ask | show | jobs | submit login
IPv6 non-alternatives: DJB's article, 13 years later (sesse.net)
78 points by teddyh on Jan 7, 2016 | hide | past | web | favorite | 71 comments



> you still need to upgrade all software on the planet and all routers on the planet.

No, you don't. The biggest benefit to using IPv4 as the routing-infrastructure and extra bits (maybe an IP option) to describe the host is that most of the Internet (routers, etc) don't need to get upgraded, only hosts. Routers don't normally mess with the packets so only the first/last wifi/switch actually need upgrading. This is a small number of devices (certainly much smaller than all!).

There could be a few routers that lose the option, and one option is to just fix those routers (still a much smaller number than all routers), but another option is to rely on connection tracking only when the service is behind such a router. The ubiquity of UPNP suggests this path would have worked just fine.

NAT gives us a 32-bit port number pair, which requires memory, makes denial-of-service attacks easier, and is complicated. An IP option means that the hosts track the connection themselves.

Another option would be to move port numbers into DNS. This might've been simple (48-bit addresses are pretty big), and only affected new services. We upgraded all of the webservers and web browsers faster than IPv6 deployed, so this probably would have just been a simple matter of mothballing IANA.

However, I worry we're not actually arguing about what we think someone a decade (or two) ago thought could be the direction to talk about solving a problem.

IPv6 is the biggest deploy attempted on the Internet, and it's been miserable. We should be talking about its failings, its mistakes, and how we could do better knowing what we learned, not patting ourselves on the back for doing the best we could've done knowing what we knew. IPv6 might be inevitable at this point, but that doesn't mean it was right.


> No, you don't. The biggest benefit to using IPv4 as the routing-infrastructure and extra bits (maybe an IP option) to describe the host is that most of the Internet (routers, etc) don't need to get upgraded, only hosts. Routers don't normally mess with the packets so only the first/last wifi/switch actually need upgrading. This is a small number of devices (certainly much smaller than all!).

That's the "BangIP" option discussed in the second half of the article and has all the problems discussed there (e.g. it makes multihoming more-or-less impossible)


Multihoming (PI) isn't impossible but it certainly requires more work. I'm not yet convinced to throw the baby out with the bath water.

Multihoming is also not the normal case: for a long time ARIN refused to make IPv6 PI allocations to existing IPv4 PI.


Now consider that IPv4 + NAT + NAT traversal is essentially a crap version of IPv4+ that uses UDP port numbers to achieve an unstable, unreliable 16 bit extension to the IPv4 address space. Of course because these port numbers are ephemeral and unreliable all P2P code must be full of complex logic to constantly check for dead paths, remap ports, deal with different kinds of NAT, etc.

I happen to think DJB was right. If we could rewind history to, say, 1998 and implement an address space extension to IPv4 that was less of a severe change than IPv6 that probably would have been the better way forward.

Personally I would have implemented IP64, using the existing IPv4 space as the most significant 32 bits of a 64 bit address space. The advantage here is that an IP remains something that can fit in a typical 64-bit CPU register and remains short enough that it's type-able and at least a little bit memorable. 64 bits would be plenty to address every device on Earth. There are some nice things about having a larger address space but most of them are minor compared with the address shortage problem. IPv6 gives you enough space for reliable stateless auto configuration, but in practice that's going out of favor since it turns out you need DHCP (DHCPv6) for other reasons besides just assigning addresses.


128-bit wasn't an arbitrary choice. It was done to ensure the routing tables would remain small and sane. It's why we use a 64-bit prefix, and a 64-bit address, for IPv6 network assignments as the default.

Note those values and think of the significance.


Exclude the infrastructure that need to be upgraded to support larger routing tables, larger AS numbers or other extensions. Exclude all the infrastructure that needs to be upgraded because it supports/does DPI or packet filtering. Exclude the new infrastructure that's newly bought and insatlled in order to cope with the network growth that caused the need for v6 in the first place. Exclude the infrastructure that needs to be bought in order to support new media types (WLAN, VDSL, denser/faster fiber, whatever).

Once all that is excluded, there isn't much infrastructure left.


You're describing IPv6.

I'm describing IPv4 that uses the current dotted-quad as the network address and adds a new host address: The routing tables don't get bigger, AS numbers are 32 bit anyway and unlikely to get bigger, DPI is actually easier than with NAT since there's no ambiguity, there's no new media types, and upgrades can be done piecemeal.

Seriously, it's better than IPv6 in every way but one: by being cheaper to deploy companies and consultants can't charge extra for IPv6 readiness over a few decades.


I'm describing a growing network.

WLAN support doesn't require new hardware because of IPv6, it requires new hardware because old 3com 3c509 cards didn't support WLAN. Increasing number of customers require increasing number of customer-facing routers and router ports because each customer requires a connection, it's nothing specific to v6. And so on.


> The routing tables don't get bigger

They do, because of route fragmentation, not because of address size.

> AS numbers are 32 bit anyway and unlikely to get bigger

No, AS numbers were 16 bit until well after the introduction of IPv6.


I had a 32 bit AS number almost a decade ago. I'm still waiting for an IPv6 address.


Well, and I've had native (non-tunneled) IPv6 for more than a decade on my DSL at home ... what's your point?

Routers have been able to handle IPv6 since quite a bit before the introduction of 32 bit AS numbers, so, if you wanted to be able to speak to 32 bit BGP peers, you had to upgrade to a router that can do IPv6 as an unavoidable side effect.


And hardware had problems with 32 bit ASNs even up to a year ago. Inline flow generation was broken on Juniper and Cisco stuff for a while.


Arista just added 4 byte ASN support to BGP in EOS, in the last release in December. Just FYI.


Interesting times we live in. IPv4+ (better name) and Enhanced IP (possibly better protocol) both use IP options. I won't recap what IPv4+ does but here's a recap on the important bits of EnhancedIP. There is a proof of concept implementation available for Linux at www.enhancedip.org. You can download VMs to see how it works. Also, http://www.enhancedip.org/learnmore.html has a quick rundown with just enough detail to get the idea. EnhancedIP uses a 64-bit address that works as two IP addresses concatenated together. Enhanced IP requires NATs and end hosts to be upgraded but not core/edge routers. Enhanced IP is also backwards compatible with IPv4 as much as is possible. There is a draft RFC and a full paper available for Enhanced IP. Because the Internet wouldn't have to wait on a core router upgrade to get started, this might move along more quickly.


> No, you don't. The biggest benefit to using IPv4 as the routing-infrastructure and extra bits (maybe an IP option) to describe the host is that most of the Internet (routers, etc) don't need to get upgraded, only hosts. Routers don't normally mess with the packets so only the first/last wifi/switch actually need upgrading. This is a small number of devices (certainly much smaller than all!).

What does WiFi or a switch even have to do with this?


This is in fact one of the ipv6 transition mechanisms and was supported by Windows, Cisco, Apple Airports etc. (6to4)


Not exactly.

6in4 gives IPv4 hosts IPv6 addresses which means we only have to upgrade all the edges, but we still have to upgrade all of them.

What I propose (effectively) gives IPv6 (though I should call it something else) hosts IPv4 addresses: the exact opposite. You don't have to upgrade anything except the user's web browser (which clearly took less than 20 years).


> 6in4 gives IPv4 hosts IPv6 addresses which means we only have to upgrade all the edges, but we still have to upgrade all of them.

No-one's turning off their IPv4 stacks though. Under your proposal if one or other edge was IPv4-only then they'd use ordinary IPv4, you'd only see any benefit if both edges were IPv4+, right? Which is the same as when using 6to4. (If you really need to avoid dual-stack even on the local network you can use 6to4 and NAT64).

(6to4 is largely a failure but the kind of approach you propose would have the same issues as far as I can see)


A 6in4 address ends in an IPv4 address so it doesn't actually add any IP space: A 6in4 host can't allocate additional IPv6 addresses that are routed over IPv4.

An IPv4+ address reserves 32 bits for the network address, and has (say) a 64 bit host address after it.

This means that IPv4+ hosts can be allocated by anyone with an IPv4 address.


> A 6in4 address ends in an IPv4 address so it doesn't actually add any IP space: A 6in4 host can't allocate additional IPv6 addresses that are routed over IPv4.

Not so - if you have a single public IPv4 address you can turn that into an IPv6 /48 and put up to 16 bits worth of hosts behind it. Given that these are only for edges and not meant to have routing within them that should be plenty (having two different sets of routing logic applying to the same packets would be a recipe for difficult-to-debug disconnections and even-more-difficult-to-debug transient slowness).


Eventually we will start turning off IPv4 stacks, just like the ATM/frame layer 2 technologies have given way to carrier ethernet.


Sure. My point was it's not that important for IPv6 to be able to talk to IPv4 - as long as you need to talk to IPv4 hosts, you can just keep running an IPv4 stack.


I think I still don't get what your suggestion is ... what could a web browser do to alleviate the address shortage in IPv4?


If you want to have larger addresses you need to make changes to anything that assumes addresses are 4 bytes. Whether you make them 6 bytes or 8 bytes is irrelevant.

Most of the internet knows how to route 4 bytes, but if I want to add new nodes, and there are only 8 billion people on the planet, surely between me and my neighbour we can share an IPv4 address -- and in fact we are with NAT, but you can't address a single device that I control -- you can only address the NAT machine, make sense?

That's actually okay though, because the only reason the NAT box can't forward the packet to my home server is because it doesn't know that's what you meant: It only knows about 4 bytes. If we teach it about 16 bytes, then it will have no problems.

The trick is, we overlap the upper 4 bytes with IPv4: This means most of the routing infrastructure (that doesn't need to know the difference between my home server and my router) can remain unchanged. This is (in fact) most of the Internet.

However an application that wants to access my server still needs to be updated.

Web browsers went through a similar problem, but they didn't use nat, they relied on the fact that the hostname could be used to identify the service. In this way, the DNS hostname which map to an IP address can be reused to address a specific web site. This information is stored in HTTP in the Host: header and in HTTPS in the SAN (subject alternative name field). The "router" (in this case usually called a web server or a proxy server) can route to the appropriate resource using this information.

This didn't happen immediately though: For a long time, many web browsers didn't use the Host: header, so before people could rely on the Host header to distinguish services, web browsers needed to be updated.

Not all of them, but enough web servers configured to remind users to upgrade their web browser eventually did the trick, and it didn't take twenty years either.

What I proposed is a general mechanism for doing this: to simply extend the address space at the application level.

We could have done it in the operating system -- say with a socket option, and I think it would still be faster than IPv6.

Does that make sense?


Well, yeah, I think I understand what you propose ... but I don't really see the point of it. I mean, where is even any significant difference to IPv6?

Yeah, you could use the IPv4 routing infrastructure for transport of this new protocol. That's also known as tunneling. You can do that with IPv6. Even with automatic assignment of addresses based on IPv4 addresses you already have, that's called 6to4. And while that was a nice idea for a transition mechanism (and in the form of 6rd still usefully employed by some ISPs), it's not really that useful in the long term, as backbone routers have been IPv6 capable for a long time, simply due to upgrades for higher bandwidths. To take a random example: Peak bandwidth at AMS-IX in 2002 was 12 Gbit/s. Now, it's 4.2 Tbit/s. And they didn't do that by multiplying the number of routers by 350.

Your analogy to HTTP and TLS also doesn't really hold up: Both are protocols that are only implemented at the edge of the network and pretty much only in software that is easy to update, while your suggested extension would have to be implemented from the boundary of the publicly routable IPv4 network outward, which in particular includes hundreds of millions of home routers where even updates to fix security vulnerabilities tend to be difficult to come by.

Also, it's not actually true that the v4 routing infrastructure wouldn't need to know the difference between your server and your router. What if you send a packet to an address that has no route? The router that determines that there is no route sends an ICMP network unreachable to the source address of your packet. How would your translation gateway know which inside address to forward it to? Or how about a fragmentation needed message? Should we break PMTUD for good?


> I don't really see the point of it. I mean, where is even any significant difference to IPv6?

IPv4+ solves the same problems that IPv6 does, is much simpler than IPv6, is cheaper than IPv6, and could have been deployed in less time than IPv6.

If we're going to learn from IPv6, then that means studying things like IPv4+.

Note I'm not suggesting we stop IPv6 efforts: I used to say that, but that's only because I think we'll have a 50% solution in another ten years, and IPv4+ could take up to ten years if we had consensus.

> while your suggested extension would have to be implemented from the boundary of the publicly routable IPv4 network outward, which in particular includes hundreds of millions of home routers where even updates to fix security vulnerabilities tend to be difficult to come by.

If you run a service on IPv4+, your router needs to support IPv4+, and your users need to support IPv4+. That's it.

This is very similar to the challenges that upgrading HTTP and HTTPS do had.

Note a user with an IPv4+ address can connect to non-IPv4+-capable systems since he also has NAT.

> addresses based on IPv4 addresses you already have, that's called 6to4

6to4 is a lot more complicated than IPv4+. It was harder to deploy, and building on IPv6 instead of IPv4 was probably a mistake.

If we don't consider the complexity of the implementation, 6to4 still took much longer to be suggested than IPv4+ (or similar) was.

> What if you send a packet to an address that has no route? The router that determines that there is no route sends an ICMP network unreachable to the source address of your packet.

NAT already has this problem. Broadcasting ICMP is an acceptable solution -- remember that IPv4+ for a client is an alternative to NAT.


> If you run a service on IPv4+, your router needs to support IPv4+, and your users need to support IPv4+. That's it.

What does "your users need to support IPv4+" mean? What does it take to make a "user" support IPv4+?

> Note a user with an IPv4+ address can connect to non-IPv4+-capable systems since he also has NAT.

Yeah, the same as with IPv6/v4 dual stack.

> NAT already has this problem. Broadcasting ICMP is an acceptable solution -- remember that IPv4+ for a client is an alternative to NAT.

No, it doesn't, no, it's not. ICMP error messages contain the first 8 bytes of the packet that couldn't be delivered, which in the case of TCP and UDP contains the port numbers, which a TCP/UDP NAT uses to NAT the ICMP messages. And broadasting is not an acceptable solution because delivery of ICMP messages happens to sockets, not to machines. If you deliver ICMP UDP port unreachable messages to all sockets in the respective IPv4+ address range where the port happens to match, that's going to cause chaos.


A user can probably support IPv4+ with a software upgrade. They do not require replacing any routers, or even their operating system.


OK ... so, the idea is that the user installs a new web browser that supports IPv4+, and that is all he needs to access IPv4+ web servers?

If so, what would the first packet the client sends look like? In particular, what would be the values in the protocol and source address fields? And what would be the values in the first reply packet from the server?


6in4 != 6to4. In 6to4, only the router needs an IPv4 address, yielding a /48 to play with.


Oh I see, sorry about that.

It's what I get for being on my phone.

6to4 would probably have been more successful had it not allowed tunnelling arbitrary IPv6 addresses, not used a different protocol type, or broken the IPv4 addresses (by adding the 2.0.0.2.ip6.arpa DNS zone), but I agree it's basically the same thing.


I for one think the more incompatible V4 and V6 are the better! There are only two things that ever made any sense: 1) try as hard as possible to be fully inter-operable with each other, or 2) full clean break. Clearly, there was never a 100% consensus on the goal. As is now, I see it as a chance to start over with so many silly things (ie, 12 layers of NAT for everything in the cloud). When you look at all the gripping about problems, it's so much of a better pitch to think of it as this new global network to play with that opens more doors instead of some never-going-to-happen retrofit from hell.


Seconded. IPv6 brings a lot of nice things that we never would have had in an IPv4 based or extended world. Router fragmentation? Gone! Simple subnetting? Hello ipv6! DHCP? Gone (mostly)! Link local addresses? Got em!

These are all positive things we wouldn't have if we were still clinging to IPv4.


I agree wholeheartedly. From an ISP perspective its dual stack. The IPv4 and IPv6 networks are separate but serve the same customers, basically they should be overlapping to all endpoints.


From what I can see, he also readily admits that IPv4 and IPv4+ hosts cannot talk to each other, or more clearly, we cannot start using the extended address space before almost everybody has IPv4+ capable software.

I don't know whether to respond to that with "what?" or "yeah, so what?" but I'm leaning toward the former. IPv4 and IPv4+ hosts would communicate with each other, but IPv4 would only be able to communicate with the overlapping range of IPv4+.

Addresses in this range would have initially been relatively valuable but their value would be expected to decrease over time as more hosts started working over IPv4+.

I think djb was right, but obviously we're unlikely to ever find out.


"what"? Since you have a multiple IPv4+ hosts with the same IPv4 address, how would an IPv4 host communicate with an IPv4+ host?


The idea of multiple IPv4+ hosts with the same IPv4 address doesn't come into it at all. (Questions of proxying in its various forms aren't really relevant.) So, to answer your question: it wouldn't.


What does proxying have to do with it? One of us is terribly misunderstanding the concept. As I understand IPv4+ concept in this article, your router gets address 1.2.3.4 then every device behind it gets 1.2.3.4.0.0.0.1, etc. That way all the routers in between don't need to be upgraded, they just get the packets to your router and don't care about the extra address bytes, and your router gets them to a particular device. Which is great for routers in the middle, but your web browser still has to use IPv4 and NAT workarounds until all the web servers are upgraded to support IPv4+.


As I understand IPv4+ concept in this article, your router gets address 1.2.3.4 then every device behind it gets 1.2.3.4.0.0.0.1, etc.

This is the bit that wasn't in djb's original article AFAIR. My take was that 1.2.3.4 and 1.2.3.4.0.0.0.1 would be the same machine -- or at least allocated to the same entity.


IPv6 will get there eventually, there's no immediate need for it to happen overnight, obviously.


Indeed, at some point the situation with IPv4 will become so grave that it will become impossible to ignore IPv6. Transitioning to something like BangIP might be much easier, but it will be impossible to force people to adopt it, which will only lead to fragmentation. IPv6 might cause massive fragmentation on the internet right now, but once the IPv6 gets closer to 100% we can start dismantling the IPv4 infrastructure, which will force the remaining few to switch to IPv6. There's no way to do that with BangIP, as it involves keeping the IPv4 infrastructure intact, which will allow people to continue browsing a large part of the web and thus there will be little to no reason for a lot of people to switch to BangIP. In the end IPv6 will be a much better solution than BangIP.


> once the IPv6 gets closer to 100% we can start dismantling the IPv4 infrastructure

It's taken 20 years for IPv6 to get to 10%. In another 20 years (2036), will IPv6 be at 20%, 100%, or 0% (superseded by something else)?


Nah. IPv6 didn't really start to get going until v4 exhaustion approached, so 20 years is an overestimate.

v4 will die when the routing table becomes too filtered and/or the number of unreliable tunnels grows too large. You may remember how unpleasant v6 was around 2005 with all the flaky tunnels. v4 may well be like that by 2020 if address trading causes many long-prefix v4 routes.

Being yesterday's technology and unreliable has a poor prognosis.


Except it went from 6% to 10% in a year.


This sounds a lot like the argument for XHTML 2.0.


There was never any pressure to switch to XHTML2 - HTML4/ XHTML1 kept working fine. In contrast, IPv4 is going to become increasingly painful.


There was nothing wrong with XHTML 2.0 apart from 0 support from the vendors. So I guess it's better, right?

(but let's not discuss XHTML 2.0 now)


The real reason why IPv6 has been so slow to get deployed is precisely that you can not just take an IPv4-using program and network, fix all the structs and API calls, and have an IPv6 program. This is a sideshow compared to the real problem. IPv6 is profoundly different in all sorts of ways. Yes, if you just want to open a TCP connection to a remote system you can use an IPv6 address instead of an IPv4 address and the resulting socket is usually essentially identical (it isn't necessarily but the differences often don't matter for the simple common case), but almost everything else changes. "DHCP" changes. Vast new rules about all the classes of IPv6 addresses, and all network hardware needs to implement new code to handle all that. IPv6 addresses are much more complicated than IPv4 addresses.

In fact probably most of the people reading this only think they know what an IPv6 address is... based on my experience with people who think they know what IPv6 is, most are wrong. Do you know what the "link local" portion of the address is off the top of your head? Do you know what an % sign in the IPv6 address signifies? (This being HN, of course a few thousand of you do; you don't need to prove that in a reply. But I bet the majority of people reading this do not.)

Just look at this page: https://en.wikipedia.org/wiki/IPv6_address

By contrast, I can't link you to the "Wikipedia page on IPv4 addresses", because it doesn't rate its own page. It just gets rolled into a single section on the IPv4 page in general: https://en.wikipedia.org/wiki/IPv4#Addressing

And that's just addresses. There's huge swathes of other changes that require huge amounts of new code to be added to all network devices.

IPv6 isn't a failure (inasmuch as we really should have been done by now) because it requires a total upgrade of all network devices. Probably the vast bulk of critical devices have been upgraded in the time since IPv6 was first standardized. IPv6 was a failure because it also immensely complicated the network protocol and code did not just have to be "slightly modified" to work, but torn down and replaced with a much larger and more complicated chunk of code. IPv6 is not "just" IPv4 with bigger addresses. IPv6 doesn't fail to interoperate with IPv4 because of trivial networking issues, IPv6 fails to interoperate with IPv4 because it's a wildly different network stack that happens to offer similar enough TCP-like abstractions that user-level code often is only slightly affected, but everything else in the stack is profoundly affected.

The advantage of the "just extend it" plan is that it would have been that easy. Perhaps a judicious application of a few solutions to the worst IPv4 problems could have been added. But IPv6 is the technical equivalent of an appropriations bill in the US Congress. We have to do this, so let's take this opportunity to stuff every wish-list item in there we can. We didn't have to do that.

In a way, the article does a better job defending DJB's thesis than attacking it, precisely by pointing out that DJB's plan would have been relatively easy and feasible....


IPv6 is not a "wildly different network stack". It retains almost everything of the IPv4 stack. It replaces some small parts of the stack (e.g., DHCP by stateless auto-configuration, which doesn't affect applications). Updating an application-layer IPv4 program to support IPv6 is usually just a matter of fixing the structs/API calls.

And how is it "much more complicated"? IPv4 with layers of NAT bolted on top of it in an ad-hoc fashion doesn't strike me as a paragon of simplicity. The IPv6 world seems much cleaner to me.

Also, IPv4 addresses absolutely are complicated enough to have warranted their own Wikipedia articles: https://en.wikipedia.org/wiki/Classful_network, https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing. But it doesn't matter - for the most part, applications don't need to care about the structure of an IPv6 address.


> wildly different network stack that happens to offer similar enough TCP-like abstractions that user-level code often is only slightly affected, but everything else in the stack is profoundly affected.

TCP itself hasn't changed. TCP is a protocol that sits on top of IP (version 4 or 6). Same with UDP. Yes the IP stack has changed, that kind of thing happens when you bump the version number ;-)

So from an application standpoint TCP/UDP haven't changed, the only thing that has changed is the structure to set up the IP connection, and even that is hidden away for most users (getaddrinfo() deals with most of the complexities for developers).

Percent signs in an address are only used on link-local segments with link-local addresses, as they are the only way to distinguish what network interface to use. In almost all cases where you are dealing with IPv6 you can completely ignore that aspect because you won't have to deal with it, especially as an application developer trying to make connections to IPv6 hosts, or even starting servers/listening for incoming connections.

> The advantage of the "just extend it" plan is that it would have been that easy.

I disagree. This still requires that the entire IP stack be upgraded to support it, applications still need to update all of their network handling code to deal with the extensions, we'd be in exactly the same boat.


As I said, application programmers just using TCP have way less to deal with than all the other hardware in the stack. The point is all the other hardware has much larger changes to make than just "extending an address". It's a brand new protocol, not an extension.

I've been involved in some relatively trivial extension of application-level network devices to IPv6, and even that was a surprisingly large nightmare because you embed all these assumptions about addresses everywhere without even realizing it. Not just "they're a 4-byte integer"; one big one you embed without even realizing it pretty deeply is that "A network address is one type." In dual-stack code, you no longer have "an address". You have two types. That's just an example of the problem.

I think perhaps anyone who is opining on how easy this should be should also mention whether or not they've tried to convert an application or a network device to IPv6 or not, because I've seen even within a network company a lot of severe underestimations of the difficulty. (Some of these things are much easier when you write new code for IPv4+IPv6, which is why I say convert. Of course if you write new code on an abstraction layer that already solved this problem it's easier.) IPv6 is not IPv4, quite profoundly. It's not just addressing changes. Converting to IPv6 is not just "replacing all your gear", it is rewriting foundational aspects of all that gear and a non-trivial amount of the software that uses it. Not mere surface aspects like addressing schemes.

This all looks fine and dandy from 30,000 feet, but when you're on the ground, it's a really hard transition.


I have (worked at a networking equipment company on IPv6 support, briefly).

The few bits that are totally different (ARP-to-ND, for example) are all very small bits of code. The really hairy stuff was always the dual-stack - the assumption of a single IP instance running over any given layer-2 network is baked deeply into most systems, and changing that is a royal pain. That plus the renumbering of constants (ugh ICMPv6).

The way I explained it to people was: IPv6 is exactly the same as IPv4, but with incompatible field sizes and constants, different (but usually MUCH simpler) address configuration, and no hop-by-hop fragmentation (oh frabjous day!).


> I think perhaps anyone who is opining on how easy this should be should also mention whether or not they've tried to convert an application or a network device to IPv6 or not

Yes, to the former, only device updates I've done was for a proprietary appliance and that was mainly get new Linux kernel built and then upgrade software. I have not had to deal with silicon level stuff.

I updated various proprietary applications over the course of a week to bind and function over IPv6. Logging was an issue with the new addresses since assumptions were made about IP length, but those were quickly fixed.

Clients that were using old functions instead of getaddrinfo() were easily updated, and in general my experience is that clients don't really care so much about what IP version they use to connect. Once again logging functions assumed that IP's were only IPv4 structs, so some changes and they could log either one.

Overall the transition was simple, the applications already supported binding to multiple addresses, so having it be dual stack ready (binding both IPv4 and IPv6 was simple), and those that didn't took a little longer but ultimately wasn't that much more difficult to get them upgraded.

I pay my network vendors to get me the latest standards, getting all of this right on their end may have been a lot of work, but ultimately that is a one-time cost of doing business, and in most cases I am paying for them to support my use cases.


Be specific. What is the "almost everything else" that so many people have to worry about? People who write IP address parsing libraries have to care about percent signs and formats. People who write DHCP clients have to care about DHCP changes. But neither of these are huge changes that affect everyone.


I've got one- every interface has two ipv6 ips, one real, one link local, which requires a lot of little tweaks in a lot of deployments.

Or if you're doing DSR, the default route ordering rules are different.


Every interface can have 1 or more IPv6 IP's. Link-local and N number of others, where N is 0 or more.

What kind of tweaks have you required in your deployments because of this?

DSR is a special use case, and with each interface having a link-local address means you don't need to provide globally unique addresses, because the source/destination specify their route explicitly, each hop can use their link-local address. DSR would also require modification if it was using an extended version of IPv4...


Link local is by design invisible to normalapplications. You can't even use them in place of routable addresses in applications. (You have to do a special bind() with the right scope id)


I'll bite. How can you have more than one "default" route without PBR on the host? That's breaking the meaning of default.

Why does link local need to be complicated? Router interfaces facing clients should be fe80::1. That way, every client knows it's default route is fe80::1%eth0 (or similar). Works great for multiple addresses from different networks on the same host, too.


This isn't new. Your interface could have more than one ipv4 IP also. If two ipv6 addresses are throwing something off that means it wasn't properly handling this case before.


> Just look at this page: https://en.wikipedia.org/wiki/IPv6_address

> By contrast, I can't link you to the "Wikipedia page on IPv4 addresses", because it doesn't rate its own page. It just gets rolled into a single section on the IPv4 page in general: https://en.wikipedia.org/wiki/IPv4#Addressing

The above neatly encapsulates my problem with IPv6. I feel IPv6 would have much more widely adopted by now if people like myself—who have spent nominal time setting up small computer networks such as their home network—could more readily grok the deltas between v4 and v6. With the reality of v6 being so dramatically different, I have on about three separate occasions sat down to try to understand what I need to do in order to have v6 on my home network and each time I just give up after a few hours of reading.

It's just so much more complicated for the amateur network operators out there.

Additionally, it instills fear that if I turn on v6, I will inevitably have my home network in some tragically vulnerable state.


> With the reality of v6 being so dramatically different, I have on about three separate occasions sat down to try to understand what I need to do in order to have v6 on my home network and each time I just give up after a few hours of reading.

I don't mean to offend you, but I think that that suggests that you don't understand IPv4 either.

IPv6 isn't really all that different from IPv4--with one major exception: All of the workarounds for the shortcomings of IPv4 that dominate local networks nowadays are not needed anymore, actually making networks so much simpler again.

Now, many people who have learned IP networking in such environments in the last ten years or so (and I suspect you are one of those) seem to think that those workarounds are what defines IPv4 and then are confused by IPv6's lack of those workarounds, thinking that those are missing features.

Maybe you think that your "internal network" is in some way fundamentally different from "the internet" and that a router is a device that connects those two to give your local network "access to the internet"? That is a common misunderstanding caused by NAT. The internet without NAT, be it IPv4 or IPv6, doesn't know any distinction between "internal" or "external" networks. It is all one network, the internet. Your LAN is not somehow "connected to the internet", it is itself part of the internet. Your home router (without NAT) is no different in function than any other router on the internet: It is connected to more than one transmission medium and thus allows devices on one medium to reach devices connected to another medium, possibly transitively through yet another (series of) routers. And it's completely symmetrical in that regard: It allows devices on your LAN to send packets to devices outside your LAN (say one of Google's webservers), but equally allows devices outside your LAN to send packets to devices on your LAN (say a webserver on your laptop).

So, the most important thing you may have to completely unlearn is the idea of "private addresses" and "NAT" and "port forwarding". You don't get one address from your provider, you get a huge subnet with quadrillions of addresses that you can use to assign addresses to your devices, similar to the early days of IPv4. Your laptop gets an IPv6 address that is no different in function than the IPv6 address of Google's webserver.

Other than that, details and terms differ, but the general concepts of IPv6 aren't all that different from IPv4. ARP is now NDP, DHCP is now SLAAC (or maybe still DHCPv6 if you like), ...

Now, if you think that it seems problematic to have "public addresses" on your "private network": It's not, that's purely psychology. Yes, a stateful packetfilter at boundaries to other, non-trustworthy, networks might still be a good idea, just as with IPv4, whether you were using NAT or not. If anything, having one global address space makes things much less complicated, and thus more difficult to screw things up.

Once you get the hang of it, you will love it and start wondering why you ever considered NAT a reasonable idea. Ever had the problem that you had multiple machines behind a NAT offering the same service that you needed to access from the outside, so you had to put one of them on a different port on "the public address"? Ever tried to access a port-forwarded service from the network behind the NAT and had it either fail because of lack of hairpin NAT, or it was slow because of the bottleneck that was the hairpin NAT? All those problems simply vanish, never to return.


Your comment gave me yet another reason to feel lucky to have learned about the Internet in the early 90’s, just before the boom. I agree with your comment enormously, and I regret that I have only one upvote to give.


Thanks for taking the time to write a very thoughtful reply. You've given me some motivation to take another look into it!


Arguably, it deserves a page because it provides more features.


The fact that it "deserves" its own page is precisely my point. "It has more features" -> "it takes more implementation work than just replacing all addresses". Even ignoring the base work of making things dual-stack you have fundamental rewrites of base assumptions about addresses to take into account.


Actually, ipv6 takes less implementation work from a network operations standpoint. Every site gets a fixed size network, every building gets a fixed size network, every vlan gets a fixed size network. No more IP budgeting and wrangling nabout justifying IP allocations. "Is that worthy of a /18 or should it be a /20?" That's all gone. Every vlan with people gets a /64 and your router interface to them is fe80::1. Turn on SLAAC and let it run. No more NAT pools and rules. It's great!


I've been pushing this idea at work lately. We've got a whole network of /28's in IPv4. Provisioning new servers is a nightmare.


I'd highly suggest you follow the NANOG BCOP. There's a site for it: http://nabcop.org/index.php/IPv6_Subnetting

Here's where I got the idea of using fe80::1 everywhere for the link-local gateway: https://www.edge-cloud.net/2013/08/ipv6-link-local-addresses...


What about Enhanced IP as in www.enhancedip.org?


Every problem noted in this article also exists in Enhanced IP. It still requires all software and hardware layers to be redesigned.

Every potential alternative to IPV6 is pointless. IPV6 is already implemented by every network vendor, and every modern operating system. Most consumer ISPs have already implemented it. All remaining ISPs, including Enterprise providers, are in the middle of implementing it.

No alternative protocol, including Enhanced IP, is going to be implemented. Ever.


While Enhanced IP requires software upgrades it does not require any hardware upgrades. Enhanced IP rides over the IPv4 network without requiring re-peering like IPv6 does. I have already used Enhanced IP over the Internet and it works fine. Also, I wrote the kernel patches for Linux over a period of less than six months. If I can do this the other operating systems vendors could do it too. Instead of being at 10% network capability after 20 years, Enhanced IP has an advantage because it transports packets over IPv4. Enhanced IP also keeps protocols like ARP and DHCPv4 so there is less disruption here. Further, Enhanced IP uses IPv6 AAAA records for DNS lookups so this area of the network experiences less disruption too. You should consider reading about how we do this as it is pretty interesting. Please read our paper or RFC for further clarification or details. They can be found here: http://www.enhancedip.org/documentation.html

The one comment you make on your blog post that is true is that Enhanced IP is not compatible with multiple layers of NAT.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: