Re: [mdnsext] mDNSext features/requirements rollup

[RJ Atkinson <[e-mail]>]

This note replies to several different notes in this thread.
I've tried to do this by working from oldest note at the
top of this note to most recent note at the bottom of this
note.

If one replies, trimming my original while editing the reply
is definitely encouraged, as this is longish.  Thanks !

Earlier, on Jan 29th 2013, Stephen Orr wrote, in part:
> I agree with Dan on this - making sure that the network 
> infrastructure has the ability to operate as good "mdns clients" 
> while providing filtering/proxying of DNS-SD advertisements 
> between L3 segments would be a fundamental use case.

Agreed.  For interconnection of different IP subnets,
past experience has shown that putting this kind of
function inside routers makes sense.  Routers are well
positioned to handle the proxy function, and already
are commonly used to provide various kinds of packet
filtering.

Of course, we ought not REQUIRE that it be implemented
in routers -- both in the sense of not requiring router
implementers to include it and also in the sense of not
requiring network operators to put the function in routers.

Later on 29th Jan 2013, David Farmer wrote, in part:
> 1. What happens if you get a proxy loop?  
>    This seems really bad! 
>    Right now I have nothing to prevent this.
> 
> 2. Maybe loop detection can be defined as part of a proxies behaviour.

I agree that loop detection/prevention is an
operational concern that ought to be addressed.

> 3. Creates the same problem AppleTalk had, routers involved
>    in the name binding protocol. This is especially a problem
>    for most enterprise network gear with powerful fast-path ASIC
>    switching and relatively low powered slow-path processors.

I really disagree with (3) above, on multiple grounds.

A.  My own operational experience with AppleTalk (EtherTalk)
    on a very large campus network was that even low-cost
    routers with small CPUs could handle NBP/AppleTalk traffic
    -- and this was ~15 years ago when a "low cost CPU" was
    MUCH less capable than today.

B.  Again, my own operational experience with AppleTalk
    on a very large campus network was that having this
    function inside the router meant that (1) the network
    operator could apply policy, (2) prevented loops, and
    (3) helped scalability by managing the inter-subnet
    AppleTalk traffic.

C.  Back then, "powerful fast-path ASIC switching" was NOT yet
    widely available and the same "low-powered slow-path 
    processors" (from ~15 years ago) were able to handle 
    BOTH bridging/forwarding and also AppleTalk/NBP traffic.  
    Also, back then the world was much more multi-protocol 
    (e.g. IPX, Banyan, IPv4, and AppleTalk were commonly 
    deployed concurrently on a single campus network using 
    the same interconnection devices; my site also had some
    experimental IPv6 traffic).

D.  The widespread availability of commodity ASIC packet
    processors and the huge increase in the power of what
    we call a "low-powered" CPU means that a well-designed
    "mDNS agent/relay/proxy" really ought not be an issue
    inside an affordable enterprise-grade switch from any
    major vendor.

> 4. Doesn't really solve any multicast traffic issues or scaling
> of the name space. Yes, it's not the network's problem to display
> 100s of services, but it will be a problem with most of the GUI's
> I've seen.

We ought to keep potential UI concerns separate from the
potential protocol concerns.  Getting the protocol design
reasonably correct is a central issue for the IETF, whereas
UI design generally is beyond the IETF's scope.  IETF might
well offer document UI concerns and/or offer advice about
UI considerations, but UIs are normally outside the IETF scope.

> 5. What about IPv6, mDNS is using link-local IPv6, how do you
> route between multiple IPv6 link-local, by definition you can't.
> So multi network mDNS is really IPv4 only right now.

I'm not too sure about the claim in that last sentence.  

I have heard of at least one multi-subnet "proxy-oriented" 
implementation of mDNS that exists today, and that approach 
should work equally well for IPv4 and IPv6.  Of course, that
existing prototype/implementation is necessarily proprietary,
simply because this WG doesn't have a specification one 
could comply with.

> So a proxy that safely interconnects multiple link-local nets
> is only one small part of the solution space we need.  That is
> only a start, but an important start.

I mostly agree with this.

Much later, on 6th February 2013, Andrew Sullivan wrote, in part:
> 
> It seems to me that, in Internet terms, we really have three
> scopes:
> 
>     1.  my network;
>     2.  my network_s_;
>     3.  the Internet.

I'm not entirely clear on Andrew's terminology, but my guess
is that by (1) he means this subnet/link and (2) the set of
inter-connected subnets/links at my site/building/home/campus.

If I'm understanding his meaning, existing mDNS + DNS-SD is
a sufficient solution for (1) -- evidence very broad deployment
and use today (and for the past 5 years or so).

> In naming, historically we've treated case (2) as a special case
> of (3), and sometimes added split-horizon or something to it.  
> What people are really asking for now is to treat case (2)
> as a special case of (1), and figure out how to make that work.

From a DNS perspective, I mostly agree with this.
In recent history, the DNS deployments mostly seem to be:
      (1) is something.LOCAL
      (2) is something.FOO.BAR.TLD
      (3) also is something.BAZ.TLD

We are now looking to extend a single instance of .LOCAL
beyond a single link/subnet, but contain it within a 
single site/campus/home.

> The problem I see is that, because of historical practice,
> attempting to treat (2) as a special case of (1) will mean
> that names designed to be local to (1) will leak into (3).  

The claim above is not obviously true for several reasons:

A) Split-horizon DNS deployments have been around since
   the 1990s at least.  THese are widely deployed.  Few
   problems have arisen in practice, as a percentage of
   split-horizon deployments.  Yes, problems could arise,
   for example if a human misconfigures something, but
   it isn't inherent in a split-horizon DNS deployment.

B) The current work here on (2) is extending mDNS rather than
   putting a bunch of *.LOCAL data into the unicast DNS system
   (which in many ways is a different system entirely, although
   they have compatible namespaces).

I think we all agree that a functional requirement is
(edit to taste):

	Any multi-link/multi-subnet mDNS solution needs
	to provide mechanisms to ensure that locally-scoped
	DNS information conveyed via mDNS (including
        whatever multi-hop mDNS solution emerges) does
        not leak across an administrative boundary
        (e.g. home, building, campus, site).

> I think that leaking locally-scoped names onto the public
> Internet is going to be a bad thing, and that's why I'm
> arguing that what is really needed is a way to bring an
> actual global namespace to this.

I'm not entirely sure what the above quote is trying to say.

I agree with supporting the conveyance of global-scope
DNS information via mDNS (and via whatever extensions 
this WG devises).  

I have clients where this (using mDNS as extended by this WG 
to convey DNS records using global-scope naming) is an 
important use-case.

I don't agree with the idea of eliminating .LOCAL or
similar scoped domains or information advertised in those
domains.  Its unrealistic to believe that a typical home
deployment will use global-scope DNS naming for devices
not intended to be accessible from outside the home.

Yours,

Ran Atkinson