Re: comments on draft-larsson-v6ops-mip-scenarios-00.txt

[Pekka Savola <pekkas@netcore.fi>]

I'm replying to all messages in one...

Hesham:
> > This doesn't help because it seems to be kind of using stateless
> > address autoconfiguration mechanisms, so it's entirely dependant on
> > v6.  You cannot deploy similar technology for v4.
>
> => It's already there in v4...It's deployed in commercial
> networks...

This is ambiguous.  I guess you meant "This has already been done for
v4 in MIPv4", but I was actually arguing, "This is an issue with v4 in
MIPv6".

You were saying that HMIPv6 [the MAP function] provides a way to do it 
for v6 in MIPv6.  Sure.  But you clearly cannot use the same mechanism 
for v4 in MIPv6, because there is no stateless address autoconf for 
v4.  Further, the MAP mechanism might not be even fit for standards 
track because there is no lifetime associated with the prefix.

> > Because adding v4 address assignment to MIPv6 is a relatively weighty
> > operation; whether the code or even specification already exists for
> > _MIPv4_ seems irrelevant.  MIPv6 just hasn't been designed with 
> > address assignment, and stateful address assignment by the HA in 
> > particular, in mind.  If a particular solution would force one to
> > specify and implement something like that on MIPv6 HAs, some people
> > might get excited.
>
> Hm.  I worked on the MIP4 address assignment code in the ipUnplugged
> HA, and did the dhcp-client part which we used to get the addresses.
>
> I really can't see that what you say here makes sense as a big and
> heavy thing from an implementation viewpoint, and especially not it
> being relevant until we get to a specific problem statement.  Do you
> have any particular implementation knowledge which makes you say this?

Yes, you can reuse or even leverage DHCP for the address assignment
to the HA.  But how does HA signal the address to the MN?  What about
the lifetime of the address -- are you assuming that the address is given
to the MN for forever?  Then you need to refresh the binding as well...

You either end up running DHCPv4 on top of the HA-MN tunnel link 
(that's OK), reinventing a subset of DHCPv4, or not dealing with the 
address lifetimes and the other tricky parts appropriately.

> > > => And? Actually, HMIPv6 has this feature already. So it's not
> > > entirely new to MIPv6.
> >
> > This doesn't help because it seems to be kind of using stateless
> > address autoconfiguration mechanisms, so it's entirely dependant on
> > v6.  You cannot deploy similar technology for v4.
>
> Mmm, not true, I believe:
>
> If you have an IPv6 Home Address, but are using MIP4 as mobility
> protocol, this implies that your Home Agent handles IPv6, and that
> your Home Agent, although talking MIP4 with the Mobile, has to
> be able to act as a IPv6 Home Agent in handling the packet routing
> and IPv6 home address of the MN.  Nothing of this is particularly
> weird, and is well described in the MIP6 spec, no?
>
> What's more, we had a grade student doing an experimental
> implementation of running IPv6 packets over MIP4 in 3 or 4
> months at ipUnplugged, so there is some basis for saying that
> I don't see this as incredibly complex.

See above.  How did the addresses get assigned?  Manually?  Or did
you assume infinite lifetime for the address?  Or did the MN also
have to implement and run parts of MIPv6 (e.g., DHAAD) on top of the
link w/ some unspecified manner (and causing more roundtrips) ?

> > With v4, at least (and possibly with v6, depending on the solution),
> > the home agent will have to keep some DHCP-like "address pool".
> > Putting that code in the MIPv6 HA function is a non-trivial exercise.
>
> Having implemented the same for an MIP4 HA myself, I would claim that
> it's not rocket science at all - it's mostly a matter of taking existing
> dhclient code and setting up communication between that and the MIP
> daemon.

Sure, you can put DHCP to work between HA and the address pool.  But
what about the MN and the HA?  I think you have assumptions about
address lifetimes which I don't necessarily share.

> > > => And? Actually, HMIPv6 has this feature already. So it's not
> > > entirely new to MIPv6.
> >
> > This doesn't help because it seems to be kind of using stateless
> > address autoconfiguration mechanisms, so it's entirely dependant on
> > v6.  You cannot deploy similar technology for v4.
> >
> > With v4, at least (and possibly with v6, depending on the solution),
> > the home agent will have to keep some DHCP-like "address pool".
> > Putting that code in the MIPv6 HA function is a non-trivial exercise.
>
> Actually, MIP4 simply defines the protocol for delivering the dynamic
> address to the mobile node.  Whether it is handled by the HA through
> an address poll, through interaction with a DHCP server etc, isn't
> defined.
>
> People have implemented several different solutions, which all work;
> this is good, and I don't see why we in discussing a draft laying out
> the playing field have to go into details which hasn't even been
> specified by the base protocol (in the MIP4 case) ??

And that protocol does not handle address lifetimes, etc. just 
basically says "Here's an IPv4 address.  Use it however long you 
want"?  How does that interact with the lifetimes for the same 
addresses given by DHCP server?  What if the address assignment to the 
HA expires from the DHCP server and the MN is still using the address, 
while it will be allocated to someone else?

There seem to be a lot of issues here, and any attempt at signalling 
MN's Home address as part of the MN-HA communication seems like a 
potentially complex procedure because it should either use DHCPv4, 
IPv6 SLAAC, etc., or ends up trying to reinvent the mechanism... 
usually in such a manner that certain cornercases aren't appropriately 
dealt with.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings