Re: Policy of IPv6 DNS Discovery

[Ralph Droms <rdroms@cisco.com>]

Eric,

I think there has been a difference of opinion in the past about your 
statement: "Granted, there would be some administration in terms of 
ensuring that multicast filters were working properly, but this is less 
than the requirements for DHCP."  My recollection is that similar 
multicast-based mechanisms have been rejected in the past because they 
require a multicast service, which has not been universally deployed to 
date.  Network admins do have successful experience with DHCP service 
deployment in IPv4 and the service deployment model in IPv6 would be 
essentially the same...

- Ralph

At 06:38 PM 8/2/2003 -0500, Eric A. Hall wrote:

>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.
>
>There's also the operational overhead differences. You'll still have to
>manage static pre-configured lists of servers, for example, while there
>wouldn't be any such lists with the multicast DNS 'CONFIG' model. Since
>any server that responded to the request would be a candidate, managing
>the list would essentially boil down to adding and deleting servers (or
>enabling and disabling recursion on those servers), and the new list of
>servers would self-identifies on the next query seamlessly.
>
>Granted, there would be some administration in terms of ensuring that
>multicast filters were working properly, but this is less than the
>requirements for DHCP.
>
> > The SRV based stuff is a different ball of wax: in that one, you're
> > reinventing SLP instead of reinventing DHCP :).
>
>I wasn't advocating any additional work for SRV. I was making the point
>that SRV-based configurations only requires a working resolver, and that
>the multicast CONFIG approach gets that minimal level of service working
>*from inside DNS* as well. So again, for those services which use SRV,
>using a DNS-based configuration service makes it simpler since everything
>~needed would be in the resolver code, with no external services needed.
>
> > In any case, either version of what you're talking about still looks
> > to me like a proposal for new protocol work.
>
>A new DNS opcode and some behavioral rules.
>
> > We're still trying to
> > determine whether -any- new protocol work is needed, so this, like the
> > RA-based and ND-based proposals, isn't really in scope at the moment.
>
>--
>Eric A. Hall                                        http://www.ehsco.com/
>Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
>
>#----------------------------------------------------------------------
># To unsubscribe, send a message to <dnsop-request@cafax.se>.

#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.