[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: dnsop@cafax.se
Cc: bmanning@ISI.EDU (Bill Manning)
From: Bill Manning <bmanning@ISI.EDU>
Date: Wed, 19 Sep 2001 01:16:55 -0700 (PDT)
Sender: owner-dnsop@cafax.se
Subject: operationally (if not yet WG) related

 The operational recommendation is at the end.
------------------------------------------------------------

In most tested DNS servers, it is possible to instanciate records with
opcode 28, the AAAA type.  Unfortunately, nearly all DNS servers will
allow either the native form, e.g.

        foo.example.com in aaaa  f5:0:1:dead:beef

or in mapped IPv4 form, e.g.

        foo.example.com in aaaa ::ffff:192.0.2.1

and either form seems to work, However, with the latest versions of
BIND <all versions of 9, through 9.2.0rc3>, on a number of different
Operating Systems, generate inconsistant results, with the following log
message being typical:

Sep  7 09:49:41 : socket.c:1085: unexpected error:
Sep  7 09:49:41 : internal_send: ::ffff192.0.2.1:#53: Invalid argument

Hum...  Whats happening?

Nothing in section 5 of RFC 2292 says that mapped addresses
are disallowed in in6_pktinfo.  The only requirement is that
they are unicast addresses.

So, does everyone do in6_pktinfo the same? Are the rest of the calls
there?  Do stack developers follow RFC 2553, esp. section 3.7?

This from a stack developer:
"The ways of handling of the IPv4-mapped IPv6 address varies the
operating systems.
When writing a dual stack application, on some OSes you need single
socket opened for IPv6 and an IPv4 packet comes with an IPv4-mapped
IPv6 address. Linux would be one of this category.
On the other OSes, you need to open two sockets; one for IPv4 and the
other for IPv6. BSD/OS and NetBSD fall under this category.
Both behaviors are considered to be valid.
This inconsistency would introduce portability problem, however."

With the following reply from a BIND developer:
"So when did RFC 2553 Section 3.7 become optional to implement?
Its always been the application writers choice whether to use
mapped addresses or not.  Now we have stacks forcing you to
use Section 3.7, stacks forcing you not to use Section 3.7 and
stacks that allow you to use Section 3.7 if you wish to.

This is bloody crazy."

        So... from an operational perspective, I would like to
        float what might actually be a legitimate Best Current
        Practice Recommendation; to wit:


"We recommend DNS administrators DO NOT use mapped IPv6 addresses with
opcode 28 <type AAAA> resource records in ANY zone file."

Again, YMMV.


-- 
--bill

Home | Date list | Subject list