Sure, but the scope of this discussion is name resolution in Homenet,
where there is always at least 1 router present.
So these two devices could always use unicast to reach a rendezvous point.
What devices do on other ephemeral ad hoc networks is out of scope.
joel jaeggli <mailto:[email protected]>
13 September 2012 18:27
On 9/12/12 10:35 PM, Ray Hunter wrote:
Fair counter point to my suggestion. Enterprises don't generally put
laptops in public viewable DNS.
Isn't your requirement to support highly mobile devices a good reason
to avoid mDNS wherever possible?
MDNS has a purpose, which is to locate on-link resources. particularly
if a network is adhoc or ephemeral it seems like the appropriate tool
for that. two devices forming an adjacency may have no other network.
[mDNS being link local specific, and any extensions/gateways from
mDNS to unicast DNS will also be local network specific, so your
favourite coffee shop network may not support them]
regards,
RayH
Mark Andrews <mailto:[email protected]>
13 September 2012 03:02
Note updating DNS involves both FORWARD and REVERSE entries and the
solutions can be different.
My machines have names. Those names don't change as I move around
the world. Random DHCP servers at coffee shops DO NOT have the
ability to update the DNS entries for those names. They do have the
authority to update the PTR records in in-addr.arpa and ip6.arpa
namespaces.
------------------------------------------------------------------------
<snip>
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
Ray Hunter <mailto:[email protected]>
13 September 2012 07:35
Fair counter point to my suggestion. Enterprises don't generally put
laptops in public viewable DNS.
Isn't your requirement to support highly mobile devices a good reason
to avoid mDNS wherever possible?
[mDNS being link local specific, and any extensions/gateways from mDNS
to unicast DNS will also be local network specific, so your favourite
coffee shop network may not support them]
regards,
RayH
<snip>
Mark Andrews <mailto:[email protected]>
13 September 2012 03:02
Note updating DNS involves both FORWARD and REVERSE entries and the
solutions can be different.
My machines have names. Those names don't change as I move around
the world. Random DHCP servers at coffee shops DO NOT have the
ability to update the DNS entries for those names. They do have the
authority to update the PTR records in in-addr.arpa and ip6.arpa
namespaces.
Machines start off with mDNS to avoid bootstrap problems. They
then have the ability to get a TSIG using TKEY signed with a
administrators TSIG (think Username/Password pair) for the forward
zone. This will be stored in non-volitile storage on the master
nameserver and on the client. Once the client has the TSIG key it
uses that to update its own forward entries.
Machines register PTR records in the reverse zones using TCP as the
authenticator in the reverse zone unless there is a DHCP option
that says to use the DHCP server to relay the PTR record update.
Ted Lemon <mailto:[email protected]>
12 September 2012 14:36
Two reasons. First, there's strong opposition to this, and so it will
never happen, whether it is the right idea or not (I don't think it's
particularly the right idea, although I'm not vehemently opposed to it
either). Secondly, it precludes the use of CGA by hosts.
Ray Hunter <mailto:[email protected]>
12 September 2012 08:41
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?
------------------------------------------------------------------------
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
