Subject: Re: [mdnsext] xmDNS support in mdnsresponder for homenet
From: Joe Abley <[email-masked]>
To: Ray Bellis <[email-masked]>
Cc: "<[email-masked]>" <[email-masked]>, Kerry Lynn <[email-masked]>, Indtiny s <[email-masked]>
Date: Thu, 15 Nov 2012 12:48:08 -0500
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <mdnsext.ietf.org>

Hi Ray,

On 2012-11-01, at 04:19, Ray Bellis <[email-masked]> wrote:

> On 31 Oct 2012, at 16:27, Indtiny s <[email-masked]> wrote:
> 
>> The document is almost concluded the basic status . http://tools.ietf.org/html/draft-lynn-homenet-site-mdns-01 
>> 
>> Due to some urgent requirment I need to go with adding the basic ".site"  domain ,i.e Any DNS query for a name ending with ".site." MUST be sent to the xmDNS multicast address (FF05::FB ) and its IPv4 equivalent to 239.255.255.239.
> 
> Please note that there will very likely be a new gTLD of '.site' some time within the next 18 months.
> 
> Whilst IETF apparently has the right to reserve TLDs for 'special use', IMHO we are unable to pre-empt any of those that have been applied for in the current round of new gTLD applications.

I confess I'm not intimately familiar with the new gTLD application process, but I don't think that's quite right. There are numerous steps in the approval process by which names can be turned down on technical grounds, regardless of whether they have been formally reserved by the IETF.

For example, applications for the .WORKGROUP top-level domain are unlikely to be accepted, since they are likely to conflict with (non-standardised) operational reality. I understand that non-conflicted, qualified panellists have been assembled to make this determination.

It would be fairly straightforward to get an answer to this from ICANN if this list would like to know the possible implications of a design that made special use of .SITE. I can make introductions if that seems useful.

According to <http://gtldresult.icann.org/application-result/applicationstatus/viewstatus> five separate applications have been received for .SITE.

Joe

From: "Johnson, Neil M" <[email-masked]>
To: Matthew Gast <[email-masked]>, Dan Harkins <[email-masked]>
Date: Wed, 14 Nov 2012 17:07:23 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, Tom Pusateri <[email-masked]>, Yi Yang <[email-masked]>
Subject: Re: [mdnsext] Forwarding link-local IP multicast

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

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

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

>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
>
>
>On 11/9/12 10:07 AM, "Johnson, Neil M" <[email-masked]> wrote:
>
>>
>>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]
>>
>>
>>
>>
>>
>>
>>On 11/9/12 11:48 AM, "Matthew Gast" <[email-masked]> wrote:
>>
>>>On 11/8/12 6:10 AM, "Dan Harkins" <[email-masked]> wrote:
>>>
>>>>>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.
>>>>
>>>>  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, 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
>>>
>>>_______________________________________________
>>>mdnsext mailing list
>>>[email-masked]
>>>https://www.ietf.org/mailman/listinfo/mdnsext
>>
>>_______________________________________________
>>mdnsext mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/mdnsext
>

From: Stuart Cheshire <[email-masked]>
Date: Tue, 13 Nov 2012 21:28:33 -0800
To: Indtiny s <[email-masked]>
Subject: Re: [mdnsext] shift from mdns to xmdns

On 13 Nov 2012, at 9:43, Indtiny s wrote:

> Hi,
> 
> Basically I am trying to bridge the gap between mdns and xmdns on mdnsrespondr from apple , after going through the few document 
>  I got the the below things , 
> 1. Change the mulitcast address from 224.0.0.251 to 224.0.0.x as per the some RFC 
> 2. And Hop Limit/TTL to supporting RFC  values 
> 3. Change the local to site when supporting site TLD 
> 
> If I think in the view of a device which register/ browse the service on site . are the above steps enough or do I need consider still to support xmdns ..?

The point of this mailing list is to work out the best solution for larger-area service discovery.

Merely changing the multicast address to a larger scope may not be the best answer. Multicast is good for small networks with no infrastructure. Just making the multicast go further works in some sense, but at a cost that is unacceptable on most large networks.

Hence the need to work out a solution that provides the desired results, but without an unacceptable traffic level.

Stuart Cheshire

Date: Tue, 13 Nov 2012 12:43:18 -0500
From: Indtiny s <[email-masked]>
To: "<[email-masked]>" <[email-masked]>
Subject: [mdnsext] shift from mdns to xmdns

--e89a8fb201ca14dae904ce63f4f0
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Basically I am trying to bridge the gap between mdns and xmdns on
mdnsrespondr from apple , after going through the few document
 I got the the below things ,
1. Change the mulitcast address from 224.0.0.251 to 224.0.0.x as per the
some RFC
2. And Hop Limit/TTL to supporting RFC  values
3. Change the local to site when supporting site TLD

If I think in the view of a device which register/ browse the service on
site . are the above steps enough or do I need consider still to support
xmdns ..?

Rgds
Indra

--e89a8fb201ca14dae904ce63f4f0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>Basically I am trying to bridge the gap between mdns and xmdns on mdnsrespondr from apple , after going through the few document </div><div> I got the the below things , </div><div>1. Change the mulitcast address from 224.0.0.251 to 224.0.0.x as per the some RFC </div>
<div>2. And Hop Limit/TTL to supporting RFC  values </div><div>3. Change the local to site when supporting site TLD </div><div><br></div><div>If I think in the view of a device which register/ browse the service on site . are the above steps enough or do I need consider still to support xmdns ..?</div>
<div><br></div><div>Rgds</div><div>Indra </div>

--e89a8fb201ca14dae904ce63f4f0--

Date: Tue, 13 Nov 2012 09:43:51 +0000
From: Adam Burns <[email-masked]>
Organization: free2air limited
To: Evan Hunt <[email-masked]>
Cc: [email-masked], Andrew Sullivan <[email-masked]>
Subject: Re: [mdnsext] mDNS relay agent idea

> put an agent at the link boundary that can take service information
> from one side and retransmit it to another

If I am not mistaken, avahi already does this.

> just as DHCP is link-local but can be relayed across links

I get what you're saying but DHCP is broadcast, mDNS is multicast.

On 12/11/2012 21:20, Evan Hunt wrote:
> On Mon, Nov 12, 2012 at 03:18:17PM -0500, Andrew Sullivan wrote:
>> On Fri, Nov 09, 2012 at 09:46:50PM +0100, Eelco Chaudron wrote:
>>> Inline with the other emails send around, I would suggest using
>>> something similar to the bootp relay approach.
>>
>> This assumes (as have several other messages) that "extend mDNS beyond
>> the local link" is the goal.  Given the features we want to suppport, it
>> is very far from clear to me that that is the right goal.
> 
> Not exactly; AIUI the suggestion here is to keep mDNS itself link-local,
> but put an agent at the link boundary that can take (some configurable
> subset of?) service information from one side and retransmit it to another,
> just as DHCP is link-local but can be relayed across links.  I'm not sure
> this requires any modification to mDNS at all.  It may be a minimally-
> invasive way to meet the service-discovery requirements of EDUCAUSE etc,
> if it scales well enough on large/complex networks.
> 

From: Michael Richardson <[email-masked]>
To: [email-masked]
Comments: In-reply-to Ron J <[email-masked]> message dated "Mon, 12 Nov 2012 16:50:50 -0500."
Date: Mon, 12 Nov 2012 18:51:49 -0500
Sender: [email-masked]
Cc: Ron J <[email-masked]>, Andrew Sullivan <[email-masked]>
Subject: Re: [mdnsext] mDNS relay agent idea

--=-=-Content-Transfer-Encoding: quoted-printable

>>>>> "Ron" == Ron J <[email-masked]> writes:
    Ron> Unless there was a way to use the beam forming information from
    Ron> the 802.11ac specification, are there even protocol changes
    Ron> that would allow Bonjour to work as a user would expect in a
    Ron> University environment? I think Enterprise users would be
    Ron> thrilled, where the threat of being punished is enough to stop
    Ron> someone from printing 100 pages of black just to waste ink. 

Most universities that I've visited have locks on the printers,
such that you have to pay for the paper/printing before the print server
releases the job from the print queue.

So, I'm not really sure that *that* issue is as big a deal as you think.

    Ron> Once there is a standard on how the mDNS packets should route
    Ron> across subnets, what next? We still wouldn't be able to use
    Ron> something like that in a classroom for AppleTV without the
    Ron> potential chaos of having a hundred students highjack an
    Ron> AirPlay Mirroring session. It only takes 1 incident of the
    Ron> honor system going wrong for the system to be in serious
    Ron> jeopardy, administratively. 

AirPlay either has user authentication, or it doesn't.
Finding the TV or not doesn't change that.
 
-- 
Michael Richardson
-on the road-

--=-=-Content-Type: application/pgp-signature

--=-=-=--

From: Michael Richardson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Comments: In-reply-to "Dan Harkins" <[email-masked]> message dated "Mon, 12 Nov 2012 10:12:05 -0800."
Date: Mon, 12 Nov 2012 18:47:21 -0500
Sender: [email-masked]
Cc: Dan Harkins <[email-masked]>
Subject: Re: [mdnsext] mDNS relay agent idea

--=-=-Content-Transfer-Encoding: quoted-printable

>>>>> "Dan" == Dan Harkins <[email-masked]> writes:
    >> 
    >> In addition to caching the service discovery, do any of the various
    >> products also provide proxying of the service itself, and/or providing
    >> additional access control?

    Dan> I'm unaware of a product that proxies the service itself but I
    Dan> know that our (Aruba's) product provides additional access
    Dan> control based on the (authenticated) identity of the discoverer
    Dan> and the access rule for the device he or she is trying to discover.

I'm trying to understand how the mdns proxy authenticates the user.
Does this also mean that if my host already knows about yonder printer,
that my host could bypass the security of the proxy?

-- 
Michael Richardson
-on the road-

--=-=-Content-Type: application/pgp-signature

--=-=-=--

From: "Johnson, Neil M" <[email-masked]>
To: Ron J <[email-masked]>
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] mDNS relay agent idea

No, I don't believe so, the links you mentioned just allow browsing static
DNS-SD entries. There is no authentication involved.

One of the problems with static entries is there is a lot of additional
embedded dynamic data in the mDNS records that make it impossible to keep
the static DNS-SD records up-to-date.

-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]

On 11/12/12 4:21 PM, "Ron J" <[email-masked]> wrote:

>If i'm not mistaken, this mixing already is supported by mDNS isn't it?
>
>http://www.dns-sd.org/ServerStaticSetup.html
>http://www.dns-sd.org/ClientBrowseOnly.html
>
>- Ron J
>NCSU, OIT ClassTech
>
>
>On Nov 12, 2012, at 5:16 PM, "Johnson, Neil M" <[email-masked]>
>wrote:
>
>> 
>> I don't think we should be mixing AAA and service discovery at the
>>network
>> level.  It should be up to the device/service to authenticate users,
>>check
>> their authorization, and keep an audit trail.
>> 
>> As for locating services, some sort of flexible hierarchal name space
>> should suffice (like DNS). Say  "printer-1 in
>>room333.building.uiowa.edu"
>> would suffice. Users should be able to search the name space (i.e.
>>"search
>> for all the printers in building X").
>> 
>> -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]
>> 
>> 
>> 
>> 
>> 
>> 
>> On 11/12/12 3:50 PM, "Ron J" <[email-masked]> wrote:
>> 
>>> I agree Andrew. While that is the goal for some things, I don't think
>>> merely extending mDNS in the ways currently discussed will serve all
>>>the
>>> concerns of the Educause members, but should thrill other Enterprise
>>> users.
>>> 
>>> It's easy enough to tweak routers currently to broadcast mDNS across
>>> different subnets (lots of companies are doing this). The bigger
>>>problem,
>>> as far as universities are concerned, seems to be user authentication
>>> (which the Aruba guy mentioned they have a solution for) and also
>>>binding
>>> a user's physical location to services physically near them (what
>>>Bonjour
>>> was designed to do in a home environment).
>>> 
>>> It seems like for mDNS to work as a University user might expect, you'd
>>> have to know 1) physically where the user is 2) require a user to
>>>specify
>>> where they are and then be able to authenticate either piece of
>>> information.
>>> 
>>> Unless there was a way to use the beam forming information from the
>>> 802.11ac specification, are there even protocol changes that would
>>>allow
>>> Bonjour to work as a user would expect in a University environment? I
>>> think Enterprise users would be thrilled, where the threat of being
>>> punished is enough to stop someone from printing 100 pages of black
>>>just
>>> to waste ink.
>>> 
>>> Once there is a standard on how the mDNS packets should route across
>>> subnets, what next? We still wouldn't be able to use something like
>>>that
>>> in a classroom for AppleTV without the potential chaos of having a
>>> hundred students highjack an AirPlay Mirroring session. It only takes 1
>>> incident of the honor system going wrong for the system to be in
>>>serious
>>> jeopardy, administratively.
>>> 
>>> An ideal workflow for a university is this:
>>> 1) A student/teacher wants to use a printer
>>> 2) They log into a website, authenticate themselves, pick their
>>>printer,
>>> and it's broadcast to them, and only them
>>> OR
>>> 2) Based on a RADIUS, etc., authentication, the system knows who they
>>> are; the user logs into a web interface that says exactly where they
>>>are,
>>> the system sanity checks this against which AP/LAN port they are on,
>>>and
>>> sends the services (registered with the network administrators) in
>>>their
>>> area directly to them
>>> 3) The student/teacher happily use their device
>>> 
>>> For either of these scenarios to work (outside of the other
>>>server/router
>>> configurations required), mDNSResponder would need to have a mechanism
>>>to
>>> handle service registrations NOT sent via a broadcast (so that a server
>>> could tell a specific client where a service lives) and authenticate
>>> these service registrations (so that a malicious application can't
>>> register bogus services on a P2P basis).
>>> 
>>> OR
>>> 
>>> Another option that wouldn't require network administrators to manually
>>> approve devices to is specify a PhysicalLocation attribute as part of
>>>the
>>> TXT record. The routers forward mDNS broadcasts that have the
>>> PhysicalLocation tags as DNS SRV records. When a client device connects
>>> to a network, it gets a PhysicalLocation tag pushed to it from the
>>> router, configured by the Administrator. When mDNS queries for
>>>services,
>>> if a PhysicalLocation is configured (which it wouldn't be in a home
>>> environment), the routers then query the DNS server for the services,
>>> then only returns what matches the client's PhysicalLocation. It would
>>> also be critical for a client to manually be able to set its
>>> PhysicalLocation, it would also be possible for a client to be
>>>associated
>>> with multiple physical locations (it could be determined by
>>>Administrator
>>> policy what to do in these situations).
>>> 
>>> 
>>> (if i've mixed up my networking terminology, please excuse me -- i'm
>>>not
>>> quite a network guru, hopefully you understand what i mean)
>>> 
>>> - Ron J
>>> NCSU, OIT ClassTech
>>> 
>>> 
>>> On Nov 12, 2012, at 3:18 PM, Andrew Sullivan <[email-masked]>
>>> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> On Fri, Nov 09, 2012 at 09:46:50PM +0100, Eelco Chaudron wrote:
>>>>> Inline with the other emails send around, I would suggest using
>>>>> something similar to the bootp relay approach.
>>>> 
>>>> This assumes (as have several other messages) that "extend mDNS beyond
>>>> the local link" is the goal.  Given the features we want to suppport,
>>>> it is very far from clear to me that that is the right goal.
>>>> 
>>>> Best,
>>>> 
>>>> A
>>>> 
>>>> 
>>>> -- 
>>>> Andrew Sullivan
>>>> [email-masked]
>>>> _______________________________________________
>>>> mdnsext mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mdnsext
>>> 
>>> _______________________________________________
>>> mdnsext mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mdnsext
>> 
>

From: Ron J <[email-masked]>
Date: Mon, 12 Nov 2012 17:21:28 -0500
To: "Johnson, Neil M" <[email-masked]>
Cc: [email-masked]
Subject: Re: [mdnsext] mDNS relay agent idea

If i'm not mistaken, this mixing already is supported by mDNS isn't it?

http://www.dns-sd.org/ServerStaticSetup.html
http://www.dns-sd.org/ClientBrowseOnly.html

- Ron J
NCSU, OIT ClassTech

On Nov 12, 2012, at 5:16 PM, "Johnson, Neil M" <[email-masked]> wrote:

> 
> I don't think we should be mixing AAA and service discovery at the network
> level.  It should be up to the device/service to authenticate users, check
> their authorization, and keep an audit trail.
> 
> As for locating services, some sort of flexible hierarchal name space
> should suffice (like DNS). Say  "printer-1 in room333.building.uiowa.edu"
> would suffice. Users should be able to search the name space (i.e. "search
> for all the printers in building X").
> 
> -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]
> 
> 
> 
> 
> 
> 
> On 11/12/12 3:50 PM, "Ron J" <[email-masked]> wrote:
> 
>> I agree Andrew. While that is the goal for some things, I don't think
>> merely extending mDNS in the ways currently discussed will serve all the
>> concerns of the Educause members, but should thrill other Enterprise
>> users.
>> 
>> It's easy enough to tweak routers currently to broadcast mDNS across
>> different subnets (lots of companies are doing this). The bigger problem,
>> as far as universities are concerned, seems to be user authentication
>> (which the Aruba guy mentioned they have a solution for) and also binding
>> a user's physical location to services physically near them (what Bonjour
>> was designed to do in a home environment).
>> 
>> It seems like for mDNS to work as a University user might expect, you'd
>> have to know 1) physically where the user is 2) require a user to specify
>> where they are and then be able to authenticate either piece of
>> information.
>> 
>> Unless there was a way to use the beam forming information from the
>> 802.11ac specification, are there even protocol changes that would allow
>> Bonjour to work as a user would expect in a University environment? I
>> think Enterprise users would be thrilled, where the threat of being
>> punished is enough to stop someone from printing 100 pages of black just
>> to waste ink.
>> 
>> Once there is a standard on how the mDNS packets should route across
>> subnets, what next? We still wouldn't be able to use something like that
>> in a classroom for AppleTV without the potential chaos of having a
>> hundred students highjack an AirPlay Mirroring session. It only takes 1
>> incident of the honor system going wrong for the system to be in serious
>> jeopardy, administratively.
>> 
>> An ideal workflow for a university is this:
>> 1) A student/teacher wants to use a printer
>> 2) They log into a website, authenticate themselves, pick their printer,
>> and it's broadcast to them, and only them
>> OR
>> 2) Based on a RADIUS, etc., authentication, the system knows who they
>> are; the user logs into a web interface that says exactly where they are,
>> the system sanity checks this against which AP/LAN port they are on, and
>> sends the services (registered with the network administrators) in their
>> area directly to them
>> 3) The student/teacher happily use their device
>> 
>> For either of these scenarios to work (outside of the other server/router
>> configurations required), mDNSResponder would need to have a mechanism to
>> handle service registrations NOT sent via a broadcast (so that a server
>> could tell a specific client where a service lives) and authenticate
>> these service registrations (so that a malicious application can't
>> register bogus services on a P2P basis).
>> 
>> OR
>> 
>> Another option that wouldn't require network administrators to manually
>> approve devices to is specify a PhysicalLocation attribute as part of the
>> TXT record. The routers forward mDNS broadcasts that have the
>> PhysicalLocation tags as DNS SRV records. When a client device connects
>> to a network, it gets a PhysicalLocation tag pushed to it from the
>> router, configured by the Administrator. When mDNS queries for services,
>> if a PhysicalLocation is configured (which it wouldn't be in a home
>> environment), the routers then query the DNS server for the services,
>> then only returns what matches the client's PhysicalLocation. It would
>> also be critical for a client to manually be able to set its
>> PhysicalLocation, it would also be possible for a client to be associated
>> with multiple physical locations (it could be determined by Administrator
>> policy what to do in these situations).
>> 
>> 
>> (if i've mixed up my networking terminology, please excuse me -- i'm not
>> quite a network guru, hopefully you understand what i mean)
>> 
>> - Ron J
>> NCSU, OIT ClassTech
>> 
>> 
>> On Nov 12, 2012, at 3:18 PM, Andrew Sullivan <[email-masked]>
>> wrote:
>> 
>>> Hi,
>>> 
>>> On Fri, Nov 09, 2012 at 09:46:50PM +0100, Eelco Chaudron wrote:
>>>> Inline with the other emails send around, I would suggest using
>>>> something similar to the bootp relay approach.
>>> 
>>> This assumes (as have several other messages) that "extend mDNS beyond
>>> the local link" is the goal.  Given the features we want to suppport,
>>> it is very far from clear to me that that is the right goal.
>>> 
>>> Best,
>>> 
>>> A
>>> 
>>> 
>>> -- 
>>> Andrew Sullivan
>>> [email-masked]
>>> _______________________________________________
>>> mdnsext mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mdnsext
>> 
>> _______________________________________________
>> mdnsext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mdnsext
> 

From: "Johnson, Neil M" <[email-masked]>
To: Ron J <[email-masked]>, Andrew Sullivan <[email-masked]>
Date: Mon, 12 Nov 2012 22:16:56 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] mDNS relay agent idea

I don't think we should be mixing AAA and service discovery at the network
level.  It should be up to the device/service to authenticate users, check
their authorization, and keep an audit trail.

As for locating services, some sort of flexible hierarchal name space
should suffice (like DNS). Say  "printer-1 in room333.building.uiowa.edu"
would suffice. Users should be able to search the name space (i.e. "search
for all the printers in building X").

-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]

On 11/12/12 3:50 PM, "Ron J" <[email-masked]> wrote:

>I agree Andrew. While that is the goal for some things, I don't think
>merely extending mDNS in the ways currently discussed will serve all the
>concerns of the Educause members, but should thrill other Enterprise
>users.
>
>It's easy enough to tweak routers currently to broadcast mDNS across
>different subnets (lots of companies are doing this). The bigger problem,
>as far as universities are concerned, seems to be user authentication
>(which the Aruba guy mentioned they have a solution for) and also binding
>a user's physical location to services physically near them (what Bonjour
>was designed to do in a home environment).
>
>It seems like for mDNS to work as a University user might expect, you'd
>have to know 1) physically where the user is 2) require a user to specify
>where they are and then be able to authenticate either piece of
>information.
>
>Unless there was a way to use the beam forming information from the
>802.11ac specification, are there even protocol changes that would allow
>Bonjour to work as a user would expect in a University environment? I
>think Enterprise users would be thrilled, where the threat of being
>punished is enough to stop someone from printing 100 pages of black just
>to waste ink.
>
>Once there is a standard on how the mDNS packets should route across
>subnets, what next? We still wouldn't be able to use something like that
>in a classroom for AppleTV without the potential chaos of having a
>hundred students highjack an AirPlay Mirroring session. It only takes 1
>incident of the honor system going wrong for the system to be in serious
>jeopardy, administratively.
>
>An ideal workflow for a university is this:
>1) A student/teacher wants to use a printer
>2) They log into a website, authenticate themselves, pick their printer,
>and it's broadcast to them, and only them
>OR
>2) Based on a RADIUS, etc., authentication, the system knows who they
>are; the user logs into a web interface that says exactly where they are,
>the system sanity checks this against which AP/LAN port they are on, and
>sends the services (registered with the network administrators) in their
>area directly to them
>3) The student/teacher happily use their device
>
>For either of these scenarios to work (outside of the other server/router
>configurations required), mDNSResponder would need to have a mechanism to
>handle service registrations NOT sent via a broadcast (so that a server
>could tell a specific client where a service lives) and authenticate
>these service registrations (so that a malicious application can't
>register bogus services on a P2P basis).
>
>OR
>
>Another option that wouldn't require network administrators to manually
>approve devices to is specify a PhysicalLocation attribute as part of the
>TXT record. The routers forward mDNS broadcasts that have the
>PhysicalLocation tags as DNS SRV records. When a client device connects
>to a network, it gets a PhysicalLocation tag pushed to it from the
>router, configured by the Administrator. When mDNS queries for services,
>if a PhysicalLocation is configured (which it wouldn't be in a home
>environment), the routers then query the DNS server for the services,
>then only returns what matches the client's PhysicalLocation. It would
>also be critical for a client to manually be able to set its
>PhysicalLocation, it would also be possible for a client to be associated
>with multiple physical locations (it could be determined by Administrator
>policy what to do in these situations).
>
>
>(if i've mixed up my networking terminology, please excuse me -- i'm not
>quite a network guru, hopefully you understand what i mean)
>
>- Ron J
>NCSU, OIT ClassTech
>
>
>On Nov 12, 2012, at 3:18 PM, Andrew Sullivan <[email-masked]>
>wrote:
>
>> Hi,
>> 
>> On Fri, Nov 09, 2012 at 09:46:50PM +0100, Eelco Chaudron wrote:
>>> Inline with the other emails send around, I would suggest using
>>>something similar to the bootp relay approach.
>> 
>> This assumes (as have several other messages) that "extend mDNS beyond
>> the local link" is the goal.  Given the features we want to suppport,
>> it is very far from clear to me that that is the right goal.
>> 
>> Best,
>> 
>> A
>> 
>> 
>> -- 
>> Andrew Sullivan
>> [email-masked]
>> _______________________________________________
>> mdnsext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mdnsext
>
>_______________________________________________
>mdnsext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mdnsext

From: Ron J <[email-masked]>
Date: Mon, 12 Nov 2012 16:50:50 -0500
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [mdnsext] mDNS relay agent idea

I agree Andrew. While that is the goal for some things, I don't think merely extending mDNS in the ways currently discussed will serve all the concerns of the Educause members, but should thrill other Enterprise users.

It's easy enough to tweak routers currently to broadcast mDNS across different subnets (lots of companies are doing this). The bigger problem, as far as universities are concerned, seems to be user authentication (which the Aruba guy mentioned they have a solution for) and also binding a user's physical location to services physically near them (what Bonjour was designed to do in a home environment).

It seems like for mDNS to work as a University user might expect, you'd have to know 1) physically where the user is 2) require a user to specify where they are and then be able to authenticate either piece of information.

Unless there was a way to use the beam forming information from the 802.11ac specification, are there even protocol changes that would allow Bonjour to work as a user would expect in a University environment? I think Enterprise users would be thrilled, where the threat of being punished is enough to stop someone from printing 100 pages of black just to waste ink.

Once there is a standard on how the mDNS packets should route across subnets, what next? We still wouldn't be able to use something like that in a classroom for AppleTV without the potential chaos of having a hundred students highjack an AirPlay Mirroring session. It only takes 1 incident of the honor system going wrong for the system to be in serious jeopardy, administratively.

An ideal workflow for a university is this:
1) A student/teacher wants to use a printer
2) They log into a website, authenticate themselves, pick their printer, and it's broadcast to them, and only them
OR
2) Based on a RADIUS, etc., authentication, the system knows who they are; the user logs into a web interface that says exactly where they are, the system sanity checks this against which AP/LAN port they are on, and sends the services (registered with the network administrators) in their area directly to them
3) The student/teacher happily use their device

For either of these scenarios to work (outside of the other server/router configurations required), mDNSResponder would need to have a mechanism to handle service registrations NOT sent via a broadcast (so that a server could tell a specific client where a service lives) and authenticate these service registrations (so that a malicious application can't register bogus services on a P2P basis).

OR

Another option that wouldn't require network administrators to manually approve devices to is specify a PhysicalLocation attribute as part of the TXT record. The routers forward mDNS broadcasts that have the PhysicalLocation tags as DNS SRV records. When a client device connects to a network, it gets a PhysicalLocation tag pushed to it from the router, configured by the Administrator. When mDNS queries for services, if a PhysicalLocation is configured (which it wouldn't be in a home environment), the routers then query the DNS server for the services, then only returns what matches the client's PhysicalLocation. It would also be critical for a client to manually be able to set its PhysicalLocation, it would also be possible for a client to be associated with multiple physical locations (it could be determined by Administrator policy what to do in these situations).

(if i've mixed up my networking terminology, please excuse me -- i'm not quite a network guru, hopefully you understand what i mean)

- Ron J
NCSU, OIT ClassTech

On Nov 12, 2012, at 3:18 PM, Andrew Sullivan <[email-masked]> wrote:

> Hi,
> 
> On Fri, Nov 09, 2012 at 09:46:50PM +0100, Eelco Chaudron wrote:
>> Inline with the other emails send around, I would suggest using something similar to the bootp relay approach.
> 
> This assumes (as have several other messages) that "extend mDNS beyond
> the local link" is the goal.  Given the features we want to suppport,
> it is very far from clear to me that that is the right goal.
> 
> Best,
> 
> A
> 
> 
> -- 
> Andrew Sullivan
> [email-masked]
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext

Date: Mon, 12 Nov 2012 21:20:17 +0000
From: Evan Hunt <[email-masked]>
To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
Subject: Re: [mdnsext] mDNS relay agent idea

On Mon, Nov 12, 2012 at 03:18:17PM -0500, Andrew Sullivan wrote:
> On Fri, Nov 09, 2012 at 09:46:50PM +0100, Eelco Chaudron wrote:
> > Inline with the other emails send around, I would suggest using
> > something similar to the bootp relay approach.
> 
> This assumes (as have several other messages) that "extend mDNS beyond
> the local link" is the goal.  Given the features we want to suppport, it
> is very far from clear to me that that is the right goal.

Not exactly; AIUI the suggestion here is to keep mDNS itself link-local,
but put an agent at the link boundary that can take (some configurable
subset of?) service information from one side and retransmit it to another,
just as DHCP is link-local but can be relayed across links.  I'm not sure
this requires any modification to mDNS at all.  It may be a minimally-
invasive way to meet the service-discovery requirements of EDUCAUSE etc,
if it scales well enough on large/complex networks.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

Date: Mon, 12 Nov 2012 15:18:17 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [mdnsext] mDNS relay agent idea

Hi,

On Fri, Nov 09, 2012 at 09:46:50PM +0100, Eelco Chaudron wrote:
> Inline with the other emails send around, I would suggest using something similar to the bootp relay approach.

This assumes (as have several other messages) that "extend mDNS beyond
the local link" is the goal.  Given the features we want to suppport,
it is very far from clear to me that that is the right goal.

Best,

A

-- 
Andrew Sullivan
[email-masked]

Date: Mon, 12 Nov 2012 15:07:52 -0500
From: Brian Dickson <[email-masked]>
To: Ran Atkinson <[email-masked]>
Cc: [email-masked]
Subject: Re: [mdnsext] Architecture for multi-hop Service Discovery

--047d7b621ede341d7504ce51db8a
Content-Type: text/plain; charset=ISO-8859-1

Useful place for code spelunking on AppleTalk (and very good documentation
for the code and overall technical design and terminology), is:
http://netatalk.sourceforge.net/

Specifically, look at the stuff related to atalkd (and friends) for actual
AppleTalk daemon and router stuff, including printer access protocol daemon
(papd).

Used this a long time ago, extensively.

Yes, avoiding reinventing the wheel is highly recommended.

Brian

On Sat, Nov 10, 2012 at 8:40 AM, Ran Atkinson <[email-masked]>wrote:

>
> Operational experience with Service Discovery based on
> the (old) AppleTalk protocols was largely positive.
>
> Back when I worked in a research lab, that same
> AppleTalk Service Discovery scheme worked well,
> for various services on a campus-wide scope,
> not limited to services on the local link.
>
> If I understand the history here correctly, part of the
> reason Stuart worked on both mDNS and DNS-SD was to
> replicate that (missing) capability in IP networks.
>
> So it would be useful and productive if someone
> knowledgeable (probably someone at Apple then or now)
> could explain the architectural approach that AppleTalk
> Service Discovery used.
>
> Once that description is available to folks here, perhaps
> we might think about how to replicate that concept and
> architectural approach.
>
> I think wheels are great, but I'd really prefer that
> we avoid re-inventing the wheel if we can use an existing
> design that would suit the current needs.
>
> Thanks,
>
> Ran
>
>
>
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext
>

--047d7b621ede341d7504ce51db8a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Useful place for code spelunking on AppleTalk (and very good documentation for the code and overall technical design and terminology), is:<div><a href="http://netatalk.sourceforge.net/">http://netatalk.sourceforge.net/</a></div>
<div><br></div><div>Specifically, look at the stuff related to atalkd (and friends) for actual AppleTalk daemon and router stuff, including printer access protocol daemon (papd).</div><div><br></div><div>Used this a long time ago, extensively.</div>
<div><br></div><div>Yes, avoiding reinventing the wheel is highly recommended.</div><div><br></div><div>Brian<br><br><div class="gmail_quote">On Sat, Nov 10, 2012 at 8:40 AM, Ran Atkinson <span dir="ltr">&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Operational experience with Service Discovery based on<br>
the (old) AppleTalk protocols was largely positive.<br>
<br>
Back when I worked in a research lab, that same<br>
AppleTalk Service Discovery scheme worked well,<br>
for various services on a campus-wide scope,<br>
not limited to services on the local link.<br>
<br>
If I understand the history here correctly, part of the<br>
reason Stuart worked on both mDNS and DNS-SD was to<br>
replicate that (missing) capability in IP networks.<br>
<br>
So it would be useful and productive if someone<br>
knowledgeable (probably someone at Apple then or now)<br>
could explain the architectural approach that AppleTalk<br>
Service Discovery used.<br>
<br>
Once that description is available to folks here, perhaps<br>
we might think about how to replicate that concept and<br>
architectural approach.<br>
<br>
I think wheels are great, but I&#39;d really prefer that<br>
we avoid re-inventing the wheel if we can use an existing<br>
design that would suit the current needs.<br>
<br>
Thanks,<br>
<br>
Ran<br>
<br>
<br>
<br>
_______________________________________________<br>
mdnsext mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/mdnsext" target="_blank">https://www.ietf.org/mailman/listinfo/mdnsext</a><br>
</blockquote></div><br></div>

--047d7b621ede341d7504ce51db8a--

From: Tom Pusateri <[email-masked]>
Date: Mon, 12 Nov 2012 14:59:37 -0500
To: "Johnson, Neil M" <[email-masked]>
Cc: Sebastian Hagedorn <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] Forwarding link-local IP multicast

On Nov 12, 2012, at 1:37 PM, "Johnson, Neil M" <[email-masked]> wrote:

> 
> 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
> 

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]>
To: Sebastian Hagedorn <[email-masked]>
Date: Mon, 12 Nov 2012 18:37:23 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] Forwarding link-local IP multicast

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

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

On 11/10/12 3:10 AM, "Sebastian Hagedorn" <[email-masked]> wrote:

>> 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.
>
>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

Date: Mon, 12 Nov 2012 10:12:05 -0800 (PST)
From: "Dan Harkins" <[email-masked]>
To: "Michael Richardson" <[email-masked]>
Importance: Normal
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] mDNS relay agent idea

  Hi Michael,

On Mon, November 12, 2012 9:57 am, Michael Richardson wrote:
>
> In addition to caching the service discovery, do any of the various
> products also provide proxying of the service itself, and/or providing
> additional access control?

  I'm unaware of a product that proxies the service itself but I
know that our (Aruba's) product provides additional access
control based on the (authenticated) identity of the discoverer
and the access rule for the device he or she is trying to discover.

  Dan.

> I'm thinking specifically of a case where the math department on
> floor 4 want to print to the nice colour printer that belongs to the
> history department on the same floor.  But, not only is service
> discovery interrupted by routers/NAT/firewall, but so actually is
> movement of packets.  (Of course, IPv6 changes this... a bit)
>
> --
> Michael Richardson
> -on the road-
>
>
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext
>

From: Michael Richardson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Comments: In-reply-to Matthew Gast <[email-masked]> message dated "Sat, 10 Nov 2012 03:46:11 +0000."
Date: Mon, 12 Nov 2012 12:57:50 -0500
Sender: [email-masked]
Subject: Re: [mdnsext] mDNS relay agent idea

--=-=-Content-Transfer-Encoding: quoted-printable

In addition to caching the service discovery, do any of the various
products also provide proxying of the service itself, and/or providing
additional access control?

I'm thinking specifically of a case where the math department on
floor 4 want to print to the nice colour printer that belongs to the
history department on the same floor.  But, not only is service
discovery interrupted by routers/NAT/firewall, but so actually is
movement of packets.  (Of course, IPv6 changes this... a bit)

-- 
Michael Richardson
-on the road-

--=-=-Content-Type: application/pgp-signature

--=-=-=--

From: Eelco Chaudron <[email-masked]>
To: Matthew Gast <[email-masked]>
Date: Mon, 12 Nov 2012 13:26:46 +0100
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] mDNS relay agent idea

Date: Mon, 12 Nov 2012 12:06:09 +0100
From: Sebastian Hagedorn <[email-masked]>
To: Ran Atkinson <[email-masked]>
Cc: [email-masked]
Subject: Re: [mdnsext] Architecture for multi-hop Service Discovery

--=====7E449C46788008DA5B49=====
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

--On 10. November 2012 08:40:03 -0500 Ran Atkinson <[email-masked]> 
wrote:

> Operational experience with Service Discovery based on
> the (old) AppleTalk protocols was largely positive.
>
> Back when I worked in a research lab, that same
> AppleTalk Service Discovery scheme worked well,
> for various services on a campus-wide scope,
> not limited to services on the local link.

I'm not an expert on AppleTalk, because back in the day I was mainly a user 
and only just started working as a network administrator, but I think that 
AppleTalk only worked so well because the world was a different place. In 
our campus network you were able to see and print to every 
AppleTalk-enabled printer! I don't think that anybody would want that these 
days. You need administrative limits on what is visible and what is not. 
Zerconf doesn't have that so far, because it was always intended to be 
link-local, but if it is to be extended to the campus, that's definitely a 
requirement.
-- 
     .:.Sebastian Hagedorn - RZKR, Weyertal 121 (Gebäude 133), Z. 2.02.:.
.:.Universität zu Köln / Cologne University - Tel. +49-221-470-89578.:.
--=====7E449C46788008DA5B49=====
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: base64

--=====7E449C46788008DA5B49=====--

From: RJ Atkinson <[email-masked]>
Date: Sat, 10 Nov 2012 08:42:13 -0500
To: [email-masked]
Subject: [mdnsext] Goals of this WG

It seems to me that the real goal of this WG (and the
original EduCause petition) is to make Service Discovery 
work well in a multi-link campus (or other single 
administrative domain) environment.

If so, focusing on how/when/where to forward link-local
packets off-link seems like attaching the cart in front
of the horse.

Yours,

Ran

From: Ran Atkinson <[email-masked]>
Date: Sat, 10 Nov 2012 08:40:03 -0500
To: [email-masked]
Subject: [mdnsext] Architecture for multi-hop Service Discovery

Operational experience with Service Discovery based on
the (old) AppleTalk protocols was largely positive.  

Back when I worked in a research lab, that same
AppleTalk Service Discovery scheme worked well,
for various services on a campus-wide scope, 
not limited to services on the local link.

If I understand the history here correctly, part of the
reason Stuart worked on both mDNS and DNS-SD was to
replicate that (missing) capability in IP networks.

So it would be useful and productive if someone
knowledgeable (probably someone at Apple then or now)
could explain the architectural approach that AppleTalk
Service Discovery used.

Once that description is available to folks here, perhaps
we might think about how to replicate that concept and
architectural approach.

I think wheels are great, but I'd really prefer that
we avoid re-inventing the wheel if we can use an existing
design that would suit the current needs.

Thanks,

Ran

From: RJ Atkinson <[email-masked]>
Date: Sat, 10 Nov 2012 08:30:44 -0500
To: [email-masked]
Subject: [mdnsext]  Forwarding link-local IP multicast

On 6th November, Tom Pusateri wrote:
> 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.

+10

Yours,

Ran

Date: Sat, 10 Nov 2012 10:10:11 +0100
From: Sebastian Hagedorn <[email-masked]>
To: "Johnson, Neil M" <[email-masked]>
Message-Context: text-message
Cc: [email-masked]
Subject: Re: [mdnsext] Forwarding link-local IP multicast

--=====DC2DA39DDC2B408585D3=====
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; sizeu3

> 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.

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
--=====DC2DA39DDC2B408585D3=====
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: base64

--=====DC2DA39DDC2B408585D3=====--

From: Matthew Gast <[email-masked]>
To: "Johnson, Neil M" <[email-masked]>, Dan Harkins <[email-masked]>
Date: Sat, 10 Nov 2012 03:57:51 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, Tom Pusateri <[email-masked]>, Yi Yang <[email-masked]>
Subject: Re: [mdnsext] Forwarding link-local IP multicast

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

On 11/9/12 10:07 AM, "Johnson, Neil M" <[email-masked]> wrote:

>
>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]
>
>
>
>
>
>
>On 11/9/12 11:48 AM, "Matthew Gast" <[email-masked]> wrote:
>
>>On 11/8/12 6:10 AM, "Dan Harkins" <[email-masked]> wrote:
>>
>>>>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.
>>>
>>>  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, 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
>>
>>_______________________________________________
>>mdnsext mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/mdnsext
>
>_______________________________________________
>mdnsext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mdnsext

From: Matthew Gast <[email-masked]>
To: Eelco Chaudron <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 10 Nov 2012 03:46:11 +0000
Accept-Language: en-US
Subject: Re: [mdnsext] mDNS relay agent idea

Eelco,

I think many of the vendor-specific products mentioned on Tuesday do
something like kinda sorta like this, at least in terms of building a
cache of services that are specific to a link.  There needs to be a way of
building adjacencies across widely separated networks.  I don't think it's
a safe assumption that relay agents will exist on every IP subnet so there
will be a way to build a chain of relay agents across the network.  It's
possible that network administrators will want to take some services from
point A and put them at point B, and if points A & B are widely
distributed across the network, then using mDNS (link-local) adjacencies
will not share across multiple hops without configuration.  I don't think
that's a big problem since it's not hard to configure, but perhaps we
could define a well-known service to bootstrap the adjacency creation
process.

Caching services is probably not optimal, though, since services can come
and go and the DF may not get immediate updates.  Maintaining state at the
DF probably consumes some amount of network capacity; more importantly, DF
cache maintenance pinging away at the network may obstruct power-saving
operations.

In your sixth step, is the "DNS (service) query" an mDNS query or a
unicast query?  If the former, I like the implicit transformation of a
multicast query into a unicast response for wireless LAN operations, but
it may impede maintenance of link-local service lists on all other
listeners.

Matthew

On 11/9/12 12:46 PM, "Eelco Chaudron" <[email-masked]>
wrote:

>Inline with the other emails send around, I would suggest using something
>similar to the bootp relay approach.
>Where a relay agent can unicast forward the service request to other
>network segments. This should be done in such a way it will work with all
>the existing mDNS querier clients out there.
>
>The mDNS relay service can run on a switch, router, or purposely build
>device/server, as long as it has connections to multiple network segments.
>Here are some ideas that came to mind during my 8 hour flight back home:
>
>- The relay agent will advertise it¹s service on all the network segments
>connected using mDNS.
>- All the relay agents on the same segment can than form adjacencies and
>determine the designated forwarded for the segment. The agent with the
>most interfaces has the highest priority, tie breaker could be the IP
>address.
>- All relay agents in the domain can form adjacencies, and build a link
>state table, so they know all reachable segments (and their unicast DF
>address)
>- Adjacencies should allow for packet signature option (MAC), but should
>be off by default
>- The designated forwarded will build a cache of services for the segment
>it¹s the designated forwarder for (others might also do this in case of
>failure of the DF, but they should not include the entries in a response
>to avoid duplicates).
>- If a DF sees a DNS (service) query it will forward it as unicast to all
>known FRs. Who will reply on behave of the service using unicast.
>- Note for this to work the services should be reachable trough the
>routed network. This should be verified if a relay agent is answering on
>behave of a service. It does not make sense to reply with link local
>addresses.
>
>
>Note that these are all random thoughts, and I was not thinking clear,
>but it¹s a nice discussion starter to get some activity on the mailing
>list ;)
>
>
>//Eelco
>
>
>DISCLAIMER:
>This e-mail and any attachments to it may contain confidential and
>proprietary material and is solely for the use of the intended recipient.
>Any review, use, disclosure, distribution or copying of this transmittal
>is prohibited except by or on behalf of the intended recipient.  If you
>have received this transmittal in error, please notify the sender and
>destroy this e-mail and any attachments and all copies, whether
>electronic or printed.
>_______________________________________________
>mdnsext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mdnsext

From: Eelco Chaudron <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 9 Nov 2012 21:46:50 +0100
Accept-Language: en-US
acceptlanguage: en-US
Subject: [mdnsext] mDNS relay agent idea

Inline with the other emails send around, I would suggest using something similar to the bootp relay approach.
Where a relay agent can unicast forward the service request to other network segments. This should be done in such a way it will work with all the existing mDNS querier clients out there.

The mDNS relay service can run on a switch, router, or purposely build device/server, as long as it has connections to multiple network segments.
Here are some ideas that came to mind during my 8 hour flight back home:

- The relay agent will advertise it’s service on all the network segments connected using mDNS.
- All the relay agents on the same segment can than form adjacencies and determine the designated forwarded for the segment. The agent with the most interfaces has the highest priority, tie breaker could be the IP address.
- All relay agents in the domain can form adjacencies, and build a link state table, so they know all reachable segments (and their unicast DF address)
- Adjacencies should allow for packet signature option (MAC), but should be off by default
- The designated forwarded will build a cache of services for the segment it’s the designated forwarder for (others might also do this in case of failure of the DF, but they should not include the entries in a response to avoid duplicates).
- If a DF sees a DNS (service) query it will forward it as unicast to all known FRs. Who will reply on behave of the service using unicast.
- Note for this to work the services should be reachable trough the routed network. This should be verified if a relay agent is answering on behave of a service. It does not make sense to reply with link local addresses.

Note that these are all random thoughts, and I was not thinking clear, but it’s a nice discussion starter to get some activity on the mailing list ;)

//Eelco

DISCLAIMER:
This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient.  If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.

From: Alf Watt <[email-masked]>
To: Matthew Gast <[email-masked]>
Date: Fri, 9 Nov 2012 20:17:01 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] Security requirement?

Good suggestion, I used 'authoritative' to indicate that the actual advertiser or it's designated proxy could respond as long as we have a chain of trust, but it never hurts to be explicit.

Have a look at the Sleep Proxy[1] support for examples of how proxying currently works, the client adding a service to the proxy needs some way to transfer keys or a signature that indicates that it's OK with another agent on the network responding.

Best,
Alf

[1] http://stuartcheshire.org/SleepProxy/

On Nov 9, 2012, at 9:29 AM, Matthew Gast <[email-masked]>
 wrote:

> I agree with that addition, but I'd modify it slightly to say that we want
> to continue to support the proxy functionality that exists today, like:
> 
> "- ensure that service resolution is authoritative for the advertisement,
> whether it is an original or proxy advertisement"
> 
> I have no immediate idea for how to solve the proxy advertisement
> authentication problem, but I'd like to try.  Given that we're trying to
> address Wi-Fi problems, having a way to advertise services to clients that
> have just woken up from a sleep seems like a good idea.
> 
> Matthew
> 
> 
> On 11/7/12 5:21 PM, "Alf Watt" <[email-masked]> wrote:
> 
>> I'd add:
>> 
>> - ensure that service resolution is authoritative for the advertisement
>> 
>> i.e. prevent a third party from replying with it's own ip & port number
>> to redirect a client for nefarious purposes.
>> 
>> Solving this for both mDNS and DNS-SD would be a good thing.
>> 
>> http://www.gnucitizen.org/blog/name-mdns-poisoning-attacks-inside-the-lan/
>> 
>> Best,
>> Alf
>> 
>> On Nov 7, 2012, at 1:59 AM, Matthew Gast <[email-masked]> wrote:
>> 
>>> Another item that emerged from today's BoF discussion was a somewhat
>>> nebulous desire for security.  It's not really in the current draft of
>>> the
>>> requirements document, so I'll start off with what I heard today, which
>>> is
>>> that service advertisements shouldn't just be trusted, and that both the
>>> service transmission and service reception should be validated.  If I
>>> were
>>> to put that into the current document, I'd propose text like this:
>>> 
>>> "REQ06: Security.
>>> - Enable validation of authenticity of service advertisements
>>>  - Users and devices are only authorized to advertise certain services
>>> - Service advertisements are only delivered to authorized recipients"
>>> 
>>> Matthew
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> mdnsext mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mdnsext
>>> 
>> 
> 
> 

From: Ray Bellis <[email-masked]>
To: "<[email-masked]>" <[email-masked]>
Date: Fri, 9 Nov 2012 20:00:00 +0000
Accept-Language: en-GB, en-US
Subject: [mdnsext] MDNSEXT BoF in Ars Technica

<http://arstechnica.com/apple/2012/11/apple-working-to-make-bonjour-compatible-with-enterprise-networks/>

Ray

From: "Johnson, Neil M" <[email-masked]>
To: Matthew Gast <[email-masked]>, Dan Harkins <[email-masked]>
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, Tom Pusateri <[email-masked]>, Yi Yang <[email-masked]>
Subject: Re: [mdnsext] Forwarding link-local IP multicast

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]

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

>On 11/8/12 6:10 AM, "Dan Harkins" <[email-masked]> wrote:
>
>>>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.
>>
>>  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, 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
>
>_______________________________________________
>mdnsext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mdnsext

From: Matthew Gast <[email-masked]>
To: Dan Harkins <[email-masked]>
Date: Fri, 9 Nov 2012 17:48:00 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, Tom Pusateri <[email-masked]>, Yi Yang <[email-masked]>
Subject: Re: [mdnsext] Forwarding link-local IP multicast

On 11/8/12 6:10 AM, "Dan Harkins" <[email-masked]> wrote:

>>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.
>
>  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, 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: Matthew Gast <[email-masked]>
To: Alf Watt <[email-masked]>, "[email-masked]" <[email-masked]>
Accept-Language: en-US
Subject: Re: [mdnsext] Security requirement?

I agree with that addition, but I'd modify it slightly to say that we want
to continue to support the proxy functionality that exists today, like:

"- ensure that service resolution is authoritative for the advertisement,
whether it is an original or proxy advertisement"

I have no immediate idea for how to solve the proxy advertisement
authentication problem, but I'd like to try.  Given that we're trying to
address Wi-Fi problems, having a way to advertise services to clients that
have just woken up from a sleep seems like a good idea.

Matthew

On 11/7/12 5:21 PM, "Alf Watt" <[email-masked]> wrote:

>I'd add:
>
>- ensure that service resolution is authoritative for the advertisement
>
>i.e. prevent a third party from replying with it's own ip & port number
>to redirect a client for nefarious purposes.
>
>Solving this for both mDNS and DNS-SD would be a good thing.
>
>http://www.gnucitizen.org/blog/name-mdns-poisoning-attacks-inside-the-lan/
>
>Best,
>Alf
>
>On Nov 7, 2012, at 1:59 AM, Matthew Gast <[email-masked]> wrote:
>
>> Another item that emerged from today's BoF discussion was a somewhat
>> nebulous desire for security.  It's not really in the current draft of
>>the
>> requirements document, so I'll start off with what I heard today, which
>>is
>> that service advertisements shouldn't just be trusted, and that both the
>> service transmission and service reception should be validated.  If I
>>were
>> to put that into the current document, I'd propose text like this:
>> 
>> "REQ06: Security.
>> - Enable validation of authenticity of service advertisements
>>   - Users and devices are only authorized to advertise certain services
>> - Service advertisements are only delivered to authorized recipients"
>> 
>> Matthew
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> mdnsext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mdnsext
>> 
>

From: "Yi Yang (yiya)" <[email-masked]>
To: Dan Harkins <[email-masked]>
Date: Thu, 8 Nov 2012 19:29:16 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>, Matthew Gast <[email-masked]>, Tom Pusateri <[email-masked]>
Subject: Re: [mdnsext] Forwarding link-local IP multicast

On Nov 8, 2012, at 9:10 AM, Dan Harkins wrote:

> 
> On Wed, November 7, 2012 2:10 pm, Matthew Gast wrote:
>> 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.
> 
>  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?

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

> 
>  Dan.
> 
>> 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
>>> 
>>> 
>>> On Nov 6, 2012, at 5:50 PM, Tom Pusateri wrote:
>>> 
>>>> 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
>>>> _______________________________________________
>>>> mdnsext mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mdnsext
>>> 
>>> _______________________________________________
>>> mdnsext mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mdnsext
>> 
>> _______________________________________________
>> mdnsext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mdnsext
>> 
> 
> 

Date: Thu, 8 Nov 2012 06:10:53 -0800 (PST)
From: "Dan Harkins" <[email-masked]>
To: "Matthew Gast" <[email-masked]>
Importance: Normal
Cc: "[email-masked]" <[email-masked]>, Tom Pusateri <[email-masked]>, Yi Yang <[email-masked]>
Subject: Re: [mdnsext] Forwarding link-local IP multicast

On Wed, November 7, 2012 2:10 pm, Matthew Gast wrote:
> 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.

  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.

> 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
>>
>>
>>On Nov 6, 2012, at 5:50 PM, Tom Pusateri wrote:
>>
>>> 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
>>> _______________________________________________
>>> mdnsext mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mdnsext
>>
>>_______________________________________________
>>mdnsext mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/mdnsext
>
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext
>

From: Alf Watt <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 8 Nov 2012 01:21:39 +0000
Accept-Language: en-US
Cc: Matthew Gast <[email-masked]>
Subject: Re: [mdnsext] Security requirement?

I'd add:

- ensure that service resolution is authoritative for the advertisement

i.e. prevent a third party from replying with it's own ip & port number to redirect a client for nefarious purposes.

Solving this for both mDNS and DNS-SD would be a good thing.

http://www.gnucitizen.org/blog/name-mdns-poisoning-attacks-inside-the-lan/

Best,
Alf

On Nov 7, 2012, at 1:59 AM, Matthew Gast <[email-masked]> wrote:

> Another item that emerged from today's BoF discussion was a somewhat
> nebulous desire for security.  It's not really in the current draft of the
> requirements document, so I'll start off with what I heard today, which is
> that service advertisements shouldn't just be trusted, and that both the
> service transmission and service reception should be validated.  If I were
> to put that into the current document, I'd propose text like this:
> 
> "REQ06: Security.
> - Enable validation of authenticity of service advertisements
>   - Users and devices are only authorized to advertise certain services
> - Service advertisements are only delivered to authorized recipients"
> 
> Matthew
> 
> 
> 
> 
> 
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext
> 

Date: Wed, 07 Nov 2012 23:16:33 +0000
From: Robert Cragie <[email-masked]>
Organization: Gridmerge Ltd.
To: [email-masked]
Subject: Re: [mdnsext] Forwarding link-local IP multicast
Reply-To: [email-masked]

This is a cryptographically signed message in MIME format.

--------------ms010704000904080602030903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

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

On 07/11/2012 10:10 PM, Matthew Gast wrote:
> 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
>>
>>
>> On Nov 6, 2012, at 5:50 PM, Tom Pusateri wrote:
>>
>>> 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
>>> _______________________________________________
>>> mdnsext mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mdnsext
>> _______________________________________________
>> mdnsext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mdnsext
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext
>

--------------ms010704000904080602030903
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

B1578mYAAAAAAAA--------------ms010704000904080602030903--

From: Matthew Gast <[email-masked]>
To: "Yi Yang (yiya)" <[email-masked]>, Tom Pusateri <[email-masked]>
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] Forwarding link-local IP multicast

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
>
>
>On Nov 6, 2012, at 5:50 PM, Tom Pusateri wrote:
>
>> 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
>> _______________________________________________
>> mdnsext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mdnsext
>
>_______________________________________________
>mdnsext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mdnsext

From: "Yi Yang (yiya)" <[email-masked]>
To: Tom Pusateri <[email-masked]>
Date: Wed, 7 Nov 2012 18:19:15 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] Forwarding link-local IP multicast

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:

> 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
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext

From: Michael Richardson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Comments: In-reply-to Tom Pusateri <[email-masked]> message dated "Tue, 06 Nov 2012 17:50:55 -0500."
Date: Wed, 07 Nov 2012 11:31:01 -0500
Sender: [email-masked]
Subject: Re: [mdnsext] Forwarding link-local IP multicast

--=-=-Content-Transfer-Encoding: quoted-printable

>>>>> "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-

--=-=-Content-Type: application/pgp-signature

--=-=-=--

From: Tom Pusateri <[email-masked]>
Date: Wed, 7 Nov 2012 09:36:47 -0500
To: Matthew Gast <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] Educause petition in requirements document

On Nov 7, 2012, at 1:59 AM, Matthew Gast <[email-masked]> wrote:

> The Educause petition serves as a valuable input into the problem
> statement, but the feedback was phrased in terms of a specific set of
> products and the protocols they use.  I've read the petition quite a few
> times, and the requests that are in scope for this work are discovery
> across IP subnets, making sure it works at scale, and ensuring that it
> works on both IPv4 and IPv6.  There are requests to make particular
> applications (AirPlay & AirPrint) work, but those protocols are not part
> of any IETF effort I'm aware of, and are not something that this group
> would ever take on.  Therefore, I'd propose that we focus the mention of
> the petition on the issues they raise that we want to work on, with
> something like this as the strawman:
> 
> "These limitations led to a call from network administrators and end users
> in the form of the Educause petition [EP].  That petition requested
> improvements to service discovery protocols:
> 
> o Service discovery should work when protocol peers are attached to
> different IP subnets.  In large networks, it is common for wireless
> devices and wired devices to use separate IP subnets, which prevents use
> of multicast-based service discovery mechanisms.

I like what you say here with one clarification:

This should be "which prevents the use of link-local multicast-based service discovery mechanisms"

Thanks,
Tom

> o Services should be advertised across multiple subnets, whether IPv4 or
> IPv6.
> o Service discovery should be scalable and supportable in large networks
> across both wired and wireless access."
> 
> Matthew
> 
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext

From: Dan York <[email-masked]>
Date: Wed, 7 Nov 2012 09:22:24 -0500
To: Matthew Gast <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mdnsext] Educause petition in requirements document

--Apple-Mail=_8118C914-2808-4604-BC94-ED475B60957E
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=us-ascii

> Therefore, I'd propose that we focus the mention of
> the petition on the issues they raise that we want to work on, with
> something like this as the strawman:

This seems like a reasonable approach and the proposed text seems good to me.

Dan

On Nov 7, 2012, at 1:59 AM, Matthew Gast wrote:

> The Educause petition serves as a valuable input into the problem
> statement, but the feedback was phrased in terms of a specific set of
> products and the protocols they use.  I've read the petition quite a few
> times, and the requests that are in scope for this work are discovery
> across IP subnets, making sure it works at scale, and ensuring that it
> works on both IPv4 and IPv6.  There are requests to make particular
> applications (AirPlay & AirPrint) work, but those protocols are not part
> of any IETF effort I'm aware of, and are not something that this group
> would ever take on.  Therefore, I'd propose that we focus the mention of
> the petition on the issues they raise that we want to work on, with
> something like this as the strawman:
> 
> "These limitations led to a call from network administrators and end users
> in the form of the Educause petition [EP].  That petition requested
> improvements to service discovery protocols:
> 
> o Service discovery should work when protocol peers are attached to
> different IP subnets.  In large networks, it is common for wireless
> devices and wired devices to use separate IP subnets, which prevents use
> of multicast-based service discovery mechanisms.
> o Services should be advertised across multiple subnets, whether IPv4 or
> IPv6.
> o Service discovery should be scalable and supportable in large networks
> across both wired and wireless access."
> 
> Matthew
> 
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext

-- 
Dan York  [email-masked]
http://www.danyork.me/   skype:danyork
Phone: +1-802-735-1624
Twitter - http://twitter.com/danyork

--Apple-Mail=_8118C914-2808-4604-BC94-ED475B60957E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div><blockquote type="cite"><div>Therefore, I'd propose that we focus the mention of<br>the petition on the issues they raise that we want to work on, with<br>something like this as the strawman:</div></blockquote><br></div>This seems like a reasonable approach and the proposed text seems good to me.<div><br></div><div>Dan<br><div><br><div><div>On Nov 7, 2012, at 1:59 AM, Matthew Gast wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>The Educause petition serves as a valuable input into the problem<br>statement, but the feedback was phrased in terms of a specific set of<br>products and the protocols they use. &nbsp;I've read the petition quite a few<br>times, and the requests that are in scope for this work are discovery<br>across IP subnets, making sure it works at scale, and ensuring that it<br>works on both IPv4 and IPv6. &nbsp;There are requests to make particular<br>applications (AirPlay &amp; AirPrint) work, but those protocols are not part<br>of any IETF effort I'm aware of, and are not something that this group<br>would ever take on. &nbsp;Therefore, I'd propose that we focus the mention of<br>the petition on the issues they raise that we want to work on, with<br>something like this as the strawman:<br><br>"These limitations led to a call from network administrators and end users<br>in the form of the Educause petition [EP]. &nbsp;That petition requested<br>improvements to service discovery protocols:<br><br>o Service discovery should work when protocol peers are attached to<br>different IP subnets. &nbsp;In large networks, it is common for wireless<br>devices and wired devices to use separate IP subnets, which prevents use<br>of multicast-based service discovery mechanisms.<br>o Services should be advertised across multiple subnets, whether IPv4 or<br>IPv6.<br>o Service discovery should be scalable and supportable in large networks<br>across both wired and wireless access."<br><br>Matthew<br><br>_______________________________________________<br>mdnsext mailing list<br><a href="mailto:[email-masked]">[email-masked]</a><br>https://www.ietf.org/mailman/listinfo/mdnsext<br></div></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">--&nbsp;<br>Dan York &nbsp;<a href="mailto:[email-masked]">[email-masked]</a><br><a href="http://www.danyork.com/">http://www.danyork.me/</a>&nbsp;&nbsp;&nbsp;<a href="skype:danyork">skype:danyork</a><br>Phone: +1-802-735-1624<br>Twitter -&nbsp;<a href="http://twitter.com/danyork">http://twitter.com/danyork</a></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br></div></div></div></span></div></span></span><br class="Apple-interchange-newline">
</div>
<br></div></div></body></html>
--Apple-Mail=_8118C914-2808-4604-BC94-ED475B60957E--

Date: Wed, 7 Nov 2012 07:35:57 -0500
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [mdnsext] Differences between mDNS and DNS names.

Dear colleagues,

On Tue, Nov 06, 2012 at 11:41:26PM +0000, Simon Kelley wrote:
> At the BOF it was pointed out that mDNS names are UTF-8 and DNS
> names are not. DNS names are encoded using IDNA, which is specified
> in RFC 3490.

It is actually slightly more complicated than that.

First of all, DNS names _can_ have UTF-8 in them.  RFC 1034 and 1035
are perfectly clear, and if they weren't 2181 made it perfectly clear,
that labels are octets, and that they can therefore contain anything.
So at one level, DNS labels _might_ be UTF-8.  And indeed, several
enterprise-aimed systems have used this feature of the DNS in order to
offer internationalization in their systems. 

But, IDNA (RFC 3490 is obsoleted by RFCs 5890-5895) effectively makes
IDNA2008-aware applications never look up labels that contain such
UTF-8, instead processing the candidate U-labels into A-labels and
then looking those up in the DNS.  We've just spent many years
convincing applications that they need to handle this UTF-8 input by
peforming a transformation on it, so backing off that position seem
unreasonable about now.

Slightly worse, IDNA2008 doesn't actually allow some of the things
that mDNS wants to permit.  For instance, the latest multicastdns
draft (-15) includes punctuation and spaces as desiderata for mDNS
labels.  But IDNA2008 explicitly excludes punctuation on purpose, so
the code point U+0027 (') isn't permitted under IDNA2008.  Also, just
for grins, using IDNA2008, Andrew = andrew, but AndrÃ© is not a legal
U-label at all (because it has an upper case character in it).  The
application is supposed to do something (probably case fold to andrÃ©),
but that of course loses information (the capitalization).  Similarly,
as near as I can tell mDNS permits all manner of things that IDNA does
not, and has no bidi rule, so that the edge cases are bound to be very
hard to cope with.  What do you do when confronted with conjoining
Hangul Jamo, for instance, in mDNS?  Because in IDNA2008, it's not
allowed.  One can argue that these are all corner cases, but there are
enough corners so as to round out the problem.

As long as mDNS remains by definition in a purely local context (and
is a separate protocol), there is nothing wrong with these
differences, because you are always looking up using one protocol or
the other.  If, however, the two protocols are to be presented as
having a single scope, then we have a problem because the user has to
have a theory of which protocol is in use in order to make correct
guesses about which kind of label will work.  If you think working
TSIG is hard for users, imagine explaining to them why it's Andrew's
Laptop but andrewslaptop.mystuff.example.com.

I believe that we are more likely to have some success if we figure
out ways to make the two different protocols somehow complementary to
one another, and we establish ways in which one can move from one
context to another with minimal disruption.  I'm not sure how to do
that yet, but maybe sleep will improve matters and I'll have something
useful to say about this aside from, "Boy, this is tricky."

Best,

A

-- 
Andrew Sullivan
[email-masked]

From: Matthew Gast <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 7 Nov 2012 06:59:11 +0000
Accept-Language: en-US
Subject: [mdnsext] Educause petition in requirements document

The Educause petition serves as a valuable input into the problem
statement, but the feedback was phrased in terms of a specific set of
products and the protocols they use.  I've read the petition quite a few
times, and the requests that are in scope for this work are discovery
across IP subnets, making sure it works at scale, and ensuring that it
works on both IPv4 and IPv6.  There are requests to make particular
applications (AirPlay & AirPrint) work, but those protocols are not part
of any IETF effort I'm aware of, and are not something that this group
would ever take on.  Therefore, I'd propose that we focus the mention of
the petition on the issues they raise that we want to work on, with
something like this as the strawman:

"These limitations led to a call from network administrators and end users
in the form of the Educause petition [EP].  That petition requested
improvements to service discovery protocols:

o Service discovery should work when protocol peers are attached to
different IP subnets.  In large networks, it is common for wireless
devices and wired devices to use separate IP subnets, which prevents use
of multicast-based service discovery mechanisms.
o Services should be advertised across multiple subnets, whether IPv4 or
IPv6.
o Service discovery should be scalable and supportable in large networks
across both wired and wireless access."

Matthew

From: Matthew Gast <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 7 Nov 2012 06:59:07 +0000
Accept-Language: en-US
Subject: [mdnsext] 802.11 addition to requirements documents

In section 1, there is a paragraph describing how DNS-SD is not suitable
for emerging technologies (beginning "Similarly, DNS-SD/mDNS in its
present form...").  One point that was brought up in today's BoF
discussion is that 802.11 is also different from the Ethernet link layers
that supported service discovery.  As a straw-man, I'd suggest text like
the following, to get at the problems related to high overhead from
multicast traffic and relatively high packet loss of multicast frames:

"Wireless networks such as 802.11 [IEEE802.11] may be adversely affected
by extensive multicast transmissions to support service discovery.  As
802.11 is typically deployed, multicast frames are sent at low data rates.
 Low-rate frames require more time to transmit frames, which increases
network overhead.  To preserve network capacity for application traffic,
administrators of large-scale networks may block some or all multicast
traffic.  In 802.11, multicast frames are not positively acknowledged and
it is common to observe much higher loss of multicast frames on 802.11
than other IEEE 802 networks."

The reference to [IEEE802.11] would be to IEEE Std 802.11-2012, IEEE
Standard for Information technology--Telecommunications and information
exchange between systems Local and metropolitan area networks--Specific
requirements Part 11: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications.

Matthew

From: Matthew Gast <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 7 Nov 2012 06:59:13 +0000
Accept-Language: en-US
Subject: [mdnsext] Security requirement?

Another item that emerged from today's BoF discussion was a somewhat
nebulous desire for security.  It's not really in the current draft of the
requirements document, so I'll start off with what I heard today, which is
that service advertisements shouldn't just be trusted, and that both the
service transmission and service reception should be validated.  If I were
to put that into the current document, I'd propose text like this:

"REQ06: Security.
- Enable validation of authenticity of service advertisements
   - Users and devices are only authorized to advertise certain services
- Service advertisements are only delivered to authorized recipients"

Matthew

From: =?iso-8859-1?Q?Patrik_Fältström?= <[email-masked]>
Date: Wed, 7 Nov 2012 07:09:06 +0100
To: Simon Kelley <[email-masked]>
Cc: [email-masked]
Subject: Re: [mdnsext] Differences between mDNS and DNS names.

There might be a few differences.

First of all, IDNA compatible strings can be A-LABEL (encoded in punycode) or U-LABEL (unicode strings). There is a 1:1 mapping between the two.

There would be a larger difference in the cases mdns requires (or not) some normalization of a unicode string before it is UTF-8 encoded. And that must be defined or else comparison of UTF-8 strings in mdns is undefined.

   Patrik

On 7 nov 2012, at 00:41, Simon Kelley <[email-masked]> wrote:

> At the BOF it was pointed out that mDNS names are UTF-8 and DNS names are not. DNS names are encoded using IDNA, which is specified in RFC 3490.
> 
> This shouldn't be a problem: both UTF-8 and IDNA are encodings for unicode, they're just different ways to represent a string of unicode in an octet stream which has some arbitrary constraints. As such, interconverting between the two representations is well defined, lossless, and fairly straightforward.
> 
> You can't use the wire format of mDNS packets as unicast DNS packets or vice versa*, but you can convert one to the other at higher level.
> 
> Cheers,
> 
> Simon.
> 
> * and not just because of the name encoding, there are other subtle differences, for example mDNS reply packets don't include the question section, whilst unicast DNS replies do.
> 
> 
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext
> 

Date: Tue, 6 Nov 2012 23:30:08 -0500
[email-masked]>
From: Brian Dickson <[email-masked]>
To: Michael Richardson <[email-masked]>
Content-Type: multipart/alternative; boundary7d7b3440c666abd404cde02ccf
Cc: [email-masked]
Subject: Re: [mdnsext] mDNS "bastion" instead of multicast forwarding
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <mdnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mdnsext>, <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mdnsext>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mdnsext>, <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2012 04:30:09 -0000

--047d7b3440c666abd404cde02ccf
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Nov 6, 2012 at 8:45 PM, Michael Richardson <[email-masked]>wrote:

>
> >>>>> "Brian" = Brian Dickson <[email-masked]> writes:
>     Brian> I think a useful area to explore, instead, would be the
>     Brian> notion from firewall-land of a "bastion host", which has
>     Brian> presence on multiple links/subnets, and is mDNS-cognizant,
>     Brian> and acts as some kind of proxy.
>
> avahi does this now.
> It suffers from loops if there are multiple machines on both networks.
> (for instance, two laptops with both wired and wireless)
>
> The point is that this bastion host has to solve all the same problems
> that the layer-3 multicast protocols have already solved.
>
>
I'm thinking not of a "normal" host, but rather something doing
resolution/caching, like a router or maybe a specialized box, with
connections on multiple links.

Even if there were more than one such box, with both boxes on both links,
the idea is that they would recognize each other and "do the right thing".
(I think there is some stuff along those lines for a single broadcast
domain for mDNS as it is.)

Does that make more sense?

It presumes that there is already-solved bits in mDNS that cold be extended
to the multiple-links scenario.

Brian

--047d7b3440c666abd404cde02ccf
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 6, 2012 at 8:45 PM, Michael Richardson <span dir="ltr">&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
&gt;&gt;&gt;&gt;&gt; &quot;Brian&quot; == Brian Dickson &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; writes:<br>
    Brian&gt; I think a useful area to explore, instead, would be the<br>
    Brian&gt; notion from firewall-land of a &quot;bastion host&quot;, which has<br>
    Brian&gt; presence on multiple links/subnets, and is mDNS-cognizant,<br>
    Brian&gt; and acts as some kind of proxy.<br>
<br>
avahi does this now.<br>
It suffers from loops if there are multiple machines on both networks.<br>
(for instance, two laptops with both wired and wireless)<br>
<br>
The point is that this bastion host has to solve all the same problems<br>
that the layer-3 multicast protocols have already solved.<br><br></blockquote><div><br></div><div>I&#39;m thinking not of a &quot;normal&quot; host, but rather something doing resolution/caching, like a router or maybe a specialized box, with connections on multiple links.</div>
<div><br></div><div>Even if there were more than one such box, with both boxes on both links, the idea is that they would recognize each other and &quot;do the right thing&quot;. (I think there is some stuff along those lines for a single broadcast domain for mDNS as it is.)</div>
<div><br></div><div>Does that make more sense?</div><div><br></div><div>It presumes that there is already-solved bits in mDNS that cold be extended to the multiple-links scenario.</div><div><br></div><div>Brian </div></div>
<br>

--047d7b3440c666abd404cde02ccf--

From: Michael Richardson <[email-masked]>
To: Brian Dickson <[email-masked]>
Comments: In-reply-to Brian Dickson <[email-masked]> message dated "Tue, 06 Nov 2012 18:07:44 -0500."
Date: Tue, 06 Nov 2012 20:45:29 -0500
Sender: [email-masked]
Cc: [email-masked]
Subject: Re: [mdnsext] mDNS "bastion" instead of multicast forwarding

--=-=-Content-Transfer-Encoding: quoted-printable

>>>>> "Brian" == Brian Dickson <[email-masked]> writes:
    Brian> I think a useful area to explore, instead, would be the
    Brian> notion from firewall-land of a "bastion host", which has
    Brian> presence on multiple links/subnets, and is mDNS-cognizant,
    Brian> and acts as some kind of proxy.

avahi does this now.
It suffers from loops if there are multiple machines on both networks.
(for instance, two laptops with both wired and wireless)

The point is that this bastion host has to solve all the same problems
that the layer-3 multicast protocols have already solved.

-- 
Michael Richardson
-on the road-

--=-=-Content-Type: application/pgp-signature

--=-=-=--

From: Michael Richardson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Comments: In-reply-to "Yi Yang (yiya)" <[email-masked]> message dated "Tue, 06 Nov 2012 22:34:06 +0000."
Date: Tue, 06 Nov 2012 20:33:47 -0500
Sender: [email-masked]
Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-00

--=-=-Content-Transfer-Encoding: quoted-printable

Kelly,
some minor edits that I suggest:

>   In response to this and similar evidence of market demand, several
>   companies have recently announced "Bonjour gateway" products that
>   allow service discovery beyond the local link.  However, these were

for longevity:
>   In response to this and similar evidence of market demand, several
>   companies have announced "Bonjour gateway" products in 2012 that
>   allow service discovery beyond the local link.  However, these were

(could be mid-2013 before the document gets published)

>   o  Airplay does not work when Apple TV's and Apple client devices
>   are

could we have Airplay [X] with a URL to tell the heathens among you what
this does, and how it works?

>2.2.  Low Power and Lossy Networks (LLNs)
>
>   Emerging wireless mesh networking technologies such as RPL/6LoWPAN
>   [RFC4944] [RFC6550] present several challenges for the current DNS-

change to:
>   [RFC4944] [RFC6550] ("LLNs") present several challenges for the current DNS-

>   SD/mDNS design.  First, "local link" is defined as a node's one-hop
>   neighbors.  This effectively means that a mesh is a multi-link
>   single-prefix subnet and that link-local multicast scope is
>   insufficient to span it.

Add to this:
    Recent work in [draft-ietf-roll-trickle-mcast] may restore
    subnet-specific multi-cast, there are costs to supporting this,
    and if a very low-cost multi-link mDNS solution existed, it could be
    deployed to LLN routing nodes.

>   Not only is subnet-scoped multicast difficult on such networks, but
>   low-power nodes may be offline for significant periods either because
>   they are "sleeping" or due to connectivity problems.  In such cases
>   LLN nodes might fail to defend their names using the current design.

add to this:
    However, for LLNs that include a controller (such as 802.15.4
    networks using ZigBee 2012), the 6lowpan ND/DAD replacement includes
    an always available whiteboard which could also include mDNS
    registrations.   This facility is not universal to LLNs [XXX I think]

>   REQ04: Suitable for both local (zero-config) and global (minimal
>   config) use.

do you really want to say "global"?  I think you mean to say, 
"within an Enterprise", or "within an AS".  I do not think that
University of Wisconsin students need to see printers at University of
Toronto...

-- 
Michael Richardson
-on the road-

--=-=-Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAABAgAGBQJQmbp7AAoJEKD0KQ7Gj3P2KZAH/1x7ViGI/J31OqakV3VvQReo
/oFl/ck9IAnGd5MlYdzrmKrKx8m8HMzsU0a8kKMEPqF/3GDB7bkTnmcMl4Gfe68J
YD14CIb0+OyPwCvLOMtfUwuzrJ8L3SVN+HFG28fEJKzLAwu+rlhhCdKb/koWTrL8
urRbOPsVtaZV3I2x7eaTZscU7ItvZHHIGRhsa+Qa2iUEVxJHmcMc2SmZCpu0bxSQ
Sx6UCU5u5CiJam6kxcVaPjDNAG1DQXiuF08yAHNBPj4T7/w46+77kcXJo3m8wqil
XMKjGHGhyMYxmcnXlDQU4Jrnl+EwxzJn/5uNBlqNjxb7UL7OMtbji3MNv67onWcù/R
-----END PGP SIGNATURE-----
--=-=-=--

From: Michael Richardson <[email-masked]>
To: [email-masked]
Comments: In-reply-to Brian Dickson <[email-masked]> message dated "Tue, 06 Nov 2012 17:51:57 -0500."
Date: Tue, 06 Nov 2012 20:41:52 -0500
Sender: [email-masked]
Subject: Re: [mdnsext] miniature equine quadrupeds

--=-=-Content-Transfer-Encoding: quoted-printable

>>>>> "Brian" == Brian Dickson <[email-masked]> writes:
    Brian> User Activity: Connect To My Home Network (over unicast!!!)

    Brian> -> user needs to know FQDN of home gateway, either via
    Brian> service-provider-facilitated name (ugly), or via user-managed
    Brian> "vanity" domain updated via Dynamic DNS (pretty).

...

    Brian> Under-the-hood Activity: Client machine now talks to mDNS
    Brian> PROXY, via unicast, located either on Home Router, or via
    Brian> (probably NAT'd by Home Router) additional device on Home

so, the interface I imagine is that one hooks up at some new (maybe your
first) homenet.  Using mDNS service discovery, the
tablet/laptop/smartphone finds out the GUA address of the mDNS proxy,
and finding one probably asks the user a question:
  
  [ Hi, You seem to be network FOOBAR. Do you wish to remember how ]
  [ to access services (printers, refridgerators, etc.) on this    ]
  [ network when you are away?   {yes}  {no} net name: _FOOBAR_    ]

is this what you have in mind?

-- 
Michael Richardson
-on the road-

--=-=-Content-Type: application/pgp-signature

--=-=-=--

Date: Tue, 06 Nov 2012 23:41:26 +0000
From: Simon Kelley <[email-masked]>
To: [email-masked]
Subject: [mdnsext] Differences between mDNS and DNS names.

At the BOF it was pointed out that mDNS names are UTF-8 and DNS names 
are not. DNS names are encoded using IDNA, which is specified in RFC 3490.

This shouldn't be a problem: both UTF-8 and IDNA are encodings for 
unicode, they're just different ways to represent a string of unicode in 
an octet stream which has some arbitrary constraints. As such, 
interconverting between the two representations is well defined, 
lossless, and fairly straightforward.

You can't use the wire format of mDNS packets as unicast DNS packets or 
vice versa*, but you can convert one to the other at higher level.

Cheers,

Simon.

* and not just because of the name encoding, there are other subtle 
differences, for example mDNS reply packets don't include the question 
section, whilst unicast DNS replies do.

Date: Tue, 6 Nov 2012 18:29:33 -0500
From: Brian Dickson <[email-masked]>
To: [email-masked]
Subject: [mdnsext] Simple idea for supporting scaling issues with small devices

--047d7b62275e7572a204cddbf94b
Content-Type: text/plain; charset=ISO-8859-1

One level of indirection may be enough for situations where lots of small
devices are used, in environments bigger than they were originally designed
for.

E.g. consumer-level box that can handle a dozen or so devices. Combine a
bunch of these and they all fail.

Solution: add the notion of a "forwarder" to the box.

If the box is multi-link aware, it would need to include relevant
name/number info in the forwarded queries, but other than that, they could
all forward their traffic by caching local-net and forwarding queries for
non-local-net (without caching results), to a centralized bigger-class box
(which needn't be a router - could be a host application), via unicast.

The incremental configuration and hardware would be negligible, and still
be backwards-compatible for the clients.

Thoughts?
Brian

--047d7b62275e7572a204cddbf94b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

One level of indirection may be enough for situations where lots of small devices are used, in environments bigger than they were originally designed for.<div><br></div><div>E.g. consumer-level box that can handle a dozen or so devices. Combine a bunch of these and they all fail.</div>
<div><br></div><div>Solution: add the notion of a &quot;forwarder&quot; to the box.</div><div><br></div><div>If the box is multi-link aware, it would need to include relevant name/number info in the forwarded queries, but other than that, they could all forward their traffic by caching local-net and forwarding queries for non-local-net (without caching results), to a centralized bigger-class box (which needn&#39;t be a router - could be a host application), via unicast.</div>
<div><br></div><div>The incremental configuration and hardware would be negligible, and still be backwards-compatible for the clients.</div><div><br></div><div>Thoughts?</div><div>Brian</div>

--047d7b62275e7572a204cddbf94b--

Date: Tue, 6 Nov 2012 18:23:40 -0500
From: Brian Dickson <[email-masked]>
To: [email-masked]
Subject: [mdnsext] namespace scope and naming "links"

--047d7b62275e66396604cddbe4f6
Content-Type: text/plain; charset=ISO-8859-1

Extending mDNS to beyond the immediate local link, raises the risk of
namespace collisions, as well as raises the risk of causing user confusion,
and UI messiness when large numbers of instances of a given service (e.g.
printers) show up in a flat namespace.

Here's a few thoughts on this.

Presuming we're talking about IP (v4 or v6), anything that is aware of
multiple links, pretty much by definition needs to know the corresponding
prefix(es) of the respective links.

And given that we're talking about locally-scoped (in the sense of "not
global DNS") stuff, address-collision within a given "local" instance is
presumed to not exist, and at the same time, address-collisions between
different "local" instances is both possible and unimportant.

So, what I'm suggesting is, use a reverse-DNS tree for the scoping of links
(preferably in CIDR-friendly manner - let's avoid tying ourselves to the
class-ful past), with no overlap with the global DNS.

So, NOT under the in-addr.arpa. zone !!!
But, analogous to it, e.g. rdns.local. or something similar.

For zero config, the mDNS things that are multiple-link/subnet aware, the
scope for names intra-link would be bare-name, and for names that need to
cross link boundaries, i.e. inter-link, they would be
name.enough.subnet.for.uniqueness.

E.g. if two links were 192.168.3.0/24 and 192.168.4.0/24, the "full" name
might be something like name.3.168.192.rdns.local, but since both "zoned"
share the 192.168 bit, names could be shortened to name.3 or name.4.

For friendliness, the non-zeroconf enhancement would be the ability to
"name" a given "link".

Under the hood, this might be to include a TXT record for the name of the
link itself, in the rdns.local tree.

3.168.192.rdns.local. IN TXT "Basement"
4.168.192.rdns.local. IN TXT "Garage"

Browsing would need to accomodate the non-flat space, but this works well
in scoping the service discovery and traffic, I think.

Thoughts?

Brian

--047d7b62275e66396604cddbe4f6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Extending mDNS to beyond the immediate local link, raises the risk of namespace collisions, as well as raises the risk of causing user confusion, and UI messiness when large numbers of instances of a given service (e.g. printers) show up in a flat namespace.<div>
<br></div><div>Here&#39;s a few thoughts on this.</div><div><br></div><div>Presuming we&#39;re talking about IP (v4 or v6), anything that is aware of multiple links, pretty much by definition needs to know the corresponding prefix(es) of the respective links.</div>
<div><br></div><div>And given that we&#39;re talking about locally-scoped (in the sense of &quot;not global DNS&quot;) stuff, address-collision within a given &quot;local&quot; instance is presumed to not exist, and at the same time, address-collisions between different &quot;local&quot; instances is both possible and unimportant.</div>
<div><br></div><div>So, what I&#39;m suggesting is, use a reverse-DNS tree for the scoping of links (preferably in CIDR-friendly manner - let&#39;s avoid tying ourselves to the class-ful past), with no overlap with the global DNS.</div>
<div><br></div><div>So, NOT under the in-addr.arpa. zone !!!</div><div>But, analogous to it, e.g. rdns.local. or something similar.</div><div><br></div><div>For zero config, the mDNS things that are multiple-link/subnet aware, the scope for names intra-link would be bare-name, and for names that need to cross link boundaries, i.e. inter-link, they would be name.enough.subnet.for.uniqueness.</div>
<div><br></div><div>E.g. if two links were <a href="http://192.168.3.0/24">192.168.3.0/24</a> and <a href="http://192.168.4.0/24">192.168.4.0/24</a>, the &quot;full&quot; name might be something like name.3.168.192.rdns.local, but since both &quot;zoned&quot; share the 192.168 bit, names could be shortened to name.3 or name.4.</div>
<div><br></div><div>For friendliness, the non-zeroconf enhancement would be the ability to &quot;name&quot; a given &quot;link&quot;.</div><div><br></div><div>Under the hood, this might be to include a TXT record for the name of the link itself, in the rdns.local tree.</div>
<div><br></div><div>3.168.192.rdns.local. IN TXT &quot;Basement&quot;</div><div>4.168.192.rdns.local. IN TXT &quot;Garage&quot;</div><div><br></div><div>Browsing would need to accomodate the non-flat space, but this works well in scoping the service discovery and traffic, I think.</div>
<div><br></div><div>Thoughts?</div><div><br></div><div>Brian</div>

--047d7b62275e66396604cddbe4f6--

Date: Tue, 6 Nov 2012 18:07:44 -0500
From: Brian Dickson <[email-masked]>
To: [email-masked]
Subject: [mdnsext] mDNS "bastion" instead of multicast forwarding

--047d7b34388476256b04cddbab3d
Content-Type: text/plain; charset=ISO-8859-1

I concur (emphatically) with the recommendation against any kind of Layer-3
activity (routing/forwarding raw multicast stuff).

I think a useful area to explore, instead, would be the notion from
firewall-land of a "bastion host", which has presence on multiple
links/subnets, and is mDNS-cognizant, and acts as some kind of proxy.

The devil, undoubtedly, is in the details.

The details that matter would be:
- zero config behavior that is sensible
- user administrative controls that allow good things
- preventing (at all costs) any exposure to user-supplied configurations
that can break a network
- scalable behavior that supports multiple use cases

And the basic primitive functionality would be:
An mDNS "thing" that is able to "speak" on two subnets, and which has mDNS
data concerning both subnets, which acts as some kind of mDNS "proxy" to
mDNS "clients" and "servers" on those subnets.

I think the how and what of all aspects of that can be worked out; the
question is, is this sufficient to facilitate the goals, and backward
compatible enough?

One final thought - for the other group (don't remember specifically what
the WG acronym is - the "lightswitch" folks), would being able to talk
unicast to such a proxy, meet all the needs so as to avoid implementing
multicast?

Brian

--047d7b34388476256b04cddbab3d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I concur (emphatically) with the recommendation against any kind of Layer-3 activity (routing/forwarding raw multicast stuff).<div><br></div><div>I think a useful area to explore, instead, would be the notion from firewall-land of a &quot;bastion host&quot;, which has presence on multiple links/subnets, and is mDNS-cognizant, and acts as some kind of proxy.</div>
<div><br></div><div>The devil, undoubtedly, is in the details.</div><div><br></div><div>The details that matter would be:</div><div>- zero config behavior that is sensible</div><div>- user administrative controls that allow good things</div>
<div>- preventing (at all costs) any exposure to user-supplied configurations that can break a network</div><div>- scalable behavior that supports multiple use cases</div><div><br></div><div>And the basic primitive functionality would be:</div>
<div>An mDNS &quot;thing&quot; that is able to &quot;speak&quot; on two subnets, and which has mDNS data concerning both subnets, which acts as some kind of mDNS &quot;proxy&quot; to mDNS &quot;clients&quot; and &quot;servers&quot; on those subnets.</div>
<div><br></div><div>I think the how and what of all aspects of that can be worked out; the question is, is this sufficient to facilitate the goals, and backward compatible enough?</div><div><br></div><div>One final thought - for the other group (don&#39;t remember specifically what the WG acronym is - the &quot;lightswitch&quot; folks), would being able to talk unicast to such a proxy, meet all the needs so as to avoid implementing multicast?</div>
<div><br></div><div>Brian</div>

--047d7b34388476256b04cddbab3d--

Date: Tue, 6 Nov 2012 17:51:57 -0500
From: Brian Dickson <[email-masked]>
To: [email-masked]
Subject: [mdnsext] miniature equine quadrupeds

--047d7b621edef9941504cddb72c1
Content-Type: text/plain; charset=ISO-8859-1

I'd like to suggest use-case-like examples of what would be a "pony", and
what would facilitate remote accessibility of mDNS-enabled services without
having a "pony".

Here is what Andrew Sullivan was talking about, which would be classified
as a "pony":

      Joe's Random
Thing.local.mac-aa-bb-cc-dd-ee-ff.city.cable-co.example.net

(Note that the things to the left of .local. are generally what mDNS would
allow, and what are prohibited by global DNS rules.)

Here is how I think things could work "just fine", modulo other aspects of
mDNS:

User Activity: Connect To My Home Network (over unicast!!!)

 -> user needs to know FQDN of home gateway, either via
service-provider-facilitated name (ugly), or via user-managed "vanity"
domain updated via Dynamic DNS (pretty).

E.g., user enters name (or has a Preferences thingy where such names are
kept):

     mac-aa-bb-cc-dd-ee-ff.city.cable-co.example.net
or
     joes-home-net.example.com

Optional User Activity: authenticate to Home Network Router

Under-the-hood Activity: Client machine now talks to mDNS PROXY, via
unicast, located either on Home Router, or via (probably NAT'd by Home
Router) additional device on Home Network, and receives mDNS "feed" with
suitable outside-in address/port combos for access to services discovered.

So, there would never be direct merger of global DNS namespace with mDNS
"local" namespace. The global DNS would be a service-discovery-discovery
mechanism.  Global and local are effectively ships-in-the-night, and the
global DNS folks sleep well at night.

Thoughts?

Brian

--047d7b621edef9941504cddb72c1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I&#39;d like to suggest use-case-like examples of what would be a &quot;pony&quot;, and what would facilitate remote accessibility of mDNS-enabled services without having a &quot;pony&quot;.<div><br></div><div>Here is what Andrew Sullivan was talking about, which would be classified as a &quot;pony&quot;:</div>
<div><br></div><div>      Joe&#39;s Random <a href="http://Thing.local.mac-aa-bb-cc-dd-ee-ff.city.cable-co.example.net">Thing.local.mac-aa-bb-cc-dd-ee-ff.city.cable-co.example.net</a></div><div><br></div><div>(Note that the things to the left of .local. are generally what mDNS would allow, and what are prohibited by global DNS rules.)</div>
<div><br></div><div>Here is how I think things could work &quot;just fine&quot;, modulo other aspects of mDNS:</div><div><br></div><div>User Activity: Connect To My Home Network (over unicast!!!)</div><div><br></div><div>
 -&gt; user needs to know FQDN of home gateway, either via service-provider-facilitated name (ugly), or via user-managed &quot;vanity&quot; domain updated via Dynamic DNS (pretty).</div><div><br></div><div>E.g., user enters name (or has a Preferences thingy where such names are kept):</div>
<div><br></div><div>     <a href="http://mac-aa-bb-cc-dd-ee-ff.city.cable-co.example.net">mac-aa-bb-cc-dd-ee-ff.city.cable-co.example.net</a></div><div>or</div><div>     <a href="http://joes-home-net.example.com">joes-home-net.example.com</a></div>
<div><br></div><div>Optional User Activity: authenticate to Home Network Router</div><div><br></div><div>Under-the-hood Activity: Client machine now talks to mDNS PROXY, via unicast, located either on Home Router, or via (probably NAT&#39;d by Home Router) additional device on Home Network, and receives mDNS &quot;feed&quot; with suitable outside-in address/port combos for access to services discovered.</div>
<div><br></div><div>So, there would never be direct merger of global DNS namespace with mDNS &quot;local&quot; namespace. The global DNS would be a service-discovery-discovery mechanism.  Global and local are effectively ships-in-the-night, and the global DNS folks sleep well at night.</div>
<div><br></div><div>Thoughts?</div><div><br></div><div>Brian</div>

--047d7b621edef9941504cddb72c1--

From: Tom Pusateri <[email-masked]>
Date: Tue, 6 Nov 2012 17:50:55 -0500
To: "[email-masked]" <[email-masked]>
Subject: [mdnsext] Forwarding link-local IP multicast

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: "Yi Yang (yiya)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 6 Nov 2012 22:34:06 +0000
Accept-Language: en-US
Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-00

For the user interface, in addition that it should be short and showing only alive/reachable/authorized services, it would be nice to support sorting as well, no matter if the sorting logic resides on client or proxy.

Yi

From: Tim Chown <[email-masked]>
Date: Tue, 6 Nov 2012 14:11:12 +0000
To: "[email-masked]" <[email-masked]>
Subject: [mdnsext] BoF today, minuter taker and Jabber relay needed

--Apple-Mail=_66C47AA8-BACB-432D-BFE7-2DD1AF9505A7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,

The mdnsext BoF is today at 15:20 US Eastern Time. The agenda is below.  
Slides are available here: https://datatracker.ietf.org/meeting/85/materials.html.
Remote participation details are here: http://www.ietf.org/meeting/85/remote-participation.html

Thomas and I will need someone to take minutes, and a Jabber relay - volunteers welcome!

Tim

Agenda: https://datatracker.ietf.org/meeting/85/agenda/mdnsext/

Extensions of the Bonjour Protocol Suite (mdnsext) BoF

TUESDAY, November 6, 2012 
1520-1650 Afternoon Session II 

Grand Ballroom C

=====================================================  * 

* Administravia (10 mins)   
  Note Well   
  Agenda bashing
  (Chairs)

* Goals of the BoF (10 mins)
  NB. RFC5434, Section 1
  (Chairs)

* Use cases for Bonjour in routed networks (15 mins)
  (Stuart Cheshire)

* Requirements (25 mins)
  draft-lynn-mdnsext-requirements-00
  (Kerry Lynn)

* Open discussion (20 mins)
  Charter bashing

* Questions and Conclusion (10 mins)
  Next steps towards a WG?

--Apple-Mail=_66C47AA8-BACB-432D-BFE7-2DD1AF9505A7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi,</div><div><br></div><div>The mdnsext BoF is today at 15:20 US Eastern Time. The agenda is below. &nbsp;</div><div>Slides are available here:&nbsp;<a href="https://datatracker.ietf.org/meeting/85/materials.html">https://datatracker.ietf.org/meeting/85/materials.html</a>.</div><div>Remote participation details are here:&nbsp;<a href="http://www.ietf.org/meeting/85/remote-participation.html">http://www.ietf.org/meeting/85/remote-participation.html</a></div><div><br></div><div>Thomas and I will need someone to take minutes, and a Jabber relay - volunteers welcome!</div><div><br></div><div>Tim</div><div><br></div><div>Agenda:&nbsp;<a href="https://datatracker.ietf.org/meeting/85/agenda/mdnsext/">https://datatracker.ietf.org/meeting/85/agenda/mdnsext/</a></div><div><br></div><div><div>Extensions of the Bonjour Protocol Suite (mdnsext) BoF</div><div><br></div><div>TUESDAY, November 6, 2012&nbsp;</div><div>1520-1650 Afternoon Session II&nbsp;</div><div><br></div><div>Grand Ballroom C</div><div><br></div><div>===================================================== &nbsp;*&nbsp;</div><div><br></div><div>* Administravia (10 mins) &nbsp;&nbsp;</div><div>&nbsp; Note Well &nbsp;&nbsp;</div><div>&nbsp; Agenda bashing</div><div>&nbsp; (Chairs)</div><div><br></div><div>* Goals of the BoF (10 mins)</div><div>&nbsp; NB. RFC5434, Section 1</div><div>&nbsp; (Chairs)</div><div><br></div><div>* Use cases for Bonjour in routed networks (15 mins)</div><div>&nbsp; (Stuart Cheshire)</div><div><br></div><div>* Requirements (25 mins)</div><div>&nbsp; draft-lynn-mdnsext-requirements-00</div><div>&nbsp; (Kerry Lynn)</div><div><br></div><div>* Open discussion (20 mins)</div><div>&nbsp; Charter bashing</div><div><br></div><div>* Questions and Conclusion (10 mins)</div><div>&nbsp; Next steps towards a WG?</div><div><br></div><div><br></div></div><div><br></div><div><br></div><div><br></div><div><br></div></body></html>
--Apple-Mail=_66C47AA8-BACB-432D-BFE7-2DD1AF9505A7--

Date: Sun, 4 Nov 2012 12:05:55 -0500
From: Indtiny s <[email-masked]>
To: Ray Bellis <[email-masked]>
Cc: "<[email-masked]>" <[email-masked]>, Kerry Lynn <[email-masked]>
Subject: Re: [mdnsext] xmDNS support in mdnsresponder for homenet

--047d7b343934c5dafa04cdae6182
Content-Type: text/plain; charset=ISO-8859-1

Hi,

Thanks for providing the useful suggestion , due to some
urgent requirement I have to support the xmDNS support  with TLD name
"site" .

Can someone help me , How and what exactly I can start with mdnsresponder
code(particularly changing the multicast address)  , in-order support the
homenet RFC ..?

Rgds
Indra

--047d7b343934c5dafa04cdae6182
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>Thanks for providing the useful suggestion , due to some urgent requirement I have to support the xmDNS support  with TLD name &quot;site&quot; . </div><div><br></div><div>Can someone help me , How and what exactly I can start with mdnsresponder code(particularly changing the multicast address)  , in-order support the homenet RFC ..?</div>
<div><br></div><div>Rgds</div><div>Indra</div><div><br><div class="gmail_quote"> </div></div>

--047d7b343934c5dafa04cdae6182--

From: Ray Bellis <[email-masked]>
To: Indtiny s <[email-masked]>
Date: Thu, 1 Nov 2012 08:19:36 +0000
Accept-Language: en-GB, en-US
Cc: "<[email-masked]>" <[email-masked]>, Kerry Lynn <[email-masked]>
Subject: Re: [mdnsext] xmDNS support in mdnsresponder for homenet

--_000_F4E943980D37459A865D6C36372343AFnominetorguk_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On 31 Oct 2012, at 16:27, Indtiny s <[email-masked]<mailto:[email-masked]>> wrote:

Hi,
The document is almost concluded the basic status . http://tools.ietf.org/html/draft-lynn-homenet-site-mdns-01

Due to some urgent requirment I need to go with adding the basic ".site"  domain ,i.e Any DNS query for a name ending with ".site." MUST be sent to the xmDNS multicast address (FF05::FB ) and its IPv4 equivalent to 239.255.255.239.

Please note that there will very likely be a new gTLD of '.site' some time within the next 18 months.

Whilst IETF apparently has the right to reserve TLDs for 'special use', IMHO we are unable to pre-empt any of those that have been applied for in the current round of new gTLD applications.

Just sayin'

Ray

--_000_F4E943980D37459A865D6C36372343AFnominetorguk_
Content-Type: text/html; charset="iso-8859-1"
Content-ID: <dd3a66f9-fd02-4ba3-a80b-373cfd5b8427>
Content-Transfer-Encoding: quoted-printable

<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 31 Oct 2012, at 16:27, Indtiny s &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi,<br>The document is almost concluded the basic status . <a href="http://tools.ietf.org/html/draft-lynn-homenet-site-mdns-01">http://tools.ietf.org/html/draft-lynn-homenet-site-mdns-01</a> <br><br>Due to some urgent requirment I need to go with adding the basic &quot;.site&quot;&nbsp; domain ,i.e Any DNS query for a name ending with &quot;.site.&quot; MUST be sent to the xmDNS multicast address (FF05::FB ) and its IPv4 equivalent to 239.255.255.239.</blockquote><br></div><div>Please note that there will very likely be a new gTLD of '.site' some time within the next 18 months.</div><div><br></div><div>Whilst IETF apparently has the right to reserve TLDs for 'special use', IMHO we are unable to pre-empt any of those that have been applied for in the current round of new gTLD applications.</div><br><div>Just sayin'</div><div><br></div><div>Ray</div><div><br></div></body></html>
--_000_F4E943980D37459A865D6C36372343AFnominetorguk_--