on 8/2/2003 5:11 PM Rob Austein wrote: > If I understand it correctly, the simple version of what you propose > (just using multicast to find recursive name servers, nothing else) > substitutes one multicast-based discovery protocol for another > multicast-based discovery protocol. Since it's quite possible to > co-locate a DHCP-lite "server" inside the same "process" (or whatever > fate sharing unit a server host uses) as the recursive name server, > the fate sharing comparision comes out as a wash when one looks at it > closely. So one's left arguing about relatively trivial engineering > details like packet formats and port numbers.
Are you referring to draft-ietf-dhc-dhcpv6-stateless-00.txt or something else? That draft makes no mention of multicast whatsoever, and the reference context of link-local is a unicast address. > In any case, either version of what you're talking about still looks > to me like a proposal for new protocol work. We're still trying to > determine whether -any- new protocol work is needed, so this, like the Some amount of work will need to be done no matter what. At the very least, a set of behavioral rules will need to be codified. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ #---------------------------------------------------------------------- # To unsubscribe, send a message to <[EMAIL PROTECTED]>.
