Subject: notes on A6 transition from AAAA (fwd)

From: Olafur Gudmundsson <[email-masked]>
Date: Sun, 25 Mar 2001 17:16:55 -0500 (EST)

Included is the "infamus" beer plan, on how to retire AAAA
everywhere but stub resolvers.
Please send all followup to namedroppers. 

	Olafur (DNSEXT WG co-chair)

ps: The peole haching this plan were Mark Andrews, Rob Austein, 
Alain Durand and Olafur Gudmundsson 

---------- Forwarded message ----------
Date: Sun, 18 Mar 2001 20:05:32 -0800
From: Alain Durand <[email-masked]>
To: [email-masked], [email-masked]
Subject: notes on A6 transition from AAAA

Transition from AAAA to A6

    Stub resolvers that ask for AAAA in queries with the RD bit turn ON
    will be returned AAAA answers.

    Resolvers that have send queries with RD bit OFF and ask for AAAA
    will be returned whatever is available, A6 or AAAA. Note that they
    SHOULD issues A6 queries in the first place.

    The entity that in its server role received a query with the RD bit
    turn ON and process that request in its resolver role issues
    A6 queries with the RD bit turned OFF is responsible for the
    systhesis of AAAA from A6 records. This entity MUST try first A6
    then MAY try AAAA queries to process the request.

    A authoritative server that only has AAAA entries and
    is asked for an A6 record MUST NOT synthesize A6 records
    from the AAAA ones. There is no restriction on populating both
    types, but it is strongly recommended against, and in such a case,
    both RRsets MUST be identical.

    If a query does not contain EDNS indicator, then any IPv6 addresses
    contain in additional data section MUST be AAAA.

    Root and TLD zones MUST only contain A6 with prefix of 0.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: [email-masked]
Date: Mon, 26 Mar 2001 16:30:39 +0900

>Please send all followup to namedroppers. 

	I have a couple of questions here.

	Regarding to additional delays imposed to existing libc resolvers.
	it seems that there will be additional delays imposed during
	transition period, due to "A6 then AAAA" retries in multiple places
	in the query chain.  was it taken into account?
	(see the end of the email for some details - hope I made no mistake)

	for a certain FQDN, supposed we have different values registered onto
	DNS database, like:
		z.itojun.org. IN AAAA xxxx
		z.itojun.org. IN A6 0 yyy
	what should a client see in this case?  yyy, xxxx, or both?

	for clients that send A6 queries RD=1, is it assumed that they
	are able to reassemble A6 fragments?  or, is it okay for them to be
	able to decipher "A6 0 <128bit>" only?

	(whether it is good idea to switch to A6 or not, is another question -
	it should be discussed separately in "case for/against A6")

itojun

scenarios:
- machine X implements the proposed behavior.
- machine A has old libc resolver, whch queries AAAA only for IPv6 name
  resolution.  A will contact X with RD=1.
- machine B has new libc resolver, which queries A6 then AAAA.  B will
  contact X with RD=1.
- foo.itojun.org. has AAAA record only.
- bar.itojun.org. has "A6 0 <128bit>" record only.
- baz.itojun.org. has "A6 0 <64bit> subnet.itojun.org." record only.
- moo.itojun.org. has "A6 0 <128bit>" and AAAA record.

when A queries AAAA RR of of foo.itojun.org.:
	A sends AAAA query to X.
	X will try to query A6 RR of foo.itojun.org., RD=0, to synthesize.
	X gets no reply.
	X will try to query AAAA RR of foo.itojun.org., RD=0.
	X gets AAAA reply.
	A will get an AAAA.
when B queries A6 then AAAA of foo.itojun.org.:
	B sends A6 query to X.
	X will try to query A6 RR of foo.itojun.org., RD=0.
	X gets no reply.
	B gets no reply.
	B sends AAAA query to X.
	X will try to query A6 RR of foo.itojun.org., RD=0, to synthesize.
	X gets no reply.
	X will try to query AAAA RR of foo.itojun.org., RD=0.
	X gets AAAA reply.
	B will get an AAAA.

when A queries AAAA RR of bar.itojun.org.:
	A sends AAAA query to X.
	X will try to query A6 RR of foo.itojun.org., RD=0, to synthesize.
	X will get "A6 0 <128bit>".
	A will get an AAAA, synthesized.
when B queries A6 then AAAA of bar.itojun.org.:
	B sends A6 query to X.
	X will try to query A6 RR of foo.itojun.org., RD=0.
	X gets A6 reply, "A6 0 <128bit>".
	B will get an A6, "A6 0 <128bit>".

when A queries AAAA RR of baz.itojun.org.:
	A sends AAAA query to X.
	X will try to query A6 RR of baz.itojun.org., RD=0, to synthesize.
	X will get "A6 0 <64bit> subnet.itojun.org.".
	A6 chain traversals happen from X.
	X gets all A6 fragments for baz.itojun.org.
	X reassembles A6 fragments.
	A will get an AAAA, synthesized.
when B queries A6 then AAAA of baz.itojun.org:
	B sends A6 query to X.
	X will try to query A6 RR of foo.itojun.org., RD=0.
	X gets A6 reply, "A6 0 <64bit> subnet.itojun.org.".
	B will get A6 reply, "A6 0 <64bit> subnet.itojun.org.".
	B sends A6 query X for subnet.itojun.org.
	A6 chain traversals happen from B.
	B gets all A6 fragments for baz.itojun.org.
	B reassembles A6 fragments.

when A queries AAAA RR of moo.itojun.org.:
	same story as bar.itojun.org. case.
when B queries A6 then AAAA of moo.itojun.org.:
	same story as bar.itojun.org. case.

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 26 Mar 2001 15:14:52 -0500

>     both RRsets MUST be identical.

This proposal does not formally define equivalence of AAAA and A6.

is this limited to zero-prefix A6, or does it include A6's with
non-zero prefixes which just happen to resolve to the same thing?
Based on Rob's "zero prefix A6 is equivalent to AAAA" slide, I assume
the former..

>     Root and TLD zones MUST only contain A6 with prefix of 0.

Following the "prohibit on primary load, grumble on secondary load,
allow through on cached queries" interpretation of the "be
conservative in what you send, and liberal in what you accept"
principle, I also assume that the "MUST"s on zone contents should be
be enforced only when loading a primary..

						- Bill

---

From: Rob Austein <[email-masked]>
Date: Mon, 26 Mar 2001 19:05:37 -0500

Date: Mon, 26 Mar 2001 15:14:52 -0500
   From: Bill Sommerfeld <[email-masked]>

Right.  There's still a bit of an open issue about what to do with
AAAA in the long run, perhaps declare it to be a form of meta query
for stub resolvers to use that means "get me an address, however
that's implemented this week, and just return me the bits please".

No, our theory was that we really didn't want synthesized A6 RRs at
all, full stop.  We're not trying for parallel mechanisms here, the
idea is that A6 would become the "real" data and AAAA would become the
way that certain clients chose to retrieve a simplified form of it.

As far as the software would be concerned, you're right.

We were, however, also recommending that these limits be enforced by
administrative policy for the root, TLDs, and other big public zones.
That's out of the IETF's scope, other than making the recommendation.

---

From: Rob Austein <[email-masked]>
Date: Mon, 26 Mar 2001 18:53:22 -0500

Date: Mon, 26 Mar 2001 16:30:39 +0900
   From: [email-masked]

Yes, retrying for AAAA at the end adds an extra step with
corresponding extra delay.  This is why the proposed rule is "This
entity MUST try first A6 then MAY try AAAA queries to process the
request."  If we go with this transition plan, we want to encourage
zone admins to switch over to putting A6 into the zone files as
quickly as possible so that the QTYPE=AAAA RD=0 query will become
unnecessary, but implementors who are willing to suffer the additional
delay and want to perform the extra query are free to do so.

yyy.

In the long run, any resolver (stub or otherwise) that understands A6
should be prepared to splice the fragments together.  In the short
run, we're proposing that only the limited form of A6 be allowed,
until developers have time to implement the full form of A6.

Agreed.  This discussion is just about how we would transition, not
about whether we should transition.

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 27 Mar 2001 14:36:39 -0500

> all, full stop.  

I was asking about the "populating both types as long as both RRsets
are identical" approach -- you need to define what you mean by
"identical".

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 28 Mar 2001 00:21:50 -0500 (EST)

> are identical" approach -- you need to define what you mean by

Identical == same number of records in both sets and 
	     for each AAAA record there exists A6/0 record with same
		address

An A6/n (where n> 0) pointing at an routing prefix does not count even if
A6 synthesis would generate an A6/0 identical to one of the AAAA. 

	Olafur