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

[Henrik Levkowetz <henrik@levkowetz.com>]

Answering one point separately.

on 2004-11-20 8:07 am Pekka Savola said the following:

>>> 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.

You are trying to solve a problem which has already been solved.

What's more, you're making it sound more complex than the solution
which has already been defined and fully implemented with several
different allocation strategies, for MIP4.

Now,

   1. This discussion doesn't belong here at all - we're way, way
      into solution space, on an issue which isn't too complex, 
      and is already defined for parallel cases.

   2. To the nitty gritty details.
      This is how it works for MIP4.  Let's first be clear on that,
      then we can discuss the IPv6-in-MIP4 case, and then the
      MIP6 cases if we have to.

     a. For MIP4 there is a mechanism for the MN to tell the HA
	during initial registration that it needs an address.

     b. This on purpose does not go into how the HA acquires an
	address to give to the MN.  This is basically GOOD.

     b1. One possibility is to have a pre-allocated pool in the HA,
	 which the HA allocates from and re-uses as it will.

     b2. Another possibility is that the HA contains a dhclient
	 proxying for the MN, which gets an address allocated for
	 the MN from a DHCP server.

     c. MIP4 defines how to tell the MN what the address is. The
	address is valid as long as the MN is registered with the
	HA.

That's all there is to it!

Now if we talk IPv6-in-MIP4, we could do the same thing.  The 
extensions needed to tell the HA that an IPv6 address is needed
and to tell the MN what address it has are trivial.

Again, the HA would need to proxy for the MN in whatever way is
used to get the IPv6 address for the MN - and in this the HA
should *not* be constrained; any way that the MN could use were
it physically present on the home link would be permissible for
the HA to use.  Don't invent new things if you don't have to.

Now, this in no way impacts hand-over characteristics, it only
impacts the initial registration.  *It doesn't belong here.*
Can we please let it go?


	Henrik