[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC 5006 status
Hi Mark,
Le 18 mars 2010 à 13:20, Mark Smith a écrit :
> On Thu, 18 Mar 2010 11:52:36 +0100
> Rémi Després <remi.despres@free.fr> wrote:
>
>> HI,
>>
>> Le 18 mars 2010 à 10:25, Gert Doering a écrit :
>>
>>> On Thu, Mar 18, 2010 at 10:15:39AM +0100, sthaug@nethelp.no wrote:
>>>> Note that this includes having DHCPv6 delivering the default gateway.
>>>
>>> This is not really important for us (no cable deployments, and the DSL
>>> deployment is PPP based, so the default gateway is always "the other end
>>> of the pipe" anyway). But I understand that other networks need this,
>>> so I'm certainly not opposing this.
>>
>> Some time ago, Dan Wing proposed (I don't remember where) that RAs could contain DHCP options that are worth advertising to all hosts.
>>
>> If generalized, this would permit to avoid reinventing in RAs options that are available in DHCPv6, and yet make the DHCPv6 protocol to be in general unnecessary.
>>
>> The simplicity of this approach is IMHO very attractive.
>>
>> Any thoughts?
>>
>
> Surely if everything is "crammed" into RAs, the only difference between
> RAs and stateless DHCPv6 is very slightly less CPU use on the
> client/server (i.e. typically router), very slightly less RAM on the
> client, and the ability of clients to ask for what they
> want and servers being selective about what they give certain clients,
> rather than getting everything in RA and then ignoring what they
> don't want.
The point is to PERMIT, with a very simple extension of RAs, that all common stateless parameters of hosts be available in RAs.
> Those costs are all so low they're negligible, so I don't
> understand why people seem to be so focused on making RAs a slightly
> less capable substitute for stateless DHCPv6, at the cost of now having
> two nearly identical mechanisms to achieve the same goal.
>
> Antoine de Saint-Exupéry said, "In anything at all, perfection is
> finally attained not when there is no longer anything to add, but when
> there is no longer anything to take away."
I love this sentence, and have tried to work with it in mind for many years.
This is the case in particular for the subject at hand.
(To me, in design efforts, MISS is even better than KISS: "MAKE It Simple, Stupid" may take more time and energy than just "KEEP It Simple, Stupid", but that's often worth it.)
A given function shouldn't be made more complex than necessary for the (wrong) reason that some of its uses are combined with more complex functions.
Hosts that need only stateless parameters shouldn't be obliged to pay the cost of supporting the protocol that is needed for stateful parameters.
One more protocol, even if requiring little RAM, is something Saint-Exupery would suggest to get rid of.
If you consider vendors of very small objects that will proliferate with IPv6, they should be permitted to use IPv6 links between these objects and their centralized controllers.
Having in these objects all network parameters acquired in RAs is simpler.
> I see adding all the stateless DHCPv6 parameters to RAs as adding
> something to RAs that, when added, should be taken away, because a
> simple mechanism already exists to perform those functions.
Note that the idea is not to impose that "all" stateless parameters should have to be advertised in RAs.
It is only that hosts should be prepared to receive some DHCPv6 options in RAs, with a standardized format for this (trivially simple to do).
Options a host doesn't know, or want to know, are simply skipped (thanks to the TLV format of options).
That's it. There is no more to standardize.
And IMHO, nothing will have to be taken away, at any time.
> Is there something I'm missing?
In my understanding, yes, as I tried to explain.
Regards,
RD