620 lines
26 KiB
Plaintext
620 lines
26 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group R. Austein
|
||
Request for Comments: 3364 Bourgeois Dilettant
|
||
Updates: 2673, 2874 August 2002
|
||
Category: Informational
|
||
|
||
|
||
Tradeoffs in Domain Name System (DNS) Support
|
||
for Internet Protocol version 6 (IPv6)
|
||
|
||
Status of this Memo
|
||
|
||
This memo provides information for the Internet community. It does
|
||
not specify an Internet standard of any kind. Distribution of this
|
||
memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
||
|
||
Abstract
|
||
|
||
The IETF has two different proposals on the table for how to do DNS
|
||
support for IPv6, and has thus far failed to reach a clear consensus
|
||
on which approach is better. This note attempts to examine the pros
|
||
and cons of each approach, in the hope of clarifying the debate so
|
||
that we can reach closure and move on.
|
||
|
||
Introduction
|
||
|
||
RFC 1886 [RFC1886] specified straightforward mechanisms to support
|
||
IPv6 addresses in the DNS. These mechanisms closely resemble the
|
||
mechanisms used to support IPv4, with a minor improvement to the
|
||
reverse mapping mechanism based on experience with CIDR. RFC 1886 is
|
||
currently listed as a Proposed Standard.
|
||
|
||
RFC 2874 [RFC2874] specified enhanced mechanisms to support IPv6
|
||
addresses in the DNS. These mechanisms provide new features that
|
||
make it possible for an IPv6 address stored in the DNS to be broken
|
||
up into multiple DNS resource records in ways that can reflect the
|
||
network topology underlying the address, thus making it possible for
|
||
the data stored in the DNS to reflect certain kinds of network
|
||
topology changes or routing architectures that are either impossible
|
||
or more difficult to represent without these mechanisms. RFC 2874 is
|
||
also currently listed as a Proposed Standard.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Austein Informational [Page 1]
|
||
|
||
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
|
||
|
||
|
||
Both of these Proposed Standards were the output of the IPNG Working
|
||
Group. Both have been implemented, although implementation of
|
||
[RFC1886] is more widespread, both because it was specified earlier
|
||
and because it's simpler to implement.
|
||
|
||
There's little question that the mechanisms proposed in [RFC2874] are
|
||
more general than the mechanisms proposed in [RFC1886], and that
|
||
these enhanced mechanisms might be valuable if IPv6's evolution goes
|
||
in certain directions. The questions are whether we really need the
|
||
more general mechanism, what new usage problems might come along with
|
||
the enhanced mechanisms, and what effect all this will have on IPv6
|
||
deployment.
|
||
|
||
The one thing on which there does seem to be widespread agreement is
|
||
that we should make up our minds about all this Real Soon Now.
|
||
|
||
Main Advantages of Going with A6
|
||
|
||
While the A6 RR proposed in [RFC2874] is very general and provides a
|
||
superset of the functionality provided by the AAAA RR in [RFC1886],
|
||
many of the features of A6 can also be implemented with AAAA RRs via
|
||
preprocessing during zone file generation.
|
||
|
||
There is one specific area where A6 RRs provide something that cannot
|
||
be provided using AAAA RRs: A6 RRs can represent addresses in which a
|
||
prefix portion of the address can change without any action (or
|
||
perhaps even knowledge) by the parties controlling the DNS zone
|
||
containing the terminal portion (least significant bits) of the
|
||
address. This includes both so-called "rapid renumbering" scenarios
|
||
(where an entire network's prefix may change very quickly) and
|
||
routing architectures such as the former "GSE" proposal [GSE] (where
|
||
the "routing goop" portion of an address may be subject to change
|
||
without warning). A6 RRs do not completely remove the need to update
|
||
leaf zones during all renumbering events (for example, changing ISPs
|
||
would usually require a change to the upward delegation pointer), but
|
||
careful use of A6 RRs could keep the number of RRs that need to
|
||
change during such an event to a minimum.
|
||
|
||
Note that constructing AAAA RRs via preprocessing during zone file
|
||
generation requires exactly the sort of information that A6 RRs store
|
||
in the DNS. This begs the question of where the hypothetical
|
||
preprocessor obtains that information if it's not getting it from the
|
||
DNS.
|
||
|
||
Note also that the A6 RR, when restricted to its zero-length-prefix
|
||
form ("A6 0"), is semantically equivalent to an AAAA RR (with one
|
||
"wasted" octet in the wire representation), so anything that can be
|
||
done with an AAAA RR can also be done with an A6 RR.
|
||
|
||
|
||
|
||
Austein Informational [Page 2]
|
||
|
||
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
|
||
|
||
|
||
Main Advantages of Going with AAAA
|
||
|
||
The AAAA RR proposed in [RFC1886], while providing only a subset of
|
||
the functionality provided by the A6 RR proposed in [RFC2874], has
|
||
two main points to recommend it:
|
||
|
||
- AAAA RRs are essentially identical (other than their length) to
|
||
IPv4's A RRs, so we have more than 15 years of experience to help
|
||
us predict the usage patterns, failure scenarios and so forth
|
||
associated with AAAA RRs.
|
||
|
||
- The AAAA RR is "optimized for read", in the sense that, by storing
|
||
a complete address rather than making the resolver fetch the
|
||
address in pieces, it minimizes the effort involved in fetching
|
||
addresses from the DNS (at the expense of increasing the effort
|
||
involved in injecting new data into the DNS).
|
||
|
||
Less Compelling Arguments in Favor of A6
|
||
|
||
Since the A6 RR allows a zone administrator to write zone files whose
|
||
description of addresses maps to the underlying network topology, A6
|
||
RRs can be construed as a "better" way of representing addresses than
|
||
AAAA. This may well be a useful capability, but in and of itself
|
||
it's more of an argument for better tools for zone administrators to
|
||
use when constructing zone files than a justification for changing
|
||
the resolution protocol used on the wire.
|
||
|
||
Less Compelling Arguments in Favor of AAAA
|
||
|
||
Some of the pressure to go with AAAA instead of A6 appears to be
|
||
based on the wider deployment of AAAA. Since it is possible to
|
||
construct transition tools (see discussion of AAAA synthesis, later
|
||
in this note), this does not appear to be a compelling argument if A6
|
||
provides features that we really need.
|
||
|
||
Another argument in favor of AAAA RRs over A6 RRs appears to be that
|
||
the A6 RR's advanced capabilities increase the number of ways in
|
||
which a zone administrator could build a non-working configuration.
|
||
While operational issues are certainly important, this is more of
|
||
argument that we need better tools for zone administrators than it is
|
||
a justification for turning away from A6 if A6 provides features that
|
||
we really need.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Austein Informational [Page 3]
|
||
|
||
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
|
||
|
||
|
||
Potential Problems with A6
|
||
|
||
The enhanced capabilities of the A6 RR, while interesting, are not in
|
||
themselves justification for choosing A6 if we don't really need
|
||
those capabilities. The A6 RR is "optimized for write", in the sense
|
||
that, by making it possible to store fragmented IPv6 addresses in the
|
||
DNS, it makes it possible to reduce the effort that it takes to
|
||
inject new data into the DNS (at the expense of increasing the effort
|
||
involved in fetching data from the DNS). This may be justified if we
|
||
expect the effort involved in maintaining AAAA-style DNS entries to
|
||
be prohibitive, but in general, we expect the DNS data to be read
|
||
more frequently than it is written, so we need to evaluate this
|
||
particular tradeoff very carefully.
|
||
|
||
There are also several potential issues with A6 RRs that stem
|
||
directly from the feature that makes them different from AAAA RRs:
|
||
the ability to build up address via chaining.
|
||
|
||
Resolving a chain of A6 RRs involves resolving a series of what are
|
||
almost independent queries, but not quite. Each of these sub-queries
|
||
takes some non-zero amount of time, unless the answer happens to be
|
||
in the resolver's local cache already. Assuming that resolving an
|
||
AAAA RR takes time T as a baseline, we can guess that, on the
|
||
average, it will take something approaching time N*T to resolve an
|
||
N-link chain of A6 RRs, although we would expect to see a fairly good
|
||
caching factor for the A6 fragments representing the more significant
|
||
bits of an address. This leaves us with two choices, neither of
|
||
which is very good: we can decrease the amount of time that the
|
||
resolver is willing to wait for each fragment, or we can increase the
|
||
amount of time that a resolver is willing to wait before returning
|
||
failure to a client. What little data we have on this subject
|
||
suggests that users are already impatient with the length of time it
|
||
takes to resolve A RRs in the IPv4 Internet, which suggests that they
|
||
are not likely to be patient with significantly longer delays in the
|
||
IPv6 Internet. At the same time, terminating queries prematurely is
|
||
both a waste of resources and another source of user frustration.
|
||
Thus, we are forced to conclude that indiscriminate use of long A6
|
||
chains is likely to lead to problems.
|
||
|
||
To make matters worse, the places where A6 RRs are likely to be most
|
||
critical for rapid renumbering or GSE-like routing are situations
|
||
where the prefix name field in the A6 RR points to a target that is
|
||
not only outside the DNS zone containing the A6 RR, but is
|
||
administered by a different organization (for example, in the case of
|
||
an end user's site, the prefix name will most likely point to a name
|
||
belonging to an ISP that provides connectivity for the site). While
|
||
pointers out of zone are not a problem per se, pointers to other
|
||
organizations are somewhat more difficult to maintain and less
|
||
|
||
|
||
|
||
Austein Informational [Page 4]
|
||
|
||
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
|
||
|
||
|
||
susceptible to automation than pointers within a single organization
|
||
would be. Experience both with glue RRs and with PTR RRs in the IN-
|
||
ADDR.ARPA tree suggests that many zone administrators do not really
|
||
understand how to set up and maintain these pointers properly, and we
|
||
have no particular reason to believe that these zone administrators
|
||
will do a better job with A6 chains than they do today. To be fair,
|
||
however, the alternative case of building AAAA RRs via preprocessing
|
||
before loading zones has many of the same problems; at best, one can
|
||
claim that using AAAA RRs for this purpose would allow DNS clients to
|
||
get the wrong answer somewhat more efficiently than with A6 RRs.
|
||
|
||
Finally, assuming near total ignorance of how likely a query is to
|
||
fail, the probability of failure with an N-link A6 chain would appear
|
||
to be roughly proportional to N, since each of the queries involved
|
||
in resolving an A6 chain would have the same probability of failure
|
||
as a single AAAA query. Note again that this comment applies to
|
||
failures in the the process of resolving a query, not to the data
|
||
obtained via that process. Arguably, in an ideal world, A6 RRs would
|
||
increase the probability of the answer a client (finally) gets being
|
||
right, assuming that nothing goes wrong in the query process, but we
|
||
have no real idea how to quantify that assumption at this point even
|
||
to the hand-wavey extent used elsewhere in this note.
|
||
|
||
One potential problem that has been raised in the past regarding A6
|
||
RRs turns out not to be a serious issue. The A6 design includes the
|
||
possibility of there being more than one A6 RR matching the prefix
|
||
name portion of a leaf A6 RR. That is, an A6 chain may not be a
|
||
simple linked list, it may in fact be a tree, where each branch
|
||
represents a possible prefix. Some critics of A6 have been concerned
|
||
that this will lead to a wild expansion of queries, but this turns
|
||
out not to be a problem if a resolver simply follows the "bounded
|
||
work per query" rule described in RFC 1034 (page 35). That rule
|
||
applies to all work resulting from attempts to process a query,
|
||
regardless of whether it's a simple query, a CNAME chain, an A6 tree,
|
||
or an infinite loop. The client may not get back a useful answer in
|
||
cases where the zone has been configured badly, but a proper
|
||
implementation should not produce a query explosion as a result of
|
||
processing even the most perverse A6 tree, chain, or loop.
|
||
|
||
Interactions with DNSSEC
|
||
|
||
One of the areas where AAAA and A6 RRs differ is in the precise
|
||
details of how they interact with DNSSEC. The following comments
|
||
apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are
|
||
semantically equivalent to AAAA RRs).
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Austein Informational [Page 5]
|
||
|
||
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
|
||
|
||
|
||
Other things being equal, the time it takes to re-sign all of the
|
||
addresses in a zone after a renumbering event is longer with AAAA RRs
|
||
than with A6 RRs (because each address record has to be re-signed
|
||
rather than just signing a common prefix A6 RR and a few A6 0 RRs
|
||
associated with the zone's name servers). Note, however, that in
|
||
general this does not present a serious scaling problem, because the
|
||
re-signing is performed in the leaf zones.
|
||
|
||
Other things being equal, there's more work involved in verifying the
|
||
signatures received back for A6 RRs, because each address fragment
|
||
has a separate associated signature. Similarly, a DNS message
|
||
containing a set of A6 address fragments and their associated
|
||
signatures will be larger than the equivalent packet with a single
|
||
AAAA (or A6 0) and a single associated signature.
|
||
|
||
Since AAAA RRs cannot really represent rapid renumbering or GSE-style
|
||
routing scenarios very well, it should not be surprising that DNSSEC
|
||
signatures of AAAA RRs are also somewhat problematic. In cases where
|
||
the AAAA RRs would have to be changing very quickly to keep up with
|
||
prefix changes, the time required to re-sign the AAAA RRs may be
|
||
prohibitive.
|
||
|
||
Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that
|
||
333MHz Celeron laptop with 128KB L2 cache and 64MB RAM running the
|
||
BIND-9 dnssec-signzone program under NetBSD can generate roughly 40
|
||
1024-bit RSA signatures per second. Extrapolating from this,
|
||
assuming one A RR, one AAAA RR, and one NXT RR per host, this
|
||
suggests that it would take this laptop a few hours to sign a zone
|
||
listing 10**5 hosts, or about a day to sign a zone listing 10**6
|
||
hosts using AAAA RRs.
|
||
|
||
This suggests that the additional effort of re-signing a large zone
|
||
full of AAAA RRs during a re-numbering event, while noticeable, is
|
||
only likely to be prohibitive in the rapid renumbering case where
|
||
AAAA RRs don't work well anyway.
|
||
|
||
Interactions with Dynamic Update
|
||
|
||
DNS dynamic update appears to work equally well for AAAA or A6 RRs,
|
||
with one minor exception: with A6 RRs, the dynamic update client
|
||
needs to know the prefix length and prefix name. At present, no
|
||
mechanism exists to inform a dynamic update client of these values,
|
||
but presumably such a mechanism could be provided via an extension to
|
||
DHCP, or some other equivalent could be devised.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Austein Informational [Page 6]
|
||
|
||
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
|
||
|
||
|
||
Transition from AAAA to A6 Via AAAA Synthesis
|
||
|
||
While AAAA is at present more widely deployed than A6, it is possible
|
||
to transition from AAAA-aware DNS software to A6-aware DNS software.
|
||
A rough plan for this was presented at IETF-50 in Minneapolis and has
|
||
been discussed on the ipng mailing list. So if the IETF concludes
|
||
that A6's enhanced capabilities are necessary, it should be possible
|
||
to transition from AAAA to A6.
|
||
|
||
The details of this transition have been left to a separate document,
|
||
but the general idea is that the resolver that is performing
|
||
iterative resolution on behalf of a DNS client program could
|
||
synthesize AAAA RRs representing the result of performing the
|
||
equivalent A6 queries. Note that in this case it is not possible to
|
||
generate an equivalent DNSSEC signature for the AAAA RR, so clients
|
||
that care about performing DNSSEC validation for themselves would
|
||
have to issue A6 queries directly rather than relying on AAAA
|
||
synthesis.
|
||
|
||
Bitlabels
|
||
|
||
While the differences between AAAA and A6 RRs have generated most of
|
||
the discussion to date, there are also two proposed mechanisms for
|
||
building the reverse mapping tree (the IPv6 equivalent of IPv4's IN-
|
||
ADDR.ARPA tree).
|
||
|
||
[RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA
|
||
mechanism used for IPv4 addresses: the RR name is the hexadecimal
|
||
representation of the IPv6 address, reversed and concatenated with a
|
||
well-known suffix, broken up with a dot between each hexadecimal
|
||
digit. The resulting DNS names are somewhat tedious for humans to
|
||
type, but are very easy for programs to generate. Making each
|
||
hexadecimal digit a separate label means that delegation on arbitrary
|
||
bit boundaries will result in a maximum of 16 NS RRsets per label
|
||
level; again, the mechanism is somewhat tedious for humans, but is
|
||
very easy to program. As with IPv4's IN-ADDR.ARPA tree, the one
|
||
place where this scheme is weak is in handling delegations in the
|
||
least significant label; however, since there appears to be no real
|
||
need to delegate the least significant four bits of an IPv6 address,
|
||
this does not appear to be a serious restriction.
|
||
|
||
[RFC2874] proposed a radically different way of naming entries in the
|
||
reverse mapping tree: rather than using textual representations of
|
||
addresses, it proposes to use a new kind of DNS label (a "bit label")
|
||
to represent binary addresses directly in the DNS. This has the
|
||
advantage of being significantly more compact than the textual
|
||
representation, and arguably might have been a better solution for
|
||
DNS to use for this purpose if it had been designed into the protocol
|
||
|
||
|
||
|
||
Austein Informational [Page 7]
|
||
|
||
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
|
||
|
||
|
||
from the outset. Unfortunately, experience to date suggests that
|
||
deploying a new DNS label type is very hard: all of the DNS name
|
||
servers that are authoritative for any portion of the name in
|
||
question must be upgraded before the new label type can be used, as
|
||
must any resolvers involved in the resolution process. Any name
|
||
server that has not been upgraded to understand the new label type
|
||
will reject the query as being malformed.
|
||
|
||
Since the main benefit of the bit label approach appears to be an
|
||
ability that we don't really need (delegation in the least
|
||
significant four bits of an IPv6 address), and since the upgrade
|
||
problem is likely to render bit labels unusable until a significant
|
||
portion of the DNS code base has been upgraded, it is difficult to
|
||
escape the conclusion that the textual solution is good enough.
|
||
|
||
DNAME RRs
|
||
|
||
[RFC2874] also proposes using DNAME RRs as a way of providing the
|
||
equivalent of A6's fragmented addresses in the reverse mapping tree.
|
||
That is, by using DNAME RRs, one can write zone files for the reverse
|
||
mapping tree that have the same ability to cope with rapid
|
||
renumbering or GSE-style routing that the A6 RR offers in the main
|
||
portion of the DNS tree. Consequently, the need to use DNAME in the
|
||
reverse mapping tree appears to be closely tied to the need to use
|
||
fragmented A6 in the main tree: if one is necessary, so is the other,
|
||
and if one isn't necessary, the other isn't either.
|
||
|
||
Other uses have also been proposed for the DNAME RR, but since they
|
||
are outside the scope of the IPv6 address discussion, they will not
|
||
be addressed here.
|
||
|
||
Recommendation
|
||
|
||
Distilling the above feature comparisons down to their key elements,
|
||
the important questions appear to be:
|
||
|
||
(a) Is IPv6 going to do rapid renumbering or GSE-like routing?
|
||
|
||
(b) Is the reverse mapping tree for IPv6 going to require delegation
|
||
in the least significant four bits of the address?
|
||
|
||
Question (a) appears to be the key to the debate. This is really a
|
||
decision for the IPv6 community to make, not the DNS community.
|
||
|
||
Question (b) is also for the IPv6 community to make, but it seems
|
||
fairly obvious that the answer is "no".
|
||
|
||
|
||
|
||
|
||
|
||
Austein Informational [Page 8]
|
||
|
||
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
|
||
|
||
|
||
Recommendations based on these questions:
|
||
|
||
(1) If the IPv6 working groups seriously intend to specify and deploy
|
||
rapid renumbering or GSE-like routing, we should transition to
|
||
using the A6 RR in the main tree and to using DNAME RRs as
|
||
necessary in the reverse tree.
|
||
|
||
(2) Otherwise, we should keep the simpler AAAA solution in the main
|
||
tree and should not use DNAME RRs in the reverse tree.
|
||
|
||
(3) In either case, the reverse tree should use the textual
|
||
representation described in [RFC1886] rather than the bit label
|
||
representation described in [RFC2874].
|
||
|
||
(4) If we do go to using A6 RRs in the main tree and to using DNAME
|
||
RRs in the reverse tree, we should write applicability statements
|
||
and implementation guidelines designed to discourage excessively
|
||
complex uses of these features; in general, any network that can
|
||
be described adequately using A6 0 RRs and without using DNAME
|
||
RRs should be described that way, and the enhanced features
|
||
should be used only when absolutely necessary, at least until we
|
||
have much more experience with them and have a better
|
||
understanding of their failure modes.
|
||
|
||
Security Considerations
|
||
|
||
This note compares two mechanisms with similar security
|
||
characteristics, but there are a few security implications to the
|
||
choice between these two mechanisms:
|
||
|
||
(1) The two mechanisms have similar but not identical interactions
|
||
with DNSSEC. Please see the section entitled "Interactions with
|
||
DNSSEC" (above) for a discussion of these issues.
|
||
|
||
(2) To the extent that operational complexity is the enemy of
|
||
security, the tradeoffs in operational complexity discussed
|
||
throughout this note have an impact on security.
|
||
|
||
(3) To the extent that protocol complexity is the enemy of security,
|
||
the additional protocol complexity of [RFC2874] as compared to
|
||
[RFC1886] has some impact on security.
|
||
|
||
IANA Considerations
|
||
|
||
None, since all of these RR types have already been allocated.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Austein Informational [Page 9]
|
||
|
||
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
|
||
|
||
|
||
Acknowledgments
|
||
|
||
This note is based on a number of discussions both public and private
|
||
over a period of (at least) eight years, but particular thanks go to
|
||
Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun
|
||
Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush,
|
||
and Sue Thomson, none of whom are responsible for what the author did
|
||
with their ideas.
|
||
|
||
References
|
||
|
||
[RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support
|
||
IP version 6", RFC 1886, December 1995.
|
||
|
||
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
|
||
IPv6 Address Aggregation and Renumbering", RFC 2874,
|
||
July 2000.
|
||
|
||
[Sommerfeld] Private message to the author from Bill Sommerfeld dated
|
||
21 March 2001, summarizing the result of experiments he
|
||
performed on a copy of the MIT.EDU zone.
|
||
|
||
[GSE] "GSE" was an evolution of the so-called "8+8" proposal
|
||
discussed by the IPng working group in 1996 and 1997.
|
||
The GSE proposal itself was written up as an Internet-
|
||
Draft, which has long since expired. Readers interested
|
||
in the details and history of GSE should review the IPng
|
||
working group's mailing list archives and minutes from
|
||
that period.
|
||
|
||
Author's Address
|
||
|
||
Rob Austein
|
||
|
||
EMail: sra@hactrn.net
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Austein Informational [Page 10]
|
||
|
||
RFC 3364 Tradeoffs in DNS Support for IPv6 August 2002
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2002). All Rights Reserved.
|
||
|
||
This document and translations of it may be copied and furnished to
|
||
others, and derivative works that comment on or otherwise explain it
|
||
or assist in its implementation may be prepared, copied, published
|
||
and distributed, in whole or in part, without restriction of any
|
||
kind, provided that the above copyright notice and this paragraph are
|
||
included on all such copies and derivative works. However, this
|
||
document itself may not be modified in any way, such as by removing
|
||
the copyright notice or references to the Internet Society or other
|
||
Internet organizations, except as needed for the purpose of
|
||
developing Internet standards in which case the procedures for
|
||
copyrights defined in the Internet Standards process must be
|
||
followed, or as required to translate it into languages other than
|
||
English.
|
||
|
||
The limited permissions granted above are perpetual and will not be
|
||
revoked by the Internet Society or its successors or assigns.
|
||
|
||
This document and the information contained herein is provided on an
|
||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Austein Informational [Page 11]
|
||
|