Re: [v6ops] sidetrack on DNS-SD vs. DHCP

[[e-mail]]

>> There should be an architecture RFC about this stuff :)
>> 
>> 
>> RFC1958 and RFC5505 cover these sorts of architectural topics. There is
>> also a bit of architecture discussion at the start of RFC1122.
> 
> The thing is, we are talking here about fixing up a confusion created by
> our own history -- the fact that DHCP was immature technology when IPv6
> was designed, so including a stand-alone autoconfiguration mechanism was,
> truly, a great step forward. So now that DHCP(v4) is a great success,
> and DHCPv6 is a bit of a poor cousin, there's a little cleanup work to do.

Fate sharing was one of the major objections to DHCP.
It was I think also felt that a service discovery mechanism was the correct way of resolving many of these issues.

Only DNS recursive resolvers in addition to addressing was required from the network.
(Now I'm even less certain that DNS recursive resolvers should be configured by the network, but oh well).

Another data point on history here is from:
https://www.ietf.org/proceedings/52/141.htm


Using DHCPv6 for DNS Configuration in Hosts, Ralph Droms
--------------------------------------------------------

<draft-droms-dnsconfig-dhcpv6-00.txt>

[Slides available at http://playground.sun.com/ipng/meetings.html]

Questions about some of the assertions in the intro, asking to clarify some of the statements.

Nordmark: Cost benefit tradeoffs. Steve points out that without state sharing problem is an improvement. Is this enough of an advantage to be worth the trouble of deploying? Deering agrees. The real question for the w.g. do we need anything beyond DHCP for client configuration?

Soliman: Thinks being able to do discovery and configuration without DHCP servers is good. Has always been a goal of the w.g. Thinks fate sharing is a significant issue with DHCP and other server approaches. Thinks claim that DHCP server can be combined in same box may not be enough. Need to have discovery mechanism in same function (process) as the service. Thinks this is a very important and DHCP doesn't meet this requirement.

Austein: Disagrees about the fate sharing comments. Could put DHCP in same process. It is an implementation issue. Doesn't see that anycast helps with the fate sharing. DHCP approach is better in the long term because it handles other information. DNS is staring to have a dependency on NTP. Doesn't want to define a special configuration mechanisms for every service. Thinks DHCP is a better solution.

Zill: If you send out one of the DHCP information requests. Will one server know all? Narten: Not a problem that you learn an incorrect list of servers.

Suggestion that level 1 compliance is OK. Could use DHCP for level 2.

Huitema: Thinks original requirement as stated by Steve Deering is correct. Limited fate sharing is better approach. Thinks we need a simple solution that work in simple networks. Thinks this DNS discovery approach provides more flexibility the just using DHCP server.

Nordmark: What is the extensibility in each approach? Talking about these as one thing is part of the problem. Could separate anycast to reach server from getting service information.

Deering took poll of room: How many people think w.g. should continue work on stateless DNS discovery? Consensus to continue work.