Re: Node Requirements: issue 17 - MIPv6

[<Basavaraj.Patil at nokia.com>]

Hi Thomas,

On 7/24/09 10:41 AM, "Thomas Narten" <narten at 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 at ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------