A6/DNAME usage guidelines and limits

[Nathan Jones <[e-mail]>]

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
[e-mail]

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