Network Working Group K. Nagami Request for Comments: 4908 INTEC NetCore Category: Experimental S. Uda JAIST N. Ogashiwa NOWARE, Inc. H. Esaki University of Tokyo R. Wakikawa Keio University H. Ohnishi NTT June 2007 Multihoming for Small-Scale Fixed Networks Using Mobile IP and Network Mobility (NEMO) Status of This Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). IETF Note This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
AbstractMultihoming technology improves the availability of host and network connectivity. Since the behaviors of fixed and mobile networks differ, distinct architectures for each have been discussed and proposed. This document proposes a common architecture for both mobile and fixed networking environments, using mobile IP (RFC 3775) and Network Mobility (NEMO; RFC 3963). The proposed architecture requires a modification of mobile IP and NEMO so that multiple Care- of Addresses (CoAs) can be used. In addition, multiple Home Agents (HAs) that are located in different places are required for redundancy. 1] and NEMO  for small-scale fixed networks. 3]. The following is a summary of those goals and benefits: o Ubiquitous Access o Redundancy/Fault-Recovery o Load Sharing o Load Balancing o Bi-casting o Preference Settings
(1) Increasing route entries in the Internet In the multihoming environments, each user's network needs to advertise its address block to all ISPs connected to them. If a multihomed user connects to only one ISP, the ISP can advertise routing information to aggregate them. But some multihomed users need to connect with different ISPs to be prepared for ISP failure. In this case, ISPs need to advertise routing information for multihomed users without aggregation. Therefore, the number of routing entries in the Internet is increasing one by one. (2) Difficulty of using multiple links efficiently It is not easy to control incoming traffic in the case of the conventional multihoming architecture using BGP. Therefore, load balancing of connected links is difficult. Figure 1 shows the basic multihoming network architecture. In this architecture, a mobile router (MR), which is a border router of the multihomed network, sets up several tunnels between the MR and the HA by multiple-CoA registration. An HA (or a router to which the HA
belongs) advertises the user's network prefix (Prefix X in Figure 1) to ISPs via the routing protocol. If the HA has several multihomed networks (Prefix X and Y in Figure 1), they can advertise an aggregated network prefix to ISPs. Therefore, the Internet routing entries do not increase one by one when the number of multihomed users is increased. HA1 ||(Advertise aggregated prefix X and Y) |v ISP | +------------------------+---------------------+ | The Internet | +-+----------+--------------------+----------+-+ | | | | ISP-A ISP-B ISP-A' ISP-B' | | | | | | | | +--- MR ---+ +--- MR ---+ CoA1 | CoA2 CoA1|CoA2 | | -------+--------- (Prefix X) -------+------ (Prefix Y) Multihomed Network X Multihomed Network Y Figure 1: Advertisement of aggregated prefixes Packets to multihomed users go to the HA, and the HA sends packets to the MR using CoA1 and CoA2. The HA selects a route in which a CoA is used. The route selection algorithm is out for scope of this document. This can improve the availability of the user network and control traffic going from the ISP to the MR. In the basic architecture, HA1 is the single point of failure. In order to improve the availability of the user network, multiple HAs are needed. This is described in Section 3.2.
HA1 ^ | | (1) Packets to prefix X | | | (2) HA forwards the packets are sent to HA | | v to CoA1 or CoA2 +-------+------+ | The Internet | +-+----------+-+ | | | | |(3) Packets are forwarded over | | | the MIP tunnel selected by | | v the HA1 ISP-A ISP-B | | | | | | +--- MR ---+ v CoA1 | CoA2 | -------+--------- (Prefix X) Multihomed Network A Figure 2: Packet Forwarding by HA 4] proposes to extend MIP6 and NEMO Basic Support to allow multiple Care-of Address registrations for the particular home address.
In order to operate multiple HAs, all HAs must have the same information such as binding information. This synchronizes the databases among the HAs. The HAHA protocol  introduces the binding synchronization among HAs. This is the same architecture as Internal BGP (IBGP). The database is synchronized by full-mesh topology. In addition, in order to simplify operation of the HA, the database is synchronized using star topology. This is analogous to the IBGP route reflector. sync HA1 ------ HA2 | | +-+----------+-+ | The Internet | +-+----------+-+ | | ISP-A ISP-B | | | | +--- MR ---+ CoA1 | CoA2 | -------+--------- Multihomed Network Figure 3: Architecture with HA Redundancy 4] to the HA. o The protocol can establish multiple tunnels between the MR and HA. o The protocol supports multiple HAs and can synchronize Binding Caches among multiple HAs. The proposed multihomed architecture uses NEMO protocols as one of the applications of NEMO. Needless to say, using the NEMO protocol is one of the solutions to accomplish the proposed multihome
architecture. Another solution is to propose a new protocol just like NEMO. Nevertheless, such a protocol would have functions just like those of NEMO.
 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", RFC 3963, January 2005.  Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C., Kuladinithi, K., and T. Noel, "Goals and Benefits of Multihoming", Work in Progress, February 2004.  Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", Work in Progress, March 2007.  Wakikawa, R., Thubert, P., and V. Devarapalli, "Inter Home Agents Protocol (HAHA)", Work in Progress, February 2004.
Satoshi Uda Japan Advanced Institute of Science and Technology 1-1 Asahidai Nomi, Ishikawa 923-1292 Japan EMail: firstname.lastname@example.org Nobuo Ogashiwa Network Oriented Software Institute, Inc. 190-2, Yoshii, Yoshii, Tano, Gunma 370-2132 Japan EMail: email@example.com Hiroshi Esaki The University of Tokyo 7-3-1 Hongo Bunkyo-ku, Tokyo 113-8656 Japan EMail: firstname.lastname@example.org Ryuji Wakikawa Keio University Department of Environmental Information, Keio University. 5322 Endo Fujisawa, Kanagawa 252-8520 Japan Phone: +81-466-49-1100 Fax: +81-466-49-1395 EMail: email@example.com URI: http://www.wakikawa.org/ Hiroyuki Ohnishi NTT Corporation 9-11, Midori-Cho, 3-Chome Musashino-Shi, Tokyo 180-8585 Japan EMail: firstname.lastname@example.org
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, 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 email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.