I think the slippery slope is not so much the options, but rather the requirement that a stack implement both mechanisms. That is, the stack - not knowing which of RA or DHCP might be in use where the device might be attached - must have both the RA and DHCP implementation. The problem gets worse if more options get added, perhaps in parallel, to both RA and DHCP. With Bob's suggestion, the specification of the two protocols in parallel seems easy enough. But the stack implementer will have to add code for any new options to both RA and DHCP.
- Ralph
At 05:04 PM 10/2/2003 -0700, Bob Hinden wrote:
Doug,
The problem with this argument is that it's a slippery slope. It sounds totally reasonable to say, "As long as we have X, we might as well include Y." However, the address(es) of the recursive name servers aren't that useful without a search list. Then, once you get into a windows environment you really need the netbios name server address.... etc. Once you get done with that, you've invented something that looks an awful lot like dhcp.
To clarify by slippery slope, I think you mean creating two sets of options (e.g., one for DHCPv6 and one for RA's) as both DHCPv6 and IPv6 neighbor discovery are existing protocols. It seems to be this can easily be avoided by creating an ND option that can carry a DHCPv6 option. The ND options are <type><length> form so it should be easy to define a new one that said the contents was a DHCPv6 option. This seems very simple to me.
#---------------------------------------------------------------------- # To unsubscribe, send a message to <[EMAIL PROTECTED]>.
