--- 1/draft-ietf-dnsext-rfc2672bis-dname-14.txt 2009-03-06 15:12:11.000000000 +0100 +++ 2/draft-ietf-dnsext-rfc2672bis-dname-15.txt 2009-03-06 15:12:11.000000000 +0100 @@ -1,104 +1,121 @@ DNS Extensions Working Group S. Rose Internet-Draft NIST Obsoletes: 2672 (if approved) W. Wijngaards Updates: 3363,4294 NLnet Labs -(if approved) July 15, 2008 +(if approved) March 6, 2009 Intended status: Standards Track -Expires: January 16, 2009 +Expires: September 7, 2009 Update to DNAME Redirection in the DNS - draft-ietf-dnsext-rfc2672bis-dname-14 + draft-ietf-dnsext-rfc2672bis-dname-15 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. + This Internet-Draft is submitted to IETF in full conformance with the + provisions of BCP 78 and BCP 79. This document may contain material + from IETF Documents or IETF Contributions published or made publicly + available before November 10, 2008. The person(s) controlling the + copyright in some of this material may not have granted the IETF + Trust the right to allow modifications of such material outside the + IETF Standards Process. Without obtaining an adequate license from + the person(s) controlling the copyright in such materials, this + document may not be modified outside the IETF Standards Process, and + derivative works of it may not be created outside the IETF Standards + Process, except to format it for publication as an RFC or to + translate it into languages other than English. 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 January 16, 2009. + This Internet-Draft will expire on September 7, 2009. Copyright Notice - Copyright (C) The IETF Trust (2008). + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents in effect on the date of + publication of this document (http://trustee.ietf.org/license-info). + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. Abstract The DNAME record provides redirection for a sub-tree of the domain name tree in the DNS system. That is, all names that end with a particular suffix are redirected to another part of the DNS. This is a revision of the original specification in RFC 2672, also aligning RFC 3363 and RFC 4294 with this revision. Requirements Language 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 RFC 2119 [RFC2119]. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 3 - 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 4 - 2.3. DNAME Apex not Redirected itself . . . . . . . . . . . . . 5 - 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 6 - 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 6 + 2. The DNAME Resource Record . . . . . . . . . . . . . . . . . . 4 + 2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.2. The DNAME Substitution . . . . . . . . . . . . . . . . . . 5 + 2.3. DNAME Apex not Redirected itself . . . . . . . . . . . . . 6 + 2.4. Names Next to and Below a DNAME Record . . . . . . . . . . 7 + 2.5. Compression of the DNAME record. . . . . . . . . . . . . . 7 - 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.1. CNAME synthesis and UD bit . . . . . . . . . . . . . . . . 7 - 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 8 - 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 10 + 3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1. CNAME synthesis and UD bit . . . . . . . . . . . . . . . . 8 + 3.2. Server algorithm . . . . . . . . . . . . . . . . . . . . . 9 + 3.3. Wildcards . . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.4. Acceptance and Intermediate Storage . . . . . . . . . . . 11 - 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 10 + 4. DNAME Discussions in Other Documents . . . . . . . . . . . . . 12 - 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 12 - 5.1. Canonical hostnames cannot be below DNAME owners . . . . . 12 - 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 12 - 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 12 - 5.3.1. DNAME bit in NSEC type map . . . . . . . . . . . . . . 12 - 5.3.2. Validators Must Understand DNAME . . . . . . . . . . . 12 - 5.3.2.1. DNAME in Bitmap Causes Invalid Name Error . . . . 13 - 5.3.2.2. Valid Name Error Response Involving DNAME in - Bitmap . . . . . . . . . . . . . . . . . . . . . . 13 - 5.3.2.3. Response With Synthesized CNAME . . . . . . . . . 13 + 5. Other Issues with DNAME . . . . . . . . . . . . . . . . . . . 13 + 5.1. Canonical hostnames cannot be below DNAME owners . . . . . 13 + 5.2. Dynamic Update and DNAME . . . . . . . . . . . . . . . . . 13 + 5.3. DNSSEC and DNAME . . . . . . . . . . . . . . . . . . . . . 13 + 5.3.1. Signed DNAME, Unsigned Synthesized CNAME . . . . . . . 14 + 5.3.2. DNAME Bit in NSEC Type Map . . . . . . . . . . . . . . 14 + 5.3.3. DNAME Chains as Strong as the Weakest Link . . . . . . 14 + 5.3.4. Validators Must Understand DNAME . . . . . . . . . . . 14 + 5.3.4.1. DNAME in Bitmap Causes Invalid Name Error . . . . 14 + 5.3.4.2. Valid Name Error Response Involving DNAME in + Bitmap . . . . . . . . . . . . . . . . . . . . . . 15 + 5.3.4.3. Response With Synthesized CNAME . . . . . . . . . 15 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 - 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 + 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 1. Introduction DNAME is a DNS Resource Record type originally defined in RFC 2672 [RFC2672]. DNAME provides redirection from a part of the DNS name tree to another part of the DNS name tree. The DNAME RR and the CNAME RR [RFC1034] cause a lookup to (potentially) return data corresponding to a domain name different from the queried domain name. The difference between the two @@ -206,52 +223,51 @@ loops. DNAMEs and CNAMEs can chain together to form loops. A single corner case DNAME can form a loop. Resolvers and servers should be cautious in devoting resources to a query, but be aware that fairly long chains of DNAMEs may be valid. Zone content administrators should take care to insure that there are no loops that could occur when using DNAME or DNAME/CNAME redirection. The domain name can get too long during substitution. For example, suppose the target name of the DNAME RR is 250 octets in length (multiple labels), if an incoming QNAME that has a first label over 5 - octets in length, the result of the result would be a name over 255 - octets. If this occurs the server returns an RCODE of YXDOMAIN - [RFC2136]. The DNAME record and its signature (if the zone is - signed) are included in the answer as proof for the YXDOMAIN (value - 6) RCODE. + octets in length, the result would be a name over 255 octets. If + this occurs the server returns an RCODE of YXDOMAIN [RFC2136]. The + DNAME record and its signature (if the zone is signed) are included + in the answer as proof for the YXDOMAIN (value 6) RCODE. 2.3. DNAME Apex not Redirected itself Unlike a CNAME RR, a DNAME RR redirects DNS names subordinate to its owner name; the owner name of a DNAME is not redirected itself. The domain name that owns a DNAME record is allowed to have other - resource record types at that domain name, except DNAMEs or CNAMEs. - This means that DNAME RRs are not allowed at the parent side of a - delegation point but are allowed at a zone apex. + resource record types at that domain name, except DNAMEs, CNAMEs or + other types that have restrictions on what they can co-exist with. + DNAME RRs are not allowed at the parent side of a delegation point + but are allowed at a zone apex. - The reason for this decision was that one can have a DNAME at the - zone apex. There still is a need to have the customary SOA and NS - resource records at the zone apex. This means that DNAME does not - mirror a zone completely, as it does not mirror the zone apex. + There still is a need to have the customary SOA and NS resource + records at the zone apex. This means that DNAME does not mirror a + zone completely, as it does not mirror the zone apex. These rules also allow DNAME records to be queried through RFC 1034 [RFC1034] compliant, DNAME-unaware caches. 2.4. Names Next to and Below a DNAME Record - Resource records MUST NOT exist at any domain name subordinate to the - owner of a DNAME RR. To get the contents for names subordinate to - that owner, the DNAME redirection must be invoked and the resulting - target queried. A server MAY refuse to load a zone that has data at - a domain name subordinate to a domain name owning a DNAME RR. If the - server does load the zone, those names below the DNAME RR will be - occluded, RFC 2136 [RFC2136], section 7.18. Also a server SHOULD + Resource records MUST NOT exist at any sub-domain of the owner of a + DNAME RR. To get the contents for names subordinate to that owner + name, the DNAME redirection must be invoked and the resulting target + queried. A server MAY refuse to load a zone that has data at a sub- + domain of a domain name owning a DNAME RR. If the server does load + the zone, those names below the DNAME RR will be occluded as + described in RFC 2136 [RFC2136], section 7.18. Also a server SHOULD refuse to load a zone subordinate to the owner of a DNAME record in the ancestor zone. See Section 5.2 for further discussion related to dynamic update. DNAME is a singleton type, meaning only one DNAME is allowed per name. The owner name of a DNAME can only have one DNAME RR, and no CNAME RRs can exist at that name. These rules make sure that for a single domain name only one redirection exists, and thus no confusion which one to follow. A server SHOULD refuse to load a zone that violates these rules. @@ -270,67 +286,71 @@ RFC 2672 (obsoleted by this document) stated that the EDNS version had a meaning for understanding of DNAME and DNAME target name compression. This document revises RFC 2672, in that there is no EDNS version signaling for DNAME. However, the flags section of EDNS(0) is updated with a Understand-DNAME flag by this document (See Section 3.3). 3. Processing - The DNAME RR causes type NS additional section processing. + The DNAME RR causes type NS additional section processing. This + refers to action at step 6 of the server algorithm outlined in + section 3.2. 3.1. CNAME synthesis and UD bit - When preparing an response, a server upon performing a DNAME - substitution will in all cases include the DNAME RR used in the - answer section. A CNAME RR record with TTL equal to the - corresponding DNAME RR is synthesized and included in the answer - section for old resolvers. The owner name of the CNAME is the QNAME - of the query. DNSSEC [RFC4033], [RFC4034], [RFC4035] says that the - synthesized CNAME does not have to be signed. The DNAME has an RRSIG - and a validating resolver can check the CNAME against the DNAME - record and validate the DNAME record. + When preparing an response, a server performing a DNAME substitution + will in all cases include the relevant DNAME RR in the answer + section. A CNAME RR with TTL equal to the corresponding DNAME RR is + synthesized and included in the answer section for resolvers that did + not indicate understanding of DNAME in queries. The owner name of + the CNAME is the QNAME of the query. The DNSSEC specification + [RFC4033], [RFC4034], [RFC4035] says that the synthesized CNAME does + not have to be signed. The DNAME has an RRSIG and a validating + resolver can check the CNAME against the DNAME record and validate + the signature over the DNAME RR. Resolvers MUST be able to handle a synthesized CNAME TTL of zero or equal to the TTL of the corresponding DNAME record. A TTL of zero means that the CNAME can be discarded immediately after processing the answer. DNAME aware resolvers can set the Understand-DNAME (UD - bit) to receive a response with only the DNAME RR and no synthesized - CNAMEs. + bit) to indicate that they can handle a response with only a DNAME RR + and no synthesized CNAMEs. The UD bit is part of the EDNS [RFC2671] extended RCODE and Flags field. It is used to omit server processing, transmission and resolver processing of unsigned synthesized CNAMEs. Resolvers can set this in a query to request omission of the synthesized CNAMEs. Servers copy the UD bit to the response, and can omit synthesized - CNAMEs from the answer. Older resolvers do not set the UD bit, and - older servers do not copy the UD bit to the answer, and will not omit - synthesized CNAMEs. + CNAMEs from the answer. Resolvers that do not implement this + specification, do not set the UD bit, and servers that do not + implement this specification do not copy the UD bit to the answer, + and will not omit synthesized CNAMEs. Updated EDNS extended RCODE and Flags field. +0 (MSB) +1 (LSB) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0: | EXTENDED-RCODE | VERSION | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2: |DO|UD| Z | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Servers MUST be able to answer a query for a synthesized CNAME. Like other query types this invokes the DNAME, and synthesizes the CNAME into the answer. 3.2. Server algorithm - Below the server algorithm, which appeared in RFC 2672 Section 4.1, - is expanded to handle the UD (Understand-DNAME) bit. + Below is the server algorithm, which appeared in RFC 2672 Section + 4.1, it is expanded to handle the UD (Understand-DNAME) bit. 1. Set or clear the value of recursion available in the response depending on whether the name server is willing to provide recursive service. If recursive service is available and requested via the RD bit in the query, go to step 5, otherwise step 2. 2. Search the available zones for the zone which is the nearest ancestor to QNAME. If such a zone is found, go to step 3, otherwise step 4. @@ -418,40 +438,46 @@ [RFC4592]. Thus records of the form "*.example.com DNAME example.net" SHOULD NOT be used. The interaction between the expansion of the wildcard and the redirection of the DNAME is non-deterministic. Because the processing is non-deterministic, DNSSEC validating resolvers may not be able to validate a wildcarded DNAME. A server MAY give a warning that the behavior is unspecified if such a wildcarded DNAME is loaded. The server MAY refuse it, refuse to - load or refuse dynamic update. + load the zone or refuse dynamic updates. 3.4. Acceptance and Intermediate Storage Recursive caching name servers can encounter data at names below the owner name of a DNAME RR, due to a change at the authoritative server where data from before and after the change resides in the cache. This conflict situation is a transitional phase, that ends when the old data times out. The caching name server can opt to store both old and new data and treat each as if the other did not exist, or drop the old data, or drop the longer domain name. In any approach, consistency returns after the older data TTL times out. Recursive caching name servers MUST perform CNAME synthesis on behalf of DNAME-ignorant clients. A recursive caching name server that understands DNAMEs can send out queries on behalf of clients with the UD bit set (See Section 3.1). After receiving the answers the recursive caching name server sends replies to DNAME ignorant clients that include DNAMEs and synthesized CNAMEs. + If a recursive caching name server encounters a DNAME RR which + contradicts information already in the cache (excluding CNAME + records), it SHOULD NOT cache the DNAME RR, but it MAY cache the + CNAME record received along with it or synthesized from the DNAME + record, subject to the rules for CNAME caching. + 4. DNAME Discussions in Other Documents In [RFC2181], in Section 10.3., the discussion on MX and NS records touches on redirection by CNAMEs, but this also holds for DNAMEs. Excerpt from 10.3. MX and NS records (in RFC 2181). The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this @@ -523,105 +549,133 @@ DNAME records can be added, changed and removed in a zone using dynamic update transactions. Adding a DNAME RR to a zone occludes any domain names that may exist under the added DNAME. A server MUST reject a dynamic update message that attempts to add a DNAME RR at a name that already has a CNAME RR or another DNAME RR associated with that name. 5.3. DNSSEC and DNAME -5.3.1. DNAME bit in NSEC type map + The following is for implementations that understand both DNSSEC and + DNAME (synthesis). - When a validator checks the NSEC RRs returned on a name error - response, it SHOULD check that the DNAME bit is not set. If the - DNAME bit is set then the DNAME substitution should have been done, - but has not. +5.3.1. Signed DNAME, Unsigned Synthesized CNAME -5.3.2. Validators Must Understand DNAME + In any response, a signed DNAME RR indicates a non-terminal + redirection of the query. There might or might not be a server + synthesized CNAME in the answer section, if there is, the CNAME will + never be signed. For a DNSSEC validator, verification of the DNAME + RR and then checking that the CNAME was properly synthesized is + sufficient proof. + +5.3.2. DNAME Bit in NSEC Type Map + + In any negative response, the NSEC or NSEC3 [RFC5155] record type bit + map SHOULD be checked to see that there was no DNAME that could have + been applied. If the DNAME bit in the type bit map is set and the + query name is a subdomain of the closest encloser that is asserted, + then DNAME substitution should have been done, but the substitution + has not been done as specified. + +5.3.3. DNAME Chains as Strong as the Weakest Link + + A response can contain a chain of DNAME and CNAME redirections. That + chain can end in a positive answer or a negative (no name error or no + data error) reply. Each step in that chain results in resource + records added to the answer or authority section of the response. + Only if all steps are secure can the AD bit be set for the response. + If one of the steps is bogus, the result is bogus. + +5.3.4. Validators Must Understand DNAME Below are examples of why DNSSEC validators MUST understand DNAME. + In the examples below, SOA records, wildcard denial NSECs and other + material not under discussion has been omitted. -5.3.2.1. DNAME in Bitmap Causes Invalid Name Error +5.3.4.1. DNAME in Bitmap Causes Invalid Name Error ;; Header: QR AA DO RCODE=3(NXDOMAIN) ;; Question foo.bar.example.com. IN A - ;; Answer + ;; Authority bar.example.com. NSEC dub.example.com. A DNAME bar.example.com. RRSIG NSEC [valid signature] - If this is the response, then only by understanding that the DNAME - bit means that foo.bar.example.com needed to have been redirected by - the DNAME, the validator can see that it is a BOGUS reply from an - attacker that collated existing records from the DNS to create a - confusing reply. + If this is the received response, then only by understanding that the + DNAME bit in the NSEC bitmap means that foo.bar.example.com needed to + have been redirected by the DNAME, the validator can see that it is a + BOGUS reply from an attacker that collated existing records from the + DNS to create a confusing reply. If the DNAME bit had not been set in the NSEC record above then the answer would have validated as a correct name error response. -5.3.2.2. Valid Name Error Response Involving DNAME in Bitmap +5.3.4.2. Valid Name Error Response Involving DNAME in Bitmap ;; Header: QR AA DO RCODE=3(NXDOMAIN) ;; Question cee.example.com. IN A - ;; Answer + ;; Authority bar.example.com. NSEC dub.example.com. A DNAME bar.example.com. RRSIG NSEC [valid signature] - This reply has the same NSEC records as the example above, but with - this query name (cee.example.com), the answer is validated, because - 'cee' does not get redirected by the DNAME at 'bar'. + This response has the same NSEC records as the example above, but + with this query name (cee.example.com), the answer is validated, + because 'cee' does not get redirected by the DNAME at 'bar'. -5.3.2.3. Response With Synthesized CNAME +5.3.4.3. Response With Synthesized CNAME ;; Header: QR AA DO RCODE=0(NOERROR) ;; Question foo.bar.example.com. IN A ;; Answer bar.example.com. DNAME bar.example.net. bar.example.com. RRSIG DNAME [valid signature] foo.bar.example.com. CNAME foo.bar.example.net. - The answer shown above has the synthesized CNAME included. However, - the CNAME has no signature, since the server does not sign online. - So it cannot be trusted. It could be altered by an attacker to be - foo.bar.example.com CNAME bla.bla.example. The DNAME record does - have its signature included, since it does not change for every query - name. The validator must verify the DNAME signature and then + The response shown above has the synthesized CNAME included. + However, the CNAME has no signature, since the server does not sign + online. So this response cannot be trusted. It could be altered by + an attacker to be foo.bar.example.com CNAME bla.bla.example. The + DNAME record does have its signature included, since it does not + change. The validator must verify the DNAME signature and then recursively resolve further to query for the foo.bar.example.net A record. 6. IANA Considerations The DNAME Resource Record type code 39 (decimal) originally has been registered by [RFC2672]. IANA should update the DNS resource record registry to point to this document for RR type 39. This draft requests the second highest bit in the EDNS flags field for the Understand-DNAME (UD) flag as described in Section 3.1. 7. Security Considerations DNAME redirects queries elsewhere, which may impact security based on policy and the security status of the zone with the DNAME and the - redirection zone's security status. + redirection zone's security status. For validating resolvers, the + lowest security status of the links in the chain of CNAME and DNAME + redirections is applied to the result. If a validating resolver accepts wildcarded DNAMEs, this creates security issues. Since the processing of a wildcarded DNAME is non- deterministic and the CNAME that was substituted by the server has no signature, the resolver may choose a different result than what the server meant, and consequently end up at the wrong destination. Use of wildcarded DNAMEs is discouraged in any case [RFC4592]. A validating resolver MUST understand DNAME, according to [RFC4034]. - In Section 5.3.2 examples are given that illustrate this need. + In RFC 4034 Section 5.3.4 examples are given that illustrate this + need. 8. Acknowledgments The authors of this draft would like to acknowledge Matt Larson for beginning this effort to address the issues related to the DNAME RR type. The authors would also like to acknowledge Paul Vixie, Ed Lewis, Mark Andrews, Mike StJohns, Niall O'Reilly, Sam Weiler, Alfred Hoenes and Kevin Darcy for their review and comments on this document. @@ -663,20 +717,24 @@ Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, July 2006. + [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS + Security (DNSSEC) Hashed Authenticated Denial of + Existence", RFC 5155, March 2008. + 9.2. Informative References [RFC1912] Barr, D., "Common DNS Operational and Configuration Errors", RFC 1912, February 1996. [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999. [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, "Representing Internet Protocol version 6 (IPv6) @@ -693,61 +751,16 @@ 100 Bureau Dr. Gaithersburg, MD 20899 USA Phone: +1-301-975-8439 Fax: +1-301-975-6238 EMail: scottr@nist.gov Wouter Wijngaards NLnet Labs - Kruislaan 419 - Amsterdam 1098 VA + Science Park 140 + Amsterdam 1098 XG The Netherlands Phone: +31-20-888-4551 EMail: wouter@nlnetlabs.nl - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - 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. - - 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, THE IETF TRUST 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. - -Intellectual Property - - 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. - -Acknowledgement - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA).