upstream/bind9
1
0
Fork 0
mirror of https://github.com/isc-projects/bind9.git synced 2026-04-26 08:39:00 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

remove old drafts

Browse source
This commit is contained in:
Mark Andrews 2004-03-10 00:55:46 +00:00
parent 9b6e6a1e70
commit 3a2a85aafc
4 changed files with 0 additions and 2348 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

767
doc/draft/draft-ietf-dnsext-aaaa-a6-01.txt
View file

@ -1,767 +0,0 @@
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]

394
doc/draft/draft-ietf-dnsext-apl-rr-02.txt
View file

@ -1,394 +0,0 @@
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]
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]
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]
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]
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]
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]
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]

68
doc/draft/draft-ietf-idn-punycode-03.txt
View file

@ -1,68 +0,0 @@
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.

1119
doc/draft/draft-ietf-ipngwg-dns-lookups-08.txt
View file

File diff suppressed because it is too large Load diff