RE: Call for v6ops agenda items

["Konrad Rosenbaum" <konrad@silmor.de>]

Hi,

On Tue, March 2, 2010 15:59, teemu.savolainen@nokia.com wrote:
>> My (rather philosophical) problem with your proposal is that you try to
>> teach the SLAAC/ICMPv6 part of the protocol stack about protocols it
>> does
>> not need to know about. This makes the driver more complex and hence
>> more
>> error prone. In my opinion unnecessarily.
>
> I don't think I'm trying to teach SLAAC/ICMPv6 anything? Why do you think
> so (i.e. where do I need to clarify)?

Oooooops. That's embarassing: for some reason I assumed your protocol was
an extension of Router Advertisements.

Do I read it correctly now in that you plan to extend DHCPv6 and/or IPv6CP?

If so, a lot of my arguments just lost their teeth.

Could you make it clearer what exact protocols can carry your extension
and how they interact with it?

> The user space software would use the Stateless DHCPv6 to learn the
> configuration information, and calculate the delegated prefixes as
> described. Why SLAAC/ICMPv6 would have to be touched?

In that case they wouldn't.

> Avoiding new DHCPv6 code on a host should be less risky?

Yes. Avoiding any extra code is less risky. As is avoiding any mix of layers.

>> I implemented a semi-stateless version of DHCPv6 for my internal
>> experiments with IPv6 over PPP - it responds with the same prefix to
>> any
>> query from the same customer, so it did not need to store any states.
>
> Yes, this lightweight DHCPv6 server (on a gateway) is an interesting
> option as well. It could indeed provide much of the functions I'm after as
> was discussed in another thread with Ole. I'm studying that as well.

This also has the upside of the provider and/or AC vendor being able to
impose any policy on prefix calculation without having to worry about the
state of implementations on the CPE side.

What I still worry about is a wholly different aspect of SPD:

Pseudo-stateful PD requires you to implement the calculation of prefixes
exactly once on the AC (DR) - even if it misinterprets some standard in
the calculation it will probably still work - the clients (RR) do not care
how their prefix was calculated, they just use it. As long as the RR works
with any single other implementation of DHCP server it will probably work
with almost all of them.

Stateless PD requires this calculation to be implemented exactly the same
way on the AC/DR (it has to calculate the routing table) and all the
variants of RR, with the RR having to implement several variants at once
since they do not know what network they will end up in. Especially the RR
implementers will be under a lot of pressure (CPE devices and mobile
phones are not exactly the most expensive network components). Per
Murphy's Law they will get it wrong. In many different ways. So we will
have a DR doing the calculation one way and several types of RR doing the
same calculation randomly the same way, a slightly different way, a very
different way or not at all.

I do not want to seem unnecessarily gloomy, but I suspect high support
costs are on the way if more than one way of calculation is supported and
if there is the slightest chance of misinterpreting the standard.



    Konrad