IPv4 in IPv6 in AAAA records

NSD
1

I'm not sure where this syntax originates (maybe an RFC, I haven't looked).
But BIND and earlier NSD accepted an IPv6 format where the low order 32 bits
could be written in dotted decimal, at least if the high order 96 bits had
the value (in IPv6 form) ::FFFF. So I could write an AAAA record like:

ham.org. 12H IN AAAA ::FFFF:209.102.192.73

which would actually be the same as:

ham.org. 12H IN AAAA ::FFFF:D166:C049

It's just a slight convenience to have this. I was just wondering if this
is supposed to be in there or not. When I upgraded to 2.1.2 from a pre-2
version, those records like the first one above became syntax errors, while
those like the second one worked OK.

2

[On 23 Aug, @08:31, Phil wrote in "IPv4 in IPv6 in AAAA records ..."]

I'm not sure where this syntax originates (maybe an RFC, I haven't looked).
But BIND and earlier NSD accepted an IPv6 format where the low order 32 bits
could be written in dotted decimal, at least if the high order 96 bits had
the value (in IPv6 form) ::FFFF. So I could write an AAAA record like:

ham.org. 12H IN AAAA ::FFFF:209.102.192.73

which would actually be the same as:

ham.org. 12H IN AAAA ::FFFF:D166:C049

It's just a slight convenience to have this. I was just wondering if this

I think it's in the RFC to allow this, so it should be added to zonec.

But just to satisfy my own curiosity. Why do you need this?

is supposed to be in there or not. When I upgraded to 2.1.2 from a pre-2
version, those records like the first one above became syntax errors, while
those like the second one worked OK.

this is an extra reason to fix this,

grtz Miek

3

[On 23 Aug, @ 08:31, Phil wrote in "IPv4 in IPv6 in AAAA records ..."]

ham.org. 12H IN AAAA ::FFFF:D166:C049

It's just a slight convenience to have this. I was just wondering if this

the following patch restores this behavior.

Regards,
Miek

=-=-=-=-=-= begin patch =-=-=-=-=-=
Index: RELNOTES

4

::ffff/96 is the IPv4-mapped-IPv6 address prefix, it's intended use is
to allow an IPv6 stack to forward IPv4 packets to an IPv6-listening
service (for example NSD listening on :: on Linux will see packets
from 193.1.193.194 as ::ffff:193.1.193.194).

There is also the IPv4-compatible-IPv6 address prefix, ::/96 and
addresses look like: ::193.1.193.194. Using either in AAAA records
is a *really* terrible idea.

This is still a bug in NSD though, as the IPv6 standards allow for the
low order 32 bits to be represented as dotted quads for any address, for
example:

  colmmacccc@byron:~$ ping6 2001:770:18:2:206:5bff:254.63.170.218
  PING 2001:770:18:2:206:5bff:254.63.170.218(2001:770:18:2:206:5bff:fe3f:aada) from ::1 : 56 data bytes
  64 bytes from 2001:770:18:2:206:5bff:fe3f:aada: icmp_seq=1 ttl=64 time=0.066 ms

c.f. Appendix B to RFC2373

5

::ffff/96 is the IPv4-mapped-IPv6 address prefix, it's intended use is
to allow an IPv6 stack to forward IPv4 packets to an IPv6-listening
service (for example NSD listening on :: on Linux will see packets
from 193.1.193.194 as ::ffff:193.1.193.194).

  IPv4 mapped address is an internal representation of IPv4 node (peer)
  on a host operating system. it should not appear on DNS database.

itojun

6

[On 23 Aug, @ 10:48, Colm wrote in "Re: IPv4 in IPv6 in AAAA recor ..."]

This is still a bug in NSD though, as the IPv6 standards allow for the
low order 32 bits to be represented as dotted quads for any address, for
example:

  colmmacccc@byron:~$ ping6 2001:770:18:2:206:5bff:254.63.170.218
  PING 2001:770:18:2:206:5bff:254.63.170.218(2001:770:18:2:206:5bff:fe3f:aada) from ::1 : 56 data bytes
  64 bytes from 2001:770:18:2:206:5bff:fe3f:aada: icmp_seq=1 ttl=64 time=0.066 ms

c.f. Appendix B to RFC2373

note that 2373 has been obsoleted by 3513, but 3513 still allows this
syntax. (See http://rfc.net/rfc3513.html#s2.2)

grtz Miek

7

Exactly, what he said.

8

[On 23 Aug, @08:31, Phil wrote in "IPv4 in IPv6 in AAAA records ..."]
> I'm not sure where this syntax originates (maybe an RFC, I haven't looked).
> But BIND and earlier NSD accepted an IPv6 format where the low order 32 bits
> could be written in dotted decimal, at least if the high order 96 bits had
> the value (in IPv6 form) ::FFFF. So I could write an AAAA record like:
>
> ham.org. 12H IN AAAA ::FFFF:209.102.192.73
>
> which would actually be the same as:
>
> ham.org. 12H IN AAAA ::FFFF:D166:C049
>
> It's just a slight convenience to have this. I was just wondering if this

I think it's in the RFC to allow this, so it should be added to zonec.

But just to satisfy my own curiosity. Why do you need this?

I generate my zone files by means of scripts sourced from other kinds of
data I set up in slightly more abstract ways. For example that data might
specify that a given web domain is hosted on a given server name and has
mail. It will generate A records instead of CNAME records by getting the
IP address of the server the domain is hosted on. It generates both the
name without "www." and with. It generates the MX record appropriately as
well. I also have an "v4inv6" option which generates AAAA records from the
IPv4 IP addresses like "::FFFF:${ipv4addr}".

I have since made a tool I can use my scripts to generate the normal IPv6
hexadecimal format for those, so I no longer need that support in zonec.
But for consistency, others may want it as more IPv6 is deployed. I just
don't know all that parser stuff so I had no hope of implementing such a
fix myself.

> is supposed to be in there or not. When I upgraded to 2.1.2 from a pre-2
> version, those records like the first one above became syntax errors, while
> those like the second one worked OK.

this is an extra reason to fix this,

I suppose. Like I say, I now have a shell tool (a program in C) that does
the conversion, so I have no urgent need. But others might; I just seem
to be the first to raise it.

9

There is also the IPv4-compatible-IPv6 address prefix, ::/96 and
addresses look like: ::193.1.193.194. Using either in AAAA records
is a *really* terrible idea.

Could you provide me with more enlightenment on this? If applicable
to the list topic, post here. If not applicable to the list topic,
you can reply privately by removing "-nsd-users" from my email address.

This is still a bug in NSD though, as the IPv6 standards allow for the
low order 32 bits to be represented as dotted quads for any address, for
example:

  colmmacccc@byron:~$ ping6 2001:770:18:2:206:5bff:254.63.170.218
  PING 2001:770:18:2:206:5bff:254.63.170.218(2001:770:18:2:206:5bff:fe3f:aada) from ::1 : 56 data bytes
  64 bytes from 2001:770:18:2:206:5bff:fe3f:aada: icmp_seq=1 ttl=64 time=0.066 ms

Would it be presumed that someone would be allowed to reach some IPv4
address internal on some LAN if there was some IPv6 translator that
could be addressed publically to do so, by expressing it with that
translator's /96 address and appending the dotted-quad? I never did
think about that before, but now it seems like an interesting way to
some services functional without implementing or deploying IPv6 on
each server. Now this is getting way off from "nsd-users" topic but
NSD would be a tool I'd be using with such a thing if I did so.

10

But why? I still don't see why.

An address expressed like ::ffff:209.102.192.73 could be used on a system
that has only IPv6 implemented, or only has IPv6 reachability, or has a
LAN that is limited to IPv6, and such an address can be converted to IPv4
at some point between that machine's stack (inclusive) to that network's
gateway (NAT), and go out over the rest of the net as IPv4.

Getting back to DNS, it's also a way to query a single record type once
and get an address that says "Use IPv4 instead, and here's the address".

Should any of what I describe not be done, or be done some other way?

Otherwise I think this capability should be included in the long term.
I just don't have an immediate need for the dotted-quad suffix syntax
anymore since I wrote a converter for my zone file generator scripts.

11

An address expressed like ::ffff:209.102.192.73 could be used on a system
that has only IPv6 implemented, or only has IPv6 reachability, or has a
LAN that is limited to IPv6, and such an address can be converted to IPv4
at some point between that machine's stack (inclusive) to that network's
gateway (NAT), and go out over the rest of the net as IPv4.

Absolutely not! As Itojun sais, ::ffff addresses are supposed to be
local to a host only, they are never to appear on the wire, see
his ID for reasons why this is a bad thing:

http://www.join.uni-muenster.de/Dokumente/drafts/draft-itojun-v6ops-v4mapped-harmful-02.txt

What you are describing is almost like a relay translator, see:

http://www.faqs.org/rfcs/rfc3142.html

But this is a layer 3 device, doing it in layer 2 won't really work
reliabily (because of header incompatibilities). And it uses the C6::/64
prefix.

Getting back to DNS, it's also a way to query a single record type once
and get an address that says "Use IPv4 instead, and here's the address".

Should any of what I describe not be done, or be done some other way?

You're just using the wrong prefix is all :slight_smile: ::ffff is for host-only
translation, a well-configured host should deny any packets with this
prefix to come in over the wire.

12

Gah, increment those layer numbers :wink:

13

I'm not proposing ::ffff go "over the wire" if we define "the wire" as
being the public routing space. As such, no need exists for a unicast
address space as the TRT proposal suggests. The existing ::ffff can do
the job, and won't have the risks Metz and Hagino suggest when done right.
If ::ffff goes over my local LAN, that's my business; there is no need for
the redundant c6::/64 assignment for it.

But in nsd-users, the on-topic issue is whether ::ffff should be supported
in AAAA records ... specifically with dotted-quad-suffix syntax. I want
to hear reasons why that should not be allowed. Whether ::ffff should be
allowed in packets should be a layer 2 issue, not a DNS issue. If comes
to pass that there is no use for ::ffff then whether it works, and is
convenient to use, in zonec is moot. But if in the end it is decided that
c6::/64 is the way to go, you still need the dotted-quad-suffix support.

14

As such, no need exists for a unicast address space as the TRT
proposal suggests. The existing ::ffff can do the job, and won't have
the risks Metz and Hagino suggest when done right. If ::ffff goes
over my local LAN, that's my business; there is no need for the
redundant c6::/64 assignment for it.

You're crazy! That's like saying you can use the multicast IPv4
assignments as your own private addresses, because you never plan to use
multicast and since it's on your own LAN, it's not the rest of the
worlds business :wink:

::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 :slight_smile:

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 :slight_smile:

I want to hear reasons why that should not be allowed.

It should be, but the dotted-quad thing should not be specific to
a particular prefix :slight_smile:

Whether ::ffff should be allowed in packets should be a layer 2 issue,
not a DNS issue. If comes to pass that there is no use for ::ffff
then whether it works, and is convenient to use, in zonec is moot.
But if in the end it is decided that c6::/64 is the way to go, you
still need the dotted-quad-suffix support.

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

15

::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 :slight_smile:

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 :slight_smile:

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 :slight_smile:

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