summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4908.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4908.txt')
-rw-r--r--doc/rfc/rfc4908.txt563
1 files changed, 563 insertions, 0 deletions
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]
+