Hi Thomas, On 7/24/09 10:41 AM, "Thomas Narten" <nar...@us.ibm.com> wrote:
> 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 agree that Route Optimization is non-existent at the present time. Given the current state of MIP6 itself, a SHOULD for RO is an exaggeration. If at all it needs to be mentioned, MAY is sufficient. > > 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. I don't know of any mainstream implementations of MIP6. IMO, MIP6 [RFC3775] by itself is plagued by the fact that it required native IPv6 networks. And given the current state of thinking w.r.t transition and co-existence with IPv4, the applicability of MIP6 is limited. Dual-stack MIP6 [RFC5555] is however cognizant of the reality and is able to work across all types of accesses. It is a much more practical protocol for real-world deployments. Hence my recommendation would be to drop MIP6 from the node requirements document and instead reference DSMIP6. > 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. Right. The need for RO at this time is non-existent. > > 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. Agree. I think RO can be removed from the node-requirements document without any harm. > > 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. Have not seen any requirements for RO being essential at this time. > > 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. MAY or even remove it. Either would be fine. > > Regarding the last recommendation, that Routers SHOULD support generic > mobility-related requirements, this means (from RFC3775): I think we should remove the reference to RFC3775 and instead point to RFC5555. > >> 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. Right. Given the lack of MIP6 implementation, these recommendations tend to get lost. At least by mentioning it in the node-requirements document, these recommendations have a chance of being implemented. -Raj > > 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 --------------------------------------------------------------------
