Subject: Re: [mdnsext] mDNSext features/requirements rollup

From: RJ Atkinson <[email-masked]>
Date: Thu, 7 Feb 2013 08:58:53 -0500

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Feb 2013 11:52:14 -0500

>>>>> "RJ" == RJ Atkinson <[email-masked]> writes:
    >> attempting to treat (2) as a special case of (1) will mean that
    >> names designed to be local to (1) will leak into (3).

    RJ> The claim above is not obviously true for several reasons:

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

There are significant problems with split-horizon.
They didn't show up until we had nomadic devices like laptops and now
smartphones.   Consider that the MIF WG has an entire draft to
attempting to solve this problem (I think it's a total fail though)

Big organizations have fewer problems because they know how to deploy
the right infrastructure and do the right configuration and training for
end(remote) notes, but smaller (dis)organizations basically devolve to
using IP address literals for all internal hosts ("intranet"s) because
of road warriors and VPNs and the like. 

That's why mDNS has been such a success, and why in homenet and here
there has been such a big discussion about what is .site, because nobody
wants to type IPv6 literals, and yet v6 global end addressability
is making people realize that they will want (some) connectivity.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Feb 2013 11:47:34 -0500

>>>>> "RJ" == RJ Atkinson <[email-masked]> writes:
    RJ> Of course, we ought not REQUIRE that it be implemented in
    RJ> routers -- both in the sense of not requiring router
    RJ> implementers to include it and also in the sense of not
    RJ> requiring network operators to put the function in routers.

+1

Perhaps we should write that this function must be easily co-located
inside a router, but that it should not depend upon any (default)
routing infrastructure to actually bring packets there.

I can imagine one implementation where we would define some anycast address
to which DNS UPDATEs and queries should be sent to, and we would assume
that the routing infrastructure would respond, with the result being
blackholed by ISPs.  Such a system would *require* the proxy function to
be co-located in routers, which I think is what you are getting at: we
don't want to require it.

A system of proxying link-local multicast would not require co-location
the way an anycast would.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 7 Feb 2013 18:40:04 -0500

> inter-connected subnets/links at my site/building/home/campus.

I was being deliberately vague partly because of the whole
do-what-I-mean flavour of this set of problems, but I think the
distinctions you're making are probably good enough
operationalizations for our purposes.

>    it isn't inherent in a split-horizon DNS deployment.

Problems have in fact arisen.  The root DNS servers receive a large
amount of traffic for names that don't exist and that are clearly
leakage of split horizon queries and of local-scope queries (*.local)
that have escaped.  One of the reasons the SiteFinder idea caused so
much anguish was that, while wilcards in some other TLDs had worked
for some time, .com turned out to be special in that failed queries
were implicitly assumed to be inside .com (so local-use-only DNS names
worked just fine before SiteFinderDay, but suddenly all got resolved
inside .com on SiteFinderDay).  From the point of view of end users,
there are no problems; from the point of view of the Internet
infrasrtucture, there are plenty of problems.

>    they have compatible namespaces).

Except that all the clients need to work as though the mDNS (".local")
names and the Internet DNS names are part of a single naming
continuum.  This fact is why .local names leak out to the Internet.
In the case of the current mDNS, at the very least it's possible to
identify (just from network topology) the border one shouldn't
traverse.  The same is not true in case (2): there's just no way to
infer the scope of the site of inter-connected links at "my site",
because we don't have a way to identify that.  (In some ways, we are
walking in sideways to the same problem people have experienced in the
DNS -- attempting to infer organizational boundaries from delegation
boundaries, or trying to infer "my domain" from the search path or
other such tricks used by standard resolver libraries.)

I've been musing over one possible strategy: to use the DNS to assert
some network boundaries.  But I haven't worked out the details of how
this might help.  Maybe a clue for mDNS responders?  That seems to
foil the whole zeroconf point of all this, though.

> not intended to be accessible from outside the home.

Well, obviously we can't ditch this: it's widely deployed.  Also IMO
it's not realistic to expect local-scope names to work across network
boundaries.  So we're now arguing about whose scope gets to be called
"local" :)

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Farmer <[email-masked]>
Date: Thu, 14 Feb 2013 23:15:38 -0600

> UI considerations, but UIs are normally outside the IETF scope.

For the most part I agree, but AppleTalk Ver2 included Zones that 
allowed users to self organize their services in the UI, and helped 
scale the name space to extend to the multi-segment environment of 
AppleTalk Ver2.  So while I don't want to specifically get into UI 
issues, a single flat name space doesn't scale, especially for the UI, 
but for many other reasons too.  This is a protocol issue we need to 
deal with in my opinion.  Stuart's hybrid proxy proposal has one 
possible solution for this, I'm not sure its the right solution. 
However, we need something that helps scale and organize the namespace 
and it needs to be designed into the protocol, especially as we expand 
from link local to a multi-segment environment.

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: David Farmer <[email-masked]>
Date: Fri, 15 Feb 2013 00:18:08 -0600

>      inside an affordable enterprise-grade switch from any

My concern is much less about processor than other resources like 
memory. But my more fundamental concern is we would be tracking another 
kind of state in the routers, the naming state of the network.

So the routers are in the idea location to do this, but I'm really 
concerned about the instability adding more network state into the 
routers.  If you think of a home broadband router they pile all sorts of 
state into them, DNS anmeing state, DHCP addressing state, TCP and UDP 
connection state, in addition to the packet forwarding state (the 
routing table), but they are doing this for 1 to 20 devices in the 
typical home.  While in large scale enterprise routers we try to make 
thins as stateless as possible, ideally the routing table only, and we 
are supporting 2500 to 7500 devices with a single large scale router.

So that doesn't mean the enterprise routers don't support the other 
services that the broadband routers do, but they do them in different 
ways.  DHCP is usually support with a relay agent, host are directed to 
DNS other services through DHCP or Router Advertisements in IPV6.

So yes, sometimes the router can and probably should the proxy or other 
naming services entity.  But I'd like us to consider a relay agent model 
or redirector model too, like you talk about in D above.  Where the 
router forwards the requests to another naming services entity or 
redirects requests to another naming services entity, that actually 
contains the naming state. In this way the routers could participate 
without building naming state in the routers themselves, and allowing 
naming to effect the stability of the routers.

This comes from my experience of runing an extremely large 
multi-protocol network that supported AppleTalk (300+ zones, 3000+ 
services), IPX (2000+ SAPs), IP, DECNET Phases 3,4,&5 all on about 500+ 
segments, where AppleTalk and IPX naming state in the routers created 
much instability and drove several rounds of upgrades.

Currently on just our 32 wireless network segments there are 3000 to 
5000 or more mDNS services advertised at peak times of the day, and that 
doesn't include any the wired segments yet.  So for scaling I do want 
the routers to participate in the naming service, but not contain any of 
the naming state itself, that's what I'm worried about.

---

From: David Farmer <[email-masked]>
Date: Fri, 15 Feb 2013 02:47:26 -0600

> simply because this WG doesn't have a specification one

OK, my comments were based on testing I did more than a year ago, and 
I'd swear that I saw only link-local IPv6 addressing for services on a 
dual-stack network with a IPv6 GUA prefix available.  However, I just 
looked at this again and now I'm seeing IPv4 GUA, IPv6 link-local, and 
IPv6 GUA addressing associated with the same mDNS service name.  So, I 
don't know if I just was remembering things wrong, if implementations 
have changed, or I just screwed up in my previous testing.  Whatever the 
case, this isn't the problem I thought it was, sorry.

However, I will say that care needs to be taking to not proxy link-local 
(IPv4 or IPv6) addressing associated with services and only proxy GUA or 
ULA addressing for services off of a network segment with multicast or 
hybrid proxy of mDNS services.  Furthermore, we need to define if a 
proxy should defend the name of a link-local only service on other 
segments to preserve naming coherency for any devices that may see the 
link-local only service and the potentially conflicting GUA addressed 
service of the same name on a different segment?  I think link-local 
only name needs to be defended.  But then, what address should the 
link-local only service be advertized with on the other segments? 
Should the proxy use its own link-local address on the other segment?

Should an mDNS proxy also proxy the data path in the case of a 
link-local only addressed service as well?  In the case of an mDNS proxy 
across a NAT Router then you would have to use the proxies outside 
address and NAT the Data path of the service, there are a whole bunch of 
corner cases here, BLECH!!

There is a similar question between IPv4 and IPv6, the 
ships-in-the-night solution for IPv4 and IPv6 used in mDNS may or may 
not be workable across multicast and hybrid proxies.  Which every way we 
go with it we need to give serious attention to the dual-stack naming 
behavior across proxies, multicast or hybrid.  If this is implemented 
differently between solutions you could see some really weird behavior.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 15 Feb 2013 10:11:29 -0500

On 15  Feb 2013, at 03:47 , David Farmer wrote:
> However, I will say that care needs to be taking to not proxy
> link-local (IPv4 or IPv6) addressing associated with services
> and only proxy GUA or ULA addressing for services off of a
> network segment with multicast or hybrid proxy of mDNS services.  

Off hand, I'm not sure exactly what set of rules/guidelines
ought to be promulgated, but I agree that this is a question
that this WG ought to examine -- and that some set of rules
or guidelines ought to be documented as part of any 
standards-track specifications.

> Furthermore, we need to define if a proxy should defend the
> name of a link-local only service on other segments to preserve
> naming coherency for any devices that may see the link-local
> only service and the potentially conflicting GUA addressed
> service of the same name on a different segment

I agree this deserves thought.  I don't have a firm view
myself just yet.

> link-local only addressed service as well?  

Also a good question that the WG ought to discuss and address.

> In the case of an mDNS proxy across a NAT Router then you
> would have to use the proxies outside address and NAT
> the Data path of the service, there are a whole bunch
> of corner cases here, BLECH!!

My intuition is that a NAT boundary (like an router interface
running E-BGP) is a natural indication of a natural 
administrative boundary.  

For a wide range of reasons, one normally ought not ("by default") 
proxy or forward mDNS packet across any natural administrative 
boundary.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 15 Feb 2013 10:26:19 -0500

On 15  Feb 2013, at 01:18 , David Farmer wrote:
> So the routers are in the idea location to do this, but I'm
> really concerned about the instability adding more network state
> into the routers.  

I have operational experience with large-scale  (e.g. campus 
wide) deployments of AppleTalk over Ethernet that used low-cost 
(and by today's standards) very very low performance CPUs 
(e.g. 68K) with tiny amounts of RAM.

The AppleTalk service advertisement proxying and zone
advertisement proxying did NOT create any sort of
instability.  Back in those days, the deployed world was
multi-protocol with some DECnet, some IP, a lot of IPX,
and some other stuff besides, so there was a lot more
state that needed to be kept inside the routers.
With today's IP-centric world, the state needed in
routers is much less, generally just a bridge table,
an IPv4 RIB/FIB and an IPv6 RIB/FIB.  Further, unlike
back then, the actual packet forwarding generally 
does not involve the switch/router CPU or the RAM
associated with the CPU.  Instead, commodity or custom
packet processing ASICs handle the heavy lifting
today, and most of the other state (e.g. bridge table, 
IPv4 & IPv6 FIBs) is stored separately in commodity TCAM.

So modern enterprise switches have tons of spare RAM
and A LOT more CPU to spare than those devices did
back in the 1990s.

> While in large scale enterprise routers we try to make
> things as stateless as possible, ideally the routing table only,
> and we are supporting 2500 to 7500 devices with a single
> large scale router.

Back in the day, tiny (68K + smallish RAM) AppleTalk (EtherTalk) 
routers were supporting 2000+ devices successfully -- without
instability.  Today's enterprise routers and L3 switches are 
MUCH more capable, with more spare capacity.

So my operational experience says that this is not a real
problem, provided we are ordinarily sensible.  

For one thing, mDNS information ought to be "soft state", that 
regularly expires in some sensible way, and gets tossed and 
relearned when someone chooses to reboot (or significantly 
reconfigure without rebooting) some router or L3 switch.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 15 Feb 2013 10:28:40 -0500

On 15  Feb 2013, at 00:15 , David Farmer wrote:
> ... AppleTalk Ver2 included Zones that allowed users to self organise
> their services in the UI, and helped scale the name space to extend
> to the multi-segment environment of AppleTalk Ver2.  

Agreed.  I still think that is a useful operational capability.

I simply want to separate the protocol functions from the
UI issues.  Protocol functions seem within the scope for this WG,
but UI issues seem outside the scope for this WG.

Cheers,

Ran

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Feb 2013 09:51:36 -0800

Hi, all,

>> UI considerations, but UIs are normally outside the IETF scope.

UI considerations are out of scope, but IMO a protocol consists of:

	data exchanged on the layer below
	state maintained at the endpoints
	timer events
	events on the layer above
	rules describing how these relate (i.e., a Mealy machine)

The IETF has as much obligation to describe the upper layer events 
("API") as it has describing the format "on the wire".

I agree, e.g., that the details of the argument format and order for 
creating sockets is out of scope for TCP, but TCP *does* specify what 
kind of upper layer actions drive the protocol.

The same ought to be true here.

Joe

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 15 Feb 2013 13:00:25 -0500

On 15  Feb 2013, at 12:51 , Joe Touch wrote:
> UI considerations are out of scope, ...

Well, I'm glad we all agree on that. :-)

> The IETF has as much obligation to describe the upper layer
> events ("API") as it has describing the format "on the wire".

I agree with the obligation to describe "upper layer events"
that are inherently part of some IETF standards-track
protocol (i.e. elements required for interoperability).

However, the IETF routinely chooses not to define
Application Programming Interfaces (APIs).  

I don't think this WG is *obliged* to produce an 
Application Programming Interface specification.
That seems optional to me.

Cheers,

Ran

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Feb 2013 10:45:36 -0800

> That seems optional to me.

It depends on what you consider an API. If it's at the level of Unix 
Sockets, I agree.

However, a good example of a "upper layer spec" is in TCP, describing 
OPEN, CLOSE, ABORT, etc., separately from how an OS implements them.

IMO, too many protocols ignore those upper layer indicators, leaving 
them to the implementers to figure out. That breeds incompatibility, and 
should be avoided.

Joe

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 15 Feb 2013 14:14:20 -0500

On 15  Feb 2013, at 13:45 , Joe Touch wrote:
> It depends on what you consider an API.
> If it's at the level of Unix Sockets, I agree.

Great.  We're on the same page then.

Describing the TCP functions/operations/state-machine 
details necessary for interoperability are one thing, 
while the BSD API to TCP/IP is quite another.

Cheers,

Ran

---

From: "Johnson, Neil M" <[email-masked]>
Date: Fri, 15 Feb 2013 21:34:56 +0000

My former employer (a large multi-national electronics device manufacturer) at one time had ~13,000 AppleTalk Zones and 10's of thousands of devices. We had all sorts of issues:
- Name collisions when far spread admins choose the same name for their zones.
- Router performance issues handling that many zones and devices.
- Issues with software trying to display that many zones and devices.
We were more than glad to get rid of Apple Talk when IP became the defacto standard.
My point is to becareful what you mean by large scale :-)
-Neil
________________________________________
From: [email-masked] [[email-masked]] on behalf of RJ Atkinson [[email-masked]]
Sent: Friday, February 15, 2013 9:26 AM
To: [email-masked]
Subject: Re: [mdnsext] mDNSext features/requirements rollup

Yours,

Ran

_______________________________________________
mdnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mdnsext

---

From: Joe Touch <[email-masked]>
Date: Fri, 15 Feb 2013 13:45:52 -0800

> while the BSD API to TCP/IP is quite another.

Just to be clear, I do look forward to the level of OPEN, CLOSE, ABORT, 
etc., though. That's critical, and is part of what's needed for 
interoperability.

Which aren't Unix sockets, but Unix sockets are *one* implementation of.

Joe