Issue around A6 Records for IPv6

Jim Bound bound at zk3.dec.com
Wed Jun 23 11:16:35 UTC 1999


Folks,

Be good if Bind workers and ISC respond to namedroppers list on this one for 
sure.

/jim


Return-Path: owner-namedroppers at opsmail.internic.net
Received: from quarry.zk3.dec.com by iota.zk3.dec.com (8.7.6/UNX 1.7/1.1.20.3/24Apr98-0811AM)
	id NAA0000027310; Tue, 22 Jun 1999 13:20:29 -0400 (EDT)
Received: from mail12.digital.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM)
	id NAA0000020465; Tue, 22 Jun 1999 13:20:28 -0400 (EDT)
Received: from opsmail.internic.net (opsmail.internic.net [198.41.0.91])
	by mail12.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id NAA04567;
	Tue, 22 Jun 1999 13:19:57 -0400 (EDT)
Received: (from majordom at localhost)
	by opsmail.internic.net (8.9.3/8.9.1) id MAA17053
	for namedroppers-outgoing; Tue, 22 Jun 1999 12:47:14 -0400 (EDT)
X-Authentication-Warning: opsmail.internic.net: majordom set sender to owner-namedroppers at internic.net using -f
Received: from rs.internic.net (bipmx2.lb.internic.net [192.168.120.15])
	by opsmail.internic.net (8.9.3/8.9.1) with SMTP id MAA17026
	for <namedroppers at internic.net>; Tue, 22 Jun 1999 12:47:12 -0400 (EDT)
Received: (qmail 8067 invoked from network); 22 Jun 1999 16:45:00 -0000
Received: from unknown (HELO rip.psg.com) (147.28.0.39)
  by 192.168.119.15 with SMTP; 22 Jun 1999 16:45:00 -0000
Received: from localhost (3135 bytes) by rip.psg.com
	via sendmail with P:stdio/R:inet_resolve/T:smtp
	(sender: <randy>) (ident <randy> using unix)
	id <m10wThX-0008G4C at rip.psg.com>
	for <namedroppers<namedroppers at internic.net>>; Tue, 22 Jun 1999 09:47:11 -0700 (PDT)
	(Smail-3.2.0.101 1997-Dec-17 #1 built 1999-Apr-1)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <199906221646.LAA00242 at gungnir.fnal.gov>
To: ipng at sunroof.eng.sun.com
Cc: namedroppers at internic.net
From: "Matt Crawford" <crawdad at fnal.gov>
Subject: draft-ietf-ipngwg-dns-lookups-04.txt
Date: Tue, 22 Jun 1999 11:46:16 -0500
Precedence: bulk

  Our area dissectors would like to have the A6 document specify just
how the resolver is supposed to act with respect to requesting AAAA
or A6 records when an IPv6 address lookup is needed.

  Down the road a short (?) way, the option will exist of using
multiple questions in a single query, with the choice of requesting
answers to all, or the first which gets a non-empty answer.  I can't
find a document which outlaws or deprecates multiple questions today,
but we all know that they don't work.

  As soon as the A6 draft is implemented, I expect to see A6 records
appear in zone files.  And when they are in zone files, I hope to see
A6-aware resolvers looking for them.  But for some period, A6 records
will be rarer than AAAA records.

  The rules for A6 processing in the server specify that A and AAAA
are returned as additional data.  So requesting A6 from an A6-aware
server which holds no A6 records won't waste a round-trip.

  Aside from using multiple questions in one UDP packet, the
following possibilities exist.

  1* Use a TCP connection to make successive queries if needed.
  Multiple queries and replies on one connection is allowed, and
  encouraged at least for the case of SOA+AXFR.  (Are there real-
  world implementation facts that would preclude this?)

  2* Ask for both A6 and AAAA in separate UDP packets, without waiting
  for an answer in between.

  3* Ask for A6, then for AAAA if RCODE=0 and ANCOUNT=0 and no AAAA
  records are returned as additional information.

  4* Ask for AAAA, then for A6 if RCODE=0 and ANCOUNT=0.

  5* Only ask for A6, never AAAA.

  6* Only ask for AAAA, never A6.

  The last of these is today's state, and we want to transition to
some other, possibly number 5.  1, 2, and 3 are all plausible
intermediate states, each with its own drawback.

  An orthogonal but important question is that of how to cause the
resolver to alter its behavior without extra redeployment steps.  It
could pick up its instruction from some magic word in a configuration
file (or environment or registry entry), or some special cue in a
zone file (but then some implementations may have to make a query for
that cue in every new process).

  As a starting point for discussion, I propose the following text to
be added to section 7 ("Transition from AAAA Records")

    Applications or libraries implementing the function of looking up
    IPv6 addresses by means of either A6 or AAAA records MUST be
    configurable to operate in at least the following modes:
    requesting A6 records before AAAA, AAAA before A6, and A6 only.
    The default mode SHOULD be to request A6 before AAAA.


More information about the bind-workers mailing list