MIP4 Nobuo Ogashiwa(INTEC Netcore) Internet-Draft Kenichi Nagami(INTEC Netcore) Expires: January 1, 2006 Ikuo Nakagawa(INTEC Netcore) Satoshi Uda (JAIST) Ryuji Wakikawa(Keio Univ.) Hiroshi Esaki(Univ. Tokyo) Hiroyuki Ohnishi(NTT) Jul 1, 2005 Binding Identifier Extension for Mobile IPv4 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 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 January 1, 2006. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document specifies a new extension for Registration Request message and Registration Reply message in Mobile IPv4. This extension can be added by mobile mode and home agent to Registration Request and Registration Reply messages. This extension carries an identification of binding of a care-of address. Ogashiwa, et al. Expires January 1, 2006 [Page 1] Internet-Draft BID Extension for MIP4 Jul 2005 1. Introduction According to the current MIP4 specification, mobile node can register multiple care-of addresses (CoA) to home agent. This can be done by setting simultaneous binding bit ('s' bit) of Registration Request message. This implies that the current MIP4 specification is applicable to multi-homing. The MIP4 specification document [RFC3344] also describes home agent's behavior as follows: "When the home agent allows simultaneous bindings, it will tunnel a separate copy of each arriving datagram to each care-of address, and the mobile node will receive multiple copies of datagrams destined to it." In multi-homing environment, mobile node and home agent can use multiple links efficiently by dividing or limiting flows or traffic for each tunnel using additional systems implemented on home agent and mobile node. However, home agent can not divide or limit flows to appropriate tunnels without binding information of CoA and network interface of mobile node. This document specifies a new extension for use in Mobile IPv4. This extension can be added by mobile node and home agent to Registration Request and Registration Reply messages. This extension carries an identification of binding of care-of address of the mobile node. By using this extension, mobile node can inform binding of coa and network interface of mobile node. Furthermore, by using this extension, mobile node can modify specific care-of address previously registered by single Registration Request even if the home agent has several care-of address registration for the mobile node. This specification does not require any changes to deployed MIP4 implementations and the current MIP4 specification. Home Agent and Mobile Node that does not support this extension can silently discard messages which includes this extension. 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Ogashiwa, et al. Expires January 1, 2006 [Page 2] Internet-Draft BID Extension for MIP4 Jul 2005 3. Motivation 3.1 Multihoming Using Multiple Physical Links As mentioned above, home agent and mobile node can use multiple links efficiently by using additional system since each links has different characteristics. For example, a user requires to use low-latency link for latency-sensitive application such as VoIP and use other links for other applications. In such situation, home agent have to know bindings of care-of address and mobile node's network interface due to split downstream traffic to appropriate tunnels. The mobile node can inform own binding of care-of address and network interface by using Multiple Care-of Address Extension proposed in this document. The discussion of the system to divide or limit user traffic to multiple tunnels is out of scope of this document. The figure 1 and following configurations are example of use of Multiple Care-of Address Extension. The BID which is assigned to the binding carried in the Registration Request and Registration Reply. In a mobile node, each network interfaces have one or more BID. i/f-1(BID1,low-latency, 32kbps) +----------------+ +-++ +----+---+ +--+ |MN| |Internet+-----+HA| +-++ +----+---+ +--+ +----------------+ i/f-2(BID2, high-latency 54Mbps) Fig.1 Example Network The MN and the HA's configuration is following: Home Agent's Configuration: MN, BID1, VoIP traffic MN, BID2, other traffic Mobile Node's Configuration: i/f-1, BID1 i/f-2, BID2 The MN acquires CoA1 and CoA2 for i/f-1 and i/f-2, then the MN send registration request messages to the HA, which include BIDs for each interfaces. After that, HA's registration database becomes as following: Home Agent's Registration Database: HoA, CoA1, BID1 HoA, CoA2, BID2 Ogashiwa, et al. Expires January 1, 2006 [Page 3] Internet-Draft BID Extension for MIP4 Jul 2005 The HA knows the bindings of BID and CoA of the MN as above database. The HA also knows appropriate filter rules bound to each BIDs due to the HA's configuration so that the HA can apply filter rules to HA's tunnel interfaces. 3.2 CoA Modification by Single Registration Request The current MIP4 specification [RFC3344] doesn't define the operation to modify a CoA previously registered to home agent. In case of that the 'S' bit doesn't set, the distinct definition of the modify operation is needless since the CoA registration will be overrided by new one. In case of the 'S' bit set and several CoAs are registered to the home agent, mobile node have to register a new CoA, and then deregister the old CoA since the modify operation is not defined. When the mobile node modify the CoA previously registered to the home agent by single operation, the home agent can keep communication between the mobile node and correspondent node. However, when the mobile node modify the CoA previously registered to the home agent by multiple operation such as deregister old one and register new one, the home agent cannot keep communication between the mobile node and correspondent node. When the number of CoA reach maximum limit, mobile node cannot register new CoA. To avoid this, if the mobile node deregister old CoA before register new CoA, mobile node and correspondent node can not keep communication. If mobile node can change CoA registered to the home agent by single operation, home agent will be able to modify the mobile node's CoA entry in own CoA database keeping communication between mobile node and correspondent node. Ogashiwa, et al. Expires January 1, 2006 [Page 4] Internet-Draft BID Extension for MIP4 Jul 2005 4. Mobile IPv4 Multiple Care-of Address Extension The format of the Multiple Care-of Address Extension is simple extension structure defined in MIP4 specification [RFC3344]. This extension is not skippable. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length = 2 | Binding Unique ID (BID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type value for Binding Unique Identifier will be assigned later. An 8-bit identifier of the option. Length The value MUST be always 2. Binding Unique ID (BID) The BID which is assigned to the binding carried in the Registration Request and Registration Reply. BID is 16-bit unsigned integer. A value of zero is reserved. 5. Use of the Multiple Care-of Address Extension 5.1 Changes to current MIP4 specification No changes is requiered for deployed implementations and current MIP4 basic specification. Home Agent and Mobile Node that doesn't support the Multiple Care-of Address Extension MAY silently discard messages which include the Multiple Care-of Address Extension or alternatively, Home Agent MAY return error code 128 ("reason unspecified") defined in MIP4 specification [RFC3344]. Ogashiwa, et al. Expires January 1, 2006 [Page 5] Internet-Draft BID Extension for MIP4 Jul 2005 5.2 Home Agent and Mobile Node's behavior Following is mobile node's and home agent's behavior when they send or receive Registration Request and Registration Reply. mobile node: o statically or dinamically decide binding unique indentifier per mobile node's network interfaces or bindings. o when send registration request, attach BID to the message using Multiple Care-of Address Extension. o when change specific CoA previously registered, send registration request which include new CoA and appropriate BID. home agent: o when receive registration request which includes Multiple Care-of Address Extension, if the home agent doesn't support the extension, then return error code or, alternatively silently discard the message. o if home agent already know the BID then override old CoA by new CoA. And then, home agent send registration reply message which include Multiple Care-of Address Extension. o if home agent doesn't know the BID then store the CoA and BID into own database. And then, home agent send registration reply message which include Multiple Care-of Address Extension. When the Multiple Care-of Address Extension is added, the simulutaneous binding bit should be set. If the simulutaneous binding bit is not set, home agent and mobile node should ignore the Multiple Care-of Address Extension and should act as traditional home agent and mobile node described in the MIP4 specification [RFC3344]. 6. Security considerations This draft does not raise specific security issues beyond those of existing Mobile IP protocols. 7. IANA Considerations This specification reserves one number for the Multiple Care-of Address Extension Section 3 from the space of numbers for non-skippable mobility extensions defined for Mobile IPv4 [MIP4] at http://www.iana.org/assignments/mobileip-numbers. The value 50 is recommended for this extension. References [MIP4] C. Perkins, Ed. "IP Mobility Support for IPv4", Ogashiwa, et al. Expires January 1, 2006 [Page 6] Internet-Draft BID Extension for MIP4 Jul 2005 RFC 3344, August 2002. Author's Addresses Nobuo Ogashiwa INTEC NetCore Inc. 1-3-3, Shin-suna, Koto-ku, Tokyo, 135-0075, Japan Email: ogashiwa@inetcore.com Kenichi Nagami INTEC NetCore Inc. 1-3-3, Shin-suna, Koto-ku, Tokyo, 135-0075, Japan Email: nagami@inetcore.com Ikuo Nakagawa INTEC NetCore Inc. 1-3-3, Shin-suna, Koto-ku, Tokyo, 135-0075, Japan Email: ikuo@inetcore.com Satoshi Uda School of Information Science Japan Advanced Institute of Science and Technology 1-1 Asahidai, Tatsunokuchi, Ishikawa, 923-1292, Japan Email: zin@jaist.ac.jp Hiroshi Esaki Graduate School of Information Science and Technology, The university of Tokyo 7-3-1 Hongo, Bunkyo-ku, Tokyo, 113-8656, Japan Email: hiroshi@wide.ad.jp Ryuji Wakikawa Keio University and WIDE 5322 Endo Fujisawa Kanagawa, 252-8520, Japan Email: ryuji@sfc.wide.ad.jp Hiroyuki Ohnishi NTT Network Service Systems Laboratories, NTT Corporation 9-11, Midori-Cho, 3-Chome Musashino-Shi, Tokyo 180-8585, Japan Email: ohnishi.hiroyuki@lab.ntt.co.jp 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. Ogashiwa, et al. Expires January 1, 2006 [Page 7] Internet-Draft BID Extension for MIP4 Jul 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. 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 (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. Ogashiwa, et al. Expires January 1, 2006 [Page 8]