draft-ietf-dnsext-dnssec-trans-03.txt   draft-ietf-dnsext-dnssec-trans-04.txt 
DNS Extensions Working Group R. Arends DNS Extensions Working Group R. Arends
Internet-Draft Telematica Instituut Internet-Draft Nominet UK
Expires: April 26, 2006 P. Koch Expires: December 28, 2006 P. Koch
DENIC eG DENIC eG
J. Schlyter J. Schlyter
NIC-SE Kirei AB
October 23, 2005 June 26, 2006
Evaluating DNSSEC Transition Mechanisms Evaluating DNSSEC Transition Mechanisms
draft-ietf-dnsext-dnssec-trans-03.txt draft-ietf-dnsext-dnssec-trans-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2006. This Internet-Draft will expire on December 28, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document collects and summarizes different proposals for This document collects and summarizes different proposals for
alternative and additional strategies for authenticated denial in DNS alternative and additional strategies for authenticated denial in DNS
responses, evaluates these proposals and gives a recommendation for a responses, evaluates these proposals and gives a recommendation for a
way forward. way forward. It is a snapshot of the DNSEXT working group discussion
of June 2004.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3 2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3
2.1. Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4 2.1. Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4
2.1.1. Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4 2.1.1. Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4
2.1.2. Add Versioning/Subtyping to Current NSEC . . . . . . . 5 2.1.2. Add Versioning/Subtyping to Current NSEC . . . . . . . 5
2.1.3. Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6 2.1.3. Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6
2.1.4. New Apex Type . . . . . . . . . . . . . . . . . . . . 6 2.1.4. New Apex Type . . . . . . . . . . . . . . . . . . . . 7
2.1.5. NSEC White Lies . . . . . . . . . . . . . . . . . . . 7 2.1.5. NSEC White Lies . . . . . . . . . . . . . . . . . . . 7
2.1.6. NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8 2.1.6. NSEC Optional via DNSKEY Flag . . . . . . . . . . . . 8
2.1.7. New Answer Pseudo RR Type . . . . . . . . . . . . . . 9 2.1.7. New Answer Pseudo RR Type . . . . . . . . . . . . . . 9
2.2. Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 9 2.2. Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
2.2.1. Partial Type-code and Signal Rollover . . . . . . . . 9 2.2.1. Partial Type-code and Signal Rollover . . . . . . . . 10
2.2.2. A Complete Type-code and Signal Rollover . . . . . . . 10 2.2.2. A Complete Type-code and Signal Rollover . . . . . . . 10
2.2.3. Unknown (New) Algorithm in DS, DNSKEY, and RRSIG . . . 11 2.2.3. Unknown (New) Algorithm in DS, DNSKEY, and RRSIG . . . 11
2.2.4. Unknown (New) Hash Algorithm in DS . . . . . . . . . . 12 2.2.4. Unknown (New) Hash Algorithm in DS . . . . . . . . . . 12
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 13 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5.1. Normative References . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Informative References . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Introduction 1. Introduction
This report shall document the process of dealing with the NSEC This report shall document the process of dealing with the NSEC zone
walking problem late in the Last Call for [RFC4033], [RFC4034], and walking problem late in the Last Call for [RFC4033], [RFC4034], and
[RFC4035]. It preserves some of the discussion that took place in [RFC4035] (further referred to as DNSSEC-bis). It preserves some of
the DNSEXT WG during the first half of June 2004 as well as some the discussion that took place in the DNSEXT WG during the first half
additional ideas that came up subsequently. of June 2004 as well as some additional ideas that came up
subsequently.
This is an edited excerpt of the chairs' mail to the WG: This is an edited excerpt of the chairs' mail to the WG:
The working group consents on not including NSEC-alt in the The working group consents on not including NSEC-alt in the
DNSSEC-bis documents. The working group considers to take up DNSSEC-bis documents. The working group considers to take up
"prevention of zone enumeration" as a work item. "prevention of zone enumeration" as a work item.
There may be multiple mechanisms to allow for co-existence with There may be multiple mechanisms to allow for co-existence with
DNSSEC-bis. The chairs allow the working group a little over a DNSSEC-bis. The chairs allow the working group a little over a
week (up to June 12, 2004) to come to consensus on a possible week (up to June 12, 2004) to come to consensus on a possible
modification to the document to enable gentle rollover. If that modification to the document to enable gentle rollover. If that
consensus cannot be reached the DNSSEC-bis documents will go out consensus cannot be reached the DNSSEC-bis documents will go out
skipping to change at page 4, line 51 skipping to change at page 5, line 7
The current DNSSEC-bis documents might need to be updated to indicate The current DNSSEC-bis documents might need to be updated to indicate
that the next owner name might not be an existing name in the zone. that the next owner name might not be an existing name in the zone.
This is not a real change to the spec since implementers have been This is not a real change to the spec since implementers have been
warned not to synthesize with previously cached NSEC records. A warned not to synthesize with previously cached NSEC records. A
specific bit to identify the dynamic signature generating key might specific bit to identify the dynamic signature generating key might
be useful as well, to prevent it from being used to fake positive be useful as well, to prevent it from being used to fake positive
data. data.
2.1.1.4. Cons 2.1.1.4. Cons
Unbalanced cost is a ground for DDoS. Though this protects against Unbalanced cost may be abused for Denial of Service (DoS) attacks on
enumeration, it is not really a path for versioning. the synthesizing name servers. While dynamic synthesis protects
against enumeration, it is not really a path for versioning.
2.1.1.5. Pros 2.1.1.5. Pros
Hardly any amendments to DNSSEC-bis. Hardly any amendments to DNSSEC-bis.
2.1.2. Add Versioning/Subtyping to Current NSEC 2.1.2. Add Versioning/Subtyping to Current NSEC
This proposal introduces versioning for the NSEC RR type (a.k.a. This proposal introduces versioning for the NSEC RR type (a.k.a.
subtyping) by adding a (one octet) version field to the NSEC RDATA. subtyping) by adding a (one octet) version field to the NSEC RDATA.
Version number 0 is assigned to the current (DNSSEC-bis) meaning, Version number 0 is assigned to the current (DNSSEC-bis) meaning,
skipping to change at page 5, line 44 skipping to change at page 5, line 49
2.1.2.3. Amendments to DNSSEC-bis 2.1.2.3. Amendments to DNSSEC-bis
Full Update of the current DNSSEC-bis documents to provide for new Full Update of the current DNSSEC-bis documents to provide for new
fields in NSEC, while specifying behavior in case of unknown field fields in NSEC, while specifying behavior in case of unknown field
values. values.
2.1.2.4. Cons 2.1.2.4. Cons
Though this is a clean and clear path without versioning DNSSEC, it Though this is a clean and clear path without versioning DNSSEC, it
takes some time to design, gain consensus, update the current dnssec- takes some time to design, gain consensus, update the current DNSSEC-
bis document, test and implement a new authenticated denial record. bis document, test and implement a new authenticated denial record.
2.1.2.5. Pros 2.1.2.5. Pros
Does not introduce an iteration to DNSSEC while providing a clear and Does not introduce an iteration to DNSSEC while providing a clear and
clean migration strategy. clean migration strategy.
2.1.3. Type Bit Map NSEC Indicator 2.1.3. Type Bit Map NSEC Indicator
Bits in the type-bit-map are reused or allocated to signify the Bits in the type-bit-map are reused or allocated to signify the
skipping to change at page 6, line 31 skipping to change at page 6, line 36
2.1.3.2. Limitations 2.1.3.2. Limitations
This mechanism uses an NSEC field that was not designed for that This mechanism uses an NSEC field that was not designed for that
purpose. Similar methods were discussed during the Opt-In discussion purpose. Similar methods were discussed during the Opt-In discussion
and the Silly-State discussion. and the Silly-State discussion.
2.1.3.3. Amendments to DNSSEC-bis 2.1.3.3. Amendments to DNSSEC-bis
The specific type-bit-map-bits must be allocated and they need to be The specific type-bit-map-bits must be allocated and they need to be
specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis) specified as 'Must Be Zero' (MBZ) when used for standard (DNSSEC-bis)
interpretation. Also, behaviour of the resolver and validator must interpretation. Also, behaviour of the resolver and validator must
be documented in case unknown values are encountered for the MBZ be documented in case unknown values are encountered for the MBZ
field. Currently the protocol document specifies that the validator field. Currently the protocol document specifies that the validator
MUST ignore the setting of the NSEC and the RRSIG bits, while other MUST ignore the setting of the NSEC and the RRSIG bits, while other
bits are only used for the specific purpose of the type-bit-map field bits are only used for the specific purpose of the type-bit-map field
2.1.3.4. Cons 2.1.3.4. Cons
The type-bit-map was not designed for this purpose. It is a The type-bit-map was not designed for this purpose. It is a
straightforward hack. Text in protocol section 5.4 was put in straightforward hack. Text in protocol section 5.4 was put in
skipping to change at page 7, line 22 skipping to change at page 7, line 27
2.1.4.2. Limitations 2.1.4.2. Limitations
A record of this kind is likely to carry additional feature/ A record of this kind is likely to carry additional feature/
versioning indications unrelated to the current question of versioning indications unrelated to the current question of
authenticated denial. authenticated denial.
2.1.4.3. Amendments to DNSSEC-bis 2.1.4.3. Amendments to DNSSEC-bis
The current DNSSEC-bis documents need to be updated to indicate that The current DNSSEC-bis documents need to be updated to indicate that
the absence of this type indicates dnssec-bis, and that the (mere) the absence of this type indicates DNSSEC-bis, and that the (mere)
presence of this type indicated unknown versions. presence of this type indicated unknown versions.
2.1.4.4. Cons 2.1.4.4. Cons
The only other 'zone' or 'apex' record is the SOA record. Though The only other 'zone' or 'apex' record is the SOA record. Adding
this proposal is not new, it is yet unknown how it might fulfill more RRs to the zone apex bloats QTYPE ANY responses for this apex.
authenticated denial extensions. This new RR type would only provide Even though the proposal is not new, it is yet unknown how it might
for a generalized signaling mechanism, not the new authenticated fulfill authenticated denial extensions. This new RR type would only
denial scheme. Since it is likely to be general in nature, due to provide for a generalized signaling mechanism, not the new
this generality consensus is not to be reached soon. authenticated denial scheme. Since it is likely to be general in
nature, due to this generality consensus is not to be reached soon.
2.1.4.5. Pros 2.1.4.5. Pros
This approach would allow for a lot of other per zone information to This approach would allow for a lot of other per zone information to
be transported or signaled to both (slave) servers and resolvers. be transported or signaled in band to both (slave) servers and
resolvers.
2.1.5. NSEC White Lies 2.1.5. NSEC White Lies
This proposal disables one part of NSEC (the pointer part) by means This proposal disables one part of NSEC (the pointer part) by means
of a special target (root, apex, owner, ...), leaving intact only the of a special target (root, apex, owner, ...), leaving intact only the
ability to authenticate denial of existence of RR sets, not denial of ability to authenticate denial of existence of RR sets, not denial of
existence of domain names (NXDOMAIN). It may be necessary to have existence of domain names (NXDOMAIN). It may be necessary to have
one working NSEC to prove the absence of a wildcard. one working NSEC to prove the absence of a wildcard.
2.1.5.1. Coexistence and Migration 2.1.5.1. Coexistence and Migration
skipping to change at page 8, line 30 skipping to change at page 8, line 36
the requirements for authenticated denial of existence. Security the requirements for authenticated denial of existence. Security
implications need to be carefully documented: search path problems implications need to be carefully documented: search path problems
(forged denial of existence may lead to wrong expansion of non-FQDNs (forged denial of existence may lead to wrong expansion of non-FQDNs
[RFC1535]) and replay attacks to deny existence of records. [RFC1535]) and replay attacks to deny existence of records.
2.1.5.5. Pros 2.1.5.5. Pros
Hardly any amendments to DNSSEC-bis. Operational "trick" that is Hardly any amendments to DNSSEC-bis. Operational "trick" that is
available anyway. available anyway.
2.1.6. NSEC Optional via DNSSKEY Flag 2.1.6. NSEC Optional via DNSKEY Flag
A new DNSKEY may be defined to declare NSEC optional per zone. A new DNSKEY may be defined to declare NSEC optional per zone.
2.1.6.1. Coexistence and Migration 2.1.6.1. Coexistence and Migration
Current resolvers/validators will not understand the Flag bit and Current resolvers/validators will not understand the Flag bit and
will have to treat negative responses as bogus. Otherwise, no will have to treat negative responses as bogus. Otherwise, no
migration path is needed since NSEC is simply turned off. migration path is needed since NSEC is simply turned off.
2.1.6.2. Limitations 2.1.6.2. Limitations
skipping to change at page 9, line 12 skipping to change at page 9, line 17
New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to
be specified in the light of absence of authenticated denial. be specified in the light of absence of authenticated denial.
2.1.6.4. Cons 2.1.6.4. Cons
Doesn't fully meet requirements. Operational consequences to be Doesn't fully meet requirements. Operational consequences to be
studied. studied.
2.1.6.5. Pros 2.1.6.5. Pros
Official version of the "trick" presented in (8). Operational Official version of the "trick" presented in Section 2.1.5.
problems can be addressed during future work on validators. Operational problems can be addressed during future work on
validators.
2.1.7. New Answer Pseudo RR Type 2.1.7. New Answer Pseudo RR Type
A new pseudo RR type may be defined that will be dynamically created A new pseudo RR type may be defined that will be dynamically created
(and signed) by the responding authoritative server. The RR in the (and signed) by the responding authoritative server. The RR in the
response will cover the QNAME, QCLASS and QTYPE and will authenticate response will cover the QNAME, QCLASS and QTYPE and will authenticate
both denial of existence of name (NXDOMAIN) or RRset. both denial of existence of name (NXDOMAIN) or RRset.
2.1.7.1. Coexistence and Migration 2.1.7.1. Coexistence and Migration
skipping to change at page 10, line 27 skipping to change at page 10, line 34
2.2.1.2. Limitations 2.2.1.2. Limitations
None. None.
2.2.1.3. Amendments to DNSSEC-bis 2.2.1.3. Amendments to DNSSEC-bis
None. None.
2.2.1.4. Cons 2.2.1.4. Cons
It is cumbersome to carefully craft an TCR that 'just fits'. The It is cumbersome to carefully craft a type code roll (TCR) that 'just
DNSSEC-bis protocol has many 'borderline' cases that needs special fits'. The DNSSEC-bis protocol has many 'borderline' cases that need
consideration. It might be easier to do a full TCR, since a few of special consideration. It might be easier to do a full TCR, since a
the types and signals need upgrading anyway. few of the types and signals need upgrading anyway.
2.2.1.5. Pros 2.2.1.5. Pros
Graceful adoption of future versions of NSEC, while there are no Graceful adoption of future versions of NSEC, while there are no
amendments to DNSSEC-bis. amendments to DNSSEC-bis.
2.2.2. A Complete Type-code and Signal Rollover 2.2.2. A Complete Type-code and Signal Rollover
A new DNSSEC space is defined which can exist independent of current A new DNSSEC space is defined which can exist independent of current
DNSSEC-bis space. DNSSEC-bis space.
skipping to change at page 13, line 27 skipping to change at page 13, line 31
work on a partial TCR, allowing graceful transition towards a future work on a partial TCR, allowing graceful transition towards a future
version of NSEC. Meanwhile, to accomodate the need for an version of NSEC. Meanwhile, to accomodate the need for an
immediately, temporary, solution against zone-traversal, we recommend immediately, temporary, solution against zone-traversal, we recommend
On-Demand NSEC synthesis. On-Demand NSEC synthesis.
This approach does not require any mandatory changes to DNSSEC-bis, This approach does not require any mandatory changes to DNSSEC-bis,
does not violate the protocol and fulfills the requirements. As a does not violate the protocol and fulfills the requirements. As a
side effect, it moves the cost of implementation and deployment to side effect, it moves the cost of implementation and deployment to
the users (zone owners) of this mechanism. the users (zone owners) of this mechanism.
4. Acknowledgements 4. Security Considerations
This document deals with transition mechanisms for new versions of
the DNS Security Extensions. The particular considerations for the
methods studied are listed in the respective sections, most
importantly the requirement for keeping private keys online in
Section 2.1.1 and Section 2.1.7 and the full or partial abandoning of
authenticated denial in Section 2.1.5 and Section 2.1.6.
5. IANA Considerations
This document does not create any new IANA registry nor does it ask
for any allocation from an existing IANA registry.
6. Acknowledgements
The authors would like to thank Sam Weiler and Mark Andrews for their The authors would like to thank Sam Weiler and Mark Andrews for their
input and constructive comments. input and constructive comments.
5. References 7. References
5.1. Normative References 7.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005. RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005. Extensions", RFC 4035, March 2005.
5.2. Informative References 7.2. Informative References
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction [RFC1535] Gavron, E., "A Security Problem and Proposed Correction
With Widely Deployed DNS Software", RFC 1535, With Widely Deployed DNS Software", RFC 1535,
October 1993. October 1993.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
Authors' Addresses Authors' Addresses
Roy Arends Roy Arends
Telematica Instituut Nominet UK
Brouwerijstraat 1
Enschede 7523 XC
The Netherlands
Phone: +31 53 4850485 Email: roy@nominet.org.uk
Email: roy.arends@telin.nl
Peter Koch Peter Koch
DENIC eG DENIC eG
Wiesenhuettenplatz 26 Wiesenhuettenplatz 26
Frankfurt 60329 Frankfurt 60329
Germany Germany
Phone: +49 69 27235 0 Phone: +49 69 27235 0
Email: pk@DENIC.DE Email: pk@DENIC.DE
Jakob Schlyter Jakob Schlyter
NIC-SE Kirei AB
Box 5774 P.O. Box 53204
Stockholm SE-114 87 Goteborg SE-400 16
Sweden Sweden
Email: jakob@nic.se Email: jakob@kirei.se
URI: http://www.nic.se/ URI: http://www.kirei.se/
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 16, line 41 skipping to change at page 16, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 31 change blocks. 
58 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/