RFC 4908

Multi-homing for small scale fixed network Using Mobile IP and NEMO

📅 published June 2007, from ietf

RFC 4908 🦋 Multihoming for Small-Scale Fixed Networks Using Mobile IP and Network Mobility (NEMO)

okay bestie, this one is an Experimental RFC from June 2007 💖 Here's the title block:

  • RFC number: 4908
  • Title: Multihoming for Small-Scale Fixed Networks Using Mobile IP and Network Mobility (NEMO)
  • Authors: K. Nagami (INTEC NetCore), S. Uda (JAIST), N. Ogashiwa (NOWARE, Inc.), H. Esaki (University of Tokyo), R. Wakikawa (Keio University), H. Ohnishi (NTT)
  • Category: Experimental
  • Date: June 2007
  • Obsoletes/Updates: the header doesn't list anything it obsoletes or updates ✨

Status of This Memo 📜

this memo defines an Experimental Protocol for the Internet community. it's not an Internet standard of any kind, and they're asking for discussion and suggestions for improvement 🫶 distribution of this memo is unlimited.

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 it notes that the decision to publish wasn't based on IETF review for things like security, congestion control, or inappropriate interaction with deployed protocols. the RFC Editor chose to publish this at its discretion, so readers should be careful when evaluating it for implementation and deployment. see RFC 3932 for more information.

Abstract 🌸

multihoming makes host and network connectivity more available, which is iconic 👑 fixed and mobile networks behave differently, so people have proposed separate architectures for each. this document proposes one common architecture that works for both mobile and fixed environments, built on mobile IP (RFC 3775) and Network Mobility (NEMO; RFC 3963). the architecture needs changes to mobile IP and NEMO so that multiple Care-of Addresses (CoAs) can be used. on top of that, multiple Home Agents (HAs) in different places are required for redundancy 💅

1. Motivation ✨

people running small-scale networks need an easy way to improve network availability and to load balance across several links 🥺 multihoming is one of the solutions for availability. the big conventional multihoming networks use BGP, but BGP has some issues, so this document proposes a multihoming architecture using mobile IP [1] and NEMO [2] for small-scale fixed networks 🎀

1.1. General Benefits of Multihoming 💜

in a multihoming network, both users and network managers can benefit from controlling outgoing traffic, incoming traffic, or both 🧚 those benefits are described in "Goals and Benefits of Multihoming" [3]. here's the quick summary:

  • Ubiquitous Access
  • Redundancy/Fault-Recovery
  • Load Sharing
  • Load Balancing
  • Bi-casting
  • Preference Settings

1.2. Problems to be Solved to Accomplish Multihoming 😤

several multihoming technologies have been proposed so far. the big conventional multihoming networks use BGP, but it has some issues, as follows:

(1) Increasing route entries in the Internet

okay this one is giving chaos 💀 in multihoming setups, each user's network has to advertise its address block to all the ISPs it connects to. if a multihomed user connects to only one ISP, that ISP can advertise routing information in an aggregated way. but some multihomed users connect to different ISPs so they're ready if one ISP fails. in that case, ISPs have to advertise routing information for multihomed users without aggregation. so the number of routing entries in the Internet keeps going up, one by one 📈

(2) Difficulty of using multiple links efficiently

controlling incoming traffic is not easy with the conventional BGP multihoming architecture. so load balancing across connected links is difficult 🙈

1.3. Using the Architecture of Mobile IP and NEMO to Solve the Problems 🧠

mobile IP (MIP) and NEMO were basically proposed for mobile hosts or mobile networks. however, their architecture and protocol can also be used for fixed networks and to solve the problems above 🔥 the details of the solution are in the sections below.

also, using the architecture and protocol of MIP and NEMO will decrease the cost of network operation. for example, with MIP and NEMO, renumbering IP addresses when office or network equipment gets relocated becomes unnecessary. that's because the network address prefix a user network uses in a mobile IP environment doesn't depend on the upstream ISP's network prefix 🎀✨

2. Multihoming Architecture Using Mobile IP and NEMO 🦋

2.1. Mobile Network Includes Fixed Network 🌈

NEMO and mobile IP have to work with multihoming by their nature 🫶 mobile nodes need multiple links to improve network connectivity availability, because the wireless link isn't always stable. so this document proposes that multihoming for fixed nodes (routers and hosts) uses the framework of NEMO and mobile IP 💅

2.2. Overview of Multihoming Network Architecture Using Mobile IP 🛰️

Figure 1 shows the basic multihoming network architecture 👀 in this setup, a mobile router (MR), which is a border router of the multihomed network, sets up several tunnels between the MR and the HA through multiple-CoA registration. an HA (or a router that the HA belongs to) advertises the user's network prefix (Prefix X in Figure 1) to ISPs through 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. so the Internet routing entries don't go up one by one as the number of multihomed users grows 🍓

                                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 them to the MR using CoA1 and CoA2 📦 the HA picks a route in which a CoA is used. the route selection algorithm is out of scope for this document 🙅‍♀️ this can improve the availability of the user network and control the traffic going from the ISP to the MR. in the basic architecture, HA1 is the single point of failure 😭 to improve the availability of the user network, multiple HAs are needed. that's covered 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

3. Requirements for Mobile IP and NEMO 🎀

3.1. Multiple Care-of-Addresses (CoAs) 🧁

multiple Care-of-Addresses are needed to improve availability and to control incoming and outgoing traffic 💖 the current Mobile IPv6 and NEMO Basic Support protocol doesn't let you register more than one Care-of Address bound to a home address with the home agent 😩 so [4] proposes extending MIP6 and NEMO Basic Support to allow multiple Care-of Address registrations for a particular home address ✨

4.1. Why the Proposed Architecture Uses NEMO Protocols 🦋

okay so the multihomed architecture in this doc is basically the same as the architecture of NEMO 💅 and NEMO protocols meet every requirement this architecture needs, which are:

  • The protocol can be used by the MR to send information such as the CoA, Home Address (HoA), and Binding Unique Identifier (BID) [4] to the HA.
  • The protocol can establish multiple tunnels between the MR and HA.
  • 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 for building this multihome architecture. Another option is to propose a brand-new protocol just like NEMO. Honestly though, that new protocol would end up with functions just like NEMO's anyway 🙈

4.2. Route Announcement from Geographically Distributed Multiple HAs ✨

bestie, this part is so cool 🌈 The architecture brings in the xSP (Multihomed Service Provider). The xSP is a conceptual service provider, so it doesn't have to be physically connected to the Internet for all practical purposes. The xSP has one or more aggregatable mobile network prefixes, and it contracts with some ISPs that are physically connected to the Internet. The point of that contract is to set up some HAs in those ISPs' networks. Those HAs announce the xSP's aggregated mobile network prefixes. So the HAs work just like border gateway routers, and the whole situation is the same as peering between the ISP and the xSP. In this case, the origin Autonomous System (AS) announced from the HAs is the xSP 👑

Now on the other side, a multihomed user (a small office user or home user) contracts with the xSP to get a mobile network prefix from it. Each multihomed user has an MR and multiple L3 connectivity to the Internet via multiple ISPs, and the MR will establish multiple tunnels to the HA. Since the user's mobile network prefixes are aggregated and announced from the HA, packets headed to the user's mobile network get sent to the nearest HA, depending on global routing information at that time 🧚 The HA that received those packets then forwards them to the user's network over the established multiple tunnels.

This model of route announcement from multiple HAs is compatible with the conventional scalable Internet architecture, and it doesn't have scalability problems. Literally iconic 💖

5. Implementation and Experimentation 🧪

We have implemented and experimented with the proposed architecture, and the vibes are good 🔥 Currently, the system works well not only on our test-bed network, but on the Internet too. In our experimentation, the MR has two upstream organizations (ISPs) and two Care-of Addresses for each organization. The MR uses the multiple-CoA option to register the Care-of Addresses to the HA.

6. Security Considerations 🔐

Okay, this section is serious, so listen up 💀 This document describes requirements of multiple CoAs and HAs for redundancy. It is necessary to enhance the protocols of MIP and NEMO to solve those requirements. Security considerations of these multihoming networks must be considered in a specification of each protocol. Don't skip this part, bestie 🫶

7. References 📚

7.1. Normative References

[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.

[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.

7.2. Informative References

[3] 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.

[4] Wakikawa, R., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", Work in Progress, March 2007.

[5] Wakikawa, R., Thubert, P., and V. Devarapalli, "Inter Home Agents Protocol (HAHA)", Work in Progress, February 2004.

Authors' Addresses 💌

Kenichi Nagami
INTEC NetCore Inc.
1-3-3, Shin-suna
Koto-ku, Tokyo  135-0075
Japan

Phone: +81-3-5565-5069
Fax:   +81-3-5565-5094
EMail: nagami@inetcore.com
Satoshi Uda
Japan Advanced Institute of Science and Technology
1-1 Asahidai
Nomi, Ishikawa  923-1292
Japan

EMail: zin@jaist.ac.jp
Nobuo Ogashiwa
Network Oriented Software Institute, Inc.
190-2, Yoshii,
Yoshii, Tano, Gunma 370-2132
Japan

EMail: ogashiwa@noware.co.jp
Hiroshi Esaki
The University of Tokyo
7-3-1 Hongo
Bunkyo-ku, Tokyo  113-8656
Japan

EMail: hiroshi@wide.ad.jp
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: ryuji@sfc.wide.ad.jp
URI:   http://www.wakikawa.org/
Hiroyuki Ohnishi
NTT Corporation
9-11, Midori-Cho, 3-Chome
Musashino-Shi, Tokyo  180-8585
Japan

EMail: ohnishi.hiroyuki@lab.ntt.co.jp

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 ietf-ipr@ietf.org.

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society.

📦 where this page comes from