This topic has been discussed a couple of times; the most recent discussion is captured in RFC 4339.
- Ralph On 7/16/06 2:19 PM, "Stephen Sprunk" <[EMAIL PROTECTED]> wrote: > Thus spake "Bob Hinden" <[EMAIL PROTECTED]> >>>>> And the standardization of this option will then be used as an >>>>> excuse for succeeding violation like "XXX server address ND >>>>> option" for arbitrary "XXX" protocols. > [snip] >>> Hmm...I cannot find background information about the "design >>> principle" on the net, either. It may be just an misunderstanding of >>> mine, in which case, yes, the above concern is resolved (I might then >>> propose a DHCPv6 server address RA option:-). >> >> Feel free :-) > > I think this raises an interesting point; there are many DHCP options that > would make sense to include in an RA -- basically all of the > non-client-specific ones. I, like Tatuya, had thought there was some > long-standing antipathy to doing that, but if not, why stop at just DNS > servers? > > There's two general solutions to this which would remove the need for DHCPv6 > in most cases where it's needed today: > > 1. Create an new RA option that can contain arbitrary DHCPv6 options, or > 2. Import a specific list of DHCP options and assign them new RA option > numbers. > > If we present a solution just for DNS, are we going to have to work on a > dozen or more of these drafts, one each for DNS, NBNS, NTP, TFTP, etc? > Let's either solve all of the problems or none of them. I have a strong > preference for the former, as autoconfig doesn't make much operational sense > if I still have to deploy DHCPv6 to get my hosts to boot. > > S -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
