RFC 4980

Analysis of Multihoming in Network Mobility Support

📅 published October 2007, from ietf

Analysis of Multihoming in Network Mobility Support 🦋

Okay bestie, this is RFC 4980 💖 It came out of the Network Working Group in October 2007, and it's Informational, so it's giving "here's some good info" rather than "here's a standard" ✨ It doesn't specify an Internet standard of any kind.

  • Authors: C. Ng (Panasonic Singapore Labs), T. Ernst (INRIA), E. Paik (KT), and M. Bagnulo (UC3M) 🫶
  • Category: Informational 🍓
  • Date: October 2007 🌸
  • Obsoletes or updates: nothing! The title block doesn't list any RFCs it obsoletes or updates 🙈

Status of This Memo 🎀

This memo gives information to the Internet community. It is not an Internet standard, not even a little. Distribution of this memo is unlimited, so share it with everyone 💅

Abstract 🧚

This doc is an analysis of multihoming in the context of network mobility (NEMO) in IPv6. Mobile networks can be multihomed in a lot of different situations, so the authors propose a taxonomy to sort the possible configurations into categories 🌈 It then describes the deployment scenarios for multihomed mobile networks, plus the issues that show up when network mobility is supported by RFC 3963 (NEMO Basic Support). Last but not least, it offers recommendations for dealing with those issues 🔥

Table of Contents 📚

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

   3.  Deployment Scenarios and Prerequisites . . . . . . . . . . . . 11
     3.1.  Deployment Scenarios . . . . . . . . . . . . . . . . . . . 11
     3.2.  Prerequisites  . . . . . . . . . . . . . . . . . . . . . . 13
   4.  Multihoming Issues . . . . . . . . . . . . . . . . . . . . . . 14
     4.1.  Fault Tolerance  . . . . . . . . . . . . . . . . . . . . . 14
       4.1.1.  Failure Detection  . . . . . . . . . . . . . . . . . . 15
       4.1.2.  Path Exploration . . . . . . . . . . . . . . . . . . . 16
       4.1.3.  Path Selection . . . . . . . . . . . . . . . . . . . . 17
       4.1.4.  Re-Homing  . . . . . . . . . . . . . . . . . . . . . . 19
     4.2.  Ingress Filtering  . . . . . . . . . . . . . . . . . . . . 19
     4.3.  HA Synchronization . . . . . . . . . . . . . . . . . . . . 21
     4.4.  MR Synchronization . . . . . . . . . . . . . . . . . . . . 22
     4.5.  Prefix Delegation  . . . . . . . . . . . . . . . . . . . . 23
     4.6.  Multiple Bindings/Registrations  . . . . . . . . . . . . . 23
     4.7.  Source Address Selection . . . . . . . . . . . . . . . . . 23
     4.8.  Loop Prevention in Nested Mobile Networks  . . . . . . . . 24
     4.9.  Prefix Ownership . . . . . . . . . . . . . . . . . . . . . 24
     4.10. Preference Settings  . . . . . . . . . . . . . . . . . . . 25
   5.  Recommendations to the Working Group . . . . . . . . . . . . . 26
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 28
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 29
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 29
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 29
   Appendix A.  Alternative Classifications Approach  . . . . . . . . 32
     A.1.  Ownership-Oriented Approach  . . . . . . . . . . . . . . . 32
       A.1.1.  ISP Model  . . . . . . . . . . . . . . . . . . . . . . 32
       A.1.2.  Subscriber/Provider Model  . . . . . . . . . . . . . . 33
     A.2.  Problem-Oriented Approach  . . . . . . . . . . . . . . . . 34
   Appendix B.  Nested Tunneling for Fault Tolerance  . . . . . . . . 35
     B.1.  Detecting Presence of Alternate Routes . . . . . . . . . . 35
     B.2.  Re-Establishment of Bi-Directional Tunnels . . . . . . . . 36
       B.2.1.  Using Alternate Egress Interface . . . . . . . . . . . 36
       B.2.2.  Using Alternate Mobile Router  . . . . . . . . . . . . 36
     B.3.  To Avoid Tunneling Loop  . . . . . . . . . . . . . . . . . 37
     B.4.  Points of Considerations . . . . . . . . . . . . . . . . . 37

1. Introduction ✨

The design goals and objectives of Network Mobility (NEMO) support in IPv6 are laid out in [1], and the terminology is described in [2] and [3]. NEMO Basic Support (RFC 3963) [4] is the solution the NEMO Working Group came up with to give continuous Internet connectivity to nodes in an IPv6 mobile network, like an in-vehicle embedded IP network 🚗💖 It works by setting up bi-directional tunnels between the mobile routers (MRs) that connect the mobile network (NEMO) to the Internet and their respective home agents (HAs). It's basically the same idea as Mobile IPv6 [5], the solution for host mobility support. The best part is that NEMO Basic Support is totally transparent to nodes behind the MR (the mobile network nodes, or MNNs), so MNNs don't have to do anything for mobility management 🫶

However, mobile networks are usually connected over wireless and therefore less reliable links, and there could be lots of nodes behind the MR too 😭 So losing connectivity, or failing to connect to the Internet at all, hits way harder than it does for a single mobile node. The scenarios in [6] show that permanent access for mobile networks typically needs several interfaces and technologies 🌸 This is especially useful for Intelligent Transport Systems (ITS) applications, since vehicles move across far-apart geographical locations. Access can come through different access technologies (e.g., Wimax, Wifi, 3G) and through different access operators, which is giving main character energy 👑

As specified in Section 5 of the NEMO Basic Support Requirements [1] (R.12), the NEMO WG must ensure that NEMO Basic Support does not prevent mobile networks from being multihomed. That means there's more than one point of attachment between the mobile network and the Internet (see the definitions in [3]). This can happen when:

  • an MR has multiple egress interfaces, or
  • the mobile network has multiple MRs, or
  • the mobile network is associated with multiple HAs, or
  • multiple global prefixes are available in the mobile network.

Using NEMO Basic Support, this would translate into having multiple bi-directional tunnels between the MR(s) and the corresponding HA(s), and it may result in multiple Mobile Network Prefixes (MNPs) being available to the MNNs 🧚 However, NEMO Basic Support doesn't specify any particular mechanism for managing multiple bi-directional tunnels, so it's kind of a mess 🙈 The objectives of this memo are therefore multifold:

  • to determine all the potential multihomed configurations for a NEMO, and then figure out which of these might be useful in a real-life scenario;
  • to capture issues that may stop some multihomed configurations from being supported under the operation of NEMO Basic Support. Not being supported doesn't necessarily mean they won't work with NEMO Basic Support, since it may be up to the implementors to make it work (hopefully this memo helps those implementors 🫶);
  • to decide which issues are worth solving and which WG is the most appropriate one to address them;
  • to identify potential solutions to the issues found earlier.

To hit these objectives, a taxonomy for classifying the possible multihomed configurations is described in Section 2 🦋 Deployment scenarios, their benefits, and the requirements to meet those benefits are illustrated in Section 3. Then the related issues get studied in Section 4. The issues are summarized in a matrix for each deployment scenario, and recommendations on which issues should be worked on, and where, are made in Section 5. The memo wraps up with an evaluation of NEMO Basic Support for multihomed configurations. Alternative classifications are outlined in the Appendix 💜

The readers should note that this document considers multihoming only from the point of view of an IPv6 environment. To understand this memo, you're expected to already know the documents cited above: the NEMO terminology as defined in [2] (Section 3) and [3], Motivations and Scenarios for Multihoming [6], Goals and Requirements of Network Mobility Support [1], and the NEMO Basic Support specification [4]. The goals and benefits of multihoming discussed in [6] apply to fixed nodes, mobile nodes, fixed networks, and mobile networks, so it's not just a mobile thing 🌈

2. Classification ✨

okay bestie, so mobile networks can be multihomed in a LOT of different ways 🌈 and we need a clean system to sort them, or everyone's gonna be talking past each other 💀 this section gives us a Configuration-Oriented taxonomy 🎀 (there are two other ways to sort these in Appendix A.1 and Appendix A.2 if you're curious 👀)

the vibe: a multihomed setup depends on how many MRs there are, how many egress interfaces, Care-of Addresses (CoA), and Home Addresses (HoA) the MRs have, and how many prefixes (MNPs) the mobile network nodes can use 🦋 we use three key parameters to tell configs apart, and each one gets written as a 3-tuple (x,y,z) ✨

  • x is the number of MRs:
    • x=1 means the mobile network has only a single MR, presumably multihomed 🫶
    • x=n means the mobile network has more than one MR
  • y is the number of HAs tied to the whole mobile network:
    • y=1 means a single HA is assigned to the mobile network
    • y=n means multiple HAs are assigned to the mobile network
  • z is the number of MNPs available within the NEMO:
    • z=1 means a single MNP is available in the NEMO
    • z=N means multiple MNPs are available in the NEMO

these three are pretty much orthogonal to each other 🧚 which means changing one doesn't force the others to change, so you get all sorts of different (x,y,z) combos 💅

so there are a total of 8 possible configurations, and we'll go through each one in the sub-sections below 🌸 one thing to keep in your head: in every single one of those 8 cases, the MR may be multihomed if either (i) multiple prefixes are available (on the home link, or on the foreign link), or (ii) the MR has multiple interfaces ✨ when that happens, the MR ends up with multiple (HoA,CoA) pairs 💖 issues about a multihomed MR are covered in [7] too 📚

also, when we say "MNP(s) is/are available in the NEMO," those MNP(s) can either be explicitly announced by the MR via router advertisement, or handed out through Dynamic Host Configuration Protocol (DHCP) [8] 🎀 both are valid ways to get them, so don't let the wording trip you up 😭

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

this is the simplest one, the (1,1,1) config 🍓 there's only one MR, it's tied to a single HA, and a single MNP is available in the NEMO 🦋 the MR and the AR are connected to the Internet through one Access Router (AR) ✨

so when does it become multihomed? at least one of these has to be true (this is the one that counts!) 💅:

  • the MR has multiple interfaces, so it has multiple CoAs 🌈
  • multiple global prefixes are available on the foreign link, so it has multiple CoAs 🫶
  • multiple global prefixes are available on the home link, so the MR has more than one path to reach the HA 👑

quick tea ☕: multiple prefixes on the foreign link don't affect the MNPs at all 🙈 MNPs are independent of whatever prefixes are on the link the MR is sitting on, so those foreign-link prefixes never get announced on the NEMO link ✨ for multiple prefixes on the home link, they only get announced on the NEMO link if the MR is set up to do that 💜 and in this (1,1,1) config, only one MNP is announced, period 💅

then a bi-directional tunnel gets set up between each (HoA,CoA) pair 🔥

and the MNNs? they're (usually) not multihomed 🥺 since they'd configure a single global address from the one MNP on the link they're 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

now the (1,1,n) config 🌸 still one MR, still one HA, but this time two or more MNPs are available in the NEMO 💖

the MR can still be multihomed, same deal as Section 2.1 🫶 and when it is, a bi-directional tunnel gets established between each (HoA,CoA) pair 🦋

the MNNs are multihomed here, bestie 😭 because several MNPs are available on the link they're attached to 🌈 so they'd each configure a global address from every MNP on that 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

(1,n,1) is giving "one MR, many HAs, one MNP" 👑 the MR is tied to multiple HAs, and a single MNP is available in the NEMO 🧚

the NEMO is multihomed because it has multiple HAs 🔥 and the conditions from Section 2.1 might also be true for the MR 💅 when they are, a bi-directional tunnel gets set up between each (HoA,CoA) pair 🦋

the MNNs? (usually) not multihomed 🥺 same as before, they configure a single global address from the single MNP on their link 🫶

                                          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

(1,n,n) is the "one MR, many HAs, many MNPs" combo 🍓 only one MR, but it's tied to multiple HAs AND more than one MNP is available in the NEMO 💖

the MR is multihomed since it has multiple HAs ✨ and the Section 2.1 conditions may also hold 🌸 a bi-directional tunnel gets established between each (HoA,CoA) pair then 🎀

MNNs are multihomed here because several MNPs are on their link 🫶 so they each configure a global address with every MNP available on that link 🦋

                                         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

(n,1,1) has more than one MR advertising global routes 💅 but the MRs are all associated with a single HA, and there's a single MNP available in the NEMO 🌈

the NEMO is multihomed since it has multiple MRs 🫶 and the Section 2.1 conditions might also apply to each MR ✨ when they do, a bi-directional tunnel gets established between each (HoA,CoA) pair 💜

MNNs: (usually) not multihomed 🥺 they configure a single global address from the single MNP on their link, so no drama 🦋

                        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

(n,1,n) is a full-on main character moment 👑 more than one MR, multiple global routes advertised by the MRs, AND multiple MNPs available within the NEMO 🔥

the NEMO is multihomed since it has multiple MRs 💅 and the Section 2.1 conditions may also hold for each MR 🌸 a bi-directional tunnel gets set up between each (HoA,CoA) pair 🎀

MNNs are multihomed because several MNPs are on their link ✨ so they configure a global address with each MNP available there 🫶

                        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

(n,n,1) has more than one MR advertising multiple global routes 🌈 and the mobile network is associated with multiple HAs at the same time, with a single MNP available in the NEMO 👑

the NEMO is multihomed since it has multiple MRs and HAs 🦋 and the Section 2.1 conditions may also hold for each MR 💅 when they do, a bi-directional tunnel gets established between each (HoA,CoA) pair ✨

MNNs (usually) aren't multihomed 🥺 they configure a single global address from the single MNP on the link they're 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 🌈

okay so the (n,n,n) config is giving maximum multihoming energy 🔥 You've got multiple MRs advertising different global routes, and the mobile network is hooked up to more than one HA at the same time. On top of that, several MNPs are available in the NEMO.

The NEMO is multihomed because it has multiple MRs and HAs, but it can also get the conditions from Section 2.1 on each MR. A bi-directional tunnel would then be set up for each (HoA,CoA) pair 💜

The MNNs are multihomed too, because several MNPs are available on the link they're attached to. So each MNN would configure a global address with every MNP on that link ✨

                    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 🎀

okay now we get into the good stuff: what this looks like IRL and what you actually need to make it work 🦋 The following generic goals and benefits of multihoming are discussed in [6]:

  1. Permanent and Ubiquitous Access
  2. Reliability
  3. Load Sharing
  4. Load Balancing/Flow Distribution
  5. Preference Settings
  6. Aggregate Bandwidth

We're gonna look at these from a NEMO angle, with one typical example for each case in the taxonomy. After that we'll talk about the prerequisites needed to hit them 💅

3.1. Deployment Scenarios 🚆

x=1: Multihomed mobile networks with a single MR

  • Example 1:
    • MR with dual/multiple access interfaces (e.g., 802.11 and GPRS capabilities). This is a (1,1,*) if a single HA is used for both. If two independent HAs are used, this is a (1,n,n) configuration.
    • Benefits: Ubiquitous Access, Reliability, Load Sharing, Preference Settings, Aggregate Bandwidth.

x=n: Multihomed mobile networks with multiple MRs

  • Example 1:
    • Train with one MR in each car, all served by the same HA, thus a (n,1,*) configuration. Alternatively, the train company might use different HAs, in different countries, thus a (n,n,n) configuration.
    • Benefits: Ubiquitous Access, Reliability, Load Sharing, Aggregate Bandwidth.
  • Example 2:
    • Wireless personal area network with a GPRS-enabled phone and a WiFi-enabled PDA. This is a (n,n,n) configuration if different HAs are also used.
    • Benefits: Ubiquitous Access, Reliability, Preference Settings, Aggregate Bandwidth.

y=1: Multihomed mobile networks with a single HA

  • Example:
    • Most single HA cases in above examples.

y=n: Multihomed mobile networks with multiple HAs

  • Example 1:
    • Most multiple HAs cases in above examples.
  • Example 2:
    • Transatlantic flight with a HA in each continent. This is a (1,n,1) configuration if there is only one MR.
    • Benefits: Ubiquitous Access, Reliability, Preference Settings (reduced delay, shortest path).

z=1: Multihomed mobile networks with a single MNP

  • Example:
    • Most single HA cases in above examples.

z=n: Multihomed mobile networks with multiple MNPs

  • Example 1:
    • Most multiple HAs cases in above examples.
  • Example 2:
    • Car with a prefix taken from home (personal traffic is transmitted using 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,) configuration.
    • Benefits: Preference Settings

3.2. Prerequisites 🧩

In this section we state the requirements needed to get the expected 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:

  • Permanent and Ubiquitous Access: At least one bi-directional tunnel must be available at any point in time.
  • Reliability: 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.
  • Load Sharing and Load Balancing: Multiple tunnels must be maintained simultaneously.
  • Preference Settings: Implicitly, multiple tunnels must be maintained simultaneously if preferences are set for deciding which of the available bi-directional tunnels should be used. To allow user/application to set the preference, a mechanism should be provided to the user/application for the notification of the availability of multiple bi-directional tunnels, and perhaps also to set preferences. A similar mechanism should also be provided to network administrators to manage preferences.
  • Aggregate Bandwidth: Multiple tunnels must be maintained simultaneously in order to increase the total aggregated bandwidth available to the mobile network.

4. Multihoming Issues 🔥

As we saw in the last section, multiple bi-directional tunnels need to be maintained either sequentially (e.g., for fault tolerance) or simultaneously (e.g., for load sharing) 👑

Sometimes 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 tunnels (load sharing, load balancing) 🌸

So, depending on the configuration, the issues below may need to be addressed sometimes dynamically. For each issue, potential ways to solve the problem are investigated 🧚

4.1. Fault Tolerance 💖

One of the goals of multihoming is the provision of fault tolerance capabilities. To provide these, a set of tasks need to be performed, including: failure detection, alternative available path exploration, path selection, and re-homing of established communications. These are also discussed in [9] by the Shim6 WG. In the following sub-sections, we look at these issues in the specific context of NEMO, rather than the general Shim6 perspective in [9]. In addition, in some scenarios, it may also be required to provide the mechanisms for coordination between different HAs (see Section 4.3) and also the coordination between different MRs (see Section 4.4).

4.1.1. Failure Detection 🔍

It is expected for faults to occur more readily at the edge of the network (i.e., the mobile nodes) due to the use of wireless connections. Efficient fault detection mechanisms are necessary to recover in a timely fashion ⭐

Depending on the NEMO configuration considered, the failure protection domain greatly varies. In some configurations, the protection domain provided by NEMO multihoming is limited to the links between the MR(s) and the HA(s). In other configurations, the protection domain allows recovery from failures in other parts of the path, so an end-to-end failure detection mechanism is required.

The failure detection capabilities required for each configuration are detailed below:

  • For the (1,1,*) cases, multiple paths are available between a single MR and a single HA. All the traffic to and from the NEMO flows through the MR and HA. Failure detection mechanisms need only to be executed between these two devices. This is a NEMO-/MIPv6-specific issue.
  • For the (n,1,*) cases, there is a single HA, so all the traffic to and from the NEMO will flow through it. The failure detection mechanisms need to be able to detect failure in the path between the used MR and the only HA. Hence, the failure detection mechanism needs only to involve the HA and the MRs. This is a NEMO/MIPv6 specific issue.
  • For the (n,n,*) cases, there are multiple paths between the different HAs and the different MRs. Moreover, the HAs may be located in different networks, and have different Internet access links. This implies that changing the HA used may not only allow recovering from failures in the link between the HA and the MR, but also from other failure modes, affecting other parts of the path. In this case, an end-to-end failure detection mechanism would provide additional protection. However, a higher number of failures is likely to occur in the link between the HA and the MR, so it may be reasonable to provide optimized failure detection mechanisms for this failure mode. The (n,n,n) case is hybrid, since selecting a different prefix results in a change of path. For this case, the Shim6 protocols (such as those discussed in [9]) may be useful.

Most of the above cases involve the detection of tunnel failures between HA(s) and MR(s). This is no different from the case of failure detection between a mobile host and its HA(s). As such, a solution for MIPv6 should apply to NEMO as well. For case (n,*,*), an MR synchronization solution (see Section 4.4) should be able to complement a MIPv6 failure detection solution to achieve the desired functionality for NEMO 🫧

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

  • On the MR's side, the MR can rely on router advertisements from access routers, or other layer-2 trigger mechanisms to detect faults, e.g., [10] and [11].
  • On the HA's side, it is more difficult to detect tunnel failures. For an ISP deployment model, the HAs and MRs can use proprietary methods (such as constant transmission of heartbeat signals) to detect failures and check tunnel liveness. In the subscriber model (see Appendix A.2: S/P model), a lack of standardized "tunnel liveness" protocol means that it is harder to detect failures.

A possible method is 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 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 and processing overhead, since binding updates sent to HAs must be protected (and possibly encrypted) with security associations 🍓

4.1.2. Path Exploration 🗺️

Okay bestie, once a failure hits the path you're currently using, you have to go find a backup path that actually works 🔍. This is closely related to failure detection, because the paths you explore have to be alternatives to the broken one. They're still different jobs though! Failure detection watches the path you're on right now, while path exploration checks the other paths, not the one you're actually sending packets through 🦋. Both can lean on a reachability or keepalive test exchange, but failure detection also gets info from upper layers (like positive or negative feedback from TCP), lower layers (like an interface being down), and network layer stuff (like an address being deprecated or an ICMP error message) 💀.

Basically, we get the same cases we looked at in the failure detection analysis (Section 4.1.1):

  • For the (1,1,*) cases, there are multiple paths between one MR and one HA. The existing paths between the HA and the MR have to be explored to find an available one 🔎. Only the HA and the MR are involved. It's a NEMO-/MIPv6-specific issue, so it has its own vibe 💜.
  • For the (n,1,*) cases, there's a single HA, so all the traffic to and from the NEMO flows through it 🚪. The available alternative paths are the different ones between the different MRs and that HA. The path-exploration mechanism only involves the HA and the MRs. This is a NEMO/MIPv6 specific issue ✨.
  • For the (n,n,*) cases, there are multiple paths between the different HAs and the different MRs 🌈. Here, alternative paths may be routed completely independently from one another. An end-to-end path-exploration mechanism would be able to discover if any of the end-to-end paths is available. The (n,n,1) case, though, seems pretty NEMO specific, because there are no multiple prefixes 💅. The (n,n,n) case is hybrid, since picking a different prefix results in a change of path. For this case, the Shim6 protocols (such as those discussed in [9]) may be useful 🧚.

Most of the above cases involve path exploring tunnels between HA(s) and MR(s). That's no different from path exploring between a mobile host and its HA(s) 🫶. So a solution for MIPv6 should apply to NEMO too! For case (n,*,*), an MR synchronization solution (see Section 4.4) should be able to complement a MIPv6 path-exploration solution to get the functionality NEMO needs 🔥.

To do path exploration, the MR sometimes also has to detect whether network media is available 📡. This may be achieved using layer 2 triggers [10], or other mechanism developed/recommended by the Detecting Network Attachment (DNA) Working Group [11]. This is related to Section 4.1.1, since being able to detect media availability would often mean being able to detect media unavailability 🙈.

4.1.3. Path Selection 🎯

You need a path-selection mechanism to pick among the multiple available paths 💖. Depending on the NEMO multihoming configuration, the differences between the paths may only affect the part between the HA and the MR, or they may affect the full end-to-end path 🌸. Depending on the configuration, path selection may be done by the HA(s), the MR(s), or the hosts themselves through address selection, which we'll get into next ✨.

The multiple available paths may differ on the tunnel between the MR and the HA used to carry traffic to and from the NEMO. In this case, the MR and the intra-NEMO routing system handle path selection for traffic flowing from the NEMO, and the HA and intra-Home Network routing system handle it for traffic flowing to the NEMO 🚇.

Or the multiple paths may differ in more than just the tunnel between the MR and the HA, since using different prefixes can mean using different providers. That makes for completely different paths between the involved endpoints 🌍. In this case, on top of the mechanisms from the previous case, you may need additional mechanisms for end-to-end path selection. This may be closely related to source address selection mechanisms within the hosts, since selecting a given address implies selecting a given prefix, which is tied to a given ISP serving one of the home networks 🦋.

A dynamic path-selection mechanism is thus needed so that this path can be selected by:

  • The HA: it should be able to select the path based on some information recorded in the binding cache 🏰.
  • The MR: it should be able to select the path based on router advertisements received on both its egress interfaces or on its ingress interfaces for the (n,*,*) case 📻.
  • The MNN: it should be able to select the path based on "Default Router Selection" (see [Section 6.3.6 Default Router Selection] [12]) in the (n,*,*) case, or based on "Source Address Selection" in the (*,*,n) cases (see Section 4.7 of the present memo) 🧭.
  • The user or the application: for example, when a user wants to pick a particular access technology among the available ones for reasons like cost or data rate 💸.
  • A combination of any of the above: a hybrid mechanism should also be available, for example one where the HA, the MR, and/or the MNNs are coordinated to select the path 🤝.

When multiple bi-directional tunnels are available and possibly used at the same time, the mode of operation may be either primary-secondary (one tunnel takes precedence over the others and is used as the default tunnel, while the other serves as a backup) or peer-to-peer (no tunnel has precedence over another, and they're all used with the same priority) 👑. This raises the question of which of the bi-directional tunnels would be selected, and based on which parameters (for example, the type of flow going into or out of the mobile network) 🤔.

The mechanisms for selecting among the different tunnels between the MR(s) and the HA(s) seem to be pretty NEMO/MIPv6 specific 💜.

For (1,*,*) cases, they're no different from path selection between a mobile host and its HA(s). So a solution for MIPv6 should apply to NEMO too! For the (n,*,*) cases, an MR synchronization solution (see Section 4.4) should be able to complement a MIPv6 path-selection solution to get the functionality NEMO needs 🔥.

The mechanisms for selecting among different end-to-end paths based on address selection are similar to the ones used in other multihoming scenarios, like those considered by Shim6 (for example [13]) 🧚.

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 and moves the existing communications from one path to the other 🦋. Similar to the earlier items in this process, the re-homing procedure varies a lot depending on the NEMO multihoming configuration 🌈.

  • For the (*,*,1) configurations, the re-homing procedure involves only the MR(s) and the HA(s). It may involve the exchange of additional BU messages. These mechanisms are shared between NEMO Basic Support and MIPv6 💖.
  • For the (*,*,n) cases, in addition to the previous mechanisms, end-to-end mechanisms may be required 🌍. Those may involve some form of end-to-end signaling, or they may simply rely on using different addresses for the communication. The mechanisms involved may be similar to those needed for re-homing Shim6 communications (for example [13]) 🫶.

4.2. Ingress Filtering ✨

okay so bestie, ingress filtering mechanisms [14][15] may drop the outgoing packets when multiple bi-directional tunnels end up at different HAs 😭. This could especially happen if different MNPs are handled by different HAs. If a packet with a source address configured from a specific MNP gets tunneled to a HA that doesn't handle that MNP, the packet may get tossed either by the HA or by a border router in the home network 💀.

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

  • For the (*,*,1) cases, there is not such an issue, since there is a single MNP 🎀.
  • For the (1,1,*) and (n,1,1) cases, there is not such a problem, since there is a single HA, accepting all the MNPs 💅.
  • For the (n,1,n) case, though ingress filtering would not occur at the HA, it may occur at the MRs, when each MR is handling different MNPs 🫶.
  • (*,n,n) is where ingress filtering gets a little messy 🙈. In the (1,n,n) case, the problem is simplified because all the traffic to and from the NEMO is routed through a single MR. This configuration lets the MR properly route packets while respecting the constraints imposed by ingress filtering. In this case, the single MR may face ingress filtering problems that a multihomed mobile node may face, as documented in [7]. 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 no problems occur with ingress filtering. However, this cannot always be assumed, which results in the problem described below.

As an example of how this could happen, picture the deployment scenario 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 MR advertises a different MNP (P1 and P2 respectively). MNP P1 is registered to HA1, and MNP P2 is registered to HA2. So MNNs should be free to auto-configure their addresses on either P1 or P2. Ingress filtering could then happen in two cases:

  • If the two tunnels are available, the MNN cannot forward a packet with source address equal to P1.MNN to MR2. This would cause ingress filtering at HA2 to occur (or even at MR2). This is contrary to normal Neighbor Discovery [12] practice, where an IPv6 node is free to choose any router as its default router regardless of the prefix it chooses to use 🌸.
  • If the tunnel to HA1 is broken, packets that would normally be sent through the tunnel to HA1 should be diverted through the tunnel to HA2. If HA2 (or some border router in HA2's domain) performs ingress filtering, packets with a source address configured from MNP P1 may be discarded 😱.
               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

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

  • Some form of source address-dependent routing, whether host-based and/or router-based, where the prefix contained in the packet's source address is considered when deciding which exit router to use when forwarding the packet 🦋.
  • The usage of nested tunnels for (*,n,n) cases. Appendix B describes one such approach 🌈.
  • Deprecating those prefixes associated with non-available exit routers 🍓.

The ingress filtering incompatibility problems that appear in some NEMO multihoming configurations are similar to those considered in Shim6 (e.g., see [16]) 👑.

4.3. HA Synchronization 🔄

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

  • Only one HA may actively advertise a route to the MNP,
  • Multiple HAs at different domains may advertise a route to the same MNP.

This may pose a problem for the routing infrastructure as a whole if the HAs are located in different administrative domains. The implications of this aspect need further exploration 🔍. A certain level of HA coordination may be required. A possible approach is to adopt an HA synchronization mechanism such as the one described in [17] and [18] ✨. Such synchronization might also be necessary in a (*,n,*) configuration, when an 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 an MNP is delegated to the MR (see Section 4.5), some level of coordination between the HAs may also be necessary 💜.

This issue is a general mobility issue that will also have to be dealt with by Mobile IPv6 (see Section 6.2.3 in [7]) as well as NEMO Basic Support 🌸.

4.4. MR Synchronization 🫶

In the (n,*,*) configurations, there are common decisions that may require synchronization among different MRs [19], such as:

  • advertising the same MNP in the (n,*,1) configurations (see also "prefix delegation" in Section 4.5);
  • one MR relaying the advertisement of the MNP from another failed MR in the (n,*,n) configuration; and
  • relaying between MRs everything that needs to be relayed, such as data packets, creating a tunnel from the ingress interface, etc., in the (n,*,*) configuration.

However, there is no known standardized protocol for this kind of router-to-router synchronization 😬. Without such synchronization, it may not be possible for a (n,*,*) configuration to achieve various multihoming goals, such as fault tolerance.

Such a synchronization mechanism can be primary-secondary (i.e., a master MR, with the other MRs as backup) or peer-to-peer (i.e., there is no clear administrative hierarchy between the MRs) 👑. The need for such a mechanism is general, in the sense that a multi-router site in the fixed network would require the same level of router synchronization.

Thus, this issue is not specific to NEMO Basic Support, though there is a more pressing need to develop an MR-to-MR synchronization scheme for providing fault tolerance and failure recovery in NEMO configurations, due to the higher possibility of link failure 🚨.

In conclusion, it is recommended to investigate a generic solution to this issue, although the solution would first have to be developed for NEMO deployments 🎀.

4.5. Prefix Delegation 🍬

In the (*,*,1) configurations, the same MNP must be advertised to the MNNs through different paths. There is, however, no synchronization mechanism available to achieve this. Without a synchronization mechanism, an MR may end up announcing incompatible MNPs. In particular:

  • for the (*,n,1) cases, how can multiple HAs delegate the same MNP to the mobile network? To do so, the HAs may be somehow configured to advertise the same MNP (see also "HA Synchronization" in Section 4.3) 🤔.
  • for the (n,*,1) cases, how can multiple MRs be synchronized to advertise the same MNP down the NEMO-link? To do so, the MRs may be somehow configured to advertise the same MNP (see also "MR Synchronization" in Section 4.4) 🥺.

Prefix delegation mechanisms [20][21][22] could be used to ensure all routers advertise the same MNP. Their applicability to a multihomed mobile network should be considered 🧐.

4.6. Multiple Bindings/Registrations 🦋

When an MR is configured with multiple CoAs, it is often necessary for it to bind these CoAs 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 is being dealt with in the Monami6 WG 👀.

4.7. Source Address Selection 🌈

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

However, currently available source address selection mechanisms do not let MNNs acquire enough information to select their source addresses intelligently (such as based on the traffic condition associated with the home network of each MNP) 😤. 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 those specified in [24], to be used. Further exploration on setting such "preference" information in Router Advertisement based on the performance of the bi-directional tunnel might prove useful ⭐. Note that 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) 💅.

This is a general issue faced by any node when offered multiple prefixes.

4.8. 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 to two different root-MRs, so the aggregated network no longer forms a simple tree structure. In such a situation, an infinite loop within the mobile network may occur 😵‍💫.

This problem is specific to NEMO Basic Support. However, at the time of writing, more research is recommended to assess the probability of loops occurring in a multihomed mobile network. For related work, see [25] for a mechanism to avoid loops in nested NEMO 🧚.

4.9. 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. However, it is unclear whether there is a sufficient deployment scenario for this problem to occur 🤷‍♀️.

It is recommended that the NEMO WG standardize a solution to this problem if there is sufficient vendor/operator interest, or specify that the split of a (n,*,1) network cannot be allowed without router renumbering 🎀.

4.10. Preference Settings

Okay so bestie, when a mobile network is multihomed, the MNNs might be able to actually benefit from that setup 🛣️✨ like they could pick between the available paths based on cost, delay, bandwidth, etc. 💅 But honestly? In some cases they just don't get that choice. 😭 Specifically:

  • In the (,,n) configuration, the MNNs can influence the path by source address selection (see Section 4.1.3 and Section 4.7). 🎀
  • In the (n,,) configuration, the MNNs can influence the path by default router selection (see Section 4.1.3). 🌸
  • In the (1,n,1) configuration, the MNNs cannot influence the path selection. 💀

Here's the tea 🍵: the preference of the MNN (like what its app or transport layer wants) might not match the preference the MR is using. So the forwarding choices the MR makes might not be the best for a particular flow, and they could even mess with transport control loops 🙈 (like TCP's flow control can get totally wrecked when the MR unexpectedly load balances a TCP flow). A mechanism that lets the MNN say what it prefers for a given traffic would be super helpful here. 🧚

Another vibe is that the MNN might not even know there are multiple forwarding paths, like in the (1,n,1) configuration. 👀 An MR advertising that multiple tunneling paths exist would let the MNN take advantage of them, especially paired with that preference mechanism we just talked about. 🦋

This problem is general too, because IPv6 nodes might want to influence the routing decisions made by upstream routers. 💖 Various WGs are exploring this right now, like the NSIS and IPFIX WGs. ✨ It's also possible the Shim6 layer in the MNNs has this capability. 🫶 It is recommended that vendors or operators look into the solutions these WGs have developed when they provide multihoming capabilities to mobile networks. 📚

Also, the Monami6 WG is currently developing a flow filtering solution for mobile nodes to indicate how flows should be forwarded by a filtering agent [27] (such as HA and mobile anchor points). 🔥 It is recommended that the Monami6 WG consider the issues described here, so that flow filtering can be performed by the MNN to indicate how flows should be forwarded by the MR. 👑

5. Recommendations to the Working Group 🎀

Several issues that might impact the deployment of NEMO with multihoming capabilities were identified in Section 4. 🧠 The matrix below shows them for each of the eight multihoming configurations, along with which WG(s) a solution for each issue is most likely to come from. 💜

    +=================================================================+
    |                       # 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/M| M |S/M| N |S/N| N |S/N|
    +---------------------------------+---+---+---+---+---+---+---+---+
    | Re-Homing                       |N/M| S |N/M| S |N/M| S |N/M| S |
    +---------------------------------+---+---+---+---+---+---+---+---+
    | Ingress Filtering               | . | . | . | t | . | . | . | N |
    +---------------------------------+---+---+---+---+---+---+---+---+
    | 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  | N | N | N | N | N | N | N | N |
    +---------------------------------+---+---+---+---+---+---+---+---+
    | Prefix Ownership                | . | . | . | . | N | . | N | . |
    +---------------------------------+---+---+---+---+---+---+---+---+
    | Preference Settings             | G | G | G | G | G | G | G | G |
    +=================================================================+
    N - NEMO Specific       M - MIPv6 Specific      G - Generic IPv6
    S - SHIM6 WG            D - DNA WG
    . - Not an Issue        t - trivial
    * - Fault Tolerance is a combination of Failure Detection, Path
        Exploration, Path Selection, and Re-Homing

               Figure 10: Matrix of NEMO Multihoming Issues

The matrix above shows which issues are NEMO-specific and which aren't. 🔍 Just remember it's a simplification of Section 4, so the subtle details aren't in Figure 10. 🙈

As you can see from Figure 10, these are the concerns that are specific to NEMO: Failure Detection, Path Exploration, Path Selection, Re-Homing, Ingress Filtering, HA Synchronization, Prefix Delegation, Loop Prevention in Nested NEMO, and Prefix Ownership. 💅 Based on the authors' best knowledge of the possible NEMO deployments, here's what they recommend:

  • A solution for Failure Detection, Path Exploration, Path Selection, and Re-Homing should be solicited from other WGs. 🦋

Path Selection is marked as NEMO-specific in Figure 10, but the technical side of the problem is believed to be pretty similar to choosing multiple paths in mobile nodes. ✨ So vendors are encouraged to ask other IETF WGs, such as Monami6 or Shim6, for a solution to these issues. 🫶

  • Ingress Filtering on the (n,n,n) configuration can be solved by the NEMO WG. 🌈

This problem is clearly defined and the WG can solve it. 💜 Deploying the (n,n,n) configuration can be imagined on vehicles for mass transportation (like buses or trains), where different service providers might install their own MRs on the vehicle or vessel. 🚌

The Shim6 WG may be developing a mechanism for overcoming ingress filtering in a more general sense. 👀 So the authors recommend that the NEMO WG concentrate only on the (n,n,n) configuration if it decides to work on this issue. 🎀

  • A solution for HA Synchronization can be looked at in a mobility-specific WG, taking into consideration both mobile hosts operating Mobile IPv6 and MRs operating NEMO Basic Support. 🧚
  • A solution for Multiple Bindings/Registrations is presently being developed by the Monami6 WG. 🌸
  • Prefix Delegation should be reviewed and checked by the NEMO WG. 🔥

The proposed solutions [22] and [21] that provide prefix delegation functionality to NEMO Basic Support should be reviewed, to make sure the concerns discussed in Section 4.5 are properly handled. 📚

  • Loop Prevention in Nested NEMO should be investigated. 🍓

Further research is recommended to assess the risk of having a loop in the nesting of multihomed mobile networks. 💀

  • Prefix Ownership should be considered by the vendors and operators. 👑

The problem of Prefix Ownership only occurs when a mobile network with multiple MRs and a single MNP can arbitrarily join and split. 🤯 Vendors and operators of mobile networks are encouraged to share their views on whether deploying this kind of mobile network makes sense. 💖

6. Conclusion 🌈

This memo presented an analysis of multihoming in the context of network mobility under the operation of NEMO Basic Support (RFC 3963). ✨ The goal was to investigate issues with this bi-directional tunneling mechanism, where mobile networks are multihomed and multiple bi-directional tunnels are set up between Home Agent and Mobile Router pairs. 🛣️ To do that, mobile networks were sorted into a taxonomy of eight possible multihomed configurations. 🧩 Issues were explained one by one, then summarized in a table that shows which multihomed configurations they apply to and which IETF working group would be the best place to solve them. 💅 This analysis should help extend the existing standards to support multihoming, and help implementors of NEMO Basic Support and multihoming-related mechanisms. 🫶

7. Security Considerations 💀🔐

This is an informational document where the multihoming configurations under the operation of NEMO Basic Support are analyzed. 📖 Security considerations of these multihoming configurations, if they differ from those that concern NEMO Basic Support, MUST be considered by forthcoming solutions. 🚨 Like, an attacker could try to use the multihomed device as a way to reach another network that wouldn't normally be reachable through the Internet. 😱 Even when forwarding to another network is turned off by configuration, an attacker could compromise a system to turn it back on. 🧨 Scary stuff, bestie, so don't sleep on this one. 🙈🔥

8. Acknowledgments 🫶

The authors would like to thank everyone who gave valuable comments on various multihoming issues on the mailing list, and also those who suggested directions at the 56th - 61st IETF Meetings. 🎀 The initial evaluation of NEMO Basic Support on multihoming configurations is a contribution from Julien Charbon. 💜

9. References 📚

9.1. Normative References

   [1]   Ernst, T., "Network Mobility Support Goals and Requirements",
         RFC 4886, July 2007.

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

   [3]   Ernst, T. and H-Y. Lach, "Network Mobility Support
         Terminology", RFC 4885, July 2007.

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

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

9.2. Informative References ✨

okay so this is the extra reading list 📚 every citation here is a source the doc points to, and I'm keeping every single one exactly as written bc the details matter 🫶

  • [6] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. Kuladinithi, "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", Work in Progress, October 2006.
  • [7] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Work in Progress, February 2006.
  • [8] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
  • [9] Arkko, J. and I. Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", Work in Progress, December 2006.
  • [10] Krishnan, S., Montavont, N., Yegin, A., Veerepalli, S., and A. Yegin, "Link-layer Event Notifications for Detecting Network Attachments", Work in Progress, November 2006.
  • [11] Narayanan, S., "Detecting Network Attachment in IPv6 Networks (DNAv6)", Work in Progress, October 2006.
  • [12] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
  • [13] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim protocol", Work in Progress, November 2006.
  • [14] 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.
  • [15] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
  • [16] Huitema, C. and M. Marcelo, "Ingress filtering compatibility for IPv6 multihomed sites", Work in Progress, October 2006.
  • [17] Wakikawa, R., Devarapalli, V., and P. Thubert, "Inter Home Agents Protocol (HAHA)", Work in Progress, February 2004.
  • [18] Koh, B., Ng, C., and J. Hirano, "Dynamic Inter Home Agent Protocol", Work in Progress, July 2004.
  • [19] Tsukada, M., "Analysis of Multiple Mobile Routers Cooperation", Work in Progress, October 2005.
  • [20] Miyakawa, S. and R. Droms, "Requirements for IPv6 Prefix Delegation", RFC 3769, June 2004.
  • [21] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", Work in Progress, September 2006.
  • [22] Thubert, P. and TJ. Kniveton, "Mobile Network Prefix Delegation", Work in Progress, November 2006.
  • [23] Wakikawa, R., "Multiple Care-of Addresses Registration", Work in Progress, June 2006.
  • [24] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
  • [25] Thubert, P., Bontous, C., and N. Nicolas, "Nested Nemo Tree Discovery", Work in Progress, November 2006.
  • [26] Kumazawa, M., "Token based Duplicate Network Detection for split mobile network (Token based DND)", Work in Progress, July 2005.
  • [27] Soliman, H., "Flow Bindings in Mobile IPv6 and NEMO Basic Support", Work in Progress, March 2007.

Appendix A. Alternative Classifications Approach 🦋

A.1. Ownership-Oriented Approach 👑

okay so Erik Nordmark (Sun Microsystems) came up with another way to sort multihomed mobile networks, and this one is based on ownership 💅 it's more of a tree-like, top-down classification. You start with who controls the HA(s) and MR(s), and there are two possibilities: either (i) one single entity controls both the HA(s) and MR(s), or (ii) separate entities control them. The first one is called the 'ISP Model' and the second is the 'Subscriber/Provider Model' 🌈

A.1.1. ISP Model 🚆

When the same entity controls the HA(s) and MR(s), it's giving an Internet Service Provider (ISP) installing MRs on trains, ships, or planes. The ISP gets to decide what kind of mobile network setup it deploys, and all 8 configurations from the Configuration-Oriented Approach are possible ✨ In the rest of this document, when we talk about a mobile network configuration controlled by a single entity, we add an 'ISP' prefix, like ISP-(1,1,1) or ISP-(1,n,n).

When a single entity (like an ISP) controls the HA(s) and MR(s), the ISP can choose whether to give the mobile network one MNP or multiple MNPs, the same way it would for any other link in its network (wired or otherwise). Either way, the ISP is the one making sure routing between the mobile networks and its core routers (like the HAs) works. That includes not introducing any aggregation between the HAs, since that would filter out routing announcements for the MNP(s) 🙈

The ISP has a few tools for this. For one, it can run its Interior Gateway Protocol (IGP) over bi-directional tunnels between the MR(s) and HA(s). It can also use static routes with the tunnels instead. If static routes are used, a mechanism to test "tunnel liveness" might be necessary so you don't end up keeping stale routes 💀 One way to test tunnel liveness is by sending heartbeat signals from MR(s) to the HA(s). A possibility is to simulate heartbeats with Binding Updates messages by controlling the "Lifetime" field of the Binding Acknowledgment message, which forces the MR to send Binding Update messages at regular intervals. But a more appropriate tool might be the Binding Refresh Request message. Conformance to the Binding Refresh Request message may be less strictly enforced in implementations, though, since it plays a somewhat secondary role compared to Binding Update messages.

A.1.2. Subscriber/Provider Model 🎀

When the HA(s) and MR(s) are controlled by separate entities, it's best illustrated with a subscriber/provider model. Here the MRs belong to a single subscriber, and that subscriber signs up with one or more ISPs for HA services. There are two sub-categories: when the subscriber subscribes to a single ISP, and when the subscriber subscribes to multiple ISPs. In the rest of this document, when we're talking about a configuration in the subscriber/provider model where the subscriber only subscribes to one ISP, we add an 'S/P' prefix, like S/P-(1,1,1) or S/P-(1,n,n). When it's the subscriber/provider model where the subscriber subscribes to multiple ISPs, we add an 'S/mP' prefix, like S/mP-(1,1,1) or S/mP-(1,n,n) 🧚

Not all 8 configurations are likely to show up in the S/P and S/mP models. For example, an S/mP-(*,1,1) mobile network with only a single HA is unlikely to be seen. For the S/P model, these configurations are likely to be deployed:

  • S/P-(1,1,1): Single Provider, Single MR, Single HA, Single MNP
  • S/P-(1,1,n): Single Provider, Single MR, Single HA, Multiple MNPs
  • S/P-(1,n,1): Single Provider, Single MR, Multiple HAs, Single MNP
  • S/P-(1,n,n): Single Provider, Single MR, Multiple HAs, Multiple MNPs
  • S/P-(n,n,1): Single Provider, Multiple MRs, Single HA, Single MNP
  • S/P-(n,1,n): Single Provider, Multiple MRs, Single HA, Multiple MNPs
  • S/P-(n,n,1): Single Provider, Multiple MRs, Multiple HAs, Single MNP
  • S/P-(n,n,n): Single Provider, Multiple MRs, Multiple HAs, Multiple MNPs

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

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

When the HA(s) and MR(s) belong to different entities, the MR is more likely to be controlled by one entity (i.e., the subscriber), and that MR sets up multiple bi-directional tunnels to one or more HA(s) provided by one or more ISP(s). In these cases, the ISP is unlikely to run IGP over the bi-directional tunnel, since it will most certainly want to keep full control of its routing domain 💅

A.2. Problem-Oriented Approach 💖

A third approach was proposed by Pascal Thubert (Cisco Systems). This one focuses on the problems of multihomed mobile networks instead of the configuration or ownership 🔥 It gives a set of 4 categories based on two orthogonal parameters: the number of HAs, and the number of MNPs advertised. Since those two parameters are orthogonal, the categories aren't mutually exclusive. The four categories are:

  • Tarzan: Single HA for Different CoAs of Same MNP

This is the case where one MR registers different CoAs to the same HA for the same subnet prefix. This is equivalent to the case of y=1, i.e., the (1,1,*) mobile network.

  • JetSet: Multiple HAs for Different CoAs of Same MNP

This is the case where the MR registers different CoAs to different HAs for the same subnet prefix. This is equivalent to the case of y=n, i.e., the (1,n,*) mobile network.

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

  • 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 🧚‍♀️

To get the extra robustness that multihoming gives, MRs that use bi-directional tunneling with their HAs should dynamically change their tunnel exit points depending on the link status. For instance, if an MR detects that one of its egress interfaces is down, it should check whether alternate routes to the global Internet exist. That alternate route might come from any other MR connected to one of its ingress interfaces that has an independent route to the global Internet, or from another active egress interface the MR itself has. If such an alternate route exists, the MR should re-establish the bi-directional tunnel using this alternate route 🌸

In the rest of this Appendix, we'll look at some methods for re-establishing bi-directional tunnels this way. This method of tunnel re-establishment is especially useful for the (*,n,n) NEMO configuration. The method described is by no means complete and is just a suggestion on how to approach the problem. It's also not the goal to specify a new protocol tailored to this form of re-establishment. Instead, we'll stick to currently available mechanisms specified in Mobile IPv6 [5] and Neighbor Discovery in IPv6 [12] 🫶

B.1. Detecting Presence of Alternate Routes 🔍

Okay so, to actually use the backup power of multihoming 💪, an MR first has to be able to detect alternate routes ✨. Admins can hard-code them into the MR if the mobile network is pretty static 🧱. But ngl, it's way more iconic when MRs find them automatically 🦋, because that's so much more flexible.

Case one is an MR with multiple egress interfaces, whether they're bound to the same HA or not. This one should be trivial, since the MR can just "realize" it has several routes out to the global Internet 🌍.

Case two is when there are multiple MRs on the mobile network. Each MR has to notice the others 👀. It can do that by listening for Router Advertisement messages on its ingress interfaces. When an MR gets a Router Advertisement with a non-zero Router Lifetime field from one of those, it knows another MR that can provide an alternate route to the global Internet is present in the mobile network 🙌.

B.2. Re-Establishment of Bi-Directional Tunnels 🔁

When an MR detects that the link its current bi-directional tunnel with its HA is using has gone down 📉, it needs to re-establish that tunnel using an alternate route it detected. There are two separate cases here. First, the alternate route comes from another egress interface that belongs to the MR. Second, the alternate route comes from another MR connected to the mobile network. We call the first case an alternate route provided by an alternate egress interface, and the second case an alternate route provided by an alternate MR 💅.

B.2.1. Using Alternate Egress Interface 🌈

When an egress interface of an MR loses its connection to the global Internet, the MR can switch to its alternate egress interface, as long as it has more than one egress interface 🔀. The most direct move is for the MR to send a binding update to the HA of the failed interface, using the CoA assigned to the alternate interface. That way the bi-directional tunneling gets re-established using the CoA on the alternate egress interface 🫶. Once the binding update succeeds, the MR encapsulates outgoing packets through the bi-directional tunnel using the alternate egress interface ✅.

The whole idea is to take the global address (most likely a CoA) assigned to an alternate egress interface and use it as the new (back-up) CoA of the MR, so it can re-establish bi-directional tunneling with its HA 🧚.

B.2.2. Using Alternate Mobile Router 🚐

When the MR loses its connection to the global Internet, it can use a route provided by an alternate MR (if one exists) to re-establish the bi-directional tunnel with its HA 🙏. Here's the order of operations. First, the MR has to get a CoA from the alternate MR, which is basically attaching itself to that alternate MR. Next, it sends a binding update to its HA using that CoA. From then on, the MR can encapsulate outgoing packets through the bi-directional tunnel via the alternate MR 🎀.

Again, the idea is to get a CoA from the alternate MR and use it as the new (back-up) CoA of the MR, so the bi-directional tunneling with its HA gets re-established 💜.

Heads up, bestie: every packet sent between MNNs and their correspondent nodes is going to go through two levels of encapsulation 😭. The first level happens between the MR that the MNN uses as its default router and that MR's HA. The second level happens between the alternate MR and its HA. Two layers of tunnel, no cap 🧅.

B.3. To Avoid Tunneling Loop 🌀

The re-establishment method from Appendix B.2 can lead to infinite loops of tunneling 😵‍💫. It happens when two MRs on a mobile network lose their connection to the global Internet at the same time, and each one tries to re-establish its bi-directional tunnel using the other. We call this phenomenon a tunneling loop 🙈.

One way to avoid a tunneling loop is for an MR that has lost its connection to the global Internet to insert an option into the Router Advertisement messages it broadcasts periodically 📣. That option tells the other MRs on the link that the sender no longer provides a global connection. Setting the Router Lifetime field to zero won't work well, though 🙅‍♀️. That would make the MNNs attached to the MR stop using it as their default router too, and then we're right back at square one 💀.

B.4. Points of Considerations 🧐

Honestly, this method of using tunnel re-establishments is by no means a complete solution 🙃. There are still points to think through before it becomes a fully functional solution. For example, Appendix B.1 suggested that an MR detects the presence of other MRs using Router Advertisements. But Router Advertisements are link scoped, so when there's more than one link, some information can get lost 📉.

Picture this: three MRs, three different prefixes, and each MR sits on a different link with regular routers in between. Now suppose only one MR is still working. How do the other MRs figure out which prefix to use to configure the new CoA 🤔? There are three prefixes being announced. An MR whose link has failed knows its own prefix is not to be used, but it can't tell which of the other two prefixes to pick for the new CoA. So a mechanism is needed that lets an MR withdraw its own prefix when it discovers its link is no longer working 🫠.

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: chanwah.ng@sg.panasonic.com


Thierry Ernst
INRIA
INRIA Rocquencourt
Domaine de Voluceau B.P. 105
Le Chesnay  78153
France

Phone: +33-1-39-63-59-30
Fax:   +33-1-39-63-54-91
EMail: thierry.ernst@inria.fr
URI:   http://www.nautilus6.org/~thierry


Eun Kyoung Paik
KT
KT Research Center
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/


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

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

Copyright (C) The IETF Trust (2007) 💖.

This document is subject to the rights, licenses and restrictions contained in BCP 78. Except as set forth there, the authors retain all their rights ✨.

The disclaimer is verbatim, because legal text needs to stay exact:

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🦋

The IETF takes no position on 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 🤷‍♀️. It also doesn't say whether any license under those rights might or might not be available, and it doesn't claim to have made any independent effort to find such rights. Info on the procedures for rights in RFC documents is in BCP 78 and BCP 79 📚.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users are all available from the IETF online 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 required to implement this standard 💅. Send that info to the IETF at ietf-ipr@ietf.org 💌.

📦 where this page comes from