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

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

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".

   >     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.

   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..

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.

   >     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.

   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..

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.

--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------

Reply via email to