NEMO Working Group P. Valitalo Internet-Draft VTT Electronics Expires: September 8, 2005 March 8, 2005 Multihoming of (1,1,*) configured networks in Network Mobility Support draft-valitalo-nemo-multihoming-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I 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/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 8, 2005. Copyright Notice Copyright (c) The Internet Society (2005). Abstract This draft describes, how NEMO support works with multiple care-of addresses, in a multihomed mobile network, when there exists one home agent, one mobile router, and one or more mobile network prefixes. Solution to the problem, how to register multiple care-of addresses bound to a single home address in a NEMO support, is proposed. Valitalo Expires September 8, 2005 [Page 1] Internet-Draft (1,1,*) Multihoming in NEMO March 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. (1,1,*) Configuration . . . . . . . . . . . . . . . . . . . . . . 3 3. Problems in the configuration . . . . . . . . . . . . . . . . . . 3 4. Proposed solution . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Binding Update . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2 Binding Acknowledgement . . . . . . . . . . . . . . . . . . . 5 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction When the mobile network has more than one point of attachment to the Internet, mobile network is called being multihomed. Multihoming situations can occur when the mobile network has multiple Mobile Routers, mobile network is associated with multiple Home Agents, or when the Mobile Router has multiple egress interfaces. In this document, potential problem in a system, which uses NEMO Support [1], with one Home Agent, one Mobile Router and one or more prefixes (1,1,* configuration) is described, and a solution is proposed to the problem. When the Mobile Router is away from home and has more than one egress interface (for example, more than one connection to the Internet), there may occur a problem with care-of addresses: In Mobile IPv6 specification [2], it is denied to register more than one care-of address to the home address in the Home Agent's Binding Cache (BC). A solution to this problem has been proposed in [3], which extends the Mobile IPv6 protocol by adding a Binding Unique Identifier (BID) to the binding cache entry to allow the registration of multiple care-of addresses (mCoA) bound to a single home address. When the Mobile Router wants to register multiple care-of addresses to the Home Agent, it sends first a Binding Update (BU) to the Home Agent, registering the primary care-of address first, with BID number set. If the primary care-of address registration is successful, the Mobile Router can register the rest of the care-of addresses. The BID number is used to identify the BC entry later, in cases that multiple care-of addresses can't be registered with a single BU, instead, every care-of address registration requires own BU message. Valitalo Expires September 8, 2005 [Page 2] Internet-Draft (1,1,*) Multihoming in NEMO March 2005 2. (1,1,*) Configuration The Mobile Router has multiple egress interfaces, which are connected to the Internet. There exists only one Home Agent. The mobile network has one or more mobile network prefixes, which are advertised to the ingress interface by the Mobile Router. +----+ p1 CoA1 +----+ +----------+ | MN |---+ +----+ +---| AR |---| | +----+ +----+ +---| |---+ +----+ | | | | | MR | | Internet |---| HA | +----+ +---| |---+ +----+ | | | | | MN |---+ +----+ +---| AR |---| | +----+ +----+ p2 CoA2 +----+ +----------+ Figure 1. (1,1,N) configuration of the NEMO network. 3. Problems in the configuration In [4] and [5], potential problems with multihoming configurations have been analysed. The usage possibility of BID has been recognized, but there is not further implementations where the BID is in use. For example, if the Mobile Router has 3 different egress interfaces to the Internet, after binding update process, the binding cache at the Home Agent could look like following, if the care-of addresses are bound to a single home address: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HoA-1 | CoA-1 | | | CoA-2 | | | CoA-3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HoA-1 = Mobile Router's home address CoA-x = Mobile Router's care-of address x In [3], at chapter 5.2, it is stated that: o "Note that there is no optimization such as registering multiple care-of addresses by using a single Binding Update, because the current Mobile IPv6 specification does not allow to send multiple bindings by means of a single Binding Update" Thus, in a case of registering multiple care-of addresses belonging to the same home address, multiple Binding Update messages has to be send from the Mobile Router to the Home Agent. Valitalo Expires September 8, 2005 [Page 3] Internet-Draft (1,1,*) Multihoming in NEMO March 2005 Problem is at the Binding Update message structure. Currently, in NEMO support, the flags and their order at the Binding Update message are defined as |A|H|L|K|M|R|, as seen below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Flags A, H, L, and K are defined by the MIPv6 specification [2]. The M-flag is used for Mobility Anchor Point (MAP) registration purposes, defined at HMIPv6 specification [6]. The R-flag is called as "Mobile Router Flag", and is set to inform the Home Agent, if the Binding Update message comes from the Mobile Router. R-flag is defined at NEMO support. In [3], a modification to the Binding Update message is proposed. To enable the BID usage in the Binding Update messages, a new flag has been defined, called as "Multiple Care-of Addresses Flag" and is defined as "M". The flag is used to inform the recipient (Home Agent or Corresponding Node) about the presence of the BID information. The mCoA specification [3] defines the flag order in the Binding Update as |A|H|L|K|R|M|, as seen below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|R|M| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the Binding Update flag order is compared to the order defined in NEMO support [1], a couple of problems occur. The M-flag is defined twice (in [3] and [6]), with different definitions, and the placement of the flags is different. Valitalo Expires September 8, 2005 [Page 4] Internet-Draft (1,1,*) Multihoming in NEMO March 2005 In the Binding Acknowledgement message structure, no flag modifications are needed, because the mCoA specification [3] does not define any new flags. However, new status code is required. MIPv6 specification [2] defines status codes 0, 1, 128-139. NEMO support [1] defines status codes 140-143. The mCoA specification [3] defines status code 140, so it should be renumbered. 4. Proposed solution 4.1 Binding Update Multiple care-of addresses flag is renamed and its position is changed in the Binding Update. Flag is renamed from 'M' to 'B', and moved to the rightmost position. Rest of the flags remain same as listed in [1]. The redefined message structure is below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|B| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Multiple care-of addresses flag (B) This flag is used for multiple care-of addresses registration. 4.2 Binding Acknowledgement Status code 140, "Binding Conflict", which is proposed at mCoA specification, is renumbered to 144. Thus, the status codes defined at [1] remain same. 140 Mobile Router Operation not permitted 141 Invalid Prefix 142 Not Authorized for Prefix 143 Forwarding Setup failed 144 Binding Conflict Valitalo Expires September 8, 2005 [Page 5] Internet-Draft (1,1,*) Multihoming in NEMO March 2005 5. References [1] V. Devarapalli et. al. "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [2] D. Johnson, C. Perkins, J. Arkko. "Mobility Support in IPv6", RFC 3775, June 2004. [3] R. Wakikawa, K. Uehara, T. Ernst, K. Nagami. "Multiple Care-of Addresses Registration", Internet Draft, draft-wakikawa-mobileip-multiplecoa-03 (work in progress), June 2004. [4] C. Ng, E. Paik, T. Ernst. "Analysis of Multihoming in Network Mobility Support", Internet Draft, draft-ietf-nemo-multihoming-issues-02 (work in progress), February 2005. [5] N. Montavont et. al. "Analysis of Multihoming in Mobile IPv6", Internet Draft, draft-montavont-mobileip-multihoming-pb-statement-03 (work in progress), January 2005. [6] H. Soliman, C. Catelluccia, K. El Maki, L. Bellier. "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", Internet Draft, draft-ietf-mipshop-hmipv6-04 (work in progress), December 2004. Author's Address Pekka Valitalo VTT Electronics Kaitovayla 1 90571 Oulu Finland E-Mail: pekka.valitalo@vtt.fi 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. Valitalo Expires September 8, 2005 [Page 6] Internet-Draft (1,1,*) Multihoming in NEMO March 2005 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. Copyright Statement Copyright (C) The Internet Society (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. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.