Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server
anyway in Homenet, why don't we go for the classic enterprise set up
that has run for years for IPv4, rather than trying to shoe horn locally
assigned SLAAC addresses into global DNS?
It's not as though you can buy any piece of domestic networking
equipment today that does not support DHCPv4, so why not DHCPv6?
So we'd have:
Homenet router <-> ISP = DHCP-PD to learn prefixes [existing]
in Homenet prefix allocation & distribution [work in progress]
DHCPv6 from the Homenet router to the ISP could be extended to
communicate any ISP DNS domain settings to the Homenet [gap]
elect/configure a unicast DNS server for Homenet [gap]
run standard unicast DNS [existing]
elect/configure a DHCPv6 server for use within Homenet [gap]
The routers that are acting as clients for DHCP-PD would seem good
candidates.
run standard DHCPv6 server on local Homenet router[existing]
configure DHCPv6 relay per Homenet router to point to Homenet DHCPv6
server[existing standard, although autoconfig is a gap for the election
process]
use DHCPv6 server to update DNS content using RFC 2316 Dynamic DNS
update on behalf of end clients [existing]
client -> Homenet router RFC 3315 DHCPv6 based address configuration,
and standard unicast DNS [existing]
Then the client only needs to do stuff that is already incorporated in
any operating system used in business.
Or is this stateless /stateful war still too fresh in the collective
IETF memory?
Ted Lemon wrote:
On Sep 11, 2012, at 11:17 AM, Kerry Lynn<[email protected]> wrote:
Can we explore how this auto-population might occur? It seems that to
glean bindings from mDNS or LLMNR there would have to be at least
(or exactly?) one "agent" per subnet. The natural place for the agent to
reside is on the router. Presumably each agent learns the address of
the DNS server via stateless DHCPv6. The DNS server would need to
be configured with a TSIG for each agent. The agent hears multicast
responses to lookups on its local link, then periodically updates the
DNS server.
I assume an alternative would be to auto-configure via stateful DHCPv6.
Would that more or less of a configuration burden than the sketch above?
Would work with existing devices?
There are a couple of options being pursued in the DHC working group; the DHCP
address registration process would be an obvious mechanism for leveraging DHCP
to populate the DNS. The idea here is that you do RA+SLAAC, or RA+CGA, and
then you contact the DHCP server to tell it what address you allocated and what
name you want associated with it, and to get any local network configuration
information you might need.
However, of course this is new technology that isn't even standardized yet.
I'd like it if homenet recommended implementing this, but I think another way
of populating the DNS is through mDNS—when a host publishes its name in mDNS,
it's assumed to be valid as long as no conflicting registration has been made
locally. I don't particularly love this method because mDNS doesn't have the
same duplicate detection features that DHCP does through the DUID, but it
wouldn't be _worse_ than plain mDNS, and would allow the DNS resolver to query
a consistent FQDN tree for local names, so that it would work whether you were
attached to the local wire or not.
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
