?

Log in

No account? Create an account

IPv6 addressing oddity - Journal of Omnifarious

Sep. 8th, 2009

01:11 am - IPv6 addressing oddity

Previous Entry Share Next Entry

I've noticed an interesting oddity in IPv6 addressing...

::ffff:n.n.n.n refers to IPv4 only hosts so that a program written for IPv6 only and running on a dual stack machine can address IPv4 only hosts. There is another class of address that is similar, but not quite the same, and I don't actually understand when it would ever be used, and that class is called "IPv4 compatible IPv6 addresses" and they are of the form ::n.n.n.n.

Interestingly the IPv6 IN6ADDR_ANY address is ::, which is equivalent to ::0.0.0.0. Fortunately, the IPv4 INADDR_ANY address is 0.0.0.0 (also known as 'this host on this network' in the 'Special Addresses' section of RFC 1700) so there doesn't seem to be any real problem.

And finally, the real problem. The IPv6 equivalent of localhost or IPv4's 127.0.0.1 is ::1, and this is equivalent to ::0.0.0.1 which makes it an 'IPv4 compatible IPv6 address'. But the IPv4 address it maps to is, according to RFC 1700, some kind of local identifier for a host on a network. That seems like an odd conflict and inconsistency to me, and I'm not really sure what it means.

Of course, I've never seen any addresses in the 0.0.0.0/8 block be used at all aside from 0.0.0.0 itself, so it's likely not a real problem. But I'm still curious.

Edit 16:36: I have the answer. According to RFC 4291 section 2.5.5.1 meaning of ::n.n.n.n addresses as 'IPv4 compatible IPv6 address' is deprecated so there is no longer any overlap in meaning between the special IPv6 addresses ::1 and :: and any IPv4 address.

Well, that was the right decision, the distinction between ::ffff:n.n.n.n addresses and ::n.n.n.n addresses was confusing and unclear anyway.

Current Location: 2237 NW 62nd ST, 98107
Current Mood: [mood icon] curious

Comments:

[User Picture]
From:zanfur
Date:September 8th, 2009 04:33 pm (UTC)
(Link)
In IPv4, the "all-zeros" network of any size (0.0.0.0/n) means "this network". So, for an interface on the 192.0.2.0/24 network (which is the official "example" network, btw), "0.0.0.1" refers to 192.0.2.1. Similarly, it would refer to 10.0.0.1 on an interface on the 10.0/12 network (or 10.0/16, or 10/8, or 10.0.0/24...).

It's pretty much completely deprecated and unused. I haven't ever seen it in use, I just learned that reading RFC's randomly one day. It's not a valid format in linux, and windows doesn't recognize it (although it will allow you to attempt to connect, while linux throws an "invalid argument" with that IP address).
(Reply) (Thread)
[User Picture]
From:omnifarious
Date:September 8th, 2009 05:11 pm (UTC)

Thanks!

(Link)

So, like IPv6's link-local addresses, except more like 'subnet local' which isn't exactly the same thing. And without even the nearly essential feature of being auto-assigned. *chuckle* I suppose it seemed like a good idea at the time.

RFC 1700 isn't very clear on exactly what it means and doesn't provide any helpful pointers to other RFCs. But that interpretation makes perfect sense given what RFC 1700 does say.

It does then seem like the fact that ::1 and 0.0.0.1 have overlapping and conflicting meanings is largely harmless.

One thing that irritates me is that this failed experiment now chews up 16 million potentially useful IP addresses, and the philosophy behind it also chews up the low IP of any subnet as well.

I still think Trabant should assign 6to4 addresses to all the nodes on its network. :-)

(Reply) (Parent) (Thread)
[User Picture]
From:omnifarious
Date:September 8th, 2009 11:45 pm (UTC)

I found the answer to my question

(Link)

I found the answer to my question and I edited my journal entry to state it.

(Reply) (Parent) (Thread)