doc: Add RFC documents

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]
+