Subject: [mdnsext] Forwarding link-local IP multicast

From: Tom Pusateri <[email-masked]>
Date: Tue, 6 Nov 2012 17:50:55 -0500

I think we need to be cautious about schemes to proxy or relay link-local IP multicast packets (224.0.0/24) across IP subnets.

While this may seem tempting, duplicates and loops are not easy to detect and the problems annunciated from the operator at Georgia Tech about too many mDNS packets will pale in comparison.

The multicast routing protocols take great care to create minimum spanning trees from the source to the many receivers of routed multicast packets. They prune branches that would create loops and ensure only a single copy of the original packet is sent on any one link.

To duplicate this effort requires coordination between each mDNS proxy/relay and you will end up redesigning the multicast routing protocols under another name.

So if you want to forward IP multicast, please use the multicast routing protocols that have been developed in the IETF that are deployed and proven.

I'm not suggesting that routed IP multicast be the solution, only that proxy/relays that forward Iiink-local IP multicast should met with skepticism.

Thanks,
Tom

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Nov 2012 11:31:01 -0500

>>>>> "Tom" == Tom Pusateri <[email-masked]> writes:
    Tom> I think we need to be cautious about schemes to proxy or relay
    Tom> link-local IP multicast packets (224.0.0/24) across IP
    Tom> subnets. 

    Tom> While this may seem tempting, duplicates and loops are not easy
    Tom> to detect and the problems annunciated from the operator at
    Tom> Georgia Tech about too many mDNS packets will pale in
    Tom> comparison. 

    Tom> The multicast routing protocols take great care to create
    Tom> minimum spanning trees from the source to the many receivers of
    Tom> routed multicast packets. They prune branches that would create
    Tom> loops and ensure only a single copy of the original packet is
    Tom> sent on any one link. 

So your suggestion is to send to a site-local multicast address and use
existing multicast protocols to distribute that to the site.  While I
concur, I'm not sure it can be done properly for IPv4 sites where there
are layers of NAT.  IPv4 is in scope for this WG (while it's out of
scope for homenet)

Many campuses have IPv4 NATs disguised as routers/switches. Sometimes
they are intended to be there, sometimes not. 

Is it in scope for a machine F, located behind NAT G, to be able to find
printer P, which is located outside the NAT?  

For instance, the math department and the french department on floor 12,
of TallBuilding on BigU.edu,  might have a printer down the hall.  Both
could have a simple installed by the departmental IT guy onto the LAN
which is on the floor.  

(why would IT guy do this at a university that has lots of public IP?
lack of training... because of belief that NATs provide security, etc)

-- 
Michael Richardson
-on the road-

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Wed, 7 Nov 2012 18:19:15 +0000

A reliable multicast through campus network is a challenge, and what makes the issue even more challenging is that packet transportation/delivery is only a part of the problems --- Considering the scalability/security/authorization/policy, not all but a selective subset of service instances may be delivered to a client, which is not something a plain multicast can solve, IMHO.

Yi

On Nov 6, 2012, at 5:50 PM, Tom Pusateri wrote:

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

---

From: Matthew Gast <[email-masked]>
Date: Wed, 7 Nov 2012 22:10:33 +0000

Exactly.  Packet delivery is only a small part of the problem here.  If we
choose to take on security work in the form hinted at by Kerry at the end
of his requirements discussion yesterday, then we will need to have
something that looks inside the content of the multicast packets to make
decisions.  I'm not in favor of developing new multicast routing
protocols.  There's a possibility that we may not want to use multicast
because large wireless LANs will often disable multicast entirely.

Matthew

On 11/7/12 10:19 AM, "Yi Yang (yiya)" <[email-masked]> wrote:

>A reliable multicast through campus network is a challenge, and what
>makes the issue even more challenging is that packet
>transportation/delivery is only a part of the problems --- Considering
>the scalability/security/authorization/policy, not all but a selective
>subset of service instances may be delivered to a client, which is not
>something a plain multicast can solve, IMHO.
>
>Yi
>
>
>> I think we need to be cautious about schemes to proxy or relay
>>link-local IP multicast packets (224.0.0/24) across IP subnets.
>> 
>> While this may seem tempting, duplicates and loops are not easy to
>>detect and the problems annunciated from the operator at Georgia Tech
>>about too many mDNS packets will pale in comparison.
>> 
>> The multicast routing protocols take great care to create minimum
>>spanning trees from the source to the many receivers of routed multicast
>>packets. They prune branches that would create loops and ensure only a
>>single copy of the original packet is sent on any one link.
>> 
>> To duplicate this effort requires coordination between each mDNS
>>proxy/relay and you will end up redesigning the multicast routing
>>protocols under another name.
>> 
>> So if you want to forward IP multicast, please use the multicast
>>routing protocols that have been developed in the IETF that are deployed
>>and proven.
>> 
>> I'm not suggesting that routed IP multicast be the solution, only that
>>proxy/relays that forward Iiink-local IP multicast should met with
>>skepticism.
>> 
>> Thanks,
>> Tom

---

From: Robert Cragie <[email-masked]>
Date: Wed, 07 Nov 2012 23:16:33 +0000

To some extent, I think it is unfortunate that the BoF has already got 
"mdns" in the name, which implies the use of mDNS (i.e. multicast). As 
was clearly pointed out in the BoF on Tuesday (6th), mDNS was originally 
aimed at Ethernet networks where multicast is cheap and effective and it 
was acknowledged this may not scale into a "site" (whatever that ends up 
being) or even to simple subnets based on wireless networks. Clearly in 
certain situations it would be preferable to use unicast DNS in 
conjunction with DNS-SD with probably some sort of distributed name 
servers but also to allow mDNS in conjunction with DNS-SD for the 
subnets which can support it effectively. The conundrum then becomes 
administration and configuration of the distributed name servers and 
what scope they support.

Robert

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 8 Nov 2012 06:10:53 -0800 (PST)

> because large wireless LANs will often disable multicast entirely.

  Yikes. Might a better approach be to let middleboxes learn about
what services are on links to which they are connected and answer
queries for those services made on different subnets based on
authorization/location/policy/whatever?

  Dan.

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Thu, 8 Nov 2012 19:29:16 +0000

> authorization/location/policy/whatever?

I agree as such a middlebox/proxy would have better knowledge on policy/location/identity and may make better decision to select the services.

Yi

---

From: Matthew Gast <[email-masked]>
Date: Fri, 9 Nov 2012 17:48:00 +0000

>authorization/location/policy/whatever?

Dan, I think we're in violent agreement here.  I didn't intend to preclude
the presence of middleboxes, though I was writing against the idea of
doing anything within the network layer with no input from upper layers.

The basic unit of service discovery is a query.  In today's service
discovery, that query is transmitted out the local link in a (link-local)
IP multicast.  One (bad) way of getting service discovery across an L3
boundary is to "route" that multicast.  If you want to apply "policy," to
borrow your term, that policy is applied based on the contents of that
query, and needs to look beyond the IP header.  If we try to solve the
problem solely at L3, we'll get a mess that pulls higher-layer information
into an L3 forwarding decision, and we get an ugly pseudo-routing
protocol.  To use a technical term, that's yucky.

Like you, I'm in favor of using something in the middle.  When you receive
a query, the IP multicast header is just encapsulation, but the policy
decision about where to send that service visibility is based on the query
contents.  I don't see a way around the middlebox holding at least some
state or policy, but I want to keep that state/policy/whatever separate
from IP forwarding and I especially don't want it to touch IP multicast
forwarding.  That does mean that policy will be applied against whatever
information the query holds.

What I was getting at with the last sentence is that our answers may not
be able to be IP multicast because some large WLANs will disable L2
multicast for scalability reasons.  Matt Sanders, the admin from Georgia
Tech who spoke at the BoF on Tuesday, talked about how much airtime the
mDNS frames were consuming on his network, but I don't recall the exact
numbers.  They seemed really high, though.

Matthew

---

From: "Johnson, Neil M" <[email-masked]>
Date: Fri, 9 Nov 2012 18:07:32 +0000

I just want to comment on the scalability of "middle boxes". We have ~180
buildings on our campus, most have their own IP (v4 and v6) subnet. In
addition, to keep our wireless broadcast domains reasonable we have
multiple wireless subnets that are allocated to users dynamically (Meaning
that two wireless clients in the same room maybe on different subnets).

I'm concerned that some of the scenarios proposed that use a middle box
would require it to have an interface (physical or virtual) in each
subnet. That won't scale for us.

-Neil.
-- 
Neil Johnson
Network Engineer
The University of Iowa
Phone: 319 384-0938
Fax: 319 335-2951
Mobile: 319 540-2081
E-Mail: [email-masked]

---

From: Matthew Gast <[email-masked]>
Date: Sat, 10 Nov 2012 03:57:51 +0000

Hi Neil,

That's useful input on a real-world deployment scenario, especially since
our big task right now is to write requirements.  That sounds like "must
support 1,000 links" (which I got by taking ~200 buildings with 3 wireless
IP blocks and 2 wired IP blocks, since I had to start somewhere -- but
please correct my wild-guess math if it's wrong).  What other steps have
you taken to get service discovery working across links on your campus
that might offer lessons for our requirements doc?

Matthew

---

From: Sebastian Hagedorn <[email-masked]>
Date: Sat, 10 Nov 2012 10:10:11 +0100

> subnet. That won't scale for us.

It would scale if the "middle box" were the router.
--
Sebastian Hagedorn - Weyertal 121, Zimmer 2.02
Regionales Rechenzentrum (RRZK)
Universität zu Köln / Cologne University - Tel. +49-221-470-89578

---

From: "Johnson, Neil M" <[email-masked]>
Date: Mon, 12 Nov 2012 18:37:23 +0000

I don't know about using a router for anything too complicated.  Our core
routers have CPU issues as it is (looking to upgrade this year).

I could see the router advertising (via mDNS) the location(s) of a box(es)
that services on the local link could then "register" with and or "query".

-Neil

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 12 Nov 2012 14:59:37 -0500

> that services on the local link could then "register" with and or "query".

Sort of like the DHCP server advertising the DNS server?

I think we should stay away from forwarding link-local IP multicast and fix the issues that are preventing wide-area bonjour from meeting the needs of the users.

Tom

---

From: "Johnson, Neil M" <[email-masked]>
Date: Wed, 14 Nov 2012 17:07:23 +0000

Matthew,

You are not too far off except for Wireless. Three subnets per building
sounds about right (one subnet for public devices, assigned Global IP's;
one subnet for devices that don't need Internet access, assigned RFC1918
IPv4 and IPv6 ULA space; and one for devices needing to reach the
Internet, but not be reachable from the Internet, Assigned RFC1918 IPv4
space and NAT'd or Fire walled to the outside world).

As for wireless, we use a controller based model and have 16 subnets of
/21 RFC1918 space NAT'd to two /22's. Those subnets are dynamically
assigned and span multiple buildings. Currently not multicast enabled.

AppleTV's and printers would probably be on the Non-NAT'd RFC1918 space
(only reachable from on campus and wireless), but may need to be visible
to users using a VPN off campus.

Some printers would be centrally managed (through a queue server) so those
queues might need to be discoverable as Services.

Sound Complicated enough for you ?

-Neil

On 11/9/12 9:57 PM, "Matthew Gast" <[email-masked]> wrote:

>>>>>Exactly.  Packet delivery is only a small part of the problem here.
>>>>>If
>>>>>we