NEMO Working Group                                                 C. Ng
Internet-Draft                                  Panasonic Singapore Labs
Expires: August 25, 2005 January 19, 2006                                        E. Paik
                                                                      KT
                                                                T. Ernst
                                                 WIDE at Keio University
                                                       February 21,
                                                              M. Bagnulo
                                                                    UC3M
                                                           July 18, 2005

          Analysis of Multihoming in Network Mobility Support
                 draft-ietf-nemo-multihoming-issues-02
                 draft-ietf-nemo-multihoming-issues-03

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 3 of RFC 3667.

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she become becomes
   aware will be disclosed, in accordance with
   RFC 3668. Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts. Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 25, 2005. January 19, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document is an analysis of multihoming in the context of network
   mobility (NEMO). (NEMO) in IPv6.  As there are many situations in which
   mobile networks may be multihomed, a taxonomy is proposed to classify
   the possible configurations.  We also describe  The possible deployment scenarios and we attempt to identify issues that arise when of
   multihomed mobile networks are multihomed while described together with the associated
   issues when network mobility supports is taken care supported by NEMO RFC 3963 (NEMO Basic Support.
   Support).  Issues are classified according to the Working Group which
   is the best chartered to solve them.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Classification . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1   (1,1,1): Single MR, Single HA, Single MNP  . . . . . . . .  7
     2.2   (1,1,n): Single MR, Single HA, Multiple MNPs . . . . . . .  7
     2.3   (1,n,1): Single MR, Multiple HAs, Single MNP . . . . . . .  8
     2.4   (1,n,n): Single MR, Multiple HAs, Multiple MNPs  . . . . .  8  9
     2.5   (n,1,1): Multiple MRs, Single HA, Single MNP . . . . . . .  9
     2.6   (n,1,n): Multiple MRs, Single HA, Multiple MNPs  . . . . .  9 10
     2.7   (n,n,1): Multiple MRs, Multiple HAs, Single MNP  . . . . . 10
     2.8   (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs . . . . 10 11

   3.  Deployment Scenarios and Prerequisites . . . . . . . . . . . . 12 13
     3.1   Deployment Scenarios . . . . . . . . . . . . . . . . . . . 12 13
     3.2   Prerequisites  . . . . . . . . . . . . . . . . . . . . . . 13 14

   4.  Problem Statement  Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 15 16
     4.1   Path Survival   Fault Tolerance  . . . . . . . . . . . . . . . . . . . . . 16
       4.1.1   Failure Detection  . . 15
     4.2 . . . . . . . . . . . . . . . . 16
       4.1.2   Path Exploration . . . . . . . . . . . . . . . . . . . 18
       4.1.3   Path Selection . . . . . . . . . . . . . . . . . . . . 19
       4.1.4   Re-Homing  . . 15
     4.3   Ingress Filtering . . . . . . . . . . . . . . . . . . . . 16
     4.4   Failure Detection 20
     4.2   Ingress Filtering  . . . . . . . . . . . . . . . . . . . . 18
     4.5 21
     4.3   Media Detection  . . . . . . . . . . . . . . . . . . . . . 19
     4.6 22
     4.4   HA Synchronization . . . . . . . . . . . . . . . . . . . . 20
     4.7 23
     4.5   MR Synchronization . . . . . . . . . . . . . . . . . . . . 20
     4.8 23
     4.6   Prefix Delegation  . . . . . . . . . . . . . . . . . . . . 21
     4.9 24
     4.7   Multiple Bindings/Registrations  . . . . . . . . . . . . . 21
     4.10 24
     4.8   Source Address Selection . . . . . . . . . . . . . . . . . 21
     4.11  Impact on the Routing Infrastructure 24
     4.9   Loop Prevention in Nested Mobile Networks  . . . . . . . . 25
     4.10  Prefix Ownership . . . 22
     4.12  Nested Mobile Networks . . . . . . . . . . . . . . . . . . 22
     4.13  Split Mobile Networks 25

   5.  Matrix [Issues,(x,y,z) Configuration]  . . . . . . . . . . . . 26

   6.  Conclusion . . . . . . 22

   5.  Conclusion . . . . . . . . . . . . . . . . . . . . 27

   7.  IANA Considerations  . . . . . . 23

   6.  Acknowledgments . . . . . . . . . . . . . . . 27

   8.  Security Considerations  . . . . . . . . 24

   7.  References . . . . . . . . . . . 27
   9.  Acknowledgments  . . . . . . . . . . . . . . . 24

       Authors' Addresses . . . . . . . . 27

   10.   References . . . . . . . . . . . . . . 26

   A.  Alternative Classifications Approach . . . . . . . . . . . 28
     10.1  Normative References . . 27
     A.1   Ownership-Oriented Approach . . . . . . . . . . . . . . . 27
       A.1.1   ISP Model . . 28
     10.2  Informative References . . . . . . . . . . . . . . . . . . 28

       Authors' Addresses . . 27
       A.1.2   Subscriber/Provider Model . . . . . . . . . . . . . . 28
     A.2   Problem-Oriented Approach . . . . . . 30

   A.  Alternative Classifications Approach . . . . . . . . . . 30

   B.  Nested Tunneling for Fault Tolerance . . . 32
     A.1   Ownership-Oriented Approach  . . . . . . . . . . 31 . . . . . 32
       A.1.1   ISP Model  . . . . . . . . . . . . . . . . . . . . . . 32
       A.1.2   Subscriber/Provider Model  . . . . . . . . . . . . . . 33
     A.2   Problem-Oriented Approach  . . . . . . . . . . . . . . . . 35

   B.  Nested Tunneling for Fault Tolerance . . . . . . . . . . . . . 36
     B.1   Detecting Presence of Alternate Routes . . . . . . . . . . 31 36
     B.2   Re-Establishment of Bi-Directional Tunnels . . . . . . . . 31 36
       B.2.1   Using Alternate Egress Interface . . . . . . . . . . . 32 37
       B.2.2   Using Alternate Mobile Router  . . . . . . . . . . . . 32 37
     B.3   To Avoid Tunneling Loop  . . . . . . . . . . . . . . . . . 33 38

   C.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 34 39

       Intellectual Property and Copyright Statements . . . . . . . . 36 41

1.  Introduction

   The design goals and objectives of Network Mobility Support (NEMO) in
   IPv6 are identified in [1] while the terminology is being described
   in [2] and [3].  NEMO Basic Support (RFC 3963) [4] is the solution
   proposed by the NEMO Working Group to provide continuous Internet
   connectivity to nodes located in a an IPv6 mobile network, e.g. like in
   an in-vehicle embedded IP network.  This solutions  The NEMO Basic Support solution
   basically solves the problem by setting up bi-directional tunnels
   between the mobile routers (MRs) connecting the mobile network to the
   Internet and their respective Home Agents (HAs), much how this is
   done in Mobile IPv6 [5], the solution for host mobility. mobility support.
   NEMO Basic Support is transparent to nodes located behind the mobile
   router (i.e. the mobile network nodes, or MNNs) and as such doesn't
   require MNNs to take any action in the mobility management.

   However, mobile networks are typically connected by means of wireless
   and thus less reliable links; there could also be many nodes behind
   the MR.  A loss of connectivity or a failure to connect to the
   Internet has thus a more significant impact than for a single mobile
   node.
   Real-life scenarios as  Scenarios illustrated in [6] demonstrate that providing a
   permanent access to mobile networks such as vehicles typically
   require the use of several interfaces and technologies since the
   mobile network may be moving in distant geographical locations where
   different access technologies are provided and governed by distinct
   access control policies.

   As specified by R.12 in section 5 of [1], the NEMO WG must ensure
   that NEMO Basic Support does not prevent mobile networks to be
   multihomed, i.e. when there is more than one point of attachment
   between the mobile network and the Internet (see definitions in
   [3]).. [3]).
   This arises either either:

   o  when a MR has multiple egress interfaces. interfaces, or

   o  the mobile network has multiple MRs, or

   o  the mobile network is associated with multiple HAs, or

   o  multiple global prefixes are available in the mobile network.

   Using NEMO Basic Support, this translates would translate into having multiple
   bi-directional tunnels between the mobile network MR(s) and its HA(s), the corresponding HA,
   and may result into multiple MNPs being advertised available to the MNNs.  However,
   NEMO Basic Support does not specify any particular mechanism to
   manage multiple bi-directional tunnels.  The objective of this memo
   is thus three-folds: multi-folded:

   o  to determine all the potential multihomed configurations for a
      NEMO, and then to identify which multihoming configurations are useful, of those may be useful in a real
      life scenario,

   o  to identify capture issues that may prevent useful some multihomed configurations
      to be supported under the operation of NEMO Basic Support.  It
      doesn't necessarily mean that those not supported will not work
      with NEMO Basic Support, just that as it is may be up to the implementors to
      make it work (hopefully issues discussed in this memo will be helpful to these
      implementors).

   For doing so,

   o  to identify potential solutions to the previously identified
      issues.

   o  to decide which issues are worth to be solved, and to determine
      which WG should address each of the issues that are worth solving.

   In order to reach these objectives, a taxonomy to classify the
   possible multihomed configurations is described in Section 2.
   Deployment scenarios, their benefits, and requirements to meet these
   benefits are illustrated in Section 3.  Following this, we study the general related
   issues are studied in Section 4, and we conclude 4.  The issues are then summarized in a
   matrix for each of the deployment scenario (Section 5).  This memo
   concludes with an evaluation of NEMO Basic Support for multihomed
   configurations.  Alternative classifications are outlined in the
   Appendix.

   In order to understand

   The readers should note that this document considers multihoming only
   from the point of view of an IPv6 environment.  In order to
   understand this memo, the reader is expected to be familiar with the
   above cited documents, i.e. with the NEMO terminology as defined in
   [2] (section 3) and [3], Goals and Benefits of Multihoming [6], Goals
   and Requirements of Network Mobility Support [1], and the NEMO Basic
   Support specification [4].  Goals and benefits for of multihoming as
   discussed in [6] are applicable to fixed nodes, mobile nodes, fixed
   networks and mobile networks.

   This document considers multihoming only from the IPv6 point of view.

2.  Classification

   Various discussions on the topic of multihoming issues in NEMO have
   been carried out on the mailing list and at IETF meetings.

   As there are several configurations in which mobile networks are
   multihomed, there is a need to classify them into a clearly defined
   taxonomy.  This can be done in various ways.  Three approaches have been
   proposed on the NEMO mailing list.  These are,  A Configuration-
   Oriented taxonomy is described in this section.  Two other
   taxonomies, namely, (i) the
   Configuration-Oriented Approach, (ii) the Ownership-Oriented Approach, and (iii) the Problem-Oriented Approach.  As the WG
   consensus seems to have converged to the Configuration-Oriented
   Approach, we only describe this approach here.  The other two
   approaches Problem-
   Oriented Approach are outlined in Appendix A.1 and Appendix A.2.

   Multihomed configurations can be classified depending on how many
   mobile routers are present, how many egress interfaces, Care-of
   Address (CoA) and Home Addresses (HoA) the mobile routers have, how
   many prefixes (MNPs) are advertised available to the mobile network nodes, etc.
   For doing so, we
   We use three key parameters differentiating different to differentiate the multihomed
   configurations.  With  Using these parameters, we can refer to each configuration is
   referred by the 3-tuple (x,y,z), where 'x', 'y', 'z' are defined as
   follows:

   o  'x' indicates the number of MRs where:

      x=1 implies a mobile network has only a single MR, presumably
         multihomed.

      x=N

      x=n implies a mobile network has more than one MR.

   o  'y' indicates the number of HAs associated with the entire mobile
      network, where:

      y=1 implies that a single HA is assigned to the mobile network.

      y=N

      y=n implies that multiple HAs (possibly in different
         administrative domains) are assigned to the mobile network.

   o  'z' indicates the number of MNPs announced to MNNs, available within the NEMO, where:

      z=1 implies that a single MNP is advertised to available in the MNNs. NEMO.

      z=N implies that multiple MNPs are advertised to available in the MNNs. NEMO

   It can be seen that the above three parameters are fairly orthogonal
   to one another.  Thus different values of 'x', 'y' and 'z' give rise
   to different combinations of the 3-tuple (x,y,z).

   As described in the sub-sections below, a total of 8 possible
   configurations can be identified.  One thing the reader has to keep
   in mind is that in each of the following 8 cases, the MR may be
   multihomed if either (i) multiple prefixes are advertised available (on the home
   link, or on the visited link), or (ii) the MR is equipped with
   multiple interfaces.  In such a case, the MR would have a combination of multiple Home
   Address / Care-of Address pairs.  Issues pertaining to a multihomed
   MR are also addressed in
   the companion document [7].

   A simplified analysis of multihoming configuration  In addition, the readers should also
   keep in mind that when "MNP(s) is/are available in NEMO Basic
   Support using the same classification can NEMO", the
   MNP(s) may either be found in [8]. explicitly announced by the MR via router
   advertisement, or mad available through Dynamic Host Configuration
   Protocol (DHCP).

2.1  (1,1,1): Single MR, Single HA, Single MNP

   The (1,1,1) mobile network has only one MR advertising a single MNP.
   In addition, the MR MR, it is associated with only one HA a
   single HA, and a single MNP is available in the NEMO.  To fall into a
   multihomed configuration, at any least one time.
   A bi-directional tunnel may be established between each pair of Home
   Address / Care-of address if the MR is itself multihomed. following conditions
   must hold:

   o  The MR may be multihomed and MNNs has multiple interfaces, or

   o  Multiple global prefixes are (usually) not multihomed since
   they would configure a available on the visited link, or

   o  Multiple global prefixes are available on the home link (Note that
      in this case, those prefixes are not all available in the NEMO,
      since there is only a single MNP in the NEMO)

   A bi-directional tunnel would then be established between each pair
   of Home Address / Care-of Address.

   Regarding MNNs, they are (usually) not multihomed since they would
   configure a single global address on from the single MNP announced available on
   the link they are attached to.

                                   _____
                   _    p      _  |     |
                  |_|-|<-_  |-|_|-|     |-|        _
                   _  |-|_|=|     |_____| |  _  |-|_|
                  |_|-|     |             |-|_|-|
                                                |
                  MNNs   MR   AR  Internet   AR    HA

                   Figure 1: (1,1,1): 1 MR, 1 HA, 1 MNP

2.2  (1,1,n): Single MR, Single HA, Multiple MNPs

   The (1,1,n) mobile network has only one MR, which it is associated to
   only one with a
   single HA at any one time.  However, and two or more MNPs are
   advertised to available in the mobile network nodes. NEMO.

   The MR may be itself multihomed, and MNNs as detailed in Section 2.1.  In such
   a case, a bi-directional tunnel would be established between each
   pair of Home Address / Care-of Address.

   Regarding MNNs, they are multihomed if because several MNPs are advertised
   available on the link they are attached to.  If that
   conditions holds,  The MNNs would then
   configure an a global address with each MNP
   announced available on the link.

                                   _____
                   _   p1,p2   _  |     |
                  |_|-|<-_  |-|_|-|     |-|        _
                   _  |-|_|=|     |_____| |  _  |-|_|
                  |_|-|     |             |-|_|-|
                                                |
                  MNNs   MR   AR  Internet   AR    HA

               Figure 2: (1,1,n): 1 MR, 1 HA, multiple MNPs

2.3  (1,n,1): Single MR, Multiple HAs, Single MNP

   The (1,n,1) mobile network has only one MR advertising and a single MNP. MNP is
   available in the NEMO.  The MR, however, is associated to with multiple
   HAs, possibly one HA per Home Address, or one HA per egress
   interface.

   The MR NEMO is multihomed since it has multiple HAs, but in addition the
   conditions detailed in Section 2.1 may also hold for the MR.  A bi-
   directional tunnel would then be multihomed whereas MNNs established between each pair of
   Home Address / Care-of Address.

   Regarding MNNs, they are (usually) not multihomed since they would
   configure a single global address on from the single MNP
   announced available on
   the link they are attached to.

                                          AR    HA2
                                           _  |
                                        |-|_|-|  _
                                 _____  |     |-|_|
                 _    p      _  |     |-|
                |_|-|<-_  |-|_|-|     |
                 _  |-|_|=|     |_____|-|        _
                |_|-|     |             |  _  |-|_|
                                        |-|_|-|
                                              |
                MNNs  MR    AR  Internet  AR    HA1

               Figure 3: (1,n,1): 1 MR, multiple HAs, 1 MNP

2.4  (1,n,n): Single MR, Multiple HAs, Multiple MNPs

   The (1,n,n) mobile network has only one MR.  However, the MR is
   associated with multiple HAs, possibly one per Home Address (or one
   HA per egress interface), and the MR advertises more than one MNP on
   its ingress interfaces.  No assumption is made on whether or not the
   HAs belongs to available in the same administrative domain.
   NEMO.

   The MR is multihomed since it has multiple HAs, but in addition the
   conditions detailed in Section 2.1 may also hold.  A bi-directional
   tunnel would then be multihomed, and the MNNs established between each pair of Home Address /
   Care-of Address.

   Regarding MNNs, they are generally multihomed since they would
   configure an a global address on from each MNP announced available on the link they
   are attached to.

                                         AR    HA2
                                          _  |  _
                                _____  |-|_|-|-|_|
                _   p1,p2   _  |     |-|     |
               |_|-|<-_  |-|_|-|     |          _
                _  |-|_|=|     |_____|-|  _  |-|_|
               |_|-|     |             |-|_|-|
                                       |     |
               MNNs  MR    AR  Internet  AR    HA1

           Figure 4: (1,n,n): 1 MR, multiple HAs, multiple MNPs

2.5  (n,1,1): Multiple MRs, Single HA, Single MNP

   The (n,1,1) mobile network has more than one MR advertising global
   routes.  These MRs, however, advertise  However, the same MNP and MR(s) are associated with the same HA.

   Each MR as single HA, and
   there in a single MNP available in the NEMO.

   The NEMO is multihomed since it has multiple MRs, but in addition the
   conditions detailed in Section 2.1 may also hold for each MR.  A bi-
   directional tunnel would then be itself multihomed, whereas MNNs established between each pair of
   Home Address / Care-of Address.

   Regarding MNNs, they are (usually) not multihomed since they would
   configure a single global address on from the single MNP announced available on
   the link they are attached to.

                        MR2
                      p<-_  |
                   _  |-|_|-|  _____
                  |_|-|     |-|     |
                   _  |       |     |-|        _
                  |_|-|  _  |-|_____| |  _  |-|_|
                      |-|_|-|         |-|_|-|
                      p<-   |               |
                  MNNs  MR1   Internet   AR    HA

               Figure 5: (n,1,1): Multiple MRs, 1 HA, 1 MNP

2.6  (n,1,n): Multiple MRs, Single HA, Multiple MNPs

   The (n,1,n) mobile network has more than one MR; multiple global
   routes and different MNPs are advertised by the MRs.

   Each MR MRs and multiple MNPs are available
   within the NEMO.

   The NEMO is multihomed since it has multiple MRs, but in addition the
   conditions detailed in Section 2.1 may also hold for each MR.  A bi-
   directional tunnel would then be itself multihomed, and MNNs established between each pair of
   Home Address / Care-of Address.

   Regarding MNNs, they are generally multihomed since they would
   configure an a global address on from each MNP announced available on the link they
   are attached to.

                        MR2
                     p2<-_  |
                   _  |-|_|-|  _____
                  |_|-|     |-|     |
                   _  |       |     |-|        _
                  |_|-|  _  |-|_____| |  _  |-|_|
                      |-|_|-|         |-|_|-|
                     p1<-   |               |
                  MNNs  MR1   Internet   AR    HA

           Figure 6: (n,1,n): Multiple MRs, 1 HA, multiple MNPs

2.7  (n,n,1): Multiple MRs, Multiple HAs, Single MNP

   The (n,n,1) mobile network has more than one MR advertising multiple
   global routes.  The mobile network is simultaneously associated with
   multiple HAs at
   any one time.  No assumptions are made on whether or not the HAs
   belongs to the same administrative domain.  However, and a single MNP is available in the NEMO.

   The NEMO is multihomed since it has multiple MRs
   advertises and HAs, but in
   addition the same MNP.

   Each MR conditions detailed in Section 2.1 may also hold for
   each MR.  A bi-directional tunnel would then be itself multihomed whereas MNNs established between
   each pair of Home Address / Care-of Address.

   Regarding MNNs, they are (usually) not multihomed since they would
   configure a single global address on from the single MNP announced available on
   the link they are attached to.

                        MR2             AR    HA2
                        p                _  |
                       <-_  |         |-|_|-|  _
                   _  |-|_|-|  _____  |     |-|_|
                  |_|-|     |-|     |-|
                   _  |       |     |
                  |_|-|  _  |-|_____|-|        _
                      |-|_|-|         |  _  |-|_|
                       <-   |         |-|_|-|
                        p                   |
                  MNNs  MR1   Internet  AR    HA1

           Figure 7: (n,n,1): Multiple MRs, Multiple HAs, 1 MNP

2.8  (n,n,n): Multiple MRs, Multiple HAs, Multiple MNPs

   The (n,n,n) mobile network has multiple MRs advertising different
   global routes and different MNPs. routes.  The mobile network is simultaneously associated with
   more than one HA at any one time.  No assumptions is made on
   whether or not the HA belongs to the same administrative domain.

   Each MR may be itself multihomed and MNNs multiple MNPs are generally available in the NEMO.

   The NEMO is multihomed since they would configure an address on each MNP announced on it has multiple MRs and HAs, but in
   addition the
   link they are attached to

                        MR2             AR conditions detailed in Section 2.1 may also hold for
   each MR.  A bi-directional tunnel would then be established between
   each pair of Home Address / Care-of Address.

   Regarding MNNs, they are generally multihomed since they would
   configure a global address from each MNP available on the link they
   are attached to.

                        MR2             AR    HA2
                        p2               _  |
                       <-_  |         |-|_|-|  _
                   _  |-|_|-|  _____  |     |-|_|
                  |_|-|     |-|     |-|
                   _  |       |     |
                  |_|-|  _  |-|_____|-|        _
                      |-|_|-|         |  _  |-|_|
                       <-   |         |-|_|-|
                        p1                  |
                  MNNs  MR1   Internet  AR    HA1

              Figure 8: (n,n,n): Multiple MRs, HAs, and MNPs

3.  Deployment Scenarios and Prerequisites

   The following generic goals and benefits of multihoming are discussed
   in a companion document [6]:

   1.  Permanent and Ubiquitous Access

   2.  Redundancy/Fault-Recovery

   3.  Load Sharing

   4.  Load Balancing

   5.  Preference Settings

   These benefits are now illustrated from a NEMO perspective with a
   typical instance scenario for each case in the taxonomy.  We then
   discuss the prerequisites to fulfill these.

3.1  Deployment Scenarios

   x=1: Multihomed mobile network networks with a single MR

      o  Example: an MR with dual/multiple access interfaces (e.g.
         802.11 and GPRS capabilities).  This is a S/P-(1,1,*) if both
         accesses are subscribed to the same ISP.  If the two accesses
         are offered by independent ISPs, this is a S/mP-(1,n,n) [for
         the meaning of this abbreviation, see Appendix A.1].

         Benefits: Ubiquity, Redundancy/Fault-Recovery, Load Sharing,
         Preference Settings

   x=N:  Multihomed mobile networks with multiple MRs

      o  Example 1: a train with one MR in each car, all served by the
         same HA, thus a (n,1,*).  Alternatively, the train company
         might be forced to use different ISPs when the train go to
         different locations, thus it is a (n,n,n).

         Benefits: Load Sharing, Redundancy/Fault-Recovery, Ubiquity

      o  Example 2: W-PAN with a GPRS_enabled GPRS-enabled phone and a WiFi-enabled
         PDA.  This is a S/mP-(n,n,n) if the two access technologies are
         subscribed separately.

         Benefits: Ubiquity, Redundancy/Fault-Recovery, Preference
         Settings
   y=1:  Multihomed mobile networks with a single HA

      o  Most single ISP cases in above examples.

   y=N:  Multihomed mobile networks with multiple HAs

      o  Most multiple ISP cases in above examples.

      o  Example: a transatlantic flight with a HA in each continent.
         This is a (1,n,1) network if there is only one MR.

         Benefits: Ubiquity, Preferences (reduced delay, shortest path)

   z=1:  Multihomed mobile networks with a single MNP

      o  Most single ISP cases in above examples.

   z=N:  Multihomed mobile networks with multiple MNPs

      o  Most multiple ISP cases in above examples.

      o  Example: a car with a prefix taken from home (personal traffic
         transit on this prefix and is paid by the owner) and one that
         belongs to the car manufacturer (maintenance traffic is paid by
         the car-manufacturer).  This will typically be a (1,1,n) or a
         (1,n,n,).

         Benefits: Preference Settings

3.2  Prerequisites

   In this section, we try to define the requirements are started in order to
   fulfill comply with the
   expected multihoming benefits of multihoming as detailed in [6].

   At least one bi-directional tunnel must be available at any point in
   time between the mobile network and the fixed network to meet all
   expectations.  But for most goals to be effective, multiple tunnels
   must be maintained simultaneously:

   o  Permanent and Ubiquitous Access:

      At least one bi-directional tunnel must be available at any point
      in time.

   o  Redundancy and Fault-Recovery:

      Both the inbound and outbound traffic must be transmitted or
      diverted over another bi-directional tunnel once a bi-directional
      tunnel is broken or disrupted.  It should be noted that the
      provision of fault tolerance capabilities does not necessarily
      require the existence of multiple bi-directional tunnels
      simultaneously.

   o  Load Sharing and Load Balancing:

      Multiple tunnels must be maintained simultaneously.

   o  Preference Settings:

      Implicitly, multiple tunnels must be maintained simultaneously if
      preferences are set for deciding which of the available
      bi-directional bi-
      directional tunnels should be used.  A  To allow user/application to
      set the preference, a mechanism must should be provided to the user/application about user/
      application for the notification of the availability of multiple bi-direction
      bi-directional tunnels, and perhaps also to set the
      preference.  The preference may reside in the mobile router or
      mobile preferences.
      Similar mechanism should also be provided to network nodes (using [9]
      administrators for instance). the administration of the preferences.

4.  Problem Statement

   In order to meet  Multihoming Issues

   As discussed in the multihoming benefits, previous section, multiple bi-directional tunnels may
   need to be maintained either simultaneously (e.g.  load balancing, for load sharing)
   or not sequentially (e.g.  redundancy) between the mobile network and the fixed network. for fault tolerance)

   In some cases, it may be necessary to divert packets from a (perhaps
   failed) bi-directional tunnel to an alternative (perhaps newly
   established) bi-directional tunnel (i.e. for matters of fault
   recovery, preferences), or to split traffic between multiple tunnel tunnels
   (load sharing, load balancing).

   For doing so,

   So, depending on the configuration under consideration, the issues
   discussed below must may need to be addressed,
   preferably sometimes dynamically.  For
   each issue, we also investigate potential ways to solve the problem are investigated and recommend
   an a recommendation is made on which IETF WG(s) should look into
   these issues.

4.1  Path Survival

   Internet connectivity is guaranteed for all MNNs as long as at least
   one bi-directional tunnel is maintained between the mobile network
   and the fixed Internet.  When an alternative tunnel must be found to
   substitute for the failed one,  Fault Tolerance

   One of the loss goals of one tunnel to multihoming is the Internet
   may result in broken sessions. provision of fault tolerance
   capabilities.  In this case, new transport sessions
   will have order to provide such features, a set of tasks need
   to be performed, including: failure detection, alternative available
   path exploration, path selection, re-homing of established over the alternate tunnel if no mechanism
   communications.  These are also discussed in [8] [9].  In the
   following sub-sections, we look at these issues in the specific
   context of NEMO, rather than the general Multi6/Shim6 perspective in
   [8] [9].  In addition, in some scenarios, it may also be required to
   provide the mechanisms for coordination between different HAs (see
   Section 4.4) and also the coordination between different MRs (see
   Section 4.5).

4.1.1  Failure Detection

   It is provided expected for faults to make this change transparent occur more readily at layers above layer 3.

   The tunnel can be changed transparently the edge of the
   network (i.e. the mobile nodes), due to the MNNs if use of wireless
   connections.  Efficient fault detection mechanisms
   such as MMI [10] are brought necessary to the MR.

   For instance,
   recover in timely fashion.  Depending on the (1,1,1) case specifically, packets are always
   transmitted to/from NEMO configuration
   considered, the same MR's ingress interface, i.e.
   independently of MR's links connectivity status.

   This is a general problem faced by any node with multiple egress
   paths.  It is recommended that this issue be considered failure protection domain greatly varies.  In some
   configurations, the protection domain provided by other WGs
   (such as IPv6, Multi6), and NEMO WG multihoming is
   limited to contribute any NEMO specific
   requirements.

4.2  Path Selection

   When multiple bi-directional tunnels are available and possibly used
   simultaneously, the mode of operation may be either primary-secondary
   (one tunnel is precedent over links between the others MR(s) and used as the default
   tunnel, while the HA(s).  In other serves as a back-up) or peer-to-peer (no
   tunnel has precedence over one another, they are used with
   configurations, the same
   priority).  This questions which bi-directional tunnel would be
   selected, and based on which parameter (e.g.  type of flow that goes
   into/out protection domain allows to recover from failures
   in other parts of the mobile network).

   A dynamic path selection path, so an end to end failure detection
   mechanism is thus needed so that this path
   could be selected by: required.

   Below are detailed which failure detection capabilities are required
   for each configuration:

   o  The HA: it should be able to select  For the path based on some
      information recorded in (1,1,*) cases, multiple paths are available between a
      single MR and a single HA.  All the binding cache.

   o  The MR: it should be able traffic from and to select the path based on router
      advertisements received on both its egress interfaces or on its
      ingress interfaces for the (n,*,*) case. NEMO
      flows through these MR and HA.  Failure detection mechanisms need
      only to be executed between these two devices.  This is a NEMO
      specific issue (MIPv6?).

   o  For the (n,1,*) cases, there is a single HA, so all the traffic
      from and to the NEMO will flow through it.  The MNN: it should failure detection
      mechanisms need to be able to select the path based on "Default
      Router Selection" (see [Section 6.3.6. Default Router Selection]
      [11]) detect failure in the (n,*,*) case or based on "Source Address Selection"
      in path between
      the (*,*,n) cases (see Section 4.10 of used MR and the present memo).

   o  The user or only HA.  Hence, the application: e.g.  in case where a user wants failure detection
      mechanism needs only to
      select a particular access technology among involve the available
      technologies for reasons of cost or data rate.

   o  A combination of any of HA and the above: MRs.  This is a hybrid mechanism should be
      also available, e.g.  one in which the HA, the MR, and/or
      NEMO specific issue (MIPv6?).

   o  For the MNNs (n,n,*) cases, there are coordinated to select multiple paths between the path.

   This is a general problem faced by any node with multiple egress
   paths.  It is recommended that this issue be considered by other WGs
   (such as IPv6, Multi6),
      different HAs and NEMO WG to contribute any NEMO specific
   requirements.

4.3  Ingress Filtering

   Ingress filtering mechanisms may drop the outgoing packets when
   multiple bi-directional tunnels end up at different HAs.  This could
   particularly occur if MRs.  Moreover, the HAs may be
      located in different MNPs are handled by networks, and have different home
   agents.  If packet with a source address configured from a specific
   MNP is tunnelled to a home agent that does not handle Internet access
      links.  This implies that specific
   MNP changing the packet HA used, may be discarded due not only allow
      to ingress filtering (either by
   the home agent or by a border gateway recover from failures in the home network).

   As an example link between the HA and the MR but
      also from other failure modes, affecting other parts of how this could happen, consider the deployment
   scenario illustrated in Figure 9. path.
      In Figure 9, this case, an end to end failure detection mechanism would
      provide additional protection.  However, a higher number of
      failures is likely in the mobile network
   has two mobile routers MR1 and MR2, with home agents HA1 and HA2
   respectively.  Two bi-directional tunnels are established are
   established link between the two pairs.  Each mobile router advertises a
   different MNP (P1 HA and P2).  MNP P1 is registered the MR, so it
      may be reasonable to HA1, and MNP P2 provide optimized failure detection
      mechanisms for this failure mode even in this scenario, as it is registered
      considered next.  The (n,n,1) case, however, seems to HA2.  Thus, MNNs should be free to auto-configure
   their addresses on any pretty
      NEMO specific, because of P1 or P2.  Ingress filtering could thus
   happen in two cases:

   o  If the two tunnels are available, MNN cannot forward packet with
      source address equals P1.MNN to MR2.  This would cause ingress
      filtering at HA2 to occur (or even at MR2).  This absence of multiple prefixes.  The
      (n,n,n) case is contrary to
      normal Neighbor Discovery [11] practice hybrid, since for those cases that an IPv6 node is free
      to choose any router as its default router regardless selecting a
      different prefix results in a change of path, the
      prefix it chooses to use.  A simple solution is to require all
      MNNs to set their default router SHIM/multi6
      protocols may be useful.  The other cases, are NEMO specific.

   In order for fault recovery to work, the MR that advertises MRs and HAs must first
   possess a means to detect failures:

   o  On the MNP MR's side, the MNNs configured their addresses from.  If such requirement is
      not placed MR can rely on mobile network nodes, then a multihoming solution
      for mobile networks must address this problem.  For a possible
      approach, see [12].  However, this is not enough router advertisements from
      access routers, or other layer-2 trigger mechanisms to maintain
      connectivity if detect
      faults, e.g. [10], [11], [12] or [13].  (For a tunnel fails (see related issue, see
      Section 4.1 for a discussion
      of this issue). 4.3.)

   o  If  On the tunnel to HA1 HA's side, it is broken, packets would be sent through the
      tunnel more difficult to HA1 are diverted through the detect tunnel to HA2.  If HA2 (or
      some border gateway in failures.
      For an ISP deployment model, the domain HAs and MRs can use proprietary
      methods (such as constant transmission of HA2) performs ingress
      filtering, packets with source address configured from MNP P1 may
      be discarded.  It should be noted that this problem may be faced
      by any (*,n,n) mobile network, even if MR1 heartbeat signals) to
      detect failures and MR2 are in fact the
      same entity in Figure 9.

   To avoid ingress filtering mechanisms dropping packets in such
   situations, MR(s) can stop advertising P1.  This would prevent MNNs
   from using check tunnel liveness.  In the address auto-configured on this prefix.  However, such S/P model (see
      Appendix A.2), a method suffers from the following two limitations:

   o  Switching addresses lack of standardized "tunnel liveness" protocol
      means that it is time consuming since nodes have harder to wait detect failures.

   A possible method is for
      addresses the MRs to get deprecated [9].

   o  Switching addresses force transport sessions without multihoming
      capabilities (such as TCP) send binding updates more
   regularly with shorter Lifetime values.  Similarly, HAs can return
   binding acknowledgment messages with smaller Lifetime values, thus
   forcing the MRs to send binding updates more frequently.  These
   binding updates can be used to terminate, emulate "tunnel heartbeats".  This
   however may lead to more traffic and processing overhead, since
   binding updates sent to HAs must be re-established
      using protected (and possibly
   encrypted) with security associations.

4.1.2  Path Exploration

   Once a failure in the currently used path is detected, alternative source address.  Transport sessions with
      multihoming capabilities (such as SCTP) may
   paths need to be able explored in order to continue
      without disruption (see also Section 4.1)

   Although one way identify an available one.
   This process is closely related to avoid the long wait for address deprecation by
   sending a router advertisement with zero Lifetime, failure detection in the
   termination/disruption of transport sessions may render this solution
   unattractive.  It is possible sense
   that paths being explored need to overcome these limitations by using
   nested tunnels.  Appendix B describes be alternative paths to the one such approach.

               Prefix: P1 +-----+  +----+  +----------+   +-----+
                       +--| MR1 |--| AR |--|          |---| HA1 |
                       |  +-----+  +----+  |          |   +-----+
       IP:    +-----+  |                   |          | Prefix: P1
    P1.MNN or | MNN |--+                   | Internet |
      P2.MNN  +-----+  |                   |          | Prefix: P2
                       |  +-----+  +----+  |          |   +-----+
                       +--| MR2 |--| AR |--|          |---| HA2 |
               Prefix: P2 +-----+  +----+  +----------+   +-----+

                  Figure 9: An (n,n,n) mobile network

   It is recommended
   that has failed.  There are, however, subtle but significant
   differences between path exploration and failure detection.  Failure
   detection occurs on the NEMO specific issue of ingress filtering
   be tackled by the NEMO WG, either through the standardization of the
   technique described currently used path while path exploration
   occurs in alternative paths (not in Appendix B, or by specifying a statement to
   define the mobile router behavior with respect one currently being used for
   exchanging packets).  Although both path exploration and failure
   detection are likely to fault recovery in rely on a reachability or keepalive test
   exchange, failure detection also relies on other information, such as
   upper layer information (e.g. positive or negative feedback form
   TCP), lower layer information (e.g. an (*,n,n) mobile network.

4.4  Failure Detection

   It interface is expected for faults to occur more readily at the edge of the down), and
   network (i.e. layer information (e.g. as an address being deprecated or
   ICMP error message).

   Basically, the mobile nodes), due to same cases as in the use analysis of wireless
   connections.  Efficient fault the failure detection mechanisms
   (Section 4.1.1) issue are necessary to
   recover in timely fashion.  In order for fault recovery to work, identified:

   o  For the
   MRs (1,1,*) cases, multiple paths are available between a
      single MR and HAs must first possess a means to detect failures:

   o  On single HA.  The existing paths between the MR's side, HA and
      the MR can also rely on router advertisements
      from access routers, or other layer-2 trigger mechanisms need to detect
      faults, e.g.  [13] or [14].  (For a related issue, see
      Section 4.5.)

   o  On the HA's side, it is more difficult for HAs be explored to detect tunnel
      failures.  For identify an ISP deployment model, available one.  The
      mechanism involves only the HAs and MRs can use
      proprietary methods (such as constant transmission of heartbeat
      signals) to detect failures HA and check tunnel liveness.  In the S/P
      model (see Appendix A.2), a lack of standardized "tunnel liveness"
      protocol means that it is harder to detect failures.

      A possible method MR.  This is for a NEMO
      specific issue (MIPv6?).

   o  For the MRs to send binding updates more
      regularly with shorter Lifetime values.  Similarly, HAs can return
      binding acknowledgment messages with smaller Lifetime values, thus
      forcing (n,1,*) cases, there is a single HA, so all the MRs to send binding updates more frequently.  These
      binding updates can be used to emulate "tunnel heartbeats".  This
      however may lead to more traffic
      from and processing overhead, since
      binding updates sent to HAs must be protected (and possibly
      encrypted) with security associations.

   There the NEMO will flow through it.  The available
      alternative paths are other failure modes to consider as well, such as failure at
   home agent, failure at access routers, or in general failure of a
   link or node along the path from different ones between the mobile router different MRs
      and the HA.  The path exploration mechanism needs only to involve
      the home agent.
   By HA and the nature of MRs.  This is a NEMO specific issue (MIPv6?).

   o  For the routing infrastructure, failure of intermediate
   nodes or links (n,n,*) cases, there are recovered by multiple paths between the
      different HAs and the routing infrastructure by
   choosing a different route.  For those failures that can't MRs.  In this case, alternative
      paths may be
   receovered (such a failure routed completely independently one from each other.
      In this case, an end to end path exploration mechanism would be
      able to discover if any of the access router), a heartbeat
   protocol or the use of small-lifetime binding updates described above
   can also be used end to detect tunnel failures.

   This end paths is available.
      However, a general problem faced by all nodes communicating with a
   peer.  It higher number of failures is recommended that NEMO WG adopts any failure detection
   mechansim standardized likely in the IETF, and, should link between
      the need arise,adapts
   such HA and the MR, so it may be reasonable to provide optimized
      path exploration mechanism specifically for detecting tunnel failures.

4.5  Media Detection

   In order this failure mode even in this
      scenario.  The (n,n,1) case, however, seems to achieve benefits such as ubiquity or fault recovery, it be pretty NEMO
      specific, because of the absence of multiple prefixes.  The
      (n,n,n) case is necessary hybrid, since for mobile router to detect the availability those cases that selecting a
      different prefix result in a change of network
   media.  This path, the SHIM/multi6
      protocols may be achieved using layer 2 triggers [13], or useful.  The other cases, are NEMO specific.

4.1.3  Path Selection

   A path selection mechanism developed/recommended by the Detecting Network Attachment
   (DNA) Working Group.

   This is related required to Section 4.4, since select among the ability to detect media
   availability would often implies multiple
   available paths.  Depending on the ability to detect media
   in-availability.

4.6  HA Synchronization

   In NEMO multihoming configuration
   involved, the (*,n,1) mobile networks, a single MNP would be registered at
   different HAs.  This gives rise to differences between the following issues:

   o  Only one HA paths may actively advertise a route to affect only the MNP.

   o  Multiple HAs at different domains may advertise a route to part
   between the
      same MNP

   This HA and the MR or may pose a problem in affect the routing infrastructure as a whole.
   The implications of this aspect needs further exploration.  Certain
   level of HA co-ordination may be required.  A possible approach is full end to
   adopt a HA synchronization mechanism such as that described in [15]
   and [16].  Such synchronization might also be necessary in a (*,n,*)
   mobile network, when a MR sends binding update messages end path.
   Related to only one
   HA (instead of all HAs).  In such cases, this, depending on the binding update
   information might have to be synchronized betweeen HAs.  The mode of
   synchoronization configuration, path selection may
   be either primary-secondary performed by the HA(s), the MR(s) or peer-to-peer.
   See also Section 4.7.

   This problem is general in the sense that Mobile IPv6 hosts themselves through
   address selection, as it will have to
   consider similar issues.  It is recommended that the issue be looked
   at in one of the Mobile IP WG, and NEMO WG to contribute any NEMO
   specific requirements.

4.7  MR Synchronization presented next.

   In the (n,*,*) mobile network, different MRs may need to be
   synchronized in order to take common decisions.  The mode of
   synchoronization may be either primary-secondary or peer-to-peer.
   This may include:

   o  In (*,*,1) cases, the (n,*,1) case, advertising multiple available paths mostly differ on
   the same MNP (see also "prefix
      delegation" in Section 4.8).

   o  In tunnel between the (n,*,n) case, a MR relaying and the advertisement of HA used to carry traffic to/from
   the MNP
      from another failed MR.

   o NEMO.  In this case, path selection is performed by the (n,*,*) cases, relaying between MRs everything that needs
      to be relayed, such as data packets, creating a tunnel MR and
   the intra-NEMO routing system for traffic flowing from the
      ingress interface, etc.

   This problem NEMO, and
   path selection is general in the sense that a multi-router site would
   require performed by the same level of router synchronization HA and intra-Home Network routing
   system for traffic flowing to the NEMO, as well.  It it is
   recommended presented next.

   A dynamic path selection mechanism is thus needed so that the issue this path
   could be looked at in IPv6 or Multi6 WG, and
   NEMO WG selected by:

   o  The HA: it should be able to contribute any NEMO specific requirements.

4.8  Prefix Delegation

   In select the (*,*,1) mobile network, path based on some
      information recorded in the same MNP must binding cache.

   o  The MR: it should be advertised able to select the
   MNNs through different paths.  This questions how to perform prefix
   delegation:

   o  For path based on router
      advertisements received on both its egress interfaces or on its
      ingress interfaces for the (n,*,*) case.

   In the (*,*,n) cases, the (*,n,1) mobile network, how multiple HAs would delegate paths available may differ in more
   than just the same MNP to tunnel between the mobile network.  For doing so, MR and the HAs may be
      somehow configured to advertise HA, since the same MNP.  (see also "HA
      Synchronization" usage of
   different prefixes may result in Section 4.6).

   o  For using different providers, hence in
   completely different paths between the (n,*,n) mobile network, how multiple mobile routers would
      be synchronized to advertise involved endpoints.  In this
   case, besides the same MNP down mechanisms presented in the NEMO-link.  For
      doing so, previous case,
   additional mechanisms for the MRs end to end path selection may be somehow configured to advertise the same
      MNP (see also "MR Synchronization" in Section 4.7).
   needed.  This could be configured manually, or dynamically.  Alternatively,
   prefix delegation mechanisms [17][18] could mechanism may be used closely related to ensure all
   routers advertise source address
   selection mechanisms within the same MNP.

   Prefix delegation hosts, since selecting a given
   address implies selecting a given prefix, which is currently being explored associated with a
   given ISP serving one of the home networks.

   In this case we need to consider additional mechanisms for path
   selection based on:

   o  The MNN: it should be able to select the path based on "Default
      Router Selection" (see [Section 6.3.6. Default Router Selection]
      [14]) in the NEMO WG.  Should (n,*,*) case or based on "Source Address Selection"
      in the WG decides (*,*,n) cases (see Section 4.8 of the present memo).

   o  The user or the application: e.g. in case where a user wants to standardize
      select a prefix delegation mechanism, particular access technology among the WG available
      technologies for reasons of cost or data rate.

   o  A combination of any of the above: a hybrid mechanism should be
      also consider its application available, e.g. one in which the HA, the MR, and/or the MNNs
      are coordinated to a multihomed mobile network.

4.9  Multiple Bindings/Registrations select the path.

   When a MR is configured with multiple Care-of Addresses, it is often
   necessary for it to bind these Care-of Addresses to bi-directional tunnels are available and possibly used
   simultaneously, the same MNP.

   This mode of operation may be either primary-secondary
   (one tunnel is precedent over the others and used as the default
   tunnel, while the other serves as a generic issue, since Mobile IPv6 nodes face a similar
   problem if back-up) or peer-to-peer (no
   tunnel has precedence over one another, they wish to bind multiple Care-of Addresses to are used with the same
   Home Address".
   priority).  This is better discussed in [7].  It is sufficient to
   note that solutions like [19] can solve this.

4.10  Source Address Selection

   In the (*,*,n) mobile networks, MNNs questions which bi-directional tunnel would be configured with
   multiple addresses.  Source address selection mechanisms are needed
   to decide
   selected, and based on which address to choose from.

   It may be desirable parameter (e.g. type of flow that goes
   into/out of the mobile network).

   The mechanisms for MNN to be able to acquire "preference"
   information on each MNP from the MRs.  This allows default address selection mechanism such as that specified in [9] among the different tunnels between
   the MR(s) and the HA(s) seems to be used.
   Further exploration on setting such "preference" information in
   Router Advertisement quite NEMO specific.  The
   mechanisms for selecting among different end to end paths based on performance of the bi-directional
   tunnel might prove
   address selection are similar to be useful.

   This is a general issue faced by any node when offered multiple
   prefixes.  It is recommended that the issue be examined by ones used in other WG
   (such multihoming
   scenarios, as IPv6).

4.11  Impact on those considered by Shim6/multi6 (e.g. [15]).

4.1.4  Re-Homing

   After an outage has been detected and an available alternative path
   has been identified, a re-homing event takes place, diverting the Routing Infrastructure

   In
   existent communications from one path to the (1,n,1) case with HAs located in distinct ISPs/ASs, multiple
   routes directed other.  Similar to the mobile network may be advertised
   previous items involved in the
   Internet.  Although this may provide shorter paths, it would add a
   burden to routing tables as multiple routes to process, the same prefix are
   injected into re-homing procedure
   heavily varies depending on the routing infrastructure.

   Such issues are investigated in NEMO multihoming configuration.

   o  For the MULTI6 working group at (*,*,1) configurations, the re-homing procedure involves
      only the IETF, MR(s) and the NEMO WG should adopt solutions designed there whenever
   appropriate.

4.12  Nested Mobile Networks

   When a multihomed mobile network is nested within another mobile
   network, it can result in very complex topologies.  For instance, a
   nested mobile network HA(s).  The re-homing procedure may be attached two different root-MRs, thus involve
      the aggregated network no exchange of additional BU messages.

      These mechanisms are shared between NEMO Basic Support and MIPv6.

   o  For the (*,*,n) cases, in addition to the previous mechanisms, end
      to end mechanisms may be required.  Such mechanisms may involve
      some form of end to end signaling or may simply rely on using
      different addresses for the communication.

      The involved mechanisms may be similar to those required for re-
      homing Shim6/multi6 communications (e.g. [15]).

4.2  Ingress Filtering

   Ingress filtering mechanisms [16][17] may drop the outgoing packets
   when multiple bi-directional tunnels end up at different HAs.  This
   could particularly occur if different MNPs are handled by different
   home agents.  If a packet with a source address configured from a
   specific MNP is tunnelled to a home agent that does not handle that
   specific MNP the packet may be discarded either by the home agent or
   by a border gateway in the home network.

   The ingress filtering compatibility issue is heavily dependent on the
   particular NEMO multihoming configuration:

   o  For the (*,*,1) cases, there is not such an issue, since there is
      a single MNP.

   o  For the (*,1,n) cases, there is not such a problem since there is
      a single HA, accepting all the MNPs.

   o  (*,n,n) are the cases where the ingress filtering presents some
      difficulties.  In the (1,n,n) case the problem is simplified
      because all the traffic from and to the NEMO is routed through a
      single MR.  Such configuration allows the MR to properly route
      packets respecting the constraints imposed by ingress filtering.
      The more complex case is the (n,n,n) case.  A simplified case
      occurs when all the prefixes are accepted by all the HAs, so that
      no problems occur with the ingress filtering.  However, this
      cannot be always assumed, resulting in the problem described
      below.

   As an example of how this could happen, consider the deployment
   scenario illustrated in Figure 9.  In Figure 9, the mobile network
   has two mobile routers MR1 and MR2, with home agents HA1 and HA2
   respectively.  Two bi-directional tunnels are established between the
   two pairs.  Each mobile router advertises a different MNP (P1 and
   P2).  MNP P1 is registered to HA1, and MNP P2 is registered to HA2.
   Thus, MNNs should be free to auto-configure their addresses on any of
   P1 or P2.  Ingress filtering could thus happen in two cases:

   o  If the two tunnels are available, MNN cannot forward packet with
      source address equals P1.MNN to MR2.  This would cause ingress
      filtering at HA2 to occur (or even at MR2).  This is contrary to
      normal Neighbor Discovery [14] practice that an IPv6 node is free
      to choose any router as its default router regardless of the
      prefix it chooses to use.

   o  If the tunnel to HA1 is broken, packets would be sent through the
      tunnel to HA1 are diverted through the tunnel to HA2.  If HA2 (or
      some border gateway in the domain of HA2) performs ingress
      filtering, packets with source address configured from MNP P1 may
      be discarded.

   Possible solutions to the ingress filtering incompatibility problem
   may be based on the following approaches:

   o  Some form of source address dependent routing, whether host-based
      and/or router-based where the prefix contained in the source
      address of the packet is considered when deciding which exit
      router to use when forwarding the packet.

   o  The usage of nested tunnels for (*,n,n) cases.  Appendix B
      describes one such approach.

   o  Deprecating those prefixes associated to non-available exit
      routers

               Prefix: P1 +-----+  +----+  +----------+   +-----+
                       +--| MR1 |--| AR |--|          |---| HA1 |
                       |  +-----+  +----+  |          |   +-----+
       IP:    +-----+  |                   |          | Prefix: P1
    P1.MNN or | MNN |--+                   | Internet |
      P2.MNN  +-----+  |                   |          | Prefix: P2
                       |  +-----+  +----+  |          |   +-----+
                       +--| MR2 |--| AR |--|          |---| HA2 |
               Prefix: P2 +-----+  +----+  +----------+   +-----+

                    Figure 9: An (n,n,n) mobile network

   The ingress filtering incompatibilities problems that appear in some
   NEMO multihoming configurations are similar to those considered in
   Shim6/multi6.

4.3  Media Detection

   In order to achieve benefits such as ubiquity or fault recovery, it
   is necessary for the mobile router to detect the availability of
   network media.  This may be achieved using layer 2 triggers [10], or
   other mechanism developed/recommended by the Detecting Network
   Attachment (DNA) Working Group [11][18].

   This is related to Section 4.1.1, since the ability to detect media
   availability would often implies the ability to detect media un-
   availability.

4.4  HA Synchronization

   In the (*,n,*) mobile networks, a single MNP would be registered at
   different HAs.  This gives rise to the following cases:

   o  Only one HA may actively advertise a route to the MNP,

   o  Multiple HAs at different domains may advertise a route to the
      same MNP

   This may pose a problem in the routing infrastructure as a whole if
   the HAs are located in different administrative domains.  The
   implications of this aspect needs further exploration.  Certain level
   of HA co-ordination may be required.  A possible approach is to adopt
   a HA synchronization mechanism such as that described in [19] and
   [20].  Such synchronization might also be necessary in a (*,n,*)
   mobile network, when a MR sends binding update messages to only one
   HA (instead of all HAs).  In such cases, the binding update
   information might have to be synchronized between HAs.  The mode of
   synchronization may be either primary-secondary or peer-to-peer.  In
   addition, when MNP is delegated to the MR (see Section 4.6), some
   level of co-ordination between the HAs may also be neceesary.

   This issue is a general mobility issue that will also have to be
   dealt with Mobile IPv6.  This issue should be dealt within a
   potentially forthcoming Monami6 WG.

4.5  MR Synchronization

   In the (n,*,*) mobile network, different MRs may need to be
   synchronized in order to take common decisions.  The mode of
   synchronization may be either primary-secondary or peer-to-peer.
   This may include:

   o  In the (n,*,1) case, advertising the same MNP (see also "prefix
      delegation" in Section 4.6).

   o  In the (n,*,n) case, a MR relaying the advertisement of the MNP
      from another failed MR.

   o  In the (n,*,*) cases, relaying between MRs everything that needs
      to be relayed, such as data packets, creating a tunnel from the
      ingress interface, etc.

   This problem is general in the sense that a multi-router site in the
   fixed network would require the same level of router synchronization.
   It is recommended that the issue be looked at in the IPv6 or Shim6
   WG, and the NEMO WG to contribute any NEMO specific requirement.

4.6  Prefix Delegation

   In the (*,*,1) mobile network, the same MNP must be advertised to the
   MNNs through different paths.  This questions how to perform prefix
   delegation:

   o  For the (*,n,1) mobile network, how multiple HAs would delegate
      the same MNP to the mobile network.  For doing so, the HAs may be
      somehow configured to advertise the same MNP. (see also "HA
      Synchronization" in Section 4.4).

   o  For the (n,*,n) mobile network, how multiple mobile routers would
      be synchronized to advertise the same MNP down the NEMO-link.  For
      doing so, the MRs may be somehow configured to advertise the same
      MNP (see also "MR Synchronization" in Section 4.5).

   This could be configured manually, or dynamically.  Alternatively,
   prefix delegation mechanisms [21] [22] could be used to ensure all
   routers advertise the same MNP.

   Prefix delegation is currently being explored in the NEMO WG.  Should
   the WG decides to standardize a prefix delegation mechanism, the WG
   should also consider its application to a multihomed mobile network.

4.7  Multiple Bindings/Registrations

   When a MR is configured with multiple Care-of Addresses, it is often
   necessary for it to bind these Care-of Addresses to the same MNP.

   This is a generic mobility issue, since Mobile IPv6 nodes face a
   similar problem.  This issue is discussed in [7].  It is sufficient
   to note that solutions like [23] can solve this for both Mobile IPv6
   and NEMO Basic Support.  This issue should be dealt within a
   potentially forthcoming Monami6 WG.

4.8  Source Address Selection

   In the (*,*,n) mobile networks, MNNs would be configured with
   multiple addresses.  Source address selection mechanisms are needed
   to decide which address to choose from.

   In addition, source address selection may be closely related to path
   selection procedures (see Section 4.1.3) and re-homing techniques
   (see Section 4.1.4).

   It may be desirable for MNNs to be able to acquire "preference"
   information on each MNP from the MRs.  This would allow default
   address selection mechanisms such as these specified in [24] to be
   used.  Further exploration on setting such "preference" information
   in Router Advertisement based on performance of the bi-directional
   tunnel might prove to be useful.

   This is a general issue faced by any node when offered multiple
   prefixes.  It is recommended that the issue be examined by other WG
   (such as IPv6).

4.9  Loop Prevention in Nested Mobile Networks

   When a multihomed mobile network is nested within another mobile
   network, it can result in very complex topologies.  For instance, a
   nested mobile network may be attached two different root-MRs, thus
   the aggregated network no longer forms a simple tree structure.  As
   such, a solution to prevent an infinite loop prevent an infinite loop of multiple mobile
   routers must be provided.

   This problem is specific to NEMO Basic Support.  It is recommended
   that the NEMO WG standardizes a solution to solve this problem (such
   as the use of a tree-spanning algorithm, or [25]).

4.10  Prefix Ownership

   When a (n,*,1) network splits, (i.e. the two MRs split themselves
   up), MRs on distinct links may try to register the only available
   MNP.  This cannot be allowed, as the HA has no way to know which node
   with an address configured from that MNP is attached to which MR.
   Some mechanism must be present for the MNP to either be forcibly
   removed from one (or all) MRs, or the implementors must not allow a
   (n,*,1) network to split.

   A possible approach to solving this problem is described in [26].

   This problem is specific to NEMO Basic Support.  It is recommended
   that the NEMO WG standardizes a solution to solve this problem, or
   specifies that the split of multiple mobile
   routers must a (n,*,1) network cannot be provided.

   This problem allowed
   without a router renumbering.

5.  Matrix [Issues,(x,y,z) Configuration]

   Several issues that might impact the deployment of NEMO with
   multihoming capabilities were identified in Section 4.  These are
   shown in the matrix below, for each of the eight multihoming
   configurations, together with indications of the WG(s) in which each
   issue is specific the most likely to be solved.

    +=================================================================+
    |                       # of MRs: | 1 | 1 | 1 | 1 | n | n | n | n |
    |                       # of HAs: | 1 | 1 | n | n | 1 | 1 | n | n |
    |                  # of Prefixes: | 1 | n | 1 | n | 1 | n | 1 | n |
    +=================================================================+
    | Fault Tolerance                 | * | * | * | * | * | * | * | * |
    +---------------------------------+---+---+---+---+---+---+---+---+
    | Failure Detection               |N/M|N/M|N/M|N/M|N/M|N/M| N | S |
    +---------------------------------+---+---+---+---+---+---+---+---+
    | Path Exploration                |N/M|N/M|N/M|N/M|N/M|N/M| N | S |
    +---------------------------------+---+---+---+---+---+---+---+---+
    | Path Selection                  | N |S/N| N |S/N| N |S/N| N |S/N|
    +---------------------------------+---+---+---+---+---+---+---+---+
    | Re-Homing                       |N/M| S |N/M| S |N/M| S |N/M| S |
    +---------------------------------+---+---+---+---+---+---+---+---+
    | Ingress Filtering               | . | . | . | t | . | . | . | N |
    +---------------------------------+---+---+---+---+---+---+---+---+
    | Media Detection                 | D | D | D | D | D | D | D | D |
    +---------------------------------+---+---+---+---+---+---+---+---+
    | HA Synchronization              | . | . |N/M|N/M| . | . |N/M|N/M|
    +---------------------------------+---+---+---+---+---+---+---+---+
    | MR Synchronization              | . | . | . | . | G | G | G | G |
    +---------------------------------+---+---+---+---+---+---+---+---+
    | Prefix Delegation               | . | . | N | N | N | N | N | N |
    +---------------------------------+---+---+---+---+---+---+---+---+
    | Multiple Binding/Registrations  | M | M | M | M | M | M | M | M |
    +---------------------------------+---+---+---+---+---+---+---+---+
    | Source Address Selection        | . | G | . | G | . | G | . | G |
    +---------------------------------+---+---+---+---+---+---+---+---+
    | Loop Prevention in Nested NEMO WG.  It is recommended that the  | N | N | N | N | N | N | N | N |
    +---------------------------------+---+---+---+---+---+---+---+---+
    | Prefix Ownership                | . | . | . | . | N | . | N | . |
    +=================================================================+
    N - NEMO Specific       M - MIPv6 Specific      G - Generic IPv6
    S - SHIM6 WG standardizes a solution to solve this problem (such as the use of
   a tree-spanning algorithm).

4.13  Split Mobile Networks

   When a (n,*,1) network splits, (i.e.  the two MRs split themselves
   up), the only available MNP will then be registered by two different
   MRs on different links.  This cannot be allowed, as the HA has no way
   to know which node with            D - DNA WG
    . - Not an address configured from that MNP is
   attached to which MR.  Some mechanism must be present for the MNP to
   either be forcibly removed from one (or all) MRs, or the implementors
   must not allow a (n,*,1) network to split.

   A possible approach to solving this problem is described in [20].

   This problem is specific to NEMO WG.  It Issue        t - trivial
    * - Fault Tolerance is recommended that the NEMO
   WG standardizes a solution to solve this problem, or specifies that
   the split combination of a (n,*,1) network cannot be allowed without a router
   renumbering.

5. Failure Detection, Path
        Exploration, Path Selection, and Re-Homing

6.  Conclusion

   This document memo is an analysis of multihoming in the context of network
   mobility.
   mobility under the operation of NEMO Basic Support.  The purpose of
   this memo is to investigate issues related investigate issues related to such a bi-directional
   tunneling mechanism when mobile networks are multihomed.  For doing
   so, a taxonomy was proposed to classify the mobile networks in eight
   possible multihomed configurations.  The issue were explained and
   were then summarized in a table showing under which multihoming
   configuration it applies, and which IETF working group is the best
   chartered to solve it.  This analysis will be helpful to such a bi-directional tunneling mechanism when mobile networks are
   multihomed.

   Several issues that might impact extend the deployment
   existing standards to support multihoming and to implementors of NEMO with
   multihoming capabilities were identified in Section 4. They include
   :

   1.  Path Survival

   2.  Path Availability

   3.  Ingress Filtering

   4.  Failure Detection

   5.  Media Detection

   6.  HA Synchronization
   Basic Support and multihoming-related mechanisms.

7.  MR Synchronization

   8.  Prefix Delegation

   9.  Multiple Binding/Registrations

   10.  Source Address Selection

   11.  Imapct on the Routing Infrastructure

   12.  Nested Mobile Networks

   13.  Split Mobile Networks.  IANA Considerations

   This study is a work in progress an informational document and need to be improved by a
   thorough study of each individual issues.  Particularly, this memo
   should be completed by a thorough threat analysis of does not require any IANA
   action.

8.  Security Considerations

   This is an informational document where the multihoming
   configurations under the operation of mobile network.  We will add security threat issues
   here as and when they NEMO Basic Support are encountered, such as
   analyzed.  Security considerations of these multihoming
   configurations, should they be different from those described in
   [21].  We also encourage interested people to contribute to this
   part.

6. that concern NEMO
   Basic Support, must be considered by forthcoming solutions.

9.  Acknowledgments

   The authors would like to thank people who have given valuable
   comments on various multihoming issues on the mailing list, and also
   those who have suggested directions in the 56th - 61st IETF Meetings.
   Sincere gratitude is also extended to Marcelo Bagnulo Braun for his
   extensive review and comments on the -00 version of this draft.
   The initial evaluation of NEMO Basic Support is a contribution from
   Julien Charbon.

7.

10.  References

10.1  Normative References

   [1]  Ernst, T., "Network Mobility Support Goals and Requirements",
         Internet-Draft draft-ietf-nemo-requirements-04,
        draft-ietf-nemo-requirements-04 (work in progress),
        February 2005.

   [2]  Manner, J. and M. Kojo, "Mobility Related Terminology",
        RFC 3753, June 2004.

   [3]  Ernst, T. and H. Lach, "Network Mobility Support Terminology",
         Internet-Draft draft-ietf-nemo-terminology-03,
        draft-ietf-nemo-terminology-03 (work in progress),
        February 2005.

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

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

10.2  Informative References

   [6]   Ernst, T., Montavont, N. and R. Wakikawa, "Goals and Benefits of Multihoming",
         Internet-Draft draft-ernst-generic-goals-and-benefits-01,
         draft-multihoming-generic-goals-and-benefits-00 (work in
         progress), February 2005. 2004.

   [7]   Montavont, N., Wakikawa, R. and T. R., Ernst, T., Ng, C., and K.
         Kuladinithi, "Analysis of Multihoming in Mobile IPv6",
         , January
         draft-montavont-mobileip-multihoming-pb-statement-04 (work in
         progress), June 2005.

   [8]   Ernst, T. and J. Charbon, "Multihoming with NEMO Basic
         Support", Proceedings First International Conference on Mobile
         Computing and Ubiquitous Networking (ICMU), January 2004.

   [9]   Draves, R., "Default Address Selection for Internet Protocol
         version 6 (IPv6)", RFC 3484, February 2003.

   [10]  Montavont, N., Noel, T. and M. Kassi-Lahlou, "MIPv6 for
         Multiple Interfaces",
         Internet-Draft draft-montavont-mobileip-mmi-00, July 2002.

   [11]  Narten, T., Nordmark, E.

   [8]   Arkko, J., "Failure Detection and W. Simpson, "Neighbor Discovery Locator Selection Design
         Considerations", draft-ietf-shim6-failure-detection-00 (work in
         progress), July 2005.

   [9]   Beijnum, I., "Shim6 Reachability Detection",
         draft-ietf-shim6-reach-detect-00 (work in progress), July 2005.

   [10]  Yegin, A., "Link-layer Event Notifications for IP Version 6 (IPv6)", RFC 2461, December 1998. Detecting
         Network Attachments", draft-ietf-dna-link-information-01 (work
         in progress), February 2005.

   [11]  Narayanan, S., "Detecting Network Attachment in IPv6 - Best
         Current Practices for hosts.", draft-ietf-dna-hosts-00 (work in
         progress), April 2005.

   [12]  Draves, R. and D. Thaler, "Default Router Preferences and
         More-Specific Routes",
         Internet-Draft draft-ietf-ipv6-router-selection-06, October
         2004.

   [13]  Yegin, A., "Link-layer Hints for Detecting Network
         Attachments", Internet-Draft draft-yegin-dna-l2-hints-01, draft-yegin-dna-l2-hints-01 (work in progress),
         February 2004.

   [14]

   [13]  Yegin, A., "Supporting Optimized Handover for IP Mobility
         -Requirements for Underlying  Systems",
         Internet-Draft draft-manyfolks-l2-mobilereq-02,
         draft-manyfolks-l2-mobilereq-02 (work in progress), July 2002.

   [14]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
         for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [15]  Bagnulo, M. and J. Arkko, "Functional decomposition of the
         multihoming protocol", draft-ietf-shim6-functional-dec-00 (work
         in progress), July 2005.

   [16]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", BCP 38, RFC 2827, May 2000.

   [17]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
         Networks", BCP 84, RFC 3704, March 2004.

   [18]  Narayanan, S., "Detecting Network Attachment in IPv6 - Best
         Current Practices for Routers", draft-ietf-dna-routers-00 (work
         in progress), July 2005.

   [19]  Wakikawa, R., Devarapalli, V. V., and P. Thubert, "Inter Home
         Agents Protocol (HAHA)",
         Internet-Draft draft-wakikawa-mip6-nemo-haha-01, draft-wakikawa-mip6-nemo-haha-01 (work
         in progress), February 2004.

   [16]

   [20]  Koh, B., Ng, C. C., and J. Hirano, "Dynamic Inter Home Agent
         Protocol", Internet-Draft draft-koh-mip6-nemo-dhap-00, draft-koh-mip6-nemo-dhap-00 (work in progress),
         July 2004.

   [17]

   [21]  Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix
         Delegation", RFC 3769, June 2004.

   [18]

   [22]  Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO",
         Internet-Draft draft-droms-nemo-dhcpv6-pd-01, February 2004.

   [19]
         draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005.

   [23]  Wakikawa, R., Uehara, K., Ernst, T. T., and K. Nagami, "Multiple
         Care-of Addresses Registration",
         Internet-Draft draft-wakikawa-mobileip-multiplecoa-04,
         draft-wakikawa-mobileip-multiplecoa-04 (work in progress),
         June 2005.

   [24]  Draves, R., "Default Address Selection for Internet Protocol
         version 6 (IPv6)", RFC 3484, February 2003.

   [25]  Thubert, P., "Nested Nemo Tree Discovery",
         draft-thubert-tree-discovery-02 (work in progress), July 2005.

   [20]

   [26]  Kumazawa, M., "Token based Duplicate Network Detection for
         split mobile network (Token  based DND)",
         Internet-Draft draft-kumazawa-nemo-tbdnd-01, October 2004.

   [21]
         draft-kumazawa-nemo-tbdnd-02 (work in progress), July 2005.

   [27]  Choi, S., "Threat for Multi-homed Mobile Networks",
         Internet-Draft draft-cho-nemo-threat-multihoming-00,
         draft-cho-nemo-threat-multihoming-00 (work in progress),
         February 2004.

   [28]  Montavont, N., Noel, T., and M. Kassi-Lahlou, "MIPv6 for
         Multiple Interfaces", draft-montavont-mobileip-mmi-00 (work in
         progress), July 2002.

   [29]  Draves, R. and D. Thaler, "Default Router Preferences and More-
         Specific Routes", draft-ietf-ipv6-router-selection-07 (work in
         progress), January 2005.

Authors' Addresses

   Chan-Wah Ng
   Panasonic Singapore Laboratories Pte Ltd
   Blk 1022 Tai Seng Ave #06-3530
   Tai Seng Industrial Estate
   Singapore  534415
   SG

   Phone: +65 65505420
   Email: cwng@psl.com.sg chanwah.ng@sg.panasonic.com

   Eun Kyoung Paik
   KT
   Portable Internet Team, Convergence Lab., KT
   17 Woomyeon-dong, Seocho-gu
   Seoul  137-792
   Korea

   Phone: +82-2-526-5233
   Fax:   +82-2-526-5200
   Email: euna@kt.co.kr
   URI:   http://mmlab.snu.ac.kr/~eun/
   Thierry Ernst
   WIDE at Keio University
   Jun Murai Lab., Keio University.
   K-square Town Campus, 1488-8 Ogura, Saiwa-Ku
   Kawasaki, Kanagawa  212-0054
   Japan

   Phone: +81-44-580-1600
   Fax:   +81-44-580-1437
   Email: ernst@sfc.wide.ad.jp
   URI:   http://www.sfc.wide.ad.jp/~ernst/

   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad, 30
   Leganes, Madrid  28911
   Spain

   Phone: +34 91624 8837
   Email: marcelo@it.uc3m.es

Appendix A.  Alternative Classifications Approach

A.1  Ownership-Oriented Approach

   An alternative approach to classifying multihomed mobile network is
   proposed by Erik Nordmark (Sun Microsystems) by breaking the
   classification of multihomed network based on ownership.  This is
   more of a tree-like top-down classification.  Starting from the
   control and ownership of the HA(s) and MR(s), there are two different
   possibilities: either (i) the HA(s) and MR(s) are controlled by a
   single entity, or (ii) the HA(s) and MR(s) are controlled by separate
   entities.  We called the first possibility the 'ISP Model', and the
   second the 'Subscriber/Provider Model'.

A.1.1  ISP Model

   The case of the HA(s) and MR(s) are controlled by the same entity can
   be best illustrated as an Internet Service Provider (ISP) installing
   mobile routers on trains, ships or planes.  It is up to the ISP to
   deploy a certain configuration of mobile network; all 8
   configurations as described in the Configuration-Oriented Approach
   are possible.  In the remaining portion of this document, when
   specifically referring to a mobile network configuration that is
   controlled by a single entity, we will add an 'ISP' prefix: for
   example: ISP-(1,1,1) or ISP-(1,N,N).

   When the HA(s) and MR(s) are controlled by a single entity (such as
   an ISP), the ISP can decide whether it wants to assign one or
   multiple MNPs to the mobile network just like it can make the same
   decision for any other link in its network (wired or otherwise).  In
   any case, the ISP will make the routing between the mobile networks
   and its core routers (such as the HAs) work.  This include not
   introducing any aggregation between the HAs which will filter out
   routing announcements for the MNP(es).

   To such ends, the ISP has various means and mechanisms.  For one, the
   ISP can run its Interior Gateway Protocol (IGP) over bi-directional
   tunnels between the MR(s) and HA(s).  Alternatively, static routes
   may be used with the tunnels.  When static routes are used, a
   mechanism  to test "tunnel liveness" might be necessary to avoid
   maintaining stale routes.  Such "tunnel liveness" may be tested by
   sending heartbeats signals from MR(s) to the HA(s).  A possibility is
   to simulate heartbeats using Binding Updates messages by controlling
   the "Lifetime" field of the Binding Acknowledgment message to force
   the MR to send Binding Update messages at regular interval.  However,
   a more appropriate tool might be the Binding Refresh Request message,
   though conformance to the Binding Refresh Request message may be less
   strictly enforced in implementations since it serves a somewhat
   secondary role when compared to Binding Update messages.

A.1.2  Subscriber/Provider Model

   The case of the HA(s) and MR(s) are controlled by the separate
   entities can be best illustrated with a subscriber/provider model,
   where the MRs belongs to a single subscriber and subscribes to one or
   more ISPs for HA services.  There is two sub-categories in this case:
   when the subscriber subscribes to a single ISP, and when the
   subscriber subscribes to multiple ISPs.  In the remaining portion of
   this document, when specifically referring to a mobile network
   configuration that is in the subscriber/provider model where the
   subscriber subscribes to only one ISP, we will add an 'S/P' prefix:
   for example: S/P-(1,1,1) or S/P-(1,n,n).  When specifically referring
   to a mobile network configuration that is in the subscriber/provider
   model where the subscriber subscribes to multiple ISPs, we will add
   an 'S/mP' prefix: for example: S/mP-(1,1,1) or S/mP-(1,n,n).

   Not all 8 configurations are likely to be deployed for the S/P and
   S/mP models.  For instance, it is unlikely to foresee a S/mP-(*,1,1)
   mobile network where there is only a single HA.  For the S/P model,
   the following configurations are likely to be deployed:

   o  S/P-(1,1,1): Single Provider, Single MR, Single HA, Single MNP

   o  S/P-(1,1,n): Single Provider, Single MR, Single HA, Multiple MNPs

   o  S/P-(1,n,1): Single Provider, Single MR, Multiple HAs, Single MNP

   o  S/P-(1,n,n): Single Provider, Single MR, Multiple HAs, Multiple
      MNPs

   o  S/P-(n,n,1): Single Provider, Multiple MRs, Single HA, Single MNP

   o  S/P-(n,1,n): Single Provider, Multiple MRs, Single HA, Multiple
      MNPs

   o  S/P-(n,n,1): Single Provider, Multiple MRs, Multiple HAs, Single
      MNP

   o  S/P-(n,n,n): Single Provider, Multiple MRs, Multiple HAs, Multiple
      MNPs

   For the S/mP model, the following configurations are likely to be
   deployed:

   o  S/mP-(1,n,1): Multiple Providers, Single MR, Multiple HAs, Single
      MNP

   o  S/mP-(1,n,n): Multiple Providers, Single MR, Multiple HAs,
      Multiple MNPs

   o  S/mP-(n,n,n): Multiple Providers, Multiple MRs, Multiple HAs,
      Multiple MNPs

   When the HA(s) and MR(s) are controlled by different entities, it is
   more likely the scenario where the MR is controlled by one entity
   (i.e. the subscriber), and the MR is establishing multiple
   bi-directional bi-
   directional tunnels to one or more HA(s) provided by one or more
   ISP(s).  In such case, it is unlikely for the ISP to run IGP over the
   bi-directional tunnel, since ISP would most certainly wish to retain
   full control of its routing domain.

A.2  Problem-Oriented Approach

   A third approach is proposed by Pascal Thubert (Cisco System).  This
   focused on the problems of multihomed mobile networks rather than the
   configuration or ownership.  With this approach, there is a set of 4
   categories based on two orthogonal parameters: the number of HAs, and
   the number of MNPs advertised.  Since the two parameters are
   orthogonal, the categories are not mutually exclusive.  The four
   categories are:

   o  Tarzan: Single HA for Different Care-of Addresses of Same MNP

      This is the case where one mobile router registers different
      Care-of Addresses to the same home agent for the same subnet
      prefix.  This is equivalent to the case of y=1, i.e. the (1,1,*)
      mobile network.

   o  JetSet: Multiple HAs for Different Care-of Addresses of Same MNP

      This is the case where the mobile router registers different
      Care-of Addresses to different home agents for the same subnet
      prefix.  This is equivalent to the case of y=n, i.e. the (1,n,*)
      mobile network.

   o  Shinkansen: Single MNP Advertised by MR(s)

      This is the case where one MNP is announced by different MRs.
      This is equivalent to the case of x=n and z=1, i.e. the (n,*,1)
      mobile network.

   o  DoubleBed: Multiple MNPs Advertised by MR(s)

      This is the case where more than one MNPs are announced by the
      different MRs.  This is equivalent to the case of x=n and z=n,
      i.e. the (n,*,n) mobile network.

Appendix B.  Nested Tunneling for Fault Tolerance

   In order to utilize the additional robustness provided by
   multihoming, MRs that employ bi-directional tunneling with their HAs
   should dynamically change their tunnel exit points depending on the
   link status.  For instance, if a MR detects that one of its egress
   interface is down, it should detect if any other alternate route to
   the global Internet exists.  This alternate route may be provided by
   any other MRs connected to one of its ingress interfaces that has an
   independent route to the global Internet, or by another active egress
   interface the MR itself possess.  If such an alternate route exists,
   the MR should re-establish the bi-directional tunnel using this
   alternate route.

   In the remaining part of this section, we will attempt to investigate
   methods of performing such re-establishment of bi-directional
   tunnels.  This method of tunnel re-estblishment is particularly
   useful for the (*,n,n) NEMO configuration.  It is not the objective
   of this memo to specify a new protocol specifically tailored to
   provide this form of re- establishments.  Instead, we will limit
   ourselves to currently available mechanisms specified in Mobile IPv6
   [5] and Neighbor Discovery in IPv6 [11]. [14].

B.1  Detecting Presence of Alternate Routes

   To actively utilize the robustness provided by multihoming, a MR must
   first be capable of detecting alternate routes.  This can be manually
   configured into the MR by the administrators if the configuration of
   the mobile network is relatively static.  It is however highly
   desirable for MRs to be able to discover alternate routes
   automatically for greater flexibility.

   The case where a MR possesses multiple egress interface (bound to the
   same HA or otherwise) should be trivial, since the MR should be able
   to "realize" it has multiple routes to the global Internet.

   In the case where multiple MRs are on the mobile network, each MR has
   to detect the presence of other MR.  A MR can do so by listening for
   Router Advertisement message on its *ingress* interfaces.  When a MR
   receives a Router Advertisement message with a non-zero Router
   Lifetime field from one of its ingress interfaces, it knows that
   another MR which can provide an alternate route to the global
   Internet is present in the mobile network.

B.2  Re-Establishment of Bi-Directional Tunnels

   When a MR detects that the link by which its current bi-directional
   tunnel with its HA is using is down, it needs to re-establish the
   bi-directional bi-
   directional tunnel using an alternate route detected.  We consider
   two separate cases here: firstly, the alternate route is provided by
   another egress interface that belongs to the MR; secondly, the
   alternate route is provided by another MR connected to the mobile
   network.  We refer to the former case as an alternate route provided
   by an alternate egress interface, and the latter case as an alternate
   route provided by an alternate MR.

B.2.1  Using Alternate Egress Interface

   When an egress interface of a MR loses the connection to the global
   Internet, the MR can make use of its alternate egress interface
   should it possess multiple egress interfaces.  The most direct way to
   do so is for the mobile router to send a binding update to the home
   agent of the failed interface using the Care-of Address assigned to
   the alternate interface in order to re-establish the bi-directional
   tunneling using the Care-of Address on the alternate egress
   interface.  After a successful binding update, the MR encapsulates
   outgoing packets through the bi-directional tunnel using the
   alternate egress interface.

   The idea is to use the global address (most likely a Care-of Address)
   assigned to an alternate egress interface as the new (back-up)
   Care-of Address of the mobile router to re-establish the
   bi-directional bi-
   directional tunneling with its home agent.

B.2.2  Using Alternate Mobile Router

   When the MR loses a connection to the global Internet, the MR can
   utilize a route provided by an alternate MR (if one exists) to
   re-establish re-
   establish the bi-directional tunnel with its HA.  First, the MR has
   to obtain a Care-of Address from the alternate MR (i.e. attaches
   itself to the alternate MR).  Next, it sends binding update to its HA
   using the Care-of Address obtained from the alternate MR.  From then
   on, the MR can encapsulates outgoing packets through the
   bi-directional bi-
   directional tunnel using via the alternate MR.

   The idea is to obtain a Care-of Address from the alternate MR and use
   this as the new (back-up) Care-of Address of the MR to re-establish
   the bi-directional tunneling with its HA.

   Note that every packet sent between MNNs and their correspondent
   nodes will experience two levels of encapsulation.  First level of
   tunneling occurs between a MR which the MNN uses as its default
   router and the MR's HA.  The second level of tunneling occurs between
   the alternate MR and its HA.

B.3  To Avoid Tunneling Loop

   The method of re-establishing the bi-directional tunnel as described
   in Appendix B.2 may lead to infinite loops of tunneling.  This
   happens when two MRs on a mobile network lose connection to the
   global Internet at the same time and each MR tries to re-establish
   bi-directional tunnel using the other MR.  We refer to this
   phenomenon as tunneling loop.

   One approach to avoid tunneling loop is for a MR that has lost
   connection to the global Internet to insert an option into the Router
   Advertisement message it broadcasts periodically.  This option serves
   to notify other MRs on the link that the sender no longer provides
   global connection.  Note that setting a zero Router Lifetime field
   will not work well since it will cause MNNs that are attached to the
   MR to stop using the MR as their default router too  (in which case,
   things are back to square one).

Appendix C.  Change Log

   o  This draft is an update of draft-ng-nemo-multihoming-issues-03.txt
      which is itself a merge of 3 previous drafts
      draft-ng-nemo-multihoming-issues-02.txt,
      draft-eun-nemo-multihoming-problem-statement-00.txt, and
      draft-charbon-nemo-multihoming-evaluation-00.txt

   o  Changes from draft-ietf-nemo-multihoming-issues-02 to -03:

      *  Enlisted Marcelo Bagnulo as co-author

      *  Restructuring of Section 4:

         +  Re-named 'Path Survival' to 'Fault Tolerance'

         +  Moved 'Path Failure Detection' and 'Path Selection' as sub-
            issues of 'Fault Tolerance'

         +  Added 'Path Exploration' and 'Re-homing' as sub-issues of
            'Fault Tolerance'

         +  Removed 'Impact on Routing Infrastructure'

      *  Breaking references into Normative and Informative

   o  Changes from draft-ietf-nemo-multihoming-issues-01 to -02:

      *  Added recommendations/suggestion of which WG each issue should
         be addressed as pointed out in 61st IETF.

      *  Minor updates on references.

   o  Changes from draft-ietf-nemo-multihoming-issues-00 to -01:

      *  Replaced NEMO-Prefix with MNP as decided by the WG at 60th IETF

      *  Addressed Issue #1 in Section 1: Added a note to remind readers
         that IPv6 is implicitly assumed

      *  Addressed Issue #3 in Section 2.3: Removed text on assumption

      *  Addressed Issue #6 in Section 3.1: Added benefits

      *  Addressed Issue #7 in Section 3.2: Modified text

      *  Addressed Issue #9 in Section 4.3: 4.2: Modified text
      *  Addressed Issue #10 in Section 4.4: 4.1.1: Added paragraph on other
         failure modes

      *  Addressed Issue #10: New Section 4.5 4.3 on media detection

      *  Addressed Issue #11 in Section 4.11: modified text

   o  Changes from draft-ng-multihoming-issues-03 to
      draft-ietf-nemo-multihoming-issues-00:

      *  Expanded "Problem Statement" (Section 4)

      *  Merged "Evaluation" Section into "Problem Statement"
         (Section 4)

      *  Cleaned up description in "Classification" (Section 2), and
         clearly indicate in each classification, what are the
         multihomed entities

      *  Re-organized "Deployment Scenarios and Prerequisites"
         (Section 3), and created the "Prerequisites" sub-section.

   o  Changes from draft-ng-multihoming-issues-02 to
      draft-ng-multihoming-issues-03:

      *  Merged with draft-eun-nemo-multihoming-problem-statement (see
         "Problem Statement" (Section 4))

      *  Included conclusions from
         draft-charbon-nemo-multihoming-evaluation-00

      *  Re-organized some part of "Benefits/Issues of Multhoming Multihoming in
         NEMO" to "Problem Statement" (Section 4)

      *  Removed lots of text to be in sync with [6].

      *  Title changed from "Multihoming Issues in NEMO Basic Support"
         to "Analysis of Multihoming in NEMO"

      *  Changed (w,x,y) to (x,y,z) in taxonomy.

      *  Moved alternative approaches of classification to Appendix

      *  Creation of this Change-Log itself ;-)

Intellectual Property Statement

   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.

Disclaimer of Validity

   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 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.

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

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