5 ms·

> 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-infrastru

by geocar 11y ago

> 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.

lmm 11y ago
> 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)
- geocar 11y ago
  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.
Arnt 11y ago
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.
- geocar 11y ago
  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.
  - zAy0LfpBZLC8mAC 11y ago
    > 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.
    - geocar 11y ago
      I had a 32 bit AS number almost a decade ago. I'm still waiting for an IPv6 address.
      - scurvy 11y ago
        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.
fulafel 11y ago
This is in fact one of the ipv6 transition mechanisms and was supported by Windows, Cisco, Apple Airports etc. (6to4)
- geocar 11y ago
  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).
  - lmm 11y ago
    > 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)
    - geocar 11y ago
      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.
      - lmm 11y ago
        > 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).
zAy0LfpBZLC8mAC 11y ago
> 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?
api 11y ago
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.
- XorNot 11y ago
  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.
enip 11y ago
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 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.

by geocar 11y ago

lmm 11y ago

> 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)

geocar 11y ago
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.

Arnt 11y ago

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.

geocar 11y ago
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.
- zAy0LfpBZLC8mAC 11y ago
  > 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.
  - geocar 11y ago
    I had a 32 bit AS number almost a decade ago. I'm still waiting for an IPv6 address.
    - scurvy 11y ago
      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.

fulafel 11y ago

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

geocar 11y ago
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).
- lmm 11y ago
  > 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)
  - geocar 11y ago
    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.
    - lmm 11y ago
      > 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).

zAy0LfpBZLC8mAC 11y ago

> 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?

api 11y ago

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.

XorNot 11y ago
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.

enip 11y ago

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 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.