Analysis of Multihoming in Network Mobility Support
RFC 4980

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    nemo mailing list <nemo@ietf.org>, 
    nemo chair <nemo-chairs@tools.ietf.org>
Subject: Document Action: 'Analysis of Multihoming in Network 
         Mobility Support' to Informational RFC 

The IESG has approved the following document:

- 'Analysis of Multihoming in Network Mobility Support '
   <draft-ietf-nemo-multihoming-issues-08.txt> as an Informational RFC

This document is the product of the Network Mobility Working Group. 

The IESG contact persons are Jari Arkko and Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-nemo-multihoming-issues-08.txt

Technical Summary

  This document is an analysis of multihoming in the
  context of network mobility (NEMO) in IPv6.

Working Group Summary
 
  This document has been relatively non-controversial
  in the WG. The document has been reviewed by many members
  of the working group; The document has gone through working
  group last call, with one comment raised and addressed. 
  The WG seems to have a pretty good understanding of 
  multihoming and how this document defines the issues 
  related to it.
 
Protocol Quality
 
  This specification has been reviewed by Jari Arkko for the
  IESG.

  A call for additional review from multihoming-related WGs
  in the IETF was made on the AD's request. This call did
  not result in any reviews. However, some members from
  the MONAMI6 WG and the SHIM6 have been involved involved
  in the NEMO work around this document.

Note to RFC Editor

  Please change in Section 1:

  OLD:
  Scenarios illustrated in [6] demonstrate that providing a permanent
  access to mobile networks such as vehicles typically require the use of
  several interfaces and technologies since the mobile network may be
  moving in distant geographical locations where different access
  technologies are provided and governed by distinct access control
  policies.
  NEW:
  Scenarios illustrated in [6] demonstrate that providing a permanent
  access to mobile networks typically require the use of several
  interfaces and technologies. For example, this is particularly useful
  for ITS (Intelligent Transport Systems) applications since vehicles are
  moving across distant geographical locations. Access would be provided
  through different access technologies (e.g. Wimax, Wifi, 3G) and through



  different access operators.

  OLD:
   o  multiple global prefixes are available in the mobile network.-->
  NEW:
   o  multiple global prefixes are available in the mobile network.

  Please expand first occurrence of MNP to Mobile Network Prefix.

  Please add the following between the first and second sentences
  in the first paragraph of Section 2.1: "The MR and the AR are
  connected to the Internet via a single Access Router (AR)."

  Please change in Section 3.1:

  OLD:
  W-PAN
  NEW:
  wireless personal area network

  Please change in Section 4:

  OLD:
  [8] and [8]
  NEW:
  [8]

  Please add an informative reference to DHCPv6 (RFC 3315)
  in the last sentence of Section 2.

  Add this text to the end of Section 8 (Security Considerations):

  For instance, an attacker could try to use the multihomed device
  as a means to access another network that wouldn't be normally
  reachable through the Internet. Even when forwarding to another
  network is turned off by configuration, an attacker could compromise
  a system to enable it.

  Please replace Section 4.10 contents with this:

   When a mobile network is multihomed, the MNNs would be able to
   benefit from this configuration, such as to choose among the
   available paths based on cost, transmission delays, bandwidth, etc. 
   However, in some cases, such a choice is not made available to the
   MNNs.  Particularly:

   o  In the (*,*,n) configuration, the MNNs can influence the path by
      source address selection (see Section 4.1.3, Section 4.7).

   o  In the (n,*,*) configuration, the MNNs can influence the path by
      default router selection (see Section 4.1.3).

   o  In the (1,n,1) configuration, the MNNs cannot influence the path
      selection.

   One aspect of preference setting is that the preference of the MNN
   (eg. application or transport layer configuration) may not be the
   same as the preference used by a MR.  Thus, forwarding choice made 
   by the MR may not be the best one for a particular flow, and may even
   be detrimental to some transport control loops (such as the flow
   control algorithm for TCP may be messed up when MR unexpectedly
   performs load balancing on a TCP flow).  A mechanism that allows the
   MNN to indicate its preference for a given traffic would be helpful
   here. 

   Another aspect of preference setting is that the MNN may not even be
   aware of the existence of multiple forwarding paths, e.g. the
   (1,n,1) configuration.  A mechanism for the MR to advertise the
   availability of multiple tunneling paths would allow the MNN to take
   advantage of this, coupled with the previously mentioned mechanism
   that allows the MNN to indicate its preference for a given traffic.

   This problem is general in the sense that any IPv6 nodes may wish to
   influence the routing decision done by the upstream routers.  Such
   mechanism is currently being explored by various WGs, such as the
   NSIS and IPFIX WGs.  It is also possible that a Shim6 layer in the
   MNNs may possess such capability.  It is recommended that vendors 
   or operators to investigate into the solutions developed by these 
   WGs when providing multihoming capabilities to mobile networks.

   In addition, the Monami6 WG is currently developing a flow filtering 
   solution for mobile nodes to indicate how flows should be forwarded
   by a filtering agent (such as home agent, mobility anchor points). 
   It is recommended that the Monami6 WG considers the issues described
   here so that flow filtering can be performed by MNN to indicate how
   flows should be forwarded by the MR.

  Please change in Section 3.1:

  OLD:
   This is a (1,1,*) if both accesses are
   performed with the same ISP.  If the two accesses are offered
   by independent ISPs, this is a (1,n,n) configuration.
  NEW:
   This is a (1,1,*) if both a single home agent is used for both.
   If two independent home agents are used, this is a (1,n,n) 
   configuration.

  OLD:
    Alternatively, the train company
    might be forced to use different ISPs when the train crosses
    different countries, thus a (n,n,n) configuration.
  NEW:
    Alternatively, the train company
    might use different home agents, in
    different countries, thus a (n,n,n) configuration.

  OLD:
   This
   is a (n,n,n) configuration if the two access technologies are
   subscribed separately.
  NEW:
   This
   is a (n,n,n) configuration if different home agents are also used.