Re: [v6ops] DHCPv6 vs ND strikes again

[Ole Troan <[e-mail]>]

>>>>> In our protocols, prefix length clearly needs to be a parameter
>>>>> (as it is in draft-hu-pppext-ipv6cp-extensions, for example).
>>>> so now we are not only going to replicate all functions between DHCPv6 and RA options, but also for IPv6CP? that appears to be a bad idea.
>>> Well, there are arguments about why this is needed from an operational viewpoint
>>> in draft-hu-pppext-ipv6cp-requirements. I guess they should be discussed
>>> on the pppext list.
>> 
>> so creating two protocols doing exactly the same thing is a good thing?
> 
> In general, not. But if an operator is using PPP to establish sessions
> with thousand or millions of subscribers, I can well understand that they
> don't want to run either SLAAC or DHCPv6 as well as IPV6CP/PPP.

ND is running there anyway. and you are saying that wrapping the bits on the wire between two IPv6 nodes makes a big difference to the operator? I don't understand that argument. if you send an IPv6 prefix on the wire with a DHCP header wrapping or an IPv6CP control header wrapping what difference does that make?
neither protocol forces any different infrastructure in the backend, e.g. you can very well run DHCP PD on the wire, and use Radius in the backend.

> Anyway, as I said, that point needs to be argued in PPPEXT, not here.

as this discussion has been held on the ipng/ipv6 list for as long as I can remember, I think it belongs here rather than in pppext.

couldn't find the first occurrence of this debate, here is one pointer:
http://www.mail-archive.com/[e-mail]/msg03545.html

consensus has been many times over to make provisioning and configuration media independent for IPv6, and that we should not create L2 specific configuration mechanisms. I see this draft's proposal is to overturn that consensus.

cheers,
Ole