Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C417021F89E0 for ; Thu, 15 Nov 2012 09:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgRBV8oqnkBP for ; Thu, 15 Nov 2012 09:48:20 -0800 (PST) Received: from mail.hopcount.ca (mail.hopcount.ca [IPv6:2001:4900:1:392::37]) by ietfa.amsl.com (Postfix) with ESMTP id DA6F721F89C3 for ; Thu, 15 Nov 2012 09:48:17 -0800 (PST) Received: from [2001:4900:1042:100:1d95:a72d:26dd:db2b] by mail.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TZ3Xt-0001sg-K4; Thu, 15 Nov 2012 17:48:14 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Joe Abley In-Reply-To: Date: Thu, 15 Nov 2012 12:48:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4BFCA58F-0A16-4D9B-8573-9CFEF5736068@hopcount.ca> References: To: Ray Bellis X-Mailer: Apple Mail (2.1499) Cc: "" , Kerry Lynn , Indtiny s Subject: Re: [mdnsext] xmDNS support in mdnsresponder for homenet X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:48:20 -0000 Hi Ray, On 2012-11-01, at 04:19, Ray Bellis wrote: > On 31 Oct 2012, at 16:27, Indtiny s wrote: >=20 >> The document is almost concluded the basic status . = http://tools.ietf.org/html/draft-lynn-homenet-site-mdns-01=20 >>=20 >> 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. >=20 > Please note that there will very likely be a new gTLD of '.site' some = time within the next 18 months. >=20 > 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 = five separate applications have been received for .SITE. Joe Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEDF21F8746 for ; Wed, 14 Nov 2012 09:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-xR+KRPQOdS for ; Wed, 14 Nov 2012 09:07:25 -0800 (PST) Received: from ITSNT447.iowa.uiowa.edu (itsnt447.iowa.uiowa.edu [128.255.67.11]) by ietfa.amsl.com (Postfix) with ESMTP id 9171521F8740 for ; Wed, 14 Nov 2012 09:07:25 -0800 (PST) Received: from ITSNT441.iowa.uiowa.edu ([169.254.3.228]) by ITSNT447.iowa.uiowa.edu ([128.255.67.11]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 11:07:24 -0600 From: "Johnson, Neil M" To: Matthew Gast , Dan Harkins Thread-Topic: [mdnsext] Forwarding link-local IP multicast Thread-Index: AQHNvHE0UHB+aCLDR0G0552LUJrx4ZffFHyAgABAoICAAQxQgIABzv4A//+QGgCAARpKgIAGsJEA Date: Wed, 14 Nov 2012 17:07:23 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.255.6.15] Content-Type: text/plain; charset="us-ascii" Content-ID: <17681D89578CBF4D8472B45FB300A938@mailhost6.uiowa.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org" , Tom Pusateri , Yi Yang Subject: Re: [mdnsext] Forwarding link-local IP multicast X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:07:26 -0000 Matthew, You are not too far off except for Wireless. Three subnets per building sounds about right (one subnet for public devices, assigned Global IP's; one subnet for devices that don't need Internet access, assigned RFC1918 IPv4 and IPv6 ULA space; and one for devices needing to reach the Internet, but not be reachable from the Internet, Assigned RFC1918 IPv4 space and NAT'd or Fire walled to the outside world). As for wireless, we use a controller based model and have 16 subnets of /21 RFC1918 space NAT'd to two /22's. Those subnets are dynamically assigned and span multiple buildings. Currently not multicast enabled. AppleTV's and printers would probably be on the Non-NAT'd RFC1918 space (only reachable from on campus and wireless), but may need to be visible to users using a VPN off campus. Some printers would be centrally managed (through a queue server) so those queues might need to be discoverable as Services. Sound Complicated enough for you ? -Neil --=20 Neil Johnson Network Engineer The University of Iowa Phone: 319 384-0938 Fax: 319 335-2951 Mobile: 319 540-2081 E-Mail: neil-johnson@uiowa.edu On 11/9/12 9:57 PM, "Matthew Gast" 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" 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. >>--=20 >>Neil Johnson >>Network Engineer >>The University of Iowa >>Phone: 319 384-0938 >>Fax: 319 335-2951 >>Mobile: 319 540-2081 >>E-Mail: neil-johnson@uiowa.edu >> >> >> >> >> >> >>On 11/9/12 11:48 AM, "Matthew Gast" wrote: >> >>>On 11/8/12 6:10 AM, "Dan Harkins" 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 >>>mdnsext@ietf.org >>>https://www.ietf.org/mailman/listinfo/mdnsext >> >>_______________________________________________ >>mdnsext mailing list >>mdnsext@ietf.org >>https://www.ietf.org/mailman/listinfo/mdnsext > Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2211721F8618 for ; Tue, 13 Nov 2012 21:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFDW7aTJQXoS for ; Tue, 13 Nov 2012 21:28:34 -0800 (PST) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id A6D4821F8614 for ; Tue, 13 Nov 2012 21:28:34 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPS id <0MDG009UJPVFTO52@mail-out.apple.com> for mdnsext@ietf.org; Tue, 13 Nov 2012 21:28:34 -0800 (PST) X-AuditID: 11807130-b7fcc6d0000038e5-84-50a32c0224e2 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id B9.40.14565.20C23A05; Tue, 13 Nov 2012 21:28:34 -0800 (PST) Received: from [10.0.1.15] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by jimbu.apple.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPSA id <0MDG002VIPVLC960@jimbu.apple.com> for mdnsext@ietf.org; Tue, 13 Nov 2012 21:28:34 -0800 (PST) From: Stuart Cheshire In-reply-to: Date: Tue, 13 Nov 2012 21:28:33 -0800 Message-id: <943321F0-D1B7-4103-A9A7-D98A363DE79D@apple.com> References: To: Indtiny s X-Mailer: Apple Mail (2.1085) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUiON1OVZdJZ3GAwdkpAhYnl5xicmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsTzu9kLXnBUvPz3hLGB8RtbFyMHh4SAicTij3ZdjJxAppjE hXvr2UBsIYFWJonzS/i7GLmA7ANMEjfmTGQESQgL6Et8v9gJVsQrYCix5PoWdhCbWUBLYv3O 40wgNhuQ/eLzFbAaToFgiZd3W8FqWARUJRY8uMECUa8tsfDJQzYY+8m7C6wQM20kPl54wgJy m5BAgMSH+8EgpoiAosTTlXoQZ8pK7LxzmmUCo8AsJEfMQnLELCRDFzAyr2IULErNSaw0NNRL LCjISdVLzs/dxAgKuoZCgx2Ma3/yH2IU4GBU4uF1alwUIMSaWFZcmXuIUYKDWUmE1/IsUIg3 JbGyKrUoP76oNCe1+BCjNAeLkjiv2TqglEB6YklqdmpqQWoRTJaJg1OqgbFdSPOwhmK2aEZd 7Kl8zcmOVzn+HrVw61DI9rwxf6Lerru1htndCWbLtghETUg0N3s3K1VongqzV4We8PIHSi81 48u07NhClonqpT2KcNvm3CQh7PVXpV35iqxa7LRPvWG+88QWSvemHtnwPE5Ug1GB++3655Wm K/R3nxXqF+ET8J/R06GsxFKckWioxVxUnAgAUNIFkTYCAAA= Cc: "" Subject: Re: [mdnsext] shift from mdns to xmdns X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 05:28:35 -0000 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 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C1721F86A9 for ; Tue, 13 Nov 2012 09:43:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvUk2XjMhjn1 for ; Tue, 13 Nov 2012 09:43:22 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7664821F86A4 for ; Tue, 13 Nov 2012 09:43:21 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id ef5so837391obb.31 for ; Tue, 13 Nov 2012 09:43:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=aFpy22xMTM11hHG8wa+Nd0PufT3Uj/VUxIp8VdovPsU=; b=C1P1yDN7LeNnpgZEnKc7OLbQoq6rpQBNIde5rr42zhl3frofOZT66Vy8JqK2B4qoXH 2JaM5thfkt+iLcAQAoiXWhu5IJ6UWXdNJGORjozcqJ2grjYGhINzRLbtjrDNwEiLbvU3 VU2VqqJaMhNPhnaTE41pYfHO7S4aUI39UKwRtsz0HMK8wnlPHBqHdpPJAFdPJbChNvCY KcGyjS5jY0G+26tG2t8o9Zt239wQr8KOETn71gMSdTeJpK6ZxijsYuHE5iZWx+uIlE10 kiopMGxJN2usAM0N4oCJYOkyWDjMeEmxaf9V92+YA9chWgaSmTw2K6WgB6Qy01bSxhIA R9aQ== MIME-Version: 1.0 Received: by 10.60.14.200 with SMTP id r8mr18374103oec.45.1352828598934; Tue, 13 Nov 2012 09:43:18 -0800 (PST) Received: by 10.182.217.8 with HTTP; Tue, 13 Nov 2012 09:43:18 -0800 (PST) Date: Tue, 13 Nov 2012 12:43:18 -0500 Message-ID: From: Indtiny s To: "" Content-Type: multipart/alternative; boundary=e89a8fb201ca14dae904ce63f4f0 Subject: [mdnsext] shift from mdns to xmdns X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 17:43:23 -0000 --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,

Basically I am trying to bridge the gap between mdns= and xmdns on mdnsrespondr from apple , after going through the few documen= t=A0
=A0I got the the below things ,=A0
1.=A0Change=A0t= he mulitcast address from=A0224.0.0.251 to 224.0.0.x as per the some RFC=A0=
2. And=A0Hop=A0Limit/TTL to supporting RFC =A0values=A0
3. C= hange the local to site when supporting site TLD=A0

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 xm= dns ..?

Rgds
Indra=A0
--e89a8fb201ca14dae904ce63f4f0-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D487321F8479 for ; Tue, 13 Nov 2012 01:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpoSadWW87Zz for ; Tue, 13 Nov 2012 01:44:14 -0800 (PST) Received: from abulafia.free2air.net (abulafia.free2air.net [87.106.251.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5715421F8659 for ; Tue, 13 Nov 2012 01:44:12 -0800 (PST) Received: from host86-179-35-105.range86-179.btcentralplus.com ([86.179.35.105] helo=[192.168.1.64]) by abulafia.free2air.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1TYD2I-0002lM-IA; Tue, 13 Nov 2012 09:44:06 +0000 Message-ID: <50A21657.9070902@free2air.net> Date: Tue, 13 Nov 2012 09:43:51 +0000 From: Adam Burns Organization: free2air limited User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Evan Hunt References: <20121112201817.GD82038@mx1.yitter.info> <20121112212017.GA69203@isc.org> In-Reply-To: <20121112212017.GA69203@isc.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 16 Nov 2012 08:18:34 -0800 Cc: mdnsext@ietf.org, Andrew Sullivan Subject: Re: [mdnsext] mDNS relay agent idea X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 09:45:55 -0000 > 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. > Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6384221F859C for ; Mon, 12 Nov 2012 15:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lhJ6TAS3pa3 for ; Mon, 12 Nov 2012 15:51:51 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3D05721F858A for ; Mon, 12 Nov 2012 15:51:51 -0800 (PST) Received: from sandelman.ca (wlan196.sandelman.ca [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTPS id 0383981AE; Mon, 12 Nov 2012 18:43:32 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 08A08CA0BC; Mon, 12 Nov 2012 18:51:50 -0500 (EST) From: Michael Richardson To: mdnsext@ietf.org In-reply-to: <56B81C8E-4FA5-460C-AAB0-A8F3CE48A6FC@gmail.com> References: <20121112201817.GD82038@mx1.yitter.info> <56B81C8E-4FA5-460C-AAB0-A8F3CE48A6FC@gmail.com> Comments: In-reply-to Ron J message dated "Mon, 12 Nov 2012 16:50:50 -0500." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 12 Nov 2012 18:51:49 -0500 Message-ID: <13482.1352764309@sandelman.ca> Sender: mcr@sandelman.ca Cc: Ron J , Andrew Sullivan Subject: Re: [mdnsext] mDNS relay agent idea X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:51:52 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ron" =3D=3D Ron J 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.=20 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.=20 AirPlay either has user authentication, or it doesn't. Finding the TV or not doesn't change that. =20 =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQoYuVAAoJEKD0KQ7Gj3P20ToH/RFQW76mwNlGofxUxqbeTiUH zcximPVkkl/IXih9us3sIz1tjO7UZ+dQJEdhbkkh9yaHrhfjG10eVOdURoxJ5nTa d7JKXt3LJqucveq6YeeM/8HAwR/S7Ze0KDUKCeDXGVv3U4J28lsDeCJaDnGOE4Mm owFlnINE+RjYjBXY0/EEBTLlz3u79VqGSe4aCqT1jdx45bqh+vWmz22+9KjKpy50 D7mXjIbEpHefrtoO/UdN5E2I+/RE0V67LzkHobmTmkhq1KVkUqTj6hXL6eCUgACT uAqCOi+NERQpLoIE+038Fe1RO6FUrHL/xsWpx2ZMg8TNpdABbuFSoHp+T0xEfEE= =1fMZ -----END PGP SIGNATURE----- --=-=-=-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A8E21F8794 for ; Mon, 12 Nov 2012 15:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i81Bm0ji69T7 for ; Mon, 12 Nov 2012 15:47:24 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9D13D21F86D3 for ; Mon, 12 Nov 2012 15:47:24 -0800 (PST) Received: from sandelman.ca (wlan196.sandelman.ca [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTPS id 2354281A9; Mon, 12 Nov 2012 18:39:04 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8A9ECCA0BC; Mon, 12 Nov 2012 18:47:21 -0500 (EST) From: Michael Richardson To: "mdnsext@ietf.org" In-reply-to: References: <9203.1352743070@sandelman.ca> Comments: In-reply-to "Dan Harkins" message dated "Mon, 12 Nov 2012 10:12:05 -0800." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 12 Nov 2012 18:47:21 -0500 Message-ID: <13315.1352764041@sandelman.ca> Sender: mcr@sandelman.ca Cc: Dan Harkins Subject: Re: [mdnsext] mDNS relay agent idea X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:47:25 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Dan" =3D=3D Dan Harkins writes: >>=20 >> In addition to caching the service discovery, do any of the various >> products also provide proxying of the service itself, and/or providi= ng >> 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? =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQoYqJAAoJEKD0KQ7Gj3P2DQYH+gMDyTgfD8vOY45FK5JhlIRq /3wfurnIQ2TLEoASIIe6Eco+DmoG9fbHRL2vXPvp+3U7d5MEJcSyv1uHaDNQMitx DA9s6kipK9mjutybQB4XkdoRm7ooHmurcVeZXu53FRrk+aWIHNKuydYX7/M7+VTo Y/cLFwhPZ9D3P3R9YIim/1vus/sCFiEUaTJb9xQuoaai6sVvrcGQJSuxgFY+KYKq JEHA80TUrR7/+JCdGxE6XsKfMiKpZ/R0FnuvrlEeoXfe5m47KVkAgT6G6Dcp6mPD j6Xc4BCh038nl9jhM6Xd+8yrtj+2YEgIEVik4qQuyEpRXEFHhWvOCJvCt7zadGo= =ZZsV -----END PGP SIGNATURE----- --=-=-=-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA36D21F85A8 for ; Mon, 12 Nov 2012 14:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itaf1hwXfEaL for ; Mon, 12 Nov 2012 14:50:51 -0800 (PST) Received: from ITSNT447.iowa.uiowa.edu (itsnt447.iowa.uiowa.edu [128.255.67.11]) by ietfa.amsl.com (Postfix) with ESMTP id BA94221F8576 for ; Mon, 12 Nov 2012 14:50:45 -0800 (PST) Received: from ITSNT441.iowa.uiowa.edu ([169.254.3.228]) by ITSNT447.iowa.uiowa.edu ([128.255.67.11]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 16:50:44 -0600 From: "Johnson, Neil M" To: Ron J Thread-Topic: [mdnsext] mDNS relay agent idea Thread-Index: Ac2+u1fg6ZQpKeiaTpOwPU+MQ5VgBgCicxyAAAM7dwD//5HwgIAAdp8A//+S0gA= Date: Mon, 12 Nov 2012 22:50:43 +0000 Message-ID: In-Reply-To: <4DF5B8E9-BE0D-4264-BDFE-EB07FB828489@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.255.6.15] Content-Type: text/plain; charset="us-ascii" Content-ID: <52C98342F0F47A4EAC48B29DEF8F8126@mailhost6.uiowa.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] mDNS relay agent idea X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:50:53 -0000 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 --=20 Neil Johnson Network Engineer The University of Iowa Phone: 319 384-0938 Fax: 319 335-2951 Mobile: 319 540-2081 E-Mail: neil-johnson@uiowa.edu On 11/12/12 4:21 PM, "Ron J" 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" >wrote: > >>=20 >> 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. >>=20 >> 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"). >>=20 >> -Neil >>=20 >> --=20 >> Neil Johnson >> Network Engineer >> The University of Iowa >> Phone: 319 384-0938 >> Fax: 319 335-2951 >> Mobile: 319 540-2081 >> E-Mail: neil-johnson@uiowa.edu >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 11/12/12 3:50 PM, "Ron J" wrote: >>=20 >>> 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. >>>=20 >>> 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). >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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 >>>=20 >>> 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). >>>=20 >>> OR >>>=20 >>> 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). >>>=20 >>>=20 >>> (if i've mixed up my networking terminology, please excuse me -- i'm >>>not >>> quite a network guru, hopefully you understand what i mean) >>>=20 >>> - Ron J >>> NCSU, OIT ClassTech >>>=20 >>>=20 >>> On Nov 12, 2012, at 3:18 PM, Andrew Sullivan >>> wrote: >>>=20 >>>> Hi, >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> Best, >>>>=20 >>>> A >>>>=20 >>>>=20 >>>> --=20 >>>> Andrew Sullivan >>>> ajs@anvilwalrusden.com >>>> _______________________________________________ >>>> mdnsext mailing list >>>> mdnsext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mdnsext >>>=20 >>> _______________________________________________ >>> mdnsext mailing list >>> mdnsext@ietf.org >>> https://www.ietf.org/mailman/listinfo/mdnsext >>=20 > Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D10421F854C for ; Mon, 12 Nov 2012 14:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7StluZ1KTDks for ; Mon, 12 Nov 2012 14:21:13 -0800 (PST) Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 60D6421F84EE for ; Mon, 12 Nov 2012 14:21:13 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id 56so1375050yhq.31 for ; Mon, 12 Nov 2012 14:21:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=xZbExS8YZnI6+QGHrn3u0Wl2vdgJ9lxpaiGhmIBh6fM=; b=wZTYBfN92O2PzNeGGP9ZcwW8qxqQSDDsQJI9zxzp9Xd/hkTHaWWdcQqIGOJ3fb8qTF QDmfc8kAZxq7CYumc5tUvbW/3lpkfAlIHBMz4L+3ketrB7dwmaVD5top0k4q5UP24mtk ymIStxcI7Vi+JIQ6F8bNLeN1rmrt6v3dw4V9UJkS53tNoQHNM1H435ed/W4rLi2Cqcje +38o9ara0wwnsAiu7WISIkYj9wa3pLfyAyu6YkO5RCNKwdeSv3Hy+0jCZyoCXMfWCgGH Y8EUtOlD9Ufbe/AeSQ24toEviNupAaIiJ83rb1c77+Njh/n6ONYF28v0oBrvOlXLf7bV mFuQ== Received: by 10.236.151.13 with SMTP id a13mr14819169yhk.53.1352758872880; Mon, 12 Nov 2012 14:21:12 -0800 (PST) Received: from nom0045706.nomadic.ncsu.edu (nom0045706.nomadic.ncsu.edu. [152.14.178.76]) by mx.google.com with ESMTPS id h22sm8010428yhk.13.2012.11.12.14.21.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 14:21:12 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ron J In-Reply-To: Date: Mon, 12 Nov 2012 17:21:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4DF5B8E9-BE0D-4264-BDFE-EB07FB828489@gmail.com> References: To: "Johnson, Neil M" X-Mailer: Apple Mail (2.1499) Cc: mdnsext@ietf.org Subject: Re: [mdnsext] mDNS relay agent idea X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:21:14 -0000 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" = wrote: >=20 > 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. >=20 > 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"). >=20 > -Neil >=20 > --=20 > Neil Johnson > Network Engineer > The University of Iowa > Phone: 319 384-0938 > Fax: 319 335-2951 > Mobile: 319 540-2081 > E-Mail: neil-johnson@uiowa.edu >=20 >=20 >=20 >=20 >=20 >=20 > On 11/12/12 3:50 PM, "Ron J" wrote: >=20 >> 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. >>=20 >> 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). >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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 >>=20 >> 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). >>=20 >> OR >>=20 >> 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). >>=20 >>=20 >> (if i've mixed up my networking terminology, please excuse me -- i'm = not >> quite a network guru, hopefully you understand what i mean) >>=20 >> - Ron J >> NCSU, OIT ClassTech >>=20 >>=20 >> On Nov 12, 2012, at 3:18 PM, Andrew Sullivan >> wrote: >>=20 >>> Hi, >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Best, >>>=20 >>> A >>>=20 >>>=20 >>> --=20 >>> Andrew Sullivan >>> ajs@anvilwalrusden.com >>> _______________________________________________ >>> mdnsext mailing list >>> mdnsext@ietf.org >>> https://www.ietf.org/mailman/listinfo/mdnsext >>=20 >> _______________________________________________ >> mdnsext mailing list >> mdnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/mdnsext >=20 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E073F21F8681 for ; Mon, 12 Nov 2012 14:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWLvaHUnmeTO for ; Mon, 12 Nov 2012 14:17:12 -0800 (PST) Received: from itsnt427.iowa.uiowa.edu (itsnt427.iowa.uiowa.edu [128.255.6.109]) by ietfa.amsl.com (Postfix) with ESMTP id A019D21F860F for ; Mon, 12 Nov 2012 14:17:11 -0800 (PST) Received: from ITSNT441.iowa.uiowa.edu ([169.254.3.228]) by itsnt427.iowa.uiowa.edu ([128.255.6.109]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 16:16:57 -0600 From: "Johnson, Neil M" To: Ron J , Andrew Sullivan Thread-Topic: [mdnsext] mDNS relay agent idea Thread-Index: Ac2+u1fg6ZQpKeiaTpOwPU+MQ5VgBgCicxyAAAM7dwD//5HwgA== Date: Mon, 12 Nov 2012 22:16:56 +0000 Message-ID: In-Reply-To: <56B81C8E-4FA5-460C-AAB0-A8F3CE48A6FC@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.255.6.15] Content-Type: text/plain; charset="us-ascii" Content-ID: <342070B4702F1C44951F508ED0C03688@mailhost6.uiowa.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] mDNS relay agent idea X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:17:13 -0000 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 --=20 Neil Johnson Network Engineer The University of Iowa Phone: 319 384-0938 Fax: 319 335-2951 Mobile: 319 540-2081 E-Mail: neil-johnson@uiowa.edu On 11/12/12 3:50 PM, "Ron J" 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 >wrote: > >> Hi, >>=20 >> 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. >>=20 >> 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. >>=20 >> Best, >>=20 >> A >>=20 >>=20 >> --=20 >> Andrew Sullivan >> ajs@anvilwalrusden.com >> _______________________________________________ >> mdnsext mailing list >> mdnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/mdnsext > >_______________________________________________ >mdnsext mailing list >mdnsext@ietf.org >https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC4821F86D3 for ; Mon, 12 Nov 2012 13:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uIfcgzDOR-r for ; Mon, 12 Nov 2012 13:50:35 -0800 (PST) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9EB421F844D for ; Mon, 12 Nov 2012 13:50:34 -0800 (PST) Received: by mail-gg0-f172.google.com with SMTP id i4so1366994ggn.31 for ; Mon, 12 Nov 2012 13:50:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5P+al8ClgSHMnNa5RB6QgwnevIUMu9gnELEKuc66y5Q=; b=bjAALmBFWW1Fl0b4/vKRUtYRASPuC0VuLF1ljWVO0+2Eo1HrBxXY/TVmspJ66TOBxw LJU2HLEXbv8YRRI0rkDMmdcKTmyKu+CQ4K53sesVUvufDubpBTRMTynztnNI+cutF0+D pF/y7FP2OiWZLyE1/+FrL5HwTkEoKcwNNUx4YBmLn5nvl+HMbLcc92TFZ4xnsYqES6YZ P8DNwEj0QA3N+BavgPgLjd+jEEYX2D73YXD77dzrbjdTsSzo1GYkyb2jOIXwuZ3zipnV wrG8vvvOOW5TRup/ouaSOYlSW2fDRYGtIc+WxFlmaIOGK81RXaODLNA49gJWiZR68OvR p04Q== Received: by 10.236.92.6 with SMTP id i6mr21208842yhf.40.1352757034305; Mon, 12 Nov 2012 13:50:34 -0800 (PST) Received: from nom0045706.nomadic.ncsu.edu (nom0045706.nomadic.ncsu.edu. [152.14.178.76]) by mx.google.com with ESMTPS id n12sm7084456ani.7.2012.11.12.13.50.32 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Nov 2012 13:50:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ron J In-Reply-To: <20121112201817.GD82038@mx1.yitter.info> Date: Mon, 12 Nov 2012 16:50:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <56B81C8E-4FA5-460C-AAB0-A8F3CE48A6FC@gmail.com> References: <20121112201817.GD82038@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1499) Cc: mdnsext@ietf.org Subject: Re: [mdnsext] mDNS relay agent idea X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 21:50:36 -0000 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 = wrote: > Hi, >=20 > 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. >=20 > 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. >=20 > Best, >=20 > A >=20 >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06AC21F852E for ; Mon, 12 Nov 2012 13:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJrcU2UOyjhg for ; Mon, 12 Nov 2012 13:20:23 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 67AA921F8502 for ; Mon, 12 Nov 2012 13:20:23 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 66A05CAA7A; Mon, 12 Nov 2012 21:20:17 +0000 (UTC) (envelope-from each@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10292) id 5BF50216C83; Mon, 12 Nov 2012 21:20:17 +0000 (UTC) Date: Mon, 12 Nov 2012 21:20:17 +0000 From: Evan Hunt To: Andrew Sullivan Message-ID: <20121112212017.GA69203@isc.org> References: <20121112201817.GD82038@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121112201817.GD82038@mx1.yitter.info> User-Agent: Mutt/1.4.2.3i Cc: mdnsext@ietf.org Subject: Re: [mdnsext] mDNS relay agent idea X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 21:20:24 -0000 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 -- each@isc.org Internet Systems Consortium, Inc. Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC0C21F8682 for ; Mon, 12 Nov 2012 12:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CID6qDNmVL3R for ; Mon, 12 Nov 2012 12:18:22 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF5421F860F for ; Mon, 12 Nov 2012 12:18:22 -0800 (PST) Received: from mx1.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 19B9D8A031 for ; Mon, 12 Nov 2012 20:18:20 +0000 (UTC) Date: Mon, 12 Nov 2012 15:18:17 -0500 From: Andrew Sullivan To: mdnsext@ietf.org Message-ID: <20121112201817.GD82038@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mdnsext] mDNS relay agent idea X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 20:18:22 -0000 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 ajs@anvilwalrusden.com Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7C821F86D0 for ; Mon, 12 Nov 2012 12:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoT7Z-EnDSTr for ; Mon, 12 Nov 2012 12:07:53 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E431C21F869C for ; Mon, 12 Nov 2012 12:07:52 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so2873716eaa.31 for ; Mon, 12 Nov 2012 12:07:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wzQ31FtK8bXmt0Of0bq3NWL4QCrrhYzf2QwRjKJr8tA=; b=zv0Hkq5Sb3vPA/P9c9mxMAuOcEJyvo/JINml4xefcIbsdeIQvVW2QJ8+hp0hEyvP4V tBLkU0rg6R9pYBo18E2SF9MoNST00DpbwN7YjcR+6DDttZZhGPIW9mrYlnJDGwyam/wd ehPD3AHGTKrnrcAViBC4f4pvH25TyL9JXEfco8rOts/W0PDGIYxBJc/3u4tQfd3S6sOh ZB5/ev+pyRLTwVK88gQwNCJpQxMaIVh28V6WeXb3uLUG87D0lZso2ctsBxhvvKBVoffk nVmv7oCUxfu9+sbk4Bn7p23kDcwyEHk87+ffyqoq/rQCOwXWCev2A0NBe8XrWgr6Ns83 dmcA== MIME-Version: 1.0 Received: by 10.14.174.194 with SMTP id x42mr66755973eel.22.1352750872141; Mon, 12 Nov 2012 12:07:52 -0800 (PST) Received: by 10.223.145.133 with HTTP; Mon, 12 Nov 2012 12:07:52 -0800 (PST) In-Reply-To: <242466A9-017E-4311-AA03-EA35C3F8964A@gmail.com> References: <242466A9-017E-4311-AA03-EA35C3F8964A@gmail.com> Date: Mon, 12 Nov 2012 15:07:52 -0500 Message-ID: From: Brian Dickson To: Ran Atkinson Content-Type: multipart/alternative; boundary=047d7b621ede341d7504ce51db8a Cc: mdnsext@ietf.org Subject: Re: [mdnsext] Architecture for multi-hop Service Discovery X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 20:07:54 -0000 --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 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 > mdnsext@ietf.org > 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:
http://netatalk.sourceforge.net/<= /div>

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

Used this a long time= ago, extensively.

Yes, avoiding reinventing the wheel is highly recommend= ed.

Brian

On Sat= , Nov 10, 2012 at 8:40 AM, Ran Atkinson <ran.atkinson@gmail.com&g= t; 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
mdnsext@ietf.org
https://www.ietf.org/mailman/listinfo/mdnsext

--047d7b621ede341d7504ce51db8a-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585CD21F875C for ; Mon, 12 Nov 2012 11:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.085 X-Spam-Level: X-Spam-Status: No, score=-1.085 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZPR0r5J0xHZ for ; Mon, 12 Nov 2012 11:59:41 -0800 (PST) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) by ietfa.amsl.com (Postfix) with ESMTP id E793B21F8740 for ; Mon, 12 Nov 2012 11:59:40 -0800 (PST) Received: from [172.16.10.3] (cpe-071-070-157-071.nc.res.rr.com [71.70.157.71]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 1DAC71102C; Mon, 12 Nov 2012 14:57:12 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tom Pusateri In-Reply-To: Date: Mon, 12 Nov 2012 14:59:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Johnson, Neil M" X-Mailer: Apple Mail (2.1499) Cc: Sebastian Hagedorn , "mdnsext@ietf.org" Subject: Re: [mdnsext] Forwarding link-local IP multicast X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 19:59:41 -0000 On Nov 12, 2012, at 1:37 PM, "Johnson, Neil M" = wrote: >=20 > 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). >=20 > 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". >=20 > -Neil >=20 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 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE3721F8652 for ; Mon, 12 Nov 2012 10:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKn2RZJ1fm+M for ; Mon, 12 Nov 2012 10:37:25 -0800 (PST) Received: from ITSNT447.iowa.uiowa.edu (itsnt447.iowa.uiowa.edu [128.255.67.11]) by ietfa.amsl.com (Postfix) with ESMTP id AF3E921F851C for ; Mon, 12 Nov 2012 10:37:25 -0800 (PST) Received: from ITSNT441.iowa.uiowa.edu ([169.254.3.228]) by ITSNT447.iowa.uiowa.edu ([128.255.67.11]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 12:37:24 -0600 From: "Johnson, Neil M" To: Sebastian Hagedorn Thread-Topic: [mdnsext] Forwarding link-local IP multicast Thread-Index: AQHNvHE0UHB+aCLDR0G0552LUJrx4ZffFHyAgABAoICAAQxQgIABzv4A//+QGgCAAXGOgIADTckA Date: Mon, 12 Nov 2012 18:37:23 +0000 Message-ID: In-Reply-To: <3A394608C8F55792A28FA079@vpn82-165.vpn.uni-koeln.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.255.6.15] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0DCFCA9DB21BDF419BFC26655F96AEE7@mailhost6.uiowa.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] Forwarding link-local IP multicast X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:37:26 -0000 I don't know about using a router for anything too complicated. Our core routers have CPU issues as it is (looking to upgrade this year). I could see the router advertising (via mDNS) the location(s) of a box(es) that services on the local link could then "register" with and or "query". -Neil --=20 Neil Johnson Network Engineer The University of Iowa Phone: 319 384-0938 Fax: 319 335-2951 Mobile: 319 540-2081 E-Mail: neil-johnson@uiowa.edu On 11/10/12 3:10 AM, "Sebastian Hagedorn" 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=E4t zu K=F6ln / Cologne University - Tel. +49-221-470-89578 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85EE21F85AF for ; Mon, 12 Nov 2012 10:12:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzKYoD-1FgtQ for ; Mon, 12 Nov 2012 10:12:05 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 78D8121F8598 for ; Mon, 12 Nov 2012 10:12:05 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1D4031022400A; Mon, 12 Nov 2012 10:12:05 -0800 (PST) Received: from 50.84.73.44 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 12 Nov 2012 10:12:05 -0800 (PST) Message-ID: In-Reply-To: <9203.1352743070@sandelman.ca> References: <9203.1352743070@sandelman.ca> Date: Mon, 12 Nov 2012 10:12:05 -0800 (PST) From: "Dan Harkins" To: "Michael Richardson" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] mDNS relay agent idea X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:12:06 -0000 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 > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext > Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7883421F8679 for ; Mon, 12 Nov 2012 09:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfCoJQU3j-6x for ; Mon, 12 Nov 2012 09:57:55 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB3021F874A for ; Mon, 12 Nov 2012 09:57:53 -0800 (PST) Received: from sandelman.ca (unknown [75.98.19.132]) by relay.sandelman.ca (Postfix) with ESMTPS id 4E55581A9 for ; Mon, 12 Nov 2012 12:49:34 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 77191CA0BC for ; Mon, 12 Nov 2012 12:57:50 -0500 (EST) From: Michael Richardson To: "mdnsext@ietf.org" In-reply-to: References: Comments: In-reply-to Matthew Gast message dated "Sat, 10 Nov 2012 03:46:11 +0000." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 12 Nov 2012 12:57:50 -0500 Message-ID: <9203.1352743070@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [mdnsext] mDNS relay agent idea X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 17:57:57 -0000 --=-=-= 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) =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQoTieAAoJEKD0KQ7Gj3P2FFoH/jcooFP8TfYVMzCAQmchZ0fR 7P3WuQXODQWaHkk0WCxttGnzeKadtKrdt0mGA7FuCu1lDfgCLN5ehAIzuhie1syf wwmFYs82HMaU4HLxXK5aZZFwFpGQh/LpB2V6qAOp5EOM3NJdjnhSW+9PurvADZQ8 zb5MqqfrLRGxsRQy692iNHJZNrX/ajH1WUSYgTkXKIw4ClmPl2VaOveFsK29dEZ9 PHEvVJA/J85yQMtlz4c/78UYFpxkJfWQjOHO9P7vB/U5ZeqxLOrTMN6nvYBWvPk1 WljMaRK1C46vJexbltWm3CiRT8flJnpizR0c572FhyYT2OiGP+JHxXfcog2ruaY= =N1BR -----END PGP SIGNATURE----- --=-=-=-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5981621F8475 for ; Mon, 12 Nov 2012 04:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qd4PYacTaLJ9 for ; Mon, 12 Nov 2012 04:26:54 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id 9F87521F849A for ; Mon, 12 Nov 2012 04:26:54 -0800 (PST) Received: from USSC-CASHT-P3.corp.extremenetworks.com (10.0.4.78) by ussc-casht-p2.corp.extremenetworks.com (10.255.181.88) with Microsoft SMTP Server (TLS) id 8.3.264.0; Mon, 12 Nov 2012 04:26:49 -0800 Received: from nlut-casht-p1.corp.extremenetworks.com (10.112.1.70) by ussc-casht-p3.corp.extremenetworks.com (10.0.4.78) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 12 Nov 2012 04:26:48 -0800 Received: from NLEXCHANGE.corp.extremenetworks.com ([10.112.1.63]) by nlut-casht-p1.corp.extremenetworks.com ([192.168.250.4]) with mapi; Mon, 12 Nov 2012 13:26:46 +0100 From: Eelco Chaudron To: Matthew Gast Date: Mon, 12 Nov 2012 13:26:46 +0100 Thread-Topic: [mdnsext] mDNS relay agent idea Thread-Index: Ac3A0PsKdpRO4HVFRteYHDMUKf3gsA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] mDNS relay agent idea X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 12:26:55 -0000 DQo+IENhY2hpbmcgc2VydmljZXMgaXMgcHJvYmFibHkgbm90IG9wdGltYWwsIHRob3VnaCwgc2lu Y2Ugc2VydmljZXMgY2FuIGNvbWUNCj4gYW5kIGdvIGFuZCB0aGUgREYgbWF5IG5vdCBnZXQgaW1t ZWRpYXRlIHVwZGF0ZXMuICBNYWludGFpbmluZyBzdGF0ZSBhdCB0aGUNCj4gREYgcHJvYmFibHkg Y29uc3VtZXMgc29tZSBhbW91bnQgb2YgbmV0d29yayBjYXBhY2l0eTsgbW9yZSBpbXBvcnRhbnRs eSwgREYNCj4gY2FjaGUgbWFpbnRlbmFuY2UgcGluZ2luZyBhd2F5IGF0IHRoZSBuZXR3b3JrIG1h eSBvYnN0cnVjdCBwb3dlci1zYXZpbmcNCj4gb3BlcmF0aW9ucy4NCg0KWWVzLCB0aGlzIG1pZ2h0 IGJlIGEgYml0IGN1bWJlcnNvbWUgd2hlbiBzZXJ2aWNlcyBhcmUgaW5zdGFudGx5IHJlbW92ZWQg KHBvd2VyIGRvd24gb2YgYSBwcmludGVyKS4gQnV0IEkgZ3Vlc3MgdGhpcyBpc3N1ZSBleGlzdHMg d2l0aCB0aGUgd2lkZSBhcmVhIEROUyBhcHByb2FjaCBiZWNhdXNlIHNlcnZpY2Ugd2lsbCBuZWVk IHRvIHRpbWVvdXQgYWxzby4NCg0KPg0KPiBJbiB5b3VyIHNpeHRoIHN0ZXAsIGlzIHRoZSAiRE5T IChzZXJ2aWNlKSBxdWVyeSIgYW4gbUROUyBxdWVyeSBvciBhDQo+IHVuaWNhc3QgcXVlcnk/ICBJ ZiB0aGUgZm9ybWVyLCBJIGxpa2UgdGhlIGltcGxpY2l0IHRyYW5zZm9ybWF0aW9uIG9mIGENCj4g bXVsdGljYXN0IHF1ZXJ5IGludG8gYSB1bmljYXN0IHJlc3BvbnNlIGZvciB3aXJlbGVzcyBMQU4g b3BlcmF0aW9ucywgYnV0DQo+IGl0IG1heSBpbXBlZGUgbWFpbnRlbmFuY2Ugb2YgbGluay1sb2Nh bCBzZXJ2aWNlIGxpc3RzIG9uIGFsbCBvdGhlcg0KPiBsaXN0ZW5lcnMuDQoNCkkgbWVhbnQgdG8g c2F5IG1ETlMsIGFuZCB5ZXMgdGhlIGlkZWEgd2FzIHRvIGZvcndhcmQgdGhlIG11bHRpY2FzdCwg dW5pY2FzdCB0byB0aGUgREZzLg0KDQoNCj4gT24gMTEvOS8xMiAxMjo0NiBQTSwgIkVlbGNvIENo YXVkcm9uIiA8ZWNoYXVkcm9uQGV4dHJlbWVuZXR3b3Jrcy5jb20+DQo+IHdyb3RlOg0KPg0KPj4g SW5saW5lIHdpdGggdGhlIG90aGVyIGVtYWlscyBzZW5kIGFyb3VuZCwgSSB3b3VsZCBzdWdnZXN0 IHVzaW5nIHNvbWV0aGluZw0KPj4gc2ltaWxhciB0byB0aGUgYm9vdHAgcmVsYXkgYXBwcm9hY2gu DQo+PiBXaGVyZSBhIHJlbGF5IGFnZW50IGNhbiB1bmljYXN0IGZvcndhcmQgdGhlIHNlcnZpY2Ug cmVxdWVzdCB0byBvdGhlcg0KPj4gbmV0d29yayBzZWdtZW50cy4gVGhpcyBzaG91bGQgYmUgZG9u ZSBpbiBzdWNoIGEgd2F5IGl0IHdpbGwgd29yayB3aXRoIGFsbA0KPj4gdGhlIGV4aXN0aW5nIG1E TlMgcXVlcmllciBjbGllbnRzIG91dCB0aGVyZS4NCj4+DQo+PiBUaGUgbUROUyByZWxheSBzZXJ2 aWNlIGNhbiBydW4gb24gYSBzd2l0Y2gsIHJvdXRlciwgb3IgcHVycG9zZWx5IGJ1aWxkDQo+PiBk ZXZpY2Uvc2VydmVyLCBhcyBsb25nIGFzIGl0IGhhcyBjb25uZWN0aW9ucyB0byBtdWx0aXBsZSBu ZXR3b3JrIHNlZ21lbnRzLg0KPj4gSGVyZSBhcmUgc29tZSBpZGVhcyB0aGF0IGNhbWUgdG8gbWlu ZCBkdXJpbmcgbXkgOCBob3VyIGZsaWdodCBiYWNrIGhvbWU6DQo+Pg0KPj4gLSBUaGUgcmVsYXkg YWdlbnQgd2lsbCBhZHZlcnRpc2UgaXTCuXMgc2VydmljZSBvbiBhbGwgdGhlIG5ldHdvcmsgc2Vn bWVudHMNCj4+IGNvbm5lY3RlZCB1c2luZyBtRE5TLg0KPj4gLSBBbGwgdGhlIHJlbGF5IGFnZW50 cyBvbiB0aGUgc2FtZSBzZWdtZW50IGNhbiB0aGFuIGZvcm0gYWRqYWNlbmNpZXMgYW5kDQo+PiBk ZXRlcm1pbmUgdGhlIGRlc2lnbmF0ZWQgZm9yd2FyZGVkIGZvciB0aGUgc2VnbWVudC4gVGhlIGFn ZW50IHdpdGggdGhlDQo+PiBtb3N0IGludGVyZmFjZXMgaGFzIHRoZSBoaWdoZXN0IHByaW9yaXR5 LCB0aWUgYnJlYWtlciBjb3VsZCBiZSB0aGUgSVANCj4+IGFkZHJlc3MuDQo+PiAtIEFsbCByZWxh eSBhZ2VudHMgaW4gdGhlIGRvbWFpbiBjYW4gZm9ybSBhZGphY2VuY2llcywgYW5kIGJ1aWxkIGEg bGluaw0KPj4gc3RhdGUgdGFibGUsIHNvIHRoZXkga25vdyBhbGwgcmVhY2hhYmxlIHNlZ21lbnRz IChhbmQgdGhlaXIgdW5pY2FzdCBERg0KPj4gYWRkcmVzcykNCj4+IC0gQWRqYWNlbmNpZXMgc2hv dWxkIGFsbG93IGZvciBwYWNrZXQgc2lnbmF0dXJlIG9wdGlvbiAoTUFDKSwgYnV0IHNob3VsZA0K Pj4gYmUgb2ZmIGJ5IGRlZmF1bHQNCj4+IC0gVGhlIGRlc2lnbmF0ZWQgZm9yd2FyZGVkIHdpbGwg YnVpbGQgYSBjYWNoZSBvZiBzZXJ2aWNlcyBmb3IgdGhlIHNlZ21lbnQNCj4+IGl0wrlzIHRoZSBk ZXNpZ25hdGVkIGZvcndhcmRlciBmb3IgKG90aGVycyBtaWdodCBhbHNvIGRvIHRoaXMgaW4gY2Fz ZSBvZg0KPj4gZmFpbHVyZSBvZiB0aGUgREYsIGJ1dCB0aGV5IHNob3VsZCBub3QgaW5jbHVkZSB0 aGUgZW50cmllcyBpbiBhIHJlc3BvbnNlDQo+PiB0byBhdm9pZCBkdXBsaWNhdGVzKS4NCj4+IC0g SWYgYSBERiBzZWVzIGEgRE5TIChzZXJ2aWNlKSBxdWVyeSBpdCB3aWxsIGZvcndhcmQgaXQgYXMg dW5pY2FzdCB0byBhbGwNCj4+IGtub3duIEZScy4gV2hvIHdpbGwgcmVwbHkgb24gYmVoYXZlIG9m IHRoZSBzZXJ2aWNlIHVzaW5nIHVuaWNhc3QuDQo+PiAtIE5vdGUgZm9yIHRoaXMgdG8gd29yayB0 aGUgc2VydmljZXMgc2hvdWxkIGJlIHJlYWNoYWJsZSB0cm91Z2ggdGhlDQo+PiByb3V0ZWQgbmV0 d29yay4gVGhpcyBzaG91bGQgYmUgdmVyaWZpZWQgaWYgYSByZWxheSBhZ2VudCBpcyBhbnN3ZXJp bmcgb24NCj4+IGJlaGF2ZSBvZiBhIHNlcnZpY2UuIEl0IGRvZXMgbm90IG1ha2Ugc2Vuc2UgdG8g cmVwbHkgd2l0aCBsaW5rIGxvY2FsDQo+PiBhZGRyZXNzZXMuDQo+Pg0KPj4NCj4+IE5vdGUgdGhh dCB0aGVzZSBhcmUgYWxsIHJhbmRvbSB0aG91Z2h0cywgYW5kIEkgd2FzIG5vdCB0aGlua2luZyBj bGVhciwNCj4+IGJ1dCBpdMK5cyBhIG5pY2UgZGlzY3Vzc2lvbiBzdGFydGVyIHRvIGdldCBzb21l IGFjdGl2aXR5IG9uIHRoZSBtYWlsaW5nDQo+PiBsaXN0IDspDQo+Pg0KPj4NCj4+IC8vRWVsY28N Cj4+DQo+Pg0KPj4gRElTQ0xBSU1FUjoNCj4+IFRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMgdG8gaXQgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZA0KPj4gcHJvcHJpZXRhcnkgbWF0 ZXJpYWwgYW5kIGlzIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 Lg0KPj4gQW55IHJldmlldywgdXNlLCBkaXNjbG9zdXJlLCBkaXN0cmlidXRpb24gb3IgY29weWlu ZyBvZiB0aGlzIHRyYW5zbWl0dGFsDQo+PiBpcyBwcm9oaWJpdGVkIGV4Y2VwdCBieSBvciBvbiBi ZWhhbGYgb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gIElmIHlvdQ0KPj4gaGF2ZSByZWNlaXZl ZCB0aGlzIHRyYW5zbWl0dGFsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k DQo+PiBkZXN0cm95IHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYW5kIGFsbCBjb3Bp ZXMsIHdoZXRoZXINCj4+IGVsZWN0cm9uaWMgb3IgcHJpbnRlZC4NCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBtZG5zZXh0IG1haWxpbmcgbGlz dA0KPj4gbWRuc2V4dEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tZG5zZXh0DQo+DQoNCkRJU0NMQUlNRVI6DQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0 dGFjaG1lbnRzIHRvIGl0IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJvcHJpZXRhcnkg bWF0ZXJpYWwgYW5kIGlzIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LiBBbnkgcmV2aWV3LCB1c2UsIGRpc2Nsb3N1cmUsIGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5n IG9mIHRoaXMgdHJhbnNtaXR0YWwgaXMgcHJvaGliaXRlZCBleGNlcHQgYnkgb3Igb24gYmVoYWxm IG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRy YW5zbWl0dGFsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlc3Ryb3kg dGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWxsIGNvcGllcywgd2hldGhlciBl bGVjdHJvbmljIG9yIHByaW50ZWQuDQo= Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7428D21F854B for ; Mon, 12 Nov 2012 03:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.551 X-Spam-Level: X-Spam-Status: No, score=-5.551 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGX1ZalkCjWS for ; Mon, 12 Nov 2012 03:06:22 -0800 (PST) Received: from smtp-out.rrz.uni-koeln.de (smtp-out.rrz.uni-koeln.de [134.95.19.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8C08021F84BC for ; Mon, 12 Nov 2012 03:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at uni-koeln.de Received: from smtp-auth.rrz.uni-koeln.de (smtp-auth.rrz.uni-koeln.de [134.95.19.93]) by smtp-out.rrz.uni-koeln.de (8.13.8/8.13.8) with ESMTP id qACB6CH5010920; Mon, 12 Nov 2012 12:06:12 +0100 X-AUTH-SIP: a0620@macbook-hg.rrz.uni-koeln.de [134.95.128.70] Received: from macbook-hg.rrz.uni-koeln.de (macbook-hg.rrz.uni-koeln.de [134.95.128.70]) (authenticated as user a0620 using DIGEST-MD5 bits=0) by smtp-auth.uni-koeln.de (8.13.8/8.13.8) with ESMTP id qACB6AVu016045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 12:06:11 +0100 Date: Mon, 12 Nov 2012 12:06:09 +0100 From: Sebastian Hagedorn To: Ran Atkinson Message-ID: <343F74EA8D77EF6748B2CA55@macbook-hg.rrz.uni-koeln.de> In-Reply-To: <242466A9-017E-4311-AA03-EA35C3F8964A@gmail.com> References: <242466A9-017E-4311-AA03-EA35C3F8964A@gmail.com> X-Mailer: Mulberry/4.0.9b1 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========7E449C46788008DA5B49==========" X-Scanned-By: MIMEDefang 2.73 Cc: mdnsext@ietf.org Subject: Re: [mdnsext] Architecture for multi-hop Service Discovery X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 11:06:22 -0000 --==========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 = 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=20 AppleTalk only worked so well because the world was a different place. In=20 our campus network you were able to see and print to every=20 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.=20 Zerconf doesn't have that so far, because it was always intended to be=20 link-local, but if it is to be extended to the campus, that's definitely a=20 requirement. --=20 .:.Sebastian Hagedorn - RZKR, Weyertal 121 (Geb=E4ude 133), Z. 2.02.:. .:.Universit=E4t zu K=F6ln / Cologne University - Tel. +49-221-470-89578.:. --==========7E449C46788008DA5B49========== Content-Type: application/pkcs7-signature Content-Transfer-Encoding: base64 MIIUqAYJKoZIhvcNAQcCoIIUmTCCFJUCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCEhMwggU5MIIEIaADAgECAgQOtLhdMA0GCSqGSIb3DQEBBQUAMHkxCzAJ BgNVBAYTAkRFMQ4wDAYDVQQHEwVLb2VsbjEeMBwGA1UEChMVVW5pdmVyc2l0YWV0 IHp1IEtvZWxuMRQwEgYDVQQDEwtVbmlLb2VsbiBDQTEkMCIGCSqGSIb3DQEJARYV Y2FtYXN0ZXJAdW5pLWtvZWxuLmRlMB4XDTA5MDgyNjEzMzgyMVoXDTEyMDgyNTEz MzgyMVowcDELMAkGA1UEBhMCREUxDjAMBgNVBAcTBUtvZWxuMR4wHAYDVQQKExVV bml2ZXJzaXRhZXQgenUgS29lbG4xFDASBgNVBAsTC1JSWkssIE5ldHplMRswGQYD VQQDExJTZWJhc3RpYW4gSGFnZWRvcm4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCvbrQcOH3+9/Pk2gOBHTD8neKH/ULtE2NJs3hdFgc1Zy8JiSPcQ1is E1zHaiX1RANfhWNu2fCMk1rgmlsJAq0K3YShGxdTzD36tTKKM3i+CEoNPLmWik0x +RWK5d/lSez3WGludxvjICAQsDBuFxok5AdtQcVgv2+PPBbjw8YiJhHyWiVcG0iR 3xE3ExWARR6UAhkQiR8MMD+bCDaSPrmv7O9oEkB3BOxY40cyFTzskb2H68MrCX8S HzHw9lcoE3xBvFEySKGOnJEProhE/x619FDRyXpmw6XqFGmBBufmGc1ymYZclVcl uvBsInBRUumjW6yxlnqEfg7PzVRdJAWpAgMBAAGjggHQMIIBzDAJBgNVHRMEAjAA MAsGA1UdDwQEAwIF4DApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcUAgIwHQYDVR0OBBYEFFryMqfqZw/rn+SOR8hobWb3X/tmMB8GA1UdIwQY MBaAFCrqiesOstApxf75TKV23LdvTwm6MCAGA1UdEQQZMBeBFUhhZ2Vkb3JuQHVu aS1rb2Vsbi5kZTCBgwYDVR0fBHwwejA7oDmgN4Y1aHR0cDovL2NkcDEucGNhLmRm bi5kZS91bmkta29lbG4tY2EvcHViL2NybC9jYWNybC5jcmwwO6A5oDeGNWh0dHA6 Ly9jZHAyLnBjYS5kZm4uZGUvdW5pLWtvZWxuLWNhL3B1Yi9jcmwvY2FjcmwuY3Js MIGeBggrBgEFBQcBAQSBkTCBjjBFBggrBgEFBQcwAoY5aHR0cDovL2NkcDEucGNh LmRmbi5kZS91bmkta29lbG4tY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEUGCCsG AQUFBzAChjlodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3VuaS1rb2Vsbi1jYS9wdWIv Y2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEFBQADggEBAEAQjwt/trFejwkc b0ZDFda7WWMZ48/a6kyXtDOzQwa82HSM77/hE2lRvryWx7oEW6D9Z84nI1AmjSxb fJI733ASHvw/VyA8mXf9/HRzCIMpiH9Zuk3kBqx6bezVRjL4gprvwP4ApUVPzH5A GGF/iEJl09kO6Cjv5VfbhJubucWJzsgmKuZfmfaHOOQ9uNcVqznmseMbkfVeICMy XfxA4+y5v8w65hb+EFP1rQXwf8csDxN48/g8KOmzOcwYd2+4cNz7vUIduQXUXhsc C+zO8gIZeDdAcDgAxGTGklwkGcuYfrQyJywSCz2GyiKK0Jk9maIKPooRSl7QuG5u q8p2A6swggUKMIID8qADAgECAgQKRUldMA0GCSqGSIb3DQEBBQUAMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJMSQw IgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwHhcNMDcwNDE4MDc0 MjA3WhcNMTkwNDE3MDAwMDAwWjB5MQswCQYDVQQGEwJERTEOMAwGA1UEBxMFS29l bG4xHjAcBgNVBAoTFVVuaXZlcnNpdGFldCB6dSBLb2VsbjEUMBIGA1UEAxMLVW5p S29lbG4gQ0ExJDAiBgkqhkiG9w0BCQEWFWNhbWFzdGVyQHVuaS1rb2Vsbi5kZTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMvE96PdJusN/alR90nwwV4Y iLNM1ANMT2XN4MbfniygeGzgvMX7T8juVDw4H9LRtehfBvjPqMM7nth1RR5k/gSO yUyRUzcNLZS+UVu0bXARd1WckeS8moERrV+/3HMPqNCJuk67pLjowYw1psja4qsJ aT8yOhpbanc3mZIa9tq+d4mLZ0LvZVhuFxhbIdfl+f2agskQbbYbURcPLH/nsvKt vEnKDfcHeVJGX0hfR7ZBQhCe8XiKUNhKKdQV61UO71vw7dP3xzG8PQH3SnhZKTeY hCU7YgW82PXtv26DCDIg6iJyuODqLYwXTjc1601NoToDMN6WGGP0eC/fOnipm6MC AwEAAaOCAbcwggGzMBIGA1UdEwEB/wQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMB0G A1UdDgQWBBQq6onrDrLQKcX++Uyldty3b08JujAfBgNVHSMEGDAWgBRJt8bP6D0f f+pEexMp9/EKcD7eZDAgBgNVHREEGTAXgRVjYW1hc3RlckB1bmkta29lbG4uZGUw gYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2Jh bC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5w Y2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggr BgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5k ZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUH MAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCteobYEtkcfAeVJzUD m1S/4mRtTt8E6dKtsVHFVuHSc59Gco57ugZ5PxmzV8PU5Pq45KwYZ0zE8mchP5YO iE43bu4dSeDDcIjoh9l5VanjQ+kMM3qf/tv73bRwanUQIMsd3qYHseqsXusddJgX BLZOfs+/o2FCOQX5UucQBHSFGSOObUx6uYywKDT/lY+3mzAQiA35Df20bN3UCQpA ja3KDqeLRhL8YjTw+K1cU4UwH5G/hErxOsUzhf0aKhNv074cReDkPxpBHi9QhKpQ PBehI/0alzG27CIf2rkMBSXiIwUfKQWtBOOVnDftPTB17qFttkhK4MnIIYVBBKrb AeINMIIEITCCAwmgAwIBAgICAMcwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMC REUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVs ZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9v dCBDQSAyMB4XDTA2MTIxOTEwMjkwMFoXDTE5MDYzMDIzNTkwMFowWjELMAkGA1UE BhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAi BgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTU IOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFssoNTl7LZBF0O2gAHp8 v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90D8EJ ovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWG fW8zs9sPxRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDN SVTbyRM0mnF1xWzqpwuY+SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOB2TCB1jBw BgNVHR8EaTBnMGWgY6Bhhl9odHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9z ZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNybD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNz dWVyPURUX1JPT1RfQ0FfMjAdBgNVHQ4EFgQUSbfGz+g9H3/qRHsTKffxCnA+3mQw HwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQIwDQYJKoZIhvcNAQEFBQADggEBADvhWnfASBfc qRjsga9aifC9KJKmylkYEnDsKPLnrn+WLOfyXRkx9hMrdL29gLK592fJOaJ5O+ER Ee5reJEzfjtfJid1U2WOM2Puz3PDsJIjSSFQdSOhHxjilIU9PzPpdyCNor3moYUp QPY/czJYDQlrptqFbMA/u41mZFYkTq4NPzI1AVvpjILZcllPsYaF8XSFVuXD+Fzz je5Hs1MFcOflTYppgyjhEwmGnl7I6lgeDB/5pNRaBGj9KD6LArZYtfahLDdXAGer I2iNY6XvmWtc/UtW9qtAhzTUEZJs7IfFCgsHM3K0bwwdVCzYUcfMvzDTQ3LxMr+M zkljqAD38hwwggOfMIICh6ADAgECAgEmMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNV BAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZU LVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29t IFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0xOTA3MDkyMzU5MDBaMHExCzAJ BgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQL ExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQDExpEZXV0c2NoZSBUZWxl a29tIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKsL ozXgiykUsRSFrzwQ5DlvNV1Krt3qYY2VSfRvZKMaYGakqUAihNnUpeV4kw5oAa25 TVw6ztO4qEJA38+juoJZapIbrBya2ggrJSf5aSNH8eDrLHqb9RMC0H40fMKePABZ q/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rhWFgBSV9yQTwVBgGOXa2quJO0 zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5m1Xtrd8YCKCjhopJ7lMFjxlM 1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDikVCH4Z0K5q2X0h3GOn3LvNoD NNWOWwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0OBBYEFDHDeRu69VPXF+CJei0X bAqzK50zMA8GA1UdEwQIMAYBAf8CAQUwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3 DQEBBQUAA4IBAQCUZFmtOWTnKesT/lrDixNXyAQk8HR3wGDjZ/vpiaaDv5aCfG7U wz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLOF/Msx2I2VeIi2IlVtJhIqmT6 1hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU0nvSs6jicjytnv+AWeSbRbT2 O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+WWPg8oWIMVPUVBSFcHn0LgZ3 J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM1iPWHs/1aBtEY6Jauqc1WaHl cAWbDiNXmZQKbbo5YyiGkvMYhNj70c8FVmRXMYICXTCCAlkCAQEwgYEweTELMAkG A1UEBhMCREUxDjAMBgNVBAcTBUtvZWxuMR4wHAYDVQQKExVVbml2ZXJzaXRhZXQg enUgS29lbG4xFDASBgNVBAMTC1VuaUtvZWxuIENBMSQwIgYJKoZIhvcNAQkBFhVj YW1hc3RlckB1bmkta29lbG4uZGUCBA60uF0wCQYFKw4DAhoFAKCBsTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjExMTIxMTA2MDla MCMGCSqGSIb3DQEJBDEWBBQ9iXUf6YTkt5iWTyr4MOyWjk98oDBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQAxCVQT qJRvE8dBMuAKzwhS/k4f2gg+AyDIgDpugKI9Oheb4zLwmCqAsYHWA/UaQ5WMcmC1 GgXRtbafgQx2hkvpfrkLAhtulR3BF7VzduFlBQDD2+XNH78z87+sXLL6kzbPqsSE 3o4BCKvfbUGlcc2nRUa1FXyKTgpPSUCm0Fe+Fv0VUjy6NxZGSKgGkD8AeVUQSLW+ KOuhibh/jZhfS96f/XOn31rwNOVWAU0MIdsrVPFJcUJqIOGX/4koTCV6wroftzQU lEsJNTIWvhnfGzI5dSwE4P3MbiwPltyuCdxkz+FFTXzdtoRSaQ5g3KFi8kL9MULF at7bdyVGhcFul5c8 --==========7E449C46788008DA5B49==========-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220C221F8587 for ; Sat, 10 Nov 2012 05:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6JOQhHxZ0XZ for ; Sat, 10 Nov 2012 05:42:16 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C96E21F8529 for ; Sat, 10 Nov 2012 05:42:16 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so5342827vbb.31 for ; Sat, 10 Nov 2012 05:42:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=Vyiu7eepjhD/pIyTVyVi9N7J+WCjR/Ve6eHnSg8A+F4=; b=By7Jgd3RYkbq4X3CF44ilsVmS+3PGT9rWFPE9HjwvA0n7HlAZGUrrZH7V9jOwBq2Oi TRh1pnozEbwPlBH/4OkO37SoL6jyuwcysyxkjGIyRDK3pYAcaFq0GTSl4mHbDOtyayWe 5i5/yPTOQN2dJP4Z+wELodenMXlAZp1JHZ7//4O9fSq/b4O9YbhYuuAWesqVhxJeKK4J 7G8qfezF3w5cZWtb5L7nxnCfihmQyc5R8aF7DB1e+hQxRk7JfEdT6akDj+lb2byQ3f13 05XcK0qRdEUrdB/Tob5W0GFYoz80eZghbGEzxl407ZUEv/CThg7/IpzJbBgG53aKSxT/ 4XGg== Received: by 10.52.33.197 with SMTP id t5mr5411735vdi.91.1352554936041; Sat, 10 Nov 2012 05:42:16 -0800 (PST) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id xf2sm1307959vec.12.2012.11.10.05.42.14 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Nov 2012 05:42:15 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 10 Nov 2012 08:42:13 -0500 Message-Id: <43A83DF7-CA82-45FC-B708-99243315C865@gmail.com> To: mdnsext@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Sun, 11 Nov 2012 13:40:28 -0800 Subject: [mdnsext] Goals of this WG X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 13:42:17 -0000 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 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D9621F8528 for ; Sat, 10 Nov 2012 05:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uUkRIZ6Eiec for ; Sat, 10 Nov 2012 05:40:05 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 82EC521F851C for ; Sat, 10 Nov 2012 05:40:05 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so5341592vbb.31 for ; Sat, 10 Nov 2012 05:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=4BZkKPYY0WkaKfp82XyKwBFrnKczNwbwSv2uLVP77ic=; b=f6NoBw4cNjONK+Lrvg5VIMt0g/moxY7HHORh5OAFoPQe3z4MnPfjAOXBXesxF5U1fD 0v9vQ5fOL6jKSKoyFuM9LNUYKT6ITUMqlQcm9oMWz8MnovtCqMUhTWo/gz8e1lDGZ1Wm eoNRuW7W+d7xykJs6NdR+vD1i+GDZ9Au2joImD0U0arT6PHSQwQUVPy/DkLduTBHeJ8v Hfio03WBa7VvL2C3u3RRH3E3kuRJ8I8KLNfIzO4DL4r+sKJCbhT6UWvNJctWq8lVmovk dbapeBXTdKsKxYj/ZwTrpps7MDPseDeX534wXB6HgVsvqqeP6d4PU31TMrEkjNIGIdyp Unpw== Received: by 10.220.153.78 with SMTP id j14mr15033112vcw.33.1352554805030; Sat, 10 Nov 2012 05:40:05 -0800 (PST) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id y7sm1421913vdt.1.2012.11.10.05.40.04 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Nov 2012 05:40:04 -0800 (PST) From: Ran Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 10 Nov 2012 08:40:03 -0500 Message-Id: <242466A9-017E-4311-AA03-EA35C3F8964A@gmail.com> To: mdnsext@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Sun, 11 Nov 2012 13:40:28 -0800 Subject: [mdnsext] Architecture for multi-hop Service Discovery X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 13:40:06 -0000 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 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA2C21F85CE for ; Sat, 10 Nov 2012 05:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZskqKQJGYju for ; Sat, 10 Nov 2012 05:30:47 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6228C21F858B for ; Sat, 10 Nov 2012 05:30:47 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fc26so5336000vbb.31 for ; Sat, 10 Nov 2012 05:30:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=zLLzSRlLqzuxhOrF6G6HYgrKpf0NHiv7baZ0fnZZ9Cg=; b=xY+RZxDWZmnylSiHUW9IOg6Ya6+mPiMBXpwY2NofV2+hRa8iyPOXuhX2opYwOqycnJ 3WHwpqwQsHhgNDomxOOKXCZCJp0itc9sCiTikc7NRhSjs0X+LL+QBcOmGzyEsRiCUv3U Jh/ZpCucM+x1MAK62GYrVKVfIP5+zadz3cGfd4ApKbRweffnnmCTdHC3wrs2vr1ZhDmM 7MavHrt/7qlo50xEUKLQnv4lBot7lhdXr1thkC6CwJYs4+iGNGA21OUn82KasJSVQBwL CzHQ7JQ/fwFycyUmmmhbbo3ZPicoZUK6LwLTWAT7qBTy3p7giHhM32HS4PwRRkmaMA96 po3g== Received: by 10.52.17.19 with SMTP id k19mr13452062vdd.0.1352554246439; Sat, 10 Nov 2012 05:30:46 -0800 (PST) Received: from [10.30.20.14] (pool-74-110-100-136.nrflva.fios.verizon.net. [74.110.100.136]) by mx.google.com with ESMTPS id h4sm1382171vdv.17.2012.11.10.05.30.45 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Nov 2012 05:30:45 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 10 Nov 2012 08:30:44 -0500 Message-Id: <45DDF9BB-8D25-410B-8837-487954B2A135@gmail.com> To: mdnsext@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Sun, 11 Nov 2012 13:40:28 -0800 Subject: [mdnsext] Forwarding link-local IP multicast X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 13:30:48 -0000 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 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08FF21F84D6 for ; Sat, 10 Nov 2012 01:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhNnls+Ib5wI for ; Sat, 10 Nov 2012 01:10:19 -0800 (PST) Received: from smtp-out.rrz.uni-koeln.de (smtp-out.rrz.uni-koeln.de [134.95.19.53]) by ietfa.amsl.com (Postfix) with ESMTP id A043821F84C8 for ; Sat, 10 Nov 2012 01:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at uni-koeln.de Received: from smtp-auth.rrz.uni-koeln.de (smtp-auth.rrz.uni-koeln.de [134.95.19.93]) by smtp-out.rrz.uni-koeln.de (8.13.8/8.13.8) with ESMTP id qAA9ABxa032011; Sat, 10 Nov 2012 10:10:12 +0100 X-AUTH-SIP: a0620@vpn82-165.vpn.uni-koeln.de [134.95.82.165] Received: from vpn82-165.vpn.uni-koeln.de (vpn82-165.vpn.uni-koeln.de [134.95.82.165]) (authenticated as user a0620 using DIGEST-MD5 bits=0) by smtp-auth.uni-koeln.de (8.13.8/8.13.8) with ESMTP id qAA9ABE8024556; Sat, 10 Nov 2012 10:10:11 +0100 Date: Sat, 10 Nov 2012 10:10:11 +0100 From: Sebastian Hagedorn To: "Johnson, Neil M" Message-ID: <3A394608C8F55792A28FA079@vpn82-165.vpn.uni-koeln.de> In-Reply-To: References: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) Message-Context: text-message X-Spook: nuclear nuke spy secret assassination cia fbi nsa president MIME-Version: 1.0 Content-Type: multipart/signed; micalg=sha1; protocol="application/pkcs7-signature"; boundary="==========DC2DA39DDC2B408585D3==========" X-Scanned-By: MIMEDefang 2.73 Cc: mdnsext@ietf.org Subject: Re: [mdnsext] Forwarding link-local IP multicast X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 09:10:20 -0000 --==========DC2DA39DDC2B408585D3========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=753 > 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=C3=A4t zu K=C3=B6ln / Cologne University - Tel. +49-221-470-89578 --==========DC2DA39DDC2B408585D3========== Content-Type: application/pkcs7-signature Content-Transfer-Encoding: base64 MIIUvQYJKoZIhvcNAQcCoIIUrjCCFKoCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCEiUwggVLMIIEM6ADAgECAgcUMLfDetjLMA0GCSqGSIb3DQEBBQUAMHkx CzAJBgNVBAYTAkRFMQ4wDAYDVQQHEwVLb2VsbjEeMBwGA1UEChMVVW5pdmVyc2l0 YWV0IHp1IEtvZWxuMRQwEgYDVQQDEwtVbmlLb2VsbiBDQTEkMCIGCSqGSIb3DQEJ ARYVY2FtYXN0ZXJAdW5pLWtvZWxuLmRlMB4XDTEyMDcyNjEyMzgxMVoXDTE1MDcy NjEyMzgxMVowWjELMAkGA1UEBhMCREUxDjAMBgNVBAcTBUtvZWxuMR4wHAYDVQQK ExVVbml2ZXJzaXRhZXQgenUgS29lbG4xGzAZBgNVBAMTElNlYmFzdGlhbiBIYWdl ZG9ybjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM9wlsTG5uYWWLJw VaehPoH01FW00xWXIE2US9wkdKKISKPQKy74fpgNygeEydjDtng+4Y5nUVX1lmvG mialzMX9bMIsN9m6Xk070ILM2x6J8KgNxYcNZGaIGPe2MtEdBOMyeIEMlnGAJLwl 15sbLRuYbe2zob8KdwSGOnlaqxyfNjLnlOV2pb1euGgsh1A+amPxGOq7jTz7bxkx FrtaKtdHv63HSq/hUPQvdqyTpuD0eFOV/VMROS6q/pp9cN9ThgbnfScjANc82bHY +2OlIvVoOPn1jaVnM8J5ws32md1YDuFny72dgNJrjXCNBvH+xwgv8gk7lGNidWRX aDJ0YVsCAwEAAaOCAfUwggHxMC8GA1UdIAQoMCYwEQYPKwYBBAGBrSGCLAEBBAID MBEGDysGAQQBga0hgiwCAQQCAzAJBgNVHRMEAjAAMAsGA1UdDwQEAwIF4DAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFHSwDx/kDMvJlMr3 8a4SzOTxjHqXMB8GA1UdIwQYMBaAFCrqiesOstApxf75TKV23LdvTwm6MCAGA1Ud EQQZMBeBFUhhZ2Vkb3JuQHVuaS1rb2Vsbi5kZTCBgwYDVR0fBHwwejA7oDmgN4Y1 aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmkta29lbG4tY2EvcHViL2NybC9jYWNy bC5jcmwwO6A5oDeGNWh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvdW5pLWtvZWxuLWNh L3B1Yi9jcmwvY2FjcmwuY3JsMIGeBggrBgEFBQcBAQSBkTCBjjBFBggrBgEFBQcw AoY5aHR0cDovL2NkcDEucGNhLmRmbi5kZS91bmkta29lbG4tY2EvcHViL2NhY2Vy dC9jYWNlcnQuY3J0MEUGCCsGAQUFBzAChjlodHRwOi8vY2RwMi5wY2EuZGZuLmRl L3VuaS1rb2Vsbi1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEF BQADggEBADzWLnVebyc3HiC2Bew8ro5DEydAzM3ewqooCUSKaq/7Pdao8YPY42y9 nakJHn8ToR1e34AJUXRjkDg+eQ/t+SUFXdTN2ILh6Cj0+B6YiSZQakEJyRxnPs9+ TUXPiviwgxzqAFZ1VZ2VLdSF8Kp+YtBdIXSjCgntepx/GtvCSqOaZplpC9XTyuAu GQ1bm/cw5JmvpGCnGPe5aNSd9ELMxABCWpdRDobTnaLQ/NwTpDIRupG7MjOsWmQa fF1U3xvWKIBKJUDceRMt8H4ufi1RNR651E3Gj967ypcBG+2SDsgWNv+pp/OpcXfF 6XUzIBuAKJH83EqpoOkpwPQaM7Z/HwUwggUKMIID8qADAgECAgQKRUldMA0GCSqG SIb3DQEBBQUAMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAw DgYDVQQLEwdERk4tUEtJMSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwg LSBHMDEwHhcNMDcwNDE4MDc0MjA3WhcNMTkwNDE3MDAwMDAwWjB5MQswCQYDVQQG EwJERTEOMAwGA1UEBxMFS29lbG4xHjAcBgNVBAoTFVVuaXZlcnNpdGFldCB6dSBL b2VsbjEUMBIGA1UEAxMLVW5pS29lbG4gQ0ExJDAiBgkqhkiG9w0BCQEWFWNhbWFz dGVyQHVuaS1rb2Vsbi5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMvE96PdJusN/alR90nwwV4YiLNM1ANMT2XN4MbfniygeGzgvMX7T8juVDw4H9LR tehfBvjPqMM7nth1RR5k/gSOyUyRUzcNLZS+UVu0bXARd1WckeS8moERrV+/3HMP qNCJuk67pLjowYw1psja4qsJaT8yOhpbanc3mZIa9tq+d4mLZ0LvZVhuFxhbIdfl +f2agskQbbYbURcPLH/nsvKtvEnKDfcHeVJGX0hfR7ZBQhCe8XiKUNhKKdQV61UO 71vw7dP3xzG8PQH3SnhZKTeYhCU7YgW82PXtv26DCDIg6iJyuODqLYwXTjc1601N oToDMN6WGGP0eC/fOnipm6MCAwEAAaOCAbcwggGzMBIGA1UdEwEB/wQIMAYBAf8C AQEwCwYDVR0PBAQDAgEGMB0GA1UdDgQWBBQq6onrDrLQKcX++Uyldty3b08JujAf BgNVHSMEGDAWgBRJt8bP6D0ff+pEexMp9/EKcD7eZDAgBgNVHREEGTAXgRVjYW1h c3RlckB1bmkta29lbG4uZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2Rw MS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2g O6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9j cmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0 cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2Nh Y2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZ2xv YmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUA A4IBAQCteobYEtkcfAeVJzUDm1S/4mRtTt8E6dKtsVHFVuHSc59Gco57ugZ5Pxmz V8PU5Pq45KwYZ0zE8mchP5YOiE43bu4dSeDDcIjoh9l5VanjQ+kMM3qf/tv73bRw anUQIMsd3qYHseqsXusddJgXBLZOfs+/o2FCOQX5UucQBHSFGSOObUx6uYywKDT/ lY+3mzAQiA35Df20bN3UCQpAja3KDqeLRhL8YjTw+K1cU4UwH5G/hErxOsUzhf0a KhNv074cReDkPxpBHi9QhKpQPBehI/0alzG27CIf2rkMBSXiIwUfKQWtBOOVnDft PTB17qFttkhK4MnIIYVBBKrbAeINMIIEITCCAwmgAwIBAgICAMcwDQYJKoZIhvcN AQEFBQAwcTELMAkGA1UEBhMCREUxHDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20g QUcxHzAdBgNVBAsTFlQtVGVsZVNlYyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRl dXRzY2hlIFRlbGVrb20gUm9vdCBDQSAyMB4XDTA2MTIxOTEwMjkwMFoXDTE5MDYz MDIzNTkwMFowWjELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAO BgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAt IEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOmbw2eF+Q2u9Y1U w5ZQNT1i6W5M7ZTXAFuVInTUIOs0j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4 wXjLFssoNTl7LZBF0O2gAHp8v0oOGwDDhulcKzERewzzgiRDjBw4i2poAJru3E94 q9LGE5t2re7eJujvAa90D8EJovZrzr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJ IyqWNVgn03bGcbaQHcTt/zWGfW8zs9sPxRHCioOhlF1Ba9jSEPVM/cpRrNm975KD u9rrixZWVkPP4dUTPaYfJzDNSVTbyRM0mnF1xWzqpwuY+SGdJ68+ozk5SGqMrcmZ +8MS8r0CAwEAAaOB2TCB1jBwBgNVHR8EaTBnMGWgY6Bhhl9odHRwOi8vcGtpLnRl bGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNybD8tY3Js X2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjAdBgNVHQ4EFgQUSbfG z+g9H3/qRHsTKffxCnA+3mQwHwYDVR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMr nTMwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQIwDQYJKoZIhvcN AQEFBQADggEBADvhWnfASBfcqRjsga9aifC9KJKmylkYEnDsKPLnrn+WLOfyXRkx 9hMrdL29gLK592fJOaJ5O+EREe5reJEzfjtfJid1U2WOM2Puz3PDsJIjSSFQdSOh HxjilIU9PzPpdyCNor3moYUpQPY/czJYDQlrptqFbMA/u41mZFYkTq4NPzI1AVvp jILZcllPsYaF8XSFVuXD+Fzzje5Hs1MFcOflTYppgyjhEwmGnl7I6lgeDB/5pNRa BGj9KD6LArZYtfahLDdXAGerI2iNY6XvmWtc/UtW9qtAhzTUEZJs7IfFCgsHM3K0 bwwdVCzYUcfMvzDTQ3LxMr+MzkljqAD38hwwggOfMIICh6ADAgECAgEmMA0GCSqG SIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBUZWxl a29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw05OTA3MDkxMjExMDBaFw0x OTA3MDkyMzU5MDBaMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2NoZSBU ZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYD VQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAKsLozXgiykUsRSFrzwQ5DlvNV1Krt3qYY2VSfRvZKMa YGakqUAihNnUpeV4kw5oAa25TVw6ztO4qEJA38+juoJZapIbrBya2ggrJSf5aSNH 8eDrLHqb9RMC0H40fMKePABZq/XaDPUyPCusUNrWw96DlMqoDJkyDghIVltq+9rh WFgBSV9yQTwVBgGOXa2quJO0zZ7rp+hqLVI02zrvXHVR2tvzMfnucZgyxFQVRAz5 m1Xtrd8YCKCjhopJ7lMFjxlM1d5YeZvSahxCq8XVp89oD5bk4WGYdmHIkXzWPgDi kVCH4Z0K5q2X0h3GOn3LvNoDNNWOWwH1age3FrZuSn8CAwEAAaNCMEAwHQYDVR0O BBYEFDHDeRu69VPXF+CJei0XbAqzK50zMA8GA1UdEwQIMAYBAf8CAQUwDgYDVR0P AQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQCUZFmtOWTnKesT/lrDixNXyAQk 8HR3wGDjZ/vpiaaDv5aCfG7Uwz3vnoBuuym0mHqxO1TrORdHfhqOC/wfMVkxBLLO F/Msx2I2VeIi2IlVtJhIqmT61hw22ER4WlojOleX9XowT66fakxLK46gA+M+4KnU 0nvSs6jicjytnv+AWeSbRbT2O7DNORmYMuXqIWGQ5DEhjjSx9y81SoUQ2ueKNyG+ WWPg8oWIMVPUVBSFcHn0LgZ3J3UvH7iK+f7Futg25IPs52W3v2Na80avgZQ31EGM 1iPWHs/1aBtEY6Jauqc1WaHlcAWbDiNXmZQKbbo5YyiGkvMYhNj70c8FVmRXMYIC YDCCAlwCAQEwgYQweTELMAkGA1UEBhMCREUxDjAMBgNVBAcTBUtvZWxuMR4wHAYD VQQKExVVbml2ZXJzaXRhZXQgenUgS29lbG4xFDASBgNVBAMTC1VuaUtvZWxuIENB MSQwIgYJKoZIhvcNAQkBFhVjYW1hc3RlckB1bmkta29lbG4uZGUCBxQwt8N62Msw CQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xMjExMTAwOTEwMTFaMCMGCSqGSIb3DQEJBDEWBBT1jAuASt/F1A3T NMERuYBESux4yTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAN BgkqhkiG9w0BAQEFAASCAQC8Q0ZjoTHFEXYaeB4Upd1SlPqdU3xLZ92RaGK5IYrf aDIjc7FNWKHfVDkSfgkkPewTTHTRHIVo+OVbMOsVVGGpoSrbzD4X5igQhGmBINyK 8t08byKy2DhbdYVHGdN9Y4RDTFu8MP6tLuz84esiCsO/KVkEW1PStgY1AC5DbtCv dKS7aJEfUypDO1nF3yNTi0R5DFwhb2jvmSND336O2q/6/H24dfN2jSXDkzWDai2h lulH/FA+4Lot62DgFHrzP0TGcLdeo38KoPwJhhuGnMheuBrRHq+ipFqQagyPavZI Q0Ah5jt+eXG8x4gODvZwSx8RpFjiwzBS/CFW2NEff/vp --==========DC2DA39DDC2B408585D3==========-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE3721F84FF for ; Fri, 9 Nov 2012 19:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBNyjpK5F31v for ; Fri, 9 Nov 2012 19:58:09 -0800 (PST) Received: from mx1.aerohive.com (mx1.aerohive.com [209.128.117.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8127B21F84E6 for ; Fri, 9 Nov 2012 19:58:09 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx1.aerohive.com (Postfix) with ESMTP id 6CEC54D0254; Fri, 9 Nov 2012 19:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at aerohive.com Received: from mx1.aerohive.com ([127.0.0.1]) by localhost (mx1.aerohive.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tH0eTm30wuX; Fri, 9 Nov 2012 19:56:36 -0800 (PST) Received: from mail.aerohive.com (unknown [10.16.240.56]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.aerohive.com (Postfix) with ESMTP id 466E14D0263; Fri, 9 Nov 2012 19:56:36 -0800 (PST) Received: from HQ-MBX1.aerohive.com ([fe80::25ec:76f2:f1da:a517]) by hq-cas1.aerohive.com ([fe80::5199:67eb:c502:c65d%14]) with mapi id 14.02.0298.004; Fri, 9 Nov 2012 19:57:53 -0800 From: Matthew Gast To: "Johnson, Neil M" , Dan Harkins Thread-Topic: [mdnsext] Forwarding link-local IP multicast Thread-Index: AQHNvHEsRSHOddPWkkKf+CX6lMUDoJffNgOA//+fYwCAAa2NgIABSOAAgACLkwCAAB7RgA== Date: Sat, 10 Nov 2012 03:57:51 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [10.16.5.119] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org" , Tom Pusateri , Yi Yang Subject: Re: [mdnsext] Forwarding link-local IP multicast X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 03:58:10 -0000 Hi Neil, That's useful input on a real-world deployment scenario, especially since our big task right now is to write requirements. That sounds like "must support 1,000 links" (which I got by taking ~200 buildings with 3 wireless IP blocks and 2 wired IP blocks, since I had to start somewhere -- but please correct my wild-guess math if it's wrong). What other steps have you taken to get service discovery working across links on your campus that might offer lessons for our requirements doc? Matthew On 11/9/12 10:07 AM, "Johnson, Neil M" 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. >--=20 >Neil Johnson >Network Engineer >The University of Iowa >Phone: 319 384-0938 >Fax: 319 335-2951 >Mobile: 319 540-2081 >E-Mail: neil-johnson@uiowa.edu > > > > > > >On 11/9/12 11:48 AM, "Matthew Gast" wrote: > >>On 11/8/12 6:10 AM, "Dan Harkins" 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 >>mdnsext@ietf.org >>https://www.ietf.org/mailman/listinfo/mdnsext > >_______________________________________________ >mdnsext mailing list >mdnsext@ietf.org >https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98AA21F8604 for ; Fri, 9 Nov 2012 19:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzGmUsmvjPzK for ; Fri, 9 Nov 2012 19:46:28 -0800 (PST) Received: from mx1.aerohive.com (mx1.aerohive.com [209.128.117.80]) by ietfa.amsl.com (Postfix) with ESMTP id F14F921F85EE for ; Fri, 9 Nov 2012 19:46:27 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx1.aerohive.com (Postfix) with ESMTP id B64714D0263; Fri, 9 Nov 2012 19:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at aerohive.com Received: from mx1.aerohive.com ([127.0.0.1]) by localhost (mx1.aerohive.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XYKQvShwfwX; Fri, 9 Nov 2012 19:44:54 -0800 (PST) Received: from mail.aerohive.com (unknown [10.16.240.56]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.aerohive.com (Postfix) with ESMTP id 9C3724D0254; Fri, 9 Nov 2012 19:44:54 -0800 (PST) Received: from HQ-MBX1.aerohive.com ([fe80::25ec:76f2:f1da:a517]) by hq-cas1.aerohive.com ([fe80::5199:67eb:c502:c65d%14]) with mapi id 14.02.0298.004; Fri, 9 Nov 2012 19:46:11 -0800 From: Matthew Gast To: Eelco Chaudron , "mdnsext@ietf.org" Thread-Topic: [mdnsext] mDNS relay agent idea Thread-Index: Ac2+u1fg6ZQpKeiaTpOwPU+MQ5VgBgAOpOSA Date: Sat, 10 Nov 2012 03:46:11 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [10.16.5.119] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8B32692DCFBF8C4C84CD3AF0091749F5@aerohive.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mdnsext] mDNS relay agent idea X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Nov 2012 03:46:28 -0000 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" 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=B9s service on all the network segment= s >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=B9s 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=B9s 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 >mdnsext@ietf.org >https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5662F21F86E3 for ; Fri, 9 Nov 2012 12:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIXznUWW6e76 for ; Fri, 9 Nov 2012 12:46:54 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p2.extremenetworks.com [207.179.9.62]) by ietfa.amsl.com (Postfix) with ESMTP id CCE2321F86E0 for ; Fri, 9 Nov 2012 12:46:54 -0800 (PST) Received: from nlut-casht-p1.corp.extremenetworks.com (10.112.1.70) by ussc-casht-p1.corp.extremenetworks.com (10.0.4.73) with Microsoft SMTP Server (TLS) id 8.3.264.0; Fri, 9 Nov 2012 12:46:54 -0800 Received: from NLEXCHANGE.corp.extremenetworks.com ([10.112.1.63]) by nlut-casht-p1.corp.extremenetworks.com ([192.168.250.4]) with mapi; Fri, 9 Nov 2012 21:46:51 +0100 From: Eelco Chaudron To: "mdnsext@ietf.org" Date: Fri, 9 Nov 2012 21:46:50 +0100 Thread-Topic: mDNS relay agent idea Thread-Index: Ac2+u1fg6ZQpKeiaTpOwPU+MQ5VgBg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mdnsext] mDNS relay agent idea X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 20:46:55 -0000 Inline with the other emails send around, I would suggest using something s= imilar to the bootp relay approach. Where a relay agent can unicast forward the service request to other networ= k segments. This should be done in such a way it will work with all the exi= sting mDNS querier clients out there. The mDNS relay service can run on a switch, router, or purposely build devi= ce/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=92s service on all the network segments= connected using mDNS. - All the relay agents on the same segment can than form adjacencies and de= termine the designated forwarded for the segment. The agent with the most i= nterfaces has the highest priority, tie breaker could be the IP address. - All relay agents in the domain can form adjacencies, and build a link sta= te 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 i= t=92s the designated forwarder for (others might also do this in case of fa= ilure of the DF, but they should not include the entries in a response to a= void duplicates). - If a DF sees a DNS (service) query it will forward it as unicast to all k= nown 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=92s 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 propriet= ary material and is solely for the use of the intended recipient. Any revie= w, use, disclosure, distribution or copying of this transmittal is prohibit= ed 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. Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E6221F8DAC for ; Fri, 9 Nov 2012 12:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIv8KSGRCWa9 for ; Fri, 9 Nov 2012 12:17:06 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id AB76421F8DAD for ; Fri, 9 Nov 2012 12:17:05 -0800 (PST) Received: from mail52-co1-R.bigfish.com (10.243.78.243) by CO1EHSOBE003.bigfish.com (10.243.66.66) with Microsoft SMTP Server id 14.1.225.23; Fri, 9 Nov 2012 20:17:04 +0000 Received: from mail52-co1 (localhost [127.0.0.1]) by mail52-co1-R.bigfish.com (Postfix) with ESMTP id A47936002A3; Fri, 9 Nov 2012 20:17:04 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.85; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0811HT001.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zzbb2dI98dI9371I1432Izz1de0h1202h1d1ah1d2ahzz1033IL177df4h17326ah8275bh8275dhz32i2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h) Received: from mail52-co1 (localhost.localdomain [127.0.0.1]) by mail52-co1 (MessageSwitch) id 1352492223562870_5085; Fri, 9 Nov 2012 20:17:03 +0000 (UTC) Received: from CO1EHSMHS022.bigfish.com (unknown [10.243.78.244]) by mail52-co1.bigfish.com (Postfix) with ESMTP id 7D1BDA4004B; Fri, 9 Nov 2012 20:17:03 +0000 (UTC) Received: from CH1PRD0811HT001.namprd08.prod.outlook.com (157.56.245.85) by CO1EHSMHS022.bigfish.com (10.243.66.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 9 Nov 2012 20:17:03 +0000 Received: from CH1PRD0811MB407.namprd08.prod.outlook.com ([169.254.8.142]) by CH1PRD0811HT001.namprd08.prod.outlook.com ([10.255.155.36]) with mapi id 14.16.0233.002; Fri, 9 Nov 2012 20:17:02 +0000 From: Alf Watt To: Matthew Gast Thread-Topic: [mdnsext] Security requirement? Thread-Index: AQHNvLVlxAStVa6DUkCwmVEKgzxI8pffJWEAgAKgroCAAC7ggA== Date: Fri, 9 Nov 2012 20:17:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.155.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ruckuswireless.com Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] Security requirement? X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 20:17:09 -0000 Good suggestion, I used 'authoritative' to indicate that the actual adverti= ser or it's designated proxy could respond as long as we have a chain of tr= ust, but it never hurts to be explicit. Have a look at the Sleep Proxy[1] support for examples of how proxying curr= ently works, the client adding a service to the proxy needs some way to tra= nsfer 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 wrote: > I agree with that addition, but I'd modify it slightly to say that we wan= t > to continue to support the proxy functionality that exists today, like: >=20 > "- ensure that service resolution is authoritative for the advertisement, > whether it is an original or proxy advertisement" >=20 > 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 tha= t > have just woken up from a sleep seems like a good idea. >=20 > Matthew >=20 >=20 > On 11/7/12 5:21 PM, "Alf Watt" wrote: >=20 >> I'd add: >>=20 >> - ensure that service resolution is authoritative for the advertisement >>=20 >> i.e. prevent a third party from replying with it's own ip & port number >> to redirect a client for nefarious purposes. >>=20 >> Solving this for both mDNS and DNS-SD would be a good thing. >>=20 >> http://www.gnucitizen.org/blog/name-mdns-poisoning-attacks-inside-the-la= n/ >>=20 >> Best, >> Alf >>=20 >> On Nov 7, 2012, at 1:59 AM, Matthew Gast wrote: >>=20 >>> 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 th= e >>> service transmission and service reception should be validated. If I >>> were >>> to put that into the current document, I'd propose text like this: >>>=20 >>> "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" >>>=20 >>> Matthew >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> mdnsext mailing list >>> mdnsext@ietf.org >>> https://www.ietf.org/mailman/listinfo/mdnsext >>>=20 >>=20 >=20 >=20 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6432E21F8770 for ; Fri, 9 Nov 2012 12:00:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-9ku3MdheyI for ; Fri, 9 Nov 2012 12:00:05 -0800 (PST) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id 46E8D21F8708 for ; Fri, 9 Nov 2012 12:00:04 -0800 (PST) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:Subject: Thread-Topic:Thread-Index:Date:Message-ID:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=rgsuMGlV3/JzLOeW0o9Yn/qkKWhdpZaKFSuU/TBtisr4ayDL6elQFoLX 2ZAC6QHZ90nJW41kQGSZb7R8ohN88XrnxcMxFFSADXXuCbThdkusoz2xT yqHugzpJ5oVmxng; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1352491205; x=1384027205; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20MDNSEXT=20BoF=20in=20Ars=20Technica|Date:=20F ri,=209=20Nov=202012=2020:00:00=20+0000|Message-ID:=20<45 1EF365-3A33-4EB8-9B02-B8D0194E4D59@nominet.org.uk>|To:=20 ""=20|MIME-Version: =201.0|Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20; bh=rOT1SLleV822ZePfQXwWsW8MPsL8yIoHGBKWZTjHZOk=; b=AyqBdLhFgkXaz9TufqpQDuJpbbY2PyB46wesx3N2KL8E9SAjkjM5d0H8 /FRIm7ixUj0xVbjY90ZuHUbLqSCuBXI7sBQXPLhFJAXbsYgDtJohovEJB 32yw3wVlf+ShNs3; X-IronPort-AV: E=Sophos;i="4.80,747,1344207600"; d="scan'208";a="36627549" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 09 Nov 2012 20:00:02 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi; Fri, 9 Nov 2012 20:00:02 +0000 From: Ray Bellis To: "" Thread-Topic: MDNSEXT BoF in Ars Technica Thread-Index: AQHNvrTNvUWwdzxTuU+EMUN8u75sBQ== Date: Fri, 9 Nov 2012 20:00:00 +0000 Message-ID: <451EF365-3A33-4EB8-9B02-B8D0194E4D59@nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mdnsext] MDNSEXT BoF in Ars Technica X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 20:00:06 -0000 Ray Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E919321F8758 for ; Fri, 9 Nov 2012 10:07:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOeL6UkTxPGX for ; Fri, 9 Nov 2012 10:07:34 -0800 (PST) Received: from itsnt427.iowa.uiowa.edu (itsnt427.iowa.uiowa.edu [128.255.6.109]) by ietfa.amsl.com (Postfix) with ESMTP id 224D921F8506 for ; Fri, 9 Nov 2012 10:07:34 -0800 (PST) Received: from ITSNT441.iowa.uiowa.edu ([169.254.3.228]) by itsnt427.iowa.uiowa.edu ([128.255.6.109]) with mapi id 14.02.0318.001; Fri, 9 Nov 2012 12:07:32 -0600 From: "Johnson, Neil M" To: Matthew Gast , Dan Harkins Thread-Topic: [mdnsext] Forwarding link-local IP multicast Thread-Index: AQHNvHE0UHB+aCLDR0G0552LUJrx4ZffFHyAgABAoICAAQxQgIABzv4A//+QGgA= Date: Fri, 9 Nov 2012 18:07:32 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [128.255.6.15] Content-Type: text/plain; charset="us-ascii" Content-ID: <8F2DD736D295BF43A9C4842EB5D0A510@mailhost6.uiowa.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org" , Tom Pusateri , Yi Yang Subject: Re: [mdnsext] Forwarding link-local IP multicast X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 18:07:39 -0000 I just want to comment on the scalability of "middle boxes". We have ~180 buildings on our campus, most have their own IP (v4 and v6) subnet. In addition, to keep our wireless broadcast domains reasonable we have multiple wireless subnets that are allocated to users dynamically (Meaning that two wireless clients in the same room maybe on different subnets). I'm concerned that some of the scenarios proposed that use a middle box would require it to have an interface (physical or virtual) in each subnet. That won't scale for us. -Neil. --=20 Neil Johnson Network Engineer The University of Iowa Phone: 319 384-0938 Fax: 319 335-2951 Mobile: 319 540-2081 E-Mail: neil-johnson@uiowa.edu On 11/9/12 11:48 AM, "Matthew Gast" wrote: >On 11/8/12 6:10 AM, "Dan Harkins" 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 >mdnsext@ietf.org >https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB67D21F8599 for ; Fri, 9 Nov 2012 09:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9kQdfgl28Nl for ; Fri, 9 Nov 2012 09:48:25 -0800 (PST) Received: from mx1.aerohive.com (mx1.aerohive.com [209.128.117.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1B61E21F84E3 for ; Fri, 9 Nov 2012 09:48:25 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx1.aerohive.com (Postfix) with ESMTP id C71B74D0214; Fri, 9 Nov 2012 09:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at aerohive.com Received: from mx1.aerohive.com ([127.0.0.1]) by localhost (mx1.aerohive.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lr9cuSPvCd0; Fri, 9 Nov 2012 09:46:52 -0800 (PST) Received: from mail.aerohive.com (unknown [10.16.240.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.aerohive.com (Postfix) with ESMTP id 7EEF94D016C; Fri, 9 Nov 2012 09:46:44 -0800 (PST) Received: from HQ-MBX1.aerohive.com ([fe80::25ec:76f2:f1da:a517]) by hq-cas2.aerohive.com ([::1]) with mapi id 14.02.0298.004; Fri, 9 Nov 2012 09:48:01 -0800 From: Matthew Gast To: Dan Harkins Thread-Topic: [mdnsext] Forwarding link-local IP multicast Thread-Index: AQHNvHEsRSHOddPWkkKf+CX6lMUDoJffNgOA//+fYwCAAa2NgIABSOAA Date: Fri, 9 Nov 2012 17:48:00 +0000 Message-ID: In-Reply-To: <833896d88988337447f98428060b0c48.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [10.16.5.119] Content-Type: text/plain; charset="us-ascii" Content-ID: <44FA833789695B4399AAD5C5EC13A8E4@aerohive.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org" , Tom Pusateri , Yi Yang Subject: Re: [mdnsext] Forwarding link-local IP multicast X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:48:25 -0000 On 11/8/12 6:10 AM, "Dan Harkins" 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 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7278321F874D for ; Fri, 9 Nov 2012 09:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sY2kutBiBmyX for ; Fri, 9 Nov 2012 09:29:34 -0800 (PST) Received: from mx1.aerohive.com (mx1.aerohive.com [209.128.117.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6F08B21F847F for ; Fri, 9 Nov 2012 09:29:34 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx1.aerohive.com (Postfix) with ESMTP id 17BBB4D01FF; Fri, 9 Nov 2012 09:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at aerohive.com Received: from mx1.aerohive.com ([127.0.0.1]) by localhost (mx1.aerohive.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWhVa2x3I4LA; Fri, 9 Nov 2012 09:28:02 -0800 (PST) Received: from mail.aerohive.com (unknown [10.16.240.56]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.aerohive.com (Postfix) with ESMTP id F227E4D01D1; Fri, 9 Nov 2012 09:28:01 -0800 (PST) Received: from HQ-MBX1.aerohive.com ([fe80::25ec:76f2:f1da:a517]) by hq-cas1.aerohive.com ([fe80::5199:67eb:c502:c65d%14]) with mapi id 14.02.0298.004; Fri, 9 Nov 2012 09:29:17 -0800 From: Matthew Gast To: Alf Watt , "mdnsext@ietf.org" Thread-Topic: [mdnsext] Security requirement? Thread-Index: AQHNvLVlxAStVa6DUkCwmVEKgzxI8pffJWEAgAKgroA= Date: Fri, 9 Nov 2012 17:29:16 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [10.16.5.119] Content-Type: text/plain; charset="us-ascii" Content-ID: <32093C08E6888A46907B82893F2DFA81@aerohive.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mdnsext] Security requirement? X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 17:29:35 -0000 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" 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 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: >>=20 >> "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" >>=20 >> Matthew >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> mdnsext mailing list >> mdnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/mdnsext >>=20 > Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF1221F865C for ; Thu, 8 Nov 2012 11:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTeVd1ZA-pM1 for ; Thu, 8 Nov 2012 11:29:17 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6F34D21F84DD for ; Thu, 8 Nov 2012 11:29:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3383; q=dns/txt; s=iport; t=1352402957; x=1353612557; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5GGzY/DRtIPq237qw0DsInVxe05IihcfOs17A1wnjjQ=; b=Bq30TYihQTXsXt7GFpW3A/SyCozYl9HfpY5IqsUHzHkYtzwF1I46A9lo 0h2jO5ekPRnZw8bhPGuFqQxiXUkcbeH+ThFZ4EfnJ+/vEr6dAF63ZJ33q vPzdLy+ofxTFVEzAGMNfnCm7+f8UyGozqH7CItfjz5Z8pafOag1dXNUVV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMgGnFCtJXG+/2dsb2JhbAA7CcNkgQiCHgEBAQMBAQEBDwEnNAsQAgEIDgoKFBAnCyUCBA4FCBMHh2IGC5wDoDIEjBIRhVVhA6RTgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,739,1344211200"; d="scan'208";a="140053950" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 08 Nov 2012 19:29:16 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA8JTGj6015877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Nov 2012 19:29:16 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.239]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 13:29:16 -0600 From: "Yi Yang (yiya)" To: Dan Harkins Thread-Topic: [mdnsext] Forwarding link-local IP multicast Thread-Index: AQHNvHEtgNJF/dGpDkaYzmgVkrs5oZffFHyAgABAoICAAQxQgIAAWPOA Date: Thu, 8 Nov 2012 19:29:16 +0000 Message-ID: References: <833896d88988337447f98428060b0c48.squirrel@www.trepanning.net> In-Reply-To: <833896d88988337447f98428060b0c48.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.255.165] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005 x-tm-as-result: No--52.514600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org" , Matthew Gast , Tom Pusateri Subject: Re: [mdnsext] Forwarding link-local IP multicast X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 19:29:18 -0000 On Nov 8, 2012, at 9:10 AM, Dan Harkins wrote: >=20 > 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 en= d >> 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. >=20 > 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/loc= ation/identity and may make better decision to select the services. Yi >=20 > Dan. >=20 >> On 11/7/12 10:19 AM, "Yi Yang (yiya)" wrote: >>=20 >>> 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. >>>=20 >>> Yi >>>=20 >>>=20 >>> On Nov 6, 2012, at 5:50 PM, Tom Pusateri wrote: >>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> The multicast routing protocols take great care to create minimum >>>> spanning trees from the source to the many receivers of routed multica= st >>>> packets. They prune branches that would create loops and ensure only a >>>> single copy of the original packet is sent on any one link. >>>>=20 >>>> To duplicate this effort requires coordination between each mDNS >>>> proxy/relay and you will end up redesigning the multicast routing >>>> protocols under another name. >>>>=20 >>>> So if you want to forward IP multicast, please use the multicast >>>> routing protocols that have been developed in the IETF that are deploy= ed >>>> and proven. >>>>=20 >>>> 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. >>>>=20 >>>> Thanks, >>>> Tom >>>> _______________________________________________ >>>> mdnsext mailing list >>>> mdnsext@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mdnsext >>>=20 >>> _______________________________________________ >>> mdnsext mailing list >>> mdnsext@ietf.org >>> https://www.ietf.org/mailman/listinfo/mdnsext >>=20 >> _______________________________________________ >> mdnsext mailing list >> mdnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/mdnsext >>=20 >=20 >=20 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A990421F8893 for ; Thu, 8 Nov 2012 06:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjtXYTpA0wzg for ; Thu, 8 Nov 2012 06:10:53 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id C347021F86AD for ; Thu, 8 Nov 2012 06:10:53 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 51CEF1022400A; Thu, 8 Nov 2012 06:10:53 -0800 (PST) Received: from 130.129.17.156 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 8 Nov 2012 06:10:53 -0800 (PST) Message-ID: <833896d88988337447f98428060b0c48.squirrel@www.trepanning.net> In-Reply-To: References: Date: Thu, 8 Nov 2012 06:10:53 -0800 (PST) From: "Dan Harkins" To: "Matthew Gast" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "mdnsext@ietf.org" , Tom Pusateri , Yi Yang Subject: Re: [mdnsext] Forwarding link-local IP multicast X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 14:10:54 -0000 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)" 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 >>> mdnsext@ietf.org >>> https://www.ietf.org/mailman/listinfo/mdnsext >> >>_______________________________________________ >>mdnsext mailing list >>mdnsext@ietf.org >>https://www.ietf.org/mailman/listinfo/mdnsext > > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext > Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7E421F8B17 for ; Wed, 7 Nov 2012 17:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIvxecoNqj5m for ; Wed, 7 Nov 2012 17:21:51 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 766C921F89EE for ; Wed, 7 Nov 2012 17:21:51 -0800 (PST) Received: from mail30-db3-R.bigfish.com (10.3.81.244) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Nov 2012 01:21:50 +0000 Received: from mail30-db3 (localhost [127.0.0.1]) by mail30-db3-R.bigfish.com (Postfix) with ESMTP id 2B6CF2E0452; Thu, 8 Nov 2012 01:21:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.85; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0811HT005.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: PS-18(zz98dI9371I1432Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz32i2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h) Received: from mail30-db3 (localhost.localdomain [127.0.0.1]) by mail30-db3 (MessageSwitch) id 1352337707149289_12584; Thu, 8 Nov 2012 01:21:47 +0000 (UTC) Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.228]) by mail30-db3.bigfish.com (Postfix) with ESMTP id 2200840049; Thu, 8 Nov 2012 01:21:47 +0000 (UTC) Received: from CH1PRD0811HT005.namprd08.prod.outlook.com (157.56.245.85) by DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Nov 2012 01:21:46 +0000 Received: from CH1PRD0811MB407.namprd08.prod.outlook.com ([169.254.8.4]) by CH1PRD0811HT005.namprd08.prod.outlook.com ([10.255.155.40]) with mapi id 14.16.0233.002; Thu, 8 Nov 2012 01:21:39 +0000 From: Alf Watt To: "mdnsext@ietf.org" Thread-Topic: [mdnsext] Security requirement? Thread-Index: AQHNvLVlxAStVa6DUkCwmVEKgzxI8pffJWEA Date: Thu, 8 Nov 2012 01:21:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.155.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ruckuswireless.com X-Mailman-Approved-At: Sun, 11 Nov 2012 13:40:28 -0800 Cc: Matthew Gast Subject: Re: [mdnsext] Security requirement? X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 01:33:48 -0000 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 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 th= e > requirements document, so I'll start off with what I heard today, which i= s > that service advertisements shouldn't just be trusted, and that both the > service transmission and service reception should be validated. If I wer= e > to put that into the current document, I'd propose text like this: >=20 > "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" >=20 > Matthew >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext >=20 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A8D21F8B60 for ; Wed, 7 Nov 2012 15:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=0.746, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIX0iOq6PPLR for ; Wed, 7 Nov 2012 15:15:29 -0800 (PST) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6CB21F8B16 for ; Wed, 7 Nov 2012 15:15:29 -0800 (PST) Received: from client-86-29-206-117.glfd-bam-2.adsl.virginmedia.com ([86.29.206.117] helo=[192.168.0.2]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) id 1TWEqE-0003A5-Qi for mdnsext@ietf.org; Wed, 07 Nov 2012 23:15:27 +0000 Message-ID: <509AEBD1.9080201@gridmerge.com> Date: Wed, 07 Nov 2012 23:16:33 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: mdnsext@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010704000904080602030903" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [mdnsext] Forwarding link-local IP multicast X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 23:15:33 -0000 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=20 "mdns" in the name, which implies the use of mDNS (i.e. multicast). As=20 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=20 certain situations it would be preferable to use unicast DNS in=20 conjunction with DNS-SD with probably some sort of distributed name=20 servers but also to allow mDNS in conjunction with DNS-SD for the=20 subnets which can support it effectively. The conundrum then becomes=20 administration and configuration of the distributed name servers and=20 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 e= nd > of his requirements discussion yesterday, then we will need to have > something that looks inside the content of the multicast packets to mak= e > 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)" 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 multic= ast >>> 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 deplo= yed >>> and proven. >>> >>> I'm not suggesting that routed IP multicast be the solution, only tha= t >>> proxy/relays that forward Iiink-local IP multicast should met with >>> skepticism. >>> >>> Thanks, >>> Tom >>> _______________________________________________ >>> mdnsext mailing list >>> mdnsext@ietf.org >>> https://www.ietf.org/mailman/listinfo/mdnsext >> _______________________________________________ >> mdnsext mailing list >> mdnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/mdnsext > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjExMDcyMzE2MzNaMCMGCSqGSIb3DQEJBDEWBBSdpUFgJVdV8XSQxvfVm3+gewNpDTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAHYTtX+/khOv3BIx8OIDuMeNFs+HFxN/HZQ7VrNt7zXF0DoB 2BbPylY1JFA3RmwCP0OUpgIPtzOpZdRv+HYPxEFHiT7VlULkaqahBle9/GRRTvVaSHLzpFFn q+Q8bgfTiFGi42N9TYr1PXAJAlOefxOdhfEESKo7foyXf+LYXWYWjAquHRThSlZYJ/eJO/To 9HXCaGrrRSZK49iwYhp6DjWjAsdhcPq6vwfE+1iPfjRyt4U9rkpO3xGNY4c5imiLjjT3DKwA 1S7nrWnCBsa0BOIkshpgNk07WdppLQ9Vk0NPBxAth/4aLfPGPXbx3pyOX3EVOqPrrrkhLXHL B1578mYAAAAAAAA= --------------ms010704000904080602030903-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BB121F8698 for ; Wed, 7 Nov 2012 14:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 100e7bhfdpKn for ; Wed, 7 Nov 2012 14:29:45 -0800 (PST) Received: from mx1.aerohive.com (mx1.aerohive.com [209.128.117.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6FBBB21F86A1 for ; Wed, 7 Nov 2012 14:11:08 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx1.aerohive.com (Postfix) with ESMTP id 43C934D01FD; Wed, 7 Nov 2012 14:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at aerohive.com Received: from mx1.aerohive.com ([127.0.0.1]) by localhost (mx1.aerohive.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUQ7TZ71wbs5; Wed, 7 Nov 2012 14:09:37 -0800 (PST) Received: from mail.aerohive.com (unknown [10.16.240.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.aerohive.com (Postfix) with ESMTP id D959B4D01C5; Wed, 7 Nov 2012 14:09:27 -0800 (PST) Received: from HQ-MBX1.aerohive.com ([fe80::25ec:76f2:f1da:a517]) by hq-cas2.aerohive.com ([::1]) with mapi id 14.02.0298.004; Wed, 7 Nov 2012 14:10:42 -0800 From: Matthew Gast To: "Yi Yang (yiya)" , Tom Pusateri Thread-Topic: [mdnsext] Forwarding link-local IP multicast Thread-Index: AQHNvHEsRSHOddPWkkKf+CX6lMUDoJffNgOA//+fYwA= Date: Wed, 7 Nov 2012 22:10:33 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [12.130.122.195] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] Forwarding link-local IP multicast X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 22:29:45 -0000 Exactly. Packet delivery is only a small part of the problem here. If we choose to take on security work in the form hinted at by Kerry at the end of his requirements discussion yesterday, then we will need to have something that looks inside the content of the multicast packets to make decisions. I'm not in favor of developing new multicast routing protocols. There's a possibility that we may not want to use multicast because large wireless LANs will often disable multicast entirely. Matthew On 11/7/12 10:19 AM, "Yi Yang (yiya)" 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> To duplicate this effort requires coordination between each mDNS >>proxy/relay and you will end up redesigning the multicast routing >>protocols under another name. >>=20 >> 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. >>=20 >> 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. >>=20 >> Thanks, >> Tom >> _______________________________________________ >> mdnsext mailing list >> mdnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/mdnsext > >_______________________________________________ >mdnsext mailing list >mdnsext@ietf.org >https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E79121F8B4D for ; Wed, 7 Nov 2012 10:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5EQa8kHkC5G for ; Wed, 7 Nov 2012 10:19:22 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1E28B21F8724 for ; Wed, 7 Nov 2012 10:19:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1757; q=dns/txt; s=iport; t=1352312357; x=1353521957; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8N4cTUZjyn3v4fE3U0qoUR+yBpLTeO1zDDo4L+cUr1E=; b=OWU2vtHuUswXp7bj82rHCgzxpGTR5oniPkCcbToYsSNbUKG3uA/F8VGy rDIYUxX+qVH++AGme6OxP+QC7d+C7SCY+aQiWok0EmJFA6Q04d10nh4BI ueqpW4eLZm1MDexR3uHUBR0T8vVQ9nGt0ipwxGVQXaBhyVzn/tfpaNuAb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEilmlCtJXG9/2dsb2JhbABEw2OBCIIeAQEBAwEBAQEPASc0CwULAgEIIhQQJwslAgQOBQgTB4diBgucNqAtBIwNhWZhA6RUgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,731,1344211200"; d="scan'208";a="139867620" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 07 Nov 2012 18:19:16 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA7IJG2A015551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 Nov 2012 18:19:16 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.239]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.001; Wed, 7 Nov 2012 12:19:16 -0600 From: "Yi Yang (yiya)" To: Tom Pusateri Thread-Topic: [mdnsext] Forwarding link-local IP multicast Thread-Index: AQHNvHEtgNJF/dGpDkaYzmgVkrs5oZffFHyA Date: Wed, 7 Nov 2012 18:19:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.241.210] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19346.005 x-tm-as-result: No--43.617900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <6125F34F2BED9041882CE1E130C759E6@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] Forwarding link-local IP multicast X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 18:19:23 -0000 A reliable multicast through campus network is a challenge, and what makes = the issue even more challenging is that packet transportation/delivery is o= nly a part of the problems --- Considering the scalability/security/authori= zation/policy, not all but a selective subset of service instances may be d= elivered to a client, which is not something a plain multicast can solve, I= MHO. 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. >=20 > 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 m= any mDNS packets will pale in comparison. >=20 > The multicast routing protocols take great care to create minimum spannin= g 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 o= f the original packet is sent on any one link. >=20 > To duplicate this effort requires coordination between each mDNS proxy/re= lay and you will end up redesigning the multicast routing protocols under a= nother name. >=20 > 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= . >=20 > I'm not suggesting that routed IP multicast be the solution, only that pr= oxy/relays that forward Iiink-local IP multicast should met with skepticism= . >=20 > Thanks, > Tom > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B94721F8C76 for ; Wed, 7 Nov 2012 08:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.835 X-Spam-Level: X-Spam-Status: No, score=-1.835 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFA2uXuuBwya for ; Wed, 7 Nov 2012 08:31:00 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id D985E21F8BF5 for ; Wed, 7 Nov 2012 08:31:00 -0800 (PST) Received: from sandelman.ca (dhcp-1280.meeting.ietf.org [130.129.18.128]) by relay.sandelman.ca (Postfix) with ESMTPS id DBDE181AA for ; Wed, 7 Nov 2012 11:22:53 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 382C7CA0BC for ; Wed, 7 Nov 2012 11:31:01 -0500 (EST) From: Michael Richardson To: "mdnsext@ietf.org" In-reply-to: References: Comments: In-reply-to Tom Pusateri message dated "Tue, 06 Nov 2012 17:50:55 -0500." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 07 Nov 2012 11:31:01 -0500 Message-ID: <16668.1352305861@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [mdnsext] Forwarding link-local IP multicast X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:31:01 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Tom" =3D=3D Tom Pusateri 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.=20 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.=20 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.=20 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.=20 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?=20=20 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.=20=20 (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) =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQmozEAAoJEKD0KQ7Gj3P2pWAIALxqQWnnVlUCopTMw7JIfdFS rQjuJrGbbna/l4+amEzsiQGWOXdcg+fQQDkDYX98aCOUs5YMmUfNYTw9Ewx/CMLa +OHlT1zkqQxEp4yjD+nEL0YdWkurDAVlwRFYlEJqR+23guzT4k9J2I8oHZrBYttV Tdm+9HJmsvypZYPtj727m8b8rtlQUBSxnPZSIMvt391NSrSN4v+8dfRFunkmT2Zp W/v04IOORt7bqCqlP4dj00kh0qvM32ay5xpHahU2IOu/bRFN/NWSOA7WWO6V0aXC sW4Vkb1WzOd2AUyCooNrsNBU6XypIezLT0DclKiLqRLUFFFBPZFx7bzOd8MTdo0= =Sx8K -----END PGP SIGNATURE----- --=-=-=-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E76321F8B4A for ; Wed, 7 Nov 2012 06:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.657 X-Spam-Level: X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMtNODM-Jx2n for ; Wed, 7 Nov 2012 06:36:49 -0800 (PST) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) by ietfa.amsl.com (Postfix) with ESMTP id BA5B321F8B19 for ; Wed, 7 Nov 2012 06:36:49 -0800 (PST) Received: from dhcp-5493.meeting.ietf.org (dhcp-5493.meeting.ietf.org [130.129.84.147]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 532C911B2D; Wed, 7 Nov 2012 09:34:32 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tom Pusateri In-Reply-To: Date: Wed, 7 Nov 2012 09:36:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Matthew Gast X-Mailer: Apple Mail (2.1499) Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] Educause petition in requirements document X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:36:50 -0000 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: >=20 > "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: >=20 > 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." >=20 > Matthew >=20 > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444D821F89D0 for ; Wed, 7 Nov 2012 06:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaDzIgsukZQA for ; Wed, 7 Nov 2012 06:22:32 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFDE121F8917 for ; Wed, 7 Nov 2012 06:22:27 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so2730938iec.31 for ; Wed, 07 Nov 2012 06:22:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=XY2IOYFHI6k4H9K4V+qKkX8jAGZBY5u9RNyNFhRktH8=; b=n0xS5Jf7NRs0W4qXqrcEgySm4d6jysUVl7zS8t/magZp/QumlLdki7DjAWUfnq6FLs 1tRis+ItPlhUxEHCsKfL0HLf/0YAXSWuw3KJR0hcaK75/MOZsnENGZLCcEr+06M9ULQg aHNmWW/osq+XRdmtiauF8Kb02NiWn5pONxNC8aBToo+8ci0tzDvn2WbC133kFfU7yOxV 5XZD57VXL7vRmnrOauLO0opQDjizZC4RSxpDwb3VmfQfZ5cM0wYSdubsllwNVwEwMk9n b5TD41bWv1FxWPNa54jGYcyvDIFgt9JOpBXiI2h+N2ixqQialDY7dczAYAQrPOdePMkN MfWw== Received: by 10.50.152.137 with SMTP id uy9mr4626429igb.62.1352298147476; Wed, 07 Nov 2012 06:22:27 -0800 (PST) Received: from ?IPv6:2001:470:1f07:309:1512:d79c:4ed:dec9? ([2001:470:1f07:309:1512:d79c:4ed:dec9]) by mx.google.com with ESMTPS id dq9sm2145990igc.5.2012.11.07.06.22.26 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 06:22:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_8118C914-2808-4604-BC94-ED475B60957E" From: Dan York In-Reply-To: Date: Wed, 7 Nov 2012 09:22:24 -0500 Message-Id: <9B688E57-480B-4B39-B3FD-773F16EBDC68@danyork.org> References: To: Matthew Gast X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQm6OEhyYDbYWUh4Sk2gIPUiW5aqd4onalqr1TW5oL3lELxNpC81JbK1cdTUokoCu3H82eOt Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] Educause petition in requirements document X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:22:35 -0000 --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 > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext -- Dan York dyork@lodestar2.com 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
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
mdnsext@ietf.org
https://www.ietf.= org/mailman/listinfo/mdnsext

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.me/  &nb= sp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork

= --Apple-Mail=_8118C914-2808-4604-BC94-ED475B60957E-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374C021F8B02 for ; Wed, 7 Nov 2012 04:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IwweTjkgY4W for ; Wed, 7 Nov 2012 04:36:04 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id A477E21F8AF9 for ; Wed, 7 Nov 2012 04:36:04 -0800 (PST) Received: from crankycanuck.ca (dhcp-40fd.meeting.ietf.org [130.129.64.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 414878A031 for ; Wed, 7 Nov 2012 12:36:01 +0000 (UTC) Date: Wed, 7 Nov 2012 07:35:57 -0500 From: Andrew Sullivan To: mdnsext@ietf.org Message-ID: <20121107123557.GA74606@crankycanuck.ca> References: <5099A026.8070709@thekelleys.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5099A026.8070709@thekelleys.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [mdnsext] Differences between mDNS and DNS names. X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 12:36:05 -0000 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 ajs@anvilwalrusden.com Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674C521F8B4C for ; Tue, 6 Nov 2012 22:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JHOziQotO2b for ; Tue, 6 Nov 2012 22:59:55 -0800 (PST) Received: from mx1.aerohive.com (mx1.aerohive.com [209.128.117.80]) by ietfa.amsl.com (Postfix) with ESMTP id ABC2E21F8B34 for ; Tue, 6 Nov 2012 22:59:55 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx1.aerohive.com (Postfix) with ESMTP id 9FF924D017B for ; Tue, 6 Nov 2012 22:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at aerohive.com Received: from mx1.aerohive.com ([127.0.0.1]) by localhost (mx1.aerohive.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iprjYVrnheGZ for ; Tue, 6 Nov 2012 22:58:26 -0800 (PST) Received: from mail.aerohive.com (unknown [10.16.240.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.aerohive.com (Postfix) with ESMTP id 90E1B4D0182 for ; Tue, 6 Nov 2012 22:58:26 -0800 (PST) Received: from HQ-MBX1.aerohive.com ([fe80::25ec:76f2:f1da:a517]) by hq-cas2.aerohive.com ([::1]) with mapi id 14.02.0298.004; Tue, 6 Nov 2012 22:59:40 -0800 From: Matthew Gast To: "mdnsext@ietf.org" Thread-Topic: Educause petition in requirements document Thread-Index: AQHNvLVjjliFNKuFZEWDQWNqJnn5ww== Date: Wed, 7 Nov 2012 06:59:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [63.133.204.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <1B7DDDBF9011C54F8494F188014C0017@aerohive.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mdnsext] Educause petition in requirements document X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 06:59:56 -0000 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 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737CE21F8B34 for ; Tue, 6 Nov 2012 22:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UJTC5EN4wU3 for ; Tue, 6 Nov 2012 22:59:55 -0800 (PST) Received: from mx1.aerohive.com (mx1.aerohive.com [209.128.117.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBED21F8B14 for ; Tue, 6 Nov 2012 22:59:55 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx1.aerohive.com (Postfix) with ESMTP id 6A2954D019A for ; Tue, 6 Nov 2012 22:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at aerohive.com Received: from mx1.aerohive.com ([127.0.0.1]) by localhost (mx1.aerohive.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2DlXOdtcbr9 for ; Tue, 6 Nov 2012 22:58:26 -0800 (PST) Received: from mail.aerohive.com (unknown [10.16.240.56]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.aerohive.com (Postfix) with ESMTP id 57B274D017B for ; Tue, 6 Nov 2012 22:58:26 -0800 (PST) Received: from HQ-MBX1.aerohive.com ([fe80::25ec:76f2:f1da:a517]) by hq-cas1.aerohive.com ([fe80::5199:67eb:c502:c65d%14]) with mapi id 14.02.0298.004; Tue, 6 Nov 2012 22:59:39 -0800 From: Matthew Gast To: "mdnsext@ietf.org" Thread-Topic: 802.11 addition to requirements documents Thread-Index: AQHNvLVhgqvXIdKp9E2Yau8pWdiUWw== Date: Wed, 7 Nov 2012 06:59:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [63.133.204.34] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mdnsext] 802.11 addition to requirements documents X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 06:59:56 -0000 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 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CC921F8B14 for ; Tue, 6 Nov 2012 22:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AO6txEO2CZFh for ; Tue, 6 Nov 2012 22:59:56 -0800 (PST) Received: from mx1.aerohive.com (mx1.aerohive.com [209.128.117.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4479B21F8B3B for ; Tue, 6 Nov 2012 22:59:56 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx1.aerohive.com (Postfix) with ESMTP id 3053E4D017B for ; Tue, 6 Nov 2012 22:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at aerohive.com Received: from mx1.aerohive.com ([127.0.0.1]) by localhost (mx1.aerohive.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjU7KnTuo9Ma for ; Tue, 6 Nov 2012 22:58:27 -0800 (PST) Received: from mail.aerohive.com (unknown [10.16.240.56]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.aerohive.com (Postfix) with ESMTP id 20D7F4D018B for ; Tue, 6 Nov 2012 22:58:27 -0800 (PST) Received: from HQ-MBX1.aerohive.com ([fe80::25ec:76f2:f1da:a517]) by hq-cas1.aerohive.com ([fe80::5199:67eb:c502:c65d%14]) with mapi id 14.02.0298.004; Tue, 6 Nov 2012 22:59:40 -0800 From: Matthew Gast To: "mdnsext@ietf.org" Thread-Topic: Security requirement? Thread-Index: AQHNvLVlxAStVa6DUkCwmVEKgzxI8g== Date: Wed, 7 Nov 2012 06:59:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 x-originating-ip: [63.133.204.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <0FC37C8BB078E94F9DB1D18C0E003676@aerohive.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mdnsext] Security requirement? X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 06:59:56 -0000 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 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C52221F8B18 for ; Tue, 6 Nov 2012 22:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ub9m45gIQEux for ; Tue, 6 Nov 2012 22:09:14 -0800 (PST) Received: from srv01.frobbit.se (ns2.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 488D821F8B14 for ; Tue, 6 Nov 2012 22:09:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id ED863176FB88B; Wed, 7 Nov 2012 07:09:07 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F312j6cxq-ST; Wed, 7 Nov 2012 07:09:07 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::422:a1f:978:b77f] (unknown [IPv6:2a02:80:3ffc::422:a1f:978:b77f]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 4EE2B176FB883; Wed, 7 Nov 2012 07:09:07 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <5099A026.8070709@thekelleys.org.uk> Date: Wed, 7 Nov 2012 07:09:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <91787CC9-5305-466E-B102-F9AC063E7995@frobbit.se> References: <5099A026.8070709@thekelleys.org.uk> To: Simon Kelley X-Mailer: Apple Mail (2.1499) Cc: mdnsext@ietf.org Subject: Re: [mdnsext] Differences between mDNS and DNS names. X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 06:09:15 -0000 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 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. >=20 > 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. >=20 > 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. >=20 > Cheers, >=20 > Simon. >=20 > * 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. >=20 >=20 > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext >=20 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD2221F8BD9 for ; Tue, 6 Nov 2012 20:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEcOYSQm381H for ; Tue, 6 Nov 2012 20:30:09 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1276421F8BDB for ; Tue, 6 Nov 2012 20:30:08 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so516010eaa.31 for ; Tue, 06 Nov 2012 20:30:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E0tvAi/tUO8703fkoI415auwlXxuVFYQcsU3f4swivY=; b=cP0/iehy/Pdi2jtkxjNfrAIAESSUIRyjU8pAzAV04B1KYQrPz5EQIRVhEynq+iDF5k 6WRYcmBhOWFJ4zHwARwBUvYDE0ysEViyH+syp/8GJBDiEaBlhJoudCpOO+VyAm+CITt9 d3BKVEKso06PO650GS18q8bWRuiB90kGeW66ESDcMVfJxo/h1uZXbVXrnC+mJUILA/L1 Jtwzc91w2WjuVp5yrWxXB6MtbZKgDGNz1/SXgVaNLCWkwLb5Bxzptr1/2r7yra0TUy0/ ct+Lt2FwEiSweRp7Y+yoq7NSyE87oWeytGAPCKybmh90qZC8W6iBnCNTTjzUcF6Ma5qa G0dA== MIME-Version: 1.0 Received: by 10.14.200.194 with SMTP id z42mr11224855een.13.1352262608137; Tue, 06 Nov 2012 20:30:08 -0800 (PST) Received: by 10.223.145.133 with HTTP; Tue, 6 Nov 2012 20:30:08 -0800 (PST) In-Reply-To: <3980.1352252729@sandelman.ca> References: <3980.1352252729@sandelman.ca> Date: Tue, 6 Nov 2012 23:30:08 -0500 Message-ID: From: Brian Dickson To: Michael Richardson Content-Type: multipart/alternative; boundary=047d7b3440c666abd404cde02ccf Cc: mdnsext@ietf.org Subject: Re: [mdnsext] mDNS "bastion" instead of multicast forwarding X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > > >>>>> "Brian" == Brian Dickson 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 <mcr+ietf@sandelman= .ca> wrote:

>>>>> "Brian" =3D=3D Brian Dickson <brian.peter.dickson@gmail.com>= writes:
=A0 =A0 Brian> I think a useful area to explore, instead, would be the =A0 =A0 Brian> notion from firewall-land of a "bastion host", = which has
=A0 =A0 Brian> presence on multiple links/subnets, and is mDNS-cognizant= ,
=A0 =A0 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, b= ut rather something doing resolution/caching, like a router or maybe a spec= ialized box, with connections on multiple links.

Even if there were more than one such box, with both bo= xes on both links, the idea is that they would recognize each other and &qu= ot;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=A0

--047d7b3440c666abd404cde02ccf-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FC821F88A4 for ; Tue, 6 Nov 2012 18:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.945 X-Spam-Level: X-Spam-Status: No, score=-1.945 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcKlGhQMY9eG for ; Tue, 6 Nov 2012 18:08:08 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id BA7B521F8861 for ; Tue, 6 Nov 2012 18:08:08 -0800 (PST) Received: from sandelman.ca (107-1-119-250-ip-static.hfc.comcastbusiness.net [107.1.119.250]) by relay.sandelman.ca (Postfix) with ESMTPS id 4184981A9; Tue, 6 Nov 2012 20:59:53 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A9486CA0C9; Tue, 6 Nov 2012 20:45:29 -0500 (EST) From: Michael Richardson To: Brian Dickson In-reply-to: References: Comments: In-reply-to Brian Dickson message dated "Tue, 06 Nov 2012 18:07:44 -0500." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 06 Nov 2012 20:45:29 -0500 Message-ID: <3980.1352252729@sandelman.ca> Sender: mcr@sandelman.ca Cc: mdnsext@ietf.org Subject: Re: [mdnsext] mDNS "bastion" instead of multicast forwarding X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 02:08:09 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Brian" =3D=3D Brian Dickson 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. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQmb05AAoJEKD0KQ7Gj3P2PokH/RVFLOiPocqJz4ffClRfPh2n DusJSarjipogak8ysHHB1mSXnIMLg8ML4vowfYOwsyUCpvN3AbuxlRbsZcnKRYSA bDNl5wXPiI8rraXWKm3omaT4HXH5QCtRkm+ba7xc5OQsd1dkypur4xSXJjFlUFnU 4Ikn2yjUwicH83BNuFt9EblAkYlKWMWjh9IwMTPLXDDcnRPmbSOSKn0zuqURlpE6 wg2KdA14dAyB2Wm6e3W/vBmHejfp9pzoeePq7SlNWkzvYKX9p9u2umu/dMCvzjQl 9nMNJ5oGU1MsuTzTDxJsVycpthRFqQo2IwN++bM2vuB11OdiiNVrp44MVUeFgGM= =TFd3 -----END PGP SIGNATURE----- --=-=-=-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A3021F8AFB for ; Tue, 6 Nov 2012 18:07:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYoygQBbhuQl for ; Tue, 6 Nov 2012 18:07:36 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8701F21F8861 for ; Tue, 6 Nov 2012 18:07:36 -0800 (PST) Received: from sandelman.ca (107-1-119-250-ip-static.hfc.comcastbusiness.net [107.1.119.250]) by relay.sandelman.ca (Postfix) with ESMTPS id 18AFC81AC for ; Tue, 6 Nov 2012 20:59:31 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0F9BFCA0C7 for ; Tue, 6 Nov 2012 20:33:48 -0500 (EST) From: Michael Richardson To: "mdnsext@ietf.org" In-reply-to: References: Comments: In-reply-to "Yi Yang (yiya)" message dated "Tue, 06 Nov 2012 22:34:06 +0000." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 06 Nov 2012 20:33:47 -0500 Message-ID: <3621.1352252027@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-00 X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 02:07:40 -0000 --=-=-= 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,=20 "within an Enterprise", or "within an AS". I do not think that University of Wisconsin students need to see printers at University of Toronto... =2D-=20 Michael Richardson =2Don 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= =F9/R -----END PGP SIGNATURE----- --=-=-=-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66E821F8BC8 for ; Tue, 6 Nov 2012 18:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nGOgupoxVP7 for ; Tue, 6 Nov 2012 18:02:37 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 66D9721F8BC6 for ; Tue, 6 Nov 2012 18:02:37 -0800 (PST) Received: from sandelman.ca (107-1-119-250-ip-static.hfc.comcastbusiness.net [107.1.119.250]) by relay.sandelman.ca (Postfix) with ESMTPS id 87C6C81A9 for ; Tue, 6 Nov 2012 20:54:31 -0500 (EST) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0F73DCA0C8 for ; Tue, 6 Nov 2012 20:41:53 -0500 (EST) From: Michael Richardson To: mdnsext@ietf.org In-reply-to: References: Comments: In-reply-to Brian Dickson message dated "Tue, 06 Nov 2012 17:51:57 -0500." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 06 Nov 2012 20:41:52 -0500 Message-ID: <3844.1352252512@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [mdnsext] miniature equine quadrupeds X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 02:02:38 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Brian" =3D=3D Brian Dickson 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: =20=20 [ 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? =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQmbxgAAoJEKD0KQ7Gj3P2P3kH/2EtlELiLSNW/ZbaMx7vOJST WtvnRNajumk3lDQkutk7tdHyP1RBpaWSefU7mwcGG6gSwDxUTcb6YKDs5XV+CGfQ GCgpri7jCWfsk43xbof0FfJ96/tbTiYAZkDITxG87r+HXxdEvG0cdtfYgsrSnBDv LEv9QNDVxYsTFweU+sup+7BOnZa9z916AvwrG4CL6lI+Jd2BB7Q1xbRH3aJP/KgN 2TOADv9N9HqIdWrM7xHBNSe26lYD+ZkscYZjhGdZgIgo5DgL529MpdoW93+eiwbA FMcsBM11Kcey5PpHQwQJ+Uwo+e1vJ1KOsUAlozzhrkv6AvKcMcwPh5ee+YBUo5g= =D/fQ -----END PGP SIGNATURE----- --=-=-=-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5F221F8BD4 for ; Tue, 6 Nov 2012 15:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+Ez8BwWYxrh for ; Tue, 6 Nov 2012 15:41:30 -0800 (PST) Received: from eyas.biff.org.uk (eyas.biff.org.uk [IPv6:2001:41c8:1:519c::20]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5BA21F8BB4 for ; Tue, 6 Nov 2012 15:41:30 -0800 (PST) Received: from cl-1441.lon-02.gb.sixxs.net ([2a01:348:6:5a0::2]:45933 helo=central.thekelleys.org.uk) by eyas.biff.org.uk with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TVslt-0006Vd-Li for mdnsext@ietf.org; Tue, 06 Nov 2012 23:41:29 +0000 Received: from dhcp-16fb.meeting.ietf.org ([130.129.22.251]) by central.thekelleys.org.uk with esmtpa (Exim 4.72) (envelope-from ) id 1TVsls-0006aK-UW for mdnsext@ietf.org; Tue, 06 Nov 2012 23:41:29 +0000 Message-ID: <5099A026.8070709@thekelleys.org.uk> Date: Tue, 06 Nov 2012 23:41:26 +0000 From: Simon Kelley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: mdnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mdnsext] Differences between mDNS and DNS names. X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 23:41:31 -0000 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. Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FB921F8B8F for ; Tue, 6 Nov 2012 15:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wcltm9zAJ34 for ; Tue, 6 Nov 2012 15:29:34 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6140021F8B79 for ; Tue, 6 Nov 2012 15:29:34 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so666802eek.31 for ; Tue, 06 Nov 2012 15:29:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=D7TVYlob0W500EpCOGA9W/H4qiMHBoWX1gq6L3Bk7ec=; b=of0YLfQzymc6VvzMAjUZcBflclEuF1oUZBskjHBdFztUfjkVPSsoEdbhFCOLJDnDVf g5tuxpxEJB49sIDTO3fbx0qpvnYbDhBvA9QwI4E3LWM5b8ywkhMKRxZrh1AC5VkCaUGC QwBhR0l6vyPDH8r7gBSSMmP3ctiX5P6CDI68kJ+OlymzfFA0rooUVrNk6LdJUfE9NIau ndDjRoYQwffiVyZP2LXHhxcBNkp/E8/TKb8aroYSmAy+J3l3xdial23dUB7J93dHDMkq yW5gxVScfyr0ZVsgz5MlUQN3/Jga6vrqX2yy8QnDArTJa3cfrpZgkw+6EehGd7UIiP4T OhKg== MIME-Version: 1.0 Received: by 10.14.0.198 with SMTP id 46mr8674539eeb.21.1352244573598; Tue, 06 Nov 2012 15:29:33 -0800 (PST) Received: by 10.223.145.133 with HTTP; Tue, 6 Nov 2012 15:29:33 -0800 (PST) Date: Tue, 6 Nov 2012 18:29:33 -0500 Message-ID: From: Brian Dickson To: mdnsext@ietf.org Content-Type: multipart/alternative; boundary=047d7b62275e7572a204cddbf94b Subject: [mdnsext] Simple idea for supporting scaling issues with small devices X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 23:29:35 -0000 --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 d= evices 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 oth= er than that, they could all forward their traffic by caching local-net and= forwarding queries for non-local-net (without caching results), to a centr= alized bigger-class box (which needn't be a router - could be a host ap= plication), via unicast.

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

<= /div>
Thoughts?
Brian
--047d7b62275e7572a204cddbf94b-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B8321F8BB3 for ; Tue, 6 Nov 2012 15:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgvBiR58NUkh for ; Tue, 6 Nov 2012 15:23:47 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id CBCE821F8582 for ; Tue, 6 Nov 2012 15:23:46 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so664727eek.31 for ; Tue, 06 Nov 2012 15:23:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+OZSsRhmcfsrEJ1ootG95Cl/mdi6leJUydpT0ROKv/A=; b=fd9fJ/f8q2Ay3TEn73bDS9sWtZ8KH7dCGQ45scnAp7oZZLGCHlaBXofHR+S1InIStL FU7gP5TKRZT6CTBZK/I6VSOqkEENpK7SVihDONG89Vvz/Iww0YhotzwUfwR2GI10BFMX sKXy2GjNPrs0agPopOxltUfBZC4LP3fVFT3ZpffFKWOMxHcMRPa16r1vZKz8CEuctA1e 7lWW0HkMTPqJ08D7orjxurdQU+wmNUQ4ItVL9u9jSYARQLTYS6m+hpyKENFhwUWtF66b cxXy92g6IrY1+QbeVeSTVogv8dx8cV7rHAwfcGXFiFnnckXhZQY6Jjpo4+c3rEh1wMt5 ufnw== MIME-Version: 1.0 Received: by 10.14.0.198 with SMTP id 46mr8625328eeb.21.1352244220278; Tue, 06 Nov 2012 15:23:40 -0800 (PST) Received: by 10.223.145.133 with HTTP; Tue, 6 Nov 2012 15:23:40 -0800 (PST) Date: Tue, 6 Nov 2012 18:23:40 -0500 Message-ID: From: Brian Dickson To: mdnsext@ietf.org Content-Type: multipart/alternative; boundary=047d7b62275e66396604cddbe4f6 Subject: [mdnsext] namespace scope and naming "links" X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 23:23:48 -0000 --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 names= pace 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. print= ers) 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 p= refix(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 sa= me time, address-collisions between different "local" instances i= s 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 av= oid 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 nee= d to cross link boundaries, i.e. inter-link, they would be name.enough.subn= et.for.uniqueness.


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 wel= l in scoping the service discovery and traffic, I think.

Thoughts?

Brian
--047d7b62275e66396604cddbe4f6-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379FF21F8BBA for ; Tue, 6 Nov 2012 15:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4eS4k-SUtpW for ; Tue, 6 Nov 2012 15:07:46 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 12E0A21F8B77 for ; Tue, 6 Nov 2012 15:07:45 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so444537eaa.31 for ; Tue, 06 Nov 2012 15:07:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yoxyuSjkaEgjWwFeVaeW6KloqZfcirItLSSYXiK55XY=; b=oIvAeNrKwkftalGDDsHtQ75XuvkiAY6Ezl9Br4UNSMhO9NBjBtcFzixJKUD9ap05YN gdSK2d8vVk99PZnXcPTCBrQ5xlvFPV77AoWzbjzIU5tHpYP6cQ8rr7LF805qUgvRtw1D SGhHLYzU+t02ZsRBvPPly0A4BLWTX7ceAFnMoMk0gnbb5K/sfX6kgLU0OqsmZ0ifHGoA BSIVllgEhZrO5nTCKqFglWjK8AV6QDvJv91PUtci7tmbX2lvMIULh0JMmO2gHy1G5puQ rycGnBtIW82plQiFZIWnkLSsdIFNd06yuYjbWLImh4aT/Qe81F+WoaXxgeYLHbocBz/g /9kw== MIME-Version: 1.0 Received: by 10.14.182.9 with SMTP id n9mr8457150eem.24.1352243265021; Tue, 06 Nov 2012 15:07:45 -0800 (PST) Received: by 10.223.145.133 with HTTP; Tue, 6 Nov 2012 15:07:44 -0800 (PST) Date: Tue, 6 Nov 2012 18:07:44 -0500 Message-ID: From: Brian Dickson To: mdnsext@ietf.org Content-Type: multipart/alternative; boundary=047d7b34388476256b04cddbab3d Subject: [mdnsext] mDNS "bastion" instead of multicast forwarding X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 23:07:47 -0000 --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).

I th= ink a useful area to explore, instead, would be the notion from firewall-la= nd of a "bastion host", which has presence on multiple links/subn= ets, 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 beha= vior that is sensible
- user administrative controls that allow g= ood things
- preventing (at all costs) any exposure to user-supplied configuratio= ns that can break a network
- scalable behavior that supports mul= tiple use cases

And the basic primitive functional= ity would be:
An mDNS "thing" that is able to "speak" on two sub= nets, and which has mDNS data concerning both subnets, which acts as some k= ind 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, an= d 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-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458D621F8BBF for ; Tue, 6 Nov 2012 14:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2v8gm8Re+BH for ; Tue, 6 Nov 2012 14:51:58 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5600921F8BB4 for ; Tue, 6 Nov 2012 14:51:58 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id d4so652583eek.31 for ; Tue, 06 Nov 2012 14:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=XlJJt98tZ29GkMCTTNvGXoYM7rncpPDMYUlHQ2xpr28=; b=cB9cNxo4tBjD9GkW1W0ngvwBcO1JxiqUHsqYnjLIjk6w+n36aV6OHGFwEn2L7NDrkp lm4yIBQB+LXeV9ZOi1TwN18genEbklZY26qal0M255xYcJBBii8jdJwnuHebOLO7P9RS g49NJdb5HyewngkgHVRs0C09mNTKDbKTn6ICUBoT/T6tTuXrFOFLJpzsBBV2BOKYoMjW loM8YvaYyMG35woa36iosXlI5pLzHXYTajpx70EJJtHjbrYeWWMHvCVWz/w+u08A0n8Q d0kX50Kgk42UzS6ClBs3ceLp9FSXBhImRzbBHrzs/5ZkpmHY038+BzGGYzR9acZ0DlV6 YSoQ== MIME-Version: 1.0 Received: by 10.14.174.194 with SMTP id x42mr8371621eel.22.1352242317333; Tue, 06 Nov 2012 14:51:57 -0800 (PST) Received: by 10.223.145.133 with HTTP; Tue, 6 Nov 2012 14:51:57 -0800 (PST) Date: Tue, 6 Nov 2012 17:51:57 -0500 Message-ID: From: Brian Dickson To: mdnsext@ietf.org Content-Type: multipart/alternative; boundary=047d7b621edef9941504cddb72c1 Subject: [mdnsext] miniature equine quadrupeds X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 22:51:59 -0000 --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'd like to suggest use-case-like examples of what would be a "pon= y", and what would facilitate remote accessibility of mDNS-enabled ser= vices without having a "pony".

Here is what An= drew Sullivan was talking about, which would be classified as a "pony&= quot;:


(Note th= at the things to the left of .local. are generally what mDNS would allow, a= nd what are prohibited by global DNS rules.)

Here is how I think things could work "just fine&q= uot;, modulo other aspects of mDNS:

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

=A0-> user needs to know FQDN of home gateway, either via service-provid= er-facilitated name (ugly), or via user-managed "vanity" domain u= pdated via Dynamic DNS (pretty).

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

=A0 =A0 =A0mac-aa-bb-cc-dd-ee-ff.city.cable-co.example.net<= /div>
or

Optional User Activity: authenticate to Home Network Ro= uter

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

So, there would never be direct merger of global DNS na= mespace with mDNS "local" namespace. The global DNS would be a se= rvice-discovery-discovery mechanism. =A0Global and local are effectively sh= ips-in-the-night, and the global DNS folks sleep well at night.

Thoughts?

Brian
--047d7b621edef9941504cddb72c1-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2C821F8B88 for ; Tue, 6 Nov 2012 14:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IruRGC6bDMey for ; Tue, 6 Nov 2012 14:50:48 -0800 (PST) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6334F21F8B67 for ; Tue, 6 Nov 2012 14:50:48 -0800 (PST) Received: from dhcp-5493.meeting.ietf.org (dhcp-5493.meeting.ietf.org [130.129.84.147]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 4718111A7B for ; Tue, 6 Nov 2012 17:48:32 -0500 (EST) From: Tom Pusateri Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 6 Nov 2012 17:50:55 -0500 To: "mdnsext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [mdnsext] Forwarding link-local IP multicast X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 22:50:49 -0000 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= Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1520E21F8BA2 for ; Tue, 6 Nov 2012 14:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A99vFHUKQsKF for ; Tue, 6 Nov 2012 14:34:13 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8F41221F8B99 for ; Tue, 6 Nov 2012 14:34:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=231; q=dns/txt; s=iport; t=1352241253; x=1353450853; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=psobzuIuNyURLGK4bgbDUYCeaC0Q8rENMTv71nyG8xU=; b=IhpBB+FrRK/NSGSBhugUi2Jn8SxjpYUguuY4/kGlj11ZjpiObRVsDkZ9 4h/KY0lYSrAElh0lmqoJjDmyktoV1DzEDTUqKJ2sbKcMGzB+/c9kGfOJB 858llDmX3OyTxuiA7q7gf+RV/RcQIqhJWThsXPJq1r46Ixv+44+z0h2iH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8IAKiPmVCtJXG9/2dsb2JhbABEw1aBAQeCIAEEEgEnUQEIIhRCJwQbGodomhuBK49ikC+Rd2EDpFSBa4Jvghk X-IronPort-AV: E=Sophos;i="4.80,724,1344211200"; d="scan'208";a="139493640" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 06 Nov 2012 22:34:08 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA6MY8PO032365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 6 Nov 2012 22:34:08 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.239]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 16:34:07 -0600 From: "Yi Yang (yiya)" To: "mdnsext@ietf.org" Thread-Topic: [mdnsext] draft-lynn-mdnsext-requirements-00 Thread-Index: AQHNvG7UHGXXMh9R+UqJHMdxFuaNVw== Date: Tue, 6 Nov 2012 22:34:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.255.142] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002 x-tm-as-result: No--21.119900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <4FF5086742A5F0489A48836C184B386D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mdnsext] draft-lynn-mdnsext-requirements-00 X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 22:34:14 -0000 For the user interface, in addition that it should be short and showing onl= y 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 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0976B21F8995 for ; Tue, 6 Nov 2012 06:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dE0cj-VyFhXW for ; Tue, 6 Nov 2012 06:11:27 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id EDFF521F8925 for ; Tue, 6 Nov 2012 06:11:26 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id qA6EBLIh016390 for ; Tue, 6 Nov 2012 14:11:21 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk qA6EBLIh016390 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1352211081; bh=6xOa3EOYm6rUHzsKLP30qaMdq1w=; h=From:Subject:Date:To:Mime-Version:References; b=i4lwHW6+rqJF9q8mTaZhqSmq/v7B5/hrk7XUaaC069GMWU6k4i9trLcP54TIrjTec He7eh3HE9AWgivIPp0teBXpXuv0JqP2psq5CWwuZ7lyrdEV8alLNDJy+i3+IXYr49/ yfZoHAE3+VIpbC4AYxFB3xodLmmiLUsnAp0xVGo4= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id oA5EBL0430600121wY ret-id none; Tue, 06 Nov 2012 14:11:21 +0000 Received: from dhcp-1343.meeting.ietf.org (dhcp-1343.meeting.ietf.org [130.129.19.67]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id qA6EBCov024967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 6 Nov 2012 14:11:13 GMT From: Tim Chown Content-Type: multipart/alternative; boundary="Apple-Mail=_66C47AA8-BACB-432D-BFE7-2DD1AF9505A7" Message-ID: Date: Tue, 6 Nov 2012 14:11:12 +0000 To: "mdnsext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=oA5EBL043060012100; tid=oA5EBL0430600121wY; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 References: <191090D3-111B-4AC1-847E-1A590B173E39@ecs.soton.ac.uk> X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: qA6EBLIh016390 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [mdnsext] BoF today, minuter taker and Jabber relay needed X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 14:11:28 -0000 --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. =20= 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=20 1520-1650 Afternoon Session II=20 Grand Ballroom C =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D *=20 * Administravia (10 mins) =20 Note Well =20 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 https://da= tatracker.ietf.org/meeting/85/materials.html.
Remote = participation details are here: http://w= ww.ietf.org/meeting/85/remote-participation.html

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

Tim


Extensions of the Bonjour Protocol Suite (mdnsext) = BoF

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

Grand Ballroom = C

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =  * 

* 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-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEC821F865E for ; Sun, 4 Nov 2012 09:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlC8EocLWdMJ for ; Sun, 4 Nov 2012 09:06:01 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 02FA521F8667 for ; Sun, 4 Nov 2012 09:05:55 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id k13so2254327eaa.31 for ; Sun, 04 Nov 2012 09:05:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fo4aksCUU/6hOS4BeLaT1RxmeoBOHUwkHl/4Eid8gMk=; b=aZYsZ9Z/EcV/bl7jGbVldLQSiDXobm5DbbCtAzJWzyHCyOKOy7Z8AyS152gRKmhIXI R+ogsgj5wIp1KYSsvzqVoMPWBgfEpNWyTK5KryBqTCzFsjsZIY7AVOZfM9mUf42FuBwP eLsmvS4NsOEmgUYIw0u86+3nJmWlRtPthddZA07WvA2/PKuiVa6kTVtQHh1CdKh9SsHi clIybP1JaYIP/6u5SF/Jl4JVEXd9kdKCh5HQVlACf8iDXU7bp1nPnwhpAypW1F0ULDb3 ebT6eAI4mxJdy2WF/tctD55M6NMHVXWpyAevIIv9vVmBDJ8735a8tuPfGleUoUW43Q9T 2fiw== MIME-Version: 1.0 Received: by 10.14.184.2 with SMTP id r2mr27594042eem.43.1352048755202; Sun, 04 Nov 2012 09:05:55 -0800 (PST) Received: by 10.14.28.136 with HTTP; Sun, 4 Nov 2012 09:05:55 -0800 (PST) In-Reply-To: References: Date: Sun, 4 Nov 2012 12:05:55 -0500 Message-ID: From: Indtiny s To: Ray Bellis Content-Type: multipart/alternative; boundary=047d7b343934c5dafa04cdae6182 Cc: "" , Kerry Lynn Subject: Re: [mdnsext] xmDNS support in mdnsresponder for homenet X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 17:06:03 -0000 --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,

Thanks for=A0providing=A0the useful suggestion , due= to some urgent=A0requirement=A0I have to support the xmDNS support =A0with= TLD name "site" .=A0

Can someone help m= e , How and what exactly I can start with mdnsresponder code(particularly= =A0changing=A0the multicast address) =A0,=A0in-order=A0support the homenet = RFC ..?

Rgds
Indra

=A0
--047d7b343934c5dafa04cdae6182-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E225E21F8511 for ; Thu, 1 Nov 2012 01:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+5SHIDR10Ow for ; Thu, 1 Nov 2012 01:19:41 -0700 (PDT) Received: from mx4.nominet.org.uk (mail.nominet.org.uk [213.248.199.24]) by ietfa.amsl.com (Postfix) with ESMTP id BE43121F84A8 for ; Thu, 1 Nov 2012 01:19:39 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: MIME-Version; b=1iX2/DdrZthc7cZRUtH9aXTY617r76IaNGow5UQ6+6mx6vRrbWd9mQxW V8m1mq97VB7nWIN5PAaVWxcHXIjN79QawD8jgu3LDjN9sjKFFMtKe1tNQ IDHrIYrlP/G9qgu; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1351757980; x=1383293980; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[mdnsext]=20xmDNS=20support=20in=20mdns responder=20for=20homenet|Date:=20Thu,=201=20Nov=202012 =2008:19:36=20+0000|Message-ID:=20|To:=20Indtiny=20s=20|CC:=20Kerry=20Lynn=20,=20" "=20|MIME-Version:=20 1.0|In-Reply-To:=20|References:=20=0D=0A=20=0D=0A=20; bh=bAZ5cV0eBG7HuO+N1ee1nhBLR1iwp/xkUKdjU2rvu9U=; b=Q6sHrVpjzamkNHE1kvSJDMzvCMhVDkP0mAyuP3PdMcmlQbq2t5xflOGW AX9l7gD37041tHHf6reAfkSXJ2NokxMa77OV1EH4gTbiyJX0jStVqwn3F Twu6qDHaiMjjMcW; X-IronPort-AV: E=Sophos;i="4.80,692,1344207600"; d="scan'208,217";a="36450783" Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx4.nominet.org.uk with ESMTP; 01 Nov 2012 08:19:38 +0000 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi; Thu, 1 Nov 2012 08:19:37 +0000 From: Ray Bellis To: Indtiny s Thread-Topic: [mdnsext] xmDNS support in mdnsresponder for homenet Thread-Index: AQHNt4SkuAgGzPtRkU69vI01Xg2UapfUpDgA Date: Thu, 1 Nov 2012 08:19:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F4E943980D37459A865D6C36372343AFnominetorguk_" MIME-Version: 1.0 Cc: "" , Kerry Lynn Subject: Re: [mdnsext] xmDNS support in mdnsresponder for homenet X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 08:19:42 -0000 --_000_F4E943980D37459A865D6C36372343AFnominetorguk_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 31 Oct 2012, at 16:27, Indtiny s > wrote: Hi, The document is almost concluded the basic status . http://tools.ietf.org/h= tml/draft-lynn-homenet-site-mdns-01 Due to some urgent requirment I need to go with adding the basic ".site" d= omain ,i.e Any DNS query for a name ending with ".site." MUST be sent to th= e xmDNS multicast address (FF05::FB ) and its IPv4 equivalent to 239.255.25= 5.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', IMH= O 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: Content-Transfer-Encoding: quoted-printable
On 31 Oct 2012, at 16= :27, Indtiny s <indtiny@gmail.com> wrote:

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

Due to some ur= gent 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 ve= ry 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 be= en applied for in the current round of new gTLD applications.

Just sayin'

Ray

= --_000_F4E943980D37459A865D6C36372343AFnominetorguk_--