Network Working Group V. Pappas
Internet-Draft UCLA
Expires: April 20, 2006 B. Zhang
Colorado State Univ.
E. Osterweil
UCLA
D. Massey
Colorado State Univ.
L. Zhang
UCLA
October 17, 2005
Improving DNS Service Availability by Using Long TTLs
draft-pappas-dnsop-long-ttl-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on April 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Due to the hierarchical tree structure of the Domain Name System
Pappas, et al. Expires April 20, 2006 [Page 1]
Internet-Draft Improving DNS Service Availability October 2005
[RFC1034][RFC1035], the loss of all the authoritative servers of a
zone can disrupt not only services to the zone but also all of its
descendants. This problem is particularly severe if all the
authoritative servers of the root zone, or some top level domain
zones, fail. Although proper placement of secondary servers, as
discussed in [RFC2182], can be effective means against isolated
failures, it is insufficient to protect DNS service against
intentional attacks such as distributed denial of service (DDoS)
attacks. This document proposes to mitigate the impact of DDoS
attacks against top level DNS servers by setting long (weeks or
months) TTL values for NS records and their associated A records.
Our analysis shows that this simple operational change can
dramatically reduce the impact of successful DDoS attacks on the DNS
service availability with little impact on DNS performance. To
increase the availability of cached data this draft also proposes a
simple rule for refreshing caches. All the proposed changes are
purely operational and can be incrementally deployed with no protocol
changes.
Pappas, et al. Expires April 20, 2006 [Page 2]
Internet-Draft Improving DNS Service Availability October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background and Review of Caching . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Setting Long Infrastructure TTLs . . . . . . . . . . . . . . . 7
2.1. Cases of Secondary Servers outside the Zone . . . . . . . 7
2.2. Handling Name Server Changes . . . . . . . . . . . . . . . 8
2.3. Impact on Cache Memory Size . . . . . . . . . . . . . . . 9
2.4. Effectiveness of Long TTL on Zone's Availability . . . . . 9
2.5. Enhancement of Prefetching . . . . . . . . . . . . . . . . 10
2.6. Backwards Compatibility . . . . . . . . . . . . . . . . . 10
3. Measurement Data . . . . . . . . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Pappas, et al. Expires April 20, 2006 [Page 3]
Internet-Draft Improving DNS Service Availability October 2005
1. Introduction
This document describes operational guidelines that can help mitigate
the effect of denial of service attacks directed against top level
zones in the DNS hierarchy. If all authoritative servers for a zone
fail, DNS resolvers will be unable to obtain data for the zone and
all of its descendants in the DNS tree. [RFC2182] provides
operational guidelines for selecting and operating authoritative
servers for a zone. If these guidelines are followed, it is unlikely
that any unintentional failures or errors will result in the loss of
all the authoritative servers in a zone.
However, proper placement of authoritative servers cannot effectively
protect the zone against intentional attacks. For example, a
distributed denial of service attack could target all the
authoritative servers for zone regardless of where they are placed,
resulting in availability problems for the attacked zone and all of
its descendents in the DNS tree hierarchy. Attacks against top level
domains such as the root, generic top level domains (gTLDs), country
code top level domains (ccTLDs), and other zones serving popular DNS
domains (such as co.uk. or co.jp.) could have a severe global impact.
Successful attack of all root servers could potentially disrupt
service for the entire DNS. Failure of all authoritative servers for
a large generic top level domain (gTLD) such as "com." can impact
availability for tens of millions of DNS zones. In other words,
successful attacks against a small number of critical authoritative
servers can have a disproportionate impact. The guidelines in this
document help mitigate this problem.
A fundamental observation is that caching helps defends against
denial of service attacks. For example, consider the case of an
attack against the DNS root servers. The loss of the root servers
would have an impact, but it can be mitigated by caching. Most
resolvers will have cached NS resource record sets for commonly used
gTLDs and ccTLDs. As long as the NS records and their corresponding
A resource record sets remain in the cache, the root servers are used
primarily for looking up entries in top level domains not presently
in the cache. Similar arguments apply to attacks against other top
level servers. If the NS and associated A/AAAA resource record sets
are cached, an attack against a top level zone has less impact.
Throughout the remainder of the draft, this document refer to the NS
resource record sets and the A and AAAA resource records associated
with these NS records as "infrastructure resource record sets" or
simply "infrastructure RRsets". The cache lifetime for these
infrastructure RRsets is determined by time to live (TTL) field which
has typically been set to a small number of days or hours.
Pappas, et al. Expires April 20, 2006 [Page 4]
Internet-Draft Improving DNS Service Availability October 2005
This draft recommends significantly longer TTL values on the order of
weeks for infrastructure RRsets to improves DNS service availability
in the event of successful attacks. During the time the
infrastructure RRsets for a zone are cached, queries to the zones can
be resolved without expressly traversing the DNS hierarchy. This
change is feasible due to the relatively stable nature of
infrastructure records and the DNS tolerance for occasional partial
discrepancies in the infrastructure RRsets. The long TTL
recommendations in this draft apply only to these infrastructure
RRsets; other RRsets such as those for end hosts should use short
TTLs to meet the need of more dynamic changes.
We describe the exact mechanisms and related technical and
operational issues in Section 2. In Section 3 we present measurement
results over a large set of DNS zones on the frequency of changes of
their NS and corresponding A RRsets to evaluate the feasibility of
using long TTL values for the RRsets. Section 4 discusses potential
impacts on DNS security, and Section 5 presents a specific
recommendation for setting TTL values for infrastructure RRsets.
1.1. Background and Review of Caching
An end host typically sends DNS queries to a local caching resolver.
The caching resolver will first check its local cache for records
that match; if the requested name is not in the cache, it will follow
a sequence of checks to locate this information without explicitly
traversing the DNS hierarchy. Initially the cache will check whether
the NS or A RRset of the requested zone's servers are present in its
cache. If neither set is found, the cache checks to see if the
parent zone of the request is in the cache. If any of these entries
are found in the cache (as is often the case for top level or popular
zones) the resolver will send the query directly to the corresponding
zone server.
Only when no information is found about either the requested name, or
any of the higher level servers, will the caching resolver will go
through a sequence of iterative queries that follow the parent-child
zone relationship (starting from the root zone). It will walk down
the DNS hierarchy until it reaches a server of the queried zone.
During this iterative query process, the caching resolver receives
and caches the NS and corresponding A RRsets of the zones along the
name resolution path, which can then be used to answer future queries
that involve any of the zones just visited. The cached RRsets get
flushed out when their TTL values expire.
Although DNS's top-down name lookup, as described above, provides a
simple and efficient search over a large scale distributed database,
it also introduces a dependency on the availability of the top level
Pappas, et al. Expires April 20, 2006 [Page 5]
Internet-Draft Improving DNS Service Availability October 2005
DNS servers. This dependency mandates that these servers are
available for the system to function. If any zone (including all its
servers) along the lookup path to destination zone D becomes
unavailable, then hosts in zone D become effectively unreachable even
if they still have perfect connectivity to the global Internet.
Knocking out all the root zone servers will effectively render the
entire Internet unreachable.
However from the above description, we also note that as long as the
NS and A RRsets of a zone are in the cache of a resolver, there
solver can go directly to the zone server to resolve DNS queries.
This is true even when the top level DNS servers are unavailable. As
stated in [Mock88], a high TTL value not only minimizes DNS traffic
but also "allows caching to mask periods of server unavailability due
to network or host problems." Following this hint, we have developed
a simple operational tuning principle on the TTL values of the
infrastructure RRsets that minimizes the dependency on top level
zones and increases the over all availability of a DNS zone.
1.2. Terminology
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].
Pappas, et al. Expires April 20, 2006 [Page 6]
Internet-Draft Improving DNS Service Availability October 2005
2. Setting Long Infrastructure TTLs
To reduce the dependency on top level DNS servers, and hence increase
the availability of a zone, we recommend that DNS operators for a DNS
zone, e.g. foo.example, configure a TTL value of one month for the
zone's infrastructure RRsets. This recommendation applies to the
infrastructure RRsets in the zone itself. In other words, the long
TTL value should set on the authoritative copy of the NS RRset and
any A or AAAA RRsets present in the zone (authoritative or not) that
correspond to names listed in the NS RRset.
The NS RRset and potentially the corresponding A and AAAA RRSets are
also stored at the zone's parent. It is recommended that those
copies of the infrastructure RRsets also be assigned a similar long
TTL value. However, the authoritative answer from the zone itself
should be preferred over any copy stored at the parent [RFC2181].
Thus, a shorter TTL value set by the parent zone should not reduce
the effectiveness of the long TTL values set by the child zone.
2.1. Cases of Secondary Servers outside the Zone
The following common case in DNS configuration deserves a special
explanation. When a zone server for foo.example is located inside
the zone, the operator for foo.example can configure the TTL for both
the NS RRset and the A/AAAA records to a long time period. However
some of foo.example's authoritative servers may be located in other
domains, as illustrated in the following NS RRset:
foo.example. NS ns1.foo.example.
foo.example. NS ns2.foo.example.
foo.example. NS ns.bar.example2.
The foo.example zone is authoritative for the A and AAAA resource
record sets at ns1.foo.example and ns2.foo.example. In this case,
the foo.example zone can set a longer TTL value for all the NS
records and the A records of the first two servers, but the TTL value
of the third server is configured by the bar.example2 zone, which may
or may not be set to a long time. However a short TTL for the A
record of the third server should not have a big impact, because when
the parent zone of foo.example is unavailable, the A record of the
third server may still be resolved even when it is not in the local
cache. This is due to the fact that the outage of the example zone
does not necessarily imply the failure of the bar.example2 zone.
This example also illustrated the benefit of locating secondary
servers under different branches of DNS tree.
Pappas, et al. Expires April 20, 2006 [Page 7]
Internet-Draft Improving DNS Service Availability October 2005
2.2. Handling Name Server Changes
A primary concern of an increased TTL value is data consistency. If
DNS NS RRsets are never changed and the corresponding IPv4 or IPv6
addresses of the servers never change, one could simply set the TTL
value for all the NS and the associated A/AAAA RRsets to the maximum
possible value. The data in all caching resolvers would always stay
consistent with the actual name servers. However, DNS servers do
change from time to time, new servers are added, old servers are
removed, or servers' IP address change due to network
reconfigurations. Such changes can lead to inconsistencies between
the cached NS and A RRsets for DNS servers and the actual servers.
When changes in nameservers or nameserver IP addresses do occur, the
following operational practices should be followed. First, a planned
change should involve a grace period where the old nameserver can
still be reached. Once the information in authoritative DNS servers
has been modified, the obsolete nameserver and/or obsolete IP address
should continue answering queries for the TTL period. This graceful
transition period removes the concern about obsolete data in the
cache since the cached information can still be used to resolve DNS
queries. Note that increased TTL value implies the obsolete server
or IP address should continue to operate for a longer period of time
(one month after the nameserver information has been modified in the
DNS if the one month TTL recommendation is used).
The graceful transition is ideal, but not always possible. In cases
where this is not possible, some caches will contain invalid
nameserver information for the zone. However, DNS already assumes
some authoritative servers may not respond. As long as all servers
have not changed during the TTL period, the zone will continue to be
accessible even to resolvers who have cached the now obsolete data.
Not changing all the servers during the TTL period assures that some
servers can be reached by using cached data, even when the data for
the changed server is obsolete.
One effective way to assure DNS availability in the face of
unexpected changes is for each zone to set up an adequate number of
secondary servers in diverse locations. In the earlier example, when
ns1.foo.example suddenly failed and had to be reinstalled on a
different host, although the cached data for ns1.foo.example can stay
in some resolvers for a long time before it gets flushed out of the
cache, queries for foo.example zone can still be served by the
remaining servers. This remains true as long as not all the RRs in
the NS or A/AAAA RRset change at the same time. The only negative
impact is a longer query time in the event that a cache resolver
first sends a query to ns1.foo.example (a recently failed server).
In this case, the query will timeout after a few second and the
Pappas, et al. Expires April 20, 2006 [Page 8]
Internet-Draft Improving DNS Service Availability October 2005
resolver will try the next server and succeed.
Note that when the query is answered by a working authoritative
server, this server can include the updated NS RRset in the
authoritative section of the reply. Such an inclusion will override
the obsolete RRset that is cached at the caching resolver. Thus the
only penalty paid by a caching server is a longer resolution time for
the first query that is issued after the DNS server changes. If DNS
operators follow the rule of updating the NS and corresponding A
RRsets whenever any zone server changes, a long TTL value should have
little negative impact on DNS performance.
Overall, a month long TTL value is feasible if operators minimize DNS
server changes. Our measurement results, taken over a large set of
randomly chosen DNS zones, suggest that the majority of DNS zones do
not change their NS RRset and the associated A/AAAA records
frequently, and we show this in the next section.
2.3. Impact on Cache Memory Size
Another implication when introducing longer TTLs is a potential
increase in the caching server's memory size. We believe that with
the current typical hardware this is not an issue. For example if
the working set of a very popular caching server is 10 million zones
(around 10% of the worlds DNS zones) then the memory requirements
will be under one GByte of memory, assuming that each zones
infrastructure records take less than 100 bytes of memory.
2.4. Effectiveness of Long TTL on Zone's Availability
So far we have talked about the potential issues related to a long
TTL value for infrastructure RRset. Here we provide a quick back-of-
envelope calculation on the increased zone availability by increasing
the TTL value of an infrastructure RRset. Assume foo.example is a
popular zone and its infrastructure RRset (with a TTL of 4 hours)
tends to be cached in many cache resolvers. If a DDoS attack takes
the example zone out of service for 2 hours, then on average 50% of
the cache resolves will have the foo.example zone's infrastructure
RRset expired by the end of the 2 hours. This would leave them
unable to resolve foo.example or any name under it. If we increase
the TTL value of foo.example's infrastructure RRset to 1 day, then
during a one hour outage of the example zone, only 1/12, or 8% of the
cache resolvers would flush out foo.example's infrastructure RRset
from the cache. If we increase the TTL value to one month, then
after the same 2-hour duration of the example zone's service outage,
foo.example's infrastructure RRset would stay valid in the caches of
99.72% of those cache resolvers that had fetched the RRset earlier.
The longer the TTL is, the more cache resolvers will have valid DNS
Pappas, et al. Expires April 20, 2006 [Page 9]
Internet-Draft Improving DNS Service Availability October 2005
server information in their cache, hence an increased DNS
availability in the face of temporary outages of top level servers.
2.5. Enhancement of Prefetching
Although our above analysis shows that a long TTL value alone can be
effective in increasing DNS service availability, we note that at any
given time, some cache resolvers will have the infrastructure RRsets
in their caches expire. Thus, if some top level zones are of out
service when a resolver's cache entries expire, that resolver loses
the ability to directly contact the destination zones whose
infrastructure RRsets got flushed out. To further improve DNS
service availability, we suggest that cache resolvers pre-fetch all
the infrastructure RRsets that have an initial TTL value > 2 days
(which is currently the default TTL value). We can interpret a long
TTL value for a infrastructure RRset to mean that the zone is "long
TTL aware" and desires high availability. We suggest that the
prefetch is performed when an infrastructure RRset's cache time drops
below TTL/2. Such prefetching assures that a cache resolver will
have valid infrastructure RRsets in the cache, and hence be able to
reach zone servers directly, even when some zones along the DNS
lookup path may have failed. This would remain true as long as the
outage is shorter than TTL/2 time period.
2.6. Backwards Compatibility
The advantages in this approach stem, largely, from its simplicity.
The operational practice of using long TTLs for infrastructure
records does not require any modifications to currently deployed
caches. The proposal is, therefore, backwards compatible with
existing infrastructure, and has no dependency on any specific
implementation of a DNS cache (such as BIND, djbdns, etc.).
Additional features associated with the use of the long TTL, such as
re-fetching, may be incrementally deployed without adversely
affecting any existing or neighboring caches. All additional logic
pertains to an instance's local cache and does not have the ability
to affect or exploit other caches.
Pappas, et al. Expires April 20, 2006 [Page 10]
Internet-Draft Improving DNS Service Availability October 2005
3. Measurement Data
The previous section proposed to set the TTL values of the
infrastructure RRsets to a long period, e.g. one month. Such long
TTL values imply a stable set of DNS servers for each zone. To
assess the stability of currently deployed DNS servers, we conducted
a measurement study. From a crawl over 15 million DNS zones (the
crawl was initiated at DMOZ.ORG), we randomly selected 100,000 zones
and measured their infrastructure RRset over a 4-month period.
During this 4-month period we queried each of the 100,000 zones twice
a day to obtain its infrastructure RRset. Our data shows that 75% of
the measured zones did not change either the NS or corresponding A
RRSets during the entire study period. 11% of the zones showed
changes to their NS RRset during this period, and 5% of the zones
made the changes in less than 2 months. The A records of all the
measured zone servers had more changes than the NS RRsets: 22% of the
zones had their servers' A records changed within 4 months, and 10%
of the zones made servers' A record changes in less than 2 months.
All in all, our measurement results show that the current DNS servers
in majority of the zones are very stable, even those who made changes
during our measurement period show that their DNS server changes are
rather infrequent. We believe that, with a special care, the changes
to DNS servers can be further reduced, and that a TTL value of 1
month is indeed feasible for infrastructure RRsets.
Pappas, et al. Expires April 20, 2006 [Page 11]
Internet-Draft Improving DNS Service Availability October 2005
4. Security Considerations
The long TTL solution prescribes an operational practice that
facilitates DNS queries during prolonged outages. Such outages may
result from extended DDoS attacks against key servers in the DNS.
The use of long TTLs does not reduce the vulnerability of targeted
servers to DDoS attacks. However, the use of long TTLs limits the
effectiveness of a DDoS to the global DNS. While a DDoS may disrupt
the availability of critical nameservers, the NS records for those
zones that are delegated by them will be available in remote caches
for much longer. Therefore, while a DDoS is no less likely, its
scope is dramatically reduced.
Though the long TTL extends the roll-over period that should be
followed when updating NS records for a zone, there exist no
additional operational requirements beyond what is recommended now.
The current guidelines recommend that operators continue to operate
existing nameservers during the period between the date of a change
to the NS records, and that date plus the value of the old TTL. The
only difference under that results from this proposal is to that the
roll-over period is increased in proportion to the TTL.
Failure to adhere to these guidelines has 1 of 2 effects (which exist
in the current mode of operation for the DNS too): If there exist
some nameservers that appear in both the old NS RRSet and the new
one, then any cache that is making use of a cached set may have to
issue multiple A requests and timeout before reaching an active
nameserver. However, if there is no intersection between the
nameservers in the old and the new RRSet, then there exists a period
between the date that the last cache has fetched the old values, and
that time plus 1 TTL, when a cache will direct resolvers to
inoperable nameservers. Neither of these scenarios are a concern if
operators follow the standard procedure of maintaining both sets of
servers (or at least an overlapping set) during roll-overs.
Pappas, et al. Expires April 20, 2006 [Page 12]
Internet-Draft Improving DNS Service Availability October 2005
5. Recommendations
Our analysis shows that using long TTL values for infrastructure
RRsets can be an effective way to increase DNS service availability
in face of top level DNS server outages, and that this simple
operational tuning should have negligible impact on the DNS system
and its performance. Our measurements over a large set of randomly
selected DNS zones also suggest that, in today's practice, the
infrastructure RRsets for majority of DNS zones are indeed stable and
change very infrequently.
Based on our analysis and measurement, we make the following
recommendations. First, conduct further measurement and analysis to
examine the zones with frequent infrastructure RRset changes and
understand the causes. Second, conduct detailed analysis on the
potential impact of long TTL values for infrastructure RRset on
DNSSEC deployment. Third, conduct trial deployment of long TTL
settings with a controlled set of zones and measure the zones'
availability, performance in terms of name resolution delays, and
changes in the zones' server load. We expect a decrease in the
server load. We can first extend the TTL value to 10 days, and then
to one month.
If the trial deployment succeeds without exposing any unexpected
issues, we would like to recommend wide deployment of long TTL
settings for infrastructure RRsets, both for top level zones as well
as for any zones that desire a high availability. Compared to other
DDoS defense approaches, such as anycast root servers, our proposed
long TTL solution seems simpler, more economical, and hopefully just
as effective against any transient outages of DNS lookup paths,
including the failure of top level zones.
Pappas, et al. Expires April 20, 2006 [Page 13]
Internet-Draft Improving DNS Service Availability October 2005
6. Acknowledgments
We would like to express our thanks to Greg Minshall for an early
discussion on the feasibility of using long TTLs to improve DNS
availability, to Pete Resnick for his support and the suggestion of
using one month or even longer TTL values, and to Rob Austin and
Patrik Faltstrom who also provided constructive comment to our
proposal.
7. References
[Mock88] Mockapetris, P. and K. Dunlap, "Development of the Domain
Name System", SIGCOMM, 1988.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2182] Elz, R., Bush, R., Bradner, S., and M. Patton, "Selection
and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
July 1997.
Pappas, et al. Expires April 20, 2006 [Page 14]
Internet-Draft Improving DNS Service Availability October 2005
Authors' Addresses
Vasileios Pappas
University of California, Los Angeles, Department of Computer Science
4732 Boelter Hall
Los Angeles, CA 90095-1596
US
Email: vpappas@cs.ucla.edu
Bin Zhang
Colorado State University, Department of Computer Science
Fort Collins, CO 80523-1873
US
Email: zhangb@cs.colostate.edu
Eric Osterweil
University of California, Los Angeles, Department of Computer Science
4732 Boelter Hall
Los Angeles, CA 90095-1596
US
Email: eoster@cs.ucla.edu
Dan Massey
Colorado State University, Department of Computer Science
Fort Collins, CO 80523-1873
US
Email: massey@cs.colostate.edu
Lixia Zhang
University of California, Los Angeles, Department of Computer Science
4732 Boelter Hall
Los Angeles, CA 90095-1596
US
Email: lixia@cs.ucla.edu
Pappas, et al. Expires April 20, 2006 [Page 15]
Internet-Draft Improving DNS Service Availability October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Pappas, et al. Expires April 20, 2006 [Page 16]