4 ms·

There was a third option: make the existing IPv4 space a hierarchically routed island of the new IPv4.1 space, with backwards compatible packet format, then upg

There was a third option: make the existing IPv4 space a hierarchically routed island of the new IPv4.1 space, with backwards compatible packet format, then upgrade just the endpoints in the first phase. So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure. So, if the endpoints are upgraded, you have guaranteed end-to-end deliverability without silly hacks such as NAT or STUN. This doesn't solve the "backwards compatibility" problem itself, because you still have two logical different IP networks running on top of each other, requiring separate name resolution, etc. But what it does solve is the "incentive problem": endpoints are incentivized to upgrade because it gives them an immediate benefit, end-to-end connectivity to other upgraded users with non-routable addresses sitting behind a dumb, non-upgraded IPv4 routers. For example, VoIP or P2P software would immediately benefit and it would drive adoption for an immediate use-case. In the later stage, when the entire infrastructure can understand the extended packet format, you would start to publish extended routes that don't fall into the hierarchical range, similar to IPv6 today. IPv6 lacks any such incentive, because me upgrading and enabling it has zero benefits until all hops separating me from the internet also enable it and correctly configure it. On the contrary, by requiring a completely new, complex configuration with no "default, just works" mode, IPv6 introduces a disincentive, because by enabling it not only do I not gain anything, but I risk breaking my internet due to misconfigured upstream. So the conservative setting for IpV6 has, for the last 3 decades, remained "off". This only recently began to change.

gabereiser 3y ago
>”So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure.” So… NAT.
- cornholio 3y ago
  No. There would be no NAT box holding IP-port mappings in its internal memory, with the related timeouts, flakiness, port clobbering etc. and no packet re-writing. All routing decisions would be static, based on information in the IP header: the legacy outside routers would just examine the legacy part of the IP address and packet, while the internal IPv4.1 would use the extended bits. So just like any packet routing and without translation. Critically, this solves the cold start and connectability problem of NAT: if you get a packet addressed to your outside IP, to a port that has no memorized mapping, to what internal IP do you send it to? Lacking a static or UPnP port assignment, it can only be dropped. The extended packet format would provide this information for every packet, the upgraded outside host would tell you what upgraded internal host it wants to talk to.
  - thelastparadise 3y ago
    It sounds nice on paper but typically we don't want unsolicited packets to reach internal hosts. Yes, NAT is not a firewall --yet we don't see admins eager to put random lan hosts in the DMZ or enable UPnP.
    - throw0101c 3y ago
      This is solved by statefulness: the router/firewall can be told to drop by default any unsolicited connections. It's how things work with IPv6, which doesn't have NAT (by default): just because a host has a globally routable address does not mean it is reachable by default.
    - GoblinSlayer 3y ago
      Is UPnP really unsolicited?
    - cornholio 3y ago
      You won't have the "NAT as a firewall" dilemma because there would be no NAT - this whole thought experiment would take place in the 1996 era, before the explosion of NATs. Expecting your /32 gateway to do any firewalling wouldn't be too different from expecting your ISP to do the same for the entire city at the /18 level.
- dtech 3y ago
  Not really, since in this proposal you'd still have the end-to-end routability that NAT prevents
rewmie 3y ago
> There was a third option: make the existing IPv4 space a hierarchically routed island of the new IPv4.1 space, with backwards compatible packet format, then upgrade just the endpoints in the first phase. Do you mean applying some kind of network address translation? > So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure. So, if the endpoints are upgraded, you have guaranteed end-to-end deliverability without silly hacks such as NAT or STUN. Ahem.
welterde 3y ago
You can tunnel IPv6 over IPv4 (which is how the very first deployments worked). And I think 6to4/6rd worked pretty to close to what you suggest: Each IPv4 gets assigned a block of IPv6 space which gets tunneled over IPv4.
- cornholio 3y ago
  > I think 6to4/6rd worked pretty to close to what you suggest: Each IPv4 gets assigned a block of IPv6 space which gets tunneled over IPv4 No. Tunnels encapsulate IPv6 traffic but they need to be set up, I need to know a gateway that is willing to take my traffic, decapsulate it and place it on the IPv6 internet. There are many reasons this is bad idea, it won't ever scale, it's fragile etc. 6rd doesn't improve things significantly. A backwards compatible packet format will allow you to connect directly to IPv4.1 islands, without any configuration or choke point: the packets you place on the wire have the final extended structure, even if they appear as encapsulation to the legacy IPv4 hosts in the path. It's as if any IPv6 host on the internet is guaranteed to have its own 6to4 gateway, and the encapsulation just happens to be the exact IPv6 packet / IPv4 compatible structure that you use to connect to any other non-gatewayed host.
  - welterde 3y ago
    Windows actually used to have 6to4 setup by default in the past. There is no need to manually configure anything since the 6to4 have a globally unique anycast address and the ipv6 space is just derived from the own IP address. Of course NAT breaks that if used on some box behind the router (also would break your proposal I think?) and there were a few issues with 6to4 (random people running gateways? who deals with abuse?) that lead to the development of 6rd (and which was used by a few fairly large ISPs).
azernik 3y ago
This is exactly how NAT64 works, and still doesn't solve the problem of IPv4 clients trying to connect to servers with only IPv6 addresses. The backwards incompatibility is irreducible, inherent to the special place of Layer 3 in the networking stack.
- throw0101c 3y ago
  > This is exactly how NAT64 works, and still doesn't solve the problem of IPv4 clients trying to connect to servers with only IPv6 addresses. You also have to deploy new DNS code to handle a new record type to handle longer "IPv4+" addresses. You also have to deploy new OS and library code with new socket, etc, APIs because all in_addr_t definitions and data structures are 32-bit-only.
  - GoblinSlayer 3y ago
    AFAIK, IPv6 adoption is held back by hardware. My ISP doesn't provide IPv6, but its DNS provides IPv6 addresses just fine.
    - azernik 3y ago
      Any hardware router introduced in the last two decades has IPv6 support; in my somewhat outdated experience the barrier to implementation is implementing dual-stack logic in software built for single stack.
    - janc_ 3y ago
      ISPs in Belgium implemented IPv6 a decade ago (some even two decades). ISPs elsewhere could have done it too by now (nobody is still using 10+yo hardware, I hope...).
    - throw0101c 3y ago
      > AFAIK, IPv6 adoption is held back by hardware. What hardware, especially ASICs, do not support wire speed IPv6 and have not for a decade or two? T-Mobile was gave a presentation on going IPv6-only in 2017: > For the past 10 years T-Mobile has worked towards creating an IPv6 environment and we are now getting very close to our goal. Stephan presents learning on how to successfully enable IPv6-only using DNS64 with or without 464XLAT. He will do a live demo of the different IP interfaces on an Android handset. Finally, he will discuss and give some best practices on how to handle DNS, applications, and websites that are having issues with DNS64. * https://www.youtube.com/watch?v=nNMNglk_CvE https://www.youtube.com/watch?v=nNMNglk_CvE So they started in 2007. Whatever ISP you're with has probably had at least 2-3 tech refreshes in which IPv6 hardware has been available. For the CPE, Free in France had IPv6 in 2007: * https://en.wikipedia.org/wiki/IPv6_rapid_deployment https://en.wikipedia.org/wiki/IPv6_rapid_deployment
ilyt 3y ago
> There was a third option: make the existing IPv4 space a hierarchically routed island of the new IPv4.1 space, with backwards compatible packet format, then upgrade just the endpoints in the first phase. That is called DS-Lite and we have it Still doesn't solve a problem of old clients not being able to access new servers
- cornholio 3y ago
  > That is called DS-Lite and we have it No. DS lite is a technology that allows the ISPs to upgrade to IPv6 while their clients do not. This is not the problem preventing IPv6 adoption, quite the contrary, clients support IPv6 from the Windows 2000 and Linux 2.1 era. What held back adoption is precisely that most ISPs don't bother with IPv6, which is an extra headache in configuration and man hours, as long as it provides no benefit to the end user. The beauty of a backwards compatible packet format is that it takes the last mile ISP completely out of the equation, clients upgrade when they see benefits, and instantly get end-to-end connectivity. This is important for VoIP, push to mobiles etc. > Still doesn't solve a problem of old clients not being able to access new servers See sibling comment on why this is not the right problem to solve either.
deleted 3y ago
[deleted]

gabereiser 3y ago

>”So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure.” So… NAT.

cornholio 3y ago
No. There would be no NAT box holding IP-port mappings in its internal memory, with the related timeouts, flakiness, port clobbering etc. and no packet re-writing. All routing decisions would be static, based on information in the IP header: the legacy outside routers would just examine the legacy part of the IP address and packet, while the internal IPv4.1 would use the extended bits. So just like any packet routing and without translation. Critically, this solves the cold start and connectability problem of NAT: if you get a packet addressed to your outside IP, to a port that has no memorized mapping, to what internal IP do you send it to? Lacking a static or UPnP port assignment, it can only be dropped. The extended packet format would provide this information for every packet, the upgraded outside host would tell you what upgraded internal host it wants to talk to.
- thelastparadise 3y ago
  It sounds nice on paper but typically we don't want unsolicited packets to reach internal hosts. Yes, NAT is not a firewall --yet we don't see admins eager to put random lan hosts in the DMZ or enable UPnP.
  - throw0101c 3y ago
    This is solved by statefulness: the router/firewall can be told to drop by default any unsolicited connections. It's how things work with IPv6, which doesn't have NAT (by default): just because a host has a globally routable address does not mean it is reachable by default.
  - GoblinSlayer 3y ago
    Is UPnP really unsolicited?
  - cornholio 3y ago
    You won't have the "NAT as a firewall" dilemma because there would be no NAT - this whole thought experiment would take place in the 1996 era, before the explosion of NATs. Expecting your /32 gateway to do any firewalling wouldn't be too different from expecting your ISP to do the same for the entire city at the /18 level.
dtech 3y ago
Not really, since in this proposal you'd still have the end-to-end routability that NAT prevents

rewmie 3y ago

> There was a third option: make the existing IPv4 space a hierarchically routed island of the new IPv4.1 space, with backwards compatible packet format, then upgrade just the endpoints in the first phase. Do you mean applying some kind of network address translation? > So every owner of a ipv4 would get, say, an entire 32 bit space that routes over existing IPv4 infrastructure. So, if the endpoints are upgraded, you have guaranteed end-to-end deliverability without silly hacks such as NAT or STUN. Ahem.

welterde 3y ago

You can tunnel IPv6 over IPv4 (which is how the very first deployments worked). And I think 6to4/6rd worked pretty to close to what you suggest: Each IPv4 gets assigned a block of IPv6 space which gets tunneled over IPv4.

cornholio 3y ago
> I think 6to4/6rd worked pretty to close to what you suggest: Each IPv4 gets assigned a block of IPv6 space which gets tunneled over IPv4 No. Tunnels encapsulate IPv6 traffic but they need to be set up, I need to know a gateway that is willing to take my traffic, decapsulate it and place it on the IPv6 internet. There are many reasons this is bad idea, it won't ever scale, it's fragile etc. 6rd doesn't improve things significantly. A backwards compatible packet format will allow you to connect directly to IPv4.1 islands, without any configuration or choke point: the packets you place on the wire have the final extended structure, even if they appear as encapsulation to the legacy IPv4 hosts in the path. It's as if any IPv6 host on the internet is guaranteed to have its own 6to4 gateway, and the encapsulation just happens to be the exact IPv6 packet / IPv4 compatible structure that you use to connect to any other non-gatewayed host.
- welterde 3y ago
  Windows actually used to have 6to4 setup by default in the past. There is no need to manually configure anything since the 6to4 have a globally unique anycast address and the ipv6 space is just derived from the own IP address. Of course NAT breaks that if used on some box behind the router (also would break your proposal I think?) and there were a few issues with 6to4 (random people running gateways? who deals with abuse?) that lead to the development of 6rd (and which was used by a few fairly large ISPs).

azernik 3y ago

This is exactly how NAT64 works, and still doesn't solve the problem of IPv4 clients trying to connect to servers with only IPv6 addresses. The backwards incompatibility is irreducible, inherent to the special place of Layer 3 in the networking stack.

throw0101c 3y ago
> This is exactly how NAT64 works, and still doesn't solve the problem of IPv4 clients trying to connect to servers with only IPv6 addresses. You also have to deploy new DNS code to handle a new record type to handle longer "IPv4+" addresses. You also have to deploy new OS and library code with new socket, etc, APIs because all in_addr_t definitions and data structures are 32-bit-only.
- GoblinSlayer 3y ago
  AFAIK, IPv6 adoption is held back by hardware. My ISP doesn't provide IPv6, but its DNS provides IPv6 addresses just fine.
  - azernik 3y ago
    Any hardware router introduced in the last two decades has IPv6 support; in my somewhat outdated experience the barrier to implementation is implementing dual-stack logic in software built for single stack.
  - janc_ 3y ago
    ISPs in Belgium implemented IPv6 a decade ago (some even two decades). ISPs elsewhere could have done it too by now (nobody is still using 10+yo hardware, I hope...).
  - throw0101c 3y ago
    > AFAIK, IPv6 adoption is held back by hardware. What hardware, especially ASICs, do not support wire speed IPv6 and have not for a decade or two? T-Mobile was gave a presentation on going IPv6-only in 2017: > For the past 10 years T-Mobile has worked towards creating an IPv6 environment and we are now getting very close to our goal. Stephan presents learning on how to successfully enable IPv6-only using DNS64 with or without 464XLAT. He will do a live demo of the different IP interfaces on an Android handset. Finally, he will discuss and give some best practices on how to handle DNS, applications, and websites that are having issues with DNS64. * https://www.youtube.com/watch?v=nNMNglk_CvE https://www.youtube.com/watch?v=nNMNglk_CvE So they started in 2007. Whatever ISP you're with has probably had at least 2-3 tech refreshes in which IPv6 hardware has been available. For the CPE, Free in France had IPv6 in 2007: * https://en.wikipedia.org/wiki/IPv6_rapid_deployment https://en.wikipedia.org/wiki/IPv6_rapid_deployment

ilyt 3y ago

cornholio 3y ago
> That is called DS-Lite and we have it No. DS lite is a technology that allows the ISPs to upgrade to IPv6 while their clients do not. This is not the problem preventing IPv6 adoption, quite the contrary, clients support IPv6 from the Windows 2000 and Linux 2.1 era. What held back adoption is precisely that most ISPs don't bother with IPv6, which is an extra headache in configuration and man hours, as long as it provides no benefit to the end user. The beauty of a backwards compatible packet format is that it takes the last mile ISP completely out of the equation, clients upgrade when they see benefits, and instantly get end-to-end connectivity. This is important for VoIP, push to mobiles etc. > Still doesn't solve a problem of old clients not being able to access new servers See sibling comment on why this is not the right problem to solve either.

deleted 3y ago

[deleted]