doc: Add RFC documents

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]
+