Subject: A6/DNAME usage guidelines and limits

From: Nathan Jones <[email-masked]>
Date: Tue, 2 Apr 2002 16:47:51 +1000

Standard
Reply-To:

This is a follow-on from the thread:
Subject: Re: Last Call: Representing IPv6 addresses in DNS to Proposed

On Wed, Mar 27, 2002 at 09:27:27PM +1100, Nathan Jones wrote:
>Has anyone yet started work on a draft to document guidelines for the
>usage of DNS with IPv6? (eg. recommended limits on A6 chains, etc.)

I've started writing up some guidelines, which I've included below.
They are far from complete, but I wanted to post something before the
close of the Last Call for draft-ietf-dnsext-ipv6-addresses-01.txt.

In particular:
- I need to add guidelines on DNAME.
- I need to add info on using DNSSEC in an A6 world. (If you're
  familiar with DNSSEC, you may have suggestions to send.)
- I'm not happy with the wording, but will continue to work on it and
  flesh it out to be more complete.

Let's assume for a moment that A6 and DNAME are left intact. With this
assumption in mind, please give me your feedback and suggestions.

In response to a call for a compromise between AAAA and A6, I've
portrayed fairly conservative use of A6 and also suggested
deprecating bit string labels (even though personally I like them).

------------------------
Introduction

   Extensions to DNS have been made to allow for easier renumbering with
   IPv6. Few guidelines have been written about the use of these
   extensions. This document provides suggestions that should assist
   in the deployment of A6 and DNAME.

Overview

   This section provides an overview of the DNS mechanisms discussed in
   this document. For full information, the reader should refer to the
   relevant specification.

   [Will add information here once the other guidelines are in place.]

Recommendations for A6

   [RFC2874] gives an example based on the IPv6 aggregatable address
   format [RFC2374], where a top level aggregate (TLA), next level
   aggregate (NLA), ISP and site all provide portions of an A6 record
   chain. In order to support such a configuration, A6 aware DNS
   resolvers that provide recursion MUST support at least six (6)
   levels of indirection in an A6 record chain.

[Although there are six components to the A6 record chain in the
example, only four lookups are required, since three components are
held on one server and would be returned in the Additional section.
Should the limit here be four levels of indirection (TLA, NLA, ISP,
Site)? If so, what if the site's HR department has its own
nameservers? A lookup for mail.hr.x.example. would require more than
four queries.]

   While support for six levels of indirection is important for future
   use, it is suggested that A6 records initially be implemented with
   fewer fragments.

   In many cases, a simple configuration with one level of indirection
   should be sufficient. For example, each node in a site could be
   referenced by an A6 record that has a common prefix and prefix length.
   The A6 record for the prefix would generally be maintained by the
   site, rather than an upstream ISP. As a result, most lookups will
   only require one query.

   Example:

   This example mirrors the one in section 5.1 of [RFC2874]. Site X is
   represented in the DNS by the domain name X.EXAMPLE and receives
   transit from two ISPs named A and B. A and B in turn receive transit
   from providers C, D and E. Address allocation and aggregation is
   such that site X has inherited three address prefixes:

   o  2345:00C1:CA11::/48 from A, for routes through C.
   o  2345:00D2:DA11::/48 from A, for routes through D.
   o  2345:000E:EB22::/48 from B, for routes through E.

   Let us suppose that N is a node in the site X, that it is assigned to
   subnet number 1 in this site, and that it uses the interface
   identifier '1234:5678:9ABC:DEF0'.  In our configuration, this node
   will have three addresses:

   o  2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
   o  2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
   o  2345:000E:EB22:0001:1234:5678:9ABC:DEF0

   Using the basic configuration suggested in this document, site X
   would include the following records in it's DNS:

          $ORIGIN X.EXAMPLE.
          IP6      IN  A6  0  2345:00C1:CA11::
                   IN  A6  0  2345:00D2:DA11::
                   IN  A6  0  2345:000E:EB22::
          N        IN  A6  48 ::1:1234:5678:9ABC:DEF0 IP6

   In this example, should a site need to renumber, some administration
   is still required, but only the prefix A6 records would need to be
   updated. Other A6 records that reference the prefix do not need to
   be changed.

AAAA Synthesis

   [RFC2874] discusses making a transition from AAAA to A6 by automatically
   generating AAAA records from A6 records. Such AAAA synthesis should be
   viewed as an integral part of DNS support for IPv6, rather than purely
   a transition mechanism. 

   A nameserver that offers recursive DNS resolution SHOULD be able to
   generate AAAA records in response to AAAA queries. This allows devices
   and other hosts to use a lightweight stub resolver that does not need
   to know about A6.

Deprecation of Bit String Labels

   [RFC2874] recommends the use of bit-string labels, as defined in
   [RFC2673]. The main advantage of bit-string labels is the ability to
   delegate on arbitrary bit boundaries. The disadvantage is an increase
   in complexity. To reduce this complexity, this document deprecates
   bit-string labels.

   Delegations in the inverse tree (IP6.ARPA.) therefore continue to use
   the nibble format described in [RFC1886]. In the event that delegation
   is required on non-nibble boundaries, the method specified in
   [RFC2317] should be used.

-- 
Nathan Jones
[email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Carl Perry <[email-masked]>
Date: Wed, 3 Apr 2002 15:59:42 -0600

>    and other hosts to use a lightweight stub resolver that does not need

I think this is the way to go.  A6 is a good idea, in general.  However,
having the resolver on a client have to perform multiple queries to get
a single name resolved is not a good idea.  End-points in the DNS tree
should be able to ask DNS server/cache systems to provide them an AAAA
answer to a name.  The server/cache should be able to handle AAAA and
A6, and convert A6 records to AAAA responses accordingly.  This gives
the ability for "easy" address renumeration, and a thinner client
resolver profile.  In short, it's the best of both worlds.

-- 
	-Carl Perry
	[email-masked]

"Deliver yesterday, code today, think tomorrow."

---

From: Carl Perry <[email-masked]>
Date: Wed, 3 Apr 2002 16:12:47 -0600

-- 
	-Carl Perry
	[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 03 Apr 2002 13:07:51 -0800

> resolver profile.  In short, it's the best of both worlds.

what the world is coming to is that applications (by which i include stub
resolvers) will have to have available to them a far simpler protocol/API
than full DNS.  is that what we all really want?  what it would look like
is "applications make TSIG'd AAAA and A queries of their local recursive
name server" and "recursive name servers will use EDNS0, DNSSEC, and A6."

that doesn't cover the DNAME/PTR issue but that falls out naturally.

that doesn't cover the synthesized AAAA issue but that also falls out
naturally.

the question is, before we go into detail on it, is: have we really and
truly put so much mass into the DNS protocol that most applications (and
most stub resolvers) cannot reasonably be expected to speak it?

once we know that, we know how to proceed.

---

From: Carl Perry <[email-masked]>
Date: Wed, 3 Apr 2002 19:31:08 -0600

> most stub resolvers) cannot reasonably be expected to speak it?

I believe so.  I don't know about you, but my cell phone has a hard
enough time not dropping packets and doing name queries as it is - I
would hate to see it do a six-level A6 query with DNSSEC on.

I think we at least have to be able to support a "slimmer" subset of the
entire DNS system for tree-tip devices.  I see technologies like DNSSEC
and A6 as server/cache level technologies.  Let's face it, if your
client resolver supports DNSSEC and your caching server doesn't - you
are not making any gains on the anti-spoofing front.  Sure, a client
_can_ support DNSSEC if it wants to, but I don't think it should be a
requirement.

On top of the "easier to implement a resolver" front, there is also the
improvements to the end user.  With any luck, your DNS caching server
has a lower latency connection to the Internet than your 56k modem.  So,
one can hope that if the server with the better connection does the
bulk of the network-intensive legwork and then caches the result you are
going to have a much better response time than if you did it yourself.
You'll have an even faster lookup time if some of the A6 tiers are
already cached as well.

What do you think?  

-- 
	-Carl Perry
	[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Wed, 03 Apr 2002 16:12:48 -0800

> would hate to see it do a six-level A6 query with DNSSEC on.

does that mean that we as protocol designers have failed somehow?  (this
was not the anticipated mode when all this technology was planned out.)

> Let's face it, if your client resolver supports DNSSEC and your
> caching server doesn't - you are not making any gains on the
> anti-spoofing front.

that, at least, is untrue.  a client which fully implements DNSSEC can
know whether its forwarders are corrupt -- at least in the case where
the data has been signed.

> Sure, a client _can_ support DNSSEC if it wants to, but I don't think
> it should be a requirement.

what this means is the "light weight resolver" protocol we did for BIND9
was a complete waste of time, and simple AAAA and A queries should have
been used.  (right?)

> What do you think? =20

i think it's very late in the game to be holding this conversation.

---

From: Derek Atkins <[email-masked]>
Date: 04 Apr 2002 10:30:47 -0500

> resolver profile.  In short, it's the best of both worlds.

Note that there is no way to authenticate a AAAA-synthesis.  You can
require TSIG between the 'lightweight resolver' and the synthesizing
resolver, I suppose, and require the synthesizing resolver to verify
the DNSSEC response(s).  However as an application writer I can
envision endpoint applications (users of DNS) that would want access
to the DNSSEC responses themselves.  How would you do that with AAAA
synthesis?

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Robert Elz <[email-masked]>
Date: Thu, 04 Apr 2002 23:00:40 +0700

Date:        04 Apr 2002 10:30:47 -0500
    From:        Derek Atkins <[email-masked]>
    Message-ID:  <[email-masked]>

  | However as an application writer I can
  | envision endpoint applications (users of DNS) that would want access
  | to the DNSSEC responses themselves.  How would you do that with AAAA
  | synthesis?

Clearly you wouldn't.   You (the application writer) will just send
a query for A6 records instead.   Then you'll get the A6 records, and
their SIGs, returned to you.   AAAA synthesis is an option, one which
is liklely to be heavily used - using it will never be a requirement.

If your application can handle chasing the SIG/KEY/DS/NXT/... stuff to
validate the records, it can certainly also do the extra triviality of
chasing the A6 chain, which is much simpler.

kre

---

From: Derek Atkins <[email-masked]>
Date: 04 Apr 2002 11:55:12 -0500

> chasing the A6 chain, which is much simpler.

What happens if the A6 chain requires N hops, and I get the first
three and then fail?

I would like to see a situation where the client makes 1 request and
gets a response with the whole A6 chain.  This solves the latency
issues in low bandwith situations (like cell phones) but still allows
you to use A6.

Here's an alternative proposal: is there some way to require that a
nameserver for an A6 record be able to recurse up the chain and act as
a cache for the rest of the chain?  Perhaps the nameserver is required
to always cache complete A6 chains?  That way the client need only
make one request and the responding server will follow the chain?

Here's my reasoning: A server that is authoritative for the end-host
is the one going to answer the _first_ entry in the A6 chain.  If that
server _always_ has the rest of the chain cached, and can respond with
the whole chain in one answer, then the only difference between AAAA
and A6 is the packet size (from an application point of view).

For example, assume that MIT.EDU deploys A6 records of the form

        $ORIGIN provider.net.
        mit A6 0 <>

        $ORIGIN mit.edu.
        host A6 48 mit.provider.net. <> 

When the resolver asks the MIT nameservers for "host.mit.edu. A6" the
server can respond with the following in a single packet:

        host.mit.edu A6 48 mit.provider.net. <>
        mit.provider.net A6 0 <>

Obviously this is an implementation issue, not a protocol issue.  But
it would solve some of the problems that people have with A6, namely
the relatively-unbounded number of round-trips required to resolve an
A6 request and the possibility of failing partially through a request.

I admit that this proposal does add complexity to the nameserver
implementation, because they must be aware of all A6 chains and "keep"
them in the cache..  Or, alternately, the nameserver must be required
to recurse on their own A6 records, even if they don't necessarily
recurse.

-derek

---

From: Paul Vixie <[email-masked]>
Date: Thu, 04 Apr 2002 08:50:48 -0800

> to the DNSSEC responses themselves.  How would you do that with AAAA

in this model, you wouldn't.  QTYPE=AAAA && RD=0 would be invalid.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 04 Apr 2002 09:05:39 -0800

> What happens if the A6 chain requires N hops, and I get the first

then you lose, i guess.  the hope is that once this situation is widely
known, then improved caching robustness will be seen by network operators
as a key way to increase their overall network robustness.

> make one request and the responding server will follow the chain?

in rfc2317 we "solved" this by recommending that servers for intermediate
zones also slave the delegated zones.  that way iteration would likely not
occur beyond the octet boundary.

that's probably a wise practice for A6 chain intermediaries, as well.

> ... Obviously this is an implementation issue, not a protocol issue.  But

agreed.  and as shown by rfc2317's success, it's not all that hard to do.

> to recurse on their own A6 records, even if they don't necessarily

well, there's no way to require an authority server to fetch glue, though
many will.

---

From: Randy Bush <[email-masked]>
Date: Thu, 04 Apr 2002 19:08:17 +0200

<chair hat off>

> does that mean that we as protocol designers have failed somehow?

yes, we allowed an overly-clever set of proposals from the ipv6 community
go to far for too long.

> was a complete waste of time, and simple AAAA and A queries should have

right

> i think it's very late in the game to be holding this conversation.

agree.  so let's close this off already.  pass the document.  but i would
add completely ditch dname as well.

randy

---

From: Derek Atkins <[email-masked]>
Date: 04 Apr 2002 12:14:15 -0500

> as a key way to increase their overall network robustness.

Right.  The problem is that the client resolver has _half_ the data
and doesn't know when it will complete.  With AAAA (or A) you get a
response that is either 'yes' or 'no', not 'here is half your answer
-- look here for more information'.

> well, there's no way to require an authority server to fetch glue, though

Sure there is:

"An A6 response MUST include the complete chain, or the response must
be SERVFAIL."

;-)

-derek

---

From: Greg Hudson <[email-masked]>
Date: 04 Apr 2002 13:23:33 -0500

[ post by non-subscriber ]

> most stub resolvers) cannot reasonably be expected to speak it?

It seems to me that we reached that point a long time ago.  In
particular, Unix stub resolvers won't follow CNAME chains by doing
multiple queries; they rely on the recursive resolver to go out and
fetch the CNAME chain and the terminating canonical record.

If there were no installed base, and having A6 were an external
constraint, I would say that we should make recursive resolvers go out
and fetch A6 records to make a complete chain, so that stub resolvers
can still make only one query.  Since there is an installed base of stub
resolvers which do AAAA queries, it seems we would have to require the
less elegant approach of AAAA synthesis.  But it's the functionally the
same.

(I'm not very fond of A6, but I've made all those arguments in the
past.)

---

From: Robert Elz <[email-masked]>
Date: Fri, 05 Apr 2002 21:01:54 +0700

Date:        04 Apr 2002 12:14:15 -0500
    From:        Derek Atkins <[email-masked]>
    Message-ID:  <[email-masked]>

  | Right.  The problem is that the client resolver has _half_ the data
  | and doesn't know when it will complete.

The fact that it is half the data is irrelevant - if you allow yourself
to view it other than that way, then you'll see it is no different than
any other query.

  | With AAAA (or A) you get a
  | response that is either 'yes' or 'no', not 'here is half your answer
  | -- look here for more information'.

Of course you do - to fetch an answer (except in the case that you already
have the answer, and A6 is no different there), you have to go and send
queries, usually several queries.  To find NS records, to resolve CNAME
records, ...   All during that the answer is in the process of being
accumulated.   A6 is just the same - or if you like, just more of the
same.   During processing, records will be being fetched, eventually the
last RR arrives, and you're done.  Until then, you're just part way through
getting the data.

kre

---

From: "D. J. Bernstein" <[email-masked]>
Date: 5 Apr 2002 22:47:37 -0000

Carl Perry writes:
> A6 is a good idea, in general.

No, it isn't. See http://cr.yp.to/djbdns/killa6.html. The problems with
A6 are much bigger than the cost of an extra loop in (stub) clients.

The fundamental problem is that A6's cross-server indirection is being
performed in the foreground instead of in the background. We already
have reliability problems from foreground cross-server indirection in NS
and CNAME, even though NS and CNAME don't _encourage_ cross-server
indirection the way that A6 does.

For people who want separate signatures on chunks of an address: Fine.
Put separate signatures on chunks of an address. This is compatible with
background indirection.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago