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.