From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4908.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc4908.txt (limited to 'doc/rfc/rfc4908.txt') diff --git a/doc/rfc/rfc4908.txt b/doc/rfc/rfc4908.txt new file mode 100644 index 0000000..5cf1e5d --- /dev/null +++ b/doc/rfc/rfc4908.txt @@ -0,0 +1,563 @@ + + + + + + +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. + + + + + + + + + + + + +Nagami, et al. Experimental [Page 1] + +RFC 4908 Multihoming for Fixed Network June 2007 + + +Abstract + + Multihoming 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. Motivation + + Users of small-scale networks need an easy method to improve network + availability and to load balance several links. Multihoming + technology is one of the solutions to improve availability. + Conventional major multihoming networks use BGP, but it has some + issues. Therefore, we propose 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 environment, both users and network managers + benefit from controlling outgoing traffic, incoming traffic, or both + of them. Those benefits are described in "Goals and Benefits of + Multihoming" [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.2. Problems to be Solved to Accomplish Multihoming + + Several multihoming technologies have been proposed so far. + Conventional major multihoming networks use BGP, but it has some + issues, as follows. + + + + +Nagami, et al. Experimental [Page 2] + +RFC 4908 Multihoming for Fixed Network June 2007 + + + (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. + +1.3. Using the Architecture of Mobile IP and NEMO to Solve the Problems + + Basically, mobile IP (MIP) and NEMO have been proposed for mobile + hosts or mobile networks; however, their architecture and protocol + can be used for fixed networks and to solve the problems mentioned + above. The details of the solution are described in the sections + below. + + Moreover, by using the architecture and the protocol of MIP and the + NEMO, the cost of network operation will be decreased. For instance, + in the architecture of MIP and NEMO, renumbering IP addresses when + office or network equipment is relocated becomes unnecessary, as the + network address prefix used by a user network in a mobile IP + environment does not depend on the upstream ISP's network prefix. + +2. Multihoming Architecture Using Mobile IP and NEMO + +2.1. Mobile Network Includes Fixed Network + + By their nature, NEMO and mobile IP must work with multihoming. This + is because mobile nodes need to use multiple links to improve the + availability of network connectivity since the wireless link is not + always stable. Therefore, we propose 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 + 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 + + + +Nagami, et al. Experimental [Page 3] + +RFC 4908 Multihoming for Fixed Network June 2007 + + + 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. + + + + + + + + + + + + + + + + +Nagami, et al. Experimental [Page 4] + +RFC 4908 Multihoming for Fixed Network June 2007 + + + 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 the availability and + to control incoming and outgoing traffic. The current Mobile IPv6 + and the NEMO Basic Support protocol does not allow registration of + more than one Care-of Address bound to a home address to the home + agent. Therefore, [4] proposes to extend MIP6 and NEMO Basic Support + to allow multiple Care-of Address registrations for the particular + home address. + +3.2. Multiple Home Agents + + Multiple Home Agents should be geographically distributed across the + Internet to improve service availability and for the load balancing + of the HA. When all the networks that have HA advertise the same + network prefix to their adjacent router/network, the traffic is + automatically routed to the nearest Home Agent from the viewpoint of + routing protocol topology. This operation has already been proven to + work in the area of Web server applications, such as CDN (Contents + Delivery Network), with the Interior Gateway Protocol (IGP) and + Exterior Gateway Protocol (EGP). + + + + + + +Nagami, et al. Experimental [Page 5] + +RFC 4908 Multihoming for Fixed Network June 2007 + + + 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 [5] 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. Discussion on the Mailing List + +4.1. Why the Proposed Architecture Uses NEMO Protocols + + The multihomed architecture proposed in this document is basically + the same as the architecture of NEMO. Furthermore, NEMO protocols + meet the requirements of the proposed architecture in this document, + which are: + + o 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. + + 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 + + + +Nagami, et al. Experimental [Page 6] + +RFC 4908 Multihoming for Fixed Network June 2007 + + + architecture. Another solution is to propose a new protocol just + like NEMO. Nevertheless, such a protocol would have functions just + like those of NEMO. + +4.2. Route Announcement from Geographically Distributed Multiple HAs + + In the proposed architecture, the xSP (Multihomed Service Provider) + is introduced. The xSP is a conceptual service provider; it doesn't + have to be connected to the Internet physically for all practical + purposes. xSP has one or more aggregatable mobile network prefixes. + xSP contracts with some ISPs that are physically connected to the + Internet. The purpose of this contract is to set up some HAs in + those ISPs' networks. Those HAs announce the xSP's aggregated mobile + network prefixes. This means that HAs work just like border gateway + routers, and this situation is the same as peering between the ISP + and xSP. In this case, the origin Autonomous System (AS) announced + from the HAs is the xSP. + + On the other hand, a multihomed user (a small office user or home + user) contracts with the xSP to acquire a mobile network prefix from + the xSP. 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, the packets to the user's + mobile network will be sent to the nearest HA depending on global + routing information at that time. The HA that received such packets + will forward 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. + +5. Implementation and Experimentation + + We have implemented and experimented with the proposed architecture. + Currently, the system works well not only on our test-bed network, + but on the Internet. 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. + + + + + + + + + + +Nagami, et al. Experimental [Page 7] + +RFC 4908 Multihoming for Fixed Network June 2007 + + +6. Security Considerations + + This document describes requirements of multiple CoAs and HAs for + redundancy. It is necessary to enhance the protocols of MIP and NEMO + to solve the requirements. Security considerations of these + multihoming networks must be considered in a specification of each + protocol. + +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 + + + + + + + + + +Nagami, et al. Experimental [Page 8] + +RFC 4908 Multihoming for Fixed Network June 2007 + + + 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 + + + + +Nagami, et al. Experimental [Page 9] + +RFC 4908 Multihoming for Fixed Network June 2007 + + +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 + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Nagami, et al. Experimental [Page 10] + -- cgit v1.2.3