draft-ietf-v6ops-routing-guidelines-00.txt | draft-ietf-v6ops-routing-guidelines-01.txt | |||
---|---|---|---|---|
Network Working Group M. Blanchet | Network Working Group M. Blanchet | |||
Internet-Draft Viagenie | Internet-Draft Viagenie | |||
Intended status: Standards Track February 26, 2007 | ||||
Expires: August 30, 2007 | ||||
IPv6 Routing Policies Guidelines | IPv6 Routing Policies Guidelines | |||
draft-ietf-v6ops-routing-guidelines-00.txt | draft-ietf-v6ops-routing-guidelines-01.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 31 | skipping to change at page 1, line 34 | |||
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 September 2, 2006. | This Internet-Draft will expire on August 30, 2007. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2006). | Copyright (C) The IETF Trust (2007). | |||
Abstract | Abstract | |||
Guidelines on how to manage IPv6 routes are needed for operators of | Guidelines on how to manage and filter IPv6 routes are needed for | |||
networks, either providers or enterprises. This document is a | operators of networks, either providers or enterprises. It describes | |||
followup on RFC2772 work but for the production IPv6 Internet. | IPv6 routes from the protocol point of view. It does not discuss | |||
RFC2772 becomes historic. | operational or policy issues such as the maximum length of prefixes | |||
to filter. This document is a followup on RFC2772 work but for the | ||||
production IPv6 Internet. RFC2772 is obsoleted. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Address Types . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Address Types . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.1. Node-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 | 2.1. Node-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 | |||
2.2. IPv4-Mapped Addresses . . . . . . . . . . . . . . . . . . . 3 | 2.2. IPv4-Mapped Addresses . . . . . . . . . . . . . . . . . . . 3 | |||
2.3. Link-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 | 2.3. Link-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 | |||
2.4. Site-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 | 2.4. Site-scoped Unicast . . . . . . . . . . . . . . . . . . . . 3 | |||
2.5. Global Unicast . . . . . . . . . . . . . . . . . . . . . . 3 | 2.5. Global Unicast . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2.5.1. Documentation Prefix . . . . . . . . . . . . . . . . . 4 | 2.5.1. Documentation Prefix . . . . . . . . . . . . . . . . . 4 | |||
2.5.2. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.5.2. 6to4 . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.5.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.5.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.5.4. 6bone . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.5.4. 6bone . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.6. Default Route . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.6. Default Route . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 2.7. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
2.8. Unknown addresses . . . . . . . . . . . . . . . . . . . . . 5 | 2.8. Unknown addresses . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Implementing routing policies . . . . . . . . . . . . . . . . . 5 | 3. Implementing routing policies . . . . . . . . . . . . . . . . . 5 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 | 4. RPSL Implementation . . . . . . . . . . . . . . . . . . . . . . 5 | |||
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 | |||
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
6.2. Informative References . . . . . . . . . . . . . . . . . . 6 | 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 | |||
7.2. Informative References . . . . . . . . . . . . . . . . . . 7 | ||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
Intellectual Property and Copyright Statements . . . . . . . . . . 8 | Intellectual Property and Copyright Statements . . . . . . . . . . 8 | |||
1. Introduction | 1. Introduction | |||
To maintain stability, efficiency and scalability of the IPv6 | To maintain stability, efficiency and scalability of the IPv6 | |||
Internet, guidelines for routing policies are needed for operators | Internet, guidelines for routing policies are needed for operators | |||
deploying IPv6 networks. Prior experience on IPv6 routing guidelines | deploying IPv6 networks. Prior experience on IPv6 routing guidelines | |||
on the 6bone[RFC2772], practical deployment of the IPv6 internet and | on the 6bone[RFC2772], practical deployment of the IPv6 internet and | |||
IPv6 specifications were used as input to this document. | IPv6 specifications were used as input to this document. | |||
skipping to change at page 3, line 29 | skipping to change at page 3, line 29 | |||
2. Address Types | 2. Address Types | |||
2.1. Node-scoped Unicast | 2.1. Node-scoped Unicast | |||
The node-scoped unicast addresses[RFC4291] such as the loopback | The node-scoped unicast addresses[RFC4291] such as the loopback | |||
(::1/128), the unspecified (::/128) must not be advertised in an IGP | (::1/128), the unspecified (::/128) must not be advertised in an IGP | |||
or EGP and should be filtered out when received. | or EGP and should be filtered out when received. | |||
2.2. IPv4-Mapped Addresses | 2.2. IPv4-Mapped Addresses | |||
IPv4-mapped addresses (::FFFF:0:0/96)[RFC4291] must not be advertised | IPv4-mapped addresses (::FFFF:0:0/96) [RFC4291] must not be | |||
and should be filtered out. | advertised and should be filtered out. | |||
2.3. Link-scoped Unicast | 2.3. Link-scoped Unicast | |||
The link-scoped unicast[RFC4291] routes (fe80::/10) must not be | The link-scoped unicast[RFC4291] routes (fe80::/10) must not be | |||
advertised in an IGP or EGP and should be filtered out when received. | advertised in an IGP or EGP and should be filtered out when received. | |||
2.4. Site-scoped Unicast | 2.4. Site-scoped Unicast | |||
The site-scoped unicast routes, known as Unique-local[RFC4193], | The site-scoped unicast routes, known as Unique-local[RFC4193], | |||
(fc00::/7) may be advertised in an IGP. It must not be advertised in | (fc00::/7) may be advertised in an IGP. It must not be advertised in | |||
an EGP connected to the global Internet and should be filtered out | an EGP connected to the global Internet and should be filtered out | |||
when received. However, it may be advertised in an EGP between two | when received. However, it may be advertised in an EGP between two | |||
networks sharing a private interconnect, but must not be advertised | networks sharing a private interconnect, but must not be advertised | |||
outside the scope of these networks. When advertised in an EGP, | outside the scope of these networks. When advertised in an EGP, | |||
these routes should be of length /48. | these routes should be of length /48 or smaller. | |||
2.5. Global Unicast | 2.5. Global Unicast | |||
The global unicast routes (2000::/3)[RFC4291] may be advertised in an | The global unicast routes (2000::/3) [RFC4291] may be advertised in | |||
IGP or EGP. A minimal EGP routing policy should filter out routes | an IGP or EGP. | |||
that exceed a maximum length. Determining the maximum length of a | ||||
global Internet route is outside the scope of this document. | A minimal EGP routing policy should filter out routes that exceed a | |||
maximum length. Determining the maximum length of a global Internet | ||||
route is outside the scope of this document. | ||||
A finer EGP routing policy may use only the allocated address space | A finer EGP routing policy may use only the allocated address space | |||
from IANA to registry as specified in | from IANA to registries as specified in | |||
http://www.iana.org/assignments/ipv6-unicast-address-assignments. | http://www.iana.org/assignments/ipv6-unicast-address-assignments. | |||
This would result in better filtering since the non-allocated | This would result in better filtering since the non-allocated | |||
prefixes will be filtered out. | prefixes will be filtered out. | |||
An even finer EGP routing policy may use only the assigned address | An even finer EGP routing policy may use only the assigned address | |||
space from registries to providers as available in the registry | space from registries to providers as available in the registries | |||
databases. This would result in the best filtering since the non- | databases. This would result in the best filtering since the non- | |||
assigned prefixes will be filtered out. However, this requires the | assigned prefixes will be filtered out. However, this requires the | |||
synchronization of the filters with the registry databases. | synchronization of the filters with the registries databases. | |||
2.5.1. Documentation Prefix | 2.5.1. Documentation Prefix | |||
The 2001:0db8::/32 prefix[RFC3849] is used for documentation purposes | The 2001:0db8::/32 prefix[RFC3849] is used for documentation purposes | |||
and must not be advertised in an IGP or EGP and should be filtered | and must not be advertised in an IGP or EGP and should be filtered | |||
out when received. | out when received. | |||
2.5.2. 6to4 | 2.5.2. 6to4 | |||
The 6to4[RFC4291] prefix (2002::/16) may be advertised in an IGP or | The 6to4[RFC4291][RFC3056] prefix (2002::/16) may be advertised in an | |||
EGP, when the site is running a 6to4 relay or offering a 6to4 transit | IGP or EGP, when the site is running a 6to4 relay or offering a 6to4 | |||
service. However, the provider of this service should be aware of | transit service. However, the provider of this service should be | |||
the implications of running such service[RFC3964], which includes | aware of the implications of running such service[RFC3964], which | |||
some specific filtering rules for 6to4. | includes some specific filtering rules for 6to4. | |||
2.5.3. Teredo | 2.5.3. Teredo | |||
The Teredo[RFC4380] prefix (2001::/32) may be advertised in an IGP or | The Teredo[RFC4380] prefix (2001::/32) may be advertised in an IGP or | |||
EGP, when the site is running a Teredo relay or offering a Teredo | EGP, when the site is running a Teredo relay or offering a Teredo | |||
transit service. | transit service. | |||
2.5.4. 6bone | 2.5.4. 6bone | |||
The 6bone experimental network used some experimental allocations, | The 6bone experimental network used some experimental allocations, | |||
such as 5f00::/8[RFC1897] and 3ffe::/16[RFC2471] that were later | such as 5f00::/8[RFC1897] and 3ffe::/16[RFC2471] that were later | |||
returned to IANA[RFC3701]. These prefixes should not be advertised | returned to IANA[RFC3701]. These prefixes should not be advertised | |||
in an EGP unless IANA reallocates them subsequently. | in an EGP unless IANA reallocates them subsequently. | |||
2.6. Default Route | 2.6. Default Route | |||
The default unicast route (::) may be advertised in an IGP. In an | The default unicast route (::) may be advertised in an IGP. It must | |||
EGP, it may be only advertised to the downstream but must not be | not be advertised in an EGP unless it has been requested by the | |||
advertised in the core. | recipient. | |||
2.7. Multicast | 2.7. Multicast | |||
Multicast addresses (ff00::/8)[RFC4291] have a scope in the address | Multicast addresses (ff00::/8) [RFC4291] have a 4 bits scope in the | |||
field. In the multicast routing, the routes should be announced | address field. Only addresses having the 'E' value in the scope | |||
according to the scope, similar to unicast routes. Multicast routes | field are of global scope, all other values are local or reserved. | |||
must not appear in unicast routing tables. | Therefore, only ffXe:: routes may be advertised outside an | |||
organisation network, where X may be any value. | ||||
Multicast routes must not appear in unicast routing tables. | ||||
2.8. Unknown addresses | 2.8. Unknown addresses | |||
Any non listed address above must not be advertised and should be | Any non listed address above must not be advertised and should be | |||
filtered out. Future work might reserve additional address space for | filtered out. Future work might reserve additional address space for | |||
protocol use which might require specific routing guidelines. The | protocol use which might require specific routing guidelines. The | |||
reader should refer to newer versions of the normative references in | reader should refer to newer versions of the normative references in | |||
this document to verify the existence of newer protocol address | this document to verify the existence of newer protocol address | |||
space. | space. | |||
3. Implementing routing policies | 3. Implementing routing policies | |||
This document focuses on protocol addresses and their use in the | This document focuses on protocol addresses and their use in the | |||
networks. It does not discuss any allocation policies and their | networks. It does not discuss any allocation policies and their | |||
impact on the routing policies, such as /48 Micro-allocations for | impact on the routing policies, such as /48 Micro-allocations for | |||
infrastructure providers or maximum length of a unicast prefix. As | infrastructure providers or maximum length of a unicast prefix. As | |||
such, to implement a complete routing policy, one should augment | such, to implement a complete routing policy, one should augment | |||
these guidelines with the current registry allocation policies and by | these guidelines with the current registry allocation policies and by | |||
appropriate ingress filtering techniques[RFC3704]. | appropriate ingress filtering techniques[RFC3704]. | |||
4. RPSL Implementation | ||||
The Route Policy Specification Language(RPSL)[RFC4012] used in route | The Route Policy Specification Language(RPSL)[RFC4012] used in route | |||
registries supports the policies described in this document and | registries supports the policies described in this document and | |||
should be considered to manage route policies. | should be considered to manage route policies. | |||
The following RPSL code implements the policies described in this | The following RPSL code implements the policies described in this | |||
document. This code should be considered as an example and should be | document. This code should be considered as an example and should be | |||
adapted to its target usage. | adapted to the target usage. | |||
TBD: RPSL code to fill | route-set: rs-exclude | |||
mp-members: ::1/128, ::/128, ::ffff:0:0/96^+, fe80::/10^+, | ||||
2001:0db8::/32^+ | ||||
4. Security Considerations | route-set: rs-ula | |||
mp-members: fc00::/7^+ | ||||
This document list guidelines to improve the security of networks by | route-set: rs-global-unicast | |||
filtering of routing prefixes. | mp-members: 2000::/3^+ | |||
5. Acknowledgements | route-set: rs-6to4 | |||
mp-members: 2002::/16^+ | ||||
route-set: rs-teredo | ||||
mp-members: 2001::/32^+ | ||||
filter-set: fltr-v6egp | ||||
mp-filter: NOT (rs-exclude AND rs-ula) AND rs-global-unicast | ||||
filter-set: fltr-v6igp | ||||
mp-filter: NOT rs-exclude AND rs-global-unicast | ||||
5. Security Considerations | ||||
This document list guidelines that should improve the security of | ||||
networks by the filtering of invalid routing prefixes. | ||||
6. Acknowledgements | ||||
Florent Parent, Pekka Savola, Tim Chown, Alain Baudot, Stig Venaas, | Florent Parent, Pekka Savola, Tim Chown, Alain Baudot, Stig Venaas, | |||
Vincent Jardin, Olaf Bonness, David Green, Gunter Van de Velde, | Vincent Jardin, Olaf Bonness, David Green, Gunter Van de Velde, | |||
Michael Barnes and Fred Baker have provided input and suggestions to | Michael Barnes, Fred Baker, Edward Lewis, Marla Azinger, Brian | |||
this document. | Carpenter, Mark Smith and Kevin Loch have provided input and | |||
suggestions to this document. | ||||
6. References | 7. References | |||
6.1. Normative References | 7.1. Normative References | |||
[RFC1897] Hinden, R. and J. Postel, "IPv6 Testing Address | [RFC1897] Hinden, R. and J. Postel, "IPv6 Testing Address | |||
Allocation", RFC 1897, January 1996. | Allocation", RFC 1897, January 1996. | |||
[RFC2471] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address | [RFC2471] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address | |||
Allocation", RFC 2471, December 1998. | Allocation", RFC 2471, December 1998. | |||
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains | ||||
via IPv4 Clouds", RFC 3056, February 2001. | ||||
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix | [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix | |||
Reserved for Documentation", RFC 3849, July 2004. | Reserved for Documentation", RFC 3849, July 2004. | |||
[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, | [RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky, | |||
"Routing Policy Specification Language next generation | "Routing Policy Specification Language next generation | |||
(RPSLng)", RFC 4012, March 2005. | (RPSLng)", RFC 4012, March 2005. | |||
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast | [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast | |||
Addresses", RFC 4193, October 2005. | Addresses", RFC 4193, October 2005. | |||
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing | [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing | |||
Architecture", RFC 4291, February 2006. | Architecture", RFC 4291, February 2006. | |||
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through | [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through | |||
Network Address Translations (NATs)", RFC 4380, | Network Address Translations (NATs)", RFC 4380, | |||
February 2006. | February 2006. | |||
6.2. Informative References | 7.2. Informative References | |||
[RFC2772] Rockell, R. and B. Fink, "6Bone Backbone Routing | [RFC2772] Rockell, R. and B. Fink, "6Bone Backbone Routing | |||
Guidelines", RFC 2772, February 2000. | Guidelines", RFC 2772, February 2000. | |||
[RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address | [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address | |||
Allocation) Phaseout", RFC 3701, March 2004. | Allocation) Phaseout", RFC 3701, March 2004. | |||
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed | [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed | |||
Networks", BCP 84, RFC 3704, March 2004. | Networks", BCP 84, RFC 3704, March 2004. | |||
[RFC3964] Savola, P. and C. Patel, "Security Considerations for | [RFC3964] Savola, P. and C. Patel, "Security Considerations for | |||
6to4", RFC 3964, December 2004. | 6to4", RFC 3964, December 2004. | |||
Author's Address | Author's Address | |||
Marc Blanchet | Marc Blanchet | |||
Viagenie | Viagenie | |||
Email: Marc.Blanchet@viagenie.ca | Email: Marc.Blanchet@viagenie.ca | |||
Intellectual Property Statement | Full Copyright Statement | |||
Copyright (C) The IETF Trust (2007). | ||||
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 | 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 | |||
found in BCP 78 and BCP 79. | found in BCP 78 and BCP 79. | |||
skipping to change at page 8, line 29 | skipping to change at page 8, line 45 | |||
such proprietary rights by implementers or users of this | such proprietary rights by implementers or users of this | |||
specification can be obtained from the IETF on-line IPR repository at | specification can be obtained from the IETF on-line IPR repository at | |||
http://www.ietf.org/ipr. | http://www.ietf.org/ipr. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
ietf-ipr@ietf.org. | 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 (2006). 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 | Acknowledgment | |||
Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is provided by the IETF | |||
Internet Society. | Administrative Support Activity (IASA). | |||
End of changes. 29 change blocks. | ||||
62 lines changed or deleted | 99 lines changed or added | |||
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |