NEMO Working Group T. Ernst Internet-Draft WIDE at Keio University Expires:
AprilAugust 25, 2005 October 25, 2004February 21, 2005 Network Mobility Support Goals and Requirements draft-ietf-nemo-requirements-03draft-ietf-nemo-requirements-04 Status of this Memo This document is an Internet-Draft and is subject to all provisions of sectionSection 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 AprilAugust 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004).(2005). Abstract Network mobility arises when a router connecting an entirea network to the Internet dynamically changes its point of attachment to the Internet therefromthereby causing the reachability of the entiresaid network to be changed in relation to the fixed Internet topology. Such kind of network is referred to as a mobile network. WithoutWith appropriate mechanisms, sessions established between nodes in the mobile network and the global Internet cannotcan be maintained whileafter the mobile router changes its point of attachment. The required support mechanisms will be provided in two phases. The first phase, referred to as NEMO Basic Support is to provide session continuity while the necessary optimizations mechanims referred to as NEMO Extended Support might be provided later.This document outlines the goals expected from network mobility support and defines the requirements that must be met by the NEMO Basic Support solutions.solution. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. NEMO Working Group Objectives and Methodology . . . . . . . 4 3. NEMO Support Design Goals . . . . . . . . . . . . . . . . . 5 3.1 Migration Transparency . . . . . . . . . . . . . . . . . . 5 3.2 Performance Transparency and Seamless Mobility . . . . . . 5 3.3 Network Mobility Support Transparency . . . . . . . . . . 5 3.4 Operational Transparency . . . . . . . . . . . . . . . . . 6 3.5 Arbitrary Configurations . . . . . . . . . . . . . . . . . 6 3.6 Local Mobility and Global Mobility . . . . . . . . . . . . 7 3.7 Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 3.8 Backward Compatibility . . . . . . . . . . . . . . . . . . 7 3.9 Secure Signaling . . . . . . . . . . . . . . . . . . . . . 8 3.10 Location Privacy . . . . . . . . . . . . . . . . . . . . 8 3.11 IPv4 and NAT Traversal . . . . . . . . . . . . . . . . . 8 4. NEMO Basic Support One-Liner Requirements . . . . . . . . . 8 5. Changes Between VersionsAcknowledgments . . . . . . . . . . . . . . . . . . . . . . 10 5.1 Changes between version -02 and -036. References . . . . . . . . . . . . . . 10 5.2 Changes Between Version -01 and -02. . . . . . . . . . . 10 5.3 Changes Between Version -00 and -01Author's Address . . . . . . . . . . . 11 6. Acknowledgments. . . . . . . . . . . 11 A. Change Log From Earlier Versions . . . . . . . . . . . 11 7. References. . . 12 A.1 Changes between version -03 and -04 . . . . . . . . . . . 12 A.2 Changes between version -02 and -03 . . . . . . . . . . . 12 Author's AddressA.3 Changes Between Version -01 and -02 . . . . . . . . . . . 12 A.4 Changes Between Version -00 and -01 . . . . . . . . . . . 1213 Intellectual Property and Copyright Statements . . . . . . . 1314 1. Introduction Network mobility support is concerned with managing the mobility of an entire network, viewed as a single unit, which changes its point of attachment to the Internet and thus its reachability in the Internet topology. Such kind ofa network is referred to as a mobile network and includes one or more mobile routers (MRs) which connect it to the global Internet. Nodes behind the MR(s) (MNNs) are both fixed (LFNs) and mobile (VMNs or LMNs). In most cases, the internal structure of the mobile network will in effectbe relatively stable (no dynamic change of the topology), but this is not a general assumption.always true. Cases of mobile networks includeinclude, for instance: o networksNetworks attached to people (Personal Area Networks or PANs): a cell-phone with one cellular interface and one Bluetooth interface together with a Bluetooth-enabled PDA constitute a very simple instance of a mobile network. The cell-phone is the mobile router while the PDA is used for web browsing or runs a personal web server. o networksNetworks of sensors and computers deployed in vehicles: vehicles are more and moreincreasingly embedded with a number of processing units for safety and ease of driving reasons, as advocated by ITS (Intelligent Transportation Systems) applications.applications (, ). o accessAccess networks deployed in public transportation (buses, trains, taxis, aircrafts): they provide Internet access to IP devices carried by passengers (laptop,passengers: laptop, camera, mobile phone: host mobility within network mobility or PANs: network mobility within network mobility, i.e. nested mobility (see  for the definition of nested mobility). o ad-hocAd-hoc networks connected to the Internet via aan MR: for instance students in a train that bothneed both to set up an ad-hoc network among themselvesthemselves, and toget Internet connectivity through the MR connecting the train to the Internet. Mobility of networks does not cause MNNs to change their own physical point of attachment,attachment; however they happen todo change their topological location with respect to the global Internet. If network mobility is not explicitly supported by some mechanisms, the mobility of the MR results intoin MNNs losing Internet access and breaking ongoing sessions entertainedbetween arbitrary correspondent node (CNs) in the global Internet and those MNNs located within the mobile network. In addition, the communication path between MNNs and arbitrarycorrespondent nodes (CN)becomes sub-optimal, whereasand multiple levels of mobility will cause extremely sub-optimal routing. The mechanisms required for handling such mobility issuesMobility-related terms used in this document are currently lacking within the IETF standards. Traditional work conducted ondefined in , whereas terms specifically pertaining to network mobility support (particularlyare defined in the Mobile IP working group). This document is to provide continuous Internet connectivitystructured as follows: in Section 2 we define the rough objectives and optimal routingmethodology of the NEMO working group to mobile hosts only (hosthandle network mobility support)issues and are unable to support network mobility. The NEMOwe emphasize the stepwise approach the working group has therefore been set up to deal with issues specific to network mobility. The purpose of this document is thus to detail the methodology that will be followed by the NEMO working group, its goals, and to define requirements for network mobility support. Mobility-related terms used in this document are defined in  whereas terms pertaining to network mobility specifically are defined in . This document is structured as follows: Section 2 defines the rough objectives and methodology of the NEMO working group and we emphasize the stepwise approach the working group has decideddecided to follow. A number of desirable design goals are listed in Section 3. Those design goals then serve as guidelines to edictdefine the requirements listed in Section 4 for basic network mobility support . 2. NEMO Working Group Objectives and Methodology The mechanisms required for handling network mobility issues were lacking within the IETF standards when the NEMO working group was set up at the IETF. At that time, work conducted on mobility support (particularly in the Mobile IP working group) was to provide continuous Internet connectivity and optimal routing to mobile hosts only (host mobility support). Such mechanisms speficied in Mobile IPv6  are unable to support network mobility. The NEMO working group has therefore been set up to deal with issues specific to network mobility. The primary objective of the NEMO work is to specify a solution which allows mobile network nodes (MNNs) to remain connected to the Internet and continuously reachable at all times while the mobile router seving the mobile network they are attached tochanges its point of attachment. SecondaryThe secondary goals of the work is to investigate the effects of network mobility on various aspects of internet communication such as routing protocol changes, implications of realtimereal-time traffic and fast handovers, and optimizations. TheseThis should allsupport the primary goal of reachability for mobile network nodes. Security is an important consideration too, and efforts should be made to use existing security solutions if they are appropriate. Although a well-designed solution may include security inherent in other protocols, mobile networks also introduce new challenges. For doing so,To complete these tasks, the NEMO working group has decided to take a stepwise approach. The steps in this approach byinclude standardizing a basic solution to preserve session continuity (NEMO Basic Support), and at the same time studystudying the possible approaches and issues with providing more optimal routing with potentially nested mobile networks (NEMO Extended Support). However, the working group is not chartered to actually standardize a solution to such route optimizationfor extgended support at this point in time. If deemed necessary, the working group will be rechartered based on the conclusions of the discussions. For NEMO Basic Support, the working group will assume that none of the nodes behind the MR will be aware of the network's mobility, thusmobility; thus, the network's movement needs to be completely transparent to the nodes inside the mobile network. This assumption will be made to accommodateaccommodates nodes inside the network that are not generally aware of mobility. The efforts of the Mobile IP working group have resulted in the Mobile IPv4 and Mobile IPv6 protocols, which have already solved the issue of host mobility support. Since challenges to enabling mobile networks are vastly reduced by this work, basic network mobility support will adopt the methods for host mobility support used in Mobile IP, and extend them in the simplest way possible to achieve its goals. The basic support solutionsolution, now defined in  following the requirements stated in Section 4 of the present document, is for each MR to have a Home Agent, and use bidirectionalbi-directional tunneling between the MR and HA to preserve session continuity while the MR moves. The MR will acquire a Care-of-address fromcare-of address at its attachment point much like what is done for mobile nodes (MN)(MN), using Mobile IP. This approach allows nested mobile networks, since each MR will appear to its attachment point as a single node. 3. NEMO Support Design Goals This section details the fundamental design goals the solutions will tendintend to achieve. Those design goals willserve to edict and understanddefine the issues and to impose a list of requirements definedfor forthcoming solutions. Actual requirements for NEMO Basic Support are in the next section, whereasSection 4; NEMO Extended Support hasis not yet been considered.considered at the time of this writing. 3.1 Migration Transparency A permanentPermanent connectivity to the Internet has to be provided to all MNNs whileMNNs, since continuous sessions are expected to be maintained as the mobile router changes its point of attachment. For doing so,maintaining those sessions, MNNs are expected to be reachable via their permanent IP addresses. 3.2 Performance Transparency and Seamless Mobility NEMO support is expected to be provided with limited signaling overhead and to minimize the impact of handover overhandovers on applications, in terms of packet loss or delay. However, although variable delays of transmission and losses between MNNs and their respective CNs could be perceived as the network is displaced, it would not be considered a lack of performance transparency. 3.3 Network Mobility Support Transparency MNNs behind the MR(s) don'tdo not change their own physical point of attachment as a result of the mobile network's displacement in the Internet topology. Consequently, NEMO support is expected to be performed byonly be the sole MR(s) and specificMR(s). Specific support functions on any other node than the MR(s) would better be avoided. 3.4 Operational Transparency NEMO support is to be implemented at the level of IP layer level.layer. It is expected to be transparent to upper layers so that any upper layer protocol can run unchanged on top of an IP layer extended with NEMO support. 3.5 Arbitrary Configurations The formation of a mobile network can existoccur in various levels of complexity. In the simplest case, a mobile network contains just a mobile router and a host. In the most complicated case, a mobile network is multihomed and is itself a multi-level aggregation of mobile networks with collectively thousands of mobile routers and hosts. While the list of potential configurations of mobile networks cannot be limited, at least the following configurationsones are desirable: o mobileMobile networks of any size, ranging from a sole subnet with a few IP devices to a collection of subnets with a large number of IP devices,devices. o nodesNodes that change their point of attachment within the mobile network,network. o foreignForeign mobile nodes that attach to the mobile network,network. o multihomedMultihomed mobile networknetwork: either when a single MR has multiple attachments to the internet, or when the mobile network is attached to the Internet by means of multiple MRs (see definition in  and the analysanalysis in ),). o nestedNested mobile networks (mobile networks attaching to other mobile networks (see definition in ). Although the complexity requirements of those nested networks is not clear, it is desirable to support arbitrary levels of recursive networks, andnetworks. The solution should only in the case whereimpose restrictions on nesting (e.g. path MTU) when this is impractical and protocol concerns preclude this support should the solution impose restrictions on nesting (e.g. path MTU),such support. o distinctDistinct mobility frequencies (see mobility factor in )). o distinctDistinct access medium.media. In order to keep complexity minimal, transit networks are excluded from this list. A transit network is one in which data would be forwarded between two endpoints outside of the network, so that the network itself simply serves as a transitional conduit for packet forwarding. A stub network (leaf network), on the other hand, does not serve as a data forwarding path. Data on a stub network is either sent by or addressed to a node located within that network. 3.6 Local Mobility and Global Mobility Mobile networks and mobile nodes owned by administrativelydifferent administrative entities are expected to be displaced within a domain boundary or between domain boundaries. Multihoming, vertical and horizontal handoffs, and access control mechanisms are desirable to achieve this goal. Such mobility typeis not expected to be limited for any consideration other than administrative and security policies. 3.7 Scalability NEMO support signaling and processing is expected to scale to a potentially large number of mobile networks irrespective of their configuration, mobility frequency, size and number of CNs. 3.8 Backward Compatibility NEMO support will have to co-exist with existingestablished IPv6 standards without interferingand not interfer with them. Standards defined in other IETF working groups have to be reused as much as possible and extended only if deemed necessary. For instance, the following mechanisms defined by other working groups are expected to function without modidications:modidication: o Address allocation and configuration mechanismsmechanisms. o Host mobility support: mobile nodes and correspondent nodes, either located within or outside the mobile networknetwork, are expected to keepcontinue operating protocols defined by the Mobile IP working group. This include mechanisms for host mobility support (Mobile IPv6) and seamless mobility (FMIPv6). o Multicast support entertained byintended for MNNs areis expected to be maintained while the mobile router changes its point of attachment. o Access control protocols and mechanisms used by visiting mobile hosts and routers to be authenticated and authorized to gainauthorized, gaining access to the Internet via the mobile network infrastructure (MRs). o Security protocols and mechanismsmechanisms. o Mechanisms performed by routers deployed bothin both the visited networks and in mobile networks (routing protocols, Neighbor Discovery, ICMP, Router Renumbering, ...).Renumbering). 3.9 Secure Signaling NEMO support will have to comply with the usual IETF security policies and recommendations and is expected to have its specific security issues fully addressed. In practice, all NEMO support control messages transmitted in the network will have to ensurebe protected with an acceptable level of security to prevent intruders to usurp identities and forge data. Specifically, the following issues have to be considered: o Authentication of the sender to prevent identity usurpation. o Authorization, to make sure the sender is granted permission to perform the operation as indicated in the control message. o Confidentiality of the data contained in the control message. 3.10 Location Privacy MeansLocation privacy means to hide the actual location of MNNS to third parties other than the HA are desired. InIt is not clear to which extend this has to be enforced is not clearenforced, since it is always possible to determine the topological location by analysing IPv6 headers. It would thus require some kind of encryption of the IPv6 header to prevent third parties to monitorfrom monitoring IPv6 addresses between the MR and the HA. On the other hand, it is at the very least desirable to provide a means for MNNs to hide their real topological location to their CNs. 3.11 IPv4 and NAT Traversal IPv4 clouds and NAT are likely to co-exist with IPv6 for a long time, so it is desirable to ensure mechanisms developpeddeveloped for NEMO will be able to traverse such clouds. 4. NEMO Basic Support One-Liner Requirements The NEMO WG is to specify a unified and unique "Network Mobility Basic Support" solution, hereafter referred to as "the solution". This solution is to allow all nodes in the mobile network to be reachable via permanent IP addresses, as well as maintain ongoing sessions as the MR changes its point of attachment to the Internet topology. This is to be done by maintaining a bidirectionalbi-directional tunnel between aan MR and its Home Agent. For doing so, theThe NEMO Working GroupGroup, after some investigation of alternatives, has decided to investigate reusingreuse the existing Mobile IPv6  mechanisms for thetunnel management, or extend it if deemed necessary. The list of requirements below havehas been placedimposed on the NEMO Basic Support solution. TheyThe requirements have beenmostly been met by the resulting specification which can now be found in . R01: The solution MUST be implemented at the IP layer level. R02: The solution MUST set up a bi-directional tunnel between a Mobile Router and its Home Agent (MRHA tunnel) R03: All traffic exchanged between aan MNN and a CN in the global Internet MUST transit through the bidirectionalbi-directional MRHA tunnel. R04: MNNs MUST be reachable at a permanent IP address and name. R05: The solution MUST maintain continuous sessions (both unicast and multicast) between MNNs and arbitrary CNs after IP handover of (one of) the MR. R06: The solution MUST not require modifications to any node other than MRs and HAs. R07: The solution MUST support fixed nodes, mobile hosts and mobile routers in the mobile network. R08: The solution MUST allow MIPv6-enabled MNNs to use a mobile network link as either a home link or a foreign link. R09: The solution MUST ensure backward compatibility with other standards defined by the IETF. This include particularly:In particular, this includes: R09:1: The solution MUST not prevent the proper operation of Mobile IPv6 (i.e. the solution MUST allow MIPv6-enabled MNNs to operate either the CN, HA, or MN operations defined in ) R10: The solution MUST treat all the potential configurations the same way (whatever the number of subnets, MNNs, nested levels of MRs, egress interfaces, ...)interfaces) R11: The solution MUST support at least 2 levels of nested mobile networks, while, in principle, arbitrary levels of recursive mobile networks SHOULD be supported. R12: The solution MUST function for multihomed MRMRs and multihomed mobile networks as defined in . R13: NEMO Support signaling over the bidirectionalbi-directional MUST be minimized R14: Signaling messages between the HA and the MR MUST be secured: R14.1: The receiver MUST be able to authenticate the sendersender. R14.2: The function performed by the sender MUST be authorized for the content carriedcarried. R14.3: Anti-replay MUST be providedprovided. R14.4: The signaling messages MAY be encryptedencrypted. R15: The solution MUST ensure transparent continuation of routing and management operations over the bi-directional tunnel (this includes e.g. unicast and multicast routing protocols, router renumbering, DHCPv6, etc)DHCPv6) R16: The solution MUST not impact on the routing fabric neither onWhen one egress interface fails, the Internet addressing architecture. [ACCORDING TO IETF56 minutes, SHOULD BE REMOVED] R18: Thesolution MAY preserve sessions established through another egress interface when one failsinterface. 5. Changes Between Versions 5.1 Changes between version -02 and -03 - Mostly cosmetic changes - Merged section Terminology into Introduction - Cross-references with other NEMO WG docs - Changed the introducionAcknowledgments The material presented in this document takes most of section Section 4its text from discussions and added referenceprevious documents submitted to the NEMO Basic Support's resulting specification. 5.2 Changes Between Version -01working group. This includes initial contributions from Motorola, INRIA, Ericsson and -02 - removed sub-items in R12 (sub-casesNokia. We are contained into the definition of multihoming) - minor typos - R15: Added "multicast" - R14.4: SHOULD softened to MAY according to discussion at IETF56th meeting. - R17 moved to R09 and contains former R09 as a sub-case. - R18: relaxed from "SHOULD" to may based on Vijay Devarapalli comment (030718) 5.3 Changes Between Version -00 and -01 - title of documents: included the word "goals" - entire document: some rewording - section 4: changed title of section to "NEMO Design Goals". - section 4: removed "MUST" and "MAY" - section 4: more text about location privacy - section 4: changed "Administration" paragraph to "Local and Global Mobility". Text enhanced. - section 5: R02: replace "between MR and MR's HA" with "a MR and its HA" R11: specified at least 2 levels R12: replaced "support" with "function" and add "multihomed MR" R13.x renumbered to R12.x since part of R12 (editing mistake) R13 and R18: new requirements proposed by editor and minor changes in the formulation of other Requirements 6. Acknowledgments The material presented in this document takes most of its text from discussions and previous documents submitted to the NEMO working group. This includes initial contributions from Motorola, INRIA, Ericsson and Nokia. We are particularly gratefulparticularly grateful to Hesham Soliman (Ericsson) and the IETF ADs at the time (Erik Nordmark and Thomas Narten) who highlygreatly helped to set up the NEMO working group. We are also grateful to all the following people whose comments highly contributed to the present document: TJT.J. Kniveton (Nokia), Alexandru Petrescu (Motorola), Christophe Janneteau (Motorola), Pascal Thubert (CISCO),(Cisco), Hong-Yon Lach (Motorola), Mattias Petterson (Ericsson) and all the others people who have expressed their opinions on the NEMO (formely MONET)mailing list.lists (formely known as MONET). Thierry Ernst wishwishes to personally grant support to itsacknowledge his previous employers, INRIA, and Motorola for their support and direction in bringing this topic up to the IETF,IETF -- particularly Claude Castelluccia (INRIA) and Hong-Yon Lach (Motorola). 76. References  Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.  Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", draft-ietf-nemo-basic-support-03 (work in progress), June 2004.RFC 3963, January 2005.  Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.  Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-02 (work in progress), October 2004.Internet-Draft draft-ietf-nemo-terminology-03, February 2005.  Ng, C-W.,C., Paik, E-K.E. and T. Ernst, "Analysis of Multihoming in Network Mobility Support", draft-ietf-nemo-multihoming-issues-01 (work in progress), October 2004.Internet-Draft draft-ietf-nemo-multihoming-issues-02, February 2005.  Thubert, P., Wakikawa, R. and V. Devarapalli, "NEMO Home Network Models", draft-ietf-nemo-home-network-models-01 (work in progress),Internet-Draft draft-ietf-nemo-home-network-models-01, October 2004.  Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)", IETF RFC 2460, December 1998.  Ernst, T. and K. Uehara, "Connecting Automobiles to the Internet", Proceedings 3rd International Workshop on ITS Telecommunications (ITST), November 2002.  "CALM - Medium and Long Range, High Speed, Air Interfaces parameters and protocols for broadcast, point to point, vehicle to vehicle, and vehicle to point communication in the ITS sector - Networking Protocol - Complementary Element", ISO Drat ISO/WD 21210, February 2005. Author's Address Thierry Ernst WIDE at Keio University Jun Murai Lab., Keio University. K-square Town Campus, 1488-8 Ogura, Saiwa-Ku Kawasaki, Kanagawa 212-0054 Japan Phone: +81-44-580-1600 Fax: +81-44-580-1437 EMail:Email: firstname.lastname@example.org URI: http://www.sfc.wide.ad.jp/~ernst/ Appendix A. Change Log From Earlier Versions The discussions behind the changes in the lattest versions of this documents are reflected in the "issue" web page: http://www.sfc.wide.ad.jp/~ernst/nemo/ A.1 Changes between version -03 and -04 - Issue B1: English brush up - Issue B2: Added a reference to  and  when speaking about usages. - Issue B3: The following paragraph from section 1 was partly removed; the remaining part was moved to section 2 and rephrased: "The mechanisms required for handling such mobility issues are currently lacking within the IETF standards. Traditional work conducted on mobility support (particularly in the Mobile IP working group) is to provide continuous Internet connectivity and optimal routing to mobile hosts only (host mobility support) and are unable to support network mobility. The NEMO working group has therefore been set up to deal with issues specific to network mobility. The purpose of this document is thus to detail the methodology that will be followed by the NEMO working group, its goals, and to define requirements for network mobility support." - Issue B4: Effectively removed former requirements about "impact on the routing fabric". A.2 Changes between version -02 and -03 - Mostly cosmetic changes - Merged section Terminology into Introduction - Cross-references with other NEMO WG docs - Changed the introducion of section Section 4 and added reference to NEMO Basic Support's resulting specification. A.3 Changes Between Version -01 and -02 - removed sub-items in R12 (sub-cases are contained into the definition of multihoming) - minor typos - R15: Added "multicast" - R14.4: SHOULD softened to MAY according to discussion at IETF56th meeting. - R17 moved to R09 and contains former R09 as a sub-case. - R18: relaxed from "SHOULD" to may based on Vijay Devarapalli comment (030718) A.4 Changes Between Version -00 and -01 - title of documents: included the word "goals" - entire document: some rewording - section 4: changed title of section to "NEMO Design Goals". - section 4: removed "MUST" and "MAY" - section 4: more text about location privacy - section 4: changed "Administration" paragraph to "Local and Global Mobility". Text enhanced. - section 5: R02: replace "between MR and MR's HA" with "an MR and its HA" R11: specified at least 2 levels R12: replaced "support" with "function" and add "multihomed MR" R13.x renumbered to R12.x since part of R12 (editing mistake) R13 and R18: new requirements proposed by editor and minor changes in the formulation of other Requirements Intellectual Property Statement 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. 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. Copyright Statement Copyright (C) The Internet Society (2004).(2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.