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]