+++ /dev/null
-
-
-
-Internet Engineering Task Force Jun-ichiro itojun Hagino
-INTERNET-DRAFT IIJ Research Laboratory
-Expires: January 19, 2002 July 19, 2001
-
-
- Comparison of AAAA and A6 (do we really need A6?)
- draft-ietf-dnsext-aaaa-a6-01.txt
-
-Status of this Memo
-
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other groups
-may also distribute working documents as Internet-Drafts.
-
-Internet-Drafts are draft documents valid for a maximum of six months
-and may be updated, replaced, or obsoleted by other documents at any
-time. It is inappropriate to use Internet-Drafts as reference material
-or to cite them other than as ``work in progress.''
-
-To view the list Internet-Draft Shadow Directories, see
-http://www.ietf.org/shadow.html.
-
-Distribution of this memo is unlimited.
-
-The internet-draft will expire in 6 months. The date of expiration will
-be January 19, 2002.
-
-
-Abstract
-
-At this moment, there are two DNS resource record types defined for
-holding IPv6 address in the DNS database; AAAA [Thomson, 1995] and A6
-[Crawford, 2000] . AAAA has been used for IPv6 network operation since
-1996. Questions arose whether we really need A6 or not, or whether it
-is really possible to migrate to A6 or not. Some says AAAA is enough
-and A6 is not necessary. Some says A6 is necessary and AAAA should get
-deprecated.
-
-The draft tries to understand pros and cons between these two record
-types, and makes suggestions on deployment of IPv6 record type.
-
-The draft does not cover the use of bit string label and DNAME resource
-record (reverse mapping), as it seems that nibble form is well accepted
-in the community, newer formats have too much deployment costs, thus we
-see few need/voice that calls for migration. Refer to IETF50 dnsext
-working group minutes for more details.
-
-
-
-
-HAGINO Expires: January 19, 2002 [Page 1]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-1. A brief summary of the IPv6 resource record types
-
-1.1. AAAA record
-
-AAAA resource record is formatted as follows. DNS record type value for
-AAAA is 28 (assigned by IANA). Note that AAAA record is formatted as a
-fixed-length data.
-
- +------------+
- |IPv6 Address|
- | (16 octets)|
- +------------+
-
-With AAAA, we can define DNS records for IPv6 address resolution as
-follows, just like A records for IPv4.
-
- $ORIGIN X.EXAMPLE.
- N AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
- N AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
- N AAAA 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
-
-
-1.2. A6 record
-
-A6 resource record is formatted as follows. DNS record type value for
-A6 is 38 (assigned by IANA). Note that A6 record is formatted as a
-variable-length data.
-
- +-----------+------------------+-------------------+
- |Prefix len.| Address suffix | Prefix name |
- | (1 octet) | (0..16 octets) | (0..255 octets) |
- +-----------+------------------+-------------------+
-
-With A6, it is possible to define an IPv6 address by using multiple DNS
-records. Here is an example taken from RFC2874:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-HAGINO Expires: January 19, 2002 [Page 2]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
- $ORIGIN X.EXAMPLE.
- N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
- SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
- IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
- IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
-
- SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
- SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
-
- SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
-
- A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
-
- A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
-
- B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.
-
- C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
- D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
- E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
-
-If we translate the above into AAAA records, it will be as follows:
-
- $ORIGIN X.EXAMPLE.
- N AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
- N AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
- N AAAA 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
-
-It is also possible to use A6 records in ``non-fragmented'' manner, like
-below.
-
- $ORIGIN X.EXAMPLE.
- N A6 0 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
- N A6 0 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
- N A6 0 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
-
-There is a large design difference between A6 and AAAA. A6 imposes
-address resolutions tasks more to the resolver side, to reduce the
-amount of zone file maintenance cost. The complexity is in the resolver
-side. AAAA asks zone file maintainers to supply the full 128bit IPv6
-address in one record, and the resolver side can be implemented very
-simple.
-
-
-2. Deployment status
-
-2.1. Name servers/resolvers
-
-As of writing, AAAA is deployed pretty widely. BIND4 (since 4.9.4),
-BIND8, BIND9 and other implementations support AAAA, as both DNS servers
-and as resolver libraries. On the contrary, the author knows of only
-one DNS server/resolver implementation that supports A6; BIND9.
-
-
-HAGINO Expires: January 19, 2002 [Page 3]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-Almost all of the IPv6-ready operating systems ship with BIND4 or BIND8
-resolver library. [need to check situations with resolver libraries
-based on non-BIND code] Therefore, they cannot query A6 records (unless
-applications gets linked with BIND9 libraries explicitly).
-
-2.2. IPv6 network
-
-IPv6 network has been deployed widely since 1996. Though many of the
-participants consider it to be experimental, commercial IPv6 services
-has been deployed since around 1999, especially in Asian countries.
-Even today, there are numerous IPv6 networks operated just as serious as
-IPv4.
-
-2.3. DNS database
-
-There are no IPv6-reachable root DNS servers, partly because we have
-both AAAA and A6, and we are not decided about which is the one we would
-like to really deploy (so we cannot put IPv6 root NS records). The lack
-of IPv6-reachable root DNS servers is now preventing IPv6-only or
-IPv4/v6 dual stack network operations.
-
-At this moment, very small number of ccTLD registries accept
-registeration requests for IPv6 glue records. Many of the ccTLDs and
-gTLDs do not take IPv6 glue records, partly because of the lack of
-consensus between AAAA and A6. Again, the lack of IPv6 glue records is
-causing pain in IPv6-ready network operations. For example, JP ccTLD
-accepts IPv6 glue records and registers them as AAAA records. IPv6 NS
-records (with AAAA) works flawlessly from our experiences. For example,
-try the following commands to see how JP ccTLD registers IPv6 glue
-records (``/e'' is for English-language output):
-
- % whois -h whois.nic.ad.jp wide.ad.jp/e
- % whois -h whois.nic.ad.jp ns1.v6.wide.ad.jp/e
-
-
-3. Deploying DNS records
-
-At this moment, the following four strategies are proposed for the
-deployment of IPv6 DNS resource record; AAAA, fragmented A6 records,
-non-fragmented A6 records, and AAAA synthesis.
-
-3.1. AAAA records
-
-AAAA records have been used on IPv6 network (also known as 6bone) since
-it has started in 1996 and has been working just fine ever since. AAAA
-record is a straight extension of A record; it needs a single query-
-response roundtrip to resolve a name into an IPv6 address.
-
-A6 was proposed to add network renumbering friendliness to AAAA. With
-AAAA, a full 128bit IPv6 address needs to be supplied in a DNS resource
-record. Therefore, in the event of network renumber, administrators
-need to update the whole DNS zone file with the new IPv6 address
-
-
-HAGINO Expires: January 19, 2002 [Page 4]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-prefixes. We will discuss the issues with renumbering in a dedicated
-section.
-
-3.2. Fragmented A6 records
-
-If we are to use fragmented A6s (128bit splitted into multiple A6s), we
-have a lot of issues/worries.
-
-If we are to resolve IPv6 addresses using fragmented A6 records, we need
-to query DNS multiple times to resolve a single DNS name into an IPv6
-address. Since there has been no DNS record types that require multiple
-queries for resolution of the address itself, we have very little
-experience on such resource records.
-
-There will be more delays in name resolution compared to queries to
-A/AAAA records. If we define a record with more number of fragments,
-there will be more query roundtrips. There are only few possibilities
-to query fragments in parallel. In the above example, we can resolve
-A.NET.IP6.C.NET and A.NET.IP6.D.NET in parallel, but not others.
-
-At this moment, there is very little documents available, regarding to
-the relationship between DNS record TTL and the query delays. For
-example, if the DNS record TTL is smaller than the communication delays
-between the querier and the DNS servers, what should happen?
-
-o If we compute DNS record TTL based on the wallclock on the DNS server
- side, the DNS records are already expired and the querier will not be
- able to reassemble a complete IPv6 record. Worse, by setting up
- records with very low TTL, we can let recursive DNS resolvers to go
- into infinite loop by letting them chase a wrong A6 chain (see the
- section on security considration) [BIND 9.2.0snap: resolver does not
- go into infinite loop, meaning that BIND 9.2.0snap resolver does not
- really honor DNS record TTL during A6 reassembly].
-
-o If we compute it starting from the time the querier got the record, we
- will have some jitter in TTL computation among multiple queriers. If
- the query delays are long enough, the querier would end up having
- inconsistent A6 fragments, and the IPv6 address can be bogus after
- reassembly. With record types other than A6, we had no such problem,
- since we have never tried to reassemble an address out of multiple DNS
- records (with CNAME chain chasing a similar problem can arise, but the
- failure mode is much simpler to diagnose as the records are considered
- as an atomic entity).
-
-Some says that caches will avoid querying fragmented A6s again and
-again. However, most of the library resolver implementations do not
-cache anything. The traffic between library resolver and the first-hop
-nameserver will not be decreased by the cached records. The TTL problem
-(see above) is unavoidable for the library resolver without cache. [XXX
-will they interpret TTL field? BIND8 resolver does not]
-
-
-
-
-HAGINO Expires: January 19, 2002 [Page 5]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-If some of the fragments are DNSSEC-signed and some are not, how should
-we treat that address? RFC2874 section 6 briefly talks about it, not
-sure if complete answer is given.
-
-It is much harder to implement A6 fragment reassemble code, than to
-implement AAAA record resolver. AAAA record resolver can be implemented
-as a straight extension of A record resolver.
-
-o It is much harder to design timeout handling for the A6 reassembly.
- There would be multiple timeout parameters, including (1) communcation
- timeout for a single A6 fragment, (2) communcation timeout for the
- IPv6 address itself (total time needed for reassembly) and (3) TTL
- timeout for A6 fragment records.
-
-o In the case of library resolver implementation, it is harder to deal
- with exceptions (signals in UNIX case) for the large code fragment for
- resolvers.
-
-o When A6 prefix length field is not multiple of 8, address suffix
- portion needs to be shifted bitwise while A6 fragments are
- reassembled. Also, resolver implementations must be careful about
- overwraps of the bits. From our implementatation experiences, the
- logic gets very complex and we (unfortunately) expect to see a lot of
- security-critical bugs in the future.
-
-In RFC2874, a suggestion is made to use limited number of fragments per
-an IPv6 address. However, there is no protocol limitation defined. The
-lack makes it easier for malicious parties to impose DoS attacks using
-lots of A6 fragments (see the section on security consideration). [BIND
-9.2.0snap: The implementation limits the number of fragments within an
-A6 chain to be smaller than 16; It is not a protocol limitation but an
-implementation choice. Not sure if it is the right choice or not]
-
-With fragmented A6 records, in multi-prefix network configuration, it is
-not possible for us to limit the address on the DNS database to the
-specific set of records, like for load distribution purposes. Consider
-the following example. Even if we would like to advertise only
-2345:00D2:DA11:1:1234:5678:9ABC:DEF0 for N.X.EXAMPLE, it is not possible
-to do so. It becomes mandatory for us to define the whole IPv6 address
-by using ``A6 0'' for N.X.EXAMPLE, and in effect, the benefit of A6
-(renumber friendliness) goes away.
-
-
-
-
-
-
-
-
-
-
-
-
-
-HAGINO Expires: January 19, 2002 [Page 6]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
- ; with the following record we would advertise both records
- $ORIGIN X.EXAMPLE.
- N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
- M A6 64 ::2345:2345:2345:2345 SUBNET-1.IP6
- SUBNET-1.IP6 A6 0 2345:00C1:CA11:1::
- A6 0 2345:00D2:DA11:1::
-
- ; we need to do the following, jeopardizing renumbering
- ; friendliness for N.X.EXAMPLE
- $ORIGIN X.EXAMPLE.
- N A6 0 2345:00C1:CA11:1:1234:5678:9ABC:DEF0
- M A6 64 ::2345:2345:2345:2345 SUBNET-1.IP6
- SUBNET-1.IP6 A6 0 2345:00C1:CA11:1::
- A6 0 2345:00D2:DA11:1::
-
-A6 resource record type and A6 fragment/reassembly were introduced to
-help administrators on network renumber. When network gets renumbered,
-the administrator needs to update A6 fragment for the higher address
-bits (prefixes) only. Again, we will discuss the issues with
-renumbering in a dedicated section.
-
-
-3.3. Non-fragmented A6 records
-
-There are proposals to use non-fragmented A6 records in most of the
-places, like ``A6 0 <128bit>'', so that we would be able to switch to
-fragmented A6 records when we find a need for A6.
-
->From the packet format point of view, the approach has no benefit
-against AAAA. Rather, there is a one-byte overhead to every
-(unfragmented) A6 record compared to a AAAA record.
-
-If the nameserver/resolver programs hardcode A6 processing to handle no
-fragments, there will be no future possibility for us to introduce
-fragmented A6 records. When there is no need for A6 reassembly, there
-will be no code deployment, and even if the reassembly code gets
-deployed they will not be tested enough. The author believes that the
-``prepare for the future, use non-fragmented A6'' argument is not
-worthwhile.
-
-In the event of renumbering, non-fragmented A6 record has the same
-property as AAAA (the whole zone file has to be updated).
-
-3.4. AAAA synthesis (A6 and AAAA hybrid approach)
-
-At this moment, end hosts support AAAA records only. Some people would
-like to see A6 deployment in DNS databases even with the lack of end
-hosts support. To workaround the deployment issues of A6, the following
-approach is proposed in IETF50 dnsext working group slot. It is called
-``AAAA synthesis'' [Austein, 2001] :
-
-
-
-
-HAGINO Expires: January 19, 2002 [Page 7]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-o Deploy A6 DNS records worldwide. The proposal was not specific about
- whether we would deploy fragmented A6 records, or non-fragmented A6
- records (``A6 0'').
-
-o When a host queries AAAA record to a DNS server, the DNS server
- queries A6 fragments, reassemble it, and respond with a AAAA record.
-
-The approach needs to be diagnosed/specified in far more detail. For
-example, the following questions need to be answered:
-
-o What is the DNS error code against AAAA querier, if the A6 reassembly
- fails?
-
-o What TTL should the synthesized AAAA record have? [BIND 9.2.0snap
- uses TTL=0]
-
-o Which nameserver should synthesize the AAAA record, in the DNS
- recursize query chain? Is the synthesis mandatory for every DNS
- server implementation?
-
-o What should we do if the A6 reassembly takes too much time?
-
-o What should we do about DNSSEC signatures?
-
-o What if the resolver wants no synthesis? Do we want to have a flag
- bit in DNS packet, to enable/disable AAAA synthesis?
-
-o Relationships between A6 TTL, AAAA TTL, A6 query timeouts, AAAA query
- timeouts, and other timeout parameters?
-
-The approach seems to be vulnerable against DoS attacks, because the
-nameserver reassembles A6 fragments on behalf of the AAAA querier. See
-security consideration section for more details.
-
-3.5. Issues in keeping both AAAA and A6
-
-If we are to keep both AAAA and A6 records onto the worldwide DNS
-database, it would impose more query delays to the client resolvers.
-Suppose we have a dual-stack host implementation. If they need to
-resolve a name into addresses, the node would need to query in the
-following order (in the order which RFC2874 suggests):
-
-o Query A6 records, and get full IPv6 addresses by chasing and
- reassembling A6 fragment chain.
-
-o Query AAAA records.
-
-o Query A records.
-
-o Sort the result based on destination address ordering rule. An
- example of the ordering rule is presented as a draft [Draves, 2001] .
-
-
-
-HAGINO Expires: January 19, 2002 [Page 8]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-o Contact the destination addresses in sequence.
-
-The ordering imposes additional delays to the resolvers. The above
-ordering would be necessary for all approaches that use A6, as there are
-existing AAAA records in the world.
-
-
-4. Network renumbering
-
-Some says that there will be more frequent renumbers in IPv6 network
-operation, and A6 is necessary to reduce the zone modification cost as
-well as zone signing costs on renumber operation.
-
-It is not clear if we really want to renumber that frequently. With
-IPv6, it should be easier for ISPs to assign addresses statically to the
-downstream customers, rather than dynamically like we do in IPv4 dialup
-connectivity today. If ISPs do assign static IPv6 address block to the
-customers, there is no need to renumber customer network that frequently
-(unless the customer decides to switch the upstream ISPs that often).
-NOTE: Roaming dialup users, like those who carry laptop computers
-worldwide, seems to have a different issue from stationary dialup users.
-See [Hagino, 2000] for more discussions.
-
-It is questionable if it is possible to renumber IPv6 networks more
-frequently than with IPv4. Router renumbering protocol [Crawford, 2000]
-, IPv6 host autoconfiguration and IPv6 address lifetime [Thomson, 1998]
-can help us renumber the IPv6 network, however, network renumbering
-itself is not an easy task. If you would like to maintain reachability
-from the outside world, a site administrator needs to carefully
-coordinate site renumber. The minimal interval between renumber is
-restricted by DNS record timeouts, as DNS records will be cached around
-the world. If the TTL of DNS records are X, the interval between
-renumber must be longer than 2 * X. If we consider clients/servers that
-tries to validate addresses using reverse lookups, we also need to care
-about the relationship between IPv6 address lifetime [Thomson, 1998] and
-the interval between renumber. At IETF50 ipngwg session, there was a
-presentation by JINMEI Tatsuya regarding to site renumbering experiment.
-It is recommend to read through the IETF49 minutes and slides. [XXX
-Fred Baker had a draft on this - where?] For the network renumbering to
-be successful, no configuration files should have hardcoded (numeric) IP
-addresses. It is a very hard requirement to meet. We fail to satisfy
-this in many of the network renumbering events, and the failure causes a
-lot of troubles.
-
-At this moment there is no mechanism defined for ISPs to renumber
-downstream customers at will. Even though it may sound interesting for
-ISPs, it would cause a lot of (social and political) issues in doing so,
-so the author would say it is rather unrealistic to pursue this route.
-The only possible candidate, router renumbering protocol [Crawford,
-2000] does not really fit into the situation. The protocol is defined
-using IPsec authentication over site-local multicast packets. It would
-be cumbersome to run router renumbering protocol across multiple
-
-
-HAGINO Expires: January 19, 2002 [Page 9]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-administrative domains, as (1) customers will not want to share IPsec
-authentication key for routers with the upstream ISP, and (2) customer
-network will be administered as a separate site from the upstream ISP
-(Even though router renumbering protocol could be used with unicast
-addresess, it is not realistic to assume that we can maintain the list
-of IPv6 addresses for all the routers in both customers' and ISPs'
-networks).
-
-A6 was designed to help administators update zone files during network
-renumbering events. Even with AAAA, zone file modification itself is
-easy; you can just query-replace the addresses in the zone files. The
-difficulty of network renumber comes from elsewhere.
-
-With AAAA, we need to sign the whole zone again with DNSSEC keys, after
-renumbering the network. With A6, we need to sign upper bits only with
-DNSSEC keys. Therefore, A6 will impose less zone signing cost on the
-event of network renumbering. As seen above, it is questionable if we
-renumber network that often, so it is questionable if A6 brings us an
-overall benefit. Note, however, even if we use A6 to facilitate more
-frequent renumbering and lower signing cost, all glue records has to be
-installed as non-fragmented A6 records (``A6 0''), and required to be
-signed again on renumbering events.
-
-
-5. Security consideration
-
-There are a couple of security worries mentioned in the above. To give
-a brief summary:
-
-o There will be a higher delay imposed by query/reply roundtrips for
- fragmented A6 records. This could affect every services that relies
- upon DNS records.
-
-o There is no upper limit defined for the number of A6 fragments for
- defining an IPv6 address. Malicious parties may try to put a very
- complex A6 chains and confuse nameservers worldwide.
-
-o A6 resolver/nameserver is much harder to implement correctly than AAAA
- resolver/nameserver. A6 fragment reassembly code needs to take care
- of bitwise data reassembly, bitwise overwrap checks, and others. From
- our implementatation experiences, we expect to see a lot of security-
- issue bugs in the future.
-
-o Interaction between DNS record TTL and the DNS query delays leads to
- non-trivial timeout problem.
-
-We would like to go into more details for some of these.
-
-5.1. DoS attacks against AAAA synthesis
-
-When a DNS server is configured for AAAA synthesis, malicious parties
-can impose DoS attacks using the interaction between DNS TTL and query
-
-
-HAGINO Expires: January 19, 2002 [Page 10]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-delays. The attack can chew CPU time and/or memory, as well as some
-network bandwidth on a victim nameserver, by the following steps:
-
-o A bad guy configures a record with very complex A6 chain, onto some
- nameservers. (the bad guy has to have controls over the servers).
- The nameservers can be located anywhere in the world. The A6 chain
- should have a very low TTL (like 1 or 0 seconds). The attack works
- better if we have higher delays between the victim nameservers and the
- nameservers that serve A6 fragments.
-
-o The bad guy queries the record using AAAA request, to the victim
- nameserver.
-
-o The victim nameserver will try to reassemble A6 fragments. During the
- reassembly process, the victim nameserver puts A6 fragments into the
- local cache. The cached records will expire during the reassembly
- process. The nameserver will need to query a lot of A6 fragments
- (more traffic). The server can go into an infinite loop, if it tries
- to query the expired A6 fragments again.
-
-Note, however, this problem could be considered as a problem in
-recursize resolvers in general (like CNAME and NS chasing); A6 and AAAA
-synthesis makes the problem more apparent, and more complex to diagnose.
-
-To remedy this problem, we have a couple of solutions:
-
-(1) Deprecate A6 and deploy AAAA worldwide. If we do not have A6, the
- problem goes away.
-
-(2) Even if we use A6, do not configure nameservers for AAAA synthesis.
- Deployment issues with existing IPv6 hosts get much harder.
-
-(3) Impose a protocol limitation to the number of A6 fragments.
-
-(4) Do not query the expired records in A6 chain again. In other words,
- implement resolvers that ignore TTL on DNS records. Not sure if it
- is the right thing to do.
-
-
-6. Conclusion
-
-NOTE: the section expresses the impressions of the author.
-
-A6/AAAA discussion has been an obstacle for IPv6 deployment, as the
-deployment of IPv6 NS recodrs have been deferred because of the
-discussion. The author do not see benefit in keeping both AAAA and A6
-records, as it imposes more query delays to the clients. So the author
-believes that we need to pick one of them.
-
-Given the unlikeliness of frequent network renumbering, the author
-believes that the A6's benefit in lower zone signing cost is not
-significant. The benefit of A6 (in zone signing cost) is much less than
-
-
-HAGINO Expires: January 19, 2002 [Page 11]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-the expected complication that will be imposed by A6 operations.
-
->From the above discussions, the author suggests to keep AAAA and
-deprecate A6 (move A6 document to historic state). The author believes
-that A6 can cause a lot of problem than the benefits it may have. A6
-will make IPv6 DNS operation more complicated and vulnerable to attacks.
-AAAA is proven to work right in our IPv6 network operation since 1996.
-AAAA has been working just fine in existing IPv6 networks, and the
-author believes that it will in the coming days.
-
-
-
-References
-
-Thomson, 1995.
-S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
-RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt.
-
-Crawford, 2000.
-M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6
-Address Aggregation and Renumbering" in RFC2874 (July 2000).
-ftp://ftp.isi.edu/in-notes/rfc2874.txt.
-
-Austein, 2001.
-R. Austein, "Tradeoffs in DNS support for IPv6" in draft-ietf-dnsext-
-ipv6-dns-tradeoffs-00.txt (July 2001). work in progress material.
-
-Draves, 2001.
-Richard Draves, "Default Address Selection for IPv6" in draft-ietf-
-ipngwg-default-addr-select-04.txt (May 2001). work in progress material.
-
-Hagino, 2000.
-Jun-ichiro Hagino and Kazu Yamamoto, "Requirements for IPv6 dialup PPP
-operation" in draft-itojun-ipv6-dialup-requirement-00.txt (July 2000).
-work in progress material.
-
-Crawford, 2000.
-Matt Crawford, "Router Renumbering for IPv6" in RFC2894 (August 2000).
-ftp://ftp.isi.edu/in-notes/rfc2894.txt.
-
-Thomson, 1998.
-S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration" in
-RFC2462 (December 1998). ftp://ftp.isi.edu/in-notes/rfc2462.txt.
-
-
-Change history
-
-none.
-
-
-
-
-
-
-HAGINO Expires: January 19, 2002 [Page 12]
-\f
-
-DRAFT Comparison of AAAA and A6 July 2001
-
-Acknowledgements
-
-The draft was written based on discussions in IETF IPv6 and dnsext
-working groups, and help from WIDE research group.
-
-
-Author's address
-
- Jun-ichiro itojun HAGINO
- Research Laboratory, Internet Initiative Japan Inc.
- Takebashi Yasuda Bldg.,
- 3-13 Kanda Nishiki-cho,
- Chiyoda-ku,Tokyo 101-0054, JAPAN
- Tel: +81-3-5259-6350
- Fax: +81-3-5259-6351
- Email: itojun@iijlab.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-HAGINO Expires: January 19, 2002 [Page 13]
-\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Peter Koch
-Expires: September 2001 Universitaet Bielefeld
-Updates: RFC 1035 March 2001
-
- A DNS RR Type for Lists of Address Prefixes (APL RR)
- draft-ietf-dnsext-apl-rr-02.txt
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- Comments should be sent to the author or the DNSEXT WG mailing list
- <namedroppers@OPS.IETF.ORG>.
-
-Abstract
-
- The Domain Name System is primarily used to translate domain names
- into IPv4 addresses using A RRs. Several approaches exist to describe
- networks or address ranges. This document specifies a new DNS RR type
- "APL" for address prefix lists.
-
-1. Conventions used in this document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- Domain names herein are for explanatory purposes only and should not
- be expected to lead to useful information in real life [RFC2606].
-
-
-
-
-Koch Expires September 2001 [Page 1]
-\f
-INTERNET-DRAFT DNS APL RR March 2001
-
-
-2. Background
-
- The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
- associate addresses and other Internet infrastructure elements with
- hierarchically built domain names. Various types of resource records
- have been defined, especially those for IPv4 and IPv6 [RFC2874]
- addresses. In [RFC1101] a method is described to publish information
- about the address space allocated to an organisation. In older BIND
- versions, a weak form of controlling access to zone data was
- implemented using TXT RRs describing address ranges.
-
- This document specifies a new RR type for address prefix lists.
-
-3. APL RR Type
-
- An APL record has the DNS type of "APL" [draft, IANA: not yet applied
- for] and a numeric value of [draft, IANA:to be assigned]. The APL RR
- is defined in the IN class only. APL RRs cause no additional section
- processing.
-
-4. APL RDATA format
-
- The RDATA section consists of zero or more items (<apitem>) of the
- form
-
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- | ADDRESSFAMILY |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- | PREFIX | N | AFDLENGTH |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
- / AFDPART /
- | |
- +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
-
-
- ADDRESSFAMILY 16 bit unsigned value as assigned by IANA
- (see IANA Considerations)
- PREFIX 8 bit unsigned binary coded prefix length.
- Upper and lower bounds and interpretation of
- this value are address family specific.
- N negation flag, indicates the presence of the
- "!" character in the textual format. It has
- the value "1" if the "!" was given, "0" else.
- AFDLENGTH length in octets of the following address
- family dependent part (7 bit unsigned).
- AFDPART address family dependent part. See below.
-
-
-
-
-
-Koch Expires September 2001 [Page 2]
-\f
-INTERNET-DRAFT DNS APL RR March 2001
-
-
- This document defines the AFDPARTs for address families 1 (IPv4) and
- 2 (IPv6). Future revisions may deal with additional address
- families.
-
-4.1. AFDPART for IPv4
-
- The encoding of an IPv4 address (address family 1) follows the
- encoding specified for the A RR by [RFC1035], section 3.4.1.
-
- PREFIX specifies the number of bits of the IPv4 address starting at
- the most significant bit. Legal values range from 0 to 32.
-
- Trailing zero octets do not bear any information (e.g. there is no
- semantic difference between 10.0.0.0/16 and 10/16) in an address
- prefix, so the shortest possible AFDLENGTH can be used to encode it.
- However, for DNSSEC [RFC2535] a single wire encoding must be used by
- all. Therefore the sender MUST NOT include trailing zero octets in
- the AFDPART regardless of the value of PREFIX. This includes cases in
- which AFDLENGTH times 8 results in a value less than PREFIX. The
- AFDPART is padded with zero bits to match a full octet boundary.
-
- An IPv4 AFDPART has a variable length of 0 to 4 octets.
-
-4.2. AFDPART for IPv6
-
- The 128 bit IPv6 address (address family 2) is encoded in network
- byte order (high-order byte first).
-
- PREFIX specifies the number of bits of the IPv6 address starting at
- the most significant bit. Legal values range from 0 to 128.
-
- With the same reasoning as in 4.1 above, the sender MUST NOT include
- trailing zero octets in the AFDPART regardless of the value of
- PREFIX. This includes cases in which AFDLENGTH times 8 results in a
- value less than PREFIX. The AFDPART is padded with zero bits to
- match a full octet boundary.
-
- An IPv6 AFDPART has a variable length of 0 to 16 octets.
-
-5. Zone File Syntax
-
- The textual representation of an APL RR in a DNS zone file is as
- follows:
-
- <owner> IN <TTL> APL {[!]afi:address/prefix}*
-
- The data consists of zero or more strings of the address family
- indicator <afi>, immediately followed by a colon ":", an address,
-
-
-
-Koch Expires September 2001 [Page 3]
-\f
-INTERNET-DRAFT DNS APL RR March 2001
-
-
- immediately followed by the "/" character, immediately followed by a
- decimal numeric value for the prefix length. Any such string may be
- preceded by a "!" character. The strings are separated by whitespace.
- The <afi> is the decimal numeric value of that particular address
- family.
-
-5.1. Textual Representation of IPv4 Addresses
-
- An IPv4 address in the <address> part of an <apitem> is in dotted
- quad notation, just as in an A RR. The <prefix> has values from the
- interval 0..32 (decimal).
-
-5.2. Textual Representation of IPv6 Addresses
-
- The representation of an IPv6 address in the <address> part of an
- <apitem> follows [RFC2373], section 2.2. Legal values for <prefix>
- are from the interval 0..128 (decimal).
-
-6. APL RR usage
-
- An APL RR with empty RDATA is valid and implements an empty list.
- Multiple occurrences of the same <apitem> in a single APL RR are
- allowed and MUST NOT be merged by a DNS server or resolver. <apitems>
- MUST be kept in order and MUST NOT be rearranged or aggregated.
-
- A single APL RR may contain <apitems> belonging to different address
- families. The maximum number of <apitems> is upper bounded by the
- available RDATA space.
-
- RRSets consisting of more than one APL RR are legal but the
- interpretation is left to the particular application.
-
-7. Applicability Statement
-
- The APL RR defines a framework without specifying any particular
- meaning for the list of prefixes. It is expected that APL RRs will
- be used in different application scenarios which have to be
- documented separately. Those scenarios may be distinguished by
- characteristic prefixes placed in front of the DNS owner name.
-
- An APL application specification MUST include information on
-
- o the characteristic prefix, if any
-
- o how to interpret APL RRSets consisting of more than one RR
-
- o how to interpret an empty APL RR
-
-
-
-
-Koch Expires September 2001 [Page 4]
-\f
-INTERNET-DRAFT DNS APL RR March 2001
-
-
- o which address families are expected to appear in the APL RRs for
- that application
-
- o how to deal with APL RR list elements which belong to other
- address families, including those not yet defined
-
- o the exact semantics of list elements negated by the "!" character
-
- Possible applications include the publication of address ranges
- similar to [RFC1101], description of zones built following [RFC2317]
- and in-band access control to limit general access or zone transfer
- (AXFR) availability for zone data held in DNS servers.
-
- The specification of particular application scenarios is out of the
- scope of this document.
-
-8. Examples
-
- The following examples only illustrate some of the possible usages
- outlined in the previous section. None of those applications are
- hereby specified nor is it implied that any particular APL RR based
- application does exist now or will exist in the future.
-
- ; RFC 1101-like announcement of address ranges for foo.example
- foo.example. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
-
- ; CIDR blocks covered by classless delegation
- 42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26
- 1:192.168.42.128/25 )
-
- ; Zone transfer restriction
- _axfr.sbo.example. IN APL 1:127.0.0.1/32 1:172.16.64.0/22
-
- ; List of address ranges for multicast
- multicast.example. IN APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8
-
- Note that since trailing zeroes are ignored in the first APL RR the
- AFDLENGTH of both <apitems> is three.
-
-9. Security Considerations
-
- Any information obtained from the DNS should be regarded as unsafe
- unless techniques specified in [RFC2535] or [RFC2845] were used. The
- definition of a new RR type does not introduce security problems into
- the DNS, but usage of information made available by APL RRs may
- compromise security. This includes disclosure of network topology
- information and in particular the use of APL RRs to construct access
- control lists.
-
-
-
-Koch Expires September 2001 [Page 5]
-\f
-INTERNET-DRAFT DNS APL RR March 2001
-
-
-10. IANA Considerations
-
- This section is to be interpreted as following [RFC2434].
-
- This document does not define any new namespaces. It uses the 16 bit
- identifiers for address families maintained by IANA in
- http://www.iana.org/numbers.html.
-
- IANA is asked to assign a numeric RR type value for APL.
-
-11. Acknowledgements
-
- The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed
- Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review
- and constructive comments.
-
-12. References
-
-
- [RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities",
- RFC 1034, STD 13, November 1987
-
- [RFC1035] Mockapetris,P., "Domain Names - Implementation and
- Specification", RFC 1035, STD 13, November 1987
-
- [RFC1101] Mockapetris,P., "DNS Encoding of Network Names and Other
- Types", RFC 1101, April 1989
-
- [RFC2119] Bradner,S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, BCP 14, March 1997
-
- [RFC2181] Elz,R., Bush,R., "Clarifications to the DNS
- Specification", RFC 2181, July 1997
-
- [RFC2317] Eidnes,H., de Groot,G., Vixie,P., "Classless IN-ADDR.ARPA
- delegation", RFC 2317, March 1998
-
- [RFC2373] Hinden,R., Deering,S., "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998
-
- [RFC2434] Narten,T., Alvestrand,H., "Guidelines for Writing an IANA
- Considerations Section in RFCs", RFC 2434, BCP 26, October
- 1998
-
- [RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC
- 2535, March 1999
-
-
-
-
-
-Koch Expires September 2001 [Page 6]
-\f
-INTERNET-DRAFT DNS APL RR March 2001
-
-
- [RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names",
- RFC 2606, BCP 32, June 1999
-
- [RFC2845] Vixie,P., Gudmundsson,O., Eastlake,D., Wellington,B.,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000
-
- [RFC2874] Crawford,M., Huitema,C., "DNS Extensions to Support IPv6
- Address Aggregation and Renumbering", RFC 2874, July 2000
-
-
-
-13. Author's Address
-
- Peter Koch
- Universitaet Bielefeld
- Technische Fakultaet
- D-33594 Bielefeld
- Germany
- +49 521 106 2902
- <pk@TechFak.Uni-Bielefeld.DE>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Koch Expires September 2001 [Page 7]
+++ /dev/null
-A new Request for Comments is now available in online RFC libraries.
-
-
- RFC 3492
-
- Title: Punycode: A Bootstring encoding of Unicode
- for Internationalized Domain Names in Applications
- (IDNA)
- Author(s): A. Costello
- Status: Standards Track
- Date: March 2003
- Mailbox: http://www.nicemice.net/amc/
- Pages: 35
- Characters: 67439
- Updates/Obsoletes/SeeAlso: None
-
- I-D Tag: draft-ietf-idn-punycode-03.txt
-
- URL: ftp://ftp.rfc-editor.org/in-notes/rfc3492.txt
-
-
-Punycode is a simple and efficient transfer encoding syntax designed
-for use with Internationalized Domain Names in Applications
-(IDNA). It uniquely and reversibly transforms a Unicode string into
-an ASCII string. ASCII characters in the Unicode string are
-represented literally, and non-ASCII characters are represented by
-ASCII characters that are allowed in host name labels (letters,
-digits, and hyphens). This document defines a general algorithm
-called Bootstring that allows a string of basic code points to
-uniquely represent any string of code points drawn from a larger set.
-Punycode is an instance of Bootstring that uses particular parameter
-values specified by this document, appropriate for IDNA.
-
-This document is a product of the Internationalized Domain Name
-Working Group of the IETF.
-
-This is now a Proposed Standard Protocol.
-
-This document specifies an Internet standards track protocol for
-the Internet community, and requests discussion and suggestions
-for improvements. Please refer to the current edition of the
-"Internet Official Protocol Standards" (STD 1) for the
-standardization state and status of this protocol. Distribution
-of this memo is unlimited.
-
-This announcement is sent to the IETF list and the RFC-DIST list.
-Requests to be added to or deleted from the IETF distribution list
-should be sent to IETF-REQUEST@IETF.ORG. Requests to be
-added to or deleted from the RFC-DIST distribution list should
-be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
-
-Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
-an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
-help: ways_to_get_rfcs. For example:
-
- To: rfc-info@RFC-EDITOR.ORG
- Subject: getting rfcs
-
- help: ways_to_get_rfcs
-
-Requests for special distribution should be addressed to either the
-author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
-specifically noted otherwise on the RFC itself, all RFCs are for
-unlimited distribution.echo
-Submissions for Requests for Comments should be sent to
-RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
-Authors, for further information.
-
+++ /dev/null
-
-IPng Working Group Matt Crawford
-Internet Draft Fermilab
- Christian Huitema
- Susan Thomson
- Telcordia
- May 17, 2000
-
- DNS Extensions to Support IPv6 Address Aggregation and Renumbering
- <draft-ietf-ipngwg-dns-lookups-08.txt>
-
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026. Internet-Drafts are
- working documents of the Internet Engineering Task Force (IETF), its
- areas, and its working groups. Note that other groups may also
- distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other documents
- at any time. It is inappropriate to use Internet- Drafts as
- reference material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-1. Abstract
-
- This document defines changes to the Domain Name System to support
- renumberable and aggregatable IPv6 addressing. The changes include
- a new resource record type to store an IPv6 address in a manner
- which expedites network renumbering and updated definitions of
- existing query types that return Internet addresses as part of
- additional section processing.
-
- For lookups keyed on IPv6 addresses (often called reverse lookups),
- this document defines a new zone structure which allows a zone to be
- used without modification for parallel copies of an address space
- (as for a multihomed provider or site) and across network
- renumbering events.
-
-
-
-
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 1]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-Status of this Memo ............................................... 1
-
-1. Abstract ...................................................... 1
-
-2. Introduction .................................................. 3
-
-3. Overview ...................................................... 4
- 3.1. Name-to-Address Lookup .................................. 4
- 3.2. Underlying Mechanisms for Reverse Lookups ............... 4
- 3.2.1. Delegation on Arbitrary Boundaries ................ 4
- 3.2.2. Reusable Zones .................................... 5
-
-4. Specifications ................................................ 6
- 4.1. The A6 Record Type ...................................... 6
- 4.1.1. Format ............................................ 6
- 4.1.2. Processing ........................................ 6
- 4.1.3. Textual Representation ............................ 7
- 4.1.4. Name Resolution Procedure ......................... 7
- 4.2. Zone Structure for Reverse Lookups ...................... 8
-
-5. Modifications to Existing Query Types ......................... 8
-
-6. Usage Illustrations ........................................... 9
- 6.1. A6 Record Chains ........................................ 9
- 6.1.1. Authoritative Data ................................ 10
- 6.1.2. Glue .............................................. 10
- 6.1.3. Variations ........................................ 12
- 6.2. Reverse Mapping Zones ................................... 13
- 6.2.1. The TLA level ..................................... 13
- 6.2.2. The ISP level ..................................... 14
- 6.2.3. The Site Level .................................... 14
- 6.3. Lookups ................................................. 14
- 6.4. Operational Note ........................................ 15
-
-7. Transition from RFC 1886 and Deployment Notes ................. 16
- 7.1. Transition from AAAA and Coexistence with A Records ..... 17
- 7.2. Transition from Nibble Labels to Binary Labels .......... 17
-
-8. Security Considerations ....................................... 18
-
-9. IANA Considerations ........................................... 18
-
-10. Acknowledgments .............................................. 18
-
-11. References ................................................... 19
-
-12. Authors' Addresses ........................................... 20
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 2]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-2. Introduction
-
- Maintenance of address information in the DNS is one of several
- obstacles which have prevented site and provider renumbering from
- being feasible in IP version 4. Arguments about the importance of
- network renumbering for the preservation of a stable routing system
- and for other purposes may be read in documents cited here as
- [RENUM]. To support the storage of IPv6 addresses without impeding
- renumbering we define the following extensions.
-
- o A new resource record type, "A6", is defined to map a domain
- name to an IPv6 address, with a provision for indirection for
- leading "prefix" bits.
-
- o Existing queries that perform additional section processing to
- locate IPv4 addresses are redefined to do that processing for
- both IPv4 and IPv6 addresses.
-
- o A new domain, IP6.ARPA, is defined to support lookups based on
- IPv6 address.
-
- o A new prefix-delegation method is defined, relying on new DNS
- features [BITLBL, DNAME].
-
- The changes are designed to be compatible with existing application
- programming interfaces. The existing support for IPv4 addresses is
- retained. Transition issues related to the coexistence of both IPv4
- and IPv6 addresses in DNS are discussed in [TRANS].
-
- This memo proposes a replacement for the specification in RFC 1886
- and a departure from current implementation practices. The changes
- are designed to facilitate network renumbering and multihoming.
- Domains employing the A6 record for IPv6 addresses can insert
- automatically-generated AAAA records in zone files to ease
- transition. It is expected that after a reasonable period, RFC 1886
- will become Historic.
-
- The next three major sections of this document are an overview of
- the facilities defined or employed by this specification, the
- specification itself, and examples of use.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [KWORD]. The key
- word "SUGGESTED" signifies a strength between MAY and SHOULD: it is
- believed that compliance with the suggestion has tangible benefits
- in most instances.
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 3]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-3. Overview
-
- This section provides an overview of the DNS facilities for storage
- of IPv6 addresses and for lookups based on IPv6 address, including
- those defined here and elsewhere.
-
-
-3.1. Name-to-Address Lookup
-
- IPv6 addresses are stored in one or more A6 resource records. A
- single A6 record may include a complete IPv6 address, or a
- contiguous portion of an address and information leading to one or
- more prefixes. Prefix information comprises a prefix length and a
- DNS name which is in turn the owner of one or more A6 records
- defining the prefix or prefixes which are needed to form one or more
- complete IPv6 addresses. When the prefix length is zero, no DNS
- name is present and all the leading bits of the address are
- significant. There may be multiples levels of indirection and the
- existence of multiple A6 records at any level multiplies the number
- of IPv6 addresses which are formed.
-
- An application looking up an IPv6 address will generally cause the
- DNS resolver to access several A6 records, and multiple IPv6
- addresses may be returned even if the queried name was the owner of
- only one A6 record. The authenticity of the returned address(es)
- cannot be directly verified by DNS Security [DNSSEC]. The A6
- records which contributed to the address(es) may of course be
- verified if signed.
-
- Implementers are reminded of the necessity to limit the amount of
- work a resolver will perform in response to a client request. This
- principle MUST be extended to also limit the generation of DNS
- requests in response to one name-to-address (or address-to-name)
- lookup request.
-
-
-3.2. Underlying Mechanisms for Reverse Lookups
-
- This section describes the new DNS features which this document
- exploits. This section is an overview, not a specification of those
- features. The reader is directed to the referenced documents for
- more details on each.
-
-
-3.2.1. Delegation on Arbitrary Boundaries
-
- This new scheme for reverse lookups relies on a new type of DNS
- label called the "bit-string label" [BITLBL]. This label compactly
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 4]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- represents an arbitrary string of bits which is treated as a
- hierarchical sequence of one-bit domain labels. Resource records
- can thereby be stored at arbitrary bit-boundaries.
-
- Examples in section 6 will employ the following textual
- representation for bit-string labels, which is a subset of the
- syntax defined in [BITLBL]. A base indicator "x" for hexadecimal
- and a sequence of hexadecimal digits is enclosed between "\[" and
- "]". The bits denoted by the digits represent a sequence of one-bit
- domain labels ordered from most to least significant. (This is the
- opposite of the order they would appear if listed one bit at a time,
- but it appears to be a convenient notation.) The digit string may
- be followed by a slash ("/") and a decimal count. If omitted, the
- implicit count is equal to four times the number of hexadecimal
- digits.
-
- Consecutive bit-string labels are equivalent (up to the limit
- imposed by the size of the bit count field) to a single bit-string
- label containing all the bits of the consecutive labels in the
- proper order. As an example, either of the following domain names
- could be used in a QCLASS=IN, QTYPE=PTR query to find the name of
- the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
-
- \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.
-
- \[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
-
-
-
-3.2.2. Reusable Zones
-
- DNS address space delegation is implemented not by zone cuts and NS
- records, but by a new analogue to the CNAME record, called the DNAME
- resource record [DNAME]. The DNAME record provides alternate naming
- to an entire subtree of the domain name space, rather than to a
- single node. It causes some suffix of a queried name to be
- substituted with a name from the DNAME record's RDATA.
-
- For example, a resolver or server providing recursion, while looking
- up a QNAME a.b.c.d.e.f may encounter a DNAME record
-
- d.e.f. DNAME w.xy.
-
- which will cause it to look for a.b.c.w.xy.
-
-
-
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 5]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-4. Specifications
-
-
-4.1. The A6 Record Type
-
- The A6 record type is specific to the IN (Internet) class and has
- type number 38 (decimal).
-
-
-4.1.1. Format
-
- The RDATA portion of the A6 record contains two or three fields.
-
- +-----------+------------------+-------------------+
- |Prefix len.| Address suffix | Prefix name |
- | (1 octet) | (0..16 octets) | (0..255 octets) |
- +-----------+------------------+-------------------+
-
-
- o A prefix length, encoded as an eight-bit unsigned integer with
- value between 0 and 128 inclusive.
-
- o An IPv6 address suffix, encoded in network order (high-order
- octet first). There MUST be exactly enough octets in this field
- to contain a number of bits equal to 128 minus prefix length,
- with 0 to 7 leading pad bits to make this field an integral
- number of octets. Pad bits, if present, MUST be set to zero
- when loading a zone file and ignored (other than for SIG
- [DNSSEC] verification) on reception.
-
- o The name of the prefix, encoded as a domain name. By the rules
- of [DNSIS], this name MUST NOT be compressed.
-
- The domain name component SHALL NOT be present if the prefix length
- is zero. The address suffix component SHALL NOT be present if the
- prefix length is 128.
-
- It is SUGGESTED that an A6 record intended for use as a prefix for
- other A6 records have all the insignificant trailing bits in its
- address suffix field set to zero.
-
-
-4.1.2. Processing
-
- A query with QTYPE=A6 causes type A6 and type NS additional section
- processing for the prefix names, if any, in the RDATA field of the
- A6 records in the answer section. This processing SHOULD be
- recursively applied to the prefix names of A6 records included as
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 6]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- additional data. When space in the reply packet is a limit,
- inclusion of additional A6 records takes priority over NS records.
-
- It is an error for a A6 record with prefix length L1 > 0 to refer to
- a domain name which owns a A6 record with a prefix length L2 > L1.
- If such a situation is encountered by a resolver, the A6 record with
- the offending (larger) prefix length MUST be ignored. Robustness
- precludes signaling an error if addresses can still be formed from
- valid A6 records, but it is SUGGESTED that zone maintainers from
- time to time check all the A6 records their zones reference.
-
-
-4.1.3. Textual Representation
-
- The textual representation of the RDATA portion of the A6 resource
- record in a zone file comprises two or three fields separated by
- whitespace.
-
- o A prefix length, represented as a decimal number between 0 and
- 128 inclusive,
-
- o the textual representation of an IPv6 address as defined in
- [AARCH] (although some leading and/or trailing bits may not be
- significant),
-
- o a domain name, if the prefix length is not zero.
-
- The domain name MUST be absent if the prefix length is zero. The
- IPv6 address MAY be be absent if the prefix length is 128. A number
- of leading address bits equal to the prefix length SHOULD be zero,
- either implicitly (through the :: notation) or explicitly, as
- specified in section 4.1.1.
-
-
-4.1.4. Name Resolution Procedure
-
- To obtain the IPv6 address or addresses which belong to a given
- name, a DNS client MUST obtain one or more complete chains of A6
- records, each chain beginning with a record owned by the given name
- and including a record owned by the prefix name in that record, and
- so on recursively, ending with an A6 record with a prefix length of
- zero. One IPv6 address is formed from one such chain by taking the
- value of each bit position from the earliest A6 record in the chain
- which validly covers that position, as indicated by the prefix
- length. The set of all IPv6 addresses for the given name comprises
- the addresses formed from all complete chains of A6 records
- beginning at that name, discarding records which have invalid prefix
- lengths as defined in section 4.1.2.
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 7]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- If some A6 queries fail and others succeed, a client might obtain a
- non-empty but incomplete set of IPv6 addresses for a host. In many
- situations this may be acceptable. The completeness of a set of A6
- records may always be determined by inspection.
-
-
-4.2. Zone Structure for Reverse Lookups
-
- Very little of the new scheme's data actually appears under
- IP6.ARPA; only the first level of delegation needs to be under that
- domain. More levels of delegation could be placed under IP6.ARPA if
- some top-level delegations were done via NS records instead of DNAME
- records, but this would incur some cost in renumbering ease at the
- level of TLAs [AGGR]. Therefore, it is declared here that all
- address space delegations SHOULD be done by the DNAME mechanism
- rather than NS.
-
- In addition, since uniformity in deployment will simplify
- maintenance of address delegations, it is SUGGESTED that address and
- prefix information be stored immediately below a DNS label "IP6".
- Stated another way, conformance with this suggestion would mean that
- "IP6" is the first label in the RDATA field of DNAME records which
- support IPv6 reverse lookups.
-
- When any "reserved" or "must be zero" bits are adjacent to a
- delegation boundary, the higher-level entity MUST retain those bits
- in its own control and delegate only the bits over which the lower-
- level entity has authority.
-
- To find the name of a node given its IPv6 address, a DNS client MUST
- perform a query with QCLASS=IN, QTYPE=PTR on the name formed from
- the 128 bit address as one or more bit-string labels [BITLBL],
- followed by the two standard labels "IP6.ARPA". If recursive
- service was not obtained from a server and the desired PTR record
- was not returned, the resolver MUST handle returned DNAME records as
- specified in [DNAME], and NS records as specified in [DNSCF], and
- iterate.
-
-
-5. Modifications to Existing Query Types
-
- All existing query types that perform type A additional section
- processing, i.e. the name server (NS), mail exchange (MX), and
- mailbox (MB) query types, and the experimental AFS data base (AFSDB)
- and route through (RT) types, must be redefined to perform type A,
- A6 and AAAA additional section processing, with type A having the
- highest priority for inclusion and type AAAA the lowest. This
- redefinition means that a name server may add any relevant IPv4 and
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 8]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- IPv6 address information available locally to the additional section
- of a response when processing any one of the above queries. The
- recursive inclusion of A6 records referenced by A6 records already
- included in the additional section is OPTIONAL.
-
-
-6. Usage Illustrations
-
- This section provides examples of use of the mechanisms defined in
- the previous section. All addresses and domains mentioned here are
- intended to be fictitious and for illustrative purposes only.
- Example delegations will be on 4-bit boundaries solely for
- readability; this specification is indifferent to bit alignment.
-
- Use of the IPv6 aggregatable address format [AGGR] is assumed in the
- examples.
-
-
-6.1. A6 Record Chains
-
- Let's take the example of a site X that is multi-homed to two
- "intermediate" providers A and B. The provider A is itself multi-
- homed to two "transit" providers, C and D. The provider B gets its
- transit service from a single provider, E. For simplicity suppose
- that C, D and E all belong to the same top-level aggregate (TLA)
- with identifier (including format prefix) '2345', and the TLA
- authority at ALPHA-TLA.ORG assigns to C, D and E respectively the
- next level aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28
- and 2345:000E::/32.
-
- C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the
- prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to
- B.
-
- A assigns to X the subscriber identification '11' and B assigns the
- subscriber identification '22'. As a result, the site X inherits
- 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:
-
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 9]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-
- 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
-
-
-6.1.1. Authoritative Data
-
- We will assume that the site X is represented in the DNS by the
- domain name X.EXAMPLE, while A, B, C, D and E are represented by
- A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we
- assume a subdomain "IP6" that will hold the corresponding prefixes.
- The node N is identified by the domain name N.X.EXAMPLE. The
- following records would then appear in X's DNS.
-
- $ORIGIN X.EXAMPLE.
- N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
- SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
- IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
- IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
-
- And elsewhere there would appear
-
- SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
- SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
-
- SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
-
- A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
-
- A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
-
- B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.
-
- C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
- D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
- E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
-
-
-6.1.2. Glue
-
- When, as is common, some or all DNS servers for X.EXAMPLE are within
- the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry
- enough "glue" information to enable DNS clients to reach those
- nameservers. This is true in IPv6 just as in IPv4. However, the A6
- record affords the DNS administrator some choices. The glue could
- be any of
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 10]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- o a minimal set of A6 records duplicated from the X.EXAMPLE zone,
-
- o a (possibly smaller) set of records which collapse the structure
- of that minimal set,
-
- o or a set of A6 records with prefix length zero, giving the
- entire global addresses of the servers.
-
- The trade-off is ease of maintenance against robustness. The best
- and worst of both may be had together by implementing either the
- first or second option together with the third. To illustrate the
- glue options, suppose that X.EXAMPLE is served by two nameservers
- NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers
- ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively.
- Then the top-level zone EXAMPLE would include one (or more) of the
- following sets of A6 records as glue.
-
- $ORIGIN EXAMPLE. ; first option
- X NS NS1.X
- NS NS2.X
- NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X
- NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X
- SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X
- SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X
- IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
- IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
-
-
- $ORIGIN EXAMPLE. ; second option
- X NS NS1.X
- NS NS2.X
- NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET.
- A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET.
- NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET.
- A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET.
-
-
- $ORIGIN EXAMPLE. ; third option
- X NS NS1.X
- NS NS2.X
- NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111
- A6 0 2345:00D2:DA11:1:1:11:111:1111
- A6 0 2345:000E:EB22:1:1:11:111:1111
- NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222
- A6 0 2345:00D2:DA11:2:2:22:222:2222
- A6 0 2345:000E:EB22:2:2:22:222:2222
-
- The first and second glue options are robust against renumbering of
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 11]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if
- those providers' own DNS is unreachable. The glue records of the
- third option are robust against DNS failures elsewhere than the
- zones EXAMPLE and X.EXAMPLE themselves, but must be updated when X's
- address space is renumbered.
-
- If the EXAMPLE zone includes redundant glue, for instance the union
- of the A6 records of the first and third options, then under normal
- circumstances duplicate IPv6 addresses will be derived by DNS
- clients. But if provider DNS fails, addresses will still be
- obtained from the zero-prefix-length records, while if the EXAMPLE
- zone lags behind a renumbering of X.EXAMPLE, half of the addresses
- obtained by DNS clients will still be up-to-date.
-
- The zero-prefix-length glue records can of course be automatically
- generated and/or checked in practice.
-
-6.1.3. Variations
-
- Several more-or-less arbitrary assumptions are reflected in the
- above structure. All of the following choices could have been made
- differently, according to someone's notion of convenience or an
- agreement between two parties.
-
- First, that site X has chosen to put subnet information in a
- separate A6 record rather than incorporate it into each node's
- A6 records.
-
- Second, that site X is referred to as "SUBSCRIBER-X" by both of
- its providers A and B.
-
- Third, that site X chose to indirect its provider information
- through A6 records at IP6.X.EXAMPLE containing no significant
- bits. An alternative would have been to replicate each subnet
- record for each provider.
-
- Fourth, B and E used a slightly different prefix naming
- convention between themselves than did A, C and D. Each
- hierarchical pair of network entities must arrange this naming
- between themselves.
-
- Fifth, that the upward prefix referral chain topped out at
- ALPHA-TLA.ORG. There could have been another level which
- assigned the TLA values and holds A6 records containing those
- bits.
-
- Finally, the above structure reflects an assumption that address
- fields assigned by a given entity are recorded only in A6 records
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 12]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- held by that entity. Those bits could be entered into A6 records in
- the lower-level entity's zone instead, thus:
-
- IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET.
- IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET.
-
- IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET.
- and so on.
-
-
- Or the higher-level entities could hold both sorts of A6 records
- (with different DNS owner names) and allow the lower-level entities
- to choose either mode of A6 chaining. But the general principle of
- avoiding data duplication suggests that the proper place to store
- assigned values is with the entity that assigned them.
-
- It is possible, but not necessarily recommended, for a zone
- maintainer to forego the renumbering support afforded by the
- chaining of A6 records and to record entire IPv6 addresses within
- one zone file.
-
-
-6.2. Reverse Mapping Zones
-
- Supposing that address space assignments in the TLAs with Format
- Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in
- zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then
- the IP6.ARPA zone would include
-
- $ORIGIN IP6.ARPA.
- \[x234500/24] DNAME IP6.ALPHA-TLA.ORG.
- \[x267800/24] DNAME IP6.BRAVO-TLA.ORG.
- \[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY.
-
- Eight trailing zero bits have been included in each TLA ID to
- reflect the eight reserved bits in the current aggregatable global
- unicast addresses format [AGGR].
-
-
-6.2.1. The TLA level
-
- ALPHA-TLA's assignments to network providers C, D and E are
- reflected in the reverse data as follows.
-
- \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
- \[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET.
- \[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET.
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 13]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-6.2.2. The ISP level
-
- The providers A through E carry the following delegation information
- in their zone files.
-
- \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
- \[x2DA/12].IP6.D.NET. DNAME IP6.A.NET.
- \[xEB/8].IP6.E.NET. DNAME IP6.B.NET.
- \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
- \[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE.
-
- Note that some domain names appear in the RDATA of more than one
- DNAME record. In those cases, one zone is being used to map
- multiple prefixes.
-
-
-6.2.3. The Site Level
-
- Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to-
- name translations. This domain is now referenced by two different
- DNAME records held by two different providers.
-
- $ORIGIN IP6.X.EXAMPLE.
- \[x0001/16] DNAME SUBNET-1
- \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE.
- and so on.
-
- SUBNET-1 need not have been named in a DNAME record; the subnet bits
- could have been joined with the interface identifier. But if
- subnets are treated alike in both the A6 records and in the reverse
- zone, it will always be possible to keep the forward and reverse
- definition data for each prefix in one zone.
-
-
-6.3. Lookups
-
- A DNS resolver looking for a hostname for the address
- 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the
- DNAME records shown above and would form new queries. Assuming that
- it began the process knowing servers for IP6.ARPA, but that no
- server it consulted provided recursion and none had other useful
- additional information cached, the sequence of queried names and
- responses would be (all with QCLASS=IN, QTYPE=PTR):
-
-
-
-
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 14]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-
- To a server for IP6.ARPA:
- QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
-
- Answer:
- \[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.
-
- To a server for IP6.ALPHA-TLA.ORG:
- QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
-
- Answer:
- \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
-
- To a server for IP6.C.NET.:
- QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
-
- Answer:
- \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
-
- To a server for IP6.A.NET.:
- QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
-
- Answer:
- \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
-
- To a server for IP6.X.EXAMPLE.:
- QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
-
- Answer:
- \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
- \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
-
- All the DNAME (and NS) records acquired along the way can be cached
- to expedite resolution of addresses topologically near to this
- address. And if another global address of N.X.EXAMPLE were resolved
- within the TTL of the final PTR record, that record would not have
- to be fetched again.
-
-
-6.4. Operational Note
-
- In the illustrations in section 6.1, hierarchically adjacent
- entities, such as a network provider and a customer, must agree on a
- DNS name which will own the definition of the delegated prefix(es).
- One simple convention would be to use a bit-string label
- representing exactly the bits which are assigned to the lower-level
- entity by the higher. For example, "SUBSCRIBER-X" could be replaced
- by "\[x11/8]". This would place the A6 record(s) defining the
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 15]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- delegated prefix at exactly the same point in the DNS tree as the
- DNAME record associated with that delegation. The cost of this
- simplification is that the lower-level zone must update its upward-
- pointing A6 records when it is renumbered. This cost may be found
- quite acceptable in practice.
-
-
-7. Transition from RFC 1886 and Deployment Notes
-
- When prefixes have been "delegated upward" with A6 records, the
- number of DNS resource records required to establish a single IPv6
- address increases by some non-trivial factor. Those records will
- typically, but not necessarily, come from different DNS zones (which
- can independently suffer failures for all the usual reasons). When
- obtaining multiple IPv6 addresses together, this increase in RR
- count will be proportionally less -- and the total size of a DNS
- reply might even decrease -- if the addresses are topologically
- clustered. But the records could still easily exceed the space
- available in a UDP response which returns a large RRset [DNSCLAR] to
- an MX, NS, or SRV query, for example. The possibilities for overall
- degradation of performance and reliability of DNS lookups are
- numerous, and increase with the number of prefix delegations
- involved, especially when those delegations point to records in
- other zones.
-
- DNS Security [DNSSEC] addresses the trustworthiness of cached data,
- which is a problem intrinsic to DNS, but the cost of applying this
- to an IPv6 address is multiplied by a factor which may be greater
- than the number of prefix delegations involved if different
- signature chains must be verified for different A6 records. If a
- trusted centralized caching server (as in [TSIG], for example) is
- used, this cost might be amortized to acceptable levels. One new
- phenomenon is the possibility that IPv6 addresses may be formed from
- a A6 records from a combination of secure and unsecured zones.
-
- Until more deployment experience is gained with the A6 record, it is
- recommended that prefix delegations be limited to one or two levels.
- A reasonable phasing-in mechanism would be to start with no prefix
- delegations (all A6 records having prefix length 0) and then to move
- to the use of a single level of delegation within a single zone.
- (If the TTL of the "prefix" A6 records is kept to an appropriate
- duration the capability for rapid renumbering is not lost.) More
- aggressively flexible delegation could be introduced for a subset of
- hosts for experimentation.
-
-
-
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 16]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-7.1. Transition from AAAA and Coexistence with A Records
-
- Administrators of zones which contain A6 records can easily
- accommodate deployed resolvers which understand AAAA records but not
- A6 records. Such administrators can do automatic generation of AAAA
- records for all of a zone's names which own A6 records by a process
- which mimics the resolution of a hostname to an IPv6 address (see
- section 4.1.4). Attention must be paid to the TTL assigned to a
- generated AAAA record, which MUST be no more than the minimum of the
- TTLs of the A6 records that were used to form the IPv6 address in
- that record. For full robustness, those A6 records which were in
- different zones should be monitored for changes (in TTL or RDATA)
- even when there are no changes to zone for which AAAA records are
- being generated. If the zone is secure [DNSSEC], the generated AAAA
- records MUST be signed along with the rest of the zone data.
-
- A zone-specific heuristic MAY be used to avoid generation of AAAA
- records for A6 records which record prefixes, although such
- superfluous records would be relatively few in number and harmless.
- Examples of such heuristics include omitting A6 records with a
- prefix length less than the largest value found in the zone file, or
- records with an address suffix field with a certain number of
- trailing zero bits.
-
- On the client side, when looking up and IPv6 address, the order of
- A6 and AAAA queries MAY be configurable to be one of: A6, then AAAA;
- AAAA, then A6; A6 only; or both in parallel. The default order (or
- only order, if not configurable) MUST be to try A6 first, then AAAA.
- If and when the AAAA becomes deprecated a new document will change
- the default.
-
- The guidelines and options for precedence between IPv4 and IPv6
- addresses are specified in [TRANS]. All mentions of AAAA records in
- that document are henceforth to be interpreted as meaning A6 and/or
- AAAA records in the order specified in the previous paragraph.
-
-
-7.2. Transition from Nibble Labels to Binary Labels
-
- Implementations conforming to RFC 1886 perform reverse lookups as
- follows:
-
- An IPv6 address is represented as a name in the IP6.INT domain
- by a sequence of nibbles separated by dots with the suffix
- ".IP6.INT". The sequence of nibbles is encoded in reverse order,
- i.e. the low-order nibble is encoded first, followed by the next
- low-order nibble and so on. Each nibble is represented by a
- hexadecimal digit. For example, a name for the address
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 17]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in
- section 6.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.-
- 8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int."
-
- Implementations conforming to this specification will perform a
- lookup of a binary label in IP6.ARPA as specified in Section 3.2.
- It is RECOMMENDED that for a transition period implementations first
- lookup the binary label in IP6.ARPA and if this fails try to lookup
- the 'nibble' label in IP6.INT.
-
-
-8. Security Considerations
-
- The signing authority [DNSSEC] for the A6 records which determine an
- IPv6 address is distributed among several entities, reflecting the
- delegation path of the address space which that address occupies.
- DNS Security is fully applicable to bit-string labels and DNAME
- records. And just as in IPv4, verification of name-to-address
- mappings is logically independent of verification of address-to-name
- mappings.
-
- With or without DNSSEC, the incomplete but non-empty address set
- scenario of section 4.1.4 could be caused by selective interference
- with DNS lookups. If in some situation this would be more harmful
- than complete DNS failure, it might be mitigated on the client side
- by refusing to act on an incomplete set, or on the server side by
- listing all addresses in A6 records with prefix length 0.
-
-
-9. IANA Considerations
-
- The A6 resource record has been assigned a Type value of 38.
-
-
-10. Acknowledgments
-
- The authors would like to thank the following persons for valuable
- discussions and reviews: Mark Andrews, Rob Austein, Jim Bound,
- Randy Bush, Brian Carpenter, David Conrad, Steve Deering, Francis
- Dupont, Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob
- Hinden, Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik
- Nordmark, Mike O'Dell, Michael Patton and Ken Powell.
-
-
-
-
-
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 18]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
-11. References
-
-
- [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
- [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable
- Global Unicast Address Format". RFC 2374, July 1998.
-
- [BITLBL] Crawford, M., "Binary Labels in the Domain Name System",
- RFC 2673, August 1999.
-
- [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
- August 1999.
-
- [DNSCLAR] Elz, R and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [DNSIS] Mockapetris, P. V., "Domain names - implementation and
- specification", RFC 1035, November 1987.
-
- [DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System
- Security Extensions", RFC 2535, March 1999.
-
- [KWORD] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels," RFC 2119.
-
- [RENUM] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
- 1900, February 1996.
-
- Ferguson, P. and H. Berkowitz, "Network Renumbering Overview:
- Why would I want it and what is it anyway?", RFC 2071, January
- 1997.
-
- Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
- Behaviour Today", RFC 2101, February 1997.
-
- [TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for
- IPv6 Hosts and Routers", RFC 1933, April 1996.
-
- [TSIG] Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B.
- Wellington, "Secret Key Transaction Authentication for DNS
-
-
-
-
-
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 19]
-\f
-Internet Draft IPv6 DNS May 17, 2000
-
-
- (TSIG)", work in progress.
-
-12. Authors' Addresses
-
- Matt Crawford Christian Huitema Susan Thomson
- Fermilab Telcordia Telcordia
- MS 368 MCC 1J236B MCC 1C259B
- PO Box 500 445 South Street 445 South Street
- Batavia, IL 60510 Morristown, NJ 07960 Morristown, NJ 07960
- USA USA USA
-
- +1 630 840-3461 +1 201 829-4266 +1 201 829-4514
- crawdad@fnal.gov huitema@research.telcordia.com
- set@research.telcordia.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires November 22, 2000 Crawford et al. [Page 20]
-
projects / thirdparty / bind9.git / commitdiff
