[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-larsson-v6ops-mip-scenarios-00.txt
on 2004-11-20 8:07 am Pekka Savola said the following:
> 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.
So you make the HA use the same solution for MIP4 as today's MIP4 HAs
uses. (see separate mail)
>>> 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.
Not right (see my separate mail), but that's beside the point here.
This is a matter that doesn't impact, affect the tunnelling and handover
characteristics, so it really doesn't belong in this discussion.
>>>> => 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) ?
In this case, statically. Dynamic address assignment is not a part
of the base MIP specification, for a good reason! If it had been
dynamically, the HA would have had to proxy for the MN while it
was away, as in the MIP4 dhcp-based solution.
But that is irrelevant here, because it doesn't impact the handover
characteristics or tunnelling overhead - it's only relevant when setting
up the tunnel.
>>> 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.
If you have an MN away from home, you break everything if you let it
change address, so you don't do that. And between HA and MN, the
address is implicitly confirmed by each re-registration. And it's
defined and works fine for MIP4, and in such a manner that it can
easily be adapted to MIP6, IPv4-in-MIP6 and IPv6-in-MIP4.
But more importantly, this does not belong here, because it does
not impact the handover characteristics or tunnelling overhead, it
only affects the initial registration.
>>>> => 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?
And what does this discussion have to do with handover latency and
tunnel overhead?
> 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
No, that's not the way it's done, and the way it's done is not complex.
> 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.
No need to re-invent stuff -- actually, even less than the way you
are envisioning it. The HA proxies for the MN. Everything else is
just re-use of existing mechanisms.
No, there may be issues that needs describing, but they are not relevant
to this draft, and they are not particularly complex.
Henrik