draft-ietf-mboned-msdp-deploy-05.txt   draft-ietf-mboned-msdp-deploy-06.txt 
INTERNET-DRAFT M. McBride INTERNET-DRAFT M. McBride
draft-ietf-msdp-deploy-05.txt J. Meylor J. Meylor
D. Meyer D. Meyer
Category Best Current Practice Category Best Current Practice
Expires: July 2004 January 2004 Expires: September 2004 March 2004
Multicast Source Discovery Protocol (MSDP) Deployment Scenarios Multicast Source Discovery Protocol (MSDP) Deployment Scenarios
<draft-ietf-mboned-msdp-deploy-05.txt> <draft-ietf-mboned-msdp-deploy-06.txt>
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes best current practices for intra-domain and
inter-domain deployment of the Multicast Source Discovery Protocol
(MSDP) in conjunction with Protocol Independent Multicast Sparse Mode
(PIM-SM).
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 33 skipping to change at page 1, line 33
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.
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 [RFC 2119].
This document is a product of the MBONED Working Group. Comments This document is a product of the MBONED Working Group. Comments
should be addressed to the authors, or the mailing list at should be addressed to the authors, or the mailing list at
mboned@lists.uoregon.edu. mboned@lists.uoregon.edu.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes best current practices for intra-domain and
inter-domain deployment of the Multicast Source Discovery Protocol
(MSDP) in conjunction with Protocol Independent Multicast Sparse Mode
(PIM-SM).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Inter-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 5 1.1. BCP, Experimental Protocols and Normative References. . . . 5
2.1. Peering between PIM Border Routers. . . . . . . . . . . . . 5 2. Inter-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 6
2.2. Peering between Non-Border Routers. . . . . . . . . . . . . 6 2.1. Peering between PIM Border Routers. . . . . . . . . . . . . 7
2.3. MSDP Peering without BGP. . . . . . . . . . . . . . . . . . 8 2.2. Peering between Non-Border Routers. . . . . . . . . . . . . 8
2.4. MSDP Peering at a Multicast Exchange. . . . . . . . . . . . 8 2.3. MSDP Peering without BGP. . . . . . . . . . . . . . . . . . 9
3. Intra-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 9 2.4. MSDP Peering at a Multicast Exchange. . . . . . . . . . . . 10
3.1. Peering between MSDP and MBGP Configured Routers. . . . . . 9 3. Intra-domain MSDP Peering Scenarios. . . . . . . . . . . . . . 10
3.2. MSDP Peer is not BGP Peer (or no BGP Peer). . . . . . . . . 10 3.1. Peering between MSDP and MBGP Configured Routers. . . . . . 10
3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 11 3.2. MSDP Peer is not BGP Peer (or no BGP Peer). . . . . . . . . 11
3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 11 3.3. Hierarchical Mesh Groups. . . . . . . . . . . . . . . . . . 12
3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 12 3.4. MSDP and Route Reflectors . . . . . . . . . . . . . . . . . 13
4. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 13 3.5. MSDP and Anycast RPs. . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 14
5.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 14 4.1. Filtering SA messages . . . . . . . . . . . . . . . . . . . 15
5.2. SA message state limits . . . . . . . . . . . . . . . . . . 14 4.2. SA message state limits . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 15 6. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References. . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References. . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References. . . . . . . . . . . . . . . . . . . 17 7.2. Informative References. . . . . . . . . . . . . . . . . . . 18
9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 17 8. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 18
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 17 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 18
10. Intellectual Property . . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
MSDP [RFC3618] is used primarily in two deployment scenarios: MSDP [RFC3618] is used primarily in two deployment scenarios:
o Between PIM Domains o Between PIM Domains
MSDP can be used between Protocol Independent Multicast Sparse MSDP can be used between Protocol Independent Multicast Sparse
Mode (PIM-SM) [RFC2362] domains to convey information Mode (PIM-SM) [PIM-SM] domains to convey information
about active sources available in other domains. MSDP peering about active sources available in other domains. MSDP peering
used in such cases is generally one to one peering, and used in such cases is generally one to one peering, and
utilizes the deterministic peer-RPF (Reverse Path Forwarding) utilizes the deterministic peer-RPF (Reverse Path Forwarding)
rules described in the MSDP specification (i.e., does not use rules described in the MSDP specification (i.e., does not use
mesh-groups). Peerings can be aggregated on a single MSDP mesh-groups). Peerings can be aggregated on a single MSDP
peer. Such a peer can typically have from one to hundreds of peer. Such a peer can typically have from one to hundreds of
peerings, which is similar in scale to BGP peerings. peerings, which is similar in scale to BGP peerings.
o Within a PIM Domain o Within a PIM Domain
skipping to change at page 4, line 41 skipping to change at page 4, line 41
one-to-one peering with MSDP peers outside that PIM domain for one-to-one peering with MSDP peers outside that PIM domain for
discovery of external sources. MSDP for anycast-RP without discovery of external sources. MSDP for anycast-RP without
external MSDP peering is a valid deployment option and common. external MSDP peering is a valid deployment option and common.
Current best practice for MSDP deployment utilizes PIM-SM and the Current best practice for MSDP deployment utilizes PIM-SM and the
Border Gateway Protocol with multi-protocol extensions (MBGP) Border Gateway Protocol with multi-protocol extensions (MBGP)
[RFC1771, RFC2858]. This document outlines how these protocols work [RFC1771, RFC2858]. This document outlines how these protocols work
together to provide an intra-domain and inter-domain Any Source together to provide an intra-domain and inter-domain Any Source
Multicast (ASM) service. Multicast (ASM) service.
Multicast (ASM) service. The PIM-SM specification assumes that SM The PIM-SM specification assumes that SM operates only in one PIM
operates only in one PIM domain. MSDP is used to enable the use of domain. MSDP is used to enable the use of multiple PIM domains by
multiple PIM domains by distributing the required information about distributing the required information about active multicast sources
active multicast sources to other PIM domains. Due to breaking the to other PIM domains. Due to breaking the Internet multicast
Internet multicast infrastructure down to multiple PIM domains, MSDP infrastructure down to multiple PIM domains, MSDP also enables the
also enables the possibility to set policy on the visibility of the possibility to set policy on the visibility of the groups and
groups and sources. sources.
Transit IP providers typically deploy MSDP to be part of the global Transit IP providers typically deploy MSDP to be part of the global
multicast infrastructure by connecting to their upstream and peer multicast infrastructure by connecting to their upstream and peer
multicast networks using MSDP. multicast networks using MSDP.
Edge multicast networks typically have two choices: to use their Edge multicast networks typically have two choices: to use their
Internet providers RP, or to have their own RP and connect it to Internet providers RP, or to have their own RP and connect it to
their ISP using MSDP. By deploying their own RP and MSDP, one can their ISP using MSDP. By deploying their own RP and MSDP, one can
use internal multicast groups which are not visible to the provider's use internal multicast groups which are not visible to the provider's
RP. This helps with internal multicast being able to continue to work RP. This helps with internal multicast being able to continue to work
in the event there is a problem with connectivity to the provider or in the event there is a problem with connectivity to the provider or
the provider's RP/MSDP is experiencing difficulties. In the simplest the provider's RP/MSDP is experiencing difficulties. In the simplest
cases where no internal multicast groups are necessary, there is cases where no internal multicast groups are necessary, there is
often no need to deploy MSDP. often no need to deploy MSDP.
1.1. BCP, Experimental Protocols and Normative References
This document describes the best current practice for a widely
deployed Experimental protocol, MSDP. There is no plan to advance the
MSDP's status (for example, to Proposed Standard). The reasons for
this include:
o MSDP was originally envisioned as a temporary protocol to be
supplanted by whatever the IDMR working group produced as an
inter-domain protocol. However, the IDMR WG (or subsequently,
the BGMP WG) never produced a protocol that could be deployed
to replace MSDP.
o One of the primary reasons given for MSDP to be classified as
Experimental was that the MSDP Working Group came up with
modifications to the protocol that the WG thought made it
better but that implementors didn't see any reasons to
deploy. Without these modifications (e.g., UDP or GRE
encapsulation), MSDP can have negative consequences to initial
packets in datagram streams.
o Scalability: Although we don't know what the hard limits might
be, readvertising everything you know every 60 seconds clearly
limits the amount of state you can advertise.
o MSDP reached near ubiquitous deployment as the de-facto
standard inter-domain multicast protocol in the IPv4 Internet.
o No consensus could be reached regarding the reworking of MSDP
to address the many concerns of various constituencies within
the IETF. As a result, a decision was taken to document what is
(ubiquitously) deployed and move that document to Experimental.
While advancement of MSDP to Proposed Standard was considered,
for the reasons mentioned above, it was immediately discarded.
o The advent of protocols such as source specific multicast and
bi-directional PIM, as well as embedded RP techniques for
IPv6, have further reduced consensus that a replacement
protocol for MSDP for the IPv4 Internet is required.
The RFC Editor's policy regarding references is that they be split
into two categories known as "normative" and "informative". Normative
references specify those documents which must be read to understand
or implement the technology in an RFC (or whose technology must be
present for the technology in the new RFC to work) [RFCED]. In order
to understand this document, one must also understand both the PIM
and MSDP documents. As a result, references to these documents are
normative.
The IETF has adopted the policy that BCPs must not have normative
references to Experimental protocols. However, this document is a
special case in that the underlying Experimental document (MSDP) is
not planned to be advanced to Proposed Standard.
The MBONED Working Group requests approval under the Variance
Procedure as documented in RFC 2026 [RFC2026].
Note to RFC-Editor: If IETF/IESG approves this, please change the
above sentence into: The MBONED Working Group has requested approval
under the Variance Procedure as documented in RFC 2026 [RFC2026].
The IESG followed the Variance Procedure, and after an additional 4
week IETF Last Call evaluated the comments and status and has
approved this document.
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 [RFC 2119].
2. Inter-domain MSDP Peering Scenarios 2. Inter-domain MSDP Peering Scenarios
The following sections describe the most common inter-domain MSDP The following sections describe the most common inter-domain MSDP
peering possibilities and their deployment options. peering possibilities and their deployment options.
2.1. Peering between PIM Border Routers 2.1. Peering between PIM Border Routers
In this case, the MSDP peers within the domain have their own RP In this case, the MSDP peers within the domain have their own RP
located within a bounded PIM domain. In addition, the domain will located within a bounded PIM domain. In addition, the domain will
typically have its own Autonomous System (AS) number and one or more typically have its own Autonomous System (AS) number and one or more
skipping to change at page 13, line 18 skipping to change at page 14, line 38
address either through Auto-RP, BSR, or a static RP assignment. Each address either through Auto-RP, BSR, or a static RP assignment. Each
designated router in the domain will send source registers and group designated router in the domain will send source registers and group
joins to the Anycast RP address. Unicast routing will direct those joins to the Anycast RP address. Unicast routing will direct those
registers and joins to the nearest Anycast RP. If a particular registers and joins to the nearest Anycast RP. If a particular
Anycast RP router fails, unicast routing will direct subsequent Anycast RP router fails, unicast routing will direct subsequent
registers and joins to the nearest Anycast RP. That RP will then registers and joins to the nearest Anycast RP. That RP will then
forward an MSDP update to all peers within the Anycast MSDP mesh forward an MSDP update to all peers within the Anycast MSDP mesh
group. Each RP will then forward (or receive) the SAs to (from) group. Each RP will then forward (or receive) the SAs to (from)
external customers and providers. external customers and providers.
4. Intellectual Property 4. Security Considerations
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
5. Security Considerations
An MSDP service should be secured by explicitly controlling the state An MSDP service should be secured by explicitly controlling the state
which is created by, and passed within, the MSDP service. As with which is created by, and passed within, the MSDP service. As with
unicast routing state, MSDP state should be controlled locally, at unicast routing state, MSDP state should be controlled locally, at
the edge origination points. Selective filtering at the multicast the edge origination points. Selective filtering at the multicast
service edge helps ensure that only intended sources result in SA service edge helps ensure that only intended sources result in SA
message creation, and this control helps to reduce the likelihood of message creation, and this control helps to reduce the likelihood of
state-aggregation related problems in the core. There are a variety state-aggregation related problems in the core. There are a variety
of points where local policy should be applied to the MSDP service. of points where local policy should be applied to the MSDP service.
5.1. Filtering SA messages 4.1. Filtering SA messages
The process of originating SA messages should be filtered to ensure The process of originating SA messages should be filtered to ensure
only intended local sources are resulting in SA message origination. only intended local sources are resulting in SA message origination.
In addition, MSDP speakers should filter on which SA messages get In addition, MSDP speakers should filter on which SA messages get
received and forwarded. received and forwarded.
Typically there is a fair amount of (S,G) state in a PIM-SM domain Typically there is a fair amount of (S,G) state in a PIM-SM domain
that is local to the domain. However, without proper filtering, sa- that is local to the domain. However, without proper filtering, sa-
messages containing these local (S,G) announcements may be advertised messages containing these local (S,G) announcements may be advertised
to the global MSDP infrastructure. Examples of this includes domain to the global MSDP infrastructure. Examples of this includes domain
local applications that use global IP multicast addresses and sources local applications that use global IP multicast addresses and sources
that use RFC 1918 addresses [RFC1918]. To improve on the scalability that use RFC 1918 addresses [RFC1918]. To improve on the scalability
of MSDP and to avoid global visibility of domain local (S,G) of MSDP and to avoid global visibility of domain local (S,G)
information, an external SA filter list is recommended to help information, an external SA filter list is recommended to help
prevent unnecessary creation, forwarding, and caching of well-known prevent unnecessary creation, forwarding, and caching of well-known
domain local sources. domain local sources.
5.2. SA message state limits 4.2. SA message state limits
Proper filtering on SA message origination, receipt, and forwarding Proper filtering on SA message origination, receipt, and forwarding
will significantly reduce the likelihood of unintended and unexpected will significantly reduce the likelihood of unintended and unexpected
spikes in MSDP state However, a sa-cache state limit SHOULD BE spikes in MSDP state However, a sa-cache state limit SHOULD be
configured as a final safeguard to state spikes. When an MSDP peering configured as a final safeguard to state spikes. When an MSDP peering
has reached a stable state (i.e., when the peering has been has reached a stable state (i.e., when the peering has been
established and the initial SA state has been transferred), it may established and the initial SA state has been transferred), it may
also be desirable to configure a rate limiter for the creation of new also be desirable to configure a rate limiter for the creation of new
SA state entries. SA state entries.
6. IANA Considerations 5. IANA Considerations
This document creates a no new requirements on IANA namespaces This document creates no new requirements on IANA namespaces
[RFC2434]. [RFC2434].
7. Acknowledgments 6. Acknowledgments
The authors would like to thank Pekka Savola, John Zwiebel, Swapna The authors would like to thank Pekka Savola, John Zwiebel, Swapna
Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier Yelamanchi, Greg Shepherd, and Jay Ford for their feedback on earlier
versions of this document. versions of this document.
8. References 7. References
8.1. Normative References 7.1. Normative References
[PIM-SM] Fenner, B., et. al, "Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol Specification
(Revised)", draft-ietf-pim-sm-v2-new-09.txt. Work
in progress.
[RFC1771] Rekhter, Y., and T. Li, "A Border Gateway [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway
Protocol 4 (BGP-4)", RFC 1771, March 1995. Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de [RFC1918] Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de
Groot, E. Lear, "Address Allocation for Private Groot, E. Lear, "Address Allocation for Private
Internets", RFC 1918, Feburary, 1996. Internets", RFC 1918, Feburary, 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels" RFC 2119/BCP 14, Indicate Requirement Levels" RFC 2119/BCP 14,
March 1997. March 1997.
[RFC2362] D. Estrin, et. al., "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol
Specification", RFC 2362, June, 1998.
[RFC2365] Meyer, D. "Administratively Scoped IP Multicast", [RFC2365] Meyer, D. "Administratively Scoped IP Multicast",
RFC 2365, July, 1998. RFC 2365, July, 1998.
[RFC2434] Narten, T., and H. Alvestrand, "Guidelines for [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in Writing an IANA Considerations Section in
RFCs", RFC 2434/BCP 0026, October, 1998. RFCs", RFC 2434/BCP 0026, October, 1998.
[RFC2858] Bates T., Y. Rekhter, R. Chandra, D. Katz, [RFC2858] Bates T., Y. Rekhter, R. Chandra, D. Katz,
"Multiprotocol Extensions for BGP-4", RFC 2858, "Multiprotocol Extensions for BGP-4", RFC 2858,
June 2000. June 2000.
skipping to change at page 17, line 5 skipping to change at page 18, line 5
[RFC3446] Kim, D., et. al., "Anycast Rendezvous Point (RP) [RFC3446] Kim, D., et. al., "Anycast Rendezvous Point (RP)
Mechanism using Protocol Independent Multicast Mechanism using Protocol Independent Multicast
(PIM) and Multicast Source Discovery Protocol (PIM) and Multicast Source Discovery Protocol
(MSDP)", RFC 3446, January, 2003. (MSDP)", RFC 3446, January, 2003.
[RFC3618] Meyer, D. and W. Fenner (Editors), "The Multicast [RFC3618] Meyer, D. and W. Fenner (Editors), "The Multicast
Source Discovery Protocol (MSDP)", RFC 3618, Source Discovery Protocol (MSDP)", RFC 3618,
October, 2003. October, 2003.
8.2. Informative References 7.2. Informative References
[AUTORP] Fenner, W., et. al., " Protocol Independent [AUTORP] Fenner, W., et. al., " Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", draft-ietf-pim-sm-v2-new-08.txt, Specification (Revised)", draft-ietf-pim-sm-v2-new-08.txt,
April, 2004. Work in progress. April, 2004. Work in progress.
[BSR] Fenner, W., et. al., "Bootstrap Router (BSR) [BSR] Fenner, W., et. al., "Bootstrap Router (BSR)
Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt, Mechanism for PIM Sparse Mode", draft-ietf-pim-sm-bsr-03.txt,
February, 2003. Work in progress. February, 2003. Work in progress.
[IANA] http://www.iana.org [IANA] http://www.iana.org
9. Author's Addresses [RFCED] http://www.rfc-editor.org/policy.html#policy.refs
8. Author's Addresses
Mike McBride Mike McBride
Cisco Systems Cisco Systems
Email: mcbride@cisco.com Email: mcbride@cisco.com
John Meylor John Meylor
Cisco Systems Cisco Systems
Email: jmeylor@cisco.com Email: jmeylor@cisco.com
David Meyer David Meyer
Email: dmm@1-4-5.net Email: dmm@1-4-5.net
10. Full Copyright Statement 9. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). 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 translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at line 642 skipping to change at page 19, line 20
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
10. 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.
11. Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/