Sri - I agree with all of your comments including the statement that
RO is a key feature of MIPv6. I would add a caveat that there is not
much incentive for a large scale server to implement RO, as it benefits
the mobile node user rather than the application or the hosting service.
It seems RO in that case might be a "value-add" that services pitched at
mobile end-users might advertise as advantageous. In several
conversations with vendors, there is resistance to the idea of making RO
mandatory for all hosts.
Remembering that by SHOULD we mean YOU REALLY SHOULD. REALLY. WE MEAN
IT! (Unless you have a very good reason not to) which is every so
slightly less imperative than MUST, can we avoid the SHOULD/MUST
argument by keeping it as SHOULD but adding some strong language
reiterating the importance of RO and the market value of having it?
For example, in the US DoD IPv6 Profiles document the following language
has been included at least the last couple of annual revisions,
attempting to address this issue. Maybe some of this text would help.
Full disclosure: I am an editor on the cited document, and the wording
on misalignment of incentive comes from prior discussions with Thomas
Narten on the subject.
"Any IPv6 Capable Node can interoperate with a MIPv6 Mobile Node as a
Correspondent Node as stated in Section 8.1 of RFC 3775 (no additional
functionality is required). MIPv6 includes a feature called “Route
Optimization” which increases the efficiency of packet routing between a
Mobile Node and Correspondent Node. An IPv6 Capable Node to be deployed
where MIPv6 is prevalent SHOULD support Route Optimization as defined in
RFC 3775.
Route Optimization presents some unique challenges. There is a
misalignment of incentive – for RO to be effective it must be widely
implemented by the Correspondent Nodes including general purpose servers
for which it provides no benefit. RO certainly would provide performance
enhancement for a geographically dispersed enterprise, where it would
eliminate triangular routing of packets to a home network when the MN
was visiting a location where the enterprise maintained corporate
servers. While it would be helpful for general servers to support RO,
due to current lack of MIPv6 deployments and the small benefit it does
not make sense to require RO for servers at this time.
RO raises some security concerns, especially in deployments where it
would be undesirable to reveal the location of a travelling MIPv6 MN. At
least an approximate location can be derived from IPv6 prefix of the
network where the MN is operating. In those cases, it would be better to
disable RO in the MN and rely on the Home Agent to conceal the current
location of the MN."
On 8/20/2010 11:22 AM, Sri Gundavelli wrote:
Couple of comments on Section 9.0 (Mobility): draft-ietf-6man-node-req-bis-05
1.) When Mobile IPv6 was designed, one important feature that made into the
protocol is the support for Route Optimization. The ability for a mobile node
to provide the information on the direct (non-anchor or non-triangular) path to
a Correspondent Node. This was not possible in Mobile IPv4, as any change
requirement to IPv4 did not make much sense. This is one feature of Mobile IPv6
that stands out. The semantics of RO, say Type-II RH, is part of the basic IPv6
feature. Most IPv6 stacks have support for these options and in most cases the
RO procedure as well. Given this, It is very important that the IPv6
Correspondent Node functionality is mandated on every IPv6 node. However, the
Home Agent functionality on IPv6 routers, or the Mobile Node stack on a IPv6
node, can be optional, that is fine. But, its important that the end-points has
natural RO support.
2.) I'd additionally remove the comments around lack of deployment experience
around the protocol. This comment applies to practically every IPv6 feature,
SEND or other extensions. In fact with Mobile IPv4 being a core mobility
protocol in CDMA, we probably have bit more related experience on the node
requirements from IPv6 node perspective.
3.) Section 9.0 should be reviewed by MEXT, NETLMM and NETEXT working groups,
so the node requirements with respect to IP Mobility are properly presented.
Regards
Sri
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
