Re: [mdnsext] mDNSext features/requirements rollup

As a first step I'm ok with this, in fact I'm already doing it, but I view this as mostly a work around or hack.

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 o a proxies behavior.

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.

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.

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.

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.

-- 
===============================================
David Farmer               Email:farmer@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota    
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

On Jan 29, 2013, at 12:11, "Stephen Orr (sorr)" <sorr@cisco.com> wrote:

> 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.
> 
> How the information gets displayed, searching etc would be left up to the client GUI.
> 
> Stephen
> 
> -----Original Message-----
> From: mdnsext-bounces@ietf.org [mailto:mdnsext-bounces@ietf.org] On Behalf Of Dan Harkins
> Sent: Tuesday, January 29, 2013 12:24 PM
> To: David Farmer
> Cc: mdnsext@ietf.org; Andrew Sullivan
> Subject: Re: [mdnsext] mDNSext features/requirements rollup
> 
> 
>  Hello,
> 
> On Mon, January 28, 2013 5:07 pm, David Farmer wrote:
>> 
>> So you hear a bunch of us pushing to solve this with network hacks, or 
>> mDNS hacks.  Not because we think it is really the right way, but 
>> because the network is what we can effect, its the levers we can 
>> control.  The applications and wiz-bang-thing devices are out of our 
>> control and, right or wrong, we have had exceptions placed on us to 
>> make them work on our networks.
>> 
>> So, while it may not be the right thing, I need a way to make normal 
>> mDNS and Link-Local DNS Services Discovery work on my network.  Which 
>> consists of multiple segments and the services the users want may or 
>> may not exist on the same segment.  Fundamentally, this is either a 
>> symptom of the success of mDNS and Link-Local DNS Services Discovery 
>> or a failure to think through the consequences of not including 
>> broader scalability in the original solution, take your pick.
> 
>  What you're asking for is for networking devices like routers and firewalls and the like to provide a form of proxying for these link-local DNS services discovery. This can be enhanced by using smarts in the network (e.g. is the authenticated wiz-bang-thing authorized to make such a query?) and by explicit config of the networking device. The nice thing about this is that none of the wiz-bang-things need to be touched, they do what they always did but get a much more rich response.
> 
>  This seems to me like a well-defined problem we could work on that could produce a useful RFC.
> 
>  regards,
> 
>  Dan.
> 
> 
> 
> _______________________________________________
> mdnsext mailing list
> mdnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/mdnsext