I disagree. The context of my message is that there should be some
identifier that can disambiguate the namespace per Homenet. I'm talking
about using the ULA to generate a HomenetID for use in the namespace.
See RFC6281.
The HomenetID and DNS subomain (or as you put it
"<somethingveryobscure>") may be generated by one unique host (e.g. each
Homenet border router) based on a ULA. But that does not mean it cannot
be discovered by all hosts and routers in the Homenet (via some bunch of
discovery mechanisms such as automatic prefix distribution for
router-router and DHCPv6 for router - fridge).
The HomenetID will remain constant as long as the ULA of the border
router remains constant. If it appears to vary (because the border
router changes) then highly mobile nodes will get some indication that
they may not be connected to their own Homenet, and ask for user input
to accept an update. Static nodes would only know their local HomenetID,
and if it changed they could be set to always accept the update without
user input. Eventually you would probably end up with a search list
linked to the number of border routers the end node has ever
encountered, but end nodes can automatically age out old entries.
We might also want to be able to manually override the auto-generated
HomenetID to cover the case where border router hardware is replaced by
the user, but that's no different to MAC address cloning on CPE's in the
past (where ISPs used the MAC address of the CPE as an identifier in
management systems).
Sure there's a downside in complexity of the namespace. The potential
upside of this approach is that the same
<somethingveryobscure>.sitelocal. zone file could also be mounted as a
secondary on <somethingveryobscure> .<ISP DNS root> or
<somethingveryobscure> .<employer's DNS root> if the ISP or enterprise
wished to provide this service for global name resolution. Highly mobile
nodes would only need two items in their DNS search list, the search
list can be pretty much auto-generated, and they can use the same name
resolution technology (DNS) wherever they are located. It also
completely avoids trying to synch mDNS with DNS, which I think you'll
agree is likely to be very difficult.
Curtis Villamizar <mailto:cur...@occnc.com>
4 August 2012 22:06
With all due respect, any suggestion to use the ULA in a domain name
produces either a domain that is unique to one host or a domain that
is every bit as global as sitelocal, depending on whether by stating
"ULA prefix" you mean the local ULA or the well-known global ULA
prefix.
In rfc4193:
Local IPv6 unicast addresses have the following characteristics:
- Globally unique prefix (with high probability of uniqueness).
- Well-known prefix to allow for easy filtering at site
boundaries.
[...]
If you mean the first (the local ULA prefix), then the domain is
unique to one host. My computer could never find my fridge using the
hostname "fridge" unless it knew every ULA on the local network and
created an entry in the dns search path. Very long entries in the dns
search path are a very bad thing (tm).
If you means the second (the assigned prefix under which all ULA fall)
then the domain is common to all hosts in the universe that generate a
ULA address. The only difference is it is
<host>.<somethingveryobscure>.sitelocal.
Curtis
In message <501965d4.1040...@globis.net>
------------------------------------------------------------------------
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
