Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)
RFC 3363

Document Type RFC - Informational (August 2002; No errata)
Updated by RFC 6672
Updates RFC 2673, RFC 2874
Authors Randy Bush  , Alain Durand  , Bill Fink  , ├ôlafur Gu├░mundsson  , Tony Hain 
Last updated 2020-07-29
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3363 (Informational)
Action Holders
Consensus Boilerplate Unknown
Telechat date
Responsible AD Thomas Narten
IESG note Published as RFC 3363 and 3364
Send notices to <>
Network Working Group                                            R. Bush
Request for Comments: 3363                                     A. Durand
Updates: 2673, 2874                                              B. Fink
Category: Informational                                   O. Gudmundsson
                                                                 T. Hain
                                                             August 2002

            Representing Internet Protocol version 6 (IPv6)
               Addresses in the Domain Name System (DNS)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.


   This document clarifies and updates the standards status of RFCs that
   define direct and reverse map of IPv6 addresses in DNS.  This
   document moves the A6 and Bit label specifications to experimental

1.  Introduction

   The IETF had begun the process of standardizing two different address
   formats for IPv6 addresses AAAA [RFC1886] and A6 [RFC2874] and both
   are at proposed standard.  This had led to confusion and conflicts on
   which one to deploy.  It is important for deployment that any
   confusion in this area be cleared up, as there is a feeling in the
   community that having more than one choice will lead to delays in the
   deployment of IPv6.  The goal of this document is to clarify the

   This document also discusses issues relating to the usage of Binary
   Labels [RFC 2673] to support the reverse mapping of IPv6 addresses.

   This document is based on extensive technical discussion on various
   relevant working groups mailing lists and a joint DNSEXT and NGTRANS
   meeting at the 51st IETF in August 2001.  This document attempts to
   capture the sense of the discussions and reflect them in this
   document to represent the consensus of the community.

Bush, et. al.                Informational                      [Page 1]
RFC 3363        Representation of IPv6 Addresses in DNS      August 2002

   The main arguments and the issues are covered in a separate document
   [RFC3364] that reflects the current understanding of the issues.
   This document summarizes the outcome of these discussions.

   The issue of the root of reverse IPv6 address map is outside the
   scope of this document and is covered in a different document

1.1 Standards Action Taken

   This document changes the status of RFCs 2673 and 2874 from Proposed
   Standard to Experimental.

2.  IPv6 Addresses: AAAA RR vs A6 RR

   Working group consensus as perceived by the chairs of the DNSEXT and
   NGTRANS working groups is that:

   a) AAAA records are preferable at the moment for production
      deployment of IPv6, and

   b) that A6 records have interesting properties that need to be better
      understood before deployment.

   c) It is not known if the benefits of A6 outweigh the costs and

2.1 Rationale

   There are several potential issues with A6 RRs that stem directly
   from the feature that makes them different from AAAA RRs: the ability
   to build up addresses via chaining.

   Resolving a chain of A6 RRs involves resolving a series of what are
   nearly-independent queries.  Each of these sub-queries takes some
   non-zero amount of time, unless the answer happens to be in the
   resolver's local cache already.  Other things being equal, we expect
   that the time it takes to resolve an N-link chain of A6 RRs will be
   roughly proportional to N.  What data we have suggests that users are
   already impatient with the length of time it takes to resolve A RRs
   in the IPv4 Internet, which suggests that users are not likely to be
   patient with significantly longer delays in the IPv6 Internet, but
   terminating queries prematurely is both a waste of resources and
   another source of user frustration.  Thus, we are forced to conclude
   that indiscriminate use of long A6 chains is likely to lead to
   increased user frustration.

Bush, et. al.                Informational                      [Page 2]
RFC 3363        Representation of IPv6 Addresses in DNS      August 2002

   The probability of failure during the process of resolving an N-link
   A6 chain also appears to be roughly proportional to N, since each of
   the queries involved in resolving an A6 chain has roughly the same
   probability of failure as a single AAAA query.

   Last, several of the most interesting potential applications for A6
   RRs involve situations where the prefix name field in the A6 RR
   points to a target that is not only outside the DNS zone containing
   the A6 RR, but is administered by a different organization entirely.
   While pointers out of zone are not a problem per se, experience both
Show full document text