Re: Architectural argument for RAs [Re: [69ATTENDEES] DHCP]

[james woodyatt <jhw@apple.com>]

On Sep 20, 2007, at 22:01, Erik Kline wrote:
> An argument for using the ll multicast addresses for "all dns  
> servers", and "all ntp servers", perhaps? Or/also SLP?

Almost.  I see the architecture like this:

1) Use router solicitation to find your provisioned prefix and  
router, then stateless autoconfigure.

2) Discover ad-hoc services with multicast DNS service discovery (see  
<http://www.dns-sd.org/>)

3) Discover provisioned DNS resolving proxy servers with router  
advertisement options (see draft-jeong-dnsop-ipv6-dns-discovery).   
Failing that, use multicast DNS to discovery ad-hoc proxy resolving  
servers (query for _domain._udp.local SRV records).  Failing *that*,  
fall back completely to a local recursive resolver.

4) Discover the domains of local interest within the DNS horizon by  
querying for the DNS-SD signaling records in a reserved domain.

5) Discover all provisioned services in domains of local interest  
with non-multicast DNS-SD.

With an architecture like this, service discovery is fate-shared with  
the rest of the name resolution system.  Ad-hoc networks require zero  
configuration and no management.  The only possible appeal that DHCP  
has over this architecture, it seems to me, is that DHCP lets you  
keep on enjoying the opportunity to break your network-- by swapping  
ethernet cards around, which destroys the contrived mapping between  
MAC address and node identity you've been carefully managing at great  
expense and ever-expanding budgetary authority.

If IP networks were to be made brain-dead simple to operate, then  
Mahogany Row wouldn't be willing to pay such high salaries to the  
operators, now wouldn't they?


--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering