J. Kempf,EditorInternet Draft K. LeungJ. Kempf, Editor Document: draft-ietf-netlmm-nohost-ps-01.txt P. Roberts K. Nishida G. Giaretta M. Liebschdraft-ietf-netlmm-nohost-ps-02.txt Expires: October,December, 2006 April,June, 2006 Problem Statement for Network-based IP Local Mobility (draft-ietf-netlmm-nohost-ps-01.txt)(draft-ietf-netlmm-nohost-ps-02.txt) 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. 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.http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract In this document, the well-known problem of localizedLocalized mobility management for IP link handoveris given a fresh look. Aftera short discussion ofwell understood concept in the problem andIETF with a couplenumber of scenarios,solutions already available. This document looks at the principal shortcomings of the existing solutionssolutions, all of which involve the host in mobility management, and makes a case for network-based local mobility management. Contributors Gerardo Giaretta, Kent Leung, Katsutoshi Nishida, Phil Roberts, and Marco Liebsch all contributed major effort to this document. Their names are discussed.not included in the authors' section due to the RFC Editor's limit of 5 names. Table of Contents 1.0 Introduction.....................................................2Introduction.............................................2 2.0 The Local Mobility Problem.......................................4Problem...............................4 3.0 Scenarios for Localized Mobility Management......................6Management..............6 4.0 Problems with Existing Solutions.................................7Solutions.........................7 5.0 Security Considerations..........................................9IANA Considerations......................................9 6.0 Author Information...............................................9Security Considerations..................................9 7.0 Informative References..........................................10Acknowledgements........................................10 8.0 IPR Statements..................................................10Author Information......................................10 9.0 Informative References...................................9 10.0 IPR Statements..........................................11 11.0 Disclaimer of Validity..........................................11 10.0Validity..................................11 12.0 Copyright Notice................................................11Notice........................................11 1.0 Introduction Localized mobility management has been the topic of much work in the IETF for some time, and it may seem as if little remains to be said on the topic.IETF. The experimental protocols developed from previous work, namely FMIPv6  and HMIPv6,HMIPv6 , involve host-based solutions that mimicrequire host involvement at the IP layer similar to a greateror lesser extent the approach takenin addition to that required by Mobile IPv6  for global mobility management. However, recent developments in the IETF and the WLAN infrastructure market suggest that it may be time to take a fresh look at localized mobility management. Firstly, new IETF work on global mobility management protocols that are not Mobile IPv6, such as HIP  and Mobike , 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, it would require additional effort to implement and deploy these localized mobility management protocols in an non-Mobile IPv6 mobile environment. Secondly, the success in the WLAN infrastructure market of WLAN switches, which perform localized mobilitymanagement without any host stack involvement, suggests a possible designparadigm that could be used to accommodate other global mobility managementoptions on the mobile node while reducing host stack software complexity andexpanding the range of mobile nodes that could be accommodated. This document briefly describes the general local mobility problem and a fewscenarios where localized mobility management would be desirable. Then, it describes the two most seriousThen problems with existing protocols: the requirement for host stack support, and the complex security interactions required between the mobile nodeor proposed IETF localized mobility management protocols are briefly discussed. The network- based mobility management architecture and the access network. Morea short description of how it solves these problems is presented. A more detailed requirementsdiscussion of goals for a network-based, localized mobility management protocol and gap analysis for existing protocols can be found in . Note that IPv6 and wireless links are considered to be the primary focal points for a network-based localized mobility management, so the language in this document reflects that focus. However, the conclusions of this document apply equally to IPv4 and wired links where nodes are disconnecting and reconnecting. 1.1 Terminology Mobility terminology in this draft follows that in RFC 3753 , with the addition of some new and revised terminology given here: IP Link A set of routers, mobile nodes, and wireless access points that share link broadcast capability or its functional equivalent. This definition covers one or multiple access points under one or several access routers. In the past, such a set has been called a subnet, but this term is not strictly correct for IPv6, since multiple subnet prefixes can be assigned to an IP link in IPv6. Access Network (revised) An Access Network consists of following three components: wireless or other access points, access routers, access network gateways which form the boundary to other networks and may shield other networks from the specialized routing protocols (if any) run in the Access Network; and (optionally) other internal access network routers which may also be needed in some cases to achieve a specialized routing protocol. Local MobilityLocal Mobility (revised) Local Mobility is mobility over a restricted area of the network topology.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 protocols dealing withany IP mobility management confined within the access network. Localized mobility management signaling is not routed outside the access network, although a handover may trigger Global Mobility Management signaling. Localized mobility management protocols exploitprotocol that maintains the localityIP connectivity and reachability of movement by confining movement related changesa mobile node when it moves, and whose signalling is confined to thean access network. Localized Mobility Management Protocol A protocol that supports localized mobility management. 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 when movement causes a topology change and thus invalidates a global unicast address on the local IP link currently in active use by the mobile node. The Global Mobility Protocol may also allow the mobile node to maintain a mapping between a permanent address and a temporary address on the local network for rendezvous with nodes that want to initiate a connection. Typically, thisThis protocol willcould be Mobile IPv6 IP  but it could also be HIP  or Mobike  (Note: although Mobike is not considered a mobility management protocol in general, for purposes of this document, it will be so considered because it manages the address map and routing between a fixed VPN endpoint address and a changing local address). 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. For Mobile IPv6 ,IP , this is the home agent. For HIP , this may be the rendezvous server. For Mobike , this is the VPN tunnelgateway in the home network. Some global mobility management protocols, such as HIP, support end to end global mobility management without a Global Mobility Anchor Point, at the risk of dropping a connection if both sides are mobile and both move at the same time. Intra-Link Mobility Intra-Link Mobility is mobility between wireless access points within an IP Link. Typically, this kind of mobility only involves Layer 2 mechanisms, so Intra-Link Mobility is often called Layer 2 mobility. No IP link 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 a change of IP link. If the IP link consists of a single access point/router combination, then this type of mobility is typically absent. See Figure 1. 2.0 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 aggregation routersgateways function as an access network gateway, although inaggregation routers. In this case, there is no specialized routing protocol (e.g. GTP, Cellular IP, Hawaii, etc.) and the routers function asform a standard IP routed network.network (e.g. OSPF, IS-IS, RIP, etc.). This is illustrated in Figure 1, where the aggregationaccess network gateway routers are designated as "AggR"."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 Aggregation Routers AggR A1Access Network Gateways (ANGs) GA1 and B1GB1 are gateways to thetheir access network.networks. The Access Routers AR A1(ARs) RA1 and A2RA2 are in Access Networkaccess network A, B1RB1 is in Access Networkaccess network B. Note that it is possible to have additional aggregation routers between AggR A1ANG GA1 and AggR B1ANG GB1 and the access routers if the access network is large. Access Points AP A1(APs) PA1 through A3PA3 are in Access Networkaccess network A, B1PB1 and B2PB2 are in Access Networkaccess network B. Other Aggregation Routers, Access Routers,ANGs, ARs, and Access PointsAPs are also possible.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 one of interest since it is quite common, but the problems discussed here are equally relevant to ring or mesh topologies in which access routersARs are directly connected through some part of the network. Access Network A Access Network B +-------+ +-------+ |AggR A1||ANG GA1| (other AggRs) |AggR B1|ANGs) |ANG GB1| (other AggRs)ANGs) +-------+ +-------+ @ @ @ @ @ @ @ @ @ (other routers) @ @ @ @ @ @ @ @ @ +-----+ +-----+ +-----++------+ +------+ +------+ |AR A1|RA1| |AR A2|(otherRA2|(other ARs) |AR B1|RB1| (other ARs) +-----+ +-----+ +-----++------+ +------+ +------+ * * * * * * * * * * * * * * * * * * * * * * * * * * (other APs) * * (other APs) /\ /\ /\ /\ /\ /AP\ /AP\ /AP\ /AP\ /AP\ / A1/PA1 \ / A2/PA2 \ / A3/PA3 \ / B1/PB1 \ / B2/PB2 \ ------ ------ ------ ------ ------ +--+ +--+ +--+ +--+ |MN|----->|MN|----->|MN|-------->|MN| +--+ +--+ +--+ +--+ Intra-link Local Global (Layer 2) Mobility Mobility Mobility Figure 1. Scope of Local and Global Mobility Management As shown in the figure, a global mobility protocol ismay 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 access pointsAPs under the same access routerAR constitutes Intra- link mobility, andintra-link, or Layer 2, mobility, and is typically handled by Layer 2 mobility protocols (if there is only one access point/cellAP/cell per access router,AR, then intra-link mobility may be lacking). Between these two lies local mobility. Local mobility occurs when a mobile node moves between two access pointsAPs connected to two different access routers.ARs. Global mobility protocols allow a mobile node to maintain reachability when a change between access routers occurs,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 access routersARs for handling local mobility. However, there are three well-knownwell- known problems involved in using a global mobility protocolsprotocol for every transitionmovement between access routers.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, during which timepackets 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 IP 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 . 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 IP link move. 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.0 Scenarios for Localized Mobility Management There are a variety of scenarios in which localized mobility management is attractive.useful. 3.1 Large Campus with Diverse Physical InterconnectivityOne scenario where localized mobility management would be attractive is fora large campus wireless LAN deployment in whichdeployment. Having a single broadcast domain for all WLAN access points doesn't scale very well. Also, sometimes parts of the campus are connectedcannot be covered by one VLAN for other reasons (e.g., some links thatare other than 802.3 or in which it is not possible to cover the campus by one VLAN.802.3). In this case, the campus is divided into separate IP links each served by one or more access routers. This kind of deployment is served today by wireless LAN switches that co-ordinate 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  and Super 3G/3.9G  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 UWBUltraWide Band (UWB)  and Bluetooth.Bluetooth . 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 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  for a more detailed discussion of the requirementsgoals for a network-based localized mobility management.management protocol. 3.3 Picocellular Network with Small But Node-Dense IP 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 and Bluetooth, 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 IP links", 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 IP link movement. 4.0 Problems with Existing Solutions Existing solutions for localized mobility management fall into three 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, namely 802.11 running on an 802.3 wired network backhaul. 3) Use of a standard IGP such as OSPF or IS-IS to distribute host routes, and updating the host routes when the mobile node moves.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 likely to beindependent of the lack of widespread Mobile IPv4 deployment, since it is much easier to deploy and use the network. 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) Security for the existingExisting host-based localized mobility management solutions requires complexrequire setting up additional security associations with network elements for no improvementin security over what is available if localized mobility management is not used. In addition to the additional signaling required to set up these security associations, provisioning a mobile node with credentials for roaming to allthe access networks where the mobile node might end up may prove difficult, acting as a barrierdomain. Market acceptance of WLAN switches has been very large, so Solution 2 is widely deployed and continuing to deployment.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 vendor's equipment. 3) Because the solutions are based on layer 2 routing, they may not scale up to a metropolitan area, or local province. Solution 3 has the following problems: 1) Each router in theHaving an interoperable, standardized localized mobility management domainprotocol that is required to maintain a host route table andscalable to search thetopologically large networks, but requires no host route table for routing each packet, limiting the memory and processing power scalability. 2) After handover, until host routes propagate back along the current path of traffic to the localized mobility management domain border, traffic packets for the mobile node are sent to the old router, causing the packets to drop. Since IGPs typically propagate routing updates through flooding, the delay in host route propagation also limits the topological span of the localized mobility management domain. 3) Rapid movement by the mobile node faster than the rate at which flooding can propagate host routes could lead to a cascading series of host route messages that never stabilize. Having an interoperable, standardized localized mobility management protocol that is scalable to topologically large networks, but requires no host stack involvementstack involvement for localized mobility management is a highly desirable solution. Mobility routing anchor points within the backbone network maintain a collection of routes for individual mobile nodes. The routes point to the access routersARs on which mobile nodes currently are located. Packets for the mobile node are routed to and from the mobile node through the mobility anchor point. When a mobile node moves from one access routerAR to another, the access routersARs send a route update to the mobility anchor point. While some mobile node involvement is necessary and expected for generic mobility functions such as movement detection and to inform the access routerAR about mobile node movement, no specific mobile node to network protocol will be required for localized mobility management itself. The advantages that this solution has over the Solutions 1 through 3and 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. 3) Compared with Solution 3, the framework described above for network-based localized mobility management only requires the involvement of the access routers and the mobility anchor. All other routers within the localized mobility management domain do not need to handle host routes, making the architecture more scalable. In addition, because updating the routes requires communication between only two routers, propagation of routes on handover is likely to be much faster.5.0 IANA Considerations There are no IANA considerations in this document. 6.0 Security Considerations Localized mobility management has certain security considerations, one of which - need for access network to mobile node security - was touched on in this document. ExistingHost-based localized mobility management solutions increaseprotocols have all the need for mobile nodesecurity problems involved with providing a service to accessa host. Network-based localized mobility management requires security among network signalingelements equivalent to what is needed for routing information security, and provisioning of the mobile node with credentials without increasing thesecurity beyondbetween the host and network equivalent to what is available ifneeded for network access, but no localized mobility management solution is used.more. A more complete discussion of the security requirementsgoals for network-based localized mobility management can be found in . 6.0 Author Information James Kempf DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110 USA Phone: +1 408 451 4711 Email: email@example.com Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: firstname.lastname@example.org Phil Roberts Motorola Labs Schaumberg, IL USA Email: email@example.com Katsutoshi Nishida NTT DoCoMo Inc. 3-5 Hikarino-oka, Yokosuka-shi Kanagawa, Japan Phone: +81 46 840 3545 Email: firstname.lastname@example.org Gerardo Giaretta Telecom Italia Lab via G. Reiss Romoli, 274 10148 Torino Italy Phone: +39 011 2286904 Email: email@example.com Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221-90511-46 Email: firstname.lastname@example.org References 7.1 Informative References  Koodli, R., editor, "Fast Handovers for Mobile IPv6," RFC 4068, July, 2005.  Soliman, H., editor, "Hierarchical Mobile IPv6 Mobility Management," RFC 4140, August, 2005.  Johnson, D., Perkins, C., and Arkko, J., "Mobility Support in IPv6," RFC 3775.  Moskowitz, R., and Nikander, P., Jokela, P., and Henderson, T.,"Host Identity Protocol", Internet Draft, work in progress.Protocol (HIP) Architecture", RFC 4423, May, 2006.  Kivinen, T.,Eronen, P., editor, "IKEv2 Mobility and Tschopfening, H., "Design of the MOBIKE Protocol",Multihoming Protocol (MOBIKE)", Internet Draft, work in progress.  Kempf, J., Leung, K., Roberts, P., Giaretta, G., Liebsch, M., and Nishita, K.., "Requirements and Gap Analysiseditor, "Goals for Network-based Localized Mobility Management", Internet Draft, work in progress.  Manner, J., and Kojo, M., "Mobility Related Terminology", RFC 3753, June, 2004.  IEEE, "Air Interface for Mobile Broadband Wireless Access Systems", 802.16e, 2005.  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.http://www.3gpp.org/ftp/Specs/html-info/23882.htm.  http://www.ieee802.org/15/pub/TG3a.htm  Bluetooth SIG, "Specification of the Bluetooth System", November, 2004, available at http://www.bluetooth.com.  Koodli, R., "IP Address Location Privacy and Mobile IPv6: Problem Statement", Internet Draft, work in progress.  Perkins, C., editor, " IP Mobility Support for IPv4", RFC 3220, August, 2002. 8.0 Acknowledgements The authors would like to acknowledge the following for particularly diligent reviewing: Pekka Savola, Vijay Devarapalli, Gabriel Montenegro, Peter McCann, and Vidya Narayanan. 9.0 Author's Addresses James Kempf DoCoMo USA Labs 181 Metro Drive, Suite 300 San Jose, CA 95110 USA Phone: +1 408 451 4711 Email: email@example.com Kent Leung Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA EMail: firstname.lastname@example.org Phil Roberts Motorola Labs Schaumberg, IL USA Email: email@example.com Katsutoshi Nishida NTT DoCoMo Inc. 3-5 Hikarino-oka, Yokosuka-shi Kanagawa, Japan Phone: +81 46 840 3545 Email: firstname.lastname@example.org Gerardo Giaretta Telecom Italia Lab via G. Reiss Romoli, 274 10148 Torino Italy Phone: +39 011 2286904 Email: email@example.com Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36 69115 Heidelberg Germany Phone: +49 6221-90511-46 Email: firstname.lastname@example.org 10.0 IPR Statements 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 email@example.com. 9.0ietf- firstname.lastname@example.org. 11.0 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 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 10.012.0 Copyright Notice Copyright (C) The Internet Society (2006). 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.