draft-ietf-seamoby-ctp-10.txt   draft-ietf-seamoby-ctp-11.txt 
Seamoby WG J. Loughney (editor) Seamoby WG J. Loughney (editor)
Internet Draft M. Nakhjiri Internet Draft M. Nakhjiri
Category: Experimental C. Perkins Category: Experimental C. Perkins
<draft-ietf-seamoby-ctp-10.txt> R. Koodli <draft-ietf-seamoby-ctp-11.txt> R. Koodli
Expires: December 2004 June 2004 Expires: Feburary 2005 August 2004
Context Transfer Protocol Context Transfer Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026 [RFC2026]. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
skipping to change at page 17, line 33 skipping to change at page 18, line 33
CTP. In this specification, the use of such SCTP features is not CTP. In this specification, the use of such SCTP features is not
recommended at this time. recommended at this time.
The SCTP Payload Data Chunk carries the context transfer protocol The SCTP Payload Data Chunk carries the context transfer protocol
messages. The User Data part of each SCTP message contains an messages. The User Data part of each SCTP message contains an
appropriate context transfer protocol message defined in this appropriate context transfer protocol message defined in this
document. The messages sent using SCTP are CTD (Section 2.5.3), CTDR document. The messages sent using SCTP are CTD (Section 2.5.3), CTDR
(Section 2.5.4), CTC (Section 2.5.5) and CT-Req (Section 2.5.6). In (Section 2.5.4), CTC (Section 2.5.5) and CT-Req (Section 2.5.6). In
general, each SCTP message can carry feature contexts belonging to general, each SCTP message can carry feature contexts belonging to
any MN. If the SCTP checksum calculation fails, the nAR returns the any MN. If the SCTP checksum calculation fails, the nAR returns the
BAD_CHECKSUM error code in a CTDR message. BAD_CHECKSUM error code in a CTDR message.
A single stream is used for context transfer without in-sequence A single stream is used for context transfer without in-sequence
delivery of SCTP messages. Each message corresponds to a single MN's delivery of SCTP messages. Each message corresponds to a single MN's
feature context collection. A single stream provides simplicity. Use feature context collection. A single stream provides simplicity. Use
of multiple streams to prevent head-of-line blocking is for future of multiple streams to prevent head-of-line blocking is for future
study. Having unordered delivery allows the receiver to not block for study. Having unordered delivery allows the receiver to not block for
in-sequence delivery of messages that belong to different MNs. The in-sequence delivery of messages that belong to different MNs. The
Payload Protocol Identifier in the SCTP header is 'CTP'. Inter-router Payload Protocol Identifier in the SCTP header is 'CTP'. Inter-router
CTP uses the Seamoby SCTP port [IANA]. CTP uses the Seamoby SCTP port [IANA].
skipping to change at page 22, line 51 skipping to change at page 24, line 7
If the MNs are not authenticated and authorized before moving on the If the MNs are not authenticated and authorized before moving on the
network, there is a potential for masqurading attacks to shift state network, there is a potential for masqurading attacks to shift state
between ARs, causing network disruptions. between ARs, causing network disruptions.
Additionally, DoS attacks can be launched from MNs towards the access Additionally, DoS attacks can be launched from MNs towards the access
routers by requesting multiple context transfers and then routers by requesting multiple context transfers and then
disappearing. Finally, a rogue access router could flood mobile disappearing. Finally, a rogue access router could flood mobile
nodes with packets, attempting DoS attacks, and issue bogus context nodes with packets, attempting DoS attacks, and issue bogus context
transfer requests to surrounding routers. transfer requests to surrounding routers.
Consistency and correctness in context transfer depend on
interoperable feature context definitions and how CTP is utilized for
a particular application. For some considerations regarding
consistency and correctness that have general applicability but are
articulated in the context of AAA context transfer, please see [EAP].
6.2. Access Router Considerations 6.2. Access Router Considerations
The CTP inter-router interface relies on IETF standardized security The CTP inter-router interface relies on IETF standardized security
mechanisms for protecting traffic between access routers, as opposed mechanisms for protecting traffic between access routers, as opposed
to creating application security mechanisms. IPsec MUST be supported to creating application security mechanisms. IPsec MUST be supported
between access routers. between access routers.
In order to avoid the introduction of additional latency due to the In order to avoid the introduction of additional latency due to the
need for establishment of a secure channel between the context need for establishment of a secure channel between the context
transfer peers (ARs), the two ARs SHOULD establish such a secure transfer peers (ARs), the two ARs SHOULD establish such a secure
channel in advance. The two access routers need to engage in a key channel in advance. The two access routers need to engage in a key
exchange mechanisms such as IKE [RFC2409], establish IPSec SAs, exchange mechanisms such as IKE [RFC2409], establish IPSec SAs,
skipping to change at page 23, line 32 skipping to change at page 24, line 43
non-null encryption and authentication algorithms to provide per- non-null encryption and authentication algorithms to provide per-
packet authentication, integrity protection and confidentiality, and packet authentication, integrity protection and confidentiality, and
MUST implement the replay protection mechanisms of IPsec. In those MUST implement the replay protection mechanisms of IPsec. In those
scenarios where IP layer protection is needed, ESP in tunnel mode scenarios where IP layer protection is needed, ESP in tunnel mode
SHOULD be used. Non-null encryption should be used when using IPSec SHOULD be used. Non-null encryption should be used when using IPSec
ESP. Strong security on the inter-router interface is required to ESP. Strong security on the inter-router interface is required to
protect against attacks by rogue routers, and to ensure protect against attacks by rogue routers, and to ensure
confidentiality on the context transfer authorization key in confidentiality on the context transfer authorization key in
predicative transfer. predicative transfer.
The details of IKE key exchange and other details of the IPsec
security associations between routers are to be determined as part of
the research phase associated with finalizing the protocol for
standardization. Prior to standardization, these details must be
determined. Other working groups are currently working on general
security for routing protocols. Ideally, a solution for CTP will be
based on this work, if possible, in order to minimize operational
configuration of routers for different protocols. Requirements for
CTP will be brought to the appropriate IETF routing protocol security
working groups for consideration.
6.3 Mobile Node Considerations 6.3 Mobile Node Considerations
The CTAR message requires the MN and AR to possess a shared secret The CTAR message requires the MN and AR to possess a shared secret
key in order to calculate the authorization token. Validation of this key in order to calculate the authorization token. Validation of this
token MUST precede context transfer or installation of context for token MUST precede context transfer or installation of context for
the MN, removing the risk that an attacker could cause an the MN, removing the risk that an attacker could cause an
unauthorized transfer. How the shared key is established is out of unauthorized transfer. How the shared key is established is out of
scope of the current specification. If both the MN and AR know scope of the current specification. If both the MN and AR know
certified public keys of the other party, Diffie-Helman can be used certified public keys of the other party, Diffie-Helman can be used
to generate a shared secret [RFC2631]. If an AAA protocol of some to generate a shared secret [RFC2631]. If an AAA protocol of some
skipping to change at page 25, line 17 skipping to change at page 26, line 38
Motiwala, Phil Neumiller, Hesham Soliman and Lucian Suciu for their Motiwala, Phil Neumiller, Hesham Soliman and Lucian Suciu for their
help and suggestions with this document. help and suggestions with this document.
9. References 9. References
9.1 Normative References 9.1 Normative References
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require-
Levels", BCP 14, RFC 2119, March 1997. ment Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA Con- [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
siderations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)",
2409, November 1998. RFC 2409, November 1998.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Pay-
(ESP)", RFC 2406, November 1998. load (ESP)", RFC 2406, November 1998.
[SCTP] Stewert, R., et. al., "Stream Control Transmission Protocol", [SCTP] Stewert, R., et. al., "Stream Control Transmission Proto-
RFC 2960, October, 2000. col", RFC 2960, October, 2000.
[PR-SCTP] Stewert, R., et. al., "SCTP Partial Reliability Extension", [PR-SCTP] Stewert, R., et. al., "SCTP Partial Reliability Extension",
Internet Engineering Task Force. Work in Progress. Internet Engineering Task Force. Work in Progress.
[CARD] Liebisch, M., and Singh, A., editors, et. al., "Candidate [CARD] Liebisch, M., and Singh, A., editors, et. al., "Candidate
Access Router Discovery", Internet Engineering Task Force. Access Router Discovery", Internet Engineering Task Force.
Work in Progress. Work in Progress.
[IANA] Kempf, J., "Instructions for Seamoby Experimental Protocol [IANA] Kempf, J., "Instructions for Seamoby Experimental Protocol
IANA Allocations", Internet Engineering Task Force. Work in IANA Allocations", Internet Engineering Task Force. Work in
Progress. Progress.
9.2 Non-Normative References 9.2 Non-Normative References
[CTHC] R. Koodli et al., "Context Relocation for Seamless Header Com- [CTHC] R. Koodli et al., "Context Relocation for Seamless Header
pression in IP Networks", Internet Draft, Internet Engineering Compression in IP Networks", Internet Draft, Internet
Task Force, Work in Progress. Engineering Task Force, Work in Progress.
[FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet [FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet
Engineering Task Force. Work in Progress. Engineering Task Force. Work in Progress.
[LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4", [LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4",
Internet Engineering Task Force. Work in Progress. Internet Engineering Task Force. Work in Progress.
[RFC3374] J. Kempf et al., "Problem Description: Reasons For Performing [RFC3374] J. Kempf et al., "Problem Description: Reasons For Performing
Context Transfers Between Nodes in an IP Access Network", RFC Context Transfers Between Nodes in an IP Access Network", RFC
3374, May 2001. 3374, May 2001.
[RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998. Protocol", RFC 2401, November 1998.
[TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet [TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet
Engineering Task Force, Work in Progress. Engineering Task Force, Work in Progress.
[RFC2631] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC 2631, [RFC2631] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC 2631,
June, 1999. June, 1999.
[PerkCal04] [PerkCal04]C. Perkins and P. Calhoun, "AAA Registration Keys for Mobile
C. Perkins and P. Calhoun, "AAA Registration Keys for Mobile
IPv4", Internet Engineering Task Force, Work in Progress. IPv4", Internet Engineering Task Force, Work in Progress.
[MIPv6] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in [MIPv6] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in
IPv6", Internet Engineering Task Force, Work in Progress. IPv6", Internet Engineering Task Force, Work in Progress.
[RFC2710] S. Deering, W. Fenner, and B. Haberman, " Multicast Listener [RFC2710] S. Deering, W. Fenner, and B. Haberman, " Multicast Listener
Discovery (MLD) for IPv6," RFC 2710, October, 1999. Discovery (MLD) for IPv6," RFC 2710, October, 1999.
[RFC2461] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery [RFC2461] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)," RFC 2461, December, 1998. for IP Version 6 (IPv6)," RFC 2461, December, 1998.
skipping to change at page 27, line 17 skipping to change at page 28, line 33
[RFC3095] C. Borman, ed., "RObust Header Compression (ROHC)", RFC 3095, [RFC3095] C. Borman, ed., "RObust Header Compression (ROHC)", RFC 3095,
July, 2001. July, 2001.
[BT] IEEE, "IEEE Standard for information technology - Telecommuni- [BT] IEEE, "IEEE Standard for information technology - Telecommuni-
cation and information exchange between systems - LAN/MAN - cation and information exchange between systems - LAN/MAN -
Part 15.1: Wireless Medium Access Control (MAC) and Physical Part 15.1: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) specifications for Wireless Personal Area Networks Layer (PHY) specifications for Wireless Personal Area Networks
(WPANs)", IEEE Standard 802.15.1, 2002. (WPANs)", IEEE Standard 802.15.1, 2002.
[EAP] B. Aboba, D. Simon, J. Arkko, P. Eron, and H. Levokowetz,
"Extensible Authentication Protocol (EAP) Key Management
Framework", Internet Draft, work in progress.
Appendix A. Timing and Trigger Considerations Appendix A. Timing and Trigger Considerations
Basic Mobile IP handover signaling can introduce disruptions to the Basic Mobile IP handover signaling can introduce disruptions to the
services running on top of Mobile IP, which may introduce unwanted services running on top of Mobile IP, which may introduce unwanted
latencies that practically prohibit its use for certain types of ser- latencies that practically prohibit its use for certain types of
vices. Mobile IP latency and packet loss is being optimized through services. Mobile IP latency and packet loss is being optimized
several alternative procedures, such as Fast Mobile IP [FMIPv6] and through several alternative procedures, such as Fast Mobile IP
Low Latency Mobile IP [LLMIP]. [FMIPv6] and Low Latency Mobile IP [LLMIP].
Feature re-establishment through context transfer should contribute Feature re-establishment through context transfer should contribute
zero (optimally) or minimal extra disruption of services in conjunc- zero (optimally) or minimal extra disruption of services in conjunc-
tion to handovers. This means that the timing of context transfer tion to handovers. This means that the timing of context transfer
SHOULD be carefully aligned with basic Mobile IP handover events, and SHOULD be carefully aligned with basic Mobile IP handover events, and
with optimized Mobile IP handover signaling mechanisms, as those pro- with optimized Mobile IP handover signaling mechanisms, as those pro-
tocols become available. tocols become available.
Furthermore, some of those optimized mobile IP handover mechanisms Furthermore, some of those optimized mobile IP handover mechanisms
may provide more flexibility in choosing the timing and order for may provide more flexibility in choosing the timing and order for
skipping to change at page 28, line 17 skipping to change at page 29, line 46
example of how context transfer could result in a commercially example of how context transfer could result in a commercially
viable, widely deployable, interoperable benefit for wireless net- viable, widely deployable, interoperable benefit for wireless net-
works. This is one reason why CTP is being proposed as an Experimen- works. This is one reason why CTP is being proposed as an Experimen-
tal protocol, rather than Standards Track. However, it nevertheless tal protocol, rather than Standards Track. However, it nevertheless
seems valuable to have a simple example that shows how handover could seems valuable to have a simple example that shows how handover could
benefit from using CTP. The example we consider here is transferring benefit from using CTP. The example we consider here is transferring
IPv6 MLD state [RFC2710]. MLD state is a particularly good example IPv6 MLD state [RFC2710]. MLD state is a particularly good example
because every IPv6 node must perform at least one MLD messaging because every IPv6 node must perform at least one MLD messaging
sequence on the wireless link to establish itself as an MLD listener sequence on the wireless link to establish itself as an MLD listener
prior to performing router discovery [RFC2461] or duplicate address prior to performing router discovery [RFC2461] or duplicate address
detection [RFC2462] or before sending/receiving any application-spe- detection [RFC2462] or before sending/receiving any application-
cific traffic (including Mobile IP handover signaling, if any). The specific traffic (including Mobile IP handover signaling, if any).
node must subscribe to the Solicited Node Multicast Address as soon The node must subscribe to the Solicited Node Multicast Address as
as it comes up on the link. Any application-specific multicast soon as it comes up on the link. Any application-specific multicast
addresses must be re-established as well. Context transfer can sig- addresses must be re-established as well. Context transfer can signi-
nificantly speed up re-establishing multicast state by allowing the ficantly speed up re-establishing multicast state by allowing the nAR
nAR to initialize MLD for a node that just completed handover without to initialize MLD for a node that just completed handover without any
any MLD signaling on the new wireless link. The same approach could MLD signaling on the new wireless link. The same approach could be
be used for transferring multicast context in IPv4. used for transferring multicast context in IPv4.
An approximate quantitative estimate for the amount of savings in An approximate quantitative estimate for the amount of savings in
handover time can be obtained as follows. MLD messages are 24 octets, handover time can be obtained as follows. MLD messages are 24 octets,
to which the headers must be added, because there is no header com- to which the headers must be added, because there is no header
pression on the new link, with IPv6 header being 40 octets, and a compression on the new link, with IPv6 header being 40 octets, and a
required Router Alert Hop-by-Hop option being 8 octets including required Router Alert Hop-by-Hop option being 8 octets including pad-
padding. The total MLD message size is 72 octets per subscribed mul- ding. The total MLD message size is 72 octets per subscribed multi-
ticast address. RFC 2710 recommends that nodes send 2 to 3 MLD Report cast address. RFC 2710 recommends that nodes send 2 to 3 MLD Report
messages per address subscription, since the Report message is unac- messages per address subscription, since the Report message is unack-
knowledged. Assuming 2 MLD messages sent for a subscribed address, nowledged. Assuming 2 MLD messages sent for a subscribed address, the
the MN would need to send 144 octets per address subscription. If MLD MN would need to send 144 octets per address subscription. If MLD
messages are sent for both the All Nodes Multicast address and the messages are sent for both the All Nodes Multicast address and the
Solicited Node Multicast address for the node's link local address, a Solicited Node Multicast address for the node's link local address, a
total of 288 octets are required when the node hands over to the new total of 288 octets are required when the node hands over to the new
link. Note that some implementations of IPv6 optimize by not sending link. Note that some implementations of IPv6 optimize by not sending
an MLD message for the All Nodes Multicast Address, since the router an MLD message for the All Nodes Multicast Address, since the router
can infer that at least one node is on the link (itself) when it can infer that at least one node is on the link (itself) when it
comes up and always will be, but for purposes of this calculation, we comes up and always will be, but for purposes of this calculation, we
assume that the IPv6 implementation is conformant and that the mes- assume that the IPv6 implementation is conformant and that the mes-
sage is sent. The amount of time required for MLD signaling will, of sage is sent. The amount of time required for MLD signaling will, of
course, depend on the per node available wireless link bandwidth, but course, depend on the per node available wireless link bandwidth, but
some representative numbers can be obtained by assuming bandwidths of some representative numbers can be obtained by assuming bandwidths of
20 kbps or 100 kbps. With these two bit rates, the savings from not 20 kbps or 100 kbps. With these two bit rates, the savings from not
having to perform the pre-router discovery messages are 115 msec. and having to perform the pre-router discovery messages are 115 msec. and
23 msec., respectively. If any application-specific multicast 23 msec., respectively. If any application-specific multicast
addresses are subscribed, the amount of time saved could be addresses are subscribed, the amount of time saved could be substan-
substantially more. tially more.
This example might seem a bit contrived because MLD isn't used in the This example might seem a bit contrived because MLD isn't used in the
3G cellular protocols and wireless local area network protocols typi- 3G cellular protocols and wireless local area network protocols typi-
cally have enough bandwidth, if radio propagation conditions are cally have enough bandwidth, if radio propagation conditions are
optimal, so sending a single MLD message might not be viewed as such optimal, so sending a single MLD message might not be viewed as such
a performance burden. An example of a wireless protocol where MLD a performance burden. An example of a wireless protocol where MLD
context transfer might be useful is IEEE 802.15.1 (Bluetooth)[BT]. context transfer might be useful is IEEE 802.15.1 (Bluetooth)[BT].
IEEE 802.15.1 has two IP "profiles": one with and one without PPP. IEEE 802.15.1 has two IP "profiles": one with and one without PPP.
The profile without PPP would use MLD. The 802.15.1 protocol has a The profile without PPP would use MLD. The 802.15.1 protocol has a
maximum bandwidth of about 800 kbps, shared between all nodes on the maximum bandwidth of about 800 kbps, shared between all nodes on the
skipping to change at page 30, line 22 skipping to change at page 31, line 51
text Data Block. This transition is exactly the same as if the text Data Block. This transition is exactly the same as if the
router had received a Report message. router had received a Report message.
- If the router is in the Listeners present state on that interface, - If the router is in the Listeners present state on that interface,
it remains in that state but restarts the timer, as if it had it remains in that state but restarts the timer, as if it had
received a Report message. received a Report message.
If more than one MLD router is on the link, a router receiving an MLD If more than one MLD router is on the link, a router receiving an MLD
Context Data Block SHOULD send the block to the other routers on the Context Data Block SHOULD send the block to the other routers on the
link. If wireless bandwidth is not an issue, the router MAY instead link. If wireless bandwidth is not an issue, the router MAY instead
send a proxy MLD Report message on the wireless interface that adver- send a proxy MLD Report message on the wireless interface that
tises the Subnet Prefix field from the Context Data Block. Since MLD advertises the Subnet Prefix field from the Context Data Block. Since
routers do not keep track of which nodes are listening to munticast MLD routers do not keep track of which nodes are listening to munti-
addresses, only whether a particular multicast address is being lis- cast addresses, only whether a particular multicast address is being
tened to, proxying the subscription should cause no difficulty. listened to, proxying the subscription should cause no difficulty.
Authors' Addresses Authors' Addresses
Rajeev Koodli Rajeev Koodli
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
Rajeev.koodli@nokia.com Rajeev.koodli@nokia.com
skipping to change at page 31, line 4 skipping to change at page 32, line 31
00180 Espoo 00180 Espoo
Finland Finland
john.loughney@nokia.com john.loughney@nokia.com
Madjid F. Nakhjiri Madjid F. Nakhjiri
Motorola Labs Motorola Labs
1031 East Algonquin Rd., Room 2240 1031 East Algonquin Rd., Room 2240
Schaumburg, IL, 60196 Schaumburg, IL, 60196
USA USA
madjid.nakhjiri@motorola.com madjid.nakhjiri@motorola.com
Charles E. Perkins Charles E. Perkins
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
charliep@iprg.nokia.com charliep@iprg.nokia.com
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 INFOR-
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). 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.
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 INFOR- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Intellectual Property 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.
Copies of IPR disclosures made to the IETF Secretariat and any assur- Copies of IPR disclosures made to the IETF Secretariat and any
ances of licenses to be made available, or the result of an attempt assurances of licenses to be made available, or the result of an
made to obtain a general license or permission for the use of such attempt made to obtain a general license or permission for the use of
proprietary rights by implementers or users of this specification can such proprietary rights by implementers or users of this specifica-
be obtained from the IETF on-line IPR repository at tion 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 ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Acknowledgement Acknowledgement
 End of changes. 

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