Subject: draft-ietf-ipngwg-dns-lookups-04.txt

From: "Matt Crawford" <[email-masked]>
Date: Tue, 22 Jun 1999 11:46:16 -0500

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.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Peter Tattam <[email-masked]>
Date: Wed, 23 Jun 1999 12:32:05 +1000 (EST)

I am close to beginning an A6 implementation in my DNS server.

I raised the question some time ago about A6 -> AAAA translation for efficiency
reasons, but was howled down.  Is this still a possible topic for discussion? 

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Jim Bound <[email-masked]>
Date: Wed, 23 Jun 1999 07:53:17 -0400

Matt,

I have added BIND V9 mail list and BIND workers as this affects our IPv6
A6 rollout and any fixes to 8.1.2 which is about ready to go into
production and in kits for IPv6 Customers; who by the way have not
widely deployed A6 records quite yet :--).

I would also like to hear Bob Halley's take on this too.

>or A6 records when an IPv6 address lookup is needed.

Why for the record and so its in the archives for future reference OK?

>but we all know that they don't work.

Yes this will be part of BIND v9 for that code base which will be about
in 6 months long before massive IPv6 deployment?  

The meta query has been a BIND vendor request for some time and should 
be here real soon.

So why the urgency with BIND v9 so close?

>will be rarer than AAAA records.

Agreed.

>server which holds no A6 records won't waste a round-trip.

I want this to happen but for the record I always have thought this was
a bad idea as a MUST requirement and should be able to be overriden by
some code to the server.  A client may not want the A or AAAA records
back and we want to be able to permit that behavior for the future when
A and AAAA records are very  rare.  But I just thought of that so sorry
but I will now check this for last call.  Or before DS happens.

>following possibilities exist.

The meta query will be able to do this fyi.

>  world implementation facts that would preclude this?)

This increases the packets to the server for every request and why we
use UDP in the first place.  At least that is what current thinking
suggests for intensive client server processing should use UDP.  Of
course I don't agree with that current thinking.

>  for an answer in between.

Yuck.  That puts more state in the resolver awaiting to reply to the
application.

>  records are returned as additional information.

This sounds like the solution but we need a way as I said above to shut
this down to not return add'l section records too.

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

This should be permitted.

>  5* Only ask for A6, never AAAA.

This should be permitted.

>  6* Only ask for AAAA, never A6.

This should be permitted.

>intermediate states, each with its own drawback.

We should permit 5 and 6 for "transition" and 5 gives us 3 by default.

>that cue in every new process).

This is where the BIND v9 and BIND workers need to discuss this because
it is an important point.  I am not sure the spec should get into
specifying this because then we would have to assume we know all the
ways products will provide deployment of resolvers.  The best we can do
is provide an example abstraction.

I would like to see us stay away from environment variables and config
files, as this type of fix can cause release number problems for
product sets.  So I think that is a bad idea but will defer to ISC and
folks there.  But as a vendor I have gotten burned messing with config
files for DNS parts.

I need to think on this one a bit more and get back to you.
But its an important point and very critical.

>    requesting A6 records before AAAA, AAAA before A6, and A6 only.
????  I think you have a logic error in the above sentence ???
>    The default mode SHOULD be to request A6 before AAAA.

When asking a user if they are using IPv6 on their node I envision
asking them are you ready for A6 records.  If they say yes then I could
use the default above but I would ask them if they wanted the default
and they should not if they know there are no A6 records deployed.
So your SHOULD above is OK I think.  

But as I said above if a site has gotten rid of AAAA records or simply
does not want them don't want to see them in the hostent structure or
the A records but that is an API function I think we have covered in
2553.

/jim

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 23 Jun 1999 08:49:22 -0500

> I raised the question some time ago about A6 -> AAAA translation
> for efficiency reasons, but was howled down.  Is this still a
> possible topic for discussion?

You read section 7, yes?  Or are you talking not about a transition
aid, but a regular, long-term strategy?

			Matt

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 23 Jun 1999 09:12:30 -0500

> Why for the record and so its in the archives for future reference OK?

I will not answer for them, as I am not convinced of the necessity
myself, except in the sense that's it's necesary to play ball with
the ADs if we want this to go though.

> >multiple questions in a single query, ...
> 

I don't know what's to be in BINDv9; I never heard of the bindv9 list
before, but I do know that the multi-question feature is spec'd in
EDNS1, and given the velocity of the much simpler EDNS0, (to say
nothing of A6) I'm not going to pin anything on EDNS1 if I can help
it.

> some code to the server.  A client may not want the A or AAAA records...

And the server knows this by what, ESP?  Remember, additional data is
included only to the extent that it (a) fits in the packet and (b) is
available in the responding server.

> >    The default mode SHOULD be to request A6 before AAAA.

Explain the error, please; I don't see it.

				Matt

---

From: Jim Bound <[email-masked]>
Date: Wed, 23 Jun 1999 10:33:11 -0400

>the ADs if we want this to go though.

Hmmm.  Then they should tell us on the list I think.  
Tom or Erik??? Please..................

>nothing of A6) I'm not going to pin anything on EDNS1 if I can help

BINDv9 is the next major arch release of BIND with lots of good stuff
like SMP.  A group of us vendors and some other folks are paying ISC to
deliver an NGN BIND that will eat gremlins so to speak.  

The multiquery will be there we need it for IPv6, regardless of the
velocity of some spec.  But we can move forward I see your point now.

>available in the responding server.

I am thinking we need to tell the server about the transition issue.

>Explain the error, please; I don't see it.

If I ask for A6 records before AAAA then why would I ask for AAAA
records before A6.  Its one way or the other?  A6 ONLY is good and
something I think we should be able to do per the above.

thanks
/jim

---

From: Thomas Narten <[email-masked]>
Date: Wed, 23 Jun 1999 10:48:29 -0400

> Why for the record and so its in the archives for future reference OK?

Once A6 records are specified, there would be two ways of doing the
same thing (i.e., query the DNS for v6 addresses). Implementers need
some guidance as to which of these two approaches to implement.
Moreover, AAAA records are deployed today, while A6 records are
not. Thus, a transition strategy for migrating from AAAA to A6 is
necessary.

If this stuff isn't specified in an RFC, vendors will likely not know
what to do and make choices that aren't well thought out (e.g, ship
resolvers that do AAAA only or A6 only). Thus, some guidance is needed
to insure that once folks actually start deploying A6, it can be made
to work in a sensible fashion.

This is akin to an applicability statement stating in what context
some new feature should be used and how it relates to an existing
feature that it conflicts/overlaps with.

Thomas

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 23 Jun 1999 09:46:31 -0500

> I am thinking we need to tell the server about the transition issue.

And there are already notes in the draft about transition issues for
the server side.  The directive from the ADs concerns the client side.

> something I think we should be able to do per the above.

Read it this way: "... MUST be configurable to operate in at least
the following modes: Foo, Bar and Baz, where Foo=(A6 before AAAA),
Bar=(AAAA before A6) and Baz=(A6 only)."  The sample text says all
three modes must be available to choose among.

(I can't send to the two lists you added, so a moderator is getting
work, and any readers there will get this out-of-order.)

				Matt

---

From: Sham Chakravorty <[email-masked]>
Date: Wed, 23 Jun 1999 13:24:59 -0400

We are in the process of summarizing various Ipv6 implementation issues
including the status of the protocol, extent of its use around the
world, etc., for a large organization for use in mostly mobile, narrow
bandwidth environment.

We would most appreciate information on your experience with IPv6
implementation for large organizations.  We would appreciate knowing
about extent of IPv4 (or other) tunneling you needed, interoperability
issues, bandwidth usage (especially in the low bandwidth links such as
radio links), delays due to dual stacking at the hosts and/or routers if
any, issues for the mobile environment, and any other related issues
such as impact on security, training the network managers/ops staff,
etc.

Thanks much in anticipation of your inputs.

S. Chakravorty
*************************************

---

From: Bob Halley <[email-masked]>
Date: Wed, 23 Jun 1999 18:22:49 -0700

> server which holds no A6 records won't waste a round-trip.

This is only true if the A6-aware server is authoritative for the name
being queried, or if the server is nonauthoritative and the data is
cached.  Because the A and AAAA records are additional data, a
nonauthoritative server will not recurse to retrieve them.

Some additional clarification in section 4.1.2 might be helpful, since
doing additional section processing when there are no records of the
desired type is new.

> The default mode SHOULD be to request A6 before AAAA.

This sounds reasonable to me, except that I propose that the default
be "A6 only".  I prefer this default because this is where we want to
be after the transition is over.  If we use some other default, then
after the transition period there are two options:

	People have to specify "A6 only" in their config files to get
	the desired post-transition behavior.

	The application/library default must change.

Having to explicitly specify "A6 only" in config files after the
transition period would be annoying, since it is the desired default
behavior.

Changing the application/library default is something I'd like to
avoid, since it changes the meaning of configuration files that people
have in production, perhaps breaking things.

/Bob

---

From: Jim Bound <[email-masked]>
Date: Mon, 28 Jun 1999 14:41:07 -0400

Tom,

>feature that it conflicts/overlaps with.

thanks.
/jim

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jun 1999 01:01:49 -0700 (PDT)

To add to Thomas' concern about specifying transition:

There is some interaction between the transition strategy in the resolver
since section 7 says:
    A server providing recursive service MAY be configurable to
    synthesize AAAA records from A6 records in response to clients' AAAA
    queries.

If a server does this and the resolvers ask for AAAA before A6
then how can the server tell that the resolver is capable of
asking for A6 records so it can skip the synthesis?

This issue points out that we need the resolver and server
transition written down so that the WGs and the IESG can check 
that things work well together.
Just having the transition strategy for the DNS server isn't enough.

   Erik

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 29 Jun 1999 10:13:31 -0500

> if we want to specify a metaquery that can be satisfied by either AAAA
> or A6 records (or A records for that matter) then by all means let's make
> one.  MAILA and MAILB are metaqueries.  they have no corresponding RRTYPES;
> they are examples of QTYPE being a subtype of RRTYPE in the DNS specs.

I made that suggestion to the AD's.  I'll let them present their own
arguments against it, rather than distort them from memory.

					Matt

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 29 Jun 1999 07:54:01 -0700

note: i have removed

	, [email-masked],
	[email-masked]

from the CC list, since these are internal ISC lists and should not have
been CC'd (or mentioned in public, for that matter) by a thread which also
hit namedroppers and ipng.  bad jim, no bone.  they might have been BCC'd;
those of you who are on them will know :-).

> asking for A6 records so it can skip the synthesis?

that's one possible bad thing.  but record synthesis has to be very
carefully considered -- and in this case after carefully considering it
i hereby object to doing it for AAAA.

but answering with types not in evidence, or making things up on the fly,
or putting unrelated things in as additional data, will all screw DNSSEC in
different ways.  repeat after me: dns is a coherent, reliable, distributed,
autonomous database.  it is not a directory service.  it encodes policy as
facts, and returns those facts reliably to questioners.  it does not 
directly deal in policy.

> Just having the transition strategy for the DNS server isn't enough.

this is certainly also true.