8 ms·

I have several times cited it as a key article, more insightful than almost anything else I've ever read about IPv6, but I concede it is overlong and unclear an

I have several times cited it as a key article, more insightful than almost anything else I've ever read about IPv6, but I concede it is overlong and unclear and needs more illustrations. (Which, as a technical writer myself, I generally regard as a crutch.) I think the core argument can be summarised as this: 1. IPv6 is flawed because it has 2 main layers, but it needed 3. 2. It understands physical addresses, and it has its own logical addresses. 3. But it really needed another layer in between them: a virtual translation/mapping layer. 4. Crucially, it lacks this. As such it is not better enough than IPv4 to ever totally replace IPv4. 5. But apenwarr proposes that it is, in essence, possible to fake this using QUIC. https://en.wikipedia.org/wiki/QUIC https://en.wikipedia.org/wiki/QUIC <- note the diagram in that article. 6. Using this, it's possible to fake what IPv6 should have had but didn't, and get some of the benefits at the cost of more work. 7. However IPv6 remains doomed to never totally replace IPv4. Boiling that down to 2 key points: Point A: IPv6 is broken because it didn't go far enough; its mapping model is fundamentally inadequate. Point B: It's OK, here's how we can work around that, but it doesn't fix the problem & never will. And generalising from that argument, my take is this: Butler Lampson said: "All problems in computer science can be solved by another level of indirection." David Wheeler pointed out: "… except for the problem of too many layers of indirection." The corollary of this is: it is imperative to closely track how many layers of indirection you have. Too many is bad, but arguably, not enough is worse. With too many, you get inefficiency, but you can nonetheless get the job done. But with too few, you might not usefully be able to do the job at all. IPv6 did not have enough, and so failed to achieve its primary goal.

GordonS 3y ago
> As such it is not better enough than IPv4 That's the crux of it. Sometimes I think we'd be better off forgetting about IPv6, and starting afresh with an IPv7 - something that provides a meaningful incentive to upgrade.
- poizan42 3y ago
  IPv7 was used for the "TP/IX: The Next Internet" proposal from 1993: https://datatracker.ietf.org/doc/html/rfc1475 https://datatracker.ietf.org/doc/html/rfc1475 The next available version is IPv10
  - jve 3y ago
    > IPv10 Which is fine, because it is IPv2 in human readable form after all.
  - LinuxBender 3y ago
    We may wish to skip that one as well. [1][2] [1] - https://www.noction.com/blog/ipv10 https://www.noction.com/blog/ipv10 [2] - https://datatracker.ietf.org/doc/draft-omar-ipv10/10/ https://datatracker.ietf.org/doc/draft-omar-ipv10/10/
    - BizarroLand 3y ago
      OK, so let's just crank it all the way to 11, since 11 is 1 more than 10. I think smarter people than me can handle all the technical underlayment, but when it gets to the point of where the techs and sysadmins are using it, it should have an 8 digit hex key at the start and then an IPv4 "alike" address at the end, and 0000:0000:-whatever should encapsulate the current network schema for backwards compatibility. Then new systems would get 0000:0001:- and on. That would add 4 billion entire internets to the system and still work at the fundamental level like the current one. Your IPv11 layer would only be used at the edges where the systems leave your wlan, and they could send your mac address as the swapover key or use it as part of the key when sharing security data, and the best part is that end users and clients would not need to know anything more about the network to make it work than that 8 digit string, and most of them, especially home and mobile users, wouldn't even need to know that. It would stop at your modem and be handled by the cell carriers and your home internet providers.
      - 0cf8612b2e1e 3y ago
        Probably anathema to the dreams of IPv6+ IP-for-everything, but in your putative scheme, could we also make a carve out for local network? I like that 192.168.*, 10.* are defined as local. So 0000:0000 local network, 0000:0001 legacy internet.
        BizarroLand 3y ago
- AtlasBarfed 3y ago
  I think what is first necessary is to force compliance of upgrading of IPV4 stacks to accept some information in the options section of the IP packet. According to wikipedia, many/most routers ignore or block packets that have anything specified there. You know what? That sounds like the RFC isn't being followed, but if it's a large enough pattern, then the RFC doesn't matter. It is the standard. I would say: 1) gather all the engineers from the major switches and networking companies, the Linux network stack, and apple and microsoft, and sure the mobiles. And ask them the easiest way to change the code to support a vast expansion of addresses in the general format of the IPV4 header: options section? Magic IPV4 address that triggers a IPV4r2 packet? 2) as a carrot, maybe you make some way that NATs / VPNs / bridging / whatever works BETTER in the IPV4r2 packet? If the packets had more information in them about the mapping/bridging so external polling was easier and numerous other use cases, then that would spur the vendors to change. 3) accept that NATs, Bridges, etc exist and will continue to. They are now established as a way to think about networking, and there are likely millions of people that think about networking in these ways, even if they are superfluous / unnecessary in the utopia of IPv6 universal adoption. So put them in the protocol. If universal addressing with firewalls eliminates everything, then they will wither on the vine over the course of a couple decades. So, what's wrong with this? It's obviously naive. Also, NO SLASHES NO COLONS in the notation. And ... can we increase the number of ports to 32 bits or more?
  - AtlasBarfed 3y ago
    OK I want to expand on a "magic IPv4" address that is used to flag if a packet is legacy IPV4 routable or requires IPV4 processing. If there is that magic IPV4 and an unupgraded router encounters that packet, it ROUTES IT TO THAT MAGIC IP. ... that magic IP isn't a ghost IP. It's a service that takes the packet and routes it using IPV4v2, and NAT translates it back to the legacy router on the return path. ... that might not work ... or maybe it will?
    - greyface- 3y ago
      You've reinvented 6to4 and the 192.88.99.1 well-known anycast address.
tenebrisalietum 3y ago
I read the article, also found it a bit confusing and wayward, and couldn't quite articulate why I disagreed with it at first, but I think I can now. - The "mobile IP" problem isn't IP's job and should not be. IP should be as stateless as possible because this makes it cheap and easy to add capacity and redundancy to a network. - IP addresses are assigned to interfaces, not people, computers, devices, applications, nodes, etc. If you want a fixed reference identifier associated to something across the wire, it is correct to implement that in addition to the state it requires on top of IP. If your application assigns or assumes identity based on IP address, that's a badly written application at this point. > Y has no idea what that means, and throws it away. X should have sent Y a session ID? The client and server should maintain session IDs and not the IP layer (imagine the security issues)? - I think the author mostly has a problem with TCP. QUIC may become the next TCP. And that's fine.
- derefr 3y ago
  > The "mobile IP" problem isn't IP's job and should not be. IP should be as stateless as possible because this makes it cheap and easy to add capacity and redundancy to a network. But, to be clear, many implementations of IP (both IPv4 and IPv6) do already have "mobile IPs." There's nothing stopping you from having "mobile IPs." They're just complex, and only work when everywhere the IP can move between all exists within a single AS. • You can move between multiple wireless APs in a conference hall, and have a layer-3 address that follows you as you switch network segments and thus acquire new layer-2 addresses (which means that the packets destined to that address are being dynamically re-routed at some upstream switch, as the address assignment changes.) • You can move between cellular antenna and frontend infra (think: WiMax or 5G APs) at different places in a city, while remaining connected to a single cellular backend infra (what you'd think of as a "cell tower") and thus holding a single persistent L3 address.
  - Dagger2 3y ago
    You can actually move anywhere with Mobile IPv6. If you move outside your AS, it automatically tunnels your traffic back to your home network with IPsec. There's also a feature called "Correspondent Node" which allows you to send traffic directly rather than tunnelling via your home network. Which kind of makes it sound like IPv6 already has the feature the article thinks it should have had.
deleted 3y ago
[deleted]
FuriouslyAdrift 3y ago
The single biggest mistake IPv6 made was not encompassing the entire IPv4 space within it to ease transition. As it is, I am seeing a transition to either non-IP or LISP/HIP based methodologies due to security and attestation concerns.
- K2L8M11N2 3y ago
  But it does, that's what ::ffff:0:0/96 is for
  - remram 3y ago
    I can't `ping ::ffff:192.168.0.1` and have it ping my router. There is a range reserved for representing IPv4 addresses, but the stack doesn't translate.
    - throw0101b 3y ago
      > I can't `ping ::ffff:192.168.0.1` and have it ping my router. How would that even work in theory? How would a ('legacy'?) host that only understands the 32-bit data structure of IPv4 addresses talk to a >32-bit data structure IPv6 addressed host?
      - FuriouslyAdrift 3y ago
        If it truly encapsulated IPv4, then there wouldn't be two stacks. It would be one stack and legacy devices could snip the xtra bits (or have it done for them via a router).
        deleted 3y ago
        [deleted]
        icedchai 3y ago
        I'm skeptical. How would the legacy device V4 understand the "extra bits"? How would this work on the same subnet (no router)?
arka2147483647 3y ago
> Point A: IPv6 is broken because it didn't go far enough Alternatively, it failed because it went too far. When you have an established system which is used everywhere, it is immensely difficult to replace it. Something like IPv4, with 64 bit addressed might have been easier to push through. Eg, addresses like 123.123.123.123.123.123.123.123. We have jumbo frames, why not jumbo addresses?
- jandrese 3y ago
  Because it comes with all of the drawbacks of IPv6 but also ditches some of the advantages. You still need to update every router and application. Network admins still need to learn something new. The two protocols still don't interoperate. If you're going to go through all of that trouble why only do a half measure. IPv6 is supposed to be the final version of IP.
  - arka2147483647 3y ago
    > The two protocols still don't interoperate. On the contrary, they would, the behavior's and quicks would be the same. And if we define, say, that if the last four components are zero, then the addr is the same as normal IPv4 address, then you could deploy the whole thing without having anybody assigning new addresses. NAT's/configs/etc could keep working. The big problem with IPv6 is that everything has to be double-configured to support both IPv4 and IPv6. Two addressed for all. Different semantics. No backwards compatibility. If you imagine that all network HW is recycled, say every decade, you could roll the thing in without having anybody to reconfigure everything. Eventually coverage would be complete. This cant happen with IPv6, because the double configuration problem. Extending vs replacement. This is of course a pointless though experiment, because IPv6 is the route that was chosen.
    - deleted 3y ago
      [deleted]
    - ksec 3y ago
      I have been stating something very similar this for close to 10 years. It could possibly be known as IPv5 considering Internet Stream Protocol was never really used. Or simply IP64.
fanf2 3y ago
Lampson attributed that “fundamental theorem of software engineering” to Wheeler, he did not claim to have said it first.
AtlasBarfed 3y ago
I pulled out this as the most salient point in the article: IPV6 designers assumed that IPV4 would be phased out completely in a short period of time, for some definition of a short period of time, and IPV6 would completely replace internet networking. I think it was protocol design hubris: we are fixing SO MUCH STUFF that people will flock to this irresistible shining trophy of protocol design. And now it's been ... almost ... 30 years. Which means what is really necessary is a new IP protocol that will somehow, SOMEHOW (don't ask me how, I don't effing know) speak seamlessly to IPV4 and IPV6, and be so irresistible that people will want to migrate off of both. I almost wonder if what is necessary isn't a formally predesigned protocol. What is needed is someone, somewhere, to come up with an approach that becomes a grassroots, and the industry rushes towards it. I don't even know if such a thing is possible anymore, IPV4 land may at this point be complexity theory/mathematically impossible to make a N+1 umbrella protocol of any real "elegance".
- Dagger2 3y ago
  > Which means what is really necessary is a new IP protocol that will somehow, SOMEHOW (don't ask me how, I don't effing know) speak seamlessly to IPV4 and IPV6 You don't know how, and nobody knows how, because it's not possible to do. v4 simply does not support addresses longer than 32 bits. If it did, we wouldn't need v6 in the first place. Choosing not to do something that's impossible isn't hubris. Hubris is criticizing the people who knew what they were doing without realizing how little of the problem domain you yourself understand.
  - lproven 3y ago
    > You don't know how, and nobody knows how, because it's not possible to do. I think you misunderstood the comment, but at first reading, I did too. But on consideration, I do not think @AtlasBarfed meant that this hypothetical IPv12 or whatever (7 through to 10 are taken) would be able to talk to both in one protocol. It's well established that no seamless extension of the IPv4 4-octet address space was possible. I know, a lot of people still don't get that, but honestly, to the majority of people working in tech today, all this stuff is black magic that just happens. Either they learn, or they don't and can be ignored. That's OK. We have to live with that and move on. The real, the big question here is: was there some single obvious thing that IPv6 failed to do or failed to include that has made its uptake so slow? It's taken some 30 years to reach approximately half the IP market. That is not just "not good" - that's terrible. What IMHO apenwarr's blog post was trying to get at was the complexity of connection schemes needed, and how a new protocol with an integral way of of constructing virtual networks, connected over the public internet into cohesive wholes via some form of built-in redirection or mapping layer, would have made it a far more compelling offering. I have seen others saying this, but I can't find any links any more. I welcome other pointers to articles not merely pointing out problems -- there are lots of those -- but proposing solutions.

GordonS 3y ago

> As such it is not better enough than IPv4 That's the crux of it. Sometimes I think we'd be better off forgetting about IPv6, and starting afresh with an IPv7 - something that provides a meaningful incentive to upgrade.

poizan42 3y ago
IPv7 was used for the "TP/IX: The Next Internet" proposal from 1993: https://datatracker.ietf.org/doc/html/rfc1475 https://datatracker.ietf.org/doc/html/rfc1475 The next available version is IPv10
- jve 3y ago
  > IPv10 Which is fine, because it is IPv2 in human readable form after all.
- LinuxBender 3y ago
  We may wish to skip that one as well. [1][2] [1] - https://www.noction.com/blog/ipv10 https://www.noction.com/blog/ipv10 [2] - https://datatracker.ietf.org/doc/draft-omar-ipv10/10/ https://datatracker.ietf.org/doc/draft-omar-ipv10/10/
  - BizarroLand 3y ago
    OK, so let's just crank it all the way to 11, since 11 is 1 more than 10. I think smarter people than me can handle all the technical underlayment, but when it gets to the point of where the techs and sysadmins are using it, it should have an 8 digit hex key at the start and then an IPv4 "alike" address at the end, and 0000:0000:-whatever should encapsulate the current network schema for backwards compatibility. Then new systems would get 0000:0001:- and on. That would add 4 billion entire internets to the system and still work at the fundamental level like the current one. Your IPv11 layer would only be used at the edges where the systems leave your wlan, and they could send your mac address as the swapover key or use it as part of the key when sharing security data, and the best part is that end users and clients would not need to know anything more about the network to make it work than that 8 digit string, and most of them, especially home and mobile users, wouldn't even need to know that. It would stop at your modem and be handled by the cell carriers and your home internet providers.
    - 0cf8612b2e1e 3y ago
      Probably anathema to the dreams of IPv6+ IP-for-everything, but in your putative scheme, could we also make a carve out for local network? I like that 192.168.*, 10.* are defined as local. So 0000:0000 local network, 0000:0001 legacy internet.
      - BizarroLand 3y ago
AtlasBarfed 3y ago
I think what is first necessary is to force compliance of upgrading of IPV4 stacks to accept some information in the options section of the IP packet. According to wikipedia, many/most routers ignore or block packets that have anything specified there. You know what? That sounds like the RFC isn't being followed, but if it's a large enough pattern, then the RFC doesn't matter. It is the standard. I would say: 1) gather all the engineers from the major switches and networking companies, the Linux network stack, and apple and microsoft, and sure the mobiles. And ask them the easiest way to change the code to support a vast expansion of addresses in the general format of the IPV4 header: options section? Magic IPV4 address that triggers a IPV4r2 packet? 2) as a carrot, maybe you make some way that NATs / VPNs / bridging / whatever works BETTER in the IPV4r2 packet? If the packets had more information in them about the mapping/bridging so external polling was easier and numerous other use cases, then that would spur the vendors to change. 3) accept that NATs, Bridges, etc exist and will continue to. They are now established as a way to think about networking, and there are likely millions of people that think about networking in these ways, even if they are superfluous / unnecessary in the utopia of IPv6 universal adoption. So put them in the protocol. If universal addressing with firewalls eliminates everything, then they will wither on the vine over the course of a couple decades. So, what's wrong with this? It's obviously naive. Also, NO SLASHES NO COLONS in the notation. And ... can we increase the number of ports to 32 bits or more?
- AtlasBarfed 3y ago
  OK I want to expand on a "magic IPv4" address that is used to flag if a packet is legacy IPV4 routable or requires IPV4 processing. If there is that magic IPV4 and an unupgraded router encounters that packet, it ROUTES IT TO THAT MAGIC IP. ... that magic IP isn't a ghost IP. It's a service that takes the packet and routes it using IPV4v2, and NAT translates it back to the legacy router on the return path. ... that might not work ... or maybe it will?
  - greyface- 3y ago
    You've reinvented 6to4 and the 192.88.99.1 well-known anycast address.

tenebrisalietum 3y ago

I read the article, also found it a bit confusing and wayward, and couldn't quite articulate why I disagreed with it at first, but I think I can now. - The "mobile IP" problem isn't IP's job and should not be. IP should be as stateless as possible because this makes it cheap and easy to add capacity and redundancy to a network. - IP addresses are assigned to interfaces, not people, computers, devices, applications, nodes, etc. If you want a fixed reference identifier associated to something across the wire, it is correct to implement that in addition to the state it requires on top of IP. If your application assigns or assumes identity based on IP address, that's a badly written application at this point. > Y has no idea what that means, and throws it away. X should have sent Y a session ID? The client and server should maintain session IDs and not the IP layer (imagine the security issues)? - I think the author mostly has a problem with TCP. QUIC may become the next TCP. And that's fine.

derefr 3y ago
> The "mobile IP" problem isn't IP's job and should not be. IP should be as stateless as possible because this makes it cheap and easy to add capacity and redundancy to a network. But, to be clear, many implementations of IP (both IPv4 and IPv6) do already have "mobile IPs." There's nothing stopping you from having "mobile IPs." They're just complex, and only work when everywhere the IP can move between all exists within a single AS. • You can move between multiple wireless APs in a conference hall, and have a layer-3 address that follows you as you switch network segments and thus acquire new layer-2 addresses (which means that the packets destined to that address are being dynamically re-routed at some upstream switch, as the address assignment changes.) • You can move between cellular antenna and frontend infra (think: WiMax or 5G APs) at different places in a city, while remaining connected to a single cellular backend infra (what you'd think of as a "cell tower") and thus holding a single persistent L3 address.
- Dagger2 3y ago
  You can actually move anywhere with Mobile IPv6. If you move outside your AS, it automatically tunnels your traffic back to your home network with IPsec. There's also a feature called "Correspondent Node" which allows you to send traffic directly rather than tunnelling via your home network. Which kind of makes it sound like IPv6 already has the feature the article thinks it should have had.

deleted 3y ago

[deleted]

FuriouslyAdrift 3y ago

The single biggest mistake IPv6 made was not encompassing the entire IPv4 space within it to ease transition. As it is, I am seeing a transition to either non-IP or LISP/HIP based methodologies due to security and attestation concerns.

K2L8M11N2 3y ago
But it does, that's what ::ffff:0:0/96 is for
- remram 3y ago
  I can't `ping ::ffff:192.168.0.1` and have it ping my router. There is a range reserved for representing IPv4 addresses, but the stack doesn't translate.
  - throw0101b 3y ago
    > I can't `ping ::ffff:192.168.0.1` and have it ping my router. How would that even work in theory? How would a ('legacy'?) host that only understands the 32-bit data structure of IPv4 addresses talk to a >32-bit data structure IPv6 addressed host?
    - FuriouslyAdrift 3y ago
      If it truly encapsulated IPv4, then there wouldn't be two stacks. It would be one stack and legacy devices could snip the xtra bits (or have it done for them via a router).
      - deleted 3y ago
        [deleted]
      - icedchai 3y ago
        I'm skeptical. How would the legacy device V4 understand the "extra bits"? How would this work on the same subnet (no router)?

arka2147483647 3y ago

> Point A: IPv6 is broken because it didn't go far enough Alternatively, it failed because it went too far. When you have an established system which is used everywhere, it is immensely difficult to replace it. Something like IPv4, with 64 bit addressed might have been easier to push through. Eg, addresses like 123.123.123.123.123.123.123.123. We have jumbo frames, why not jumbo addresses?

jandrese 3y ago
Because it comes with all of the drawbacks of IPv6 but also ditches some of the advantages. You still need to update every router and application. Network admins still need to learn something new. The two protocols still don't interoperate. If you're going to go through all of that trouble why only do a half measure. IPv6 is supposed to be the final version of IP.
- arka2147483647 3y ago
  > The two protocols still don't interoperate. On the contrary, they would, the behavior's and quicks would be the same. And if we define, say, that if the last four components are zero, then the addr is the same as normal IPv4 address, then you could deploy the whole thing without having anybody assigning new addresses. NAT's/configs/etc could keep working. The big problem with IPv6 is that everything has to be double-configured to support both IPv4 and IPv6. Two addressed for all. Different semantics. No backwards compatibility. If you imagine that all network HW is recycled, say every decade, you could roll the thing in without having anybody to reconfigure everything. Eventually coverage would be complete. This cant happen with IPv6, because the double configuration problem. Extending vs replacement. This is of course a pointless though experiment, because IPv6 is the route that was chosen.
  - deleted 3y ago
    [deleted]
  - ksec 3y ago
    I have been stating something very similar this for close to 10 years. It could possibly be known as IPv5 considering Internet Stream Protocol was never really used. Or simply IP64.

fanf2 3y ago

Lampson attributed that “fundamental theorem of software engineering” to Wheeler, he did not claim to have said it first.

AtlasBarfed 3y ago

I pulled out this as the most salient point in the article: IPV6 designers assumed that IPV4 would be phased out completely in a short period of time, for some definition of a short period of time, and IPV6 would completely replace internet networking. I think it was protocol design hubris: we are fixing SO MUCH STUFF that people will flock to this irresistible shining trophy of protocol design. And now it's been ... almost ... 30 years. Which means what is really necessary is a new IP protocol that will somehow, SOMEHOW (don't ask me how, I don't effing know) speak seamlessly to IPV4 and IPV6, and be so irresistible that people will want to migrate off of both. I almost wonder if what is necessary isn't a formally predesigned protocol. What is needed is someone, somewhere, to come up with an approach that becomes a grassroots, and the industry rushes towards it. I don't even know if such a thing is possible anymore, IPV4 land may at this point be complexity theory/mathematically impossible to make a N+1 umbrella protocol of any real "elegance".

Dagger2 3y ago
> Which means what is really necessary is a new IP protocol that will somehow, SOMEHOW (don't ask me how, I don't effing know) speak seamlessly to IPV4 and IPV6 You don't know how, and nobody knows how, because it's not possible to do. v4 simply does not support addresses longer than 32 bits. If it did, we wouldn't need v6 in the first place. Choosing not to do something that's impossible isn't hubris. Hubris is criticizing the people who knew what they were doing without realizing how little of the problem domain you yourself understand.
- lproven 3y ago
  > You don't know how, and nobody knows how, because it's not possible to do. I think you misunderstood the comment, but at first reading, I did too. But on consideration, I do not think @AtlasBarfed meant that this hypothetical IPv12 or whatever (7 through to 10 are taken) would be able to talk to both in one protocol. It's well established that no seamless extension of the IPv4 4-octet address space was possible. I know, a lot of people still don't get that, but honestly, to the majority of people working in tech today, all this stuff is black magic that just happens. Either they learn, or they don't and can be ignored. That's OK. We have to live with that and move on. The real, the big question here is: was there some single obvious thing that IPv6 failed to do or failed to include that has made its uptake so slow? It's taken some 30 years to reach approximately half the IP market. That is not just "not good" - that's terrible. What IMHO apenwarr's blog post was trying to get at was the complexity of connection schemes needed, and how a new protocol with an integral way of of constructing virtual networks, connected over the public internet into cohesive wholes via some form of built-in redirection or mapping layer, would have made it a far more compelling offering. I have seen others saying this, but I can't find any links any more. I welcome other pointers to articles not merely pointing out problems -- there are lots of those -- but proposing solutions.