5 ms·

So, what would that magical migration path look like, then?

Asooka 9y ago
For one, all IPv4 addresses could also be IPv6 addresses. There could be a straightforward translation between an IPv4 packet and an IPv6 packet and back just by prepending the address with 0s. You could enable backbone routers to speak only IPv6 and then translate those packets to IPv4 packets only when sending them to the endpoint devices. In short, IPv6 could have been designed as a backwards-compatible extension of IPv4, not a completely new network.
- growse 9y ago
  > For one, all IPv4 addresses could also be IPv6 addresses You mean how you can map from IPv4 addresses to IPv6 addresses? See RFC4291 section 2.5.5. https://www.ietf.org/rfc/rfc4291.txt https://www.ietf.org/rfc/rfc4291.txt
- zAy0LfpBZLC8mAC 9y ago
  > For one, all IPv4 addresses could also be IPv6 addresses. You have that today, all IPv4 addresses are also dualstack addresses, which is how IPv6 is normally deployed for the transition. > There could be a straightforward translation between an IPv4 packet and an IPv6 packet and back just by prepending the address with 0s. Which doesn't help you anything because it doesn't enable IPv4 hosts to communicate with IPv6 hosts. > You could enable backbone routers to speak only IPv6 and then translate those packets to IPv4 packets only when sending them to the endpoint devices. That's called a tunnel, you can have that today. > IPv6 could have been designed as a backwards-compatible extension of IPv4, not a completely new network. What exactly is the backwards compatibility if none of that allows IPv4 and IPv6 hosts to interoperate?
- stephen_g 9y ago
  That still doesn't work though, because an IPv4 host still can't address an IPv6 host, and an IPv4 router still wouldn't be able to route to an IPv6 network (without hacks far uglier than NAT). And they couldn't just upgrade every router in every backhaul network to the new protocol at once (assuming what you describe could actually work) - that took a decade, because lots of it used custom silicon for routing and switching.
- jcranmer 9y ago
  > There could be a straightforward translation between an IPv4 packet and an IPv6 packet and back just by prepending the address with 0s. I'm guessing you're unaware that this is what you do right now. The IPv4 address space has a map in IPv6 at ::ffff:0:0/96 for being able to listen to both IPv4 and IPv6 on an IPv6 address space. There's also a few other different maps of the entire IPv4 address space for other mixed IPv4/IPv6 schemes. The problem with any addressing enhancement to IPv4 is you still have to change every software ever (at the very least, you need to know how to craft new addresses), and you still have to change almost all hardware as well. Maybe you can devise schemes that could let some of the hardware in the middle be IPv6-unaware, but you still have to route the resulting packets to the correct location, which means you'd want to update most of the middle hops anyways.
dangerlibrary 9y ago
Something more like UTF-8? Largely backwards compatible with old formats (ascii) while still being extensible.
- johncolanduoni 9y ago
  The ASCII/UTF-8 backwards compatibility relies on (a) a large subset of data fitting within the constraints of ASCII and (b) most "upstack" applications being able to handle a few garbled/unrecognized characters. How does this map to routing packets on the internet, where the IP header contains time-sensitive metadata needed for delivery and the payload is largely agnostic of the differences?
- zAy0LfpBZLC8mAC 9y ago
  > Something more like UTF-8? Largely backwards compatible with old formats (ascii) while still being extensible. Which would work how exactly in the case of IP? So far sounds mostly like "make it backwards compatible by making it backwards compatible".
  - aexaey 9y ago
    >> Largely backwards compatible > how exactly in the case of IP? For example, introduce two special IP options that would act as "page selector" for source and destination addresses respectively. i.e. SRC: 1.1.1.1, DST: 2.2.2.2, no options -> from 1.1.1.1 to 2.2.2.2 (backwards-compatible packet, classic IPv4) SRC: 1.1.1.1, DST: 2.2.2.2, opt.X: 1.1.1, opt.Y: 2.2.2 -> from 1.1.1.1.1.1.1 to 2.2.2.2.2.2.2 (our faux-IPv6) SRC: 1.1.1.1, DST: 2.2.2.2, opt.X: 0.0.0, opt.Y: 2.2.2 -> from 1.1.1.1 to 2.2.2.2.2.2.2 ("old" address communicating with "new" address) Last example of three is impossible with IPv4/6 dichotomy, and is most important for backward compatibility here - yes, "old" IP holder needs to upgrade their software too[1], but they don't need to get a new IP address, and as a result you don't end up with two isolated "Internets", a.k.a. dual-stack. Say, for ease of processing on router, require that X and Y would appear only together, in that order, preceding other options (which is a bit of an exception as far as IP options go, but again, a backward-compatible one). Now, I'm not proposing this seriously of course, but you asked for example - here you go, a plausible, backwards-compatible "IPv4.1", if you like. [1] All major desktop OS support IPv6 for last 10 years and major mobile OS for last 7. Let's face it - software upgrade turned out (surprisingly) not to be the biggest obstacle.
hn_throwaway_99 9y ago
This post gives a very good explanation of what a sensible transition plan would have looked like. It mainly starts with IPv4 address space being a subset of IPv6, instead of a totally new address space: http://cr.yp.to/djbdns/ipv6mess.html http://cr.yp.to/djbdns/ipv6mess.html
- growse 9y ago
  IPv4 is a subset of IPv6! They literally invented a way to map from an IPv4 address to IPv6 with a special prefix.
  - convolvatron 9y ago
    wth happened with that, in the original proposal it was 96 bits of zero, then that was deprecated, and then they added :ffff:0:0 with the same functionality
    - wyufro 9y ago
      No, they have different functions. Sending to ::1.2.3.4 would send an IPv6-in-IPv4 packet to 1.2.3.4. Using ::ffff:1.2.3.4 tells the OS that you want to send a proper IPv4 packet and no IPv6 is used on the wire. I don't know why the former was deprecated, but I think almost no OS supported it so might've been just that.
      - Avernar 9y ago
        The former was depricated because the automatic tunneling transition method was depricated and none of the current IPV6 transition methods use them. Now some software use those addresses to store IPV4 addresses in the same memory as an IPV6 address.
- dom0 9y ago
  The article itself isn't dated, but for reference Last-Modified: Sat, 02 Aug 2003 14:27:40 GMT

For one, all IPv4 addresses could also be IPv6 addresses. There could be a straightforward translation between an IPv4 packet and an IPv6 packet and back just by prepending the address with 0s. You could enable backbone routers to speak only IPv6 and then translate those packets to IPv4 packets only when sending them to the endpoint devices. In short, IPv6 could have been designed as a backwards-compatible extension of IPv4, not a completely new network.

growse 9y ago
> For one, all IPv4 addresses could also be IPv6 addresses You mean how you can map from IPv4 addresses to IPv6 addresses? See RFC4291 section 2.5.5. https://www.ietf.org/rfc/rfc4291.txt https://www.ietf.org/rfc/rfc4291.txt
zAy0LfpBZLC8mAC 9y ago
> For one, all IPv4 addresses could also be IPv6 addresses. You have that today, all IPv4 addresses are also dualstack addresses, which is how IPv6 is normally deployed for the transition. > There could be a straightforward translation between an IPv4 packet and an IPv6 packet and back just by prepending the address with 0s. Which doesn't help you anything because it doesn't enable IPv4 hosts to communicate with IPv6 hosts. > You could enable backbone routers to speak only IPv6 and then translate those packets to IPv4 packets only when sending them to the endpoint devices. That's called a tunnel, you can have that today. > IPv6 could have been designed as a backwards-compatible extension of IPv4, not a completely new network. What exactly is the backwards compatibility if none of that allows IPv4 and IPv6 hosts to interoperate?
stephen_g 9y ago
That still doesn't work though, because an IPv4 host still can't address an IPv6 host, and an IPv4 router still wouldn't be able to route to an IPv6 network (without hacks far uglier than NAT). And they couldn't just upgrade every router in every backhaul network to the new protocol at once (assuming what you describe could actually work) - that took a decade, because lots of it used custom silicon for routing and switching.
jcranmer 9y ago
> There could be a straightforward translation between an IPv4 packet and an IPv6 packet and back just by prepending the address with 0s. I'm guessing you're unaware that this is what you do right now. The IPv4 address space has a map in IPv6 at ::ffff:0:0/96 for being able to listen to both IPv4 and IPv6 on an IPv6 address space. There's also a few other different maps of the entire IPv4 address space for other mixed IPv4/IPv6 schemes. The problem with any addressing enhancement to IPv4 is you still have to change every software ever (at the very least, you need to know how to craft new addresses), and you still have to change almost all hardware as well. Maybe you can devise schemes that could let some of the hardware in the middle be IPv6-unaware, but you still have to route the resulting packets to the correct location, which means you'd want to update most of the middle hops anyways.

dangerlibrary 9y ago

Something more like UTF-8? Largely backwards compatible with old formats (ascii) while still being extensible.

johncolanduoni 9y ago
The ASCII/UTF-8 backwards compatibility relies on (a) a large subset of data fitting within the constraints of ASCII and (b) most "upstack" applications being able to handle a few garbled/unrecognized characters. How does this map to routing packets on the internet, where the IP header contains time-sensitive metadata needed for delivery and the payload is largely agnostic of the differences?
zAy0LfpBZLC8mAC 9y ago
> Something more like UTF-8? Largely backwards compatible with old formats (ascii) while still being extensible. Which would work how exactly in the case of IP? So far sounds mostly like "make it backwards compatible by making it backwards compatible".
- aexaey 9y ago
  >> Largely backwards compatible > how exactly in the case of IP? For example, introduce two special IP options that would act as "page selector" for source and destination addresses respectively. i.e. SRC: 1.1.1.1, DST: 2.2.2.2, no options -> from 1.1.1.1 to 2.2.2.2 (backwards-compatible packet, classic IPv4) SRC: 1.1.1.1, DST: 2.2.2.2, opt.X: 1.1.1, opt.Y: 2.2.2 -> from 1.1.1.1.1.1.1 to 2.2.2.2.2.2.2 (our faux-IPv6) SRC: 1.1.1.1, DST: 2.2.2.2, opt.X: 0.0.0, opt.Y: 2.2.2 -> from 1.1.1.1 to 2.2.2.2.2.2.2 ("old" address communicating with "new" address) Last example of three is impossible with IPv4/6 dichotomy, and is most important for backward compatibility here - yes, "old" IP holder needs to upgrade their software too[1], but they don't need to get a new IP address, and as a result you don't end up with two isolated "Internets", a.k.a. dual-stack. Say, for ease of processing on router, require that X and Y would appear only together, in that order, preceding other options (which is a bit of an exception as far as IP options go, but again, a backward-compatible one). Now, I'm not proposing this seriously of course, but you asked for example - here you go, a plausible, backwards-compatible "IPv4.1", if you like. [1] All major desktop OS support IPv6 for last 10 years and major mobile OS for last 7. Let's face it - software upgrade turned out (surprisingly) not to be the biggest obstacle.

hn_throwaway_99 9y ago

This post gives a very good explanation of what a sensible transition plan would have looked like. It mainly starts with IPv4 address space being a subset of IPv6, instead of a totally new address space: http://cr.yp.to/djbdns/ipv6mess.html http://cr.yp.to/djbdns/ipv6mess.html

growse 9y ago
IPv4 is a subset of IPv6! They literally invented a way to map from an IPv4 address to IPv6 with a special prefix.
- convolvatron 9y ago
  wth happened with that, in the original proposal it was 96 bits of zero, then that was deprecated, and then they added :ffff:0:0 with the same functionality
  - wyufro 9y ago
    No, they have different functions. Sending to ::1.2.3.4 would send an IPv6-in-IPv4 packet to 1.2.3.4. Using ::ffff:1.2.3.4 tells the OS that you want to send a proper IPv4 packet and no IPv6 is used on the wire. I don't know why the former was deprecated, but I think almost no OS supported it so might've been just that.
    - Avernar 9y ago
      The former was depricated because the automatic tunneling transition method was depricated and none of the current IPV6 transition methods use them. Now some software use those addresses to store IPV4 addresses in the same memory as an IPV6 address.
dom0 9y ago
The article itself isn't dated, but for reference Last-Modified: Sat, 02 Aug 2003 14:27:40 GMT