    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]