IPv4 in IPv6 in AAAA records

[Phil Howard]

On Tue, Aug 24, 2004 at 07:33:07PM +0100, Colm MacCarthaigh wrote:

| ::ffff/96 is a host-level only mechanism, it will really really confuse
| your applications if they see it coming on the wire. Say you have an
| application listening on ::, it gets a packet on ::ffff:192.168.0.1 ,
| how does it know that wasn't an IPv4 packet that came in and was
| translated by the hosts stack?
| 
| It's a bad bad idea. ::ffff/96 isn't some arbitrary handy way of
| representing IPv4 address in IPv6, it's a transistion mechanism. Please
| use it properly, the last thing we need is people deploying IPv6
| brokenness and getting the protocol a bad rep :)

I'm making the information available on DNS for anyone wanting to
translate.

Presumably an application that queries for AAAA records and gets one
with ::ffff:209.102.192.73 will do one of:

1.  not treat ::ffff special and just bind() an AF_INET6 address as
    usual, and the OS net stack will map it in some way so IPv4 is
    used on that socket

2.  recognize ::ffff and extract the IPv4 part and just bind() the
    AF_INET address.

3.  recognize ::ffff and refuse to deal with it.

What the OS could do with ::ffff is:

1.  Leave the socket with domain PF_INET6 but still do IPv4 out to the
    net, hiding this fact from the application.

2.  Change the socket domain to PF_INET.  But this might cause breakage.

3.  Disregard ::ffff specially and just send ::ffff out the wire in the
    hopes that it is translated to something routable before it reaches
    the border where it can't be routed anywhere.  A router can then
    translate like any NAT.

Once one has IPv6 address space, which will most likely be at least the
size of a /96, they can use a router that translates their /128 or /96
address prefix to an IPv4 address on the LAN for a host that only know
IPv4.  Traffic going back will have to translated from saved state since
the IPv6-unaware machine won't know the IPv6 address of what connected
to it.  Originating connections from an IPv4-only machine when the
connectivity is IPv6-only is left up to the readers.

But I do not expect any host to try to reach my hosts by literally
using a ::ffff address ... I expect it to be translated to IPv4 before
it reaches the outside wire (and this may happen in the machine just
as well).


| But back on-topic ...
| 
| > But in nsd-users, the on-topic issue is whether ::ffff should be
| > supported in AAAA records ... specifically with dotted-quad-suffix
| > syntax.  
| 
| No, ::ffff should not be treated more specially than any other 
| /96 by NSD. A DNS implementation should be agnostic to the content
| of an AAAA record. 
| 
| NSD should (and now does afaict) however support the dotted-quad
| representation for the last 32-bits, for any AAAA record. So if I want
| to have 2001:770:18:2::193.1.193.194, I can :)

With the patch posted earlier, it should.  I haven't tested.


| dotted-quad syntax has to be supported, I don't think that can be
| disputed :)

OK.  And use of ::ffff is topic for some other area.

-- 
-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------