On 05/08/2012 07:58, Ray Hunter wrote:
> I disagree. The context of my message is that there should be some
> identifier that can disambiguate the namespace per Homenet.
That's what I meant too. The only point is to avoid ambiguity in the
namespace. The only reason for using a ULA prefix to create a unique
identifier string is to avoid the bother of inventing a new method of
creating a unique identifier string. The name has no relation to
addressing or routing whatever. If you prefer some other way of creating
a string with a very high probability of uniqueness, that's fine.
Brian
> 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:[email protected]>
>> 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 <[email protected]>
>> ------------------------------------------------------------------------
>
>
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
