I tend to think MIPv6 RO is not deployed in CNs, at least not as wide as
expected.

With respect to Raj's earlier suggestion, I wouldn't agree substituting
RFC5555 for RFC3775, i.e. to use DSMIPv6 instead of Mobile IPv6 -
because Mobile IPv6 and Mobile IPv4 have been used successfully for this
goal, with practical implementations, simultaneously; whereas I'm not
aware of DSMIPv6 implementations(?).

I would also recommend to suggest the use of NEMOv6 protocol extensions
to Mobile IPv6, whenever talking Mobile Nodes.  I.e. say "Mobile Nodes
(Mobile Hosts and Mobile Routers RFC3963)".  It would have been easier
if RFC3775 referred to RFC3963 but it's not the case, and 3775bis not too.

RFC3963 NEMOv6 implementations are probably as widespread as Mobile IPv6
implementations.  Additionally, radvd (which is widely used on linux)
does mention RFC3963 and does implement the HA NEMOv6 features necessary
in RA.

I think the qualification of use of NEMOv6 RFC3963 could be as strong as
RFC3775 (MAY?).

For example, for this current Node Requirements text:
Routers SHOULD support the generic mobility-related requirements for all IPv6 routers described in Section 8.3 of [RFC-3775]. Routers MAY support the home agent functionality described in Section 8.4 of [RFC-3775], including support of [RFC-2473] and [RFC-3776].

I'd suggest  something like: "Routers (Mobile Routers or Home Agents)
MAY support Mobile Router and Home Agents respective implementations, as
described in RFC3775 and RFC3963."  Or similar.

A Mobile Router is different from a Router, for example, because of a relatively strong recommendation, in that it must not join (capitalized) the all-routers link-local multicast address when not at home.

Finally, RFC3776 has been updated by another RFC, which could be
mentioned.  Whose implementation status I don't know.

Just some thoughts,

Alex

Thomas Narten a écrit :
The document currently says:

8.  Mobile IP

The Mobile IPv6 [RFC3775] specification defines requirements for
the following types of nodes:

- mobile nodes - correspondent nodes with support for route
optimization - home agents - all IPv6 routers

Hosts MAY support mobile node functionality described in Section
8.5 of [RFC3775], including support of generic packet tunneling
[RFC2473] and secure home agent communications [RFC4877].

Hosts SHOULD support route optimization requirements for correspondent nodes described in Section 8.2 of [RFC3775].

Routers SHOULD support the generic mobility-related requirements
for all IPv6 routers described in Section 8.3 of [RFC3775].
Routers MAY support the home agent functionality described in
Section 8.4 of [RFC3775], including support of [RFC2473] and
[RFC4877].


I think the above text needs updating. As with SEND, I do not believe
 we have sufficient implementation and deployment experience to make
a general SHOULD recommendations for RO.

I would like to get a better sense of what the implementation status of MIPv6 is. AFAIK, it is not implemented in mainstream products (or distributions) at this time. Moreover, RO is new technology to IPv6 (MIPv4 does not have it), making it even more important to get real deployment and operational experience before making a broad SHOULD recommendation.

The first MAY recommendation basically says that implementing
mobility functions (i.e., being a mobile node) is completely
optional. That seems fine.

The second recommendation says that generic hosts SHOULD implement RO. But, RO primarily benefits mobile nodes, so it is in some sense
an unfunded mandate for hosts. Hosts pay a cost for implementing RO,
but don't see much, if any, benefit. Moreover, it is unclear at this
point that we have any significant deployment experience with this technology.

W.r.t. RO, discussion in the past has also raised concerns as to whether larger content servers (i.e., amazons and googles) would be willing to support RO. They raised concerns about scalability, etc.

Thus, in the absence of significant deployment and operational experience, I think it is premature to broadly recommend
implemenation of RO. A MAY for general hosts seems about the best we
can do.

Regarding the last recommendation, that Routers SHOULD support
generic mobility-related requirements, this means (from RFC3775):

8.3.  All IPv6 Routers

All IPv6 routers, even those not serving as a home agent for Mobile
 IPv6, have an effect on how well mobile nodes can communicate:

o  Every IPv6 router SHOULD be able to send an Advertisement
Interval option (Section 7.3) in each of its Router Advertisements
[12], to aid movement detection by mobile nodes (as in Section
11.5.1). The use of this option in Router Advertisements SHOULD be configurable.

o Every IPv6 router SHOULD be able to support sending unsolicited multicast Router Advertisements at the faster rate described in Section 7.5. If the router supports a faster rate, the used rate MUST be configurable.

o Each router SHOULD include at least one prefix with the Router Address (R) bit set and with its full IP address in its Router Advertisements (as described in Section 7.2).

o  Routers supporting filtering packets with routing headers SHOULD
 support different rules for type 0 and type 2 routing headers (see
Section 6.4) so that filtering of source routed packets (type 0) will not necessarily limit Mobile IPv6 traffic which is delivered via type 2 routing headers.


I think that these recommendations are generally OK. Indeed, I think it is a bit unfortunate that those recommendations are hidden within the MIPv6 spec as opposed to being merged in with the ND spec, but that isn't something node requirments can address.

Comments?

Thomas -------------------------------------------------------------------- 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
--------------------------------------------------------------------

Reply via email to