Subject: [Mip6] comments on draft-ietf-mip6-dsmip-problem-01.txt

From: gabriel montenegro <[email-masked]>
Date: Thu, 3 Nov 2005 17:39:05 -0800 (PST)

I was asked to review this draft. I attach my comments.

tnx,

-gabriel

Some comments on this draft. 

In general, I found it refreshingly short and simple. It does focus on the tunnel
set-up aspects of IP mobility. But there's movement detection, FA discovery or
router discovery, prefix discovery, liveness detection, etc. Either these other
areas should be taken into consideration or the problem statement should be
modified to explicitly address only the tunnel set-up aspects of mobility.

Please see below for further comments.

-------------------------------------------------------
...

> 3.0 Problem description
> 
>    Mobile IP (v4 and v6) uses a signaling protocol (Registration

s/a signaling protocol/signaling protocols/
s/Registration/e.g., Registration/

As I mention above, there is more than one type of signaling going on.

>    requests in [MIPv4] and Binding updates in [MIPv6]) to set up tunnels
>    between two end points. At the moment Mobile IP signaling is tightly

s/ to set up tunnels between two end points././

Cuz it's more than setting up tunnels.

...
> 3.2. Operational burdens
...
>    In addition, deploying both protocols will require duplication of
>    security credentials on mobile nodes and home agents. This includes,

s/,//

>    IPsec security associations, keying material, and new authentication
>    protocols for Mobile IPv6, in addition to the security credentials
>    and associations required by Mobile IPv4. Such duplication is again
>    significant with no gain to the operator or the mobile node.

"no gain"? I think this is not correct. There is some gain, presumably.
The argument I think is more along that it seems doable to obtain the same
gain with much fewer resources.

> 3.3. Mobility management inefficiencies
> 
>    Suppose that a mobile node is moving within a dual stack access
>    network. Every time the mobile node moves it needs to send two mobile
>    IP messages to its home agent to allow its IPv4 and IPv6 connections
>    to survive. There is no reason for such duplication. If local
>    mobility optimizations were deployed (e.g. HMIPv6) Fast handovers or
>    local MIPv4 HA), the mobile node will need to update the local agents
>    running each protocol. Ironically, one local agent might be running
>    both HMIPv6 and local MIPv4 home agent. Clearly, it is not desirable
>    to have to send two messages and complete two sets of transactions
>    for the same fundamental optimization.
> 
>    Hence, such parallel operation of Mobile IPv4 and Mobile IPv6 will
>    complicate mobility management within the Internet and increase the
>    amount of bandwidth needed at the critical handover time for no
>    apparent gain.

"no apparent gain", see comment above.

...
> 
> 4. Conclusion and recommendations
> 
>    The points above highlight the tight coupling in both Mobile IPv4 and
>    Mobile IPv6 between signaling and the IP addresses used by upper

s/addresses/address types/

>    layers. Given that Mobile IPv4 is currently deployed and Mobile IPv6
>    is expected to be deployed, there is a need for gradual transition
>    from IPv4 mobility management to IPv6. Running both protocols

This presupposes only one of several possible deployment scenarios.
Here, the assumption is that devices become mobile via MIP4 first, and
then migrate to MIP6. But it may be that a significant population of
devices will only know MIP6 mobility. They may use IPv4 (without mobility)
to increase their chances of attaching to the net wherever they visit,
but would only use IPv4 as an underlay for IPv6 (including mobility).
So perhaps the MIP4->MIP6 upgrade scenario is not the only
possibility (as implied here), and the draft should acknowledge that.

>    simultaneously is inefficient and has the problems described above.
>    The gradual transition can be done when needed or deemed appropriate
>    by operators or implementers. In the mean time, it is important to
>    ensure that the problems listed above can be avoided. Hence, this
>    section lists some actions that should be taken by the IETF to
> 
> 
> 
> 
> Tsirtsis and Soliman                                            [Page 4]
> 
> INTERNET-DRAFT           Dual stack MIP problem            October, 2005
> 
> 
>    address the problems listed above, without mandating the use of two
>    mobility management protocols simultaneously.
> 
>    In order to allow for a gradual transition based on current standards
>    and deployment, the following work areas seem to be reasonable:

some of the stuff below is a bit cryptic, are there perhaps drafts
that can be referred to informationally?

> 
>    - It should be possible to run one mobility management protocol that
>    can manage mobility for both IPv4 and IPv6 addresses used by upper
>    layers. Both Mobile IPv4 and Mobile IPv6 should be able of performing
>    such task. It may not be possible to support route optimization for
>    Mobile IPv6 in all cases; however, mobility management and session
>    continuity can be supported.
> 
>    - It should be possible to create IPv4 extensions to Mobile IPv6 so
>    that an IPv4 and IPv6 capable mobile node can register its IPv4 and
>    IPv6 home addresses to an IPv4 and IPv6 enabled Home Agent using
>    MIPv6 signaling only.
> 
>    - It should be possible to create IPv6 extensions to Mobile IPv4 so
>    that an IPv4 and IPv6 capable mobile node can register its IPv4 and
>    IPv6 home addresses to an IPv4 and IPv6 enabled Home Agent using
>    Mobile IPv4 signaling only.
> 
>    - It should also be possible to extend [MIPv4] and [MIPv6] so that a
>    mobile node can register a single care-of address (IPv4 or IPv6) to
>    which IPv4 and/or IPv6 packets can be tunneled.
> 
>    Following the steps listed above, a vendor can choose to support one
>    mobility management protocol while avoiding the incompatibility and
>    inefficiency problems listed in this document. Similarly, operators
>    can decide to continue using one mobility management protocol while
>    addressing the transition scenarios that a mobile node is likely to
>    face when roaming within the Internet.
> 
>    Further work in this area, possibly independent of Mobile IP, may
>    also be of interest to some parties in which case it should be dealt
>    with separately from the incremental Mobile IP based changes.

Not sure what this last paragraph adds. Perhaps delete it.

-gabriel
_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6