Hacker News Reader

Comment by zAy0LfpBZLC8mAC | Hacker News Reader

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

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

When you work out the details of DJB's "plan" you discover that it's just as messy as IPv6, maybe worse. http://archive.is/eHvKF

IPv4 is a subset of IPv6! They literally invented a way to map from an IPv4 address to IPv6 with a special prefix.

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

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.

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.

The article itself isn't dated, but for reference

Last-Modified: Sat, 02 Aug 2003 14:27:40 GMT

The old date of the article kind of proves my point. It's 14 years later, and we still get huge HN threads around the very-incomplete state of IPv6 transition.

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.

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

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.

> 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

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

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

The ASCII->UTF-8 transition is arguably nearly as painful as IPv4->IPv6, and it's still nowhere near complete.

Switching to UTF-8 requires two major steps. The first was making software and interchange systems preserve the 8th bit (it used to be commonly used as a parity bit). For email, this was true only about the mid-to-late 90s--surprisingly recent. The second step, which is still incomplete today, is letting control mechanisms that used to speak only ASCII understand UTF-8 (or something else non-ASCII) reliably. You could only put UTF-8 in C++ or C code as of C++11/C11, for example. Non-ASCII domain names are still problematic, to say nothing of non-ASCII email addresses. In other words, trying to speak UTF-8 to someone who only speaks ASCII is still as problematic as trying to speak IPv6 to someone who only speaks IPv4. We just don't notice it as much because we keep advising people to only speak ASCII in key places.

> For email, this was true only about the mid-to-late 90s--surprisingly recent.

Actually, email still is not nominally 8-bit transparent (ESMTP 8BITMIME is optional and not supported by all MTAs), but it doesn't need to be, that's what quoted-printable and base64 are for.

The timeframe I'm using is the timeframe where you stop seeing servers mangle 8-bit email. 8BITMIME technically requires converting 8-bit bodies to QP and base64, which is generally not necessary nowadays, and some would argue that software that chooses not to implement that shouldn't advertise 8BITMIME.

> and some would argue that software that chooses not to implement that shouldn't advertise 8BITMIME.

Which is why I wrote that email still nominally isn't 8-bit clean :-)

Yes, in practice, you won't find an MTA that doesn't leave your 8 bit data unharmed, but you do find MTAs that don't advertise 8BITMIME, and so nominally noone should send them 8 bit data ... except everyone does anyway, of course ...

One of major blockers of UTF-8 transition is Windows world - the operating system itself, who stubbornly stuck with not even complete UTF-16 support, and also a big amount of software for this OS family without the proper UTF-8 compatibility.

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?

Except UFT8 is not backwards compatible with ASCII!

An application written to only understand ASCII will not print non-ASCII UTF-8 characters. That is what you are asking here. It can't be done with ASCII/UTF8. It can't be done with IPv4/IPv6.

UTF8 is backward compatible with ASCII just fine - latter is a strict subset of former. It doesn't get more backward-compatible than that!

IPv6, on the other hand, is not at all backward compatible with IPv4 (was never a design goal - magic of OSI stack was supposed to do it's thing). One would argue that incompatibility is in large part responsible for the 6's slow start - even though afterthought bolt-ons eventually did see sunlight - ::ffff:x.x.x.x thing, cornucopia of tunnels and dual-stacks of various degree lite-ness, etc.

... which means that if of two parties only one understand UTF-8, they have to speak ASCII. ASCII being a subset of UTF-8 does not provide and benefit in that regard, just as IPv4 addresses being a subset of IPv6 addresses wouldn't.

Let me drill down it for you:

Imagine two endpoints talking a backward compatible pair of standards: A only speaks ASCII, B only speaks UTF-8. Would you think they will be able to communicate at least something?

Now imagine two endpoints talking a not backward compatible pair: A only speaks IPv4, and B only speaks IPv6. Will they be able to communicate, at least something?

See the difference?

> Imagine two endpoints talking a backward compatible pair of standards: A only speaks ASCII, B only speaks UTF-8. Would you think they will be able to communicate at least something?

As long as they only speak ASCII, yes.

> Now imagine two endpoints talking a not backward compatible pair: A only speaks IPv4, and B only speaks IPv6. Will they be able to communicate, at least something?

That's why you deploy IPv6 dual-stacked with IPv4. That way, if two parties only speak IPv4, it's completely backwards compatible.

> See the difference?

Sure do I see the difference. What I don't see is how to apply any of that to the v4 to v6 transition in a way that would have any advantage over how it is being done now.

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

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

What advantage does that have over IPv6? From a backwards-compatibility perspective, it seems identical.

In order for two hosts to communicate over IPv6, both ends need to have: software that supports IPv6, and the entire network path between them needs to be able to route IPv6 packets. Your proposal is functionally no different: you call the extended address field an "option", but in fact every host is required to understand it.

I used term "options" here the way it was defined in RFC 791. [1] It's a standard way to extend IPv4 packet header.

[1] https://tools.ietf.org/html/rfc791

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

1. What would be a scenario where hosts using this mechanism could communicate where neither IPv4 nor IPv6 would work?

2. How do new internet participants get addresses under your scheme, if it only expands the number of addresses in existing allocations?

Reply on news.ycombinator.com