Hacker News new | ask | show | jobs
by cronjobber 3251 days ago
IPv6 could have done three things. First, embed the "legacy" address space. Second, have legacy-to-legacy connections use v4 on the wire. Third, strongly encourage existing user-maintained configuration (config file formats etc.) to remain perfectly valid as long as they don't use v6 addresses (or other v6 features.)

You are right, you'd still need a "legacy" address to connect to "true" v4 servers, but that address would be all you need, while most operating systems, routers, client and server software could be, technically, all-v6 all-the-time by now.

2 comments

> embed the "legacy" address space

They did. Every IPv4 address is in a reserved area of the IPv6 address space.

   a.b.c.d           # v4
   ::FFFF:a.b.c.d    # v6
http://www.tcpipguide.com/free/t_IPv6IPv4AddressEmbedding-2....

> software could be, technically, all-v6 all-the-time by now.

I started using v6 in the late 90s.

Software developed post-2000(-ish) should already be compatible. Unfortunately, there are a lot of developers that think this is hard/impossible (or they are lazy), and so we have software that is defunct by design.

> that address would be all you need

Regardless of how the address was represented, software would still need to be updated.

I stand corrected, RFC 4038 seems to be what I was looking for. But it seems to be a late addition, and OS support is optional. If developers think moving their apps to IPv6 is too complicated, I can't fault them.
> If developers think moving their apps to IPv6 is too complicated, I can't fault them.

I can. I'm a developer and it's easy to add support for IPV6 to apps.

Parsing and displaying IPV6 addresses? There are many libraries and articles for that. Connecting to a host name? Call one function and loop through the list of address structures returned and connect like normal with them skipping the ones that failed. Accepting connections? A little more tricky but since you're writing a server it's not difficult in comparison. The tricky part is figuring out what order you should bind to the socket or if you should use IPV4 mapped addresses.

And if you're using a higher level language or library then it becomes even easier. You just have to worry about the larger size of the address in both binary and text representation if you care about that at all (connecting to a host name you don't have to worry).

The only difficult bit is convincing management it's a good idea to support IPV6. But then the problem shifts from the technical to the political.

> First, embed the "legacy" address space.

What do you mean by that?

> Second, have legacy-to-legacy connections use v4 on the wire.

Just as IPv6 does?

> Third, strongly encourage existing user-maintained configuration (config file formats etc.) to remain perfectly valid as long as they don't use v6 addresses (or other v6 features.)

Just as is the case with IPv6?

> You are right, you'd still need a "legacy" address to connect to "true" v4 servers, but that address would be all you need

Just as it is now?

> while most operating systems, routers, client and server software could be, technically, all-v6 all-the-time by now.

If they implemented the extensions ... just as if they implemented IPv6 by now?