summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4830.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4830.txt')
-rw-r--r--doc/rfc/rfc4830.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc4830.txt b/doc/rfc/rfc4830.txt
new file mode 100644
index 0000000..7b63963
--- /dev/null
+++ b/doc/rfc/rfc4830.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group J. Kempf, Ed.
+Request for Comments: 4830 DoCoMo USA Labs
+Category: Informational April 2007
+
+
+ Problem Statement for Network-Based Localized
+ Mobility Management (NETLMM)
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+ Localized mobility management is a well-understood concept in the
+ IETF, with a number of solutions already available. This document
+ looks at the principal shortcomings of the existing solutions, all of
+ which involve the host in mobility management, and makes a case for
+ network-based local mobility management.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Terminology ................................................3
+ 2. The Local Mobility Problem ......................................4
+ 3. Scenarios for Localized Mobility Management .....................7
+ 3.1. Large Campus ...............................................7
+ 3.2. Advanced Cellular Network ..................................7
+ 3.3. Picocellular Network with Small But Node-Dense Last
+ Hop Links ..................................................8
+ 4. Problems with Existing Solutions ................................8
+ 5. Advantages of Network-based Localized Mobility Management .......9
+ 6. Security Considerations ........................................10
+ 7. Informative References .........................................10
+ 8. Acknowledgements ...............................................11
+ 9. Contributors ...................................................12
+
+
+
+
+
+
+
+
+
+Kempf Informational [Page 1]
+
+RFC 4830 NETLMM Problem Statement April 2007
+
+
+1. Introduction
+
+ Localized mobility management has been the topic of much work in the
+ IETF. The experimental protocols developed from previous works,
+ namely Fast-Handovers for Mobile IPv6 (FMIPv6) [13] and Hierarchical
+ Mobile IPv6 (HMIPv6) [18], involve host-based solutions that require
+ host involvement at the IP layer similar to, or in addition to, that
+ required by Mobile IPv6 [10] for global mobility management.
+ However, recent developments in the IETF and the Wireless LAN (WLAN)
+ infrastructure market suggest that it may be time to take a fresh
+ look at localized mobility management.
+
+ First, new IETF work on global mobility management protocols that are
+ not Mobile IPv6, such as Host Identity Protocol (HIP) [16] and IKEv2
+ Mobility and Multihoming (MOBIKE) [4], suggests that future wireless
+ IP nodes may support a more diverse set of global mobility protocols.
+ While it is possible that existing localized mobility management
+ protocols could be used with HIP and MOBIKE, some would require
+ additional effort to implement, deploy, or in some cases, even
+ specify in a non-Mobile IPv6 mobile environment.
+
+ Second, the success in the WLAN infrastructure market of WLAN
+ switches, which perform localized management without any host stack
+ involvement, suggests a possible paradigm that could be used to
+ accommodate other global mobility options on the mobile node while
+ reducing host stack software complexity, expanding the range of
+ mobile nodes that could be accommodated.
+
+ This document briefly describes the general local mobility problem
+ and scenarios where localized mobility management would be desirable.
+ Then problems with existing or proposed IETF localized mobility
+ management protocols are briefly discussed. The network-based
+ mobility management architecture and a short description of how it
+ solves these problems are presented. A more detailed discussion of
+ goals for a network-based, localized mobility management protocol and
+ gap analysis for existing protocols can be found in [11]. Note that
+ IPv6 and wireless links are considered to be the initial scope for a
+ network-based localized mobility management, so the language in this
+ document reflects that scope. However, the conclusions of this
+ document apply equally to IPv4 and wired links, where nodes are
+ disconnecting and reconnecting.
+
+
+
+
+
+
+
+
+
+
+Kempf Informational [Page 2]
+
+RFC 4830 NETLMM Problem Statement April 2007
+
+
+1.1. Terminology
+
+ Mobility terminology in this document follows that in RFC 3753 [14],
+ with the addition of some new and revised terminology given here:
+
+ WLAN Switch
+
+ A WLAN switch is a multiport bridge Ethernet [8] switch that
+ connects network segments but also allows a physical and logical
+ star topology, which runs a protocol to control a collection of
+ 802.11 [6] access points. The access point control protocol
+ allows the switch to perform radio resource management functions
+ such as power control and terminal load balancing between the
+ access points. Most WLAN switches also support a proprietary
+ protocol for inter-subnet IP mobility, usually involving some kind
+ of inter-switch IP tunnel, which provides session continuity when
+ a terminal moves between subnets.
+
+ Access Network
+
+ An access network is a collection of fixed and mobile network
+ components allowing access to the Internet all belonging to a
+ single operational domain. It may consist of multiple air
+ interface technologies (for example, 802.16e [7], Universal Mobile
+ Telecommunications System (UMTS) [1], etc.) interconnected with
+ multiple types of backhaul interconnections (such as Synchronous
+ Optical Network (SONET) [9], metro Ethernet [15] [8], etc.).
+
+ Local Mobility (revised)
+
+ Local Mobility is mobility over an access network. Note that
+ although the area of network topology over which the mobile node
+ moves may be restricted, the actual geographic area could be quite
+ large, depending on the mapping between the network topology and
+ the wireless coverage area.
+
+ Localized Mobility Management
+
+ Localized Mobility Management is a generic term for any protocol
+ that maintains the IP connectivity and reachability of a mobile
+ node for purposes of maintaining session continuity when the
+ mobile node moves, and whose signaling is confined to an access
+ network.
+
+ Localized Mobility Management Protocol
+
+ A protocol that supports localized mobility management.
+
+
+
+
+Kempf Informational [Page 3]
+
+RFC 4830 NETLMM Problem Statement April 2007
+
+
+ Global Mobility Management Protocol
+
+ A Global Mobility Management Protocol is a mobility protocol used
+ by the mobile node to change the global, end-to-end routing of
+ packets for purposes of maintaining session continuity when
+ movement causes a topology change, thus invalidating a global
+ unicast address of the mobile node. This protocol could be Mobile
+ IP [10] [17], but it could also be HIP [16] or MOBIKE [4].
+
+ Global Mobility Anchor Point
+
+ A node in the network where the mobile node maintains a permanent
+ address and a mapping between the permanent address and the local
+ temporary address where the mobile node happens to be currently
+ located. The Global Mobility Anchor Point may be used for
+ purposes of rendezvous and possibly traffic forwarding.
+
+ Intra-Link Mobility
+
+ Intra-Link Mobility is mobility between wireless access points
+ within a link. Typically, this kind of mobility only involves
+ Layer 2 mechanisms, so Intra-Link Mobility is often called Layer 2
+ mobility. No IP subnet configuration is required upon movement
+ since the link does not change, but some IP signaling may be
+ required for the mobile node to confirm whether or not the change
+ of wireless access point also resulted in the previous access
+ routers becoming unreachable. If the link is served by a single
+ access point/router combination, then this type of mobility is
+ typically absent. See Figure 1.
+
+2. The Local Mobility Problem
+
+ The local mobility problem is restricted to providing IP mobility
+ management for mobile nodes within an access network. The access
+ network gateways function as aggregation routers. In this case,
+ there is no specialized routing protocol (e.g., Generic Tunneling
+ Protocol (GTP), Cellular IP, Hawaii, etc.) and the routers form a
+ standard IP routed network (e.g., OSPF, Intermediate System to
+ Intermediate System (IS-IS), RIP, etc.). This is illustrated in
+ Figure 1, where the access network gateway routers are designated as
+ "ANG". Transitions between service providers in separate autonomous
+ systems, or across broader, topological "boundaries" within the same
+ service provider, are excluded.
+
+ Figure 1 depicts the scope of local mobility in comparison to global
+ mobility. The Access Network Gateways (ANGs), GA1 and GB1, are
+ gateways to their access networks. The Access Routers (ARs), RA1 and
+ RA2, are in access network A; RB1 is in access network B. Note that
+
+
+
+Kempf Informational [Page 4]
+
+RFC 4830 NETLMM Problem Statement April 2007
+
+
+ it is possible to have additional aggregation routers between ANG GA1
+ and ANG GB1, and the access routers if the access network is large.
+ Access Points (APs) PA1 through PA3 are in access network A; PB1 and
+ PB2 are in access network B. Other ANGs, ARs, and APs are also
+ possible, and other routers can separate the ARs from the ANGs. The
+ figure implies a star topology for the access network deployment, and
+ the star topology is the primary interest since it is quite common,
+ but the problems discussed here are equally relevant to ring or mesh
+ topologies in which ARs are directly connected through some part of
+ the network.
+
+ Access Network A Access Network B
+
+ +-------+ +-------+
+ |ANG GA1| (other ANGs) |ANG GB1| (other ANGs)
+ +-------+ +-------+
+ @ @ @
+ @ @ @
+ @ @ @ (other routers)
+ @ @ @
+ @ @ @
+ @ @ @
+ +------+ +------+ +------+
+ |AR RA1| |AR RA2|(other ARs) |AR RB1| (other ARs)
+ +------+ +------+ +------+
+ * * *
+ * * * * *
+ * * * * *
+ * * * * *
+ * * * * *
+ * * * (other APs) * * (other APs)
+ /\ /\ /\ /\ /\
+ /AP\ /AP\ /AP\ /AP\ /AP\
+ /PA1 \ /PA2 \ /PA3 \ /PB1 \ /PB2 \
+ ------ ------ ------ ------ ------
+
+ +--+ +--+ +--+ +--+
+ |MN|----->|MN|----->|MN|-------->|MN|
+ +--+ +--+ +--+ +--+
+ Intra-link Local Global
+ (Layer 2) Mobility Mobility
+ Mobility
+
+ Figure 1. Scope of Local and Global Mobility Management
+
+
+
+
+
+
+
+Kempf Informational [Page 5]
+
+RFC 4830 NETLMM Problem Statement April 2007
+
+
+ As shown in the figure, a global mobility protocol may be necessary
+ when a mobile node (MN) moves between two access networks. Exactly
+ what the scope of the access networks is depends on deployment
+ considerations. Mobility between two APs under the same AR
+ constitutes intra-link (or Layer 2) mobility, and is typically
+ handled by Layer 2 mobility protocols (if there is only one AP/cell
+ per AR, then intra-link mobility may be lacking). Between these two
+ lies local mobility. Local mobility occurs when a mobile node moves
+ between two APs connected to two different ARs.
+
+ Global mobility protocols allow a mobile node to maintain
+ reachability when the MN's globally routable IP address changes. It
+ does this by updating the address mapping between the permanent
+ address and temporary local address at the global mobility anchor
+ point, or even end to end by changing the temporary local address
+ directly at the node with which the mobile node is corresponding. A
+ global mobility management protocol can therefore be used between ARs
+ for handling local mobility. However, there are three well-known
+ problems involved in using a global mobility protocol for every
+ movement between ARs. Briefly, they are:
+
+ 1) Update latency. If the global mobility anchor point and/or
+ correspondent node (for route-optimized traffic) is at some
+ distance from the mobile node's access network, the global
+ mobility update may require a considerable amount of time. During
+ this time, packets continue to be routed to the old temporary
+ local address and are essentially dropped.
+
+ 2) Signaling overhead. The amount of signaling required when a
+ mobile node moves from one last-hop link to another can be quite
+ extensive, including all the signaling required to configure an IP
+ address on the new link and global mobility protocol signaling
+ back into the network for changing the permanent to temporary
+ local address mapping. The signaling volume may negatively impact
+ wireless bandwidth usage and real-time service performance.
+
+ 3) Location privacy. The change in temporary local address as the
+ mobile node moves exposes the mobile node's topological location
+ to correspondents and potentially to eavesdroppers. An attacker
+ that can assemble a mapping between subnet prefixes in the mobile
+ node's access network and geographical locations can determine
+ exactly where the mobile node is located. This can expose the
+ mobile node's user to threats on their location privacy. A more
+ detailed discussion of location privacy for Mobile IPv6 can be
+ found in [12].
+
+
+
+
+
+
+Kempf Informational [Page 6]
+
+RFC 4830 NETLMM Problem Statement April 2007
+
+
+ These problems suggest that a protocol to localize the management of
+ topologically small movements is preferable to using a global
+ mobility management protocol on each movement to a new link. In
+ addition to these problems, localized mobility management can provide
+ a measure of local control, so mobility management can be tuned for
+ specialized local conditions. Note also that if localized mobility
+ management is provided, it is not strictly required for a mobile node
+ to support a global mobility management protocol since movement
+ within a restricted IP access network can still be accommodated.
+ Without such support, however, a mobile node experiences a disruption
+ in its traffic when it moves beyond the border of the localized
+ mobility management domain.
+
+3. Scenarios for Localized Mobility Management
+
+ There are a variety of scenarios in which localized mobility
+ management is useful.
+
+3.1. Large Campus
+
+ One scenario where localized mobility management would be attractive
+ is a campus WLAN deployment, in which the geographical span of the
+ campus, distribution of buildings, availability of wiring in
+ buildings, etc. preclude deploying all WLAN access points as part of
+ the same IP subnet. WLAN Layer 2 mobility could not be used across
+ the entire campus.
+
+ In this case, the campus is divided into separate last-hop links,
+ each served by one or more access routers. This kind of deployment
+ is served today by WLAN switches that coordinate IP mobility between
+ them, effectively providing localized mobility management at the link
+ layer. Since the protocols are proprietary and not interoperable,
+ any deployments that require IP mobility necessarily require switches
+ from the same vendor.
+
+3.2. Advanced Cellular Network
+
+ Next-generation cellular protocols, such as 802.16e [7] and Super
+ 3G/3.9G [2], have the potential to run IP deeper into the access
+ network than the current 3G cellular protocols, similar to today's
+ WLAN networks. This means that the access network can become a
+ routed IP network. Interoperable localized mobility management can
+ unify local mobility across a diverse set of wireless protocols all
+ served by IP, including advanced cellular, WLAN, and personal area
+ wireless technologies such as UltraWide Band (UWB) [5] and Bluetooth
+ [3]. Localized mobility management at the IP layer does not replace
+ Layer 2 mobility (where available) but rather complements it. A
+ standardized, interoperable localized mobility management protocol
+
+
+
+Kempf Informational [Page 7]
+
+RFC 4830 NETLMM Problem Statement April 2007
+
+
+ for IP can remove the dependence on IP-layer localized mobility
+ protocols that are specialized to specific link technologies or
+ proprietary, which is the situation with today's 3G protocols. The
+ expected benefit is a reduction in maintenance cost and deployment
+ complexity. See [11] for a more detailed discussion of the goals for
+ a network-based localized mobility management protocol.
+
+3.3. Picocellular Network with Small But Node-Dense Last-Hop Links
+
+ Future radio link protocols at very high frequencies may be
+ constrained to very short, line-of-sight operation. Even some
+ existing protocols, such as UWB [5] and Bluetooth [3], are designed
+ for low transmit power, short-range operation. For such protocols,
+ extremely small picocells become more practical. Although picocells
+ do not necessarily imply "pico subnets", wireless sensors and other
+ advanced applications may end up making such picocellular type
+ networks node-dense, requiring subnets that cover small geographical
+ areas, such as a single room. The ability to aggregate many subnets
+ under a localized mobility management scheme can help reduce the
+ amount of IP signaling required on link movement.
+
+4. Problems with Existing Solutions
+
+ Existing solutions for localized mobility management fall into two
+ classes:
+
+ 1) Interoperable IP-level protocols that require changes to the
+ mobile node's IP stack and handle localized mobility management as
+ a service provided to the mobile node by the access network.
+
+ 2) Link specific or proprietary protocols that handle localized
+ mobility for any mobile node but only for a specific type of link
+ layer, for example, 802.11 [6].
+
+ The dedicated localized mobility management IETF protocols for
+ Solution 1 are not yet widely deployed, but work continues on
+ standardization. Some Mobile IPv4 deployments use localized mobility
+ management. For Solution 1, the following are specific problems:
+
+ 1) The host stack software requirement limits broad usage even if the
+ modifications are small. The success of WLAN switches indicates
+ that network operators and users prefer no host stack software
+ modifications. This preference is independent of the lack of
+ widespread Mobile IPv4 deployment, since it is much easier to
+ deploy and use the network.
+
+
+
+
+
+
+Kempf Informational [Page 8]
+
+RFC 4830 NETLMM Problem Statement April 2007
+
+
+ 2) Future mobile nodes may choose other global mobility management
+ protocols, such as HIP or MOBIKE. The existing localized mobility
+ management solutions all depend on Mobile IP or derivatives.
+
+ 3) Existing localized mobility management solutions do not support
+ both IPv4 and IPv6.
+
+ 4) Existing host-based localized mobility management solutions
+ require setting up additional security associations with network
+ elements in the access domain.
+
+ Market acceptance of WLAN switches has been very large, so Solution 2
+ is widely deployed and continuing to grow. Solution 2 has the
+ following problems:
+
+ 1) Existing solutions only support WLAN networks with Ethernet
+ backhaul and therefore are not available for advanced cellular
+ networks or picocellular protocols, or other types of wired
+ backhaul.
+
+ 2) Each WLAN switch vendor has its own proprietary protocol that does
+ not interoperate with other vendors' equipment.
+
+ 3) Because the solutions are based on Layer 2 routing, they may not
+ scale up to a metropolitan area or local province, particularly
+ when multiple kinds of link technologies are used in the backbone.
+
+5. Advantages of Network-based Localized Mobility Management
+
+ Having an interoperable, standardized localized mobility management
+ protocol that is scalable to topologically large networks, but
+ requires no host stack involvement for localized mobility management
+ is a highly desirable solution. The advantages that this solution
+ has over Solutions 1 and 2 above are as follows:
+
+ 1) Compared with Solution 1, a network-based solution requires no
+ localized mobility management support on the mobile node and is
+ independent of global mobility management protocol, so it can be
+ used with any or none of the existing global mobility management
+ protocols. The result is a more modular mobility management
+ architecture that better accommodates changing technology and
+ market requirements.
+
+ 2) Compared with Solution 2, an IP-level network-based localized
+ mobility management solution works for link protocols other than
+ Ethernet, and for wide area networks.
+
+
+
+
+
+Kempf Informational [Page 9]
+
+RFC 4830 NETLMM Problem Statement April 2007
+
+
+ RFC 4831 [11] discusses a reference architecture for a network-
+ based, localized mobility protocol and the goals of the protocol
+ design.
+
+6. Security Considerations
+
+ Localized mobility management has certain security considerations,
+ one of which -- the need for security from access network to mobile
+ node -- was discussed in this document. Host-based localized
+ mobility management protocols have all the security problems involved
+ with providing a service to a host. Network-based localized mobility
+ management requires security among network elements that is
+ equivalent to what is needed for routing information security, and
+ security between the host and network that is equivalent to what is
+ needed for network access, but no more. A more complete discussion
+ of the security goals for network-based localized mobility management
+ can be found in [11].
+
+7. Informative References
+
+ [1] 3GPP, "UTRAN Iu interface: General aspects and principles", 3GPP
+ TS 25.410, 2002,
+ http://www.3gpp.org/ftp/Specs/html-info/25410.htm.
+
+ [2] 3GPP, "3GPP System Architecture Evolution: Report on Technical
+ Options and Conclusions", TR 23.882, 2005,
+ http://www.3gpp.org/ftp/Specs/html-info/23882.htm.
+
+ [3] Bluetooth SIG, "Specification of the Bluetooth System",
+ November, 2004, available at http://www.bluetooth.com.
+
+ [4] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)",
+ RFC 4555, June 2006.
+
+ [5] IEEE 802.15 WPAN High Rate Alternative PHY Task Group 3a (TG3a),
+ http://www.ieee802.org/15/pub/TG3a.html.
+
+ [6] IEEE, "Wireless LAN Medium Access Control (MAC) and Physical
+ Layer (PHY) specifications", IEEE Std. 802.11, 1999.
+
+ [7] IEEE, "Amendment to IEEE Standard for Local and Metropolitan
+ Area Networks - Part 16: Air Interface for Fixed Broadband
+ Wireless Access Systems - Physical and Medium Access Control
+ Layers for Combined Fixed and Mobile Operation in Licensed
+ Bands", IEEE Std. 802.16e-2005, 2005.
+
+
+
+
+
+
+Kempf Informational [Page 10]
+
+RFC 4830 NETLMM Problem Statement April 2007
+
+
+ [8] IEEE, "Carrier sense multiple access with collision detection
+ (CSMA/CD) access method and physical layer specifications", IEEE
+ Std. 802.3-2005, 2005.
+
+ [9] ITU-T, "Architecture of Transport Networks Based on the
+ Synchronous Digital Hierarchy (SDH)", ITU-T G.803, March, 2000.
+
+ [10] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
+ IPv6", RFC 3775, June 2004.
+
+ [11] Kempf, J., Ed., "Goals for Network-Based Localized Mobility
+ Management (NETLMM)", RFC 4831, April 2007.
+
+ [12] Koodli, R., "IP Address Location Privacy and Mobile IPv6:
+ Problem Statement", Work in Progress, February 2007.
+
+ [13] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July
+ 2005.
+
+ [14] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
+ 3753, June 2004.
+
+ [15] Metro Ethernet Forum, " Metro Ethernet Network Architecture
+ Framework - Part 1: Generic Framework", MEF 4, May, 2004.
+
+ [16] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP)
+ Architecture", RFC 4423, May 2006.
+
+ [17] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
+ 2002.
+
+ [18] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier,
+ "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC
+ 4140, August 2005.
+
+8. Acknowledgements
+
+ The authors would like to acknowledge the following for particularly
+ diligent reviewing: Vijay Devarapalli, Peter McCann, Gabriel
+ Montenegro, Vidya Narayanan, Pekka Savola, and Fred Templin.
+
+
+
+
+
+
+
+
+
+
+
+Kempf Informational [Page 11]
+
+RFC 4830 NETLMM Problem Statement April 2007
+
+
+9. Contributors
+
+ Kent Leung
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134
+ USA
+ EMail: kleung@cisco.com
+
+ Phil Roberts
+ Motorola Labs
+ Schaumberg, IL
+ USA
+ EMail: phil.roberts@motorola.com
+
+ Katsutoshi Nishida
+ NTT DoCoMo Inc.
+ 3-5 Hikarino-oka, Yokosuka-shi
+ Kanagawa,
+ Japan
+ Phone: +81 46 840 3545
+ EMail: nishidak@nttdocomo.co.jp
+
+ Gerardo Giaretta
+ Telecom Italia Lab
+ via G. Reiss Romoli, 274
+ 10148 Torino
+ Italy
+ Phone: +39 011 2286904
+ EMail: gerardo.giaretta@tilab.com
+
+ Marco Liebsch
+ NEC Network Laboratories
+ Kurfuersten-Anlage 36
+ 69115 Heidelberg
+ Germany
+ Phone: +49 6221-90511-46
+ EMail: marco.liebsch@ccrle.nec.de
+
+Editor's Address
+
+ James Kempf
+ DoCoMo USA Labs
+ 181 Metro Drive, Suite 300
+ San Jose, CA 95110
+ USA
+ Phone: +1 408 451 4711
+ EMail: kempf@docomolabs-usa.com
+
+
+
+Kempf Informational [Page 12]
+
+RFC 4830 NETLMM Problem Statement April 2007
+
+
+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
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Kempf Informational [Page 13]
+