draft-ietf-mip6-dsmip-problem-03.txt   rfc4977.txt 
Network Working Group G. Tsirtsis Network Working Group G. Tsirtsis
Internet-Draft Qualcomm Request for Comments: 4977 Qualcomm
Intended status: Standards Track H. Soliman Category: Informational H. Soliman
Expires: July 23, 2007 Elevate Technologies Elevate Technologies
January 19, 2007 August 2007
Problem Statement: Dual Stack Mobility Problem Statement: Dual Stack Mobility
draft-ietf-mip6-dsmip-problem-03.txt
Status of this Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 23, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007). This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract Abstract
This draft discusses the issues associated with mobility management This document discusses the issues associated with mobility
for dual stack mobile nodes. Currently, two mobility management management for dual stack mobile nodes. Currently, two mobility
protocols are defined for IPv4 and IPv6. Deploying both in a dual management protocols are defined for IPv4 and IPv6. Deploying both
stack mobile node introduces a number of problems. Deployment and in a dual stack mobile node introduces a number of problems.
operational issues motivate the use of a single mobility management Deployment and operational issues motivate the use of a single
protocol. This draft discusses such motivations. The draft also mobility management protocol. This document discusses such
discusses requirements for the Mobile IPv4 and Mobile IPv6 protocol motivations. The document also discusses requirements for the Mobile
so that they can support mobility management for a dual stack node. IPv4 (MIPv4) and Mobile IPv6 (MIPv6) protocol so that they can
support mobility management for a dual stack node.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction and Motivation . . . . . . . . . . . . . . . . . . 2
3. Introduction and Motivation . . . . . . . . . . . . . . . . . 5 3. Problem Description . . . . . . . . . . . . . . . . . . . . . . 3
4. Problem Description . . . . . . . . . . . . . . . . . . . . . 6 3.1. The Impossibility of Maintaining IP Connectivity . . . . . 4
4.1. The impossibility of Maintaining IP Connectivity . . . . . 6 3.2. Implementation Burdens . . . . . . . . . . . . . . . . . . 4
4.2. Implementation Burdens . . . . . . . . . . . . . . . . . . 6 3.3. Operational Burdens . . . . . . . . . . . . . . . . . . . . 4
4.3. Operational Burdens . . . . . . . . . . . . . . . . . . . 7 3.4. Mobility Management Inefficiencies . . . . . . . . . . . . 4
4.4. Mobility Management Inefficiencies . . . . . . . . . . . . 7 3.5. IPv4 to IPv6 Transition Mechanisms . . . . . . . . . . . . 5
4.5. IPv4 to IPv6 Transition Mechanisms . . . . . . . . . . . . 7 4. Conclusions and Recommendations . . . . . . . . . . . . . . . . 5
5. Conclusions and Recommendations . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8. Changes from version .02 . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Requirements Notation
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 [RFC2119].
2. Terminology 1. Terminology
In addition to [RFC2119], this draft uses the following terms as This document uses the following terms as defined in Stateless IP/
defined in SIIT [RFC2765]: IPv4-capable node, IPv4-enabled node, ICMP Translation (SIIT) [RFC2765]: IPv4-capable node, IPv4-enabled
IPv6-capable node, IPv6-enabled node. node, IPv6-capable node, IPv6-enabled node.
The following terms are introduced in this document: The following terms are introduced in this document:
- MIPv4-capable node: - MIPv4-capable node:
A node that supports MIPv4 [RFC3344] in its implementation. This A node that supports MIPv4 [RFC3344] in its implementation. This
allows the mobile node to configure a home address (statically or allows the mobile node to configure a home address (statically or
dynamically) and use such address in its Mobile IPv4 signaling. A dynamically) and use such address in its Mobile IPv4 signaling. A
MIPv4-capable node may also be IPv6-capable or IPv6-enabled and MIPv4-capable node may also be IPv6-capable or IPv6-enabled and
must be IPv4-capable. must be IPv4-capable.
- MIPv6-capable node: - MIPv6-capable node:
A node that supports MIPv6 [RFC3775] by configuring a home address A node that supports MIPv6 [RFC3775] by configuring a home address
and using such address in its Mobile IPv6 signaling. A MIPv6- and using such address in its Mobile IPv6 signaling. A MIPv6-
enabled node may also be IPv4-capable or IPv4-enabled and must be enabled node may also be IPv4-capable or IPv4-enabled and must be
IPv6-capable. IPv6-capable.
3. Introduction and Motivation 2. Introduction and Motivation
A MIPv4-capable node can use Mobile IPv4 [RFC3344] to maintain A MIPv4-capable node can use Mobile IPv4 [RFC3344] to maintain
connectivity while moving between IPv4 subnets. Similarly, a MIPv6- connectivity while moving between IPv4 subnets. Similarly, a MIPv6-
capable node can use Mobile IPv6 [RFC3775] to maintain connectivity capable node can use Mobile IPv6 [RFC3775] to maintain connectivity
while moving between IPv6 subnets. while moving between IPv6 subnets.
One of the ways of migrating to IPv6 is to deploy nodes that are both One of the ways of migrating to IPv6 is to deploy nodes that are both
IPv4 and IPv6 capable. Such nodes will be able to get both IPv4 and IPv4 and IPv6 capable. Such nodes will be able to get both IPv4 and
IPv6 addresses and thus can communicate with the current IPv4 IPv6 addresses and thus can communicate with the current IPv4
Internet as well as any IPv6 nodes and networks as they become Internet as well as any IPv6 nodes and networks as they become
skipping to change at page 5, line 31 skipping to change at page 3, line 11
ensure connectivity since that also depends on the IP version support ensure connectivity since that also depends on the IP version support
of the network accessed. Supporting Mobile IPv4 and Mobile IPv6 is of the network accessed. Supporting Mobile IPv4 and Mobile IPv6 is
also more inefficient since it requires: also more inefficient since it requires:
- Mobile nodes to be both MIPv4 and MIPv6 capable. - Mobile nodes to be both MIPv4 and MIPv6 capable.
- Mobile nodes to send two sets of signaling messages on every - Mobile nodes to send two sets of signaling messages on every
handoff. handoff.
- Network Administrators to run and maintain two sets of mobility - Network Administrators to run and maintain two sets of mobility
management systems on the same network. Each of these systems management systems on the same network, with each of these systems
requiring their own set of optimizations. requiring its own set of optimizations.
This draft discusses the potential inefficiencies, IP connectivity This document discusses the potential inefficiencies, IP connectivity
problems, and operational issues that are evident when running both problems, and operational issues that are evident when running both
mobility management protocols simultaneously. It also proposes a mobility management protocols simultaneously. It also proposes a
work area to be taken up by the IETF on the subject and discusses work area to be taken up by the IETF on the subject and discusses
requirements for appropriate solutions. requirements for appropriate solutions.
4. Problem Description 3. Problem Description
Mobile IP (v4 and v6) uses a signaling protocol (Registration Mobile IP (v4 and v6) uses a signaling protocol (Registration
requests in MIPv4 [RFC3344] and Binding updates in MIPv6 [RFC3775]) requests in MIPv4 [RFC3344] and Binding updates in MIPv6 [RFC3775])
to set up tunnels between two end points. At the moment, Mobile IP to set up tunnels between two end points. At the moment, Mobile IP
signaling is tightly coupled to the address family (i.e., IPv4 or signaling is tightly coupled to the address family (i.e., IPv4 or
IPv6) used, in the connections it attempts to manipulate. There are IPv6) used, in the connections it attempts to manipulate. There are
no fundamental technical reasons for such coupling. If Mobile IP no fundamental technical reasons for such coupling. If Mobile IP
were viewed as a tunnel setup protocol, it should be able to setup IP were viewed as a tunnel-setup protocol, it should be able to set up
in IP tunnels, independently of the IP version used in the outer and IP in IP tunnels, independently of the IP version used in the outer
inner headers. Other protocols, for example SIP [RFC3261], are able and inner headers. Other protocols -- for example, SIP [RFC3261] --
to use either IPv4 or IPv6 based signaling plane to manipulate IPv4 are able to use either an IPv4- or IPv6-based signaling plane to
and IPv6 connections. manipulate IPv4 and IPv6 connections.
A node that is both MIPv4 and MIPv6 capable, will require the A node that is both MIPv4 and MIPv6 capable, will require the
following to roam within the Internet: following to roam within the Internet:
- The network operator needs to ensure that the home agent - The network operator needs to ensure that the home agent supports
supports both protocols or that it has two separate Home Agents both protocols or that it has two separate Home Agents supporting
supporting the two protocols, each requiring its own management. the two protocols, each requiring its own management.
- Double the amount of configuration in the mobile node and the - Double the amount of configuration in the mobile node and the home
home agent (e.g., security associations). agent (e.g., security associations).
- IP layer local network optimizations for handovers will also - IP-layer local network optimizations for handovers will also need
need to be duplicated. to be duplicated.
We argue that all of the above will make the deployment of Mobile We argue that all of the above will make the deployment of Mobile
IPv6 as well as any dual stack solution in a mobile environment IPv6, as well as any dual stack solution in a mobile environment,
harder. We will discuss some of the issues with the current approach harder. We will discuss some of the issues with the current approach
separately in the following sections. separately in the following sections.
4.1. The impossibility of Maintaining IP Connectivity 3.1. The Impossibility of Maintaining IP Connectivity
Even if a mobile node is both MIPv4 and MIPv6 capable, connectivity Even if a mobile node is both MIPv4 and MIPv6 capable, connectivity
across different networks would not in fact be guaranteed since that across different networks would not, in fact, be guaranteed since
also depends on the IPv4/IPv6 capabilities of the networks the mobile that also depends on the IPv4/IPv6 capabilities of the networks the
is visiting; i.e., a node attempting to connect via a IPv4 only mobile is visiting; i.e., a node attempting to connect via a IPv4-
network would not be able to maintain connectivity of its IPv6 only network would not be able to maintain connectivity of its IPv6
applications and vice versa. This is potentially the most serious applications and vice versa. This is potentially the most serious
problem discussed in this document. problem discussed in this document.
4.2. Implementation Burdens 3.2. Implementation Burdens
As mentioned above, a node that is IPv4 and IPv6 capable must also be As mentioned above, a node that is IPv4 and IPv6 capable must also be
MIPv4 and MIPv6 capable to roam within the Internet. Clearly this MIPv4 and MIPv6 capable to roam within the Internet. The ability to
increases the complexity of implementations for vendors that decide employ both IP versions from one mobility protocol makes it possible
to support both protocols. to implement just that one protocol, assuming the protocol choice is
known. However, in situations where the mobile node must be capable
Some vendors, however, may not support both protocols in either of working in any network, it may still need two protocols.
mobile nodes or home agents. Although this is more of a commercial
issue, it does affect the large-scale deployment of mobile devices on
the Internet.
4.3. Operational Burdens 3.3. Operational Burdens
As mentioned earlier, deploying both protocols will require managing As mentioned earlier, deploying both protocols will require managing
both protocols in the mobile node and the home agent. This adds both protocols in the mobile node and the home agent. This adds
significant operational issues for the network operator. It would significant operational issues for the network operator. It would
certainly require the network operator to have deep knowledge in both certainly require the network operator to have deep knowledge in both
protocols which is something an operator may not be able to justify protocols, which is something an operator may not be able to justify
due to the lack of substantial gains. due to the lack of substantial gains.
In addition, deploying both protocols will require duplication of In addition, deploying both protocols will require duplication of
security credentials on mobile nodes and home agents. This includes, security credentials on mobile nodes and home agents. This includes
IPsec security associations, keying material, and new authentication IPsec security associations, keying material, and new authentication
protocols for Mobile IPv6, in addition to the security credentials protocols for Mobile IPv6, in addition to the security credentials
and associations required by Mobile IPv4. Depending on the security and associations required by Mobile IPv4. Depending on the security
mechanisms used and with some further work it might be possible to mechanisms used and with some further work, it might be possible to
optimize some of these processes. Assuming nothing else changes, rely on one set of common credentials. Assuming nothing else
however, such duplication is again significant with no gain to the changes, however, such duplication is again significant with no gain
operator or the mobile node. to the operator or the mobile node.
4.4. Mobility Management Inefficiencies 3.4. Mobility Management Inefficiencies
Suppose that a mobile node is moving within a dual stack access Suppose that a mobile node is moving within a dual stack access
network. Every time the mobile node moves it needs to send two network. Every time the mobile node moves, it needs to send two
mobile IP messages to its home agent to allow its IPv4 and IPv6 mobile IP messages to its home agent to allow its IPv4 and IPv6
connections to survive. There is no reason for such duplication. If connections to survive. There is no reason for such duplication. If
local mobility optimizations were deployed (e.g., Hierarchical Mobile local mobility optimizations were deployed (e.g., Hierarchical Mobile
IPv6 [RFC4140], Fast handovers for Mobile IPv4 [RFC4068]) the mobile IPv6 (HMIPv6) [RFC4140], Fast handovers for Mobile IPv4 [RFC4068]),
node will need to update the local agents running each protocol. the mobile node will need to update the local agents running each
Ironically, one local agent might be running both HMIPv6 and local protocol. Ironically, one local agent might be running both HMIPv6
MIPv4 home agent. Clearly, it is not desirable to have to send two and local MIPv4 home agent. Clearly, it is not desirable to have to
messages and complete two sets of transactions for the same send two messages and complete two sets of transactions for the same
fundamental optimization. fundamental optimization.
Hence, such parallel operation of Mobile IPv4 and Mobile IPv6 will Hence, such parallel operation of Mobile IPv4 and Mobile IPv6 will
complicate mobility management within the Internet and increase the complicate mobility management within the Internet and increase the
amount of bandwidth needed at the critical handover time for no amount of bandwidth needed at the critical handover time for no
apparent gain. apparent gain.
4.5. IPv4 to IPv6 Transition Mechanisms 3.5. IPv4 to IPv6 Transition Mechanisms
The IETF has standardized a number of transition mechanisms to allow The IETF has standardized a number of transition mechanisms to allow
networks and end nodes to gain IPv6 connectivity while the Internet networks and end nodes to gain IPv6 connectivity while the Internet
is migrating from IPv4 to IPv6. A cursory examination of such is migrating from IPv4 to IPv6. However, while some transition
transition mechanisms indicates that none of them is designed to deal mechanisms can be combined with Mobile IPv4 or Mobile IPv6, none of
with mobile nodes. While some transition mechanisms can be combined the known mechanisms have been shown to assist with the issues
with Mobile IPv4 or Mobile IPv6, non of the known mechanisms have described in this document.
been shown to assist with the issues described in this document.
5. Conclusions and Recommendations 4. Conclusions and Recommendations
The points above highlight the tight coupling in both Mobile IPv4 and The points above highlight the tight coupling in both Mobile IPv4 and
Mobile IPv6 between signaling and the IP addresses used by upper Mobile IPv6 between signaling and the IP addresses used by upper
layers. Given that Mobile IPv4 is currently deployed and Mobile IPv6 layers. Given that Mobile IPv4 is currently deployed and Mobile IPv6
is expected to be deployed, there is a need for gradual transition is expected to be deployed, there is a need for gradual transition
from IPv4 mobility management to IPv6. Running both protocols from IPv4 mobility management to IPv6. Running both protocols
simultaneously is inefficient and has the problems described above. simultaneously is inefficient and has the problems described above.
The gradual transition can be done when needed or deemed appropriate The gradual transition can be done when needed or deemed appropriate
by operators or implementers. In the mean time, it is important to by operators or implementers. In the mean time, it is important to
ensure that the problems listed above can be avoided. Hence, this ensure that the problems listed above can be avoided. Hence, this
section lists some actions that should be taken by the IETF to section lists some actions that should be taken by the IETF to
address the problems listed above, without mandating the use of two address the problems listed above, without mandating the use of two
mobility management protocols simultaneously. mobility management protocols simultaneously.
In order to allow for a gradual transition based on current standards The Mobile IPv6 Working Group has reached the view that to allow for
and deployment, the following work areas seem to be reasonable: a gradual transition based on current standards and deployment, the
following work areas would be reasonable:
- It should be possible to run one mobility management protocol - It should be possible to run one mobility management protocol that
that can manage mobility for both IPv4 and IPv6 addresses used by can manage mobility for both IPv4 and IPv6 addresses used by upper
upper layers. Both Mobile IPv4 and Mobile IPv6 should be able of layers. Both Mobile IPv4 and Mobile IPv6 should be able to
performing such task. It may not be possible to support route perform such tasks. It may not be possible to support route
optimization for Mobile IPv6 in all cases; however, mobility optimization for Mobile IPv6 in all cases; however, mobility
management and session continuity can be supported. management and session continuity can be supported.
- It should be possible to create IPv4 extensions to Mobile IPv6 - It should be possible to create IPv4 extensions to Mobile IPv6 so
so that an IPv4 and IPv6 capable mobile node can register its IPv4 that an IPv4 and IPv6 capable mobile node can register its IPv4
and IPv6 home addresses to an IPv4 and IPv6 enabled Home Agent and IPv6 home addresses to an IPv4- and IPv6-enabled Home Agent
using MIPv6 signaling only. using MIPv6 signaling only.
- It should be possible to create IPv6 extensions to Mobile IPv4 - It should be possible to create IPv6 extensions to Mobile IPv4 so
so that an IPv4 and IPv6 capable mobile node can register its IPv4 that an IPv4 and IPv6 capable mobile node can register its IPv4
and IPv6 home addresses to an IPv4 and IPv6 enabled Home Agent and IPv6 home addresses to an IPv4- and IPv6-enabled Home Agent
using Mobile IPv4 signaling only. using Mobile IPv4 signaling only.
- It should also be possible to extend MIPv4 [RFC3344] and MIPv6 - It should also be possible to extend MIPv4 [RFC3344] and MIPv6
[RFC3775] so that a mobile node can register a single care-of [RFC3775] so that a mobile node can register a single care-of
address (IPv4 or IPv6) to which IPv4 and/or IPv6 packets can be address (IPv4 or IPv6) to which IPv4 and/or IPv6 packets can be
tunneled. tunneled.
Following the steps listed above, a vendor can choose to support one If the IETF chooses to pursue all these paths, a vendor could choose
mobility management protocol while avoiding the incompatibility and to support one mobility management protocol while avoiding the
inefficiency problems listed in this document. Similarly, operators incompatibility and inefficiency problems listed in this document.
can decide to continue using one mobility management protocol while Similarly, operators could decide to continue using one mobility
addressing the transition scenarios that a mobile node is likely to management protocol throughout the period of IPv4 and IPv6
face when roaming within the Internet. coexistence. However, a mobile node would be forced to choose one
approach or the other, or nevertheless to install both and use one or
the other according to circumstances.
6. Security Considerations 5. Security Considerations
This documents is a problem statement which does not by itself This document is a problem statement that does not by itself
introduce any security issues. introduce any security issues.
7. IANA Considerations 6. References
This document does not introduce any IANA considerations.
8. Changes from version .02
- Re-wrote draft using XML template
- Changed title to fit in under 47 characters
- Rearranged subsections under Section 4
- In Section 4.2, clarified that implementation complexity is
increased for vendors that decide to support both versions of the
protocol
- In Section 4.3, clarified that some optimizations might be
possible with respect to duplicated security mechanisms for MIPv4
and MIPv6
- Added a section on transition mechanisms (Section 4.5)
- Added "Security Considerations" Section 6
- General clean up and a number editorial corrections.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 6.1. Normative References
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000. (SIIT)", RFC 2765, February 2000.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002. August 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
9.2. Informative References 6.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005. July 2005.
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management Bellier, "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", RFC 4140, August 2005. (HMIPv6)", RFC 4140, August 2005.
Authors' Addresses Authors' Addresses
George Tsirtsis George Tsirtsis
Qualcomm Qualcomm
Phone: +908-443-8174 Phone: +908-443-8174
Email: tsirtsis@qualcomm.com EMail: tsirtsis@qualcomm.com
Hesham Soliman Hesham Soliman
Elevate Technologies Elevate Technologies
Phone: +614-111-410-445 Phone: +614-111-410-445
Email: hesham@elevatemobile.com EMail: hesham@elevatemobile.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. 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
skipping to change at page 15, line 44 skipping to change at line 335
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 44 change blocks. 
175 lines changed or deleted 111 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/