Re: [v6ops] question about draft-jjmb-v6ops-unique-ipv6-prefix-per-host

[Tim Chown <[e-mail]>]

> On 4 Jul 2017, at 07:59, Ole Troan <[e-mail]> wrote:
> 
> Brian,
> 
>>> On Jul 3, 2017, at 5:41 PM, Ole Troan <[e-mail]> wrote:
>>>> It breaks the assumption that everything you want discovered is within the same broadcast domain. Many think that assumption was broken anyway.
>>> 
>>> Given the document I'm presently working on, I wouldn't really argue with that, except to say that it's still the default assumption in most environments.
>> 
>> Yes, and that has deeply impacted both a document I'm working on
>> (draft-ietf-anima-grasp) and a demo implementation thereof
>> (https://github.com/becarpenter/graspy/blob/master/grasp.py).
>> 
>> The cost of *not* having link-local multicast is considerable,
>> because it means that every node, however dumb, must replicate
>> and relay discovery in one way or another.
> 
> The solution I briefly described previously of course supports link-local multicast.
> 
> If your answer to the discovery problem is that we must put all nodes on the network in the same broadcast domain, we know that doesn't scale well. Apart from Taht showing that bridging links with very different properties doesn't work well either (wired and wireless). This was the premise for homenet.
> 
> For the current mDNS based discovery, that is already heavily filtered by the network in large L2 domains. It is just too noisy.
> 
> Since we have to solve the problem for multiple links anyway, does it then make a difference that logical topology follows physical topology and each host is on its own link?
> 
> Fingers crossed for hybrid dns-sd... the IETF glorious past in service discovery hasn't given me much confidence though. ;-)

The hybrid proxy work was split at IETF97 into a discovery and an advertising proxy. The discovery proxy is about to be sent to the IESG (though it carries a reference to .home that needs fixing); see https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-06

The general approach is that unicast queries from a DNS-SD client for a specific subdomain allocated to a link, e.g. Building1.example.com, are forwarded until they reach the discovery proxy (as the delegated authoritative name server for that subdomain), and the unicast response is then synthesised from responses to a local multicast DNS query on the link. The new DNS Push work allows client hosts to subscribe to receive updates; DNS Push is also about to be sent to the IESG.

Tim