5 ms·

I am not a network engineer, but for about 20 years I have wondered why we didn't 'just' do something like: 1. Include an extra 32-bits of address information

by dqh 4y ago

I am not a network engineer, but for about 20 years I have wondered why we didn't 'just' do something like: 1. Include an extra 32-bits of address information as an IP options header. Call it an IP4.4 packet. 2. (I think?) IP4.4 packets would therefore happily travel over existing IP4 infrastructure. 3. Each existing IP4 address becomes a potential IP4.4 network with 32-bits of address space behind it. IP4.4 aware routers at the network border could swap inbound IP4 destination with the .4 address before forwarding on to the internal network. Basically like NAT, but you can allow inbound connections without maintaining state. EDIT: formatting

vlovich123 4y ago
What happens when your 4.4 packet hits a router box somewhere out there that doesn’t understand 4.4? Where’s it going to send that packet? To the wrong address (or potentially even create an infinite loop). Now what?
- AtlasBarfed 4y ago
  I understand what you're saying, but isn't IP supposed to be about routing things around failure points? So routers that "know" IP 4.4 would "know" what routers aren't 4.4.
  - vlovich123 4y ago
    By definition you’re trying to retain back compat. So you have a 4.4 source IP address. You try to establish a TCP connection to a legacy IPv4 website that isn’t 4.4 aware. What address is that website sending the response back to? Even if it is 4.4 aware, how do you guarantee it’s taking a path back through 4.4 aware servers? The whole point of adding an option header is to allow unmolested transit through existing IP stacks. If you’re saying you’re routing around them, then you’ve bifurcated the networks and you’re back to IPv6.
    - AtlasBarfed 4y ago
      You're basically doing carrier grade NAT for that, the same thing that is apparently tooootallly acceptable to the ipv6 people for their big success story: mobile. The only success story of ipv6 leads us to the solution: backbone-level CGNAT and other hacks, then impose the economic cost on IPV4-only carriers and endusers.
      - keiyakins 4y ago
        Indeed, your system would require NAT4.44 as a transition mechanism, just like NAT64 is needed now. It gets no benefit over IPv6, and none of the other benefits like SLAAC. So, what's the point? It's no easier to migrate to, and once we're migrated is worse.
        dqh 4y ago
        If a source behind an IP4.4 router sent a packet to an IP4 destination, then yes, the source router would need to apply NAT to the source address. But this is already a standard IP4 router capability, and I think that most connection origins on the internet are already behind a NAT. I don't agree that it wouldn't have been easier to migrate. No changes would have been needed within retail ISPs for starters. Source code changes to existing IP4 stacks would have been minimal, without requiring a whole new stack like IP6. Practical migration requires only that the source and destination networks be IP4.4 aware. The idea might make less and less sense over time, but if we'd done this 20 years ago we would have reliably had all the address space we needed 10 years ago, no further transition necessary. So much money spent on IP6 could have been saved, not to mention the opportunity cost of IP4 space being hard to get in recent years.
        keiyakins 4y ago
        How would changes not have been required in the ISPs? An IPv4 router wouldn't know what to do with a 4.4 packet. At best, it'd route it to the wrong place - 1.2.3.4.5.6.7.8 and 5.6.7.8 are totally different hosts that may well not even be on the same continent. Additionally, the only reason so much code had to change for ipv6 is that Berkley sockets is a terrible, terrible API that has abstractions so leaky they might as well not exist. Sure, in other APIs (what few exist) low-level code had to be rewritten somewhat, but that's going to be true for any protocol change, because that's kinda what change means.
- dqh 4y ago
  It routes it as an IP4 packet, because it still is a valid IP4 address. Think of it as a way to let a stateless IP4.4 aware NAT router at the edge join two 32-bit networks together. An IP4.4 client could send a packet to a destination in that network by putting the address of the IP4.4 router in the usual IP4 destination, and the 'internal' IP address in the IP options header. No 'entire Internet update' necessary
- dqh 4y ago
  > or potentially even create an infinite loop I think that's what TTL is for. Without it, it would be entirely possible to have infinite loops between IP4 networks.
remram 4y ago
"Happily travel" and get to the wrong place? What's the point of that?
- dqh 4y ago
  Happily traverse the existing IP4 Internet, to an IP4.4 aware edge network. The point is that you don't need to modify any IP4 networks between the IP4.4 aware origin and destination routers.
fulafel 4y ago
We had a IPv6 transition mechanism that worked a bit like this (but nicer), it was phased out when native v6 support was deemed widespread enough. https://en.wikipedia.org/wiki/6to4 https://en.wikipedia.org/wiki/6to4
- dqh 4y ago
  Thanks for that. As a transition-to-IP6 technology that makes a lot of sense, but I think it required a lot of prerequisite technology and work (i.e. IP6 itself). The hack I described could have been implemented on top of existing IP4 codebases.
  - fulafel 4y ago
    Sure, we could have had hacks that would have been faster to implement, but there isn't reason to believe it would have helped. The bottleneck was never in the code. Routers and OSes got v6 support ages ago and it's been working in lots of edu & gov networks all over the world for 20+ years. ISPs just haven't been enabling it. Lukewarm deployment incentives for ISPs, lack of pull from device/app makers, etc have been the main problems. Apps adapted to the NAT world quickly, users forgot what capabilities they lost and started to fall into the NAT = security cognitive trap.
    - dqh 4y ago
      > ISPs just haven't been enabling it. It’s a chicken and egg problem. It would have been nice if everybody everywhere agreed to build and use an entirely new network at the same time, but that was never going to be practical. The actual problem at hand was lack of address space, and I think this could have been addressed with a more viable upgrade path - turn every IP4 address into x number of addresses behind it, and allow retail ISPs to remain IP4 only.

by dqh 4y ago

vlovich123 4y ago

What happens when your 4.4 packet hits a router box somewhere out there that doesn’t understand 4.4? Where’s it going to send that packet? To the wrong address (or potentially even create an infinite loop). Now what?

AtlasBarfed 4y ago
I understand what you're saying, but isn't IP supposed to be about routing things around failure points? So routers that "know" IP 4.4 would "know" what routers aren't 4.4.
- vlovich123 4y ago
  By definition you’re trying to retain back compat. So you have a 4.4 source IP address. You try to establish a TCP connection to a legacy IPv4 website that isn’t 4.4 aware. What address is that website sending the response back to? Even if it is 4.4 aware, how do you guarantee it’s taking a path back through 4.4 aware servers? The whole point of adding an option header is to allow unmolested transit through existing IP stacks. If you’re saying you’re routing around them, then you’ve bifurcated the networks and you’re back to IPv6.
  - AtlasBarfed 4y ago
    You're basically doing carrier grade NAT for that, the same thing that is apparently tooootallly acceptable to the ipv6 people for their big success story: mobile. The only success story of ipv6 leads us to the solution: backbone-level CGNAT and other hacks, then impose the economic cost on IPV4-only carriers and endusers.
    - keiyakins 4y ago
      Indeed, your system would require NAT4.44 as a transition mechanism, just like NAT64 is needed now. It gets no benefit over IPv6, and none of the other benefits like SLAAC. So, what's the point? It's no easier to migrate to, and once we're migrated is worse.
      - dqh 4y ago
        If a source behind an IP4.4 router sent a packet to an IP4 destination, then yes, the source router would need to apply NAT to the source address. But this is already a standard IP4 router capability, and I think that most connection origins on the internet are already behind a NAT. I don't agree that it wouldn't have been easier to migrate. No changes would have been needed within retail ISPs for starters. Source code changes to existing IP4 stacks would have been minimal, without requiring a whole new stack like IP6. Practical migration requires only that the source and destination networks be IP4.4 aware. The idea might make less and less sense over time, but if we'd done this 20 years ago we would have reliably had all the address space we needed 10 years ago, no further transition necessary. So much money spent on IP6 could have been saved, not to mention the opportunity cost of IP4 space being hard to get in recent years.
        keiyakins 4y ago
        How would changes not have been required in the ISPs? An IPv4 router wouldn't know what to do with a 4.4 packet. At best, it'd route it to the wrong place - 1.2.3.4.5.6.7.8 and 5.6.7.8 are totally different hosts that may well not even be on the same continent. Additionally, the only reason so much code had to change for ipv6 is that Berkley sockets is a terrible, terrible API that has abstractions so leaky they might as well not exist. Sure, in other APIs (what few exist) low-level code had to be rewritten somewhat, but that's going to be true for any protocol change, because that's kinda what change means.
dqh 4y ago
It routes it as an IP4 packet, because it still is a valid IP4 address. Think of it as a way to let a stateless IP4.4 aware NAT router at the edge join two 32-bit networks together. An IP4.4 client could send a packet to a destination in that network by putting the address of the IP4.4 router in the usual IP4 destination, and the 'internal' IP address in the IP options header. No 'entire Internet update' necessary
dqh 4y ago
> or potentially even create an infinite loop I think that's what TTL is for. Without it, it would be entirely possible to have infinite loops between IP4 networks.

remram 4y ago

"Happily travel" and get to the wrong place? What's the point of that?

dqh 4y ago
Happily traverse the existing IP4 Internet, to an IP4.4 aware edge network. The point is that you don't need to modify any IP4 networks between the IP4.4 aware origin and destination routers.

fulafel 4y ago

We had a IPv6 transition mechanism that worked a bit like this (but nicer), it was phased out when native v6 support was deemed widespread enough. https://en.wikipedia.org/wiki/6to4 https://en.wikipedia.org/wiki/6to4

dqh 4y ago
Thanks for that. As a transition-to-IP6 technology that makes a lot of sense, but I think it required a lot of prerequisite technology and work (i.e. IP6 itself). The hack I described could have been implemented on top of existing IP4 codebases.
- fulafel 4y ago
  Sure, we could have had hacks that would have been faster to implement, but there isn't reason to believe it would have helped. The bottleneck was never in the code. Routers and OSes got v6 support ages ago and it's been working in lots of edu & gov networks all over the world for 20+ years. ISPs just haven't been enabling it. Lukewarm deployment incentives for ISPs, lack of pull from device/app makers, etc have been the main problems. Apps adapted to the NAT world quickly, users forgot what capabilities they lost and started to fall into the NAT = security cognitive trap.
  - dqh 4y ago
    > ISPs just haven't been enabling it. It’s a chicken and egg problem. It would have been nice if everybody everywhere agreed to build and use an entirely new network at the same time, but that was never going to be practical. The actual problem at hand was lack of address space, and I think this could have been addressed with a more viable upgrade path - turn every IP4 address into x number of addresses behind it, and allow retail ISPs to remain IP4 only.