TOC 
IETF MONAMI6 Working GroupN. Montavont
Internet-DraftENST-B
Expires: April 30, 2006R. Wakikawa
 Keio University
 T. Ernst
 Keio University / WIDE
 C. Ng
 Panasonic Singapore Labs
 K. Kuladinithi
 University of Bremen
 October 27, 2005

Analysis of Multihoming in Mobile IPv6

draft-montavont-mobileip-multihoming-pb-statement-05.txt

Status of this Memo

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 becomes aware will be disclosed, in accordance with 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 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 April 30, 2006.

Copyright Notice

Copyright © The Internet Society (2005).

Abstract

The use of multiple interfaces is foreseen to provide ubiquitous, permanent and fault-tolerant access to the Internet, particularly on mobile nodes which are more prone to failure or sudden lack of connectivity. However, Mobile IPv6 currently lacks support for such multihomed nodes. Individual solutions have been proposed to extend Mobile IPv6 but all issues have not been addressed in a single document. The purpose of the present document is thus to fill up this gap and to raise the discussion in order to make sure that forthcoming solutions will address all the issues. In this document, we propose a taxonomy to classify the situations where a mobile node could be multihomed. This taxonomy is then used to highlight the issues preventing mobile nodes operating Mobile IPv6 to be multihomed.



Table of Contents

1.  Introduction

2.  Terminology

3.  Requirements

4.  Taxonomy

5.  Scenarios
    5.1.  (1,1): 1 HoA, 1 CoA
    5.2.  (n,1): n HoAs, 1 CoA
    5.3.  (1,n): 1 HoA, n CoAs
    5.4.  (n,n): n HoAs, n CoAs
    5.5.  (n,0): n HoAs, no CoAs

6.  Issues
    6.1.  General IPv6-related Issues
        6.1.1.  Path Selection
        6.1.2.  Ingress Filtering
        6.1.3.  Failure detection
    6.2.  MIPv6-specific Issues
        6.2.1.  Binding Multiple CoAs to a given HoA
        6.2.2.  Using one HoA as a CoA
        6.2.3.  Simultaneous location in home and foreign networks
    6.3.  Considerations for MIPv6 Implementation
        6.3.1.  Binding a new CoA to the right HoA
        6.3.2.  Binding HoA to interface
        6.3.3.  Flow redirection
    6.4.  Summary

7.  TODO List

8.  Conclusion

9.  Contributors

10.  Acknowledgments

11.  References

Appendix A.  Why a MN may want to redirect flows

§  Authors' Addresses
§  Intellectual Property and Copyright Statements




 TOC 

1. Introduction

The use of multiple addresses (allocated to either a single interface or multiple interfaces) is foreseen to provide ubiquitous, permanent and fault-tolerant access to the Internet, particularly on mobile nodes which are prone to failure or sudden lack of connectivity. Mobile IPv6 [1] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.),[2] (Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” June 2004.) is designed to allow a mobile node to maintain its IPv6 communications while moving between IPv6 subnets. However, the current specification of Mobile IPv6 lacks support for mobile nodes with multiple addresses used simultaneously, i.e. multihomed mobile nodes. These addresses would be assigned to a single interface or to multiple interfaces, which poses a number of issues.

Individual solutions have been proposed to extend Mobile IPv6 for multihomed mobile nodes, but all issues have not been addressed in a single document. The purpose of the present document is thus to fill up this gap by listing such issues, raising the discussion at the IETF, and placing some requirements in order to propose comprehensive solutions in forthcoming standards.

This document has two goals. The first goal of this document is to define the requirements from the point of view of multihomed mobile nodes operating Mobile IPv6. The second goal of this document is to define the issues arising when we attempt to fulfill these requirements. The definition of the potentially needed solutions is out of scope of the analysis document. These should be defined in a separate document once the IETF community agrees on which issues should be solved.

In order to reach the goals of this document, we define a taxonomy which is used to describe the different situations where a mobile node is multihomed. For each case, we show the configuration a multihomed node may have (number of interfaces, number of Home Addresses or number of Care-of Addresses). We also illustrate each scenario.

To understand the foundation of this document, the reader must read our companion document [3] (Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C., Kuladinithi, K., and T. Noel, “Goals and Benefits of Multihoming,” October 2005.) which outlines the motivations, the goals and the benefits of multihoming for both fixed and mobile nodes (i.e. generic IPv6 nodes). Real-life scenarios as illustrated in that document are the base motivations of the present study. The reader must also understand the operation of the Mobile IPv6 protocol ([1] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.)).

The document is organized as follows: in Section 2 (Terminology), we introduce the terminology related to multihoming and used in this document. In Section 3 (Requirements), we discuss what is required on the mobile nodes to fully benefit from a multihomed configuration. Then we propose in Section 4 (Taxonomy) a taxonomy to classify the different cases where mobile nodes are multihomed. Thereafter the taxonomy is used in Section 5 (Scenarios) to describe a number of multihomed configuration specific to Mobile IPv6. Finally we discuss in Section 6 (Issues) and Section 6.3 (Considerations for MIPv6 Implementation) all issues related to a multihomed MN and we identify what is missing to reach the goals outlined in [3] (Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C., Kuladinithi, K., and T. Noel, “Goals and Benefits of Multihoming,” October 2005.). These issues are classified into IPv6 issues, Mobile IPv6-specific issues, and advices to implementers.



 TOC 

2. Terminology

The terms used in the present document are defined in [4] (Manner, J. and M. Kojo, “Mobility Related Terminology,” June 2004.), [1] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) and [3] (Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C., Kuladinithi, K., and T. Noel, “Goals and Benefits of Multihoming,” October 2005.).

In this draft we are using the following terms and abbreviations:



 TOC 

3. Requirements

The following generic goals and benefits of multihoming are discussed in the companion document [3] (Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C., Kuladinithi, K., and T. Noel, “Goals and Benefits of Multihoming,” October 2005.):

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

In this section, we are determining what is required for a mobile node to achieve these design goals. We will determine later in the document (in Section 5 (Scenarios)) which requirements are already fulfilled by MIPv6 and what issues remain in order to meet the requirements not currently fulfilled by MIPv6.

Basically, Internet connectivity is guaranteed for a MN as long as at least one path is maintained between the MN and the fixed Internet. This path can be divided into two paths: the path between the MN to its HA(s) and the path between the HA(s) and the CN. If RO is in place between the MN and a CN, an additional path between the MN and the CN must be guaranted. In some cases, it may be necessary to divert packets from a (perhaps failed) path to an alternative (perhaps newly established) path (e.g. for matters of reliability, preferences), or to split traffic between multiple paths (e.g. for load sharing, load balancing). The use of an alternative path must be transparent at layers above layer 3 if broken sessions and the establishment of new transport sessions has to be avoided.

In order to meet some of the goals (particularly load balancing and load sharing), multiple paths must be maintained simultaneously between the mobile node and its CN.

This can translate into the following enumeration of requirements:

  1. A MN must have either multiple interfaces with at least a single valid global IP address on each interface, or a single interface with more than one valid global address, or a single interface with one valid global address and multiple HoAs.
  2. A MN must be able to use multiple interfaces simultaneously when it is equipped with multiple interfaces.
  3. A MN must be able to attach distinct interfaces to different access networks (distinct foreign links or distinct home links, or a combination of both), when it is equipped with multiple interfaces.
  4. A MN should be able to share its traffic load among its interfaces, when several interfaces are activated and configured with valid addresses.
  5. A mechanism should be available to quickly activate a backup interface and redirect traffic when an interface fails (e.g., loss of connection).
  6. A mechanism should be available to quickly redirect flow from one address to another when it is needed. Some of the triggers of flow redirection are given in Appendix A.
  7. The MN must be able to use multiple HAs simultaneously for a given home address.
  8. The MN must be able to use a distinct HA for each home address simultaneously.

One has to consider whether these goals can be achieved with transparency or without transparency. Transparency is achieved when switching between interfaces does not cause the disruption of on-going sessions. To be achieved with transparency, a necessary (may or may not be sufficient) condition is for the end-point addresses to remain unchanged. This is in-view of the large amount of Internet traffic today are carried by TCP, which unlike SCTP, cannot handle multiple end-point address pairs.

In future when a Shim6 protocol is designed and deployed, upper layer transparency may be maintained even if end-point addresses are changed. However, as Shim6 is in its early design phase as of the writing of this memo, we will continue to assume that an end-point address change would cause a transport layer disruption throughout this document.



 TOC 

4. Taxonomy

In order to examine the issues preventing a MIPv6 mobile node to meet the requirements listed in Section 3 (Requirements) we use in the present document the following taxonomy (x,y) where:

A value of '1' implies there is a single instance of the parameter, whereas a value of 'n' indicates that there are multiple instances of the parameter. A value '*' indicates that the number can be '1' or 'n'.

An illustration of this taxonomy is given in Figure 1 (Illustration of the Taxonomy).



           Mobile Node

        HoA1         HoA2   ... HoAn   --> Permanent Address (x)
         |            |          |
   +-----+--------+   |          |
   |     |        |   |          |
  CoA1   +--CoA2  +---CoA3  ... CoAn   --> Temporary Address (y)
   |          |        |         |
  Link1      Link2    Link3 ... Linkn  -->     IPv6 Link (n/a *)
   |          |        |         |
   +-----+----+        |         |
         |             |         |
        IF1            IF2  ... IFn    -->   Physical layer

HoA1 ::= {CoA1, 2, 3} [IF1 and IF2]
HoA2 ::= {CoA3}       [IF2]
Mobile Node(x = 2, y = 3)

* because number of IPv6 links is equal to the number of CoAs, y
 Figure 1: Illustration of the Taxonomy 

As the taxonomy suggests, the fact that the mobile node has several HoAs is independent from the fact that the mobile node has multiple interfaces. The fact that the mobile node has multiple interfaces does not imply that it has multiple HoAs and vice-versa. Similarly, the number of CoAs is independent from the number of HoAs and the number of interfaces. While a node would probably have at least one CoA per interface, multiple prefixes available on a link may lead to the node building several CoAs on that link.

We propose a taxonomy with two parameters because each of them has an influence on either the mobile node behavior / management, or the potential benefits the mobile node may obtain from such configuration.

The configurations denoted by these parameters will have an impact on the way multihoming is supported. According to the number of HoAs and CoAs, different policies will be needed, such as which CoA has to be mapped with which HoA, do all the CoAs need to be mapped with all the HoAs, etc.



 TOC 

5. Scenarios

In this section, we detail the reachable multihoming goals under each type of configuration. For each configuration, we give a basic explanation and we list which of the goals outlined in Section 3 (Requirements) are achievable provided that supporting mechanisms are either already existing or could be defined. Other goals are not achievable due to the inherent configuration of the node. Then, we briefly discuss the current situation with MIPv6 and we point to issues discussed later in this document in Section 6.1 (General IPv6-related Issues), Section 6.2 (MIPv6-specific Issues) and Section 6.3 (Considerations for MIPv6 Implementation).



 TOC 

5.1. (1,1): 1 HoA, 1 CoA

When the node has a single network interface, it is not multihomed. The node has only one interface, with one HoA and is currently away from its home link. A CoA is configured on the foreign link. This is the usual scenario considered by Mobile IPv6 which would bind that CoA to the HoA. None of the multihoming goals are achievable.

However, when the node has several interfaces, this scenario is a very special case of a node with multiple interfaces connected to different IPv6 subnets. The MN is multihomed if one of the interface is attached to a foreign link, the other one is attached to the home link. Thus, the MN only configures one CoA on the foreign subnet, and one HoA on the home link.

There cannot be more than two interfaces, otherwise the mobile node would either have (A) multiple interfaces on the home link, or (B) multiple interfaces on foreign links. For (A), there would be multiple HoAs. For (B) there would be multiple CoAs.

Achievable goals: ubiquitous access, reliability, load sharing, load balancing, preference settings, bicasting

Current situation with MIPv6:



 TOC 

5.2. (n,1): n HoAs, 1 CoA

The MN is multihomed, since it has several HoAs. This case may happen when a node is getting access to the Internet through different HAs (possibly distinct operators) and each offers a Mobile IPv6 service to the node. That way, the node will have a HoA per HA. Alternatively, a single home network may be multihomed to the Internet, leading to having multiple prefixes on the home link. Thus the MN would have multiple HoAs for a single home link. Either case, the node would need to configure a single CoA on the visited IPv6 subnet, and bind that single CoA to all the HoAs it owns. If the MN has multiple interfaces, only one interface is connected to a foreign network. The other interfaces are connected to their home links.

Achievable goals: Ubiquitous access, reliability, load sharing, load balancing (if the MN has more than one interface), bicasting, preference settings.

Current situation with MIPv6:



 TOC 

5.3. (1,n): 1 HoA, n CoAs

The MN is multihomed since it has several CoAs. This case may occur when the interface of the node is connected to a link where multiple IPv6 prefixes are available. One possible reason for this is that the visited network is multihomed and because of that, multiple prefixes are available in it, one per provider. Note that the MN may be connected to its home link with one of its interfaces.

Achievable goals: reliability, load sharing, bicasting, preference settings.

Current situation with MIPv6:



 TOC 

5.4. (n,n): n HoAs, n CoAs

The MN is multihomed since it has multiple addresses. This case can be viewed as a combination of the two cases described above: the MN has several HoAs (e.g. given by different operators) and several CoAs (e.g. because the node is receiving multiple IPv6 prefixes). As an example, we can consider a node with three interfaces, two of them connected to their home link (two different HoAs) and the last one connected to a visited link where two IPv6 prefixes are available.

Achievable goals: ubiquitous access, reliability, load sharing, load balancing, bicasting, preferences settings.

Current situation with MIPv6



 TOC 

5.5. (n,0): n HoAs, no CoAs

This case happens when the interfaces are connected to their respective home links. This node can be considered as a fixed node from a multihoming point of view. The node would no longer be in the (n,0) configuration when one or more of the interfaces are attached to foreign links.

Achievable goals: ubiquitous access, reliability, load sharing, load balancing, bicasting, preference settings.

Current situation with MIPv6



 TOC 

6. Issues

Existing protocols may not be able to handle the requirements expressed in Section 3 (Requirements). For doing so, the issues discussed in this section must be addressed, and solved preferably by dynamic mechanisms. Note that some issues are pertaining to MIPv6 solely, whereas other issues are not at all related to MIPv6. However, such non MIPv6 issues must be solved in order to meet the requirements outlined in Section 3 (Requirements).

In this section, we describe some of these issues in two main headings: general IPv6-related issues, and issues that are specific to MIPv6. Other concerns related to implementations of MIPv6 are described in Section 6.3 (Considerations for MIPv6 Implementation). Issues and their area of application are summarized in Section 6.4 (Summary)



 TOC 

6.1. General IPv6-related Issues



 TOC 

6.1.1. Path Selection

When there exists multiple paths from and to the MN, the MN ends up choosing a source and destination address, and possibly the interface that should be used.

Another related aspect of path selection is the concern of ingress filtering. This is detailed in Section 6.1.2 (Ingress Filtering).



 TOC 

6.1.2. Ingress Filtering

In the (*,n) case, a MN may be connected to multiple access networks or multiple home networks each practicing ingress filtering [9] (Baker, F. and P. Savola, “Ingress Filtering for Multihomed Networks,” March 2004.), [10] (Ferguson, P. and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing,” May 2000.). Thus, to avoid ingress filtering, the selection of path would be limited by the choice of address used. This is related to Section 6.1.1 (Path Selection). The problem of ingress filtering however, is two-fold. It can occur at the access network, as well as the home network.

For instance, consider Figure 2 (MN connected to Multiple Access/Home Networks) below. In the access network, when mobile node MN sends a packet through AR-A, it must use CoA=PA.MN; and when MN sends a packet through AR-B, it must use CoA=PB.MN. In the home network, when MN tunnels the packet to home agent HA-1, it must use HoA=P1.MN; and when MN tunnels the packet to home agent HA-2, it must use HoA=P2.MN. This greatly limits the way MN can benefit from its multihoming configuration.

As an illustration, suppose MN is choosing the interface (which would determine the CoA used) and the home network to use (which would determine the HoA used), it might be possible that the chosen CoA is not registered with the chosen HoA.



              Prefix: PA +------+    +----------+    +------+
       HoA: P1.MN  /-----| AR-A |----|          |----| HA-1 |
       CoA: PA.MN /      +------+    |          |    +------+
             +----+                  |          |   Prefix: P1
             | MN |                  | Internet |
             +----+                  |          |   Prefix: P2
       HoA: P2.MN \      +------+    |          |    +------+
       CoA: PB.MN  \-----| AR-B |----|          |----| HA-2 |
              Prefix: PB +------+    +----------+    +------+
 Figure 2: MN connected to Multiple Access/Home Networks 

It must be noted that should the mobile node MN have a way of binding both CoAs PA.MN and PB.MN simultaneously to each of HoAs P1.MN and P2.MN (see Section 6.2.1 (Binding Multiple CoAs to a given HoA)), then it can choose the CoA to use based on the access network it wishes to use for outgoing packets. This solves the first part of the problem: ingress filtering at the access network. It is, nonetheless, still limited to using only a specific home agent for the home-address used (i.e. the second problem of ingress filtering at the home network remains unsolved).



 TOC 

6.1.3. Failure detection

Currently, IPv6 has no clearly defined mechanism for failure detection. A failure in the path between two nodes can be located at many different places: the media of one of the node is broken (i.e., loss of connectivity), the path between the MN and the HoA is broken, the home link is disconnected from the Internet, etc. By now, MIPv6 only relies on the ability or the inability to receive Router Advertisements within a stipulated period to detect the availibility or loss of media. Current effort [11] (Choi, J., “Goals of Detecting Network Attachment in IPv6,” December 2004.) in the DNA Working Group aims to address this, such as through the use of layer 2 triggers [12] (Yegin, A., “Link-layer Event Notifications for Detecting Network Attachments,” July 2005.). Movement detection might be extended to include other triggers such as the loss of connectivity on one interface. Moreover, the chosen Further mechanisms would be needed to detect a failure in the path between a MN and its CN(s), as well as between the MN and its HoA(s), as between the MN and CN(s), as between the MN and CN(s).



 TOC 

6.2. MIPv6-specific Issues



 TOC 

6.2.1. Binding Multiple CoAs to a given HoA

In the (1,n) cases, multiple CoAs would be available to the MN. In order to use them simultaneously, the MN must be able to bind and register multiple CoAs for a single HoA with both the HA and the CNs. The MIPv6 specification is currently lacking such ability.

Although in the (n,n) cases, MIPv6 allows MN to have multiple HoA and CoA pairs, the upper layer's choice of using a particular HoA would mean that the MN is forced to use the corresponding CoA. This constrains the MN from choosing the best (in terms of cost, bandwidth etc) access link for a particular flow, since CoA is normally bound to a particular interface. If the MN can register all available CoAs with each HoA, this would completely decouple the HoA from the interface, and allow the MN to fully exploit its multihoming capabilities.

To counter this issue, solutions like [13] (Wakikawa, R., “Multiple Care-of Addresses Registration,” June 2005.) may be used.



 TOC 

6.2.2. Using one HoA as a CoA

In (n,*) cases, the MN has multiple HoAs. A HoA may be seen as a CoA from the perspective of another home link of the same MN.

As an example, a MN has two HoAs (HoA1 and HoA2) on two distinct home links. MN is connected to these two home links via two interfaces. If the MN looses its connectivity on its first interface, HoA1 is not reachable. It may then want to register HoA2 as a CoA for HoA1 in order to keep receiving packets intended to HoA1, via the second interface.

According to the definition of a CoA, the current MIPv6 specification prohibits registering another HoA as a CoA.

In RFC3775 section 6.1.7 it is written: " Similarly, the Binding Update MUST be silently discarded if the care-of address appears as a home address in an existing Binding Cache entry, with its current location creating a circular reference back to the home address specified in the Binding Update (possibly through additional entries)."

In other words, the BU must be discarded if the binding cache of the receiver is:

Binding Cache:
New BU: HoA = addr1 w/ CoA = addr2
existing entries: HoA = addr2 w/ CoA = addr3
  HoA = addr3 w/ CoA = addr1


But, in the following situation:

Binding Cache:
New BU: HoA = addr1 w/ CoA = addr2
existing entries: HoA = addr2 w/ CoA = addr3


and no other entries in the binding cache concerning addr1/2/3. In this case, the BU should be accepted.

In order to counter this, a MN must be able to register whatever address it owns with any of its HoA. A mechanism is needed to determine how to decide which HoA will be chosen and the definition of a HoA and CoA might be extended. Some addtional details can be found in [14] (Montavont, N., “Mobile IPv6 for multiple interfaces (MMI),” July 2005.).



 TOC 

6.2.3. Simultaneous location in home and foreign networks

Rule 4 of RFC3484 specifies that a HoA will always be preferred to a CoA. While this rule allows to choose which address to use, it does not allow to beneft from being multihomed. When a MN is multihomed, it may have one of its interfaces directly connected to a home link. This may have an impact on the way multihoming is managed, since addresses from other interfaces cannot be registered as CoAs for the HoA associated to the home link the mobile node is connected on.

In the special case of (1,*) where one of the interface is connected to the home link, none of the other addresses can be used to achieve multihoming goals with the HA.



 TOC 

6.3. Considerations for MIPv6 Implementation

In addition to the issues described in Section 6.1 (General IPv6-related Issues) and Section 6.2 (MIPv6-specific Issues), there are other concerns implementers should take into consideration so that their MIPv6 implementations are more "friendly" to the use of multiple interfaces. These implementation-related considerations are described in the sub-sections below.



 TOC 

6.3.1. Binding a new CoA to the right HoA

In the (n,*) cases, the MN has multiple HoAs. When the MN moves and configures a new CoA, the newly obtained CoA must be bound to a specific HoA. The current MIPv6 specification doesn't provide a decision mechanism to determine to which HoA this newly acquired CoA should be bound to.

With no such mechanism, the MN may be confused and may bind this CoA to a possibly wrong HoA. The result might be to bind the CoA to the same HoA the previous CoA was bound to or to another one, depending on the implementation. It would indeed be better to specify the behavior so that all implementations are compliant.



 TOC 

6.3.2. Binding HoA to interface

In (n,*) cases, MIPv6 does not provide any information on how HoAs should be bound on a device, and particularly there is no mechanism to bind HoAs to interfaces.

This may be troublesome, for example, when we consider a MN configured with two HoAs and equipped with three interfaces. When the MN is connected to a home link via one interface, it will need to bind the corresponding HoA to this interface, even if the HoA was initially assigned to another one.



               HoA1          HoA2

          CoA1        CoA2         CoA3
         Iface1      Iface2       Iface3
 Figure 3: Illustration of the case (2,3) 

HoA must always be assigned to an activated interface and if the MN is connected to its home link, the corresponding HoA must be used on this interface. In some cases, the HoA then would have to be re-assigned to another interface in case of connection loss or attachment to the home link.



 TOC 

6.3.3. Flow redirection

Internet connectivity is guaranteed for a MN as long as at least one path is maintained between the MN and its CN. When an alternative path must be found to substitute for another one, the loss of one path to the Internet may result in broken sessions. In this case, new transport sessions would have to be established over the alternate path if no mechanism is provided to redirect flow transparently at layers above layer 3. The need for flow redirection is given in Appendix A.

The different mechanisms that can be used to provide flow redirection can be split into two categories, depending on the part of the path that needs to be changed. The first category is when the CoA changes: if one of the MN's CoA needs to be changed, it influences the path between the MN and its HA, and the path between the MN and its CN in RO mode. If the MN has multiple interfaces and one fails, established sessions on the failed interface would break if no support mechanism is used to redirect flows from the failed interface to another.

The second category is when the HoA changes: if one of the MN's HoA needs to be changed, it influences the path between the CN and the HoA. In (n,*) cases, the MN has multiple HoAs. If one fails, established sessions on the failed HoA would break if no support mechanism is used to redirect flows from a failed HoA to another, unless the transport session has multihoming capabilities, such as SCTP, to allow dynamic changing of addresses used.



 TOC 

6.4. Summary




 +=================================================+
 |                      # of HoAs: | 1 | 1 | n | n |
 |                      # of CoAs: | 1 | n | 1 | n |
 +=================================================+
 |             General IPv6 Issues                 |
 +---------------------------------+---+---+---+---+
 | Path Selection                  |   | o | o | o |
 +---------------------------------+---+---+---+---+
 | Ingress Filtering               |   |   | o | o |
 +---------------------------------+---+---+---+---+
 | Failure detection               |o  | o | o | o |
 +---------------------------------+---+---+---+---+
 |            MIPv6-Specific Issues                |
 +---------------------------------+---+---+---+---+
 | Binding Multiple CoAs to a      |   | o | o | o |
 |   given HoA                     |   |   |   |   |
 +---------------------------------+---+---+---+---+
 | Using one HoA as a CoA          |   |   | o | o |
 +---------------------------------+---+---+---+---+
 | Simultaneous location in home   |   | o | o | o |
 |   and foreign networks          |   |   |   |   |
 +---------------------------------+---+---+---+---+
 |        Implementation-Related Concerns          |
 +---------------------------------+---+---+---+---+
 | Binding a new CoA to the        |   |   | o | o |
 |   right HoA                     |   |   |   |   |
 +---------------------------------+---+---+---+---+
 | Binding HoA to interface(s)     | o | o | o | o |
 +---------------------------------+---+---+---+---+
 | Flow redirection                | o | o | o | o |
 +=================================================+
 Figure 4: Summary of Issues and Categorization 



 TOC 

7. TODO List

Study security concerns

Possibly discuss the possibility to use HoA on both home link and foreign link as in case (1,1):

Mention about relation with Multi6 / Shim6.



 TOC 

8. Conclusion

In this document, we have raised issues related to multihoming. We have seen that mechanisms are needed to redirect flow from a failed path to a new path, and mechanisms to decide which path should better be taken when multiple paths are available. This raises a number of issues.

Even if MIPv6 can be used as a mechanism to manage multihomed MN, triggers of flows redirection between interfaces/addresses are not adapted to the multihoming status of the node. Also, we have shown that in some scenarios MIPv6 is ambiguous in the definitions of CoA/HoA and in the mappings between HoAs, CoAs and network interfaces. Finally, we have also raised issues not directly related to MIPv6, but solutions for these issues are needed for mobile nodes to fully enjoy the benefits of being multihomed.



 TOC 

9. Contributors

The following people have contributed ideas, text and comments to this draft: Eun Kyoung Paik from Seoul National University, South Korea and Thomas Noel from Universite Louis Pasteur, Strasbourg, France.



 TOC 

10. Acknowledgments

The authors would like to thank all the people who have sent comments so far, particularly Tobias Kufner for raising new issues.





 TOC 

11. References

[1] Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” RFC 3775, June 2004.
[2] Arkko, J., Devarapalli, V., and F. Dupont, “Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents,” RFC 3776, June 2004.
[3] Ernst, T., Montavont, N., Wakikawa, R., Paik, E., Ng, C., Kuladinithi, K., and T. Noel, “Goals and Benefits of Multihoming,” draft-multihoming-generic-goals-and-benefits-02 (work in progress), October 2005.
[4] Manner, J. and M. Kojo, “Mobility Related Terminology,” RFC 3753, June 2004.
[5] Soliman, H., Malki, K., and C. Castelluccia, “Per-flow movement in MIPv6,” draft-soliman-mobileip-flow-move-02 (work in progress), July 2002.
[6] Montavont, N. and T. Noel, “Home Agent Filtering for Mobile IPv6,” draft-montavont-mobileip-ha-filtering-v6-00 (work in progress), January 2004.
[7] Kuladinithi, K., “Filters for Mobile IPv6 Bindings (NOMADv6),” draft-nomadv6-mobileip-filters-02 (work in progress), June 2004.
[8] Draves, R., “Default Address Selection for Internet Protocol version 6 (IPv6),” RFC 3484, February 2003.
[9] Baker, F. and P. Savola, “Ingress Filtering for Multihomed Networks,” BCP 84, RFC 3704, March 2004.
[10] 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.
[11] Choi, J., “Goals of Detecting Network Attachment in IPv6,” draft-ietf-dna-goals-04 (work in progress), December 2004.
[12] Yegin, A., “Link-layer Event Notifications for Detecting Network Attachments,” draft-ietf-dna-link-information-02 (work in progress), July 2005.
[13] Wakikawa, R., “Multiple Care-of Addresses Registration,” draft-wakikawa-mobileip-multiplecoa-04 (work in progress), June 2005.
[14] Montavont, N., “Mobile IPv6 for multiple interfaces (MMI),” draft-montavont-mip6-mmi-02 (work in progress), July 2005.
[15] Yegin, A., “Link-layer Hints for Detecting Network Attachments,” draft-yegin-dna-l2-hints-01 (work in progress), February 2004.


 TOC 

Appendix A. Why a MN may want to redirect flows

When a MN is multihomed, an addresses selection mechanism is needed to distribute flows over interfaces. As policies may change over time, as well as the available addresses/interfaces, flow redirection mechanisms are needed. While the selection policy is out of scope of this document, the following reasons may trigger the MN to redirect flow from one address to another:



 TOC 

Authors' Addresses

  Nicolas Montavont
  Ecole Nationale Superieure des telecommunications de Bretagne
  2, rue de la chataigneraie
  Cesson Sevigne 35576
  France
Phone:  (+33) 2 99 12 70 23
Email:  nicolas.montavont@enst-bretagne.fr
URI:  http://www-r2.u-strasbg.fr/~montavont/
  
  Ryuji Wakikawa
  Keio University
  Department of Environmental Information, Keio University.
  5322 Endo
  Fujisawa, Kanagawa 252-8520
  Japan
Phone:  +81-466-49-1100
Fax:  +81-466-49-1395
Email:  ryuji@sfc.wide.ad.jp
URI:  http://www.wakikawa.net/
  
  Thierry Ernst
  Keio University / WIDE
  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/
  
  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
  
  Koojana Kuladinithi
  University of Bremen
  ComNets-ikom,University of Bremen.
  Otto-Hahn-Allee NW 1
  Bremen, Bremen 28359
  Germany
Phone:  +49-421-218-8264
Fax:  +49-421-218-3601
Email:  koo@comnets.uni-bremen.de
URI:  http://www.comnets.uni-bremen.de/~koo/


 TOC 

Intellectual Property Statement

Disclaimer of Validity

Copyright Statement

Acknowledgment