Subject: [Mip6] RE: DISCUSS: draft-ietf-mip6-dsmip-problem comments from Thomas

From: "Hesham Soliman" <[email-masked]>
Date: Thu, 15 Mar 2007 21:11:49 +1100

Thomas, 

Thanks for the review. Some comments below. FYI, I've added the IESG just as
an FYI that the discussion is taking place on the WG list. Whoever responds
should remove them. 

 > Not sure these are all that significant. But I think this document
 > kind of oversimplifies the problem statement. 
 > 
 > 2007-02-22: review of 03
 > 
 > 
 > > > 4.3.  Operational Burdens
 > > > 
 > > >    As mentioned earlier, deploying both protocols will 
 > require managing
 > > >    both protocols in the mobile node and the home agent. 
 >  This adds
 > > >    significant operational issues for the network 
 > operator.  It would
 > > >    certainly require the network operator to have deep 
 > knowledge in both
 > > >    protocols which is something an operator may not be 
 > able to justify
 > > >    due to the lack of substantial gains.
 > > > 
 > > >    In addition, deploying both protocols will require 
 > duplication of
 > > >    security credentials on mobile nodes and home agents. 
 >  This includes,
 > > >    IPsec security associations, keying material, and new 
 > authentication
 > > >    protocols for Mobile IPv6, in addition to the 
 > security credentials
 > > >    and associations required by Mobile IPv4.  Depending 
 > on the security
 > > >    mechanisms used and with some further work it might 
 > be possible to
 > > >    optimize some of these processes.  Assuming nothing 
 > else changes,
 > > >    however, such duplication is again significant with 
 > no gain to the
 > > >    operator or the mobile node.
 > >   
 > 
 > This is true at one level, but ignores the underlying reality. By
 > definition, transition means you are stuck with something that is
 > already deployed, with limited ability to upgrade. So if the
 > implication is that a clean-slate approach that combines both is
 > better, that misses the point.

=> It's true that the deployed IPv4 infrastructure cannot be assumed to be
"upgradeable". This is certainly the case for the MIPv6-based approach. The
only functions that are upgraded by this approach are the MIPv6-specific
ones, i.e., MN and HA. The same goes for the MIPv4-based approach. The draft
doesn't talk about how to solve the problem so I'm just giving some context.

 > > > 4.4.  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.  
 > >   
 > 
 > Sure there is. It may well be that the IPv4 and IPv6 HA are on
 > different nodes. (And this would be for historical/transitional
 > reasons, i.e., not changable.)

=> Sure, but the point was that you don't need both protocols simultaneously
in many cases. This is independent of whether they run on the same node or
different ones. 

 > > >    with Mobile IPv4 or Mobile IPv6, non of the known 
 > mechanisms have
 > >   
 > 
 > run through spell.

=> ok.

 > 
 > 
 > > >      - 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.
 > >   
 > 
 > I'm surprised to see this. My understanding is that RO is one of the
 > benefits being marketed with MIPv6. Above, the suggests that it is OK
 > to reduce/cripple this functionality.

=> Only when it *can't* be used. For instance, if the CN is IPv4-only, or if
the access network is IPv4-only. You can't use RO in those scenarios today.

 > 
 > 
 > > >       - 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.
 > >   
 > 
 > I'm not sure I agree with "should" above. Sure, its "desirable". But
 > "should" is stronger than that.

=> I'm fine with "desirable".

 > 
 > And I wonder about the implication. I.e., if one has MIPv6, but roams
 > to an IPv4 only network, the fundamental problem that needs 
 > solving is
 > associating an IPv6 address (presumably the Home Address) 
 > with an IPv4
 > COA. Neither MIPv4 nor MIPv6 does that today. So we are now talking
 > about extending MIPv6, not just adding reducing signaling. Hmm. Maybe
 > we can use IPv4-compatable addresses here. (Finally, a possible use
 > for such addresses?)

=> Compatible addresses were deprecated, but you're absolutely right, we're
using mapped addresses in the MIPv6 solution.

 > 
 > But when a MN attaches to an IPv6 only network, the MIPv4 HA 
 > can't use
 > MIPv4 because the MN doesn't have an IPv4 address. I don't see  how
 > this can be addressed without actually extending MIPv4. So the
 > implication here seems to be that this document may be implying more
 > substantive protocol changes than first appears.

=> Yes it does imply extending both protocols. 

Thanks,
Hesham

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