From owner-zeroconf@merit.edu Sun Sep 1 05:56:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11960 for ; Sun, 1 Sep 2002 05:56:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 59FE591203; Sun, 1 Sep 2002 05:57:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27EB291210; Sun, 1 Sep 2002 05:57:35 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C16A91203 for ; Sun, 1 Sep 2002 05:57:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 266C95DE46; Sun, 1 Sep 2002 05:57:34 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id BEDED5DE44 for ; Sun, 1 Sep 2002 05:57:33 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14986; Sun, 1 Sep 2002 03:57:32 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g819vTl17489; Sun, 1 Sep 2002 11:57:29 +0200 (MEST) Date: Sun, 1 Sep 2002 11:56:45 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: james mcmurry Cc: Zeroconf Subject: Re: Slightly OT: Apple to Release Source Code to its zeroconf implementation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk It is important to distinguish between Rendezvous and ZEROCONF. Rendezvous may be inspired by or even based on work in the ZEROCONF working group (address autoconfiguration and the requirements documents), but these are not yet RFCs. The zeroconf requirements themselves are not a specification, they cannot be 'implemented.' Further, the naming and service discovery components of Rendezvous are neither work items of the ZEROCONF nor any other working group. I wish Apple great success with their product and open source efforts, but it is indeed off topic - and it is NOT an implementation of ZEROCONF specifications. I encourage those who wish to discuss Rendezvous to join a mailing list devoted to that topic. Best regards, Erik Guttman ZEROCONF WG cochair From owner-zeroconf@merit.edu Sun Sep 1 06:03:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12141 for ; Sun, 1 Sep 2002 06:03:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C827291210; Sun, 1 Sep 2002 06:04:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9213491221; Sun, 1 Sep 2002 06:04:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 85C1A91210 for ; Sun, 1 Sep 2002 06:04:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6705F5DE44; Sun, 1 Sep 2002 06:04:03 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id D02625DDF5 for ; Sun, 1 Sep 2002 06:04:02 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA21660 for ; Sun, 1 Sep 2002 04:04:01 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g81A3xl17648 for ; Sun, 1 Sep 2002 12:03:59 +0200 (MEST) Date: Sun, 1 Sep 2002 12:03:14 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: ZEROCONF WG mailing list discussion Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The zeroconf mailing list is devoted to completing the work we have in front of us: - completing the zeroconf requirement document - completing the IPv4 address allocation document We specifically do not have the charter to specify any naming or service discovery protocol beyond their requirements. Please strive to restrict your postings to topics within the working group charter. If you feel the charter should be changed, we can of course discuss this. Regards, Erik From owner-zeroconf@merit.edu Sun Sep 1 22:00:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01745 for ; Sun, 1 Sep 2002 22:00:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 32FE69120F; Sun, 1 Sep 2002 22:01:33 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9960091213; Sun, 1 Sep 2002 22:01:20 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D39449120F for ; Sun, 1 Sep 2002 22:01:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A30135DE74; Sun, 1 Sep 2002 22:01:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 2DE4A5DD95 for ; Sun, 1 Sep 2002 22:01:08 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g82211012689; Sun, 1 Sep 2002 22:01:01 -0400 (EDT) Message-Id: <200209020201.g82211012689@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Zeroconf Subject: Re: hypocrisy of zeroconf In-reply-to: (Your message of "Fri, 30 Aug 2002 11:21:02 PDT.") <3D5C009A-BC45-11D6-BE61-000393760260@apple.com> Date: Sun, 01 Sep 2002 22:01:01 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > There is nothing about the zeroconf proposals that "redefines IP to > work differently than applications expect". An application that uses IP > can continue to transparently do so with an IPv4 link local address > without knowing the difference. this is simply false. normal IPv4 addresses have global scope and can be used in referrals without the application having to be aware of network topology. normal IPv4 addresses are globally unique and can be addressed without the application having to worry about which network interface to use. normal IPv4 addresses do not become invalid at a whim (absent device failure). applications that treat IPv4LL addresses like they are normal addresses will fail for unexpected reasons when those apps try to use them in referrals to devices on other interfaces or other links, and when those addresses suddenly stop working due to conflicts. but you knew this already. Keith From owner-zeroconf@merit.edu Sun Sep 1 22:02:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01779 for ; Sun, 1 Sep 2002 22:02:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 35CFE91213; Sun, 1 Sep 2002 22:03:56 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFC209121E; Sun, 1 Sep 2002 22:03:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D94D291213 for ; Sun, 1 Sep 2002 22:03:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B7C675DE74; Sun, 1 Sep 2002 22:03:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 498F55DD95 for ; Sun, 1 Sep 2002 22:03:53 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8223o012742; Sun, 1 Sep 2002 22:03:50 -0400 (EDT) Message-Id: <200209020203.g8223o012742@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: "Zeroconf" Subject: Re: Slightly OT: Apple to Release Source Code to its zeroconf implementation In-reply-to: (Your message of "Fri, 30 Aug 2002 12:34:22 PDT.") <200208301934.g7UJYJ304146@scv3.apple.com> Date: Sun, 01 Sep 2002 22:03:50 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > Zeroconf is NOT an IETF Standard (yet). Stuart, if you're claming that zeroconf is ANY kind of standard, then you're misleading people. And what Apple and Microsoft have been shipping for most of the past four years differs in very important ways from what is in the current linklocal spec. Keith From owner-zeroconf@merit.edu Sun Sep 1 22:49:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02510 for ; Sun, 1 Sep 2002 22:49:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 234EF9121E; Sun, 1 Sep 2002 22:50:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E76A291222; Sun, 1 Sep 2002 22:50:30 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B691E9121E for ; Sun, 1 Sep 2002 22:50:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 98C505DE77; Sun, 1 Sep 2002 22:50:29 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 388755DD95 for ; Sun, 1 Sep 2002 22:50:29 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA24862 for ; Sun, 1 Sep 2002 22:50:28 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA06146 for ; Sun, 1 Sep 2002 22:47:09 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id WAA05458 for ; Sun, 1 Sep 2002 22:47:08 -0400 (EDT) Date: Sun, 1 Sep 2002 22:47:07 -0400 Subject: Re: hypocrisy of zeroconf Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200209020201.g82211012689@astro.cs.utk.edu> Message-Id: <457C1370-BE1E-11D6-93FC-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday, September 1, 2002, at 10:01 PM, Keith Moore wrote: >> There is nothing about the zeroconf proposals that "redefines IP to >> work differently than applications expect". An application that uses >> IP >> can continue to transparently do so with an IPv4 link local address >> without knowing the difference. > > this is simply false. No, it's conditionally false, or true, depending on how you look at it. Depending on the network in question, this will work. Or, it will not. But there is nothing in zeroconf that breaks IPv4. > > normal IPv4 addresses have global scope and can be used in referrals > without the application having to be aware of network topology. partially correct. Normal IPv4 addresses have whatever scope the network they are on chooses to allow them to have. There is no requirement for IPv4, or IPv6 for that matter to have (physical) global scope. They need scope in relation to the job at hand for the device. For example, a printer that is only used by a small group of people only needs scope on that scale. It does not need to have it's own world-wide address. There are many networks that, for various reasons, don't need world-wide scope for their addresses. This is one of the things that is causing a perceptual problem with Zeroconf. Address scope. If you work in a situation where ever IP address must have (physical) global scope, then Zeroconf potentially is a real problem. However, in many situations, and the majority of corporate situations, this is not the case. IP addresses are private, and the only external Internet access is carefully limited and monitored. So for these situations, the 'normal' mode for IPv4 addresses are immaterial, as access to the rest of the world on a constant or casual basis is neither desirable or allowable. In these situations, Zeroconf is almost completely positive in potential. > > normal IPv4 addresses are globally unique and can be addressed > without the application having to worry about which network > interface to use. They *can* be globally unique. They don't have to be. They only have to be unique for the scope of use. > > normal IPv4 addresses do not become invalid at a whim (absent device > failure). DHCP lease expirations without a renewal invalidate IP addresses. > > applications that treat IPv4LL addresses like they are normal addresses > will fail for unexpected reasons when those apps try to use them in > referrals to devices on other interfaces or other links, and when those > addresses suddenly stop working due to conflicts. In cases where this is not appropriate, there is nothing in Zeroconf that prevents you from using other methods of IP address assignment. Indications to the contrary are incorrect. Zeroconf is not a binary standard. It is designed to co-exist with other network setups. IPv6 and v4 are able to coexist on the same network, despite being radically different in many ways. The same holds true for Zeroconf. john From owner-zeroconf@merit.edu Sun Sep 1 22:51:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02580 for ; Sun, 1 Sep 2002 22:51:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 37CF791222; Sun, 1 Sep 2002 22:53:06 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1D1291223; Sun, 1 Sep 2002 22:53:05 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E784A91222 for ; Sun, 1 Sep 2002 22:53:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C7A2C5DE77; Sun, 1 Sep 2002 22:53:04 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 683305DD95 for ; Sun, 1 Sep 2002 22:53:04 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id WAA02377 for ; Sun, 1 Sep 2002 22:53:03 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA06336 for ; Sun, 1 Sep 2002 22:49:45 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id WAA05857 for ; Sun, 1 Sep 2002 22:49:45 -0400 (EDT) Date: Sun, 1 Sep 2002 22:49:44 -0400 Subject: Re: Slightly OT: Apple to Release Source Code to its zeroconf implementation Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200209020203.g8223o012742@astro.cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday, September 1, 2002, at 10:03 PM, Keith Moore wrote: >> Zeroconf is NOT an IETF Standard (yet). > > Stuart, if you're claming that zeroconf is ANY kind of standard, then > you're misleading people. Define 'industry standard'. Real world, it's whatever the industry wants it to be. Java is a great example of an industry standard. > > And what Apple and Microsoft have been shipping for most of the past > four years differs in very important ways from what is in the current > linklocal spec. Um...Apple only started shipping Rendezvous August 24th. Prior to that, the only way to assign addresses was: 1) Manually 2) DHCP 3) Bootp 4) PPPoE 5) PPP Microsoft is another story altogether. But you can't tar both companies with the same brush if you trying to be fair about things. john From owner-zeroconf@merit.edu Sun Sep 1 23:00:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02743 for ; Sun, 1 Sep 2002 23:00:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1609A91223; Sun, 1 Sep 2002 23:01:32 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4B3E91224; Sun, 1 Sep 2002 23:01:31 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D12591223 for ; Sun, 1 Sep 2002 23:01:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 780F25DD95; Sun, 1 Sep 2002 23:01:29 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from home.karahalios.org (alexk-3.dsl.speakeasy.net [216.254.7.224]) by segue.merit.edu (Postfix) with ESMTP id 890F65DE77 for ; Sun, 1 Sep 2002 23:01:28 -0400 (EDT) Received: from usr2.Karahalios.org (usr2.Karahalios.org [192.168.2.2]) by home.karahalios.org (8.11.1/8.10.1) with ESMTP id g8231R915593 for ; Sun, 1 Sep 2002 20:01:27 -0700 Date: Sun, 1 Sep 2002 20:01:27 -0700 Subject: Re: Slightly OT: Apple to Release Source Code to its zeroconf implementation Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: Alex Karahalios To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <45BAE294-BE20-11D6-A3EF-00039377AD70@Outersoft.com> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, Not to pick any nits here, but Apple had link local addressing prior to Rendezvous. I think it's even mentioned in one of the zeroconf drafts. Alex Karahalios On Sunday, September 1, 2002, at 07:49 PM, John C. Welch wrote: > Um...Apple only started shipping Rendezvous August 24th. Prior to > that, the only way to assign addresses was: From owner-zeroconf@merit.edu Sun Sep 1 23:17:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02923 for ; Sun, 1 Sep 2002 23:17:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5954691224; Sun, 1 Sep 2002 23:17:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F61691227; Sun, 1 Sep 2002 23:17:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EC97E91224 for ; Sun, 1 Sep 2002 23:17:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CB81B5DE77; Sun, 1 Sep 2002 23:17:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by segue.merit.edu (Postfix) with ESMTP id D15065DD95 for ; Sun, 1 Sep 2002 23:17:12 -0400 (EDT) Received: from ilister.dialup.dstc.edu.au (ilister.dialup.dstc.edu.au [130.102.182.103]) by piglet.dstc.edu.au (8.12.3/8.12.3) with ESMTP id g823GlMB025729; Mon, 2 Sep 2002 13:16:49 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id g823Gfg86364; Mon, 2 Sep 2002 13:16:41 +1000 (EST) (envelope-from ilister@lister.dnsalias.net) Date: Mon, 2 Sep 2002 13:16:40 +1000 (EST) From: Ian Lister X-X-Sender: To: Keith Moore Cc: Zeroconf Subject: Re: hypocrisy of zeroconf In-Reply-To: <200209020201.g82211012689@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checked: SPAMASSASSIN: This message probably not SPAM X-Spam-Score: -4.4, Required: 5 X-Virus-Scanned: Message: ok X-Scanned-By: MIMEDefang 2.9 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-zeroconf@merit.edu Precedence: bulk On Sun, 1 Sep 2002, Keith Moore wrote: >normal IPv4 addresses have global scope and can be used in referrals >without the application having to be aware of network topology. This statement is false. RFC 1918 has been around for quite some time now. NAT is related and certainly broke a few applications, but that's very different from non-global addressing (and people who use it find the benefits far outweigh the drawbacks). Do you have similar problems with RFC 1918? >normal IPv4 addresses are globally unique and can be addressed >without the application having to worry about which network >interface to use. The first part of this statement is also false (because RFC 1918 already stops addresses from being globally unique). The second part of this statement is misleading because IPv4LL addresses will not start breaking applications on multihomed hosts. Section 3 of the draft covers this issue in detail, and the only case in which applications might need extra knowledge about how interfaces relate to addresses is the third case, in which APIs are updated to explicitly deal with the issue. The requirement to update existing applications is explicit and any implementor choosing this path would be fully aware of that need. (FWIW I can't see anybody choosing that path for an existing platform with substantial existing applications). >normal IPv4 addresses do not become invalid at a whim (absent device >failure). Although the definition of `whim' might be open to debate, I think this statement is largely false too. DHCP made it explicit that addresses can change (and the application sees it as a whim[0]). Even before that, users could (and still can) change their address manually (at a whim, or for some other reason). Some popular platforms used to demand a reboot when this happened (often the subject of ridicule from people using systems that were quite happy to change addresses at a whim with no ill effects), but I'm not aware of any that still do. The worst case is just that an existing connection is broken and the application has to reestablish it. Given the low frequency with which this is likely to occur (it requires two hosts who have already successfully claimed and started using the same address - about 1 in 2^16 probability - to begin seeing each others' frames) it puts it in the same category as DHCP leases expiring and users manually renumbering. Address change has been happening for a long time and applications that don't deal with it are already broken. IPv4LL doesn't change this. >applications that treat IPv4LL addresses like they are normal addresses >will fail for unexpected reasons when those apps try to use them in >referrals to devices on other interfaces or other links, and when those >addresses suddenly stop working due to conflicts. Do you have any examples of applications that will break like this? To refer to the theme of earlier discussion, having conducted your analysis and found alleged flaws, can you construct a realistic test case in which those flaws are exposed? Do your applications that might be broken by this work with DHCP, RFC 1918, and/or manual readdressing (not to mention NAT)? Do you think that even if such applications do exist their inability to correctly function on IPv4LL networks should prevent IPv4LL from being used at all, regardless of whether its users want to use these applications or not? Would (any of) your concerns be satisfied if the draft described the (currently implemented and widely deployed) behaviour of assigning an IPv4LL address iff no other address was available (rather than its current recommendation of assigning IPv4LL regardless of existing addresses). >but you knew this already. We've been told it a lot of times, but still haven't had the evidence presented. Ian [0] Unless it has been querying the OS to check on the duration of a lease. Of course an IPv4LL implementation can provide support for such behaviour by simply reporting its address as being from a very short lease. From owner-zeroconf@merit.edu Sun Sep 1 23:53:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03400 for ; Sun, 1 Sep 2002 23:53:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 46F9891228; Sun, 1 Sep 2002 23:54:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0CC7891229; Sun, 1 Sep 2002 23:54:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B5B2191228 for ; Sun, 1 Sep 2002 23:54:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 983E85DE7A; Sun, 1 Sep 2002 23:54:37 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 2CF7D5DE79 for ; Sun, 1 Sep 2002 23:54:37 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g823sW013714; Sun, 1 Sep 2002 23:54:32 -0400 (EDT) Message-Id: <200209020354.g823sW013714@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ian Lister Cc: Keith Moore , Zeroconf Subject: Re: hypocrisy of zeroconf In-reply-to: (Your message of "Mon, 02 Sep 2002 13:16:40 +1000.") Date: Sun, 01 Sep 2002 23:54:32 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > On Sun, 1 Sep 2002, Keith Moore wrote: > >normal IPv4 addresses have global scope and can be used in referrals > >without the application having to be aware of network topology. > > This statement is false. RFC 1918 has been around for quite some time now. RFC 1918 is intended for private networks - that is networks that are disconnected from the Internet. RFC 1918 addresses don't cause any problems with referrals for such networks because it's impossible for addresses to leak out of a disconnected network. NATted networks are a completely different matter, of course, and NATs do cause problems - but they cause problems regardless of whether or not they use RFC 1918 addresses. > >normal IPv4 addresses are globally unique and can be addressed > >without the application having to worry about which network > >interface to use. > > The first part of this statement is also false (because RFC 1918 already > stops addresses from being globally unique). again, if you're on a disconnected network, then a RFC 1918 address is already unique within that network, so it's no problem. similarly, if people want to use IPv4 LL addresses on completely disconnected network, I have no problem with that either. OTOH the imposition of IPv4 LL addresses onto networks that are connected to the public internet (or to other networks) does cause problems for applications. > The second part of this > statement is misleading because IPv4LL addresses will not start breaking > applications on multihomed hosts. false. if an app resides on a host that has multiple interfaces that support LL addresses, the host in general has no idea which interface to use to contact an LL address, and it's possible that the same LL address is available on multiple interfaces. The idea that the host can get the interface from the connection state isn't a general solution- it only works for incoming traffic and for conneciton-oriented protocols. I haven't reviewed the latest draft (will do so before the end of Last Call) but basically there's no way to fix this problem and still be compatible with existing APIs. So yes, this is a fundamental change to the way that IP works, and yes, it will break applications that are unfortunate enough to encounter duplicate addresses. > >normal IPv4 addresses do not become invalid at a whim (absent device > >failure). > > Although the definition of `whim' might be open to debate, I think this > statement is largely false too. DHCP made it explicit that addresses can > change (and the application sees it as a whim[0]). The fact that you can break a network by misconfiguring a DHCP server is not a license for the zeroconf WG to break it in other ways. > Even before that, users > could (and still can) change their address manually yes, and they can turn off their workstations, or unplug them from the network, or hit them with sledge hammers. but we never have expected the network or applications to recover from such failures. Linklocal is forcing new failure modes on essentially every host on the internet and expecting applications to recover from such failures. > The worst case is just that an > existing connection is broken and the application has to reestablish it. false. it's simply incorrect to assume that such failures are recoverable. in general, there is no other name by which the peer process can reliably be contacted, and for many applications successful recovery from broken connections requires explicit support in the application-level protocol. > Given the low frequency with which this is likely to occur (it requires > two hosts who have already successfully claimed and started using the same > address - about 1 in 2^16 probability - to begin seeing each others' > frames) > it puts it in the same category as DHCP leases expiring and users > manually renumbering. Address change has been happening for a long time > and applications that don't deal with it are already broken. false. essentially zero existing applications can transparently recover from address changes, and the current Internet architecture doesn't provide enough hooks to allow applications to do so in general. there's no other reliable name for a peer socket/process than address+port. > >applications that treat IPv4LL addresses like they are normal addresses > >will fail for unexpected reasons when those apps try to use them in > >referrals to devices on other interfaces or other links, and when those > >addresses suddenly stop working due to conflicts. > > Do you have any examples of applications that will break like this? yes. pvm. netsolve. globus. > Do your applications that might be broken by this work with DHCP, RFC > 1918, and/or manual readdressing (not to mention NAT)? so what you are saying is that because DHCP and RFC 1918 and NATs are sometimes misused, that this group has the right to force everyone to accept the same failure modes that result from misuse of these other technologies? > Do you think that even if such applications do exist their inability to > correctly function on IPv4LL networks should prevent IPv4LL from being > used at all, regardless of whether its users want to use these > applications or not? let's take two separate cases: a) is this sufficient for proposed standard? I want to read the latest draft just to be sure, but based on earlier drafts, I don't think so. It has known technical deficiencies with respect to the reqiurements placed on it. b) should users be able to use this if they want to? sure, but it shouldn't be forced on their hosts and applications, and it shouldn't be used on connected IP networks - at least, not without some way to keep it from interfering with apps that aren't equipped to deal with it. by all means, use it in disconnected networks. > Would (any of) your concerns be satisfied if the draft described the > (currently implemented and widely deployed) behaviour of assigning an > IPv4LL address iff no other address was available (rather than its current > recommendation of assigning IPv4LL regardless of existing addresses). yes. the behavior of earlier implementaitons was far preferable to what the current recommendation requires. > >but you knew this already. > > We've been told it a lot of times, but still haven't had the evidence > presented. no, it's been presented multiple times - there's just a lack of willingness to accept it because it illustrates fundamental problems with v4 linklocal addresses that are not easily fixed. Keith From owner-zeroconf@merit.edu Mon Sep 2 00:04:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03555 for ; Mon, 2 Sep 2002 00:04:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6E45A91229; Mon, 2 Sep 2002 00:05:24 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25DC89122A; Mon, 2 Sep 2002 00:05:24 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E3EF591229 for ; Mon, 2 Sep 2002 00:04:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AC9465DE7B; Mon, 2 Sep 2002 00:04:30 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 454AA5DE79 for ; Mon, 2 Sep 2002 00:04:30 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8244T013845; Mon, 2 Sep 2002 00:04:29 -0400 (EDT) Message-Id: <200209020404.g8244T013845@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: Zeroconf Subject: note about messages from John Welch Cc: moore@cs.utk.edu From: Keith Moore Date: Mon, 02 Sep 2002 00:04:29 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk I'm not going to reply to any more messages from John Welch. Partially this is because I was asked not to do so by the Chair. But I had already pretty much concluded that it was a waste of my time to do so, so I'm happy to comply with the Chair's request. Keith From owner-zeroconf@merit.edu Mon Sep 2 03:22:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15561 for ; Mon, 2 Sep 2002 03:22:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 31ADB9121E; Mon, 2 Sep 2002 03:24:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF98291222; Mon, 2 Sep 2002 03:24:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB0379121E for ; Mon, 2 Sep 2002 03:24:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A577E5DE87; Mon, 2 Sep 2002 03:24:14 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 0B0205DE84 for ; Mon, 2 Sep 2002 03:24:14 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g827OAm28905 for ; Mon, 2 Sep 2002 00:24:10 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 2 Sep 2002 00:24:08 -0700 Received: from adsl-64-171-18-123.dsl.sntc01.pacbell.net (vpn-gh-56.apple.com [17.254.136.55]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g827NrV01979 for ; Mon, 2 Sep 2002 00:23:53 -0700 (PDT) Date: Mon, 2 Sep 2002 00:23:36 -0700 Subject: Re: hypocrisy of zeroconf Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: Joshua Graessley To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200209020201.g82211012689@astro.cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sunday, September 1, 2002, at 07:01 PM, Keith Moore wrote: > normal IPv4 addresses have global scope and can be used in referrals > without the application having to be aware of network topology. > > normal IPv4 addresses are globally unique and can be addressed > without the application having to worry about which network > interface to use. As John Welch pointed out, this is false. Private addresses are often used and they are often used with NATs. NATs do break a lot of software but the simple fact is that enough people have NATs that if your software doesn't work with a NAT, your software can not be widely deployed. As nasty as they are NATs are unfortunately, a way of life. By the way, I like the work you and others have done on teredo to punch holes in NAT. > normal IPv4 addresses do not become invalid at a whim (absent device > failure). Neither do IPv4 link-local addresses. Read the draft. In most cases conflicts will be detected before an address is assigned to a machine. The only place it is even remotely likely that two machines will have the same address is the case where you bridge to previously separate networks together that have machines with IPv4 link local addresses assigned. I suppose the way in which IPv4 link-local addresses are significantly different from normal IPv4 addresses is that the conflicts will be detected right away instead of leading to mysterious problems that are hard to diagnose. As pointed out by others, using DHCP can lead to addresses changing. Just like with IPv4 link-local addresses, these address changes are rare, assuming the DHCP server is configured correctly. Another very common situation for addresses changing is a person moving their computer. I've got a laptop, I take it between work and home every day. Every day I switch my IP address when I get to work and again when I get home. Most applications on my computer are aware of the address changes and work without any difficulty. In addition, many people use dial-up connections where the connection may drop often. It is very handy for applications to be aware of the state of any connections to the network and act accordingly. It is naive for an application to assume that it has statically assigned addresses that never change. > applications that treat IPv4LL addresses like they are normal addresses > will fail for unexpected reasons when those apps try to use them in > referrals to devices on other interfaces or other links, and when those > addresses suddenly stop working due to conflicts. Normal IPv4 addresses, as noted above, will fail in a more mysterious manner when conflicts occur. IPv4LL addresses will be reassigned and networking operations can continue without intervention. I haven't yet heard of an example of a case where using a private address and NAT for referrals to other devices would succeed where an IPv4LL referral would fail. I haven't read much of the IPv6 RFCs. Do they suggest application developers treat IPv6LL addresses different from global scoped IPv6 addresses? > but you knew this already. We do know that this is what you've been saying. Please give us some examples of where this could cause problems. -josh From owner-zeroconf@merit.edu Mon Sep 2 04:18:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16577 for ; Mon, 2 Sep 2002 04:18:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CED919120D; Mon, 2 Sep 2002 04:19:26 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9AB5A91223; Mon, 2 Sep 2002 04:19:26 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A510C9120D for ; Mon, 2 Sep 2002 04:19:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 83A645DE8D; Mon, 2 Sep 2002 04:19:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id 273FA5DE89 for ; Mon, 2 Sep 2002 04:19:25 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21640; Mon, 2 Sep 2002 02:19:23 -0600 (MDT) Received: from qwer (qwer [129.157.142.111]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g828JLl12962; Mon, 2 Sep 2002 10:19:21 +0200 (MEST) Date: Mon, 2 Sep 2002 10:19:21 +0200 (MEST) From: Erik Guttman X-Sender: erikg@qwer To: Keith Moore Cc: Zeroconf Subject: Re: note about messages from John Welch In-Reply-To: <200209020404.g8244T013845@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Mon, 2 Sep 2002, Keith Moore wrote: > Partially this is because I was asked not to do so by the Chair. But > I had already pretty much concluded that it was a waste of my time > to do so, so I'm happy to comply with the Chair's request. Keith, John, I want to thank you for your examination of the naming and addressing issues which directly or peripherally concern the working group. I have not requested that anyone stop posting or responding to this list, only that we do so with consideration and brevity, addressing the topics we are chartered to discuss. I regret that your very positive contributions and obvious desire to improve configurability and usability of our networks has gotten lost in an acrimonious and drifting debate. Please do continue to post and discuss - but keep it on topic, brief and polite. Remember the others following this forum. Best regards, Erik Guttman ZEROCONF cochair From owner-zeroconf@merit.edu Mon Sep 2 07:57:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19900 for ; Mon, 2 Sep 2002 07:57:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 97B6F91224; Mon, 2 Sep 2002 07:58:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65A3C91228; Mon, 2 Sep 2002 07:58:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D26F91224 for ; Mon, 2 Sep 2002 07:58:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2FACC5DD99; Mon, 2 Sep 2002 07:58:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 83AC15DE50 for ; Mon, 2 Sep 2002 07:58:53 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10826; Mon, 2 Sep 2002 05:58:47 -0600 (MDT) Received: from qwer (qwer [129.157.142.111]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g82Bwil18873; Mon, 2 Sep 2002 13:58:44 +0200 (MEST) Date: Mon, 2 Sep 2002 13:58:44 +0200 (MEST) From: Erik Guttman X-Sender: erikg@qwer Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: Erik Guttman , Thomas Narten , erik.nordmark@sun.com Subject: ZEROCONF WG actions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The following drafts have been submitted to the IESG for consideration as RFCs. draft-ietf-zeroconf-reqts-11.txt to Informational draft-ietf-zeroconf-ipv4-linklocal-07.txt to Proposed Standard The latter document is currently in IETF last call for a final round. Both documents have been through Working Group last call in prior versions and have changed only very little since, in response to last call comments. Please see the current charter at www.ietf.org/html.charters/zeroconf-charter.html As previously discussed on the list, I propose changing the text as follows. From: This WG will produce two documents. The first describes the requirements for the configuration (and security) services, defaults, and mechanisms a node needs to fully participate on ZEROCONF networks and/or configured networks. The second, which follows the first, will detail a 'profile' specifying which standards specifically satisfy ZEROCONF requirements. The WG will also produce two protocol specifications. First, the WG will develop a document describing automatic generation and assignment of link-local IPv4 addresses in environments lacking host configuration (static or using DHCP). The document will describe existing practice as well as define recommendations for future implementations. Second, the WG will develop a profile of the Address Allocation Protocol (AAP) to provide Zero Configuration Multicast Address Allocation support for IPv4 and IPv6. To: This WG will produce two documents. The first describes the requirements for the configuration (and security) services, defaults, and mechanisms a node needs to fully participate on ZEROCONF networks and/or configured networks. The WG will also produce one protocol specification. The WG will develop a document describing automatic generation and assignment of link-local IPv4 addresses in environments lacking host configuration (static or using DHCP). The document will describe existing practice as well as define recommendations for future implementations. The goals should be changed from: Done Submit internet-draft to be considered as an Informational RFC on Requirements for Zero Configuration Networking. Done Submit Automatic Address Configuration for IPv4 to be considered as a Standards Track RFC. AUG 01 Submit Multicast Address Allocation Protocol for Zeroconf Networks to be considered as a Standards Track RFC. AUG 01 Submit internet-draft to be considered as an Informational RFC on Host Profile for Zero Configuration Networking. To: Done Submit internet-draft to be considered as an Informational RFC on Requirements for Zero Configuration Networking. Done Submit Automatic Address Configuration for IPv4 to be considered as a Standards Track RFC. According to this, we wait till our two active documents advance and do additional work on them if necessary. This accurately reflects the actual output of this working group. No discussion or activity on ZMAAP or the host profile has been undertaken for over 18 months. Comments? Best regards, Erik Guttman ZEROCONF cochair From owner-zeroconf@merit.edu Mon Sep 2 09:04:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21228 for ; Mon, 2 Sep 2002 09:04:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2B4E991228; Mon, 2 Sep 2002 09:05:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E747D9122B; Mon, 2 Sep 2002 09:05:26 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D4E2091228 for ; Mon, 2 Sep 2002 09:05:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BDBFC5DEA2; Mon, 2 Sep 2002 09:05:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 3FC545DD99 for ; Mon, 2 Sep 2002 09:05:25 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01053; Mon, 2 Sep 2002 06:05:22 -0700 (PDT) Received: from qwer (qwer [129.157.142.111]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g82D5Jl21096; Mon, 2 Sep 2002 15:05:19 +0200 (MEST) Date: Mon, 2 Sep 2002 15:05:19 +0200 (MEST) From: Erik Guttman X-Sender: erikg@qwer To: bradh@cuneata.net Cc: Erik Guttman , zeroconf@merit.edu, Thomas Narten , erik.nordmark@sun.com Subject: Re: ZEROCONF WG actions In-Reply-To: <1030971329.3d735fc17a878@www.cuneata.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Mon, 2 Sep 2002 bradh@cuneata.net wrote: > Quoting Erik Guttman : > > > According to this, we wait till our two active documents advance and > > do > > additional work on them if necessary. This accurately reflects the > > actual output of this working group. No discussion or activity on > > ZMAAP or the host profile has been undertaken for over 18 months. > I am not sure what this means. > > Do we not believe that some form of multicast address assignment is > needed in a zeroconf environment? There has been no active interest on the working group to work on this topic for some time. The disincentive for work here is that collisions on use of the same multicast address can be disambiguated by different applications use of distinct UDP port numbers. Even if there are collisions on the same port #, multicast apps are supposed to be able to survive such collisions. Dave Thaler or Steve Hanna can point us to the right doc citing this guideline. So the only real incentive for this protocol is optimization - to minimize collisions. This is not a very strong argument. In a larger multicast network one could deploy madcap to hand out non-colliding addresses. > Do we not believe in that vendors will need guidance for implementing > zeroconf for hosts? We have not distinguished ourselves in this working group as being able to reach a concensus on which protocols are best suited for the tasks described in the requirements document. address allocation IPv6 includes stateless addrconf IPv4 address autoconfiguration will be specified by this WG name resolution This is a charter item of the DNSEXT working group multicast address allocation Discussed above service discovery We have disagreement here that we have not been able to overcome. > I have done a bit of work (on paper) for the host profile, and think that it will > be needed if there is any hope for interoperability. We will get interoperability in each of the areas above as the IETF standardizes protocol. It is just that this working group is not the place to define how this works as a total 'bill of goods.' The IETF doesn't generally write profiles anyway. Its not clear that we could get one published as an RFC, even if we had the will to do so. Best regards, Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n Short email (<140 characters) to Solaris Installation and Deployment 01728655497@d2-message.de Sun Microsystems cell: +49 172 865 5497 From owner-zeroconf@merit.edu Mon Sep 2 10:02:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22731 for ; Mon, 2 Sep 2002 10:02:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 53A3D9120D; Mon, 2 Sep 2002 10:03:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2196B9121E; Mon, 2 Sep 2002 10:03:28 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F7CB9120D for ; Mon, 2 Sep 2002 10:03:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0EF055DEB1; Mon, 2 Sep 2002 10:03:17 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 969B95DEB0 for ; Mon, 2 Sep 2002 10:03:16 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g82E2w009402; Mon, 2 Sep 2002 10:02:58 -0400 (EDT) Message-Id: <200209021402.g82E2w009402@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Zeroconf Subject: Re: hypocrisy of zeroconf In-reply-to: (Your message of "Mon, 02 Sep 2002 00:23:36 PDT.") Date: Mon, 02 Sep 2002 10:02:58 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > normal IPv4 addresses have global scope and can be used in referrals > > without the application having to be aware of network topology. > > > > normal IPv4 addresses are globally unique and can be addressed > > without the application having to worry about which network > > interface to use. > > As John Welch pointed out, this is false. Private addresses are often > used and they are often used with NATs. NATs do break a lot of software > but the simple fact is that enough people have NATs that if your > software doesn't work with a NAT, your software can not be widely > deployed. actually, that's not even true. what it means is that your software cannot work behind a NAT. this certainly limits the environments in which the software can be run - e.g. the software will not automagically work from anywhere in what users think of as "the net". but the existence of NATs does not prevent software that doesn't (and fundamentally cannot) work with NATs from existing and being useful. OTOH, linklocal - because it ships with the OS, gets enabled by default, and is there all the time, imposes NAT-like restrictions on networks that haven't chosen to run NAT. and it imposes new burdens on existing applications that were working just fine on their networks - now those apps either have to explicitly refuse to use LL addresses or they have to explicitly specify interfaces and try to recover from broken connections. even then they'll fail more often with LL addresses than before. > As nasty as they are NATs are unfortunately, a way of life. they're "a" way of life. not "the" way of life. if you're trying to sell an app to the mass market, you probably assume that either your app works with NATs or you can't succeed. but that doesn't mean that all networks work this way, or that no app can be useful unless it's NAT-compatible. > > normal IPv4 addresses do not become invalid at a whim (absent device > > failure). > > Neither do IPv4 link-local addresses. Read the draft. as you're probably aware, I have read the draft on multiple occasions and have made extensive comments about it. so when I say "invalid at a whim" you should interpret that as coming from someone who has repeatedly read the draft and who understands the conditions under which LLs become invalid. IMHO such failures are not negligible. the additional faliures introduced by LLs might be acceptable if you design your network with such failures in mind (to limit the number of devices on a logical link) - but existing networks were not designed with linklocals in mind. for instance it's fairly common these days to use moderately sized subnets and L2 switching. in those cases LL collisions can be expected to be more common. > In most cases > conflicts will be detected before an address is assigned to a machine. > The only place it is even remotely likely that two machines will have > the same address is the case where you bridge to previously separate > networks together that have machines with IPv4 link local addresses > assigned. or when you have machines with interfaces on multiple networks (increasingly common) or when network congestion (not unusual) prevents the claim/defend protocol from working. I suppose the way in which IPv4 link-local addresses are > significantly different from normal IPv4 addresses is that the > conflicts will be detected right away instead of leading to mysterious > problems that are hard to diagnose. normal IP addresses do not have such conflicts. when such conflicts do arise, it is due to improper configuration, and hosts and apps aren't expected to deal with those problems. however the LL draft makes clear that hosts and apps are expected to deal with problems caused by LL - even though there's no way of either avoiding such failures (since LL is imposed on hosts) or transparently recovering from such failures. > As pointed out by others, using DHCP can lead to addresses changing. > Just like with IPv4 link-local addresses, these address changes are > rare, assuming the DHCP server is configured correctly. again, the fact that DHCP can cause problems if misconfigured is not an argument for LL causing problems. > Another very common situation for addresses changing is a person moving > their computer. I've got a laptop, I take it between work and home > every day. Every day I switch my IP address when I get to work and > again when I get home. Most applications on my computer are aware of > the address changes and work without any difficulty. In addition, many > people use dial-up connections where the connection may drop often. It > is very handy for applications to be aware of the state of any > connections to the network and act accordingly. It is naive for an > application to assume that it has statically assigned addresses that > never change. no, it's not "naive" of an application to assume that - in fact, many applications quite reasonably *do* assume that (for instance, the vast majority of servers on the network). yes, it's an operational constraint, but it's not a rare one. rather, it is naive of LL proponents to assume that all applications work like the ones on their laptops and can operate under the same set of constraints that are imposed by nomadic hosts. > > applications that treat IPv4LL addresses like they are normal addresses > > will fail for unexpected reasons when those apps try to use them in > > referrals to devices on other interfaces or other links, and when those > > addresses suddenly stop working due to conflicts. > > Normal IPv4 addresses, as noted above, will fail in a more mysterious > manner when conflicts occur. again, the potential for other sources of failure is not a justification for LL imposing failures. > IPv4LL addresses will be reassigned and > networking operations can continue without intervention. no they will not. existing connections/associations will break, existing apps using those connections/associations will fail, and in general there is no way for those apps to recover. in the vast majority of cases intervention is necessary to restart the operation, restart the app, etc. and it's not reasonable to assume that such apps are interacting with a human user who is monitoring the situation and can quickly initiate recovery. > I haven't yet > heard of an example of a case where using a private address and NAT for > referrals to other devices would succeed where an IPv4LL referral would > fail. it can happen anytime the network behind the NAT is subnetted. but you seem to be arguing that the existence of NATs is license for LL to cause many of the same problems that NAT cause. > I haven't read much of the IPv6 RFCs. Do they suggest application > developers treat IPv6LL addresses different from global scoped IPv6 > addresses? yes, they are treated differently. there's an address selection algorithm that tries to specify when to use certain kinds of addresses. it doesn't entirely solve the problem. but at least the IPv6 people admit that the problem exists. > > > but you knew this already. > > We do know that this is what you've been saying. Please give us some > examples of where this could cause problems. I've given examples on numerous occasions. the problem seems to be that folks here think it's perfectly reasonable to force the entire network to operate under the constraints of a nomadic laptop that only connects from behind NATs. most people only see their email client, IM client, and web browser, and they think that is representative of the entire network. in reality the network is far more diverse than that. From owner-zeroconf@merit.edu Tue Sep 3 16:51:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13871 for ; Tue, 3 Sep 2002 16:51:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1F60A91252; Tue, 3 Sep 2002 16:52:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E543391264; Tue, 3 Sep 2002 16:52:54 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 75BC091252 for ; Tue, 3 Sep 2002 16:52:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 641905DEDB; Tue, 3 Sep 2002 16:52:53 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id E76945DED8 for ; Tue, 3 Sep 2002 16:52:52 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g83Kqq010629; Tue, 3 Sep 2002 16:52:52 -0400 (EDT) Message-Id: <200209032052.g83Kqq010629@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: Zeroconf Subject: comments on draft-ietf-zeroconf-reqts-11.txt Cc: moore@cs.utk.edu, iesg@ietf.org From: Keith Moore Date: Tue, 03 Sep 2002 16:52:52 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk these comments are intended as input into IESG decision-making about whether to publish draft-ietf-zeroconf-reqts-11.txt as Informational, and also to the zeroconf WG as input to a possible future revision of this document. I see this document as somewhat more important than the typical WG requirements document since zeroconf technologies have the potential to have wide-ranging effects on internet applications and networks, and presumably the linklocal document will be evaluated for 'known technical omissions' with respect to these requirements. so if these requirements are incomplete or poorly-founded, they don't serve as a good basis for judging linklocal. it does seem odd that the requirements document hasn't been formally reviewed by a wider community before now, and even now is not subject to IETF-wide last call. even if they're just informational from the standpoint of standardization they're being used to justify features of standards-track protocols - so we should probably give them more scrutiny than typical 'informational' documents. then again, I'd vastly prefer that we call these things 'design goals'. somehow the word 'requirements' keeps sticking in people's minds even though these documents are rarely either prescient or robust enough to actually be considered 'requirements'. ---------------------------------------------------------------------- executive summary: - the requirements seem incomplete. important considerations - such as the impact of zeroconf technologies on existing applications and existing networks - are omitted. - a few of the requirements seem dubious details: section 1.3 the document doesn't say that there are absolutely no dependencies between zeroconf technologies, so perhaps this is just a nit. but if you expect the name-to-address translation service to be able to return limited-scope addresses in response to queries (and you clearly do) then there is a dependency between the name-to-address translation service and the scope of such addresses - namely, the service needs to be aware of the scope boundaries of its clients. otherwise it will return addresses that are unusable by its clients and may in fact point to completely different hosts. concrete example: if the scope of LL v4 addresses and LL v4 multicast are not the same (and they could easily differ) then an mDNS/LLMNR lookup can easily return an address that isn't usable by the client. of course if you put such addresses in DNS then you have even more problems. so I think there are unstated requirements that - the zeroconf technologies coexist with each other in a useful way, which is to say that they can be consistent with one another - the zeroconf technologies coexist with similar services that are used in managed networks - either by providing consistent (or non-conflicting) results or by arranging that the zeroconf service is not used when the managed service exists. (even then you still have consistency issues, since the ability to access the 'managed' services may differ from one node to another). and *those* translate into more specific requirements which I can't enumerate off the top of my head. section 1.4 it's reasonable for scalability to be a secondary goal for truly ad hoc networks - there seems little point in trying to support ad hoc networks that consist of thousands of hosts. OTOH, if zeroconf technologies are to be used on existing networks, scaling _on those networks_ becomes considerably more of a concern. it's been argued on the mailing list that some zeroconf technologies should be usable on managed networks in addition to ad hoc networks. indeed, it's been forcefully argued that linklocal should be enabled by default on all hosts so that it can be used to communicate with appliances without having to configure such appliances. if this is a goal, it needs to be explicit, and the scalability concern needs to be reconsidered. regardless, there needs to be a requirement that zeroconf technologies not interefere with operation or security on managed networks. section 1.6 it's not clear what it means for zeroconf protocols to "restore the network to a consistent state", especially when all of the relevant state that I can see is maintained in the hosts and applications rather than in the network. zeroconf may be able to resolve address conflicts, but it cannot transparently recover applications from such conflicts. there needs to be a requirement that zeroconf minimize impact on applications. actually there's little mention of applications in the document, even though the effect on some kinds of applications is significant. this seems like a major omission. it's not clear that names, or name-to-address mappings, are properly considered 'network' resources if they are similar to DNS names or have the potential to overlap with the DNS name space - either as a matter of on-the-wire protocol or via APIs that applications use to look up such names. section 2.1 again, the document talks about what "hosts" should or should not assume regarding stability of "network resources" but does not mention what "applications" may assume or whether zeroconf creates new burdens for applications. section 2.2 (middle of page 6) the document talks about "increased robustness" of _zeroconf_ protocols but says nothing about the effect on the robustness of applications hosted on hosts that use zeroconf. section 3.1 (3rd bullet) [nit?] "MUST allow configuration of zero or more gateways (for the internetwork scenario)". perhaps this is trivially satisfied (because allowing zero gateways suffices) and it can therefore be omitted. or perhaps it needs rewording for clarity. please remind me of how v4 linklocal facilities connection of gateways? (last bullet list of requirements on middle page 8) it seems like nomadic hosts are likely to connect to multiple networks in the course of a day. is such a host better off using the same address each time it connects to a particular network, or better off trying to claim/defend the same address on every network to which it connects? would large numbers of nomadic hosts (as seems likely) seriously affect the stability of linklocal addresses even though the hosts try to maintain their addresses as they migrate? also, given that apps on nomadic hosts might need to keep some connections open as they move, has any thought been given to interaction between zeroconf technologies and mobile IP? are there requirements along these lines waiting to be discovered? section 3.2 I keep being told that the name-to-address issue is out of scope for this group. maybe dnsext should review this portion of the document? or maybe it should be omitted? especially since mDNS/LLMNR still seems to be in flux with fundamental problems still unresolved? nit: s/quite likely to use a different IP/quite likely to use different IP/ ^ I realize this isn't the only group using the term, but the emphasis on "host names" seems a bit archaic. these days users rarely care about accessing "hosts", they care about accessing "services". (sometimes the host *is* the desired service, but that's the exception rather than the rule). of course, it's not the use of the term that's important so much as the assumptions that go along with it. for instance, should service lookups map to host names and host names to addresses, or should service lookups map directly to addresses? nit: "for applications like web browsers...the use of names rather than IP addresses is beneficial". only if the names are more stable and more mnemonic than the addresses :) not that they're being proposed by this WG but temporary names aren't very useful for such purposes. I would say "may be beneficial" rather than "is". (page 9, bullets) if "host names" are or aren't DNS names then it would be good to say that in the first bullet in the Terms section. that's the first thing a reader would want to know. there's no statement about the effect of the name resolution protocol on APIs that are currently used to look up DNS names. it's an important question because it will affect apps. there's a desire to have these things "just work" with existing apps, but at the same time if the results are inconsistent with DNS then it will cause problems. there's also no statement about the consistency of results of the lookups using name resolution protocol across different locations. if the results are inconsistent at different places this will also break apps that want to use these names to do referrals. there needs to be a requirement that lookups of DNS names are consistent with lookups using DNS. "probing a desired host name...must not prevent the desired hostname from being resolved". I'm not sure what this means. - "from being resolved...at a later time" ? - s/must not/MUST NOT/ ? again, it is not at all clear that host names are properly treated as "network resources", i.e. resources that belong to the network. traditionally DNS names are not related to network topology. this might imply that the network and/or protocols for looking up such names should be able to detect naming conflicts between DNS-style names but NOT to adjucate between such conflicts - because the network is not authoritative for any portion of DNS name space. (individual hosts might have been assigned such authority - just as they might be running DNS servers that are authoritative, but the "network" is not authoritative) "local" names (that don't look like FQDNs) might be a different matter. (I realize that this document says that they aren't DNS names but mDNS/LLMNR seems to act as if they are DNS names or at least the spaces can overlap - then consistency becomes an issue) "zeroconf name resolution protocol MUST support resolution of names on multiple IP subnets connected by a router". I'm not sure what this means - it seems like a network-centric definition but the hosts/apps are what are implementing the protocol. Do you mean that the protocol MUST enable resolution of names on other IP subnets that those to which the host supporting the querying application is attached? again, is there a potential conflict between the use of limited-scope addresses in this name-to-address lookup service and having the lookup service work across a larger area than such addresses? "zeroconf name resolution protocols MUST allow timely re-use of hostnames" again this seems misstated, at least for FQDNs - such names are not delegated to the network or to zeroconf protocols to manage. section 3.2.2 "host names ...are inherently locally scoped". not from the examples envisioned in the current mDNS/LLMNR draft. "a DNS server supporting dynamic updates can provide automatic configuration of a DNS name space in a network". I'm not sure what this means. Are you saying that such a server could (or perhaps should) be used instead of the zeroconf name lookup service? Are you saying that this mechanism should be used (when available) to ensure consistency between the zeroconf service and DNS? "The zeroconf namespace is orthogonal to the DNS class IN namespace" seems irreconcilable with "It is RECOMMENDED that zeroconf host names conform to the character set and formatting of DNS host names". (and the latter seems to me to need strong justification) EITHER the two services share a common namespace (and need to produce consistent results with one another) OR they need to be clearly distinguished from one another - different syntax, different APIs, etc. so that apps don't get confused and try to treat zeroconf host names as if they had the same properties of DNS names. several requirements seem to be omitted here. "...MUST NOT allow zeroconf names to mask DNS names". this is not a sufficient restriction. in general it is necessary to produce consistent results when different hosts in different parts of the network look up the same DNS-like name, even if those hosts have different local scopes or if some of those hosts are using zeroconf and others are using DNS. that's not to say that all RRs for all names need to be visible to all hosts at all times - that's not even true for pure DNS - but that (for reasons similar to those given in RFC 2826) the name lookup service needs to provide a uniform view of DNS-style names from everywhere. local (unqualified) names are a different matter - we do expect their meanings to differ from one place to another. --- since I'm busy and I'm mostly concerned about names and addresses, I didn't review the remainder of the document. again, attention to important considerations that were omitted from the requirements in the document are probably more important than most of the tweaks suggested above. e.g. compatibility with existing apps, effects of introduction of zeroconf on the operation of existing/managed networks. Keith From owner-zeroconf@merit.edu Tue Sep 3 17:52:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15584 for ; Tue, 3 Sep 2002 17:52:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF1BA91264; Tue, 3 Sep 2002 17:54:05 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8ACB191266; Tue, 3 Sep 2002 17:54:05 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F8D491264 for ; Tue, 3 Sep 2002 17:54:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 12B5B5DEEA; Tue, 3 Sep 2002 17:54:04 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id A6C0C5DECE for ; Tue, 3 Sep 2002 17:54:03 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g83Ls3m20389 for ; Tue, 3 Sep 2002 14:54:03 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 3 Sep 2002 14:54:01 -0700 Received: from adsl-64-171-18-123.dsl.sntc01.pacbell.net (vpn-gh-580.apple.com [17.254.138.67]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g83Lrw318936 for ; Tue, 3 Sep 2002 14:53:58 -0700 (PDT) Date: Tue, 3 Sep 2002 14:53:40 -0700 Subject: Re: hypocrisy of zeroconf Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: Joshua Graessley To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200209021402.g82E2w009402@astro.cs.utk.edu> Message-Id: <9B61307A-BF87-11D6-9CEA-000393760260@apple.com> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, September 2, 2002, at 07:02 AM, Keith Moore wrote: >>> normal IPv4 addresses have global scope and can be used in referrals >>> without the application having to be aware of network topology. >>> >>> normal IPv4 addresses are globally unique and can be addressed >>> without the application having to worry about which network >>> interface to use. >> >> As John Welch pointed out, this is false. Private addresses are often >> used and they are often used with NATs. NATs do break a lot of >> software >> but the simple fact is that enough people have NATs that if your >> software doesn't work with a NAT, your software can not be widely >> deployed. > > actually, that's not even true. what it means is that your software > cannot work behind a NAT. this certainly limits the environments > in which the software can be run - e.g. the software will not > automagically > work from anywhere in what users think of as "the net". but the > existence > of NATs does not prevent software that doesn't (and fundamentally > cannot) > work with NATs from existing and being useful. Your assertion was that the zeroconf working group is trying to "redefine IP to work differently than applications expect". Your arguments were: > normal IPv4 addresses have global scope and can be used in referrals > without the application having to be aware of network topology. > > normal IPv4 addresses are globally unique and can be addressed > without the application having to worry about which network > interface to use. As pointed out before, this is not true. RFC1918 specifies private address ranges that are not in any way globally unique. > OTOH, linklocal - because it ships with the OS, gets enabled by > default, > and is there all the time, imposes NAT-like restrictions on networks > that haven't chosen to run NAT. and it imposes new burdens on > existing > applications that were working just fine on their networks - now those > apps either have to explicitly refuse to use LL addresses or they have > to > explicitly specify interfaces and try to recover from broken > connections. > even then they'll fail more often with LL addresses than before. As far as I can tell, there is no requirement in the current draft that a host must acquire an IPv4LL address in addition to a globally scoped address. For the very reason you state, I think it makes more sense for hosts to only acquire IPv4LL addresses when a configured address is not available. I believe it makes sense to retain any IPv4LL address acquired even after a globally configured address becomes available to maintain any TCP sessions already using the LL address. In that case, the IPv4LL address may present similar problems to NAT. >> As nasty as they are NATs are unfortunately, a way of life. > > they're "a" way of life. not "the" way of life. if you're trying to > sell an app to the mass market, you probably assume that either your > app works with NATs or you can't succeed. but that doesn't mean > that all networks work this way, or that no app can be useful unless > it's > NAT-compatible. This is true, but those applications ignoring NAT are making certain assumptions that, while possibly true for a specific configuration/situation, are not true for the IP in general. >>> normal IPv4 addresses do not become invalid at a whim (absent device >>> failure). >> >> Neither do IPv4 link-local addresses. Read the draft. > > as you're probably aware, I have read the draft on multiple occasions > and have made extensive comments about it. so when I say "invalid at a > whim" you should interpret that as coming from someone who has > repeatedly > read the draft and who understands the conditions under which LLs > become > invalid. IMHO such failures are not negligible. > > the additional faliures introduced by LLs might be acceptable if you > design your network with such failures in mind (to limit the number > of devices on a logical link) - but existing networks were not > designed with linklocals in mind. for instance it's fairly common > these days to use moderately sized subnets and L2 switching. > in those cases LL collisions can be expected to be more common. The number of devices on a logical link must be limited for other reasons. In addition, the collision detection used before an address is picked should eliminate the possibility of two nodes self assigning the same address. If the logical link is so large that there is a significant amount of packet loss so that the collision detection is failing, then the network is poorly designed and the collisions are just one symptom. Using a real world example (which I believe has been used before). An AppleTalk network, which uses a similar mechanism to allocate addresses, and has nearly as many nodes as addresses available does work without the addresses changing constantly. It did take a long time to find an unused addresses, but once an address was acquired, it worked and there were rarely collisions. This is a pathological case where the number of nodes where very close to the number of addresses available. Do you think that logical links with more than 32k nodes are common? You said "IMHO such failures are not negligible.". Do you have any evidence, models, something to back that up? Using AppleTalk's address allocation as an example to study, such failures are negligible. >> In most cases >> conflicts will be detected before an address is assigned to a machine. >> The only place it is even remotely likely that two machines will have >> the same address is the case where you bridge to previously separate >> networks together that have machines with IPv4 link local addresses >> assigned. > > or when you have machines with interfaces on multiple networks > (increasingly common) or when network congestion (not unusual) > prevents the claim/defend protocol from working. If congestion is causing the claim/defend protocol from working, the network is probably running in to other sorts of problems as well. IPv4LL address collisions would just be one symptom of a poorly designed network. I had not considered how a machine with multiple interfaces on different networks could cause problems with address collisions. The draft does suggest that a multihomed host should try and keep it's addresses unique on all interfaces. If a device with multiple interfaces already has 2 unique IPv4LL addresses on two different networks and a third interface is plugged in to a third network network that already has one or two of the devices addresses in use, what is the multihomed device supposed to do? It seems to me it would need to allocate new IPv4 link-local addresses that are unique across all three interfaces. > I suppose the way in which IPv4 link-local addresses are >> significantly different from normal IPv4 addresses is that the >> conflicts will be detected right away instead of leading to mysterious >> problems that are hard to diagnose. > > normal IP addresses do not have such conflicts. when such conflicts > do arise, it is due to improper configuration, and hosts and apps > aren't expected to deal with those problems. however the LL > draft makes clear that hosts and apps are expected to deal with > problems caused by LL - even though there's no way of either avoiding > such failures (since LL is imposed on hosts) or transparently > recovering from such failures. Normal IP addresses do have such conflicts and they are due to improper configuration. Hosts and apps should not be expected to deal with such problems. It would be nice if stacks did a better job of detecting this. >> As pointed out by others, using DHCP can lead to addresses changing. >> Just like with IPv4 link-local addresses, these address changes are >> rare, assuming the DHCP server is configured correctly. > > again, the fact that DHCP can cause problems if misconfigured is not > an argument for LL causing problems. This is not an argument that it's alright for LL to cause problems but just an observation that most applications already live in a dynamic environment were addresses and connectivity do change. Again, I think you overestimate how often IPv4LL addresses will change. Just as DHCP misconfiguration can cause problems, a poorly designed network with a enough congestion that the IPv4LL claim/defend mechanism fails can cause problems. >> Another very common situation for addresses changing is a person >> moving >> their computer. I've got a laptop, I take it between work and home >> every day. Every day I switch my IP address when I get to work and >> again when I get home. Most applications on my computer are aware of >> the address changes and work without any difficulty. In addition, many >> people use dial-up connections where the connection may drop often. It >> is very handy for applications to be aware of the state of any >> connections to the network and act accordingly. It is naive for an >> application to assume that it has statically assigned addresses that >> never change. > > no, it's not "naive" of an application to assume that - in fact, many > applications quite reasonably *do* assume that (for instance, the vast > majority of servers on the network). yes, it's an operational > constraint, > but it's not a rare one. > > rather, it is naive of LL proponents to assume that all applications > work > like the ones on their laptops and can operate under the same set of > constraints that are imposed by nomadic hosts. In the statically configured world where an application can assume it's address, and the addresses of other nodes will not change, the applications will most likely be configured to use those static addresses. This sounds like a highly configured environment, it is not clear why IPv4LL addresses would be use instead of the configured ones. >> IPv4LL addresses will be reassigned and >> networking operations can continue without intervention. > > no they will not. existing connections/associations will break, > existing > apps using those connections/associations will fail, and in general > there > is no way for those apps to recover. in the vast majority of cases > intervention is necessary to restart the operation, restart the app, > etc. and it's not reasonable to assume that such apps are interacting > with a human user who is monitoring the situation and can quickly > initiate > recovery. Not true, if service discovery is used or name to address mapping, when communication does break, an application could easily find the new address and resume communication. This certainly would require modification of an application. You still haven't presented any evidence that IPv4LL addresses are likely to change often as you suggest would happen. >> I haven't yet >> heard of an example of a case where using a private address and NAT >> for >> referrals to other devices would succeed where an IPv4LL referral >> would >> fail. > > it can happen anytime the network behind the NAT is subnetted. > > but you seem to be arguing that the existence of NATs is license for > LL to cause many of the same problems that NAT cause. Networks can break in many ways when you start using private addresses on separate networks. Does that mean we shouldn't do that? Since IPv4LL addresses may cause some problems in some edge cases, does that mean that they are useless? I don't think so. You still haven't backed up your assertion that the zeroconf working group is trying to "redefine IP to work differently than applications expect". So far, your arguments seem to point to some applications that expect a configured environment with addresses that will never change and all addresses that are globally accessible. I don't think it's right to assume that IP applications expect that or even require that. RFC1918 specifies addresses that are not global in scope, so an application can not expect every IP address to have global scope. Applications assuming global scope are making assumptions beyond those that IP defines. NATs make it easy to send data from private addresses to the global internet, making it trivial to leak private addresses. These are not excuses for making something else that causes problems. They are examples of other things that, while they have the potential to cause problems, are in general, very useful and widely deployed. >> I haven't read much of the IPv6 RFCs. Do they suggest application >> developers treat IPv6LL addresses different from global scoped IPv6 >> addresses? > > yes, they are treated differently. there's an address selection > algorithm > that tries to specify when to use certain kinds of addresses. it > doesn't > entirely solve the problem. but at least the IPv6 people admit that > the > problem exists. Source address selection is covered in section 2.6 of the ipv4 linklocal draft. Selection of remote addresses from name lookup, service discovery, or other sources has not been addressed. -josh From owner-zeroconf@merit.edu Tue Sep 3 17:59:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15709 for ; Tue, 3 Sep 2002 17:59:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AD5FE91266; Tue, 3 Sep 2002 18:00:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 790FD91267; Tue, 3 Sep 2002 18:00:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5AB7191266 for ; Tue, 3 Sep 2002 18:00:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2A03B5DEEA; Tue, 3 Sep 2002 18:00:37 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id AA1305DECE for ; Tue, 3 Sep 2002 18:00:36 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g83M0Z011202; Tue, 3 Sep 2002 18:00:35 -0400 (EDT) Message-Id: <200209032200.g83M0Z011202@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Keith Moore Cc: Zeroconf , iesg@ietf.org Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt In-reply-to: (Your message of "Tue, 03 Sep 2002 16:52:52 EDT.") <200209032052.g83Kqq010629@astro.cs.utk.edu> Date: Tue, 03 Sep 2002 18:00:35 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > but if you expect the name-to-address translation service to be able to > return limited-scope addresses in response to queries (and you clearly > do) then there is a dependency between the name-to-address translation > service and the scope of such addresses - namely, the service needs to > be aware of the scope boundaries of its clients. otherwise it will > return addresses that are unusable by its clients and may in fact point > to completely different hosts. further comment to my earlier comment - the major problem with limited scope addresses in general is that hosts and apps usually have no way to know whether an address is valid in a particular context. this is true whether or not the limited scope address is initially obtained by using a DNS or an LLMNR lookup (it's not necessarily the case that they are). the server providing the lookup typically has no idea about the networks to which the lookup client has access, and there's no assurance that the client that's doing the query is the same party that will actually try to communicate with that address. so trying to have the name-to-lookup service return limited scope addresses only when the client that's doing the query is within the proper scope for that address is at best only a partial solution - addresses will still leak out of the scopes in which they are valid. Keith From owner-zeroconf@merit.edu Tue Sep 3 19:45:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17468 for ; Tue, 3 Sep 2002 19:45:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EAFB891252; Tue, 3 Sep 2002 19:47:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2A2D9125C; Tue, 3 Sep 2002 19:47:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1F09891252 for ; Tue, 3 Sep 2002 19:47:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 074645DEE5; Tue, 3 Sep 2002 19:47:17 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 786F85DE41 for ; Tue, 3 Sep 2002 19:47:16 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g83NlG510282 for ; Tue, 3 Sep 2002 16:47:16 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 3 Sep 2002 16:47:14 -0700 Received: from adsl-64-171-18-123.dsl.sntc01.pacbell.net (vpn-gh-580.apple.com [17.254.138.67]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g83NlFb26872 for ; Tue, 3 Sep 2002 16:47:15 -0700 (PDT) Date: Tue, 3 Sep 2002 16:46:56 -0700 Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: Joshua Graessley To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200209032052.g83Kqq010629@astro.cs.utk.edu> Message-Id: <6E835282-BF97-11D6-9CEA-000393760260@apple.com> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm not sure I understand how the scope of the two could differ. Both are defined as link-local scope. In the case of ethernet, an ethernet broadcast and an ethernet multicast should be just as effective in reaching all nodes, right? I think that any equipment that handles the two differently would break many applications. Is there another media where the definition of link-local changes if an address is multicast? -josh On Tuesday, September 3, 2002, at 01:52 PM, Keith Moore wrote: > concrete example: if the scope of LL v4 addresses and LL v4 multicast > are not the same (and they could easily differ) then an mDNS/LLMNR > lookup > can easily return an address that isn't usable by the client. of > course > if you put such addresses in DNS then you have even more problems. From owner-zeroconf@merit.edu Tue Sep 3 20:08:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17871 for ; Tue, 3 Sep 2002 20:08:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 130BA91252; Tue, 3 Sep 2002 20:09:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2E769125C; Tue, 3 Sep 2002 20:09:33 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C8DEC91252 for ; Tue, 3 Sep 2002 20:09:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AE2C85DEA4; Tue, 3 Sep 2002 20:09:32 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 017E05DE41 for ; Tue, 3 Sep 2002 20:09:31 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g8409Vm18346 for ; Tue, 3 Sep 2002 17:09:31 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 3 Sep 2002 17:09:31 -0700 Received: from adsl-64-171-18-123.dsl.sntc01.pacbell.net (vpn-gh-580.apple.com [17.254.138.67]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g8409UV01259 for ; Tue, 3 Sep 2002 17:09:30 -0700 (PDT) Date: Tue, 3 Sep 2002 17:09:11 -0700 Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: Joshua Graessley To: Zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <5.1.1.6.2.20020903195236.02e171f8@mail.amaranth.net> Message-Id: <8A2634EA-BF9A-11D6-9CEA-000393760260@apple.com> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, September 3, 2002, at 04:57 PM, Daniel Senie wrote: > At 07:46 PM 9/3/2002, you wrote: >> I'm not sure I understand how the scope of the two could differ. Both >> are defined as link-local scope. In the case of ethernet, an ethernet >> broadcast and an ethernet multicast should be just as effective in >> reaching all nodes, right? I think that any equipment that handles >> the two differently would break many applications. Is there another >> media where the definition of link-local changes if an address is >> multicast? > > Ethernet controllers treat Multicast and Broadcast differently. In a > simple environment with hubs, the multicast packets get to each > station, but STILL are handled differently. Broadcast packets are > received by the Ethernet driver. Multicast packets are discarded > before being handed to the driver, unless the driver has asked for the > multicast group the packet is in. > > In the event of better Ethernet switches, they will monitor which > Multicast groups a particular port needs, and only send those to that > port (read up on IGMP snooping). Still, this should not limit the effective scope of an IPv4LL multicast versus an IPv4LL unicast, right? The broadcast address used for ARP should get to all of the nodes on the "local link", allowing an IPv4LL address to be used for communication with any other node on that link. In the case of DNS sent to a link-local address, the multicast packet should only be received by other devices on that local link. With the exception of some switches that may try to be smart and filter out multicast traffic, the broadcast and multicast traffic will be seen by the same devices. In the case where there is "smart" hardware filtering multicast, the nodes to receive the multicast would be a subset of the nodes that would receive the broadcast. On Tuesday, September 3, 2002, at 01:52 PM, Keith Moore wrote: > concrete example: if the scope of LL v4 addresses and LL v4 multicast > are not the same (and they could easily differ) then an mDNS/LLMNR > lookup > can easily return an address that isn't usable by the client. of > course > if you put such addresses in DNS then you have even more problems. If the nodes receiving the multicast are a subset of the nodes receiving broadcasts, wouldn't it be impossible for an mDNS/LLMNR reply to make it to a node where the IPv4LL address would be inaccessible? I suppose you could have nodes that knew about mDNS/LLMNR that did not know about IPv4LL addresses and therefore did not have a route to those addresses. -josh From owner-zeroconf@merit.edu Tue Sep 3 20:14:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18027 for ; Tue, 3 Sep 2002 20:14:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8C50F9125C; Tue, 3 Sep 2002 20:15:48 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5800D91263; Tue, 3 Sep 2002 20:15:48 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 39A579125C for ; Tue, 3 Sep 2002 20:15:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 140B25DEE5; Tue, 3 Sep 2002 20:15:47 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 99FB35DE41 for ; Tue, 3 Sep 2002 20:15:46 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g840Fh011755; Tue, 3 Sep 2002 20:15:43 -0400 (EDT) Message-Id: <200209040015.g840Fh011755@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Zeroconf Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt In-reply-to: (Your message of "Tue, 03 Sep 2002 16:46:56 PDT.") <6E835282-BF97-11D6-9CEA-000393760260@apple.com> Date: Tue, 03 Sep 2002 20:15:43 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > I'm not sure I understand how the scope of the two could differ. Both > are defined as link-local scope. In the case of ethernet, an ethernet > broadcast and an ethernet multicast should be just as effective in > reaching all nodes, right? I think that any equipment that handles the > two differently would break many applications. that sounds like an argument that I would make :) as it turns out the local ethernet in my building at UTK doesn't (yet) support multicast because it's not really an ethernet - it is actually based on some kind of cisco switches that don't do multicast unless you enable a proprietary cisco protocol on them. and our network guys have it disabled (last I checked) because they don't understand it. yes, it's prevented us from running several apps. we've been wanting multicast ever since we moved into this building two years ago. (the last building we were in was one of the first on campus to be wired so it had a *real* ethernet, complete with vampire taps. those were the days...) somehow I doubt we're the only ones in that situation. just as there are folks who don't understand that IP is designed to have global addresses and that failure to provide global addresses breaks apps that quite reasonably expect them, there are also folks who don't understand that ethernets are designed to support multicast and that failure to support multicast breaks apps that quite reasonably expect it (at least on the LAN). Keith p.s. will respond to your other message after doing a detailed review of the latest linklocal draft. today is my day to do detailed reviews... From owner-zeroconf@merit.edu Tue Sep 3 20:58:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19007 for ; Tue, 3 Sep 2002 20:58:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 42E9F91252; Tue, 3 Sep 2002 20:59:40 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 087B691263; Tue, 3 Sep 2002 20:59:39 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0693191252 for ; Tue, 3 Sep 2002 20:59:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D78015DEA4; Tue, 3 Sep 2002 20:59:38 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 634EE5DE41 for ; Tue, 3 Sep 2002 20:59:38 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g840xY011882; Tue, 3 Sep 2002 20:59:35 -0400 (EDT) Message-Id: <200209040059.g840xY011882@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Zeroconf@merit.edu Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt In-reply-to: (Your message of "Tue, 03 Sep 2002 17:09:11 PDT.") <8A2634EA-BF9A-11D6-9CEA-000393760260@apple.com> Date: Tue, 03 Sep 2002 20:59:34 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > If the nodes receiving the multicast are a subset of the nodes > receiving broadcasts, wouldn't it be impossible for an mDNS/LLMNR reply > to make it to a node where the IPv4LL address would be inaccessible? I'm not sure that the LL multicast hosts are necessarily a strict subset of the hosts capable of receiving broadcasts, because of the various kinds of L2 switching and bridging technologies out there that treat broadcast and multicast differently. It seems like a dubious assumption. just as one example, is CGMP aware of broadcast boundaries? note for that for the purposes of the requirements document it isn't necessary to actually answer the question - just to determine whether there's a requirement that the scope of name lookup results be (able to be) bounded by the local link (in unicast LL terms) scope. Keith From owner-zeroconf@merit.edu Wed Sep 4 10:22:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01213 for ; Wed, 4 Sep 2002 10:22:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5BC489127B; Wed, 4 Sep 2002 10:24:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 235439127C; Wed, 4 Sep 2002 10:24:09 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 35BDC9127B for ; Wed, 4 Sep 2002 10:24:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B7185DF2B; Wed, 4 Sep 2002 10:24:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from smtp1.extremenetworks.com (smtp1.extremenetworks.com [216.52.8.6]) by segue.merit.edu (Postfix) with ESMTP id EDEED5DF20 for ; Wed, 4 Sep 2002 10:24:07 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.103]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 2829B7A0A; Wed, 4 Sep 2002 07:24:05 -0700 (PDT) Date: Wed, 4 Sep 2002 09:04:57 -0400 Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Zeroconf@merit.edu To: Keith Moore From: RJ Atkinson In-Reply-To: <200209040059.g840xY011882@astro.cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, Sep 3, 2002, at 20:59 America/Montreal, Keith Moore wrote: > just as one example, is CGMP aware of broadcast boundaries? CGMP is an interesting practical case, but is irrelevant to the IETF and this conversation, since it is cisco's proprietary protocol. CGMP was designed to compensate for the absence of IGMP support in cisco's Ethernet switches. In effect, networks that require CGMP are broken with respect to the IP Multicast specifications. Most modern Ethernet switches are IGMP-aware and don't need or use CGMP. Ran rja@extremenetworks.com From owner-zeroconf@merit.edu Wed Sep 4 10:40:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02408 for ; Wed, 4 Sep 2002 10:40:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 378D49127F; Wed, 4 Sep 2002 10:41:40 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 074C091280; Wed, 4 Sep 2002 10:41:39 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED5209127F for ; Wed, 4 Sep 2002 10:41:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D17D25DDC3; Wed, 4 Sep 2002 10:41:38 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 9A1B95DD90 for ; Wed, 4 Sep 2002 10:41:38 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g84Efa008390; Wed, 4 Sep 2002 10:41:36 -0400 (EDT) Message-Id: <200209041441.g84Efa008390@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: RJ Atkinson Cc: Keith Moore , Zeroconf@merit.edu Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt In-reply-to: (Your message of "Wed, 04 Sep 2002 09:04:57 EDT.") Date: Wed, 04 Sep 2002 10:41:36 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > just as one example, is CGMP aware of broadcast boundaries? > > CGMP is an interesting practical case, but is irrelevant to the IETF > and this conversation, since it is cisco's proprietary protocol. I disagree that it's irrelevant - if an assumption held by this group (or one that is implicit in the zeroconf architecture) doesn't hold true in practice, that can affect the reliability and deployability of the zeroconf technologies. Which is not to say that every kind of vendor-brokenness should be accomodated, or that any specific vendor's brokenness should be accomodated. I cite this only as one concrete real-world example of why it may be unrealistic to expect that LL multicast is supported even on media that are supposed to support it, and why it may be unrealistic to expect that LL multicast and LL unicast have the same scope. Given the inherent nature of L2 switches and L2 bridges between dissimilar media, it would not surprise me if there are other examples - though I don't know of any offhand. The real point here is to raise the questions - given that LL addresses are inherently of limited scope, is there an expectation that the zeroconf name lookup protocol needs to be able to limit its answers to include only addresses which are usable by the host making the query? - if so, is there an expectation that using LL multicast to do such queries provides an effective mechanism for limiting the results in this way? - and in particular, is there an expectation that LL multicast and LL unicast have the same scope? if so, it seems like such expectations should be stated explicitly. and if none of these are the case, then it begs the question - given that LL unicast addresses are ambiguous and only usable within a limited scope, how do hosts that obtain such addresses from other hosts (whether by LLMNR or other means) know whether such LL addresses should be valid for them? Keith From owner-zeroconf@merit.edu Wed Sep 4 11:39:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05760 for ; Wed, 4 Sep 2002 11:39:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A06449128A; Wed, 4 Sep 2002 11:40:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 69E8C9128B; Wed, 4 Sep 2002 11:40:34 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C2C39128A for ; Wed, 4 Sep 2002 11:40:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5651A5DDC0; Wed, 4 Sep 2002 11:40:33 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from smtp1.extremenetworks.com (smtp1.extremenetworks.com [216.52.8.6]) by segue.merit.edu (Postfix) with ESMTP id 341F85DD90 for ; Wed, 4 Sep 2002 11:40:33 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.103]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 20C447A0A; Wed, 4 Sep 2002 08:40:27 -0700 (PDT) Date: Wed, 4 Sep 2002 11:40:27 -0400 Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Zeroconf@merit.edu To: Keith Moore From: RJ Atkinson In-Reply-To: <200209041441.g84Efa008390@astro.cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Sep 4, 2002, at 10:41 America/Montreal, Keith Moore wrote: > Which is not to say that every kind of vendor-brokenness should be > accomodated, > or that any specific vendor's brokenness should be accomodated. > > I cite this only as one concrete real-world example of why it may be > unrealistic > to expect that LL multicast is supported even on media that are > supposed to > support it, and why it may be unrealistic to expect that LL multicast > and LL > unicast have the same scope. Given the inherent nature of L2 switches > and L2 > bridges between dissimilar media, it would not surprise me if there > are other > examples - though I don't know of any offhand. Keith, Several different IETF and IEEE standards require Ethernet switches to properly accomodate IP multicasting. Deployments of broken equipment don't justify any changes to IETF or IEEE standards or requirements. And in my experience most Ethernet switches handle IP multicasting properly. The broken implementations are limited to one particular vendor (not Extreme) to the best of my knowledge (If you continue to take the position quoted above, I'll also ask you to quit complaining about NAT since it is widely deployed and breaks various other things. By the logic above, NAT-tolerance should be an IETF design requirement -- something which you often argue vocally against. :-) Ran rja@extremenetworks.com From owner-zeroconf@merit.edu Wed Sep 4 11:47:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06202 for ; Wed, 4 Sep 2002 11:47:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AC47291218; Wed, 4 Sep 2002 11:48:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF8A59127D; Wed, 4 Sep 2002 11:48:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 41ACF91218 for ; Wed, 4 Sep 2002 11:47:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2521A5DDC6; Wed, 4 Sep 2002 11:47:38 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id B13425DDB8 for ; Wed, 4 Sep 2002 11:47:37 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g84FlZ009101; Wed, 4 Sep 2002 11:47:35 -0400 (EDT) Message-Id: <200209041547.g84FlZ009101@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: RJ Atkinson Cc: Keith Moore , Zeroconf@merit.edu Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt In-reply-to: (Your message of "Wed, 04 Sep 2002 11:40:27 EDT.") Date: Wed, 04 Sep 2002 11:47:35 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk Ran, read my messages again. this discussion is about trying to get the zeroconf requirements and assumptions made explicit. Keith > Several different IETF and IEEE standards require Ethernet switches to > properly accomodate IP multicasting. Deployments of broken equipment > don't justify any changes to IETF or IEEE standards or requirements. > And in my experience most Ethernet switches handle IP multicasting > properly. The broken implementations are limited to one particular > vendor (not Extreme) to the best of my knowledge > > (If you continue to take the position quoted above, I'll also ask you to > quit complaining about NAT since it is widely deployed and breaks > various From owner-zeroconf@merit.edu Tue Sep 10 20:33:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00562 for ; Tue, 10 Sep 2002 20:33:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 75C539135E; Tue, 10 Sep 2002 20:34:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3ACEF9135F; Tue, 10 Sep 2002 20:34:35 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0642C9135E for ; Tue, 10 Sep 2002 20:33:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CD2B45DE2A; Tue, 10 Sep 2002 20:33:18 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id 438DD5DE1A for ; Tue, 10 Sep 2002 20:33:18 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id RAA14481; Tue, 10 Sep 2002 17:33:15 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id RAA14333; Tue, 10 Sep 2002 17:30:41 -0700 (MST)] Received: from motorola.com (mvp-10-238-2-20.corp.mot.com [10.238.2.20]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g8B0Wx7C001470; Wed, 11 Sep 2002 10:33:03 +1000 (EST) Message-ID: <3D7E8F3B.4030808@motorola.com> Date: Wed, 11 Sep 2002 10:32:59 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Cc: Zeroconf Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt References: <200209032052.g83Kqq010629@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Firstly, thanks for your comments. I appreciate the time and care you have put into them. I have been away, so it has taken me a little time to get around to replying. Keith Moore wrote: > then again, I'd vastly prefer that we call these things 'design goals'. > somehow the word 'requirements' keeps sticking in people's minds even > though these documents are rarely either prescient or robust enough > to actually be considered 'requirements'. > "Requirements" documents are currently 100% buzzword compliant in the IETF at the moment... ;) > executive summary: > > - the requirements seem incomplete. important considerations - such as > the impact of zeroconf technologies on existing applications and > existing networks - are omitted. > I'm happy to add two requirements: 1. that zeroconf technologies not interefere with operation or security on managed networks 2. that zeroconf minimize impact on existing applications > - a few of the requirements seem dubious > Not sure I follow exactly what you are referring to. > details: > > section 1.3 > > the document doesn't say that there are absolutely no dependencies > between zeroconf technologies, so perhaps this is just a nit. > > but if you expect the name-to-address translation service to be able to > return limited-scope addresses in response to queries (and you clearly > do) then there is a dependency between the name-to-address translation > service and the scope of such addresses - namely, the service needs to > be aware of the scope boundaries of its clients. otherwise it will > return addresses that are unusable by its clients and may in fact point > to completely different hosts. > > concrete example: if the scope of LL v4 addresses and LL v4 multicast > are not the same (and they could easily differ) then an mDNS/LLMNR lookup > can easily return an address that isn't usable by the client. of course > if you put such addresses in DNS then you have even more problems. > > so I think there are unstated requirements that > > - the zeroconf technologies coexist with each other in a useful way, > which is to say that they can be consistent with one another > > - the zeroconf technologies coexist with similar services that > are used in managed networks - either by providing consistent > (or non-conflicting) results or by arranging that the zeroconf > service is not used when the managed service exists. > (even then you still have consistency issues, since the ability > to access the 'managed' services may differ from one node to > another). > > and *those* translate into more specific requirements which I can't > enumerate off the top of my head. > Maybe this is just a requirement that the name service lookup and address scope boundaries should match? The managed network comments seem more relevant to later sections -- where you cover it again.. > section 1.4 > > it's reasonable for scalability to be a secondary goal for truly > ad hoc networks - there seems little point in trying to support > ad hoc networks that consist of thousands of hosts. OTOH, if > zeroconf technologies are to be used on existing networks, scaling > _on those networks_ becomes considerably more of a concern. > > it's been argued on the mailing list that some zeroconf technologies > should be usable on managed networks in addition to ad hoc networks. > indeed, it's been forcefully argued that linklocal should be enabled > by default on all hosts so that it can be used to communicate with > appliances without having to configure such appliances. > > if this is a goal, it needs to be explicit, and the scalability > concern needs to be reconsidered. > > regardless, there needs to be a requirement that zeroconf technologies > not interefere with operation or security on managed networks. > Yes, I agree. Non-interference is a desirable goal. I think people may have disagreed about the presence or seriousness of disruption to current networks in particular proposals but I think everyone agrees that breaking peoples existing networks isn't a win. > section 1.6 > > it's not clear what it means for zeroconf protocols to "restore > the network to a consistent state", especially when all of the > relevant state that I can see is maintained in the hosts and > applications rather than in the network. zeroconf may be able > to resolve address conflicts, but it cannot transparently recover > applications from such conflicts. > > there needs to be a requirement that zeroconf minimize impact on > applications. actually there's little mention of applications > in the document, even though the effect on some kinds of applications > is significant. this seems like a major omission. > > > it's not clear that names, or name-to-address mappings, are properly > considered 'network' resources if they are similar to DNS names > or have the potential to overlap with the DNS name space - either as a > matter of on-the-wire protocol or via APIs that applications use to > look up such names. > Again, I'm happy with a "requirement that zeroconf minimize impact on applications". Regarding the discussion about "network resources" and the like: the text is intended to get the idea across. Some things don't fit the category that well, and right at the moment I'm not seeing a burning need to change the text. > section 2.1 > > again, the document talks about what "hosts" should or should not > assume regarding stability of "network resources" but does not mention > what "applications" may assume or whether zeroconf creates new burdens > for applications. > > section 2.2 (middle of page 6) > > the document talks about "increased robustness" of _zeroconf_ protocols > but says nothing about the effect on the robustness of applications > hosted on hosts that use zeroconf. > Covered by the above general "requirement that zeroconf minimize impact on applications"? > section 3.1 (3rd bullet) [nit?] > > "MUST allow configuration of zero or more gateways (for the internetwork > scenario)". perhaps this is trivially satisfied (because allowing > zero gateways suffices) and it can therefore be omitted. or perhaps it > needs rewording for clarity. > > please remind me of how v4 linklocal facilities connection of gateways? > Sigh. Charter says single router. One needs routing information to send packets in that case. > (last bullet list of requirements on middle page 8) > > it seems like nomadic hosts are likely to connect to multiple networks > in the course of a day. is such a host better off using the same > address each time it connects to a particular network, or better off > trying to claim/defend the same address on every network to which it > connects? would large numbers of nomadic hosts (as seems likely) > seriously affect the stability of linklocal addresses even though the > hosts try to maintain their addresses as they migrate? > > also, given that apps on nomadic hosts might need to keep some connections > open as they move, has any thought been given to interaction between > zeroconf technologies and mobile IP? are there requirements along these > lines waiting to be discovered? > Scope creep? Seems to me that identifying the network you had just plugged into isn't trivial. Before leaping into the next set of comments I should summarise what I believe the state of play is with zeroconf naming. I have been following the discussion in dnsext, and my understanding was that there was general agreement on the following points: - mDNS/LLMNR was *not* DNS, rather it was a seperate protocol, seperate port, seperate cache, etc - there was agreement that mDNS/LLMNR should not be used as a substitute for DNS -- ie should not be used for looking up "one true DNS names" - that mDNS/LLMNR should not be used to transport DNS requests to a "back end resolver" These comments also apply to the IPv6 Node Information Query proposal as well. Right now, the -12 LLMNR document has examples with FQDNs in them. Unless there have been conversations that I am unaware of, I believe it was the intent of the working group *not* to support the resolution of names such as mylaptop.microsoft.com using LLMNR. > section 3.2 > > I keep being told that the name-to-address issue is out of scope for this > group. maybe dnsext should review this portion of the document? or maybe > it should be omitted? especially since mDNS/LLMNR still seems to be in > flux with fundamental problems still unresolved? > > nit: s/quite likely to use a different IP/quite likely to use different IP/ > ^ > > I realize this isn't the only group using the term, but the emphasis on > "host names" seems a bit archaic. these days users rarely care about > accessing "hosts", they care about accessing "services". (sometimes > the host *is* the desired service, but that's the exception rather than > the rule). of course, it's not the use of the term that's important > so much as the assumptions that go along with it. for instance, should > service lookups map to host names and host names to addresses, or should > service lookups map directly to addresses? > Service lookups could do either and one could "name" services. Right now the world doesn't divide neatly down those two lines -- e.g. browser bookmarks contain names. > nit: "for applications like web browsers...the use of names rather than > IP addresses is beneficial". only if the names are more stable > and more mnemonic than the addresses :) not that they're being > proposed by this WG but temporary names aren't very useful for > such purposes. I would say "may be beneficial" rather than "is". > > (page 9, bullets) > if "host names" are or aren't DNS names then it would be good to say that > in the first bullet in the Terms section. that's the first thing a > reader would want to know. > Sure.. > there's no statement about the effect of the name resolution protocol > on APIs that are currently used to look up DNS names. it's an important > question because it will affect apps. there's a desire to have these > things "just work" with existing apps, but at the same time if the > results are inconsistent with DNS then it will cause problems. > If zeroconf name resolution is orthogonal to DNS name resolution, then people can turn it on and use it (it also may be enabled in some situations by default -- for example when there is no DNS server). I don't see a problem for these cases. I also believe that it *is* possible to do implementations where both co-exist quite well. One example is Microsoft's NetBIOS name lookup protocol. My win2k box seems to cope just fine providing you understand that netbios names don't have dots in them. Interestingly, various dialogue boxes that used to only accept netbios names now accept DNS names too. > there's also no statement about the consistency of results of the > lookups using name resolution protocol across different locations. > if the results are inconsistent at different places this will also > break apps that want to use these names to do referrals. > > there needs to be a requirement that lookups of DNS names are consistent > with lookups using DNS. > If the zeroconf name resolution protocols were orthogonal to the DNS then this sort of consistency isn't required. > > "probing a desired host name...must not prevent the desired hostname > from being resolved". > > I'm not sure what this means. > > - "from being resolved...at a later time" ? > - s/must not/MUST NOT/ ? > > again, it is not at all clear that host names are properly treated > as "network resources", i.e. resources that belong to the network. > traditionally DNS names are not related to network topology. > Host wants to test uniqueness of a name it would like to use and will respond to mDNS/LLMNR lookups for. Negative caching of the probes should not prevent the name being looked up for 5 minutes just because the host was testing uniqueness. > this might imply that the network and/or protocols for looking up > such names should be able to detect naming conflicts between DNS-style > names but NOT to adjucate between such conflicts - because the network > is not authoritative for any portion of DNS name space. (individual > hosts might have been assigned such authority - just as they might > be running DNS servers that are authoritative, but the "network" is > not authoritative) > Orthogonal => no problem? > "local" names (that don't look like FQDNs) might be a different matter. > > (I realize that this document says that they aren't DNS names but > mDNS/LLMNR seems to act as if they are DNS names or at least the > spaces can overlap - then consistency becomes an issue) > > see above comments about what I take to be the dnsext position on this stuff. > "zeroconf name resolution protocol MUST support resolution of > names on multiple IP subnets connected by a router". > > I'm not sure what this means - it seems like a network-centric > definition but the hosts/apps are what are implementing the protocol. > Do you mean that the protocol MUST enable resolution of names on > other IP subnets that those to which the host supporting the > querying application is attached? > > again, is there a potential conflict between the use of limited-scope > addresses in this name-to-address lookup service and having the lookup > service work across a larger area than such addresses? > > Well... the charter has this router. The language might be a bit unclear, but I think you got the basic point. In general I believe we would be short-sighted in coming up with a protocol which was not in principle usable within a small routed network. > "zeroconf name resolution protocols MUST allow timely re-use of hostnames" > > again this seems misstated, at least for FQDNs - such names are not > delegated to the network or to zeroconf protocols to manage. > Orthogonal => no problem. > section 3.2.2 > > "host names ...are inherently locally scoped". not from the examples > envisioned in the current mDNS/LLMNR draft. > > "a DNS server supporting dynamic updates can provide automatic configuration > of a DNS name space in a network". I'm not sure what this means. > Are you saying that such a server could (or perhaps should) be used instead > of the zeroconf name lookup service? Are you saying that this mechanism > should be used (when available) to ensure consistency between the zeroconf > service and DNS? > Such a server doesn't really fit the zeroconf picture, however it would work in one place where many people see zeroconf protocols as being useful: the home network. No, I was not suggesting that it was some kind of conflict resolution between the DNS and ZNS. > "The zeroconf namespace is orthogonal to the DNS class IN namespace" > seems irreconcilable with "It is RECOMMENDED that zeroconf host names > conform to the character set and formatting of DNS host names". > (and the latter seems to me to need strong justification) > > EITHER the two services share a common namespace (and need to produce > consistent results with one another) OR they need to be clearly > distinguished from one another - different syntax, different APIs, etc. > so that apps don't get confused and try to treat zeroconf host names > as if they had the same properties of DNS names. > > several requirements seem to be omitted here. > One possibility is to corral all the zeroconf names into a single part of the DNS namespace, for example inside a domain suffix such as "local.arpa". It would be a failure if all existing applications had to be re-written to use ZNS names where they currently use DNS names. From a user point of view, it is important that someone can use a ZNS name in a URL: http://linksys-box/ > "...MUST NOT allow zeroconf names to mask DNS names". this is not > a sufficient restriction. in general it is necessary to produce > consistent results when different hosts in different parts of the network > look up the same DNS-like name, even if those hosts have different > local scopes or if some of those hosts are using zeroconf and others > are using DNS. that's not to say that all RRs for all names need to > be visible to all hosts at all times - that's not even true for pure DNS - > but that (for reasons similar to those given in RFC 2826) the name lookup > service needs to provide a uniform view of DNS-style names from everywhere. > I think this is well put. Again, I think most of the problems go away if we are just clear on the orthogonality of DNS and ZNS. Clearly, ZNS names need to be consistent within a site. A site may be a single broadcast domain, or in general a small routed network. Since a ZNS name is not global, it cannot have the same semantics as a global DNS name. Interestingly, although the main point of RFC 2826 seems to be to debunk alternate DNS roots, it also says: This does not preclude private networks from operating their own private name spaces, but if they wish to make use of names uniquely defined for the global Internet, they have to fetch that information from the global DNS naming hierarchy, and in particular from the coordinated root servers of the global DNS naming hierarchy. I think we're talking about a private namespace. I also think it would be prudent to ensure that the labels used in the private namespace and the DNS do not conflict, which is why I'm keen on the local.arpa/private.arpa fixed domain suffix for private names. btw, that isn't the same as saying that I'm keen on using the suffix to trigger mDNS lookups. > local (unqualified) names are a different matter - we do expect > their meanings to differ from one place to another. > However it is done (no suffix, known suffix, whatever) ZNS names are not globally unique. Their unqiueness can only be guaranteed within the scope of the lookup protocol. > --- > > since I'm busy and I'm mostly concerned about names and addresses, I > didn't review the remainder of the document. > > again, attention to important considerations that were omitted from the > requirements in the document are probably more important than > most of the tweaks suggested above. e.g. compatibility with existing apps, > effects of introduction of zeroconf on the operation of existing/managed > networks. > -- regards aidan ____ :wq! Sydney Network Research Lab aidan.williams@motorola.com Motorola Australian Research Centre phone: +61 2 9666 0649 Locked Bag 5028, Botany NSW 1455 phax: +61 2 9666 0501 Australia http://marc.labs.mot.com/snrl/ From owner-zeroconf@merit.edu Tue Sep 10 21:08:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01130 for ; Tue, 10 Sep 2002 21:08:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D3338912BA; Tue, 10 Sep 2002 21:09:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9676F91360; Tue, 10 Sep 2002 21:09:31 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 886B8912BA for ; Tue, 10 Sep 2002 21:09:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 70A7D5DE96; Tue, 10 Sep 2002 21:09:30 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mta02bw.bigpond.com (mta02bw.bigpond.com [139.134.6.34]) by segue.merit.edu (Postfix) with ESMTP id 2E1775DE1A for ; Tue, 10 Sep 2002 21:09:29 -0400 (EDT) Received: from 192.168.1.246 ([144.135.24.84]) by mta02bw.bigpond.com (Netscape Messaging Server 4.15 mta02bw May 23 2002 23:53:28) with SMTP id H291VO00.BO1; Wed, 11 Sep 2002 11:09:24 +1000 Received: from CPE-203-51-35-162.nsw.bigpond.net.au ([203.51.35.162]) by bwmam06.mailsvc.email.bigpond.com(MailRouter V3.0n 53/1436446); 11 Sep 2002 11:09:24 From: Brad Hards To: Aidan Williams , Keith Moore Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt Date: Wed, 11 Sep 2002 11:03:25 +1000 User-Agent: KMail/1.4.5 Cc: Zeroconf References: <200209032052.g83Kqq010629@astro.cs.utk.edu> <3D7E8F3B.4030808@motorola.com> In-Reply-To: <3D7E8F3B.4030808@motorola.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200209111103.25887.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 11 Sep 2002 10:32, Aidan Williams wrote: > Maybe this is just a requirement that the name service lookup > and address scope boundaries should match? The managed network > comments seem more relevant to later sections -- where you cover > it again.. My mind is not 100% at the moment, but one idea that keeps coming back to me is that perhaps the only thing that should ever appear in LLMNR is LL addresses. So rather than being orthogonal, zeroconf name resolution and DNS name resolution are exclusive. It should always be clear which one you are using. Now when I go to implement this problem, I thinking of hacking the back-end resolver libraries, and adding another option to the name service switch, so my /etc/nsswitch.conf looks like: #hosts: files nisplus nis dns hosts: files nisplus nis dns llmnr Then the dns entry means "DNS only if not in 169.254/16, otherwise fall throught". And when Keith is proved right and some applications fail, getting back to a working arrangement is trivial. Or am I missing something? Brad - -- http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9fpZdW6pHgIdAuOMRAqgEAJ92t1QO1FFWBgug/9Y2IaMPdtulZwCfcKRi kU6nLg18dyQjPTOFd/YC0HQ= =xvOQ -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Tue Sep 10 22:13:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02363 for ; Tue, 10 Sep 2002 22:13:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 03BD591366; Tue, 10 Sep 2002 22:14:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C0F3391367; Tue, 10 Sep 2002 22:14:27 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B10A91366 for ; Tue, 10 Sep 2002 22:14:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 799195DEAD; Tue, 10 Sep 2002 22:14:26 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 154A85DD90 for ; Tue, 10 Sep 2002 22:14:26 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8B2EN010635; Tue, 10 Sep 2002 22:14:23 -0400 (EDT) Message-Id: <200209110214.g8B2EN010635@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Aidan Williams Cc: Keith Moore , Zeroconf Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt In-reply-to: (Your message of "Wed, 11 Sep 2002 10:32:59 +1000.") <3D7E8F3B.4030808@motorola.com> Date: Tue, 10 Sep 2002 22:14:23 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk Thanks for the reply. I think I agree with most of it, will probably respond on a few details later. But to immediately follow-up on probably the most significant issue: I agree that there are far fewer issues with LLMNR/mDNS/ZNS if it is clear that these names are separate from DNS names. However the examples in mdns-12 make me think that they're not going to be separate (especially in contrast to an earlier version of that document where the names were in a private local.arpa space). So it might be a good idea for the requirements document to separately cover both private names and public names because the requirements for the two cases seem to differ considerably. Keith From owner-zeroconf@merit.edu Tue Sep 10 22:48:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03158 for ; Tue, 10 Sep 2002 22:48:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E2F819136B; Tue, 10 Sep 2002 22:50:23 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B30D91369; Tue, 10 Sep 2002 22:50:23 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 62C6B9136B for ; Tue, 10 Sep 2002 22:48:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4425E5DEC3; Tue, 10 Sep 2002 22:48:56 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id CCD135DD90 for ; Tue, 10 Sep 2002 22:48:55 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8B2mo010725; Tue, 10 Sep 2002 22:48:50 -0400 (EDT) Message-Id: <200209110248.g8B2mo010725@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brad Hards Cc: Aidan Williams , Keith Moore , Zeroconf Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt In-reply-to: (Your message of "Wed, 11 Sep 2002 11:03:25 +1000.") <200209111103.25887.bhards@bigpond.net.au> Date: Tue, 10 Sep 2002 22:48:50 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > My mind is not 100% at the moment, but one idea that keeps coming back to me > is that perhaps the only thing that should ever appear in LLMNR is LL > addresses. There are several approaches that could minimize the potential for conflicts between LLMNR and DNS: one is to say (as I think you were suggesting) that LLMNR is where you look up LL addresses and DNS is where you look up global addresses. so they would share a common name space but there would be a more-or-less clear separation of function between the two services, so you never have the services giving conflicting information. (there are still potential issues if the same API is used to access both, and it's not immediately clear how you handle separation of function for non-address RR types) another is to say that LLMNR is for a separate set of names than DNS names - so you use LLMNR to look up "local" names and DNS to look up "non-local" names. the thing is, for some (not all) hosts we would really like them to be able to keep their DNS names even in an ad hoc environment - e.g. as a backup for loss of external connectivity. another is to say that LLMNR only acts as a cache for DNS. that minimizes conflicts but makes it difficult for a host to update its own information if it is disconnected from the DNS server for its zone, so I don't consider it a viable alternative and I mention it only for completeness. another is to say that LLMNR and DNS are just two different ways of getting to the same information (at least for nonlocal names), and we insist that they be consistent with one another to the same degree that we insist that DNS servers for the same zone be consistent with one another. so a host answering LLMNR queries would be required to EITHER act as a DNS cache and return data consistent with the last known data from an authoritative DNS server (and even then, probably only for its "own names") OR be delegated the authority to run its own zone (perhaps consisting of only a single name) and serve as the authoriative master for that zone. as far as DNS were concerned, the parent zone would have an NS record pointing to that host whenever it knew that the host had an externally-accessible address; the host would need to update that NS record whenever it got a new address. I don't think anything would prevent the parent zone from acting as either a secondary or a cache for the child zone, avoiding the extra referral for most queries. so instead of having LLMNR be a separate name service from DNS, it would be just an extension of DNS - a way to get the same information via a slightly different access protocol (and with somewhat less confidence in the LLMNR result due to the absence of an NS chain from the root). It might even be reasonable to put the two under the same API, modulo some concerns about security and differences in error conditions. presumably LLMNR could still handle queries for local (non-dotted) names without having to worry about consistency issues for that case). one interesting consequence of this would be that hosts would need to stop advertising LL addresses whenever they had "real" addresses, so as to not leak LL addresses into DNS. But I suspect the last case can actually be made to work well and would allow LLMNR to produce results as consistent as DNS does now. but I need to analyze it some more to be confident about it. then I will feed it to the lions in dnsext who will no doubt rip it to shreds if it fails some important criterion :) Keith From owner-zeroconf@merit.edu Wed Sep 11 03:35:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00399 for ; Wed, 11 Sep 2002 03:35:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6ACF0912C2; Wed, 11 Sep 2002 03:36:22 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 383C691371; Wed, 11 Sep 2002 03:36:22 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D986A912C2 for ; Wed, 11 Sep 2002 03:36:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B7AC85DE40; Wed, 11 Sep 2002 03:36:20 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from gw-nl6.philips.com (gw-nl6.philips.com [212.153.235.103]) by segue.merit.edu (Postfix) with ESMTP id 385F15DE25 for ; Wed, 11 Sep 2002 03:36:20 -0400 (EDT) Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl6.philips.com (Postfix) with ESMTP id 62466A14A5; Wed, 11 Sep 2002 09:36:18 +0200 (MET DST) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id JAA20687; Wed, 11 Sep 2002 09:36:17 +0200 (MET DST) From: peter.van.der.stok@philips.com Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id JAA19392; Wed, 11 Sep 2002 09:36:16 +0200 (MET DST) To: Keith Moore Cc: Aidan Williams , Zeroconf Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 11 Sep 2002 09:33:51 +0200 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 11/09/2002 09:33:53, Serialize complete at 11/09/2002 09:33:53 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0029C4FDC1256C31_=" Sender: owner-zeroconf@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 0029C4FDC1256C31_= Content-Type: text/plain; charset="us-ascii" Dear all, I tend to agree with the separation of the name space requirements. Currently, we assume that link-local addresses will only be used during the absence of a DHCP server and that DHCP servers will be present in the home because there is always a connection to the outside world via a residential gateway. DHCP servers are also present in for example set-top boxes. Link-local addresses become interesting for ad-hoc networks (two people meeting in the street, or emptying your personal music archive to the home storage). For those cases local names are needed. When connections exist to the outside world, one may consider that local names and global names co-exist and that different mechanisms exist to support them. Simple browsing on local names seems reasonable while more sophisticated searching from applications is wanted for global services. Therefore, I would suggest to decouple the existence of local names from the usage of link-local addresses. Local names can exist independent of link-local addresses. Peter van der Stok Philips Research Laboratories Eindhoven Bldg: WDC 3-041 Prof. Holstlaan 4 Phone: +31 40 2742649 5656 AA Eindhoven Fax: +31 40 2786516 The Netherlands Mailto: Peter.van.der.Stok@ philips.com Keith Moore Sent by: owner-zeroconf@merit.edu 11-09-2002 04:14 To: Aidan Williams cc: Keith Moore Zeroconf (bcc: Peter van der Stok/EHV/RESEARCH/PHILIPS) Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt Classification: Thanks for the reply. I think I agree with most of it, will probably respond on a few details later. But to immediately follow-up on probably the most significant issue: I agree that there are far fewer issues with LLMNR/mDNS/ZNS if it is clear that these names are separate from DNS names. However the examples in mdns-12 make me think that they're not going to be separate (especially in contrast to an earlier version of that document where the names were in a private local.arpa space). So it might be a good idea for the requirements document to separately cover both private names and public names because the requirements for the two cases seem to differ considerably. Keith --=_alternative 0029C4FDC1256C31_= Content-Type: text/html; charset="us-ascii"
Dear all,

I tend to agree with the separation of the name space requirements.
Currently, we assume that link-local addresses will only be used during
the absence of a DHCP server and that DHCP servers will be present in the home
because there is always a connection to the outside world via a residential gateway.
DHCP servers are also present in for example set-top boxes.
Link-local addresses become interesting for ad-hoc networks (two people meeting in the street,
or emptying your personal music archive to the home storage). For those cases
local names are needed.

When connections exist to the outside world, one may consider that local names
and global names co-exist and that different mechanisms exist to support them.
Simple browsing on local names seems reasonable while more sophisticated
searching from applications is wanted for global services.

Therefore, I would suggest to decouple the existence of local names from the
usage of link-local addresses. Local names can exist independent of
link-local addresses.

Peter van der Stok                Philips Research Laboratories Eindhoven
Bldg: WDC 3-041                  Prof. Holstlaan 4
Phone: +31 40 2742649       5656 AA Eindhoven
Fax:      +31 40 2786516       The Netherlands
Mailto: Peter.van.der.Stok@ philips.com


Keith Moore <moore@cs.utk.edu>
Sent by: owner-zeroconf@merit.edu

11-09-2002 04:14

       
        To:        Aidan Williams <aidan.williams@motorola.com>
        cc:        Keith Moore <moore@cs.utk.edu>
Zeroconf <zeroconf@merit.edu>
(bcc: Peter van der Stok/EHV/RESEARCH/PHILIPS)
        Subject:        Re: comments on draft-ietf-zeroconf-reqts-11.txt

        Classification:        




Thanks for the reply.  I think I agree with most of it, will
probably respond on a few details later.

But to immediately follow-up on probably the most significant issue:
I agree that there are far fewer issues with LLMNR/mDNS/ZNS if it
is clear that these names are separate from DNS names.  However the
examples in mdns-12 make me think that they're not going to be separate
(especially in contrast to an earlier version of that document where
the names were in a private local.arpa space).  

So it might be a good idea for the requirements document to separately
cover both private names and public names because the requirements for
the two cases seem to differ considerably.

Keith

--=_alternative 0029C4FDC1256C31_=-- From owner-zeroconf@merit.edu Wed Sep 11 10:33:29 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11082 for ; Wed, 11 Sep 2002 10:33:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 27E3B912D3; Wed, 11 Sep 2002 10:34:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2764912D8; Wed, 11 Sep 2002 10:34:07 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC5F6912D3 for ; Wed, 11 Sep 2002 10:33:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0D44D5DE39; Wed, 11 Sep 2002 10:33:03 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by segue.merit.edu (Postfix) with ESMTP id 9DA945DE37 for ; Wed, 11 Sep 2002 10:33:02 -0400 (EDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8BEX1lg022782 for ; Wed, 11 Sep 2002 10:33:01 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8BEWxa6053244 for ; Wed, 11 Sep 2002 10:32:59 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g8BET1328162 for ; Wed, 11 Sep 2002 10:29:01 -0400 Message-Id: <200209111429.g8BET1328162@rotala.raleigh.ibm.com> To: zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-06.txt In-Reply-To: Message from "Wed, 28 Aug 2002 12:19:30 EDT." Date: Wed, 11 Sep 2002 10:29:01 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Thomas Narten writes: > In re-reviewing the document, I had the following comments: > Most are nits. The one substantive comment is: > If the destination address is in the 169.254/16 prefix (including the > 169.254.255.255 broadcast address), the host SHOULD use its link- > local source address, if it has one. If the host does not have a > link-local source address, then it MAY choose to ARP for the > destination address and then send its packet, with a routable source > IP address and a link-local destination IP address, directly to its > destination on the same physical link. The host MUST NOT send the > packet to any router for forwarding. > The above wording suggests that if host has no LL address, it is not > required to use its global address to talk to a device that only has a > LL address. This seems broken (i.e, will result in communication > failure that is hard to diagnose). Seems to me that SHOULD->MUST and > the MAY should also be a MUST. I have seen no followup on this question. Does this mean that the WG doesn't think there is an issue? Doesn't care? Or? PS, it would be good to resolve this so I can get the document before the IESG for consideration. Thomas From owner-zeroconf@merit.edu Wed Sep 11 11:59:25 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14064 for ; Wed, 11 Sep 2002 11:59:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A956F91388; Wed, 11 Sep 2002 11:57:51 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 82C3991382; Wed, 11 Sep 2002 11:57:51 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2A07B91381 for ; Wed, 11 Sep 2002 11:56:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 14FD15DE49; Wed, 11 Sep 2002 11:56:10 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id A2DE45DE43 for ; Wed, 11 Sep 2002 11:56:09 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8BFu2007717; Wed, 11 Sep 2002 11:56:02 -0400 (EDT) Message-Id: <200209111556.g8BFu2007717@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-06.txt In-reply-to: (Your message of "Wed, 11 Sep 2002 10:29:01 EDT.") <200209111429.g8BET1328162@rotala.raleigh.ibm.com> Date: Wed, 11 Sep 2002 11:56:02 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > If the destination address is in the 169.254/16 prefix (including the > > 169.254.255.255 broadcast address), the host SHOULD use its link- > > local source address, if it has one. If the host does not have a > > link-local source address, then it MAY choose to ARP for the > > destination address and then send its packet, with a routable source > > IP address and a link-local destination IP address, directly to its > > destination on the same physical link. The host MUST NOT send the > > packet to any router for forwarding. > > > The above wording suggests that if host has no LL address, it is not > > required to use its global address to talk to a device that only has a > > LL address. This seems broken (i.e, will result in communication > > failure that is hard to diagnose). Seems to me that SHOULD->MUST and > > the MAY should also be a MUST. > > I have seen no followup on this question. Does this mean that the WG > doesn't think there is an issue? Doesn't care? Or? "MUST use LL source address" is not acceptable - there are apps that will break if this is done. I'd argue that hosts SHOULD use a global address whenever possible (if nothing else, for the sake of backward compatibility) and SHOULD NOT use an LL source address -- even when talking to an LL destination -- except as a last resort. Keith From owner-zeroconf@merit.edu Wed Sep 11 13:08:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16939 for ; Wed, 11 Sep 2002 13:08:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A4DD091386; Wed, 11 Sep 2002 13:09:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E5B091382; Wed, 11 Sep 2002 13:09:54 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 133F49130D for ; Wed, 11 Sep 2002 13:09:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0250A5DE5A; Wed, 11 Sep 2002 13:09:53 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by segue.merit.edu (Postfix) with ESMTP id 931EE5DE59 for ; Wed, 11 Sep 2002 13:09:52 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8BH9gDf144430; Wed, 11 Sep 2002 13:09:42 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8BH9mRA164172; Wed, 11 Sep 2002 11:09:48 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g8BH5pa29206; Wed, 11 Sep 2002 13:05:51 -0400 Message-Id: <200209111705.g8BH5pa29206@rotala.raleigh.ibm.com> To: Keith Moore Cc: zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-06.txt In-Reply-To: Message from "Wed, 11 Sep 2002 11:56:02 EDT." <200209111556.g8BFu2007717@astro.cs.utk.edu> Date: Wed, 11 Sep 2002 13:05:51 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Keith, > > > If the destination address is in the 169.254/16 prefix (including the > > > 169.254.255.255 broadcast address), the host SHOULD use its link- > > > local source address, if it has one. If the host does not have a > > > link-local source address, then it MAY choose to ARP for the > > > destination address and then send its packet, with a routable source > > > IP address and a link-local destination IP address, directly to its > > > destination on the same physical link. The host MUST NOT send the > > > packet to any router for forwarding. > > > > > The above wording suggests that if host has no LL address, it is not > > > required to use its global address to talk to a device that only has a > > > LL address. This seems broken (i.e, will result in communication > > > failure that is hard to diagnose). Seems to me that SHOULD->MUST and > > > the MAY should also be a MUST. > > > > I have seen no followup on this question. Does this mean that the WG > > doesn't think there is an issue? Doesn't care? Or? > "MUST use LL source address" is not acceptable - there are apps that > will break if this is done. To what wording are you referring? That wording is not mentioned above. > I'd argue that hosts SHOULD use a global address whenever possible > (if nothing else, for the sake of backward compatibility) and SHOULD > NOT use an LL source address -- even when talking to an LL > destination -- except as a last resort. If your destination is an LL address, what difference does it make if you use your LL vs global source address to talk to it? In neither case can you move off-link and continue having things work. Thomas From owner-zeroconf@merit.edu Wed Sep 11 13:20:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17490 for ; Wed, 11 Sep 2002 13:20:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D466891382; Wed, 11 Sep 2002 13:17:33 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 87F7091399; Wed, 11 Sep 2002 13:17:31 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B5A1A91382 for ; Wed, 11 Sep 2002 13:16:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 42CA95DE43; Wed, 11 Sep 2002 13:16:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id ADF375DDEE for ; Wed, 11 Sep 2002 13:16:11 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8BHG7005631; Wed, 11 Sep 2002 13:16:09 -0400 (EDT) Message-Id: <200209111716.g8BHG7005631@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Thomas Narten Cc: Keith Moore , zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-06.txt In-reply-to: (Your message of "Wed, 11 Sep 2002 13:05:51 EDT.") <200209111705.g8BH5pa29206@rotala.raleigh.ibm.com> Date: Wed, 11 Sep 2002 13:16:07 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > > > If the destination address is in the 169.254/16 prefix (including the > > > > 169.254.255.255 broadcast address), the host SHOULD use its link- > > > > local source address, if it has one. If the host does not have a > > > > link-local source address, then it MAY choose to ARP for the > > > > destination address and then send its packet, with a routable source > > > > IP address and a link-local destination IP address, directly to its > > > > destination on the same physical link. The host MUST NOT send the > > > > packet to any router for forwarding. > > > > > > > The above wording suggests that if host has no LL address, it is not > > > > required to use its global address to talk to a device that only has a > > > > LL address. This seems broken (i.e, will result in communication > > > > failure that is hard to diagnose). Seems to me that SHOULD->MUST and > > > > the MAY should also be a MUST. > > > > > > I have seen no followup on this question. Does this mean that the WG > > > doesn't think there is an issue? Doesn't care? Or? > > > "MUST use LL source address" is not acceptable - there are apps that > > will break if this is done. > > To what wording are you referring? That wording is not mentioned above. I'm referring to "Seems to me that SHOULD->MUST and the MAY should also be a MUST" or did I misinterpret it? > > I'd argue that hosts SHOULD use a global address whenever possible > > (if nothing else, for the sake of backward compatibility) and SHOULD > > NOT use an LL source address -- even when talking to an LL > > destination -- except as a last resort. > > If your destination is an LL address, what difference does it make if > you use your LL vs global source address to talk to it? In neither > case can you move off-link and continue having things work. some apps use source addresses for referrals. an LL source address might work fine for a referral from one destination, but not from another. (ironically one justification for using source addresss in referrals rather than some address passed in the payload is NATs) Keith From owner-zeroconf@merit.edu Wed Sep 11 13:33:22 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17938 for ; Wed, 11 Sep 2002 13:33:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B8E5991401; Wed, 11 Sep 2002 13:33:01 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2472391395; Wed, 11 Sep 2002 13:32:37 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B99D791401 for ; Wed, 11 Sep 2002 13:31:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 50D955DE3A; Wed, 11 Sep 2002 13:31:47 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from DIN-SMTPOUT.dreamersi.net (din-smtpout.dreamersi.net [216.217.219.195]) by segue.merit.edu (Postfix) with ESMTP id 4E52B5DE59 for ; Wed, 11 Sep 2002 13:31:45 -0400 (EDT) Received: from ADAM3 ([216.137.29.184]) by DIN-SMTPOUT.dreamersi.net with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Sep 2002 10:30:36 -0700 From: "Adam MacBeth" To: "'Keith Moore'" , "'Brad Hards'" Cc: "'Aidan Williams'" , "'Zeroconf'" Subject: RE: comments on draft-ietf-zeroconf-reqts-11.txt Date: Wed, 11 Sep 2002 10:33:21 -0700 Message-ID: <000901c259b9$52f75d40$950aa8c0@oius.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200209110248.g8B2mo010725@astro.cs.utk.edu> X-OriginalArrivalTime: 11 Sep 2002 17:30:36.0250 (UTC) FILETIME=[F06FABA0:01C259B8] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit There are some very important issues to be resolved here. If LLMNR and DNS are used to resolve names from two different and exclusive namespaces, then a lot of applications will break. Take a scenario where I have 2 devices in a home network not using zeroconf. Device A has a URL referring to Device B which is resolved just fine using DNS when the 2 devices are in the home network. If I then take these (mobile) devices out of the managed environment and they form an adhoc network and start using zeroconf, Device A can no longer resolve its URL pointing to Device B, because that URL includes a global name and LLMNR would only allow resolution of local names. So we have a case here where 2 devices which know the names of one another cannot communicate. This was one of Keith's points but struck me as an example of breaking applications which should be reinforced. > -----Original Message----- > From: owner-zeroconf@merit.edu [mailto:owner-zeroconf@merit.edu] On Behalf > Of Keith Moore > Sent: Tuesday, September 10, 2002 7:49 PM > To: Brad Hards > Cc: Aidan Williams; Keith Moore; Zeroconf > Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt > > > My mind is not 100% at the moment, but one idea that keeps coming back > to me > > is that perhaps the only thing that should ever appear in LLMNR is LL > > addresses. > > There are several approaches that could minimize the potential for > conflicts > between LLMNR and DNS: > > one is to say (as I think you were suggesting) that LLMNR is where you > look > up LL addresses and DNS is where you look up global addresses. so they > would share a common name space but there would be a more-or-less clear > separation > of function between the two services, so you never have the services > giving > conflicting information. (there are still potential issues if the same > API > is used to access both, and it's not immediately clear how you handle > separation of function for non-address RR types) > > another is to say that LLMNR is for a separate set of names than DNS names > - > so you use LLMNR to look up "local" names and DNS to look up "non-local" > names. the thing is, for some (not all) hosts we would really like them > to be able to keep their DNS names even in an ad hoc environment - e.g. > as a backup for loss of external connectivity. > > another is to say that LLMNR only acts as a cache for DNS. that minimizes > conflicts but makes it difficult for a host to update its own information > if it is disconnected from the DNS server for its zone, so I don't > consider > it a viable alternative and I mention it only for completeness. > > another is to say that LLMNR and DNS are just two different ways of > getting > to the same information (at least for nonlocal names), and we insist that > they be consistent with one another to the same degree that we insist that > DNS servers for the same zone be consistent with one another. so a host > answering LLMNR queries would be required to EITHER act as a DNS cache > and return data consistent with the last known data from an authoritative > DNS server (and even then, probably only for its "own names") OR be > delegated > the authority to run its own zone (perhaps consisting of only a single > name) > and serve as the authoriative master for that zone. as far as DNS were > concerned, the parent zone would have an NS record pointing to that host > whenever it knew that the host had an externally-accessible address; > the host would need to update that NS record whenever it got a new > address. > I don't think anything would prevent the parent zone from acting as either > a secondary or a cache for the child zone, avoiding the extra referral for > most queries. so instead of having LLMNR be a separate name service from > DNS, > it would be just an extension of DNS - a way to get the same information > via a slightly different access protocol (and with somewhat less > confidence > in the LLMNR result due to the absence of an NS chain from the root). It > might even be reasonable to put the two under the same API, modulo some > concerns about security and differences in error conditions. presumably > LLMNR could still handle queries for local (non-dotted) names without > having > to worry about consistency issues for that case). one interesting > consequence > of this would be that hosts would need to stop advertising LL addresses > whenever they had "real" addresses, so as to not leak LL addresses into > DNS. > > But I suspect the last case can actually be made to work well and would > allow > LLMNR to produce results as consistent as DNS does now. but I need to > analyze > it some more to be confident about it. then I will feed it to the lions > in > dnsext who will no doubt rip it to shreds if it fails some important > criterion :) > > Keith From owner-zeroconf@merit.edu Wed Sep 11 13:42:20 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18334 for ; Wed, 11 Sep 2002 13:42:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DB85691390; Wed, 11 Sep 2002 13:41:26 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6EE689138E; Wed, 11 Sep 2002 13:41:26 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D058C9130E for ; Wed, 11 Sep 2002 13:41:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B56265DE5A; Wed, 11 Sep 2002 13:41:18 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 4801C5DDEE for ; Wed, 11 Sep 2002 13:41:18 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8BHdl010805; Wed, 11 Sep 2002 13:39:49 -0400 (EDT) Message-Id: <200209111739.g8BHdl010805@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Adam MacBeth" Cc: "'Keith Moore'" , "'Brad Hards'" , "'Aidan Williams'" , "'Zeroconf'" Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt In-reply-to: (Your message of "Wed, 11 Sep 2002 10:33:21 PDT.") <000901c259b9$52f75d40$950aa8c0@oius.com> Date: Wed, 11 Sep 2002 13:39:46 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk I probably would not call this "breaking" an application because it is something that doesn't work before introducing zeroconf - so the fact that it doesn't work after introducing zeroconf doesn't sound like breakage to me. However I think it's a good example of something that we would very much like to work - we will be very disappointed if zeroconf does not handle this case. My own best intiution is that zeroconf name lookup needs to handle both globally-scoped and locally-scoped names, but it needs to handle globally-scoped names in a way that is consistent with DNS, and the rules for looking up locally-scoped names may need to be different from those for globally-scoped names. > There are some very important issues to be resolved here. If LLMNR and > DNS are used to resolve names from two different and exclusive > namespaces, then a lot of applications will break. > > Take a scenario where I have 2 devices in a home network not using > zeroconf. Device A has a URL referring to Device B which is resolved > just fine using DNS when the 2 devices are in the home network. If I > then take these (mobile) devices out of the managed environment and they > form an adhoc network and start using zeroconf, Device A can no longer > resolve its URL pointing to Device B, because that URL includes a global > name and LLMNR would only allow resolution of local names. > > So we have a case here where 2 devices which know the names of one > another cannot communicate. > > This was one of Keith's points but struck me as an example of breaking > applications which should be reinforced. From owner-zeroconf@merit.edu Wed Sep 11 13:42:47 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18374 for ; Wed, 11 Sep 2002 13:42:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7190B91395; Wed, 11 Sep 2002 13:42:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4271D91396; Wed, 11 Sep 2002 13:42:39 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2AEF491395 for ; Wed, 11 Sep 2002 13:42:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0F5295DE59; Wed, 11 Sep 2002 13:42:35 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by segue.merit.edu (Postfix) with ESMTP id 9A45E5DDEE for ; Wed, 11 Sep 2002 13:42:34 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8BHgNDf049384; Wed, 11 Sep 2002 13:42:23 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8BHgTRA268906; Wed, 11 Sep 2002 11:42:29 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g8BHcW829434; Wed, 11 Sep 2002 13:38:32 -0400 Message-Id: <200209111738.g8BHcW829434@rotala.raleigh.ibm.com> To: Keith Moore Cc: zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-06.txt In-Reply-To: Message from "Wed, 11 Sep 2002 13:16:07 EDT." <200209111716.g8BHG7005631@astro.cs.utk.edu> Date: Wed, 11 Sep 2002 13:38:32 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk > I'm referring to > "Seems to me that SHOULD->MUST and the MAY should also be a MUST" > or did I misinterpret it? OK. I was confused. Indeed, my original note was confusing. Please ignore it. :-( Let me try again. What I meant to say is: If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), the host SHOULD use its link- local source address, if it has one. If the host does not have a link-local source address, then it MAY choose to ARP for the destination address and then send its packet, with a routable source IP address and a link-local destination IP address, directly to its destination on the same physical link. The host MUST NOT send the packet to any router for forwarding. The above wording suggests that if host has no LL address, but it does have a global address, it is not required to use that global address to talk to a device that only has a LL address. This seems broken. I.e, it will result in communication failure that is hard to diagnose. Two nodes, both with legitimate addresses that should work, for some strange reason won't talk to each other. Seems to me like the MAY should really be a MUST. You can't NOT use the global address, if it's the only address you have. Or, if there are legitimate reasons why an implementation might not want to use its global address in this case (knowing that communication will fail as a result) please include some background explaining why this might be a reasonable approach. In contrast to my first message, I don't have a problem with the first SHOULD. Thus, Keith's followup is not on my point at all, but on existing text, that I incorrectly suggested should be changed.. Thomas From owner-zeroconf@merit.edu Wed Sep 11 13:56:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19118 for ; Wed, 11 Sep 2002 13:56:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 45AEF91391; Wed, 11 Sep 2002 13:58:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02C3691394; Wed, 11 Sep 2002 13:58:26 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E0C6591391 for ; Wed, 11 Sep 2002 13:58:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CA0275DE3A; Wed, 11 Sep 2002 13:58:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 4B8D35DE5A for ; Wed, 11 Sep 2002 13:58:25 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8BHwN019149; Wed, 11 Sep 2002 13:58:23 -0400 (EDT) Message-Id: <200209111758.g8BHwN019149@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Thomas Narten Cc: Keith Moore , zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-06.txt In-reply-to: (Your message of "Wed, 11 Sep 2002 13:38:32 EDT.") <200209111738.g8BHcW829434@rotala.raleigh.ibm.com> Date: Wed, 11 Sep 2002 13:58:22 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk Okay, first I would say that a host SHOULD NOT give up trying to contact a destination just because the destination was specified as an LL address but the host doesn't have an LL address. IMHO it SHOULD try using the routable address before giving up. But I'd go even farther - IMHO it SHOULD try using a routable address first, and use the LL address (if it has one) only as a last resort. I hesitate to say MUST NOT here because the host might have imposed administrative controls or some such on the use of certain source addresses. That and I don't recall that we've ever said that a host MUST use all available source addresses in order to try to contact a destination, so I don't know why we should impose such a constraint specifically for LL. This I think illustrates some of the fundamental problems with limited- scope addresses - (a) successful use of such addresses depends on the app or the host picking the "right" addresses in the absence of the information needed to determine which ones are "right", (b) partially because that knowledge is lacking, the host or app may need to make multiple connection attempts with different combinations of source and/or destination addresses before finding one that will work (thus introducing delay), and (c) even a source/dest combination that works for one host pair may not suffice for use in referrals by either that source or dest to other components of that app that reside on other hosts. Keith From owner-zeroconf@merit.edu Wed Sep 11 15:11:03 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21816 for ; Wed, 11 Sep 2002 15:11:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 840B4913B0; Wed, 11 Sep 2002 15:11:37 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B3B4913B6; Wed, 11 Sep 2002 15:11:37 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6767A913B0 for ; Wed, 11 Sep 2002 15:11:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 55D6A5DDC2; Wed, 11 Sep 2002 15:11:30 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by segue.merit.edu (Postfix) with ESMTP id 338465DD8C for ; Wed, 11 Sep 2002 15:11:29 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8BJAsf4051284; Wed, 11 Sep 2002 15:10:54 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8BJArRA277400; Wed, 11 Sep 2002 13:10:53 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g8BJ6rc29976; Wed, 11 Sep 2002 15:06:53 -0400 Message-Id: <200209111906.g8BJ6rc29976@rotala.raleigh.ibm.com> To: Keith Moore Cc: Zeroconf , iesg@ietf.org Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt In-Reply-To: Message from "Tue, 03 Sep 2002 16:52:52 EDT." <200209032052.g83Kqq010629@astro.cs.utk.edu> Date: Wed, 11 Sep 2002 15:06:52 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Keith, Having just reread this document, here are some thoughts on your comments. > these comments are intended as input into IESG decision-making > about whether to publish draft-ietf-zeroconf-reqts-11.txt as > Informational, and also to the zeroconf WG as input to a possible > future revision of this document. It would be helpful if more of your comments were along the lines of change the following text to . For some of your comments, its hard to say what sort of wording change you are asking for or if you are just saying the idea is so broken there is no way forward. > I see this document as somewhat more important than the typical WG > requirements document since zeroconf technologies have the potential > to have wide-ranging effects on internet applications and networks, > and presumably the linklocal document will be evaluated for 'known > technical omissions' with respect to these requirements. so if these > requirements are incomplete or poorly-founded, they don't serve as a > good basis for judging linklocal. The linklocal document is basically done and even implemented. Those that have implemented seem to think it is useful. As is the case with many requirements-type documents (unfortunately), the wish list isn't perfect and one can imagine additional desirable-to-have things that, if included, would result in change in a subsequent protocol document. At this point in time, I think issues you might have with the requirements relating to the linklocal document should also come with a clear indication of what changes you think are necessary in the LL document. > it does seem odd that the requirements document hasn't been formally > reviewed by a wider community before now, and even now is not subject > to IETF-wide last call. even if they're just informational from the > standpoint of standardization they're being used to justify features > of standards-track protocols - so we should probably give them more > scrutiny than typical 'informational' documents. Most requirements-type documents are not IETF-wide last called. > then again, I'd vastly prefer that we call these things 'design goals'. > somehow the word 'requirements' keeps sticking in people's minds even > though these documents are rarely either prescient or robust enough > to actually be considered 'requirements'. I am sympathetic to this, as they are recommendations in the end after all. > ---------------------------------------------------------------------- > executive summary: > - the requirements seem incomplete. important considerations - such as > the impact of zeroconf technologies on existing applications and > existing networks - are omitted. The problem I see with this is that I suspect you are asking for something like: "zeroconf technologies MUST NOT have impact on existing applications", and your view appears to be that use of link-local addresses by applications will break them. Thus, the entire LL document should not go forward. Is this an accurate reflection of your position? If not, what impacts are you concerned about and what would the corresponding general requirements be (and can those requirements in fact even be met)? > - a few of the requirements seem dubious Specific text please... > details: > section 1.3 > the document doesn't say that there are absolutely no dependencies > between zeroconf technologies, so perhaps this is just a nit. Are you asking for specific text be added? If so, please indicate what. > but if you expect the name-to-address translation service to be able to > return limited-scope addresses in response to queries (and you clearly > do) then there is a dependency between the name-to-address translation > service and the scope of such addresses - namely, the service needs to > be aware of the scope boundaries of its clients. otherwise it will > return addresses that are unusable by its clients and may in fact point > to completely different hosts. > concrete example: if the scope of LL v4 addresses and LL v4 multicast > are not the same (and they could easily differ) then an mDNS/LLMNR lookup > can easily return an address that isn't usable by the client. of course > if you put such addresses in DNS then you have even more problems. > so I think there are unstated requirements that > - the zeroconf technologies coexist with each other in a useful way, > which is to say that they can be consistent with one another Again, send text. I think what you may be wanting the requirements document to say is that the different pieces of zeroconf technology must work together consistently/coherently. Or something like this. This make sense to me, but I'm sort of assuming that. > - the zeroconf technologies coexist with similar services that > are used in managed networks - either by providing consistent > (or non-conflicting) results or by arranging that the zeroconf > service is not used when the managed service exists. > (even then you still have consistency issues, since the ability > to access the 'managed' services may differ from one node to > another). > > and *those* translate into more specific requirements which I can't > enumerate off the top of my head. My recollection is that earlier versions of the draft included more text about coexistance between managed and unmanaged resouces. I do wonder if more text should be added back in. But this is a fairly hard/subtle issue. For example, do we really understand how we want zeroconf name resolution to coexist with managed name resolution? If so, how does one ensure that one doesn't get confused about a particular name (use the zeroconf name or the managed/DNS one?) What if one service is temporarily down? There is some existing wording in the document that is probably too cryptic on this issue: equivalent to using the DNS protocols to query the same name. A host using DNS and zeroconf name resolution protocols at the same time MUST NOT allow zeroconf names to mask DNS names. and later configured network protocols. Locally allocated zeroconf network resources must not mask global assigned resources. > section 1.4 > it's reasonable for scalability to be a secondary goal for truly > ad hoc networks - there seems little point in trying to support > ad hoc networks that consist of thousands of hosts. OTOH, if > zeroconf technologies are to be used on existing networks, scaling > _on those networks_ becomes considerably more of a concern. Seems like a valid point. *If* there is no way to easily disable the use of zeroconf technologies on managed networks, they will have (possibly negative) problems when used on managed networks that don't make the same assumptions as a pure zeroconf-only network. > it's been argued on the mailing list that some zeroconf technologies > should be usable on managed networks in addition to ad hoc networks. > indeed, it's been forcefully argued that linklocal should be enabled > by default on all hosts so that it can be used to communicate with > appliances without having to configure such appliances. > if this is a goal, it needs to be explicit, and the scalability > concern needs to be reconsidered. > regardless, there needs to be a requirement that zeroconf technologies > not interefere with operation or security on managed networks. Again, I thought there was more along this lines in an earlier version of the document. > section 1.6 > it's not clear what it means for zeroconf protocols to "restore > the network to a consistent state", especially when all of the > relevant state that I can see is maintained in the hosts and > applications rather than in the network. zeroconf may be able > to resolve address conflicts, but it cannot transparently recover > applications from such conflicts. I wonder if you are asking for something that isn't doable. If two networks merge, and nodes find they are sharing addresses, there is a real problem that two nodes might now share an address. This isn't a zeroconf problem per se, but zeroconf is trying to say when those things happen it needs to try and fix them to make the better (as opposed to doing nothing with things staying broken forever). This can't always be doing in a way that is transparent to applications (e.g., if a node has to change addresses). Surely you agree with this. So I'm having trouble translating the above into a concrete suggestion for this document. In the absence of a specific suggestion, we probably need to move on. > there needs to be a requirement that zeroconf minimize impact on > applications. actually there's little mention of applications > in the document, even though the effect on some kinds of applications > is significant. this seems like a major omission. What does "minimize impact" mean? Totally unquantifiable, and as mentioned above, can be used to essentially say (e.g.) LL is too broken to use. > it's not clear that names, or name-to-address mappings, are properly > considered 'network' resources if they are similar to DNS names > or have the potential to overlap with the DNS name space - either as a > matter of on-the-wire protocol or via APIs that applications use to > look up such names. Is your issue with the wording calling them "resources"? Can you suggest alternative wording? > section 2.1 > again, the document talks about what "hosts" should or should not > assume regarding stability of "network resources" but does not mention > what "applications" may assume or whether zeroconf creates new burdens > for applications. > section 2.2 (middle of page 6) > the document talks about "increased robustness" of _zeroconf_ protocols > but says nothing about the effect on the robustness of applications > hosted on hosts that use zeroconf. see previous comments. > section 3.1 (3rd bullet) [nit?] > > "MUST allow configuration of zero or more gateways (for the internetwork > scenario)". perhaps this is trivially satisfied (because allowing > zero gateways suffices) and it can therefore be omitted. or perhaps it > needs rewording for clarity. Almost certainly a nit. > please remind me of how v4 linklocal facilities connection of gateways? there is a valid point buried here. The requirements document talks about multiple gateways, but doesn't have any requirements about addressing beyond link local. But if one only has link-local, then one doesn't need routers. I wonder if the real problem here is that parts of the document were written before it was settled that link-local meant "stays on the link" and doesn't go through a router. Earlier versions talked a about a single router with multiple subnets (and possibly a connection to the internet), but I think this wording is gone now. Note that there is also wording in the document that says: o A zeroconf name resolution protocol MUST support resolution of names on multiple IP subnets connected by a router. It is not quite clear what this means in light of link-local addresses are currently defined. (this also gets back to an earlier point about the different parts of zeroconf being coherent with each other). > (last bullet list of requirements on middle page 8) > it seems like nomadic hosts are likely to connect to multiple networks > in the course of a day. is such a host better off using the same > address each time it connects to a particular network, or better off > trying to claim/defend the same address on every network to which it > connects? would large numbers of nomadic hosts (as seems likely) > seriously affect the stability of linklocal addresses even though the > hosts try to maintain their addresses as they migrate? Not clear how one would even notice that one is on a "different" network as one moved around. So saying "try to use the same one again (but be prepared to use a different one if you can't)" seems about right. > also, given that apps on nomadic hosts might need to keep some connections > open as they move, has any thought been given to interaction between > zeroconf technologies and mobile IP? are there requirements along these > lines waiting to be discovered? One generally needs a global address to use MIP. When using zeroconf, I think one is not generally using global addresses, as having them implies some sort of configuration beyond zeroconf being possible. > section 3.2 > I keep being told that the name-to-address issue is out of scope for this > group. More specifically, discussing specific solutions is. > maybe dnsext should review this portion of the document? or maybe > it should be omitted? especially since mDNS/LLMNR still seems to be in > flux with fundamental problems still unresolved? > nit: s/quite likely to use a different IP/quite likely to use different IP/ > ^ > I realize this isn't the only group using the term, but the emphasis on > "host names" seems a bit archaic. these days users rarely care about > accessing "hosts", they care about accessing "services". (sometimes > the host *is* the desired service, but that's the exception rather than > the rule). of course, it's not the use of the term that's important > so much as the assumptions that go along with it. for instance, should > service lookups map to host names and host names to addresses, or should > service lookups map directly to addresses? host names still seem too useful to drop. How else to you ssh to another machine (something I still do, even at home). > nit: "for applications like web browsers...the use of names rather than > IP addresses is beneficial". only if the names are more stable > and more mnemonic than the addresses :) not that they're being > proposed by this WG but temporary names aren't very useful for > such purposes. I would say "may be beneficial" rather than "is". > (page 9, bullets) > if "host names" are or aren't DNS names then it would be good to say that > in the first bullet in the Terms section. that's the first thing a > reader would want to know. > there's no statement about the effect of the name resolution protocol > on APIs that are currently used to look up DNS names. it's an important > question because it will affect apps. there's a desire to have these > things "just work" with existing apps, but at the same time if the > results are inconsistent with DNS then it will cause problems. I think there is a findamental issue here. One of the questions that needs to be dealt with (if not here, at some point) is does the API change when looking up zeroconf names. There are important security questions lurking here, as you don't ever want an application to be fooled into thinking it is using the dns to look up "mybank.com" but instead connect to some rogue server that is spoofing that name through zeroconf technologies. The clearest way to do this is to have a differnet API for locating zeroconf names. But that obviously has ease-of-deployment issues. > there's also no statement about the consistency of results of the > lookups using name resolution protocol across different locations. > if the results are inconsistent at different places this will also > break apps that want to use these names to do referrals. Sounds a bit like you are arguing for a global name space, even if zeroconf is used. Not sure how to do this... > there needs to be a requirement that lookups of DNS names are consistent > with lookups using DNS. > "probing a desired host name...must not prevent the desired hostname > from being resolved". > I'm not sure what this means. Don't know either. > - "from being resolved...at a later time" ? > - s/must not/MUST NOT/ ? > again, it is not at all clear that host names are properly treated > as "network resources", i.e. resources that belong to the network. > traditionally DNS names are not related to network topology. > this might imply that the network and/or protocols for looking up > such names should be able to detect naming conflicts between DNS-style > names but NOT to adjucate between such conflicts - because the network > is not authoritative for any portion of DNS name space. (individual > hosts might have been assigned such authority - just as they might > be running DNS servers that are authoritative, but the "network" is > not authoritative) > "local" names (that don't look like FQDNs) might be a different matter. > (I realize that this document says that they aren't DNS names but > mDNS/LLMNR seems to act as if they are DNS names or at least the > spaces can overlap - then consistency becomes an issue) > "zeroconf name resolution protocol MUST support resolution of > names on multiple IP subnets connected by a router". > I'm not sure what this means - it seems like a network-centric > definition but the hosts/apps are what are implementing the protocol. > Do you mean that the protocol MUST enable resolution of names on > other IP subnets that those to which the host supporting the > querying application is attached? I was unclear about this wording too. > again, is there a potential conflict between the use of limited-scope > addresses in this name-to-address lookup service and having the lookup > service work across a larger area than such addresses? > "zeroconf name resolution protocols MUST allow timely re-use of hostnames" > again this seems misstated, at least for FQDNs - such names are not > delegated to the network or to zeroconf protocols to manage. is this just a wording issue? I think I know what is meant. If you stop using a name, someone else should be allowed to start using it for itself -- after some period of time. > section 3.2.2 > "host names ...are inherently locally scoped". not from the examples > envisioned in the current mDNS/LLMNR draft. > "a DNS server supporting dynamic updates can provide automatic configuration > of a DNS name space in a network". I'm not sure what this means. > Are you saying that such a server could (or perhaps should) be used instead > of the zeroconf name lookup service? Are you saying that this mechanism > should be used (when available) to ensure consistency between the zeroconf > service and DNS? > "The zeroconf namespace is orthogonal to the DNS class IN namespace" > seems irreconcilable with "It is RECOMMENDED that zeroconf host names > conform to the character set and formatting of DNS host names". > (and the latter seems to me to need strong justification) I don't see this as being an inherent conflict. > EITHER the two services share a common namespace (and need to produce > consistent results with one another) OR they need to be clearly > distinguished from one another - different syntax, different APIs, etc. > so that apps don't get confused and try to treat zeroconf host names > as if they had the same properties of DNS names. > several requirements seem to be omitted here. > "...MUST NOT allow zeroconf names to mask DNS names". this is not > a sufficient restriction. in general it is necessary to produce > consistent results when different hosts in different parts of the network > look up the same DNS-like name, even if those hosts have different > local scopes or if some of those hosts are using zeroconf and others > are using DNS. that's not to say that all RRs for all names need to > be visible to all hosts at all times - that's not even true for pure DNS - > but that (for reasons similar to those given in RFC 2826) the name lookup > service needs to provide a uniform view of DNS-style names from everywhere. > local (unqualified) names are a different matter - we do expect > their meanings to differ from one place to another. > --- > since I'm busy and I'm mostly concerned about names and addresses, I > didn't review the remainder of the document. > again, attention to important considerations that were omitted from the > requirements in the document are probably more important than > most of the tweaks suggested above. e.g. compatibility with existing apps, > effects of introduction of zeroconf on the operation of existing/managed > networks. > Keith Thomas From owner-zeroconf@merit.edu Wed Sep 11 16:05:25 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23205 for ; Wed, 11 Sep 2002 16:05:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B867D913B5; Wed, 11 Sep 2002 16:04:06 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 921F6913B4; Wed, 11 Sep 2002 16:04:06 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8DD10913B2 for ; Wed, 11 Sep 2002 16:02:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 64E285DDA4; Wed, 11 Sep 2002 16:02:36 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by segue.merit.edu (Postfix) with ESMTP id ECC3E5DD8C for ; Wed, 11 Sep 2002 16:02:35 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8BK2ZEG098880 for ; Wed, 11 Sep 2002 16:02:35 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8BK2YRA160288 for ; Wed, 11 Sep 2002 14:02:34 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g8BJwbv30462 for ; Wed, 11 Sep 2002 15:58:37 -0400 Message-Id: <200209111958.g8BJwbv30462@rotala.raleigh.ibm.com> To: zeroconf@merit.edu Subject: AD comments on draft-ietf-zeroconf-reqts-11.txt Date: Wed, 11 Sep 2002 15:58:37 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk I've re-reviewed this document, as the WG has indicated it wants the IESG to approve publication. Some of these issues are farily minor, but I think another rev is needed (hopefully quickly!), before I can put it before the IESG for consideration. > Zeroconf IP Host Requirements A better title would be nice. One that communicates to the (non-familiar) reader what the document is about. How about something like: Requirements for Automatic Configuration of IP Hosts > Some questions for further discussion: > > o Anything else to add here? > > o What might be appropriate MUST/SHOULD requirements? > > o Do we wish to restrict the operation of specific zeroconf > protocols in particular cases (e.g. the mDNS case, were it is > disabled if and DNS configuration information is present) > > o Do we wish to imply that zeroconf protocols may only be used to > configure IP addresses in specific restricted ranges? (e.g. > private addresses, 169.254/16) > > o What about "configured protocols" that may delegate an address or > name space to a zeroconf protocol for allocation? Hmm. Is this section finished? > 1.5 Routable Protocol Requirement > > Zeroconf protocols are not inherently limited to a single IP subnet. > If a protocol is intended to span multiple IP subnets it MUST NOT use > broadcasts or link-local addressing. > > Requirement: > > o Protocols intended to span multiple IP subnets MUST NOT use > broadcasts or link-local addressing. but doesn't the current MDNS document actually restrict usage to link-local? > 3.1.1 IPv6 Considerations > > IPv6 allows a host to select an appropriate IP address and netmask > using Stateless Autoconfiguration[RFC2462]. Thus a zeroconf IP > interface configuration solution already exists for hosts using IPv6. not sure I agree. for a single link, yes. But if there are multiple links/subnets, someone has to configure the routers with prefixes. This isn't zeroconf-ish. If the above wording is intended to be limited to link-local, I agree (but then the words should be more narrowly scoped). > o A zeroconf name resolution protocol MUST support resolution of > names that could not previously be resolved. In particular, > probing a desired host name (which does not exist) when joining a > network must not prevent the desired hostname from being resolved. Don't understand what that means. > o A zeroconf name resolution protocol MUST support resolution of > names on multiple IP subnets connected by a router. Not supported today by mdns. And doesn't this imply something about the link-local addresses not having sufficient utility? I guess I'm partly confused about whether zeroconf needs to work beyond link-local or not. > o Hosts using zeroconf name resolution protocols MUST ensure that > the use of a desired name will not cause a conflict when moving to > a new network or powering up. wording problem? one can't ensure (in advance) that a name won't cause a conflict on the next place you move to. Are you trying to say that you can't claim a name before verifying that the name is not in use? Can this be folded into the previous requirement: > o A zeroconf name resolution protocol MUST support mechanisms to > probe whether a host name is currently in use. ==== > o Host names SHOULD be chosen in a way that minimises the > probability that two hosts will use the same resource. Note that > this is out of scope of the name resolution protocol itself. Is wording right above? does "same resource" really mean "same host name"? > Using a zeroconf name resolution protocol to query a DNS name is NOT > equivalent to using the DNS protocols to query the same name. A host > using DNS and zeroconf name resolution protocols at the same time > MUST NOT allow zeroconf names to mask DNS names. more words? Seems like this is a somewhat cryptic way of saying that DNS and zeroconf need to coexist in a coherent fashion. Is this wording also trying to sidestep the detailed discussion about what the coexistance should look like? Seems like this is an important part of the problem to understand. > source-specific multicast addresses for IPv6, in [SS6]. SS6 is not in the references... Also, the IPv6 mcast references may need updating anyway to take care of some relatively new documents: RFC 3306/3307. > 3.3.2 Address Allocation > > IP multicast address allocation (local, link-local and site-local > scopes only) requires an application to be able to request the use of > a suitable multicast address. Coordination among applications must > occur to avoid conflicting allocations of the same address. This > coordination must span the entire scope respective to the address. > When an allocated address is no longer required, that address MUST > become available for use again. > > o MUST select a multicast address. > Missing "requirements:" before first bullet? (there is a transition missing) > 3.3.4 IPv6 Considerations > > To date, no range has been reserved for source-specific addresses in > IPv6. See [SS6]. Hence, until such a range is reserved, dynamic > allocation of source-specific addresses applies only to IPv4. Is this true in light of RFC 3306? nits: It would be good to separate references into normative and non-normative sections. > are updated to reflect these changes, and is responsible for ensuring no comma > 2, and will be applied to derive requirements for each zeroconf no comma Thomas From owner-zeroconf@merit.edu Wed Sep 11 16:24:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23488 for ; Wed, 11 Sep 2002 16:24:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ABC5B913C4; Wed, 11 Sep 2002 16:25:12 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6AC50913C8; Wed, 11 Sep 2002 16:25:12 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 341CC913C4 for ; Wed, 11 Sep 2002 16:25:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 211A25DDE1; Wed, 11 Sep 2002 16:25:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 892DD5DD8C for ; Wed, 11 Sep 2002 16:25:07 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06926; Wed, 11 Sep 2002 14:25:05 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g8BKP3l25635; Wed, 11 Sep 2002 22:25:03 +0200 (MEST) Date: Wed, 11 Sep 2002 22:24:19 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: AD comments on draft-ietf-zeroconf-reqts-11.txt In-Reply-To: <200209111958.g8BJwbv30462@rotala.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Wed, 11 Sep 2002, Thomas Narten wrote: > > Some questions for further discussion: > > > > o Anything else to add here? > > > > o What might be appropriate MUST/SHOULD requirements? > > > > o Do we wish to restrict the operation of specific zeroconf > > protocols in particular cases (e.g. the mDNS case, were it is > > disabled if and DNS configuration information is present) > > > > o Do we wish to imply that zeroconf protocols may only be used to > > configure IP addresses in specific restricted ranges? (e.g. > > private addresses, 169.254/16) > > > > o What about "configured protocols" that may delegate an address or > > name space to a zeroconf protocol for allocation? > > Hmm. Is this section finished? This sentence was not supposed to be in the released draft. Agh! > > > 1.5 Routable Protocol Requirement > > > > Zeroconf protocols are not inherently limited to a single IP subnet. > > If a protocol is intended to span multiple IP subnets it MUST NOT use > > broadcasts or link-local addressing. > > > > Requirement: > > > > o Protocols intended to span multiple IP subnets MUST NOT use > > broadcasts or link-local addressing. > > but doesn't the current MDNS document actually restrict usage to > link-local? The current mdns doc is not "intended to span multiple IP subnets." SLP does span multiple IP subnets and it does not use broadcast or link-local addressing (though it can be configured to use broadcast). > > 3.1.1 IPv6 Considerations > > > > IPv6 allows a host to select an appropriate IP address and netmask > > using Stateless Autoconfiguration[RFC2462]. Thus a zeroconf IP > > interface configuration solution already exists for hosts using IPv6. > > not sure I agree. for a single link, yes. But if there are multiple > links/subnets, someone has to configure the routers with > prefixes. This isn't zeroconf-ish. If the above wording is intended to > be limited to link-local, I agree (but then the words should be more > narrowly scoped). We don't discuss configuring routers in this document. > > o A zeroconf name resolution protocol MUST support resolution of > > names that could not previously be resolved. In particular, > > probing a desired host name (which does not exist) when joining a > > network must not prevent the desired hostname from being resolved. > > Don't understand what that means. If at first you don't succeed, try and try again. The first failure mustn't prevent you from subsequent success. > > o A zeroconf name resolution protocol MUST support resolution of > > names on multiple IP subnets connected by a router. > > Not supported today by mdns. And doesn't this imply something about > the link-local addresses not having sufficient utility? I think this is wrong. I regret I didn't catch this before forwarding the doc to the IESG. > I guess I'm > partly confused about whether zeroconf needs to work beyond > link-local or not. Link local operation is needed. It is not meant to be a limit. SLP for example is not limited to link-local. llmnr in the future might not be limited to link-local. > > o Hosts using zeroconf name resolution protocols MUST ensure that > > the use of a desired name will not cause a conflict when moving to > > a new network or powering up. > > wording problem? one can't ensure (in advance) that a name won't cause > a conflict on the next place you move to. Are you trying to say that > you can't claim a name before verifying that the name is not in use? > Can this be folded into the previous requirement: > > > o A zeroconf name resolution protocol MUST support mechanisms to > > probe whether a host name is currently in use. The requirement is too strictly stated. What it means is that if it causes a conflict, the conflict will be resolved in due time. > ==== > > > o Host names SHOULD be chosen in a way that minimises the > > probability that two hosts will use the same resource. Note that > > this is out of scope of the name resolution protocol itself. > > Is wording right above? does "same resource" really mean "same host > name"? It should be 'the same name,' since we are discussing name resolution protocol requirements. Erik From owner-zeroconf@merit.edu Wed Sep 11 16:34:15 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23854 for ; Wed, 11 Sep 2002 16:34:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 196AE913BF; Wed, 11 Sep 2002 16:35:05 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1045913B4; Wed, 11 Sep 2002 16:35:03 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4CB80913BF for ; Wed, 11 Sep 2002 16:34:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C5AD5DDD1; Wed, 11 Sep 2002 16:34:39 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id A91475DD8C for ; Wed, 11 Sep 2002 16:34:38 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8BKW2013919; Wed, 11 Sep 2002 16:32:02 -0400 (EDT) Message-Id: <200209112032.g8BKW2013919@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Thomas Narten Cc: Keith Moore , Zeroconf , iesg@ietf.org Subject: Re: comments on draft-ietf-zeroconf-reqts-11.txt In-reply-to: (Your message of "Wed, 11 Sep 2002 15:06:52 EDT.") <200209111906.g8BJ6rc29976@rotala.raleigh.ibm.com> Date: Wed, 11 Sep 2002 16:32:02 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > Keith, > > Having just reread this document, here are some thoughts on your > comments. > > > these comments are intended as input into IESG decision-making > > about whether to publish draft-ietf-zeroconf-reqts-11.txt as > > Informational, and also to the zeroconf WG as input to a possible > > future revision of this document. > > It would be helpful if more of your comments were along the lines of > change the following text to . For some of your > comments, its hard to say what sort of wording change you are asking > for or if you are just saying the idea is so broken there is no way > forward. if I see a way to solve a problem with a simple textual change, I usually suggest it. sometimes I cannot come up with a simple textual change off the top of my head, and it takes so long to do these reviews that I'd rather forward the review sooner without suggested text than delay it until I think I have good wording for everything. in some cases it seems counterproductive or at least premature to argue about the actual text when the problem seems to me to be the assumptions underlying the text - and often these assumptions are not made explicit. sometimes I simply can't fathom what is intended. > > I see this document as somewhat more important than the typical WG > > requirements document since zeroconf technologies have the potential > > to have wide-ranging effects on internet applications and networks, > > and presumably the linklocal document will be evaluated for 'known > > technical omissions' with respect to these requirements. so if these > > requirements are incomplete or poorly-founded, they don't serve as a > > good basis for judging linklocal. > > The linklocal document is basically done and even implemented. those two attributes are orthogonal - "implemented" certainly doesn't imply "done". I *hope* the problems with the previous versions of linklocal have been addressed. I'm still trying to come up with a useful review of LLMNR, so I haven't had time to get back to LL yet. > Those that have implemented seem to think it is useful. there's little doubt that it's useful. that doesn't mean that meets the 2026 requirements for PS status. a related question is - are the requirements reasonable and reasonably complete? > As is the case with > many requirements-type documents (unfortunately), the wish list isn't > perfect and one can imagine additional desirable-to-have things that, > if included, would result in change in a subsequent protocol > document. At this point in time, I think issues you might have with > the requirements relating to the linklocal document should also come > with a clear indication of what changes you think are necessary in the > LL document. my review of the current LL document will follow, and I'll do my best to get it in before the Last Call deadline. but if the LL document is to be judged according to the requirements listed in the requirements document, then it does seem worthwhile to look over those requirements also. > > it does seem odd that the requirements document hasn't been formally > > reviewed by a wider community before now, and even now is not subject > > to IETF-wide last call. even if they're just informational from the > > standpoint of standardization they're being used to justify features > > of standards-track protocols - so we should probably give them more > > scrutiny than typical 'informational' documents. > > Most requirements-type documents are not IETF-wide last called. true, but IMHO it would be a good idea of requirements documents were subject to wider review - particularly for technologies such as this one that have the potential to have a wide impact, early review of the requirements/goals document would provide a chance for early feedback from affected interests. so by "odd" I didn't mean statistically odd, I meant that by not getting wide review of such things we're missing out on valuable opportunities to fix things well before it's widely assumed that those things are stable. > > > then again, I'd vastly prefer that we call these things 'design goals'. > > somehow the word 'requirements' keeps sticking in people's minds even > > though these documents are rarely either prescient or robust enough > > to actually be considered 'requirements'. > > I am sympathetic to this, as they are recommendations in the end after > all. > > > ---------------------------------------------------------------------- > > > executive summary: > > > - the requirements seem incomplete. important considerations - such as > > the impact of zeroconf technologies on existing applications and > > existing networks - are omitted. > > The problem I see with this is that I suspect you are asking for > something like: "zeroconf technologies MUST NOT have impact on > existing applications", and your view appears to be that use of > link-local addresses by applications will break them. Thus, the entire > LL document should not go forward. > > Is this an accurate reflection of your position? If not, what impacts > are you concerned about and what would the corresponding general > requirements be (and can those requirements in fact even be met)? My position is that zeroconf technologies SHOULD minimize the impact on existing applications, SHOULD minimize the impact on operation of managed networks, MUST minimize the degree to which they impair the ability of the network to support a wide range of applications. That is, we can tolerate some small degree of disruption to existing applications and networks provided there is a reasonable workaround which allows the functionality to be restored - but impairing the ability of the network to support a wide range of applications (including distributed and p2p apps) is not an acceptable tradeoff. Off the top of my head, impacts that I'm concerned about include: - effect on existing applications that assume or require stable addresses, including their use in referrals, - effect on existing applications that assume or require addresses that are unique within the application, - effect on existing applications that assume or require addresses that are routable throughout all present and future hosts supporting a component of the application, including the use of such addresses in referrals - effect on existing applications that assume or require the level of consistency and location-independence of name lookup service that is provided by the design of DNS - effect on existing applications that assume or require unique names - effect of the introduction of zeroconf-supporting hosts on the operation of existing managed networks, including security and user support (e.g. problem diagnosis) issues > > > - a few of the requirements seem dubious > > Specific text please... > > > details: > > > section 1.3 > > > the document doesn't say that there are absolutely no dependencies > > between zeroconf technologies, so perhaps this is just a nit. > > Are you asking for specific text be added? If so, please indicate > what. I was asking a question about the assumptions being made, and wondering whether there was not an actual requirement that was not stated. I don't know what text to suggest here because I haven't been able to come up with a solution that doesn't cause problems. There appear to be problems with assuming that unicast LL scope and multicast LL scope are the same, especially in a bridged environment. There are problems if the unicast LL scope is a proper subset of the multicast LL scope (LLMNR will advertise addresses that are not valid); there are problems if the unicast LL scope is a proper subset of the multicast scope (LLMNR will fail to make hosts visible through their names even though they are reachable), and there are problems in general with expecting addresses obtained via LLMNR to be used only from the host making the query and only within a short time after making the query (this breaks apps that do address referrals). So I didn't suggest text because frankly I don't see how to solve the problem, and in order to even suggest a compromise I'd need to know more about other people's assumptions. > > - the zeroconf technologies coexist with similar services that > > are used in managed networks - either by providing consistent > > (or non-conflicting) results or by arranging that the zeroconf > > service is not used when the managed service exists. > > (even then you still have consistency issues, since the ability > > to access the 'managed' services may differ from one node to > > another). > > > > and *those* translate into more specific requirements which I can't > > enumerate off the top of my head. > > My recollection is that earlier versions of the draft included more > text about coexistance between managed and unmanaged resouces. I do > wonder if more text should be added back in. But this is a fairly > hard/subtle issue. > > For example, do we really understand how we want zeroconf name > resolution to coexist with managed name resolution? It's fairly clear to me from looking at various versions of the mDNS document that we don't understand this yet - but it seems important to get it right, and one useful approach might be to take a step back and look at how we'd state this from a goals/requirements perspective. > > section 1.6 > > > it's not clear what it means for zeroconf protocols to "restore > > the network to a consistent state", especially when all of the > > relevant state that I can see is maintained in the hosts and > > applications rather than in the network. zeroconf may be able > > to resolve address conflicts, but it cannot transparently recover > > applications from such conflicts. > > I wonder if you are asking for something that isn't doable. If two > networks merge, and nodes find they are sharing addresses, there is a > real problem that two nodes might now share an address. This isn't a > zeroconf problem per se, but zeroconf is trying to say when those > things happen it needs to try and fix them to make the better (as > opposed to doing nothing with things staying broken forever). This > can't always be doing in a way that is transparent to applications > (e.g., if a node has to change addresses). Surely you agree with > this. So I'm having trouble translating the above into a concrete > suggestion for this document. In the absence of a specific suggestion, > we probably need to move on. well, what I'm asking for here is clarification. I don't think "restore the network to a consistent state" is sufficiently well defined to understand what it means. I can't suggest text here because I simply don't know what the authors have in mind. I certainly don't expect v4 LL to ensure uniqueness or stability of addresses chosen at random from ~2**16 possibilities. Nor do I expect v4 LL to solve the problems that will result from apps that try to treat v4 LL addresses as if they were routable addresses. Clearly they will work with some apps better than others, but we want to take advantage of those that do work with LL while minimizing harm to the others. What I do think is reasonable to expect is that LL will try not to get in the way of things that already work -- so e.g. hosts and apps should not require LL addresses or assume that LL addresses will suffice to reach all hosts of interest, they shouldn't use LL addresses if routable addresses are available, hosts and apps should be discouraged (if possible) from using LL addresses in referrals and advertising them in DNS, etc. > > there needs to be a requirement that zeroconf minimize impact on > > applications. actually there's little mention of applications > > in the document, even though the effect on some kinds of applications > > is significant. this seems like a major omission. > > What does "minimize impact" mean? Totally unquantifiable, and as > mentioned above, can be used to essentially say (e.g.) LL is too > broken to use. yes, it's unquantifiable, but so is most of the rest of this document. one interpretation of "minimize impact" is that if there are reasonable measures which zeroconf could take which would avoid adverse impact on existing applications while still providing most of the potential gain from zeroconf, such measures deserve serious consideration. another would be to "maximize flexibility" of the network to support a wide range of applications and application behaviors. again, this means that we try to find a way to get the extra flexibility that zeroconf would add while minimizing the amount of flexibility that exists in the current network that would be removed by adding zeroconf. but I don't think there's anyway to assign a value to each kind of flexibility to determine the optimum design point - it has to be a judgement call. > > it's not clear that names, or name-to-address mappings, are properly > > considered 'network' resources if they are similar to DNS names > > or have the potential to overlap with the DNS name space - either as a > > matter of on-the-wire protocol or via APIs that applications use to > > look up such names. > > Is your issue with the wording calling them "resources"? Can you > suggest alternative wording? my issue is with the adjective "network". to me DNS names are not a property of the network - certainly not of the local network - since they are intended to be location-independent and they exist (and have uses) independently of the network. > > section 3.1 (3rd bullet) [nit?] > > > > "MUST allow configuration of zero or more gateways (for the internetwork > > scenario)". perhaps this is trivially satisfied (because allowing > > zero gateways suffices) and it can therefore be omitted. or perhaps it > > needs rewording for clarity. > > Almost certainly a nit. perhaps, but it seems like some clarification is in order. > > section 3.2 > > host names still seem too useful to drop. How else to you ssh to > another machine (something I still do, even at home). as do I. the point is not to drop DNS-like names, or even the use of DNS-like names to name hosts - the point is that in many (perhaps most) cases these days, what is being named is not a "host" in the traditional sense of a box with network interfaces, local memory and disk, logins, etc. Often what is being named is a "resource" (like a POP server, or a collection of web documents) which might correspond to one or more hosts (which might or might not share a set of IP addresses). Due to multiple hosts being used to implement a single "resource", along with "virtual" hosts that give the appearance of multiple "hosts" (really, multiple addresses with separate port # spaces) on a single box, the mapping between names and hosts has become fairly arbitrary. But if we are thinking "host" names when apps are thinking "resource" names, we may end up with a zeroconf solution that doesn't support the needs of those apps. Most people's computers are for practical purposes anonymous - they don't need "host" names because people rarely refer to those hosts from elsewhere in the network. nobody expects to log into those hosts because they're windows boxes or mac boxes for which the concept of "remote access" is fairly foreign. (IOW, we've regressed to the days before ARPAnet :) I don't know whether zeroconf will change this, but I do expect that people might be more interested in making "resources" accessible over ad hoc networks (e.g. game servers, file sharing servers, local IM servers, conferencing servers) than in making their "hosts" accessible over ad hoc networks (in the sense of logging into the hosts, or making all of the host's files accessible) and a single host might want to make multiple kinds of resources accessible under multiple names. offhand I don't see anything in LL or MMLNR that precludes this, but the assumption of "one host - one name" seems to be fairly prevalent in all these documents, and it seems anachronistic to me. > > (page 9, bullets) > > if "host names" are or aren't DNS names then it would be good to say that > > in the first bullet in the Terms section. that's the first thing a > > reader would want to know. > > > there's no statement about the effect of the name resolution protocol > > on APIs that are currently used to look up DNS names. it's an important > > question because it will affect apps. there's a desire to have these > > things "just work" with existing apps, but at the same time if the > > results are inconsistent with DNS then it will cause problems. > > I think there is a findamental issue here. One of the questions that > needs to be dealt with (if not here, at some point) is does the API > change when looking up zeroconf names. There are important security > questions lurking here, as you don't ever want an application to be > fooled into thinking it is using the dns to look up "mybank.com" but > instead connect to some rogue server that is spoofing that name > through zeroconf technologies. The clearest way to do this is to have > a differnet API for locating zeroconf names. But that obviously has > ease-of-deployment issues. right, and I'd like to see this addressed explicitly *somewhere*. at least a mention in the requirements doc seems appropriate. > > there's also no statement about the consistency of results of the > > lookups using name resolution protocol across different locations. > > if the results are inconsistent at different places this will also > > break apps that want to use these names to do referrals. > > Sounds a bit like you are arguing for a global name space, even if > zeroconf is used. Not sure how to do this... I think we will need LLMNR to support both global names (including consistency with DNS) and local names (which don't have to be consistent with anything) and we'll need to treat the two cases separately from a requirements standpoint. > > "zeroconf name resolution protocols MUST allow timely re-use of hostnames" > > > again this seems misstated, at least for FQDNs - such names are not > > delegated to the network or to zeroconf protocols to manage. > > is this just a wording issue? I think I know what is meant. If you > stop using a name, someone else should be allowed to start using it > for itself -- after some period of time. What you stated sounds reasonable - I'm not sure whether this is what was intended. > > > section 3.2.2 > > > "host names ...are inherently locally scoped". not from the examples > > envisioned in the current mDNS/LLMNR draft. > > > "a DNS server supporting dynamic updates can provide automatic configuration > > of a DNS name space in a network". I'm not sure what this means. > > Are you saying that such a server could (or perhaps should) be used instead > > of the zeroconf name lookup service? Are you saying that this mechanism > > should be used (when available) to ensure consistency between the zeroconf > > service and DNS? > > > "The zeroconf namespace is orthogonal to the DNS class IN namespace" > > seems irreconcilable with "It is RECOMMENDED that zeroconf host names > > conform to the character set and formatting of DNS host names". > > (and the latter seems to me to need strong justification) > > I don't see this as being an inherent conflict. it boils down to the degree to which "formatting" means "look like DNS host names". I would argue that existing apps expect a name that contains one or more dots to be fully-qualified, globally-scoped, etc. (some existing apps expect that a name that doesn't contain a dot can be transformed into a fully-qualified, globally-scoped name by appending some host-specific suffix, but we have to accept that we can't fix those). Keith From owner-zeroconf@merit.edu Wed Sep 11 16:53:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24371 for ; Wed, 11 Sep 2002 16:53:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 599E791342; Wed, 11 Sep 2002 16:55:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E91091344; Wed, 11 Sep 2002 16:55:09 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B28BF91342 for ; Wed, 11 Sep 2002 16:55:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8FF565DD8C; Wed, 11 Sep 2002 16:55:06 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by segue.merit.edu (Postfix) with ESMTP id C00C65DDDB for ; Wed, 11 Sep 2002 16:55:05 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8BKt4g2047224; Wed, 11 Sep 2002 16:55:04 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8BKt4RA119014; Wed, 11 Sep 2002 14:55:04 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g8BKp7w31023; Wed, 11 Sep 2002 16:51:07 -0400 Message-Id: <200209112051.g8BKp7w31023@rotala.raleigh.ibm.com> To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: AD comments on draft-ietf-zeroconf-reqts-11.txt In-Reply-To: Message from "Wed, 11 Sep 2002 22:24:19 +0200." Date: Wed, 11 Sep 2002 16:51:06 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Erik Guttman writes: > This sentence was not supposed to be in the released draft. Agh! OK > > > > > > 1.5 Routable Protocol Requirement > > > > > > Zeroconf protocols are not inherently limited to a single IP subnet. > > > If a protocol is intended to span multiple IP subnets it MUST NOT use > > > broadcasts or link-local addressing. > > > > > > Requirement: > > > > > > o Protocols intended to span multiple IP subnets MUST NOT use > > > broadcasts or link-local addressing. > > > > but doesn't the current MDNS document actually restrict usage to > > link-local? > The current mdns doc is not "intended to span multiple IP subnets." > SLP does span multiple IP subnets and it does not use broadcast > or link-local addressing (though it can be configured to use > broadcast). OK. > > > 3.1.1 IPv6 Considerations > > > > > > IPv6 allows a host to select an appropriate IP address and netmask > > > using Stateless Autoconfiguration[RFC2462]. Thus a zeroconf IP > > > interface configuration solution already exists for hosts using IPv6. > > > > not sure I agree. for a single link, yes. But if there are multiple > > links/subnets, someone has to configure the routers with > > prefixes. This isn't zeroconf-ish. If the above wording is intended to > > be limited to link-local, I agree (but then the words should be more > > narrowly scoped). > We don't discuss configuring routers in this document. yes, but if the routers must be configured in order for stateless addrconf to work (which it does for anything other than LL) then saying IPv6 has a zeroconf address configuration solution seems a bit misleading. More precise wording would be something like: IPv6 provides a mechanism that allows a host to generate a link-local IP address Autoconfiguration[RFC2462]. Thus a zeroconf IP interface configuration solution for generating link-local addresses already exists for hosts using IPv6. The point is that obtaining subnet masks and other scopes of addresses is not exactly a zeroconf operation in practice. > > > o A zeroconf name resolution protocol MUST support resolution of > > > names that could not previously be resolved. In particular, > > > probing a desired host name (which does not exist) when joining a > > > network must not prevent the desired hostname from being resolved. > > > > Don't understand what that means. > If at first you don't succeed, try and try again. The first failure > mustn't prevent you from subsequent success. Whoa. I don't get that at all from the words in the draft. And I'm confused about probing failing vs. resolving the name. I'd suggest a rewrite. I'm still confused about what the problem is the MUST is trying to fix (so I can't suggest words, yet). > > > o A zeroconf name resolution protocol MUST support resolution of > > > names on multiple IP subnets connected by a router. > > > > Not supported today by mdns. And doesn't this imply something about > > the link-local addresses not having sufficient utility? > I think this is wrong. I regret I didn't catch this before forwarding > the doc to the IESG. Are you saying just remove the text? > > I guess I'm partly confused about whether zeroconf needs to work > > beyond link-local or not. > Link local operation is needed. It is not meant to be a limit. > SLP for example is not limited to link-local. llmnr in the future > might not be limited to link-local. OK. I think I understand this point now. > > > > o Hosts using zeroconf name resolution protocols MUST ensure that > > > the use of a desired name will not cause a conflict when moving to > > > a new network or powering up. > > > > wording problem? one can't ensure (in advance) that a name won't cause > > a conflict on the next place you move to. Are you trying to say that > > you can't claim a name before verifying that the name is not in use? > > Can this be folded into the previous requirement: > > > > > o A zeroconf name resolution protocol MUST support mechanisms to > > > probe whether a host name is currently in use. > The requirement is too strictly stated. What it means is that > if it causes a conflict, the conflict will be resolved in due time. Ok. We need proposed text then. > > ==== > > > > > o Host names SHOULD be chosen in a way that minimises the > > > probability that two hosts will use the same resource. Note that > > > this is out of scope of the name resolution protocol itself. > > > > Is wording right above? does "same resource" really mean "same host > > name"? > It should be 'the same name,' since we are discussing name > resolution protocol requirements. OK, and thanks for the speedy response! Thomas From owner-zeroconf@merit.edu Wed Sep 11 18:35:43 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26879 for ; Wed, 11 Sep 2002 18:35:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B886A913D0; Wed, 11 Sep 2002 18:34:40 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79921913D3; Wed, 11 Sep 2002 18:34:40 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F1B4D913D0 for ; Wed, 11 Sep 2002 18:32:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D82785DD92; Wed, 11 Sep 2002 18:32:45 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id A1FC25DD8C for ; Wed, 11 Sep 2002 18:32:45 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8BMWh014587; Wed, 11 Sep 2002 18:32:43 -0400 (EDT) Message-Id: <200209112232.g8BMWh014587@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Guttman Cc: Thomas Narten , zeroconf@merit.edu Subject: Re: AD comments on draft-ietf-zeroconf-reqts-11.txt In-reply-to: (Your message of "Wed, 11 Sep 2002 22:24:19 +0200.") Date: Wed, 11 Sep 2002 18:32:43 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > > o A zeroconf name resolution protocol MUST support resolution of > > > names that could not previously be resolved. In particular, > > > probing a desired host name (which does not exist) when joining a > > > network must not prevent the desired hostname from being resolved. > > > > Don't understand what that means. > > If at first you don't succeed, try and try again. The first failure > mustn't prevent you from subsequent success. It sounds like what you are saying is that hosts/resources/services can appear at any time, and their names should be usable soon after they appear. This would imply for instance not caching the results of failed queries. > > > o Hosts using zeroconf name resolution protocols MUST ensure that > > > the use of a desired name will not cause a conflict when moving to > > > a new network or powering up. > > > > wording problem? one can't ensure (in advance) that a name won't cause > > a conflict on the next place you move to. Are you trying to say that > > you can't claim a name before verifying that the name is not in use? > > Can this be folded into the previous requirement: > > > > > o A zeroconf name resolution protocol MUST support mechanisms to > > > probe whether a host name is currently in use. > > The requirement is too strictly stated. What it means is that > if it causes a conflict, the conflict will be resolved in due time. actually it is entirely possible to ensure (as a matter of protocol compliance) that LLMNR won't cause a naming conflict for DNS-style names, at least to approximately the same extent that DNS ensures this. it can be done simply by forbidding a host from answering any LLMNR queries from any zone for which that host has not been delegated the authority to maintain that zone by the administrator of the DNS parent zone. in other words, the host has to have been delegated its own zone; then it can modify the zone and act as a server for that zone. that won't prevent two hosts from answering to the same DNS name any more than arp prevents two hosts from answering to the same IP address, but it would mean that a conflict is a violation of the protocol. OTOH, the idea that 'the network' can 'resolve' a conflict about resources that don't belong to 'the network' is something that I find totally infeasible. Keith From owner-zeroconf@merit.edu Wed Sep 11 20:05:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29045 for ; Wed, 11 Sep 2002 20:05:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 34EC3913D5; Wed, 11 Sep 2002 20:06:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC0A9913D7; Wed, 11 Sep 2002 20:06:40 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 397AB913D5 for ; Wed, 11 Sep 2002 20:06:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 288415DE16; Wed, 11 Sep 2002 20:06:37 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id C8EF15DDF6 for ; Wed, 11 Sep 2002 20:06:36 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id RAA19921; Wed, 11 Sep 2002 17:06:36 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id RAA18789; Wed, 11 Sep 2002 17:06:31 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g8C06Q7C025318; Thu, 12 Sep 2002 10:06:26 +1000 (EST) Message-ID: <3D7FDA82.8060700@motorola.com> Date: Thu, 12 Sep 2002 10:06:26 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: AD comments on draft-ietf-zeroconf-reqts-11.txt References: <200209111958.g8BJwbv30462@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thomas Narten wrote: > I've re-reviewed this document, as the WG has indicated it wants the > IESG to approve publication. Some of these issues are farily minor, > but I think another rev is needed (hopefully quickly!), before I can > put it before the IESG for consideration. I can do that pretty quickly, hopefully today. > Requirements for Automatic Configuration of IP Hosts. OK by me. ACTION: change doc name to the above. >> Some questions for further discussion: [ ... ] > Hmm. Is this section finished? > Mea culpa -- I removed other similar sections, but missed this one. ACTION: remove this section. >>1.5 Routable Protocol Requirement >> >> Zeroconf protocols are not inherently limited to a single IP subnet. >> If a protocol is intended to span multiple IP subnets it MUST NOT use >> broadcasts or link-local addressing. >> >> Requirement: >> >> o Protocols intended to span multiple IP subnets MUST NOT use >> broadcasts or link-local addressing. > > but doesn't the current MDNS document actually restrict usage to > link-local? > Yes, for now. Also this document isn't the mDNS document. The zeroconf charter currently says one router. I think it would be short-sighted if we did not at least consider the possibilty of zeroconf name resolution protocols that would operate in a small routed network. ACTION: no change. >>3.1.1 IPv6 Considerations >> >> IPv6 allows a host to select an appropriate IP address and netmask >> using Stateless Autoconfiguration[RFC2462]. Thus a zeroconf IP >> interface configuration solution already exists for hosts using IPv6. > > > not sure I agree. for a single link, yes. But if there are multiple > links/subnets, someone has to configure the routers with > prefixes. This isn't zeroconf-ish. If the above wording is intended to > be limited to link-local, I agree (but then the words should be more > narrowly scoped). > I see your point. ACTION: add the word "link-local" as in: IPv6 allows a host to select an appropriate link-local IP address and netmask using Stateless Autoconfiguration[RFC2462]. >> o A zeroconf name resolution protocol MUST support resolution of >> names that could not previously be resolved. In particular, >> probing a desired host name (which does not exist) when joining a >> network must not prevent the desired hostname from being resolved. > > > Don't understand what that means. > I'll try to clarify the text. The idea is supposed to be that conflict detection probing shouldn't be cached, resulting in the name being un-resolvable for a while. >> o A zeroconf name resolution protocol MUST support resolution of >> names on multiple IP subnets connected by a router. > > Not supported today by mdns. And doesn't this imply something about > the link-local addresses not having sufficient utility? I guess I'm > partly confused about whether zeroconf needs to work beyond > link-local or not. > Not supported today, but mentioned as a possibility in the draft. I don't see why zeroconf name can't resolve to something that isn't a link-local address (e.g. RFC1918, global IPv4 at the IETF, etc). Again, I think it would be short-sighted if we did not at least consider the possibilty of zeroconf name resolution protocols that would operate in a small routed network. ACTION: change the MUST to a SHOULD >> o Hosts using zeroconf name resolution protocols MUST ensure that >> the use of a desired name will not cause a conflict when moving to >> a new network or powering up. > > > wording problem? one can't ensure (in advance) that a name won't cause > a conflict on the next place you move to. Are you trying to say that > you can't claim a name before verifying that the name is not in use? > Can this be folded into the previous requirement: > ACTION: wording change: o A host moving to a new network or powering up MUST ensure that all names it will respond to do not conflict with names already in use. >> o A zeroconf name resolution protocol MUST support mechanisms to >> probe whether a host name is currently in use. > > > ==== > >> o Host names SHOULD be chosen in a way that minimises the >> probability that two hosts will use the same resource. Note that >> this is out of scope of the name resolution protocol itself. > > Is wording right above? does "same resource" really mean "same host > name"? > Yes. ACTION: wording change: .. that two hosts will use the same host name. >> Using a zeroconf name resolution protocol to query a DNS name is NOT >> equivalent to using the DNS protocols to query the same name. A host >> using DNS and zeroconf name resolution protocols at the same time >> MUST NOT allow zeroconf names to mask DNS names. > > > more words? Seems like this is a somewhat cryptic way of saying that > DNS and zeroconf need to coexist in a coherent fashion. Is this > wording also trying to sidestep the detailed discussion about what the > coexistance should look like? Seems like this is an important part of > the problem to understand. > > My understanding is that zeroconf name resolution and the DNS are not the same thing, and are orthogonal. I have posted to the dnsext mailing list to try and clarify that, and got one response confirming that point of view: http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01538.html Keith and others have read this document (in conjunction with the mDNS/LLMNR document) and have come to different conclusions. I shall re-read what is in the requirements document and clarify it. >> source-specific multicast addresses for IPv6, in [SS6]. > > > SS6 is not in the references... > > Also, the IPv6 mcast references may need updating anyway to take care > of some relatively new documents: RFC 3306/3307. > ACTION: shall fix > >>3.3.2 Address Allocation >> >> IP multicast address allocation (local, link-local and site-local >> scopes only) requires an application to be able to request the use of >> a suitable multicast address. Coordination among applications must >> occur to avoid conflicting allocations of the same address. This >> coordination must span the entire scope respective to the address. >> When an allocated address is no longer required, that address MUST >> become available for use again. >> >> o MUST select a multicast address. >> > > > Missing "requirements:" before first bullet? (there is a transition > missing) > ACTION: shall fix >>3.3.4 IPv6 Considerations >> >> To date, no range has been reserved for source-specific addresses in >> IPv6. See [SS6]. Hence, until such a range is reserved, dynamic >> allocation of source-specific addresses applies only to IPv4. > > > Is this true in light of RFC 3306? > Not sure, shall check it out. Any comments Dave? > nits: > > It would be good to separate references into normative and > non-normative sections. > OK. >> are updated to reflect these changes, and is responsible for ensuring > > no comma > >> 2, and will be applied to derive requirements for each zeroconf > > no comma > ACTION: press the delete key in the right place.. ;) -- regards aidan ____ :wq! Sydney Network Research Lab aidan.williams@motorola.com Motorola Australian Research Centre phone: +61 2 9666 0649 Locked Bag 5028, Botany NSW 1455 phax: +61 2 9666 0501 Australia http://marc.labs.mot.com/snrl/ From owner-zeroconf@merit.edu Wed Sep 11 22:21:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01034 for ; Wed, 11 Sep 2002 22:21:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8AB2F913BA; Wed, 11 Sep 2002 22:22:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55849913D7; Wed, 11 Sep 2002 22:22:41 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4A4A6913BA for ; Wed, 11 Sep 2002 22:22:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 297435DE20; Wed, 11 Sep 2002 22:22:40 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 993FB5DE13 for ; Wed, 11 Sep 2002 22:22:39 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id TAA28610; Wed, 11 Sep 2002 19:22:38 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id TAA07263; Wed, 11 Sep 2002 19:22:36 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g8C2MZ7C007983; Thu, 12 Sep 2002 12:22:35 +1000 (EST) Message-ID: <3D7FFA6A.8080300@motorola.com> Date: Thu, 12 Sep 2002 12:22:34 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zeroconf@merit.edu Cc: Thomas Narten Subject: probing addresses (was Re: AD comments on draft-ietf-zeroconf-reqts-11.txt) References: <200209111958.g8BJwbv30462@rotala.raleigh.ibm.com> <3D7FDA82.8060700@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Aidan Williams wrote: >>> o A zeroconf name resolution protocol MUST support resolution of >>> names that could not previously be resolved. In particular, >>> probing a desired host name (which does not exist) when joining a >>> network must not prevent the desired hostname from being resolved. >> >> Don't understand what that means. >> > I'll try to clarify the text. The idea is supposed to be that > conflict detection probing shouldn't be cached, resulting in > the name being un-resolvable for a while. > This is now two seperate requirements: A zeroconf name resolution protocol MUST support resolution of names that could not previously be resolved. and slightly later Conflict detection procedures (such as probing for the existence of a a desired host name) MUST NOT prevent the hostname from being resolved. which I think captures the intent. - aidan From owner-zeroconf@merit.edu Wed Sep 11 22:30:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01171 for ; Wed, 11 Sep 2002 22:30:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DBA92913D7; Wed, 11 Sep 2002 22:31:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79EC3913D8; Wed, 11 Sep 2002 22:31:21 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 85727913D7 for ; Wed, 11 Sep 2002 22:31:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6A5F55DE4F; Wed, 11 Sep 2002 22:31:19 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id C1D4E5DE13 for ; Wed, 11 Sep 2002 22:31:18 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id TAA02577 for ; Wed, 11 Sep 2002 19:31:18 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id TAA17791 for ; Wed, 11 Sep 2002 19:31:16 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g8C2VD7C008847; Thu, 12 Sep 2002 12:31:13 +1000 (EST) Message-ID: <3D7FFC70.6070702@motorola.com> Date: Thu, 12 Sep 2002 12:31:12 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aidan Williams Cc: Thomas Narten , zeroconf@merit.edu Subject: SSM IPv6 address range (was Re: AD comments on draft-ietf-zeroconf-reqts-11.txt) References: <200209111958.g8BJwbv30462@rotala.raleigh.ibm.com> <3D7FDA82.8060700@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Aidan Williams wrote: >>> 3.3.4 IPv6 Considerations >>> >>> To date, no range has been reserved for source-specific addresses in >>> IPv6. See [SS6]. Hence, until such a range is reserved, dynamic >>> allocation of source-specific addresses applies only to IPv4. >> >> Is this true in light of RFC 3306? >> RFC3306 specifies the IPv6 SSM address range, so the paragraph isn't accurate anymore. draft-ietf-ssm-arch-00.txt says: (talking about non-IANA allocated SSM addresses) The policy for allocating the rest of the SSM addresses to sending applications is strictly locally determined by the sending host. Given that an earlier assumption bullet says: o The node-local and SSM addresses require no protocol or interaction between multiple hosts, thus are not mentioned further in this document. I think the text is redundant. ACTION: remove paragraph - aidan From owner-zeroconf@merit.edu Wed Sep 11 22:48:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01902 for ; Wed, 11 Sep 2002 22:48:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E3750913D8; Wed, 11 Sep 2002 22:49:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A55AC913DA; Wed, 11 Sep 2002 22:49:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F2CE1913D8 for ; Wed, 11 Sep 2002 22:48:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C6C145DE3F; Wed, 11 Sep 2002 22:48:52 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 60C845DE13 for ; Wed, 11 Sep 2002 22:48:52 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8C2mo015826; Wed, 11 Sep 2002 22:48:50 -0400 (EDT) Message-Id: <200209120248.g8C2mo015826@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Aidan Williams Cc: zeroconf@merit.edu, Thomas Narten Subject: Re: probing addresses (was Re: AD comments on draft-ietf-zeroconf-reqts-11.txt) In-reply-to: (Your message of "Thu, 12 Sep 2002 12:22:34 +1000.") <3D7FFA6A.8080300@motorola.com> Date: Wed, 11 Sep 2002 22:48:50 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > Conflict detection procedures (such as probing for the > existence of a a desired host name) MUST NOT prevent the > hostname from being resolved. > > which I think captures the intent. well, I don't know if I agree. if multiple hosts are advertising conflicting information about the same name, this is an error. in the absence of some external information there is no way to "resolve" this conflict, thus the "host name" resolution should fail rather than lying to the host or application. at least that's true for a globally-scoped name. it might be appropriate for local names to behave differently. Keith From owner-zeroconf@merit.edu Thu Sep 12 00:56:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03717 for ; Thu, 12 Sep 2002 00:56:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 131F5913DA; Thu, 12 Sep 2002 00:58:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CFEE6913DC; Thu, 12 Sep 2002 00:58:02 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DD2E2913DA for ; Thu, 12 Sep 2002 00:58:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C6BF35DEB5; Thu, 12 Sep 2002 00:58:01 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id 683445DDA4 for ; Thu, 12 Sep 2002 00:58:01 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id VAA02545; Wed, 11 Sep 2002 21:58:00 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id VAA27984; Wed, 11 Sep 2002 21:57:58 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g8C4vq7C021046; Thu, 12 Sep 2002 14:57:52 +1000 (EST) Message-ID: <3D801ECF.8080709@motorola.com> Date: Thu, 12 Sep 2002 14:57:51 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Cc: zeroconf@merit.edu, Thomas Narten Subject: Re: probing addresses (was Re: AD comments on draft-ietf-zeroconf-reqts-11.txt) References: <200209120248.g8C2mo015826@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: > well, I don't know if I agree. if multiple hosts are advertising conflicting > information about the same name, this is an error. in the absence of some > external information there is no way to "resolve" this conflict, thus the > "host name" resolution should fail rather than lying to the host or application. > These haven't changed: o A host moving to a new network or powering up MUST ensure that all names it will respond to do not conflict with names already in use. o Zeroconf name resolution protocols MUST resolve host name conflicts in a timely manner and on an ongoing basis. - aidan From owner-zeroconf@merit.edu Thu Sep 12 09:10:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22352 for ; Thu, 12 Sep 2002 09:10:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 553759126E; Thu, 12 Sep 2002 09:12:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 20CF191271; Thu, 12 Sep 2002 09:12:00 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0AA7B9126E for ; Thu, 12 Sep 2002 09:11:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D90495DDE6; Thu, 12 Sep 2002 09:11:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 713F25DDB1 for ; Thu, 12 Sep 2002 09:11:58 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8CDBu011479; Thu, 12 Sep 2002 09:11:56 -0400 (EDT) Message-Id: <200209121311.g8CDBu011479@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Aidan Williams Cc: Keith Moore , zeroconf@merit.edu, Thomas Narten Subject: Re: probing addresses (was Re: AD comments on draft-ietf-zeroconf-reqts-11.txt) In-reply-to: (Your message of "Thu, 12 Sep 2002 14:57:51 +1000.") <3D801ECF.8080709@motorola.com> Date: Thu, 12 Sep 2002 09:11:56 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > These haven't changed: > > o A host moving to a new network or powering up MUST ensure that all > names it will respond to do not conflict with names already in > use. > > o Zeroconf name resolution protocols MUST resolve host name > conflicts in a timely manner and on an ongoing basis. > again, if these are global names that are (or could be) used in DNS, and there's a conflict between the names, something is wrong. it's certainly reasonable to detect such conflicts at the earliest opportunity, but "resolving" such conflicts seems infeasible. Keith From owner-zeroconf@merit.edu Thu Sep 12 11:05:57 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25998 for ; Thu, 12 Sep 2002 11:05:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 126D4912E4; Thu, 12 Sep 2002 11:04:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7A10912E1; Thu, 12 Sep 2002 11:04:30 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DDC2F912B3 for ; Thu, 12 Sep 2002 11:02:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C61F55DE43; Thu, 12 Sep 2002 11:02:50 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by segue.merit.edu (Postfix) with ESMTP id EF8395DD90 for ; Thu, 12 Sep 2002 11:02:49 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g8CF0M502019; Thu, 12 Sep 2002 11:00:22 -0400 Message-Id: <200209121500.g8CF0M502019@cichlid.adsl.duke.edu> To: Keith Moore Cc: Aidan Williams , zeroconf@merit.edu Subject: Re: probing addresses (was Re: AD comments on draft-ietf-zeroconf-reqts-11.txt) In-Reply-To: Message from Keith Moore of "Thu, 12 Sep 2002 09:11:56 EDT." <200209121311.g8CDBu011479@astro.cs.utk.edu> Date: Thu, 12 Sep 2002 11:00:22 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk > > These haven't changed: > > > > o A host moving to a new network or powering up MUST ensure that all > > names it will respond to do not conflict with names already in > > use. > > > > o Zeroconf name resolution protocols MUST resolve host name > > conflicts in a timely manner and on an ongoing basis. > > > again, if these are global names that are (or could be) used in DNS, > and there's a conflict between the names, something is wrong. it's > certainly reasonable to detect such conflicts at the earliest > opportunity, but "resolving" such conflicts seems infeasible. My reading of the intent with these words is that when two networks merge, there now may be two (or more) nodes each thinking they own a particular name. This needs to be detected and resolved, so that only one node continues to use the name. This is not the same thing as implying a global name space. Thomas From owner-zeroconf@merit.edu Thu Sep 12 11:08:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26066 for ; Thu, 12 Sep 2002 11:08:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8F715912F3; Thu, 12 Sep 2002 11:07:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E790912EF; Thu, 12 Sep 2002 11:07:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A31A4912DC for ; Thu, 12 Sep 2002 11:07:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 91CF95DE43; Thu, 12 Sep 2002 11:07:35 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by segue.merit.edu (Postfix) with ESMTP id C08E55DD90 for ; Thu, 12 Sep 2002 11:07:34 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g8CF59j02041; Thu, 12 Sep 2002 11:05:10 -0400 Message-Id: <200209121505.g8CF59j02041@cichlid.adsl.duke.edu> To: Aidan Williams Cc: zeroconf@merit.edu Subject: Re: probing addresses (was Re: AD comments on draft-ietf-zeroconf-reqts-11.txt) In-Reply-To: Message from Aidan Williams of "Thu, 12 Sep 2002 12:22:34 +1000." <3D7FFA6A.8080300@motorola.com> Date: Thu, 12 Sep 2002 11:05:09 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk > This is now two seperate requirements: > A zeroconf name resolution protocol MUST support > resolution of names that could not previously be > resolved. Still not entirely clear. I think what is meant is that you don't want to do negative caching (or at least not for long), as a failure to resolve in the past, does not mean failure will happen again in the future. If that is the intent, how about: Because hosts can connect and disconnect from a network at any time, name resolution that fails at one point in time MUST NOT result in a permanent inability to resolve that name in the future. Not sure the wording here is quite right, but seems more clear about the intent (to me) Thomas From owner-zeroconf@merit.edu Thu Sep 12 11:17:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26347 for ; Thu, 12 Sep 2002 11:17:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DD889912B3; Thu, 12 Sep 2002 11:19:26 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9ABEE912DE; Thu, 12 Sep 2002 11:19:26 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 84D3B912B3 for ; Thu, 12 Sep 2002 11:17:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5ED745DDE2; Thu, 12 Sep 2002 11:17:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail1-0.chcgil.ameritech.net (mail1-0.chcgil.ameritech.net [206.141.192.68]) by segue.merit.edu (Postfix) with ESMTP id 354495DD90 for ; Thu, 12 Sep 2002 11:17:13 -0400 (EDT) Received: from repligate ([67.36.180.20]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020912151709.OCRW4136.mail1-0.chcgil.ameritech.net@repligate>; Thu, 12 Sep 2002 10:17:09 -0500 Message-ID: <087501c25a6f$8a67e6d0$8c56fea9@repligate> From: "Jim Fleming" To: "Aidan Williams" Cc: "Richard Henderson" , , "Judith Oppenheimer" , "Joanna Lane" , , , "Bruce Young" , , "Vittorio Bertola" , , , "Richard J. Sexton" , "Joe Baptista" , , "@quasar Internet Solutions, Inc." , "Ron Sherwood" , References: <200209121311.g8CDBu011479@astro.cs.utk.edu> Subject: ..."resolving" such conflicts seems infeasible... Date: Thu, 12 Sep 2002 10:17:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Keith Moore" To: "Aidan Williams" Cc: "Keith Moore" ; ; "Thomas Narten" Sent: Thursday, September 12, 2002 8:11 AM Subject: Re: probing addresses (was Re: AD comments on draft-ietf-zeroconf-reqts-11.txt) > > These haven't changed: > > > > o A host moving to a new network or powering up MUST ensure that all > > names it will respond to do not conflict with names already in > > use. > > > > o Zeroconf name resolution protocols MUST resolve host name > > conflicts in a timely manner and on an ongoing basis. > > > > again, if these are global names that are (or could be) used in DNS, > and there's a conflict between the names, something is wrong. it's > certainly reasonable to detect such conflicts at the earliest > opportunity, but "resolving" such conflicts seems infeasible. > ..."resolving" such conflicts seems infeasible... Many things seem infeasible, if code is not being written, and there is no interest in resolving what some portray as "conflicts". As one example, look at the emerging managers for 17.IN-ADDR.ARPA. All 9 can have an opinion, software can take a vote and that particular zone in the DNS can be tracked...."on an ongoing basis"... http://www.iana.org/assignments/ipv4-address-space 017/8 Apple Computer Inc. Jul 92 http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt 0:136 PICTURES 0:137 BBS 0:138 PLACE 0:139 KIDS 0:140 SPACE 0:141 APPRAISERS 0:142 CHANGE 0:143 CREATED ========================================== From owner-zeroconf@merit.edu Thu Sep 12 11:53:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27300 for ; Thu, 12 Sep 2002 11:53:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 82D379123E; Thu, 12 Sep 2002 11:54:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4EA8F91241; Thu, 12 Sep 2002 11:54:36 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E1DC9123E for ; Thu, 12 Sep 2002 11:54:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 174F05DDE2; Thu, 12 Sep 2002 11:54:35 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail1-0.chcgil.ameritech.net (mail1-0.chcgil.ameritech.net [206.141.192.68]) by segue.merit.edu (Postfix) with ESMTP id EC17E5DDC7 for ; Thu, 12 Sep 2002 11:54:34 -0400 (EDT) Received: from repligate ([67.36.180.20]) by mail1-0.chcgil.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020912155433.PCVB4136.mail1-0.chcgil.ameritech.net@repligate>; Thu, 12 Sep 2002 10:54:33 -0500 Message-ID: <08a701c25a74$c4581bd0$8c56fea9@repligate> From: "Jim Fleming" To: "Jim Fleming" , "Aidan Williams" Cc: "Richard Henderson" , , "Judith Oppenheimer" , "Joanna Lane" , , , "Bruce Young" , , "Vittorio Bertola" , , , "Richard J. Sexton" , "Joe Baptista" , , "@quasar Internet Solutions, Inc." , "Ron Sherwood" , , References: <200209121311.g8CDBu011479@astro.cs.utk.edu> <087501c25a6f$8a67e6d0$8c56fea9@repligate> Subject: Re: ..."resolving" such conflicts seems infeasible... Date: Thu, 12 Sep 2002 10:55:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Jim Fleming" > > > > > > o Zeroconf name resolution protocols MUST resolve host name > > > conflicts in a timely manner and on an ongoing basis. > > > > > > > again, if these are global names that are (or could be) used in DNS, > > and there's a conflict between the names, something is wrong. it's > > certainly reasonable to detect such conflicts at the earliest > > opportunity, but "resolving" such conflicts seems infeasible. > > > > ..."resolving" such conflicts seems infeasible... > > Many things seem infeasible, if code is not being written, and there is no > interest in resolving what some portray as "conflicts". > http://www.sdnbd.org/sdnp/news/cctldtraining_sdnp.htm http://www.wwtld.org/nameserver/cctld_names_server_training.html Vietnam : 11 September 2002 Contact person: Vu Xuan Bach ================== Another example would be how the new 128-bit DNS software is able to look for key names and remove allocations if they are no longer in use. IN-ADDR.VN ? http://www.analogx.com/cgi-bin/cgidig.exe?DNS=205.214.45.10&Query=in-addr.vn&Type=255&submit=Lookup That type of tracking can happen on an "on-going basis". If people are told to remove zones such as IN-ADDR.VN, then they lose their allocation. That opens up more space for other people. Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer... http://ipv8.dyndns.tv http://ipv8.yi.org http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.org http://ipv8.no-ip.biz http://ipv8.no-ip.info http://ipv8.myip.us http://ipv8.dyn.ee http://ipv8.community.net.au http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt From owner-zeroconf@merit.edu Thu Sep 12 12:03:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27634 for ; Thu, 12 Sep 2002 12:03:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EF1B891243; Thu, 12 Sep 2002 12:05:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BABB791244; Thu, 12 Sep 2002 12:05:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9E75791243 for ; Thu, 12 Sep 2002 12:05:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 83A6F5DE65; Thu, 12 Sep 2002 12:05:16 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 1D9635DE43 for ; Thu, 12 Sep 2002 12:05:16 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8CG2f013091; Thu, 12 Sep 2002 12:02:41 -0400 (EDT) Message-Id: <200209121602.g8CG2f013091@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Thomas Narten Cc: Keith Moore , Aidan Williams , zeroconf@merit.edu Subject: Re: probing addresses (was Re: AD comments on draft-ietf-zeroconf-reqts-11.txt) In-reply-to: (Your message of "Thu, 12 Sep 2002 11:00:22 EDT.") <200209121500.g8CF0M502019@cichlid.adsl.duke.edu> Date: Thu, 12 Sep 2002 12:02:41 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > My reading of the intent with these words is that when two networks > merge, there now may be two (or more) nodes each thinking they own a > particular name. This needs to be detected and resolved, so that only > one node continues to use the name. > > This is not the same thing as implying a global name space. if there's no intent to support use of DNS names or DNS-like names, and the group is willing to NOT overload existing name lookup APIs, I'd like that to be stated explicitly and up-front. it simplifies a number of problems, but it also makes zeroconf incompatible with existing programs - so I have my doubts that this is the intent. From owner-zeroconf@merit.edu Thu Sep 12 12:04:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27657 for ; Thu, 12 Sep 2002 12:04:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3892391244; Thu, 12 Sep 2002 12:05:50 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0AF1D91245; Thu, 12 Sep 2002 12:05:49 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BFA3691244 for ; Thu, 12 Sep 2002 12:05:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A66975DE43; Thu, 12 Sep 2002 12:05:48 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 404BC5DDC7 for ; Thu, 12 Sep 2002 12:05:48 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8CG5b013207; Thu, 12 Sep 2002 12:05:37 -0400 (EDT) Message-Id: <200209121605.g8CG5b013207@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Thomas Narten Cc: Aidan Williams , zeroconf@merit.edu Subject: Re: probing addresses (was Re: AD comments on draft-ietf-zeroconf-reqts-11.txt) In-reply-to: (Your message of "Thu, 12 Sep 2002 11:05:09 EDT.") <200209121505.g8CF59j02041@cichlid.adsl.duke.edu> Date: Thu, 12 Sep 2002 12:05:37 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk Because hosts can connect and disconnect from a network at any time, name resolution that fails at one point in time MUST NOT result in a permanent inability to resolve that name in the future. "permanent" is too long. how about ...the failure to resolve a name at some time MUST NOT be taken as an indication that the name will remain invalid for any length of time. if we need to specify a max amount of time, I suggest one minute. From owner-zeroconf@merit.edu Fri Sep 13 05:26:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29512 for ; Fri, 13 Sep 2002 05:26:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 83B20912F6; Fri, 13 Sep 2002 05:27:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 592C0912F7; Fri, 13 Sep 2002 05:27:36 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5DA4C912F6 for ; Fri, 13 Sep 2002 05:27:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4378C5DE31; Fri, 13 Sep 2002 05:27:35 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by segue.merit.edu (Postfix) with ESMTP id D27915DE07 for ; Fri, 13 Sep 2002 05:27:34 -0400 (EDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 172224B23; Fri, 13 Sep 2002 18:27:27 +0900 (JST) To: Keith Moore Cc: zeroconf@merit.edu In-reply-to: moore's message of Thu, 12 Sep 2002 12:02:41 -0400. <200209121602.g8CG2f013091@astro.cs.utk.edu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: probing addresses (was Re: AD comments on draft-ietf-zeroconf-reqts-11.txt) From: itojun@iijlab.net Date: Fri, 13 Sep 2002 18:27:27 +0900 Message-Id: <20020913092727.172224B23@coconut.itojun.org> Sender: owner-zeroconf@merit.edu Precedence: bulk >> My reading of the intent with these words is that when two networks >> merge, there now may be two (or more) nodes each thinking they own a >> particular name. This needs to be detected and resolved, so that only >> one node continues to use the name. >> >> This is not the same thing as implying a global name space. > >if there's no intent to support use of DNS names or DNS-like names, >and the group is willing to NOT overload existing name lookup APIs, >I'd like that to be stated explicitly and up-front. it simplifies >a number of problems, but it also makes zeroconf incompatible with >existing programs - so I have my doubts that this is the intent. (i know i'm talking about different draft) then why "local.arpa" was removed from mDNS/LLMNR document? indicators like "local.arpa" or "local" (used by Apple Rendezvous) is a good indication. itojun From owner-zeroconf@merit.edu Tue Sep 17 08:05:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11523 for ; Tue, 17 Sep 2002 08:05:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4A27391247; Tue, 17 Sep 2002 08:06:46 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1BDE79125C; Tue, 17 Sep 2002 08:06:46 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 13E0A91247 for ; Tue, 17 Sep 2002 08:06:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 021F55DDD3; Tue, 17 Sep 2002 08:06:45 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 717385DDB0 for ; Tue, 17 Sep 2002 08:06:44 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id FAA02938; Tue, 17 Sep 2002 05:06:43 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id FAA27173; Tue, 17 Sep 2002 05:04:02 -0700 (MST)] Received: from motorola.com (mvp-10-238-2-5.corp.mot.com [10.238.2.5]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g8HC6Y7C004391; Tue, 17 Sep 2002 22:06:35 +1000 (EST) Message-ID: <3D871AC8.1070607@motorola.com> Date: Tue, 17 Sep 2002 22:06:32 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Cc: Thomas Narten , zeroconf@merit.edu Subject: Re: probing addresses (was Re: AD comments on draft-ietf-zeroconf-reqts-11.txt) References: <200209121605.g8CG5b013207@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the text. I ended up with: Because hosts can connect and disconnect from a network at any time, the failure to resolve a name at some time MUST NOT be taken as an indication that the name will remain invalid for any length of time. Keith Moore wrote: > Because hosts can connect and disconnect from a network > at any time, name resolution that fails at one point in > time MUST NOT result in a permanent inability to resolve > that name in the future. > > "permanent" is too long. how about > > ...the failure to resolve a name at some time MUST NOT > be taken as an indication that the name will remain invalid > for any length of time. > > if we need to specify a max amount of time, I suggest one minute. -- regards aidan ____ :wq! Sydney Network Research Lab aidan.williams@motorola.com Motorola Australian Research Centre phone: +61 2 9666 0649 Locked Bag 5028, Botany NSW 1455 phax: +61 2 9666 0501 Australia http://marc.labs.mot.com/snrl/ From owner-zeroconf@merit.edu Wed Sep 18 01:10:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09277 for ; Wed, 18 Sep 2002 01:10:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 386209122A; Wed, 18 Sep 2002 01:12:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0646F91237; Wed, 18 Sep 2002 01:12:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E60A79122A for ; Wed, 18 Sep 2002 01:12:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE1C75DFF9; Wed, 18 Sep 2002 01:12:14 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mta06ps.bigpond.com (mta06ps.bigpond.com [144.135.25.138]) by segue.merit.edu (Postfix) with ESMTP id BFA475DEB6 for ; Wed, 18 Sep 2002 01:12:13 -0400 (EDT) Received: from 192.168.1.246 ([144.135.25.69]) by mta06ps.bigpond.com (Netscape Messaging Server 4.15 mta06ps May 23 2002 23:53:28) with SMTP id H2MBSA00.AO7 for ; Wed, 18 Sep 2002 15:12:10 +1000 Received: from CPE-203-51-24-97.nsw.bigpond.net.au ([203.51.24.97]) by PSMAM01.mailsvc.email.bigpond.com(MailRouter V3.0n 71/9280713); 18 Sep 2002 15:12:10 From: Brad Hards To: zeroconf@merit.edu Subject: [OT] Implementers discussion list Date: Wed, 18 Sep 2002 15:06:04 +1000 User-Agent: KMail/1.4.5 MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200209181506.04755.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Since there appears to be moves to close up the Zeroconf working group, I'd like to invite anyone interested in implementing zeroconf technologies to join the "zeroconf-workers" mailing list. This list is wide-ranging - it doesn't restrict itself to "in-scope" tasks for the Zeroconf working group. Think of it as an integrators list for people that want to test and deploy working systems. Particular things of interest: * Automating configuration on common applications (eg modifying squid and apache to automagically provide proxy config settings to various browsers) * Trial installations of zeroconf naming solutions (eg LLMNR and http://developer.apple.com/macosx/rendezvous/) * Modifications to various existing apps to make them work sensibly in a multi-home environment. * Anything else that makes networking possible for the "mum and dad" (aka "mom and pop") type user. About zeroconf-workers This list is for people interested in making networking easy to use, by removing the need for network configuration. Specifical topics that are appropriate for this list include protocol implementation (including, but not restricted to IETF Zeroconf protocols), integration of zeroconfiguration technologies into new and existing applications, and integrating various techniques and applications into Unix-like operating systems (including Linux and Mac OS X). This is not an appropriate list to ask general questions about networking, or for step-by-step tutorial assistance. This list is hosted on Sourceforge, and discussion of software that is not generally available with source is probably off-topic. https://lists.sourceforge.net/lists/listinfo/zeroconf-workers is the mailman interface to subscribe. Administrivia: * I have configured the list so that only subscribers can post, in an attempt to reduce spam. * I am really tolerant about topic, just as long as people play nice. * The list is archived - see http://sourceforge.net/mailarchive/forum.php?forum=zeroconf-workers - -- http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9iAm8W6pHgIdAuOMRApzhAJ0clnIA1pqA5jRYkovgYWKj2BRHFwCgtSVI Fuu00EVejAZbz2VudnT1BL0= =er4Z -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Wed Sep 18 01:14:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09340 for ; Wed, 18 Sep 2002 01:14:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4FD0F91237; Wed, 18 Sep 2002 01:15:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21C1691242; Wed, 18 Sep 2002 01:15:45 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0DACB91237 for ; Wed, 18 Sep 2002 01:15:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2A20D5DFF9; Wed, 18 Sep 2002 01:15:41 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 5FB9D5DE8F for ; Wed, 18 Sep 2002 01:15:40 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id WAA27408 for ; Tue, 17 Sep 2002 22:15:39 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id WAA24715 for ; Tue, 17 Sep 2002 22:12:57 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g8I5847C028986 for ; Wed, 18 Sep 2002 15:08:04 +1000 (EST) Message-ID: <3D880A33.6090403@motorola.com> Date: Wed, 18 Sep 2002 15:08:03 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: general zeroconf co-existance requirements Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have added the second paragraph and the three requirements on the basis of recent mailing list discussion. The security requirement is repeated (and expanded upon) later in the document. If you have comments, please suggest text. 1.3 Zeroconf Coexistence It is not necessary to simultaneously use zeroconf protocols in all four areas (i.e. IP interface configuration, translation between host name and IP address, IP multicast address allocation, service discovery). For example, it may make sense on some networks to provide a DHCP server for configured IP interface configuration, but perform translation between host name and IP address using a zeroconf protocol. Given that zeroconf protocols may be deployed on existing configured networks, care must be taken in their design to ensure minimum disruption to existing networks and applications. Particular consideration should be given to the security implications of deploying zeroconf protocols in conjunction with standard configured network protocols. Requirements: o Zeroconf protocols SHOULD minimise their impact on existing networks o Zeroconf protocols SHOULD minimise impact on existing applications. o Zeroconf protocols MUST NOT be any less secure than related current IETF-Standard protocols. -- regards aidan ____ :wq! Sydney Network Research Lab aidan.williams@motorola.com Motorola Australian Research Centre phone: +61 2 9666 0649 Locked Bag 5028, Botany NSW 1455 phax: +61 2 9666 0501 Australia http://marc.labs.mot.com/snrl/ From owner-zeroconf@merit.edu Wed Sep 18 08:46:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10733 for ; Wed, 18 Sep 2002 08:46:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 607A49127C; Wed, 18 Sep 2002 08:47:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2821191285; Wed, 18 Sep 2002 08:47:41 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0A75D9127C for ; Wed, 18 Sep 2002 08:47:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E20295E05C; Wed, 18 Sep 2002 08:47:20 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 7BE5F5E056 for ; Wed, 18 Sep 2002 08:47:20 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8IClK017763 for ; Wed, 18 Sep 2002 08:47:20 -0400 (EDT) Message-Id: <200209181247.g8IClK017763@astro.cs.utk.edu> To: zeroconf@merit.edu Subject: my response to "general zeroconf co-existance requirements" Date: Wed, 18 Sep 2002 08:47:20 -0400 From: Keith Moore Sender: owner-zeroconf@merit.edu Precedence: bulk this text looks good. however somewhere in the document I think it should be stated that zeroconf MUST NOT adversely impact the abliity of the network to support existing _kinds_ of applications. that is, if specific applications require minor modification to work effectively after the introduction of zeroconf, that's perhaps tolerable - provided there is a workaround (which currently doesn't exist for LL). on the other hand, if the introduction of zeroconf requires major modifications to such applicatons or if it impairs their ability to function at all, ths is not acceptable. From owner-zeroconf@merit.edu Wed Sep 18 20:16:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04484 for ; Wed, 18 Sep 2002 20:16:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2E8DE9120C; Wed, 18 Sep 2002 20:18:05 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA87991210; Wed, 18 Sep 2002 20:18:04 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E9DBC9120C for ; Wed, 18 Sep 2002 20:17:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C88B95DEB5; Wed, 18 Sep 2002 20:17:34 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 0C5195DDBE for ; Wed, 18 Sep 2002 20:17:34 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id RAA04281 for ; Wed, 18 Sep 2002 17:17:33 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id RAA09030 for ; Wed, 18 Sep 2002 17:17:31 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g8J0HO7C003538; Thu, 19 Sep 2002 10:17:24 +1000 (EST) Message-ID: <3D891792.4090004@motorola.com> Date: Thu, 19 Sep 2002 10:17:22 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Cc: zeroconf@merit.edu Subject: Re: my response to "general zeroconf co-existance requirements" References: <200209181247.g8IClK017763@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: > this text looks good. however somewhere in the document I think it should > be stated that zeroconf MUST NOT adversely impact the abliity of the > network to support existing _kinds_ of applications. that is, if > specific applications require minor modification to work effectively after > the introduction of zeroconf, that's perhaps tolerable - provided there > is a workaround (which currently doesn't exist for LL). on the other > hand, if the introduction of zeroconf requires major modifications to > such applicatons or if it impairs their ability to function at all, > ths is not acceptable. > This text is in the paragraph preceeding these requirements: Given that zeroconf protocols may be deployed on existing configured networks, care must be taken in their design to ensure minimum disruption to existing networks and applications. ACTION: crank the SHOULDs to MUSTS: o Zeroconf protocols MUST minimise their impact on existing networks o Zeroconf protocols MUST minimise impact on existing applications. -- regards aidan ____ :wq! Sydney Network Research Lab aidan.williams@motorola.com Motorola Australian Research Centre phone: +61 2 9666 0649 Locked Bag 5028, Botany NSW 1455 phax: +61 2 9666 0501 Australia http://marc.labs.mot.com/snrl/ From owner-zeroconf@merit.edu Mon Sep 23 02:33:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00363 for ; Mon, 23 Sep 2002 02:33:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B26499122A; Mon, 23 Sep 2002 02:34:40 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7813491237; Mon, 23 Sep 2002 02:34:40 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 62C8D9122A for ; Mon, 23 Sep 2002 02:34:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3DE595DEB1; Mon, 23 Sep 2002 02:34:37 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id E96695DEAB for ; Mon, 23 Sep 2002 02:34:35 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id XAA07905; Sun, 22 Sep 2002 23:34:32 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id XAA17652; Sun, 22 Sep 2002 23:34:29 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g8N6YM7C015248; Mon, 23 Sep 2002 16:34:23 +1000 (EST) Message-ID: <3D8EB5ED.50205@motorola.com> Date: Mon, 23 Sep 2002 16:34:21 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zeroconf@merit.edu Cc: Erik Nordmark , Thomas Narten , Erik Guttman , Stuart Cheshire Subject: DNS/zeroconf name resolution co-existance text References: <200209111958.g8BJwbv30462@rotala.raleigh.ibm.com> <3D7FDA82.8060700@motorola.com> Content-Type: multipart/mixed; boundary="------------010704070006050909030209" Sender: owner-zeroconf@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------010704070006050909030209 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, I have written some expanded text on the subject of requirements for DNS and zeroconf name resolution protocol coexistance. We have not reached agreement on this. My intent was to write up the basic approaches and issues that have been suggested and call it quits. If you have objections to what I have written, can I ask that you provide specific text. Otherwise I'll end up trying to read your mind and I'm not very good at that.. ;) This is the last change arising from list email that I think I need to do to draft-ietf-zeroconf-reqts-12.txt before submitting a new rev of the draft. - aidan 3.2.2 Relationship to the DNS Zeroconf name resolution protocols cannot be directly equated with the DNS even though they may have a number of similarities. For example, the DNS protocols as deployed today rely on a server infrastructure that may not be present in a zeroconf environment. Host names used in zeroconf networks are inherently locally scoped whereas DNS names are global and unique by design. At the time of writing, consensus on how zeroconf name resolution protocols should interact with the DNS has not been reached. The next sections will attempt to capture the flavour of the different approaches that have been proposed. 3.2.2.1 Close coupling In this approach an application may look up a DNS name (e.g. "www.someco.com") using an existing API and receive and answer from a zeroconf name resolution protocol. The zeroconf name resolution protocol makes use of existing on-the-wire DNS formats, resource record definitions, and namespace. Some names may have a DNS suffix that identifies them as being local in scope. Issues yet to be resolved with this approach relate to security and consistency. If the zeroconf name resolution involves multicasting the request on a local network then the risk of spoofed responses to global DNS names like "www.someco.com" is increased. If the namespace is the same, then doing a zeroconf name lookup should return results consistent with DNS lookup for the same name. What is meant by this consistency is not agreed. Should the zeroconf lookup only be used when the DNS lookup has failed? Should that lookup reflect what would have been returned by the DNS? How should the probing for uniqueness of a zeroconf name relate to updating of a DNS record? 3.2.2.2 Completely orthogonal Another approach is to ensure that the zeroconf namespace and the DNS namespace are completely orthogonal. There is therefore no possibility of any application using the DNS via existing APIs behaving differently after a zeroconf name resolution protocol is deployed. Applications would need to explicitly use a zeroconf name lookup API in order to resolve names using a zeroconf lookup protocol. Conversely, existing applications will derive no benefit from zeroconf protocols unless they are re-written. Deployment of a zeroconf name resolution protocol would necessitate application upgrade. 3.2.2.3 API compatible In this approach the zeroconf namespace is distinct from the DNS namespace however zeroconf names may be resolved using an existing API. A number of operating systems use generalised name service interfaces that transparently allow a variety of name lookup protocols to be used to resolve hostnames for applications. A zeroconf name resolution protocol could be incorporated into such a system in a straightforward manner as just one more namespace and lookup protocol. Again, there is increased risk of spoofed responses if the multicast zeroconf name resolution protocol is used to resolve "www.someco.com". One possible way of minimising the security risk is to ensure that locally scoped names are distinguishable from DNS names, perhaps via a known reserved DNS suffix or by virtue of not containing a dot. A multicast zeroconf resolution protocol could then avoid making requests for names which look like global DNS names. Alternatively, we could require that zeroconf name lookups only be performed when the equivalent DNS lookup has failed. Aidan Williams wrote: >>Thomas Narten wrote: >>> Using a zeroconf name resolution protocol to query a DNS name is NOT >>> equivalent to using the DNS protocols to query the same name. A host >>> using DNS and zeroconf name resolution protocols at the same time >>> MUST NOT allow zeroconf names to mask DNS names. >> >> more words? Seems like this is a somewhat cryptic way of saying that >> DNS and zeroconf need to coexist in a coherent fashion. Is this >> wording also trying to sidestep the detailed discussion about what the >> coexistance should look like? Seems like this is an important part of >> the problem to understand. >> > > My understanding is that zeroconf name resolution and the > DNS are not the same thing, and are orthogonal. > I have posted to the dnsext mailing list to try and > clarify that, and got one response confirming that point > of view: > http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01538.html > > Keith and others have read this document (in conjunction > with the mDNS/LLMNR document) and have come to different > conclusions. I shall re-read what is in the requirements > document and clarify it. > --------------010704070006050909030209 Content-Type: text/plain; name="draft-ietf-zeroconf-reqts.txt" Content-Disposition: inline; filename="draft-ietf-zeroconf-reqts.txt" Content-Transfer-Encoding: 7bit Zero Configuration Networking A. Williams Internet-Draft Motorola Expires: March 19, 2003 September 18, 2002 Requirements for Automatic Configuration of IP Hosts draft-ietf-zeroconf-reqts-12.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 19, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Many common TCP/IP protocols such as DHCP [RFC2131], DNS [RFC1034][RFC1035], MADCAP [RFC2730], and LDAP [RFC2251] must be configured and maintained by an administrative staff. This is unacceptable for emerging networks such as home networks, automobile networks, airplane networks, or ad hoc networks at conferences, emergency relief stations, and many others. Such networks may be nothing more than two isolated laptop PCs connected via a wireless LAN. For all these networks, an administrative staff will not exist and the users of these networks neither have the time nor inclination to learn network administration skills. Instead, these networks need protocols that require zero user configuration and administration. This document is part of an effort to define such zero configuration Williams Expires March 19, 2003 [Page 1] Internet-Draft Zeroconf Requirements September 2002 (zeroconf) protocols. Before embarking on defining zeroconf protocols, protocol requirements are needed. This document states the zeroconf protocol requirements for four protocol areas; they are: IP interface configuration, translation between host name and IP address, IP multicast address allocation, and service discovery. This document does not define specific protocols, just requirements. The requirements for these four areas result from examining everyday use or scenarios of these protocols. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Key Words . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Reading This Document . . . . . . . . . . . . . . . . . . 4 1.3 Zeroconf Coexistence . . . . . . . . . . . . . . . . . . . 5 1.4 Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 1.5 Routable Protocol Requirement . . . . . . . . . . . . . . 5 1.6 Maintaining Consistent Network State . . . . . . . . . . . 6 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Addition and Removal of Devices . . . . . . . . . . . . . 6 2.2 Network Coalescing and Partitioning . . . . . . . . . . . 7 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 IP Interface Configuration . . . . . . . . . . . . . . . . 8 3.1.1 IPv6 Considerations . . . . . . . . . . . . . . . . . . . 10 3.2 Translation between Host name and IP Address . . . . . . . 10 3.2.1 IPv6 Considerations . . . . . . . . . . . . . . . . . . . 11 3.2.2 Relationship to the DNS . . . . . . . . . . . . . . . . . 11 3.2.2.1 Close coupling . . . . . . . . . . . . . . . . . . . . . . 12 3.2.2.2 Completely orthogonal . . . . . . . . . . . . . . . . . . 12 3.2.2.3 API compatible . . . . . . . . . . . . . . . . . . . . . . 12 3.3 IP Multicast Address Allocation Scenarios . . . . . . . . 13 3.3.1 Scope Enumeration . . . . . . . . . . . . . . . . . . . . 14 3.3.2 Address Allocation . . . . . . . . . . . . . . . . . . . . 14 3.3.3 Multiple Sources . . . . . . . . . . . . . . . . . . . . . 15 3.3.4 IPv6 Considerations . . . . . . . . . . . . . . . . . . . 15 3.4 Service Discovery Scenarios . . . . . . . . . . . . . . . 15 3.4.1 Printer Service . . . . . . . . . . . . . . . . . . . . . 16 3.4.2 IPv6 Considerations . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . 16 4.1 The Basic in/out Security Policy . . . . . . . . . . . . . 17 4.2 Security Scenarios . . . . . . . . . . . . . . . . . . . . 18 4.2.1 Use on an isolated, secure network link . . . . . . . . . 18 4.2.2 Use on a shared (insecure) link . . . . . . . . . . . . . 18 4.2.3 Use in conjunction with configured protocols . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . 19 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 19 Williams Expires March 19, 2003 [Page 2] Internet-Draft Zeroconf Requirements September 2002 Normative References . . . . . . . . . . . . . . . . . . . 19 Informative References . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . 21 Full Copyright Statement . . . . . . . . . . . . . . . . . 22 Williams Expires March 19, 2003 [Page 3] Internet-Draft Zeroconf Requirements September 2002 1. Introduction A zeroconf protocol is able to operate correctly in the absence of configured information from either a user or infrastructure services such as conventional DHCP [RFC2131] or DNS [RFC1034][RFC1035] servers. Zeroconf protocols may use configured information, when it is available, but do not rely on it being present. For example, the use of MAC addresses (i.e. layer two addresses) as parameters in zeroconf protocols is generally acceptable because they are globally unique and readily available on most devices of interest. The benefits of zeroconf protocols over existing configured protocols are an increase in the ease-of-use for end-users and a simplification of the infrastructure necessary to operate protocols. This document discusses requirements for zeroconf protocols in four areas: o IP interface configuration o Translation between host name and IP address o IP multicast address allocation o Service discovery Security considerations are also discussed. 1.1 Key Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.2 Reading This Document Introduction, Scenarios, Requirements, and Security Considerations are the major sections of this document. The Scenarios & Requirements sections walk through protocol scenarios and then lists the requirements of the protocol needed to accomplish the scenario. The Security Consideration section lists security issues with zeroconf protocols. Requirements dispersed throughout this document begin with the text "Requirements:" or "Requirement:" on a single line, which is followed Williams Expires March 19, 2003 [Page 4] Internet-Draft Zeroconf Requirements September 2002 by a bulleted list of requirements. 1.3 Zeroconf Coexistence It is not necessary to simultaneously use zeroconf protocols in all four areas (i.e. IP interface configuration, translation between host name and IP address, IP multicast address allocation, service discovery). For example, it may make sense on some networks to provide a DHCP server for configured IP interface configuration, but perform translation between host name and IP address using a zeroconf protocol. Given that zeroconf protocols may be deployed on existing configured networks, care must be taken in their design to ensure minimum disruption to existing networks and applications. Particular consideration should be given to the security implications of deploying zeroconf protocols in conjunction with standard configured network protocols. Requirements: o Zeroconf protocols SHOULD minimise their impact on existing networks o Zeroconf protocols SHOULD minimise impact on existing applications. o Zeroconf protocols MUST NOT be any less secure than related current IETF-Standard protocols. 1.4 Scalability The primary reasons to deploy Zeroconf protocols are simplicity and ease-of-use. Scalability is important but it is a secondary goal. Thus, scalability should not detract from the primary goals of simplicity and ease-of-use. 1.5 Routable Protocol Requirement Zeroconf protocols are not inherently limited to a single IP subnet. If a protocol is intended to span multiple IP subnets it MUST NOT use broadcasts or link-local addressing. Requirement: o Protocols intended to span multiple IP subnets MUST NOT use broadcasts or link-local addressing. Williams Expires March 19, 2003 [Page 5] Internet-Draft Zeroconf Requirements September 2002 1.6 Maintaining Consistent Network State Many networks undergo change during their lifetime. For example, hosts may be added and removed, network segments may be re-arranged, and devices may change names or run different services. In a configured network an administrator ensures that protocol parameters are updated to reflect these changes and is responsible for ensuring network consistency. In contrast, zeroconf protocols must adapt to changing network conditions. Zeroconf protocols must be able to resolve conflicts and return the network to a consistent state after changes in network topology or other events. Requirement: o Zeroconf protocols MUST restore the network to a consistent state in a timely fashion when changes in network topology or other events occur. This is a general requirement applicable to all zeroconf protocols. It should be kept in mind when considering the scenarios in Section 2 and will be applied to derive requirements for each zeroconf protocol area considered in Section 3. 2. Scenarios The scenarios described in the next few sections highlight the general characteristics of the zeroconf protocol environment. Each zeroconf protocol needs to deal with the following aspects of the zeroconf environment. 2.1 Addition and Removal of Devices Zeroconf protocols are expected to be useful in networks where hosts come and go. Hosts using zeroconf protocols must not assume that network resources assigned to them (e.g. address assignments, names, etc) will be appropriate for networks they subsequently join. In addition, network resources allocated to a host should be reclaimed once it leaves the network. Requirements: o Zeroconf protocols MUST support mechanisms to probe whether a network resource is currently in use. o Hosts using zeroconf protocols MUST validate allocated network resources when moving to a new network or powering up. Williams Expires March 19, 2003 [Page 6] Internet-Draft Zeroconf Requirements September 2002 o Zeroconf protocols MUST support timely reclamation of any network resources they allocate. Implication: o The information needed to allocate network resources must arrive in the network along with the host. 2.2 Network Coalescing and Partitioning Inevitably, two or more operational networks using zeroconf protocols will be connected together, creating a single merged network. Prior to the merge, each zeroconf network has independently allocated resources (e.g. addresses, names, etc). After merging, two hosts in the merged network may end up using the same network resource, thus potentially creating conflicts. In general a network merge "event" cannot be detected. For example, the installation of a layer-2 bridge between two zeroconf networks does not result in network interfaces going up and down on the hosts, which would be an indication that they should re-validate or reconfigure the network resources they are using. Implication: o It is not sufficient to rely on hosts detecting conflicts during power on or movement from network to network. Rather, detection and resolution of network conflicts is an ongoing part of zeroconf protocol operation. Requirement: o Zeroconf protocols MUST resolve network resource conflicts in a timely manner and on an ongoing basis. Zeroconf protocols that detect and resolve network resource conflicts on an ongoing basis will benefit from increased robustness in the face of poor implementation, and varying network conditions. A zeroconf network may also be split into two or more smaller independent networks. The requirement from Section 2.1 that network resources be reclaimed in a timely fashion also applies in this case. Since network merging increases the potential for network conflicts, it may be prudent to ensure that network resources associated with hosts are not immediately re-claimed for re-use. Any network which periodically joins and partitions with another zeroconf network will benefit from this behaviour. An example is an IP network in a car Williams Expires March 19, 2003 [Page 7] Internet-Draft Zeroconf Requirements September 2002 joining with the home network whilst the car is parked in the garage and partitioning when it is driven away. Requirement: o Zeroconf protocols SHOULD NOT immediately reuse network resources as soon as they become available. o Network resources SHOULD be allocated in a way that minimises the probability that two hosts will be allocated the same resource. o Network resources SHOULD be allocated in a way that increases the chances of a particular host being allocated the same resource should it leave and rejoin the network. 3. Requirements This section contains a subsection for each of the four protocol areas. Within each subsection, terms and assumptions are followed by specific zeroconf protocol requirements in that area. Each subsection ends with IPv6 considerations. 3.1 IP Interface Configuration In this document, IP interface configuration always includes the configuration of an IP address and netmask; it may include some routing information (such as default route). IP interface configuration is needed before almost any IP communication can take place. Terms: IP subnet: A single logical IP network that may span multiple link layer networks. All IP hosts on the IP subnet communicate without any layer 3 forwarding device (e.g. router). internetwork: Multiple IP subnets connected by routers. network: a context sensitive term that may apply to one or more of the terms: a link layer network, an IP subnet, or an internetwork. bridge: a networking device that connects two link layer networks by using only link-layer protocols (e.g. Ethernet). IP interface configuration must take place before an IP packet can be sent from one host to another. This section requires that sufficient information be provided by a zeroconf interface configuration Williams Expires March 19, 2003 [Page 8] Internet-Draft Zeroconf Requirements September 2002 protocol to allow IP packets to be sent to a unicast destination IP address on the same subnet as the sender, and on a different subnet to the sender. Requirements: A zeroconf IP interface configuration protocol o MUST configure an appropriate netmask. o MUST allocate unique IP addresses within an IP subnet. o MUST allow configuration of zero or more gateways (for the internetwork scenario). o MUST have unique IP subnets within an internetwork (This is only for the case when there is one or more router attached in the network where autoconfigured hosts. How routers obtain their configuration is beyond of the scope of this document.) The following requirements are derived from applying Section 2.1 and Section 2.2 to IP interface configuration. Requirements: A zeroconf IP interface configuration protocol o MUST be capable of discovering whether an IP address is currently in use. o Hosts using a zeroconf interface configuration protocol MUST validate allocated IP addresses when moving to a new network or powering up. o MUST support timely reclamation of allocated IP addresses. o MUST resolve IP address conflicts in a timely manner and on an ongoing basis. o SHOULD NOT immediately reuse IP addresses as soon as they become available. o IP addresses SHOULD be allocated in a way that minimises the probability that two hosts will be allocated the same address. o IP addresses SHOULD be allocated in a way that increases the chances of a particular host being allocated the same address should it leave and rejoin the network. Williams Expires March 19, 2003 [Page 9] Internet-Draft Zeroconf Requirements September 2002 3.1.1 IPv6 Considerations IPv6 provides a mechanism that allows a host to generate a link-local IP address Autoconfiguration[RFC2462]. Thus a zeroconf IP interface configuration solution for generating link-local addresses already exists for hosts using IPv6. 3.2 Translation between Host name and IP Address A zeroconf name resolution protocol allows users to refer to their devices by name rather than IP address. Host names are more user friendly than IP addresses and host names have a greater chance of remaining unchanged over time. A zeroconf device connected to different networks is quite likely to use different IP addresses, however a host name may stay the same. For applications like web browsers which store bookmarks and histories, use of names rather than IP addresses is beneficial. In a zeroconf network, the information required to construct a host name must enter the network with the device. It is expected that users will configure names into devices, or that devices will come with a pre-configured name. Devices may also construct a name from a MAC address or serial number. How this is to be achieved is outside the scope of this document. Terms: host name: A textual name that allows a user to refer to a host by name rather than IP address. Requirements: o A zeroconf name resolution protocol MUST allow host names to be mapped into IP addresses. o A zeroconf name resolution protocol SHOULD allow IP addresses to be mapped back to names. o Because hosts can connect and disconnect from a network at any time, the failure to resolve a name at some time MUST NOT be taken as an indication that the name will remain invalid for any length of time. o A zeroconf name resolution protocol SHOULD support resolution of names on multiple IP subnets connected by a router. The following requirements are derived from applying Section 2.1 and Section 2.2 to zeroconf name resolution. Williams Expires March 19, 2003 [Page 10] Internet-Draft Zeroconf Requirements September 2002 Requirements: o A zeroconf name resolution protocol MUST support mechanisms to probe whether a host name is currently in use. o A host moving to a new network or powering up MUST ensure that all names it will respond to do not conflict with names already in use. o Zeroconf name resolution protocols MUST allow timely re-use of hostnames. o Zeroconf name resolution protocols MUST resolve host name conflicts in a timely manner and on an ongoing basis. o Conflict detection procedures (such as probing for the existence of a desired host name) MUST NOT prevent valid hostnames from being resolved. o Zeroconf name resolution protocols SHOULD NOT immediately reuse host names as soon as they become available. o Host names SHOULD be chosen in a way that minimises the probability that two hosts will use the same name. Note that this is out of scope of the name resolution protocol itself. 3.2.1 IPv6 Considerations Protocols to perform translation between host name and IP address have no known zeroconf-related differences for IPv4 and IPv6. 3.2.2 Relationship to the DNS Zeroconf name resolution protocols cannot be directly equated with the DNS even though they may have a number of similarities. For example, the DNS protocols as deployed today rely on a server infrastructure that may not be present in a zeroconf environment. Host names used in zeroconf networks are inherently locally scoped whereas DNS names are global and unique by design. At the time of writing, consensus on how zeroconf name resolution protocols should interact with the DNS has not been reached. The next sections will attempt to capture the flavour of the different approaches that have proposed. Williams Expires March 19, 2003 [Page 11] Internet-Draft Zeroconf Requirements September 2002 3.2.2.1 Close coupling In this approach an application may look up a DNS name (e.g. "www.someco.com") using an existing API and receive and answer from a zeroconf name resolution protocol. The zeroconf name resolution protocol makes use of existing on-the-wire DNS formats, resource record definitions, and namespace. Some names may have a DNS suffix that identifies them as being local in scope. Issues yet to be resolved with this approach relate to security and consistency. If the zeroconf name resolution involves multicasting the request on a local network then the risk of spoofed responses to global DNS names like "www.someco.com" is increased. If the namespace is the same, then doing a zeroconf name lookup should return results consistent with DNS lookup for the same name. What is meant by this consistency is not agreed. Should the zeroconf lookup only be used when the DNS lookup has failed? Should that lookup reflect what would have been returned by the DNS? How should the probing for uniqueness of a zeroconf name relate to updating of a DNS record? 3.2.2.2 Completely orthogonal Another approach is to ensure that the zeroconf namespace and the DNS namespace are completely orthogonal. There is therefore no possibility of any application using the DNS via existing APIs behaving differently after a zeroconf name resolution protocol is deployed. Applications would need to explicitly use a zeroconf name lookup API in order to resolve names using a zeroconf lookup protocol. Conversely, existing applications will derive no benefit from zeroconf protocols unless they are re-written. Deployment of a zeroconf name resolution protocol would necessitate application upgrade. 3.2.2.3 API compatible In this approach the zeroconf namespace is distinct from the DNS namespace however zeroconf names may be resolved using an existing API. A number of operating systems use generalised name service interfaces that transparently allow a variety of name lookup protocols to be used to resolve hostnames for applications. A zeroconf name resolution protocol could be incorporated into such a system in a straightforward manner as just one more namespace and lookup protocol. Again, there is increased risk of spoofed responses if the multicast zeroconf name resolution protocol is used to resolve "www.someco.com". One possible way of minimising the security risk Williams Expires March 19, 2003 [Page 12] Internet-Draft Zeroconf Requirements September 2002 is to ensure that locally scoped names are distinguishable from DNS names, perhaps via a known reserved DNS suffix or by virtue of not containing a dot. A multicast zeroconf resolution protocol could then avoid making requests for names which look like global DNS names. Alternatively, we could require that zeroconf name lookups only be performed when the equivalent DNS lookup has failed. 3.3 IP Multicast Address Allocation Scenarios IP Multicast is used to conserve bandwidth for multi-receiver bulk- delivery applications, such as audio, video, or news. IP Multicast is also used to perform a logical addressing function. For example, when a host needs to communicate with local routers, it can send packets to the all-routers multicast address without having to know in advance the IP address(es) of the router(s). IPv4 multicast addresses range from 224.0.0.0 to 239.255.255.255. [RFC2365] defined multicast scopes are: node-local (unspecified for IPv4) link-local (224.0.0.0/24) local (239.255.0.0/16) site-local (unspecified for IPv4) organizational-local (239.192.0.0/14) global (224.0.1.0-238.255.255.255) A relative assignment is an integer offset from the highest address in the scope and represents a 32-bit address. For example, within the local scope, 239.255.255.0/24 is reserved for relative allocations. Source-Specific Multicast addresses are 232.0.0.0 to 232.255.255.255 [I-D.ietf-ssm-arch]. Unicast-prefix-based IPv6 multicast addresses are defined, as well as source-specific multicast addresses for IPv6[RFC3306]. Assumptions: o The node-local and SSM addresses require no protocol or interaction between multiple hosts, thus are not mentioned further in this document. o Global and organizational scoped addresses are meant for networks of a greater scale than zeroconf protocols, thus are not mentioned further in this document. Williams Expires March 19, 2003 [Page 13] Internet-Draft Zeroconf Requirements September 2002 o Only local, link-local and site-local scopes are considered further in this document. o If it is desirable to restrict multicast packets from entering and leaving a multicast scope boundary, it is assumed that the router at the boundary is a "boundary router" as described in [RFC2365]. Scenarios are scope enumeration, address allocation, and multiple sources. 3.3.1 Scope Enumeration Applications that leave the choice of scope up to the user require the ability to enumerate what scopes the host is operating within. In addition, services that are assigned relative addresses require the ability to enumerate what scopes the host is within; only then will a host be able to apply the relative address to a scope. Requirements: Application support software used to autoconfigure multicast addresses o MUST list which of the scopes (local, link-local, or site-local) are available for hosts. o MUST list per-scope address ranges that may be allocated. 3.3.2 Address Allocation IP multicast address allocation (local, link-local and site-local scopes only) requires an application to be able to request the use of a suitable multicast address. Coordination among applications must occur to avoid conflicting allocations of the same address. This coordination must span the entire scope respective to the address. When an allocated address is no longer required, that address MUST become available for use again. Requirements: A zeroconf multicast address allocation protocol o MUST select a multicast address. o MUST prevent conflicting allocations of the same address. o MUST allow the multicast address to become available after the address is no longer in use. Williams Expires March 19, 2003 [Page 14] Internet-Draft Zeroconf Requirements September 2002 3.3.3 Multiple Sources An intercom system inside a home is an example of a multiple source IP multicast application. In this type of application, several sources may be sending packets destined to the same IP multicast address. This multiple source example illustrates the problem that a particular address may continue to be valid, even after the host that initially allocated the address is no longer present; the zeroconf multicast address allocation must correctly support this type of operation. In other words, if a host allocates a multicast address, then leaves the multicast group, some other host must defend the address. Requirements: o A host other than the allocating host MUST be able to defend or otherwise maintain the allocation of a multicast address. 3.3.4 IPv6 Considerations To date, no range has been reserved for dynamic allocation of Link- scoped addresses in IPv4. Hence, unless such a range is reserved, dynamic allocation of link-scoped addresses applies only to IPv6. 3.4 Service Discovery Scenarios Service discovery protocols allow users or software to discover and select among available services. This removes the requirement that the user or client software know a server's location in advance in order for the client to communicate with the server. Terms: service: a particular logical function that may be invoked via some network protocol, such as printing, storing a file on a remote disk, or even perhaps requesting delivery of a pizza. service characteristics: Characteristics provide a finer granularity of description to differentiate services beyond just the service type. For example if the service type is printer, the characteristics may be color, pages printed per second, location, etc. service discovery protocol: A service discovery protocol enables clients to discover servers (or peers to find other peers) of a Williams Expires March 19, 2003 [Page 15] Internet-Draft Zeroconf Requirements September 2002 particular service. A service discovery protocol is an application layer protocol that relies on network and transport protocol layers. service protocol: A service protocol is used between the client and the server after service discovery is complete. The scenarios are the discovery of a simple printer service. 3.4.1 Printer Service Network-enabled printers allow various network clients to submit print jobs. A service discovery protocol MUST allow a printer service to be discovered by devices needing to print. This requires a service type as well as a service identifier to distinguish instances of a single service type. Service discovery MUST be independent from any particular printing protocol such as lpd, raw- tcp, ipp. Printers vary in their characteristics such as location, status, dots per inch, etc. Discovering a service based on these characteristics SHOULD be part of the service discovery protocol. Service discovery MUST complete in a timely (10s of seconds) manner. Requirements: o MUST allow a service to be discovered. o MUST discover via service identifier and/or service type. o MUST discover services without use of a service-specific protocol. o SHOULD discover via service characteristics. o MUST complete in a timely (10s of seconds) manner. 3.4.2 IPv6 Considerations Service discovery protocols have no zeroconf related differences for IPv4 and IPv6. 4. Security Considerations Zeroconf protocols are intended to operate in a local scope, in networks containing one or more IP subnets, and potentially in parallel with standard configured network protocols. Williams Expires March 19, 2003 [Page 16] Internet-Draft Zeroconf Requirements September 2002 Application protocols running on networks employing zeroconf protocols will be subject to the same sets of security issues identified for standard configured networks. Examples are: denial of service due to the unauthenticated nature of IPv4 ARP and lack of confidentiality unless IPSec-ESP, TLS, or similar is used. However, networks employing zeroconf protocols do have different security characteristics and the subsequent sections attempt to draw out some of the implications. Security schemes usually rely on some sort of configuration. Security mechanisms for zeroconf network protocols should be designed in keeping with the spirit of zeroconf, thus making it easy for the user to exchange keys, set policy, etc. It is preferable that a single security mechanism be employed that will allow simple configuration of all the various security parameters that may be required. Generally speaking, security mechanisms in IETF protocols are mandatory to implement. A particular implementation might permit a network administrator to turn off a particular security mechanism operationally. However, implementations should be "secure out of the box" and have a safe default configuration. Zeroconf protocols MUST NOT be any less secure than related current IETF-Standard protocols. This consideration overrides the goal of allowing systems to obtain configuration automatically. Security threats to be considered include both active attacks (e.g. denial of service) and passive attacks (e.g. eavesdropping). Protocols that require confidentiality and/or integrity should include integrated confidentiality and/or integrity mechanisms or should specify the use of existing standards-track security mechanisms (e.g. TLS [RFC2246], ESP [RFC1827], AH [RFC2402]) appropriate to the threat. 4.1 The Basic in/out Security Policy The claim/collide approach to resource allocation is attractive in the zeroconf environment. To operate securely, hosts allocating resources need to ensure that messages indicating that a network resource is in use are authenticated. Hosts soliciting for a name or service must also be able to authenticate the responses they receive. A message is considered "authenticated" if it can be proved to have been sent by a member of a group of devices running zeroconf protocols. Note that in general, devices running zeroconf protocols must trust the other devices in the group because any device may claim to be using an address or name, or advertising a service. Zeroconf security mechanisms must at a minimum be able to distinguish between messages originating from a device "inside" the group or a device "outside" the group. Williams Expires March 19, 2003 [Page 17] Internet-Draft Zeroconf Requirements September 2002 Requirement: o Security schemes for zeroconf protocols MUST be able to implement a basic "inside/outside" security policy. Access control mechanisms within a zeroconf network are beyond the scope of this document. 4.2 Security Scenarios In the next few sections, several scenarios are examined to highlight the security implications of employing zeroconf protocols in various environments. 4.2.1 Use on an isolated, secure network link In this scenario all the devices in the network are connected to a secure link (e.g. a control network in a car, or a private network between two devices used for configuration). The link might be a separate physical wire or shared media with layer-2 security enabled (e.g. wireless or power-line networks). Any host that has access to the link is trusted and any packet received from the secure link is considered to be authenticated. In this case, the inside/outside policy is implemented by controlling access to the link itself. 4.2.2 Use on a shared (insecure) link In this scenario, a group of devices use zeroconf protocols on link(s) they share with other devices who are NOT part of the group. Various pieces of network configuration MUST be consistent across all hosts sharing the link (e.g. addresses, netmask, routing information) in order for communication to occur at all. Consequently, hosts inside the group are potentially at risk from hosts outside their group when they try to configure such information (e.g. via ARP insecurity). Host names and service identifiers MUST be unique within a group, but with authentication may not need to be unique across the link. Assuming that requests and responses can be associated with a group and authenticated, solicitations and responses for host names and services that are not located inside the group can be ignored. 4.2.3 Use in conjunction with configured protocols Zeroconf protocols are likely to be used in conjunction with configured network protocols. In general, zeroconf protocols must not allocate resources from the same address or name spaces used by configured network protocols. Locally allocated zeroconf network resources must not mask global assigned resources. Williams Expires March 19, 2003 [Page 18] Internet-Draft Zeroconf Requirements September 2002 5. IANA Considerations No known IANA considerations arise from this document. 6. Acknowledgments Thanks to Peter Ford and Stuart Cheshire for hosting the NITS (Networking In The Small) BOF that was the catalyst to forming the Zeroconf Working Group. Thanks to Erik Guttman and Stuart Cheshire for forming and chairing the Zeroconf Working Group, which is responsible for this document. Thanks to Erik Guttman for providing key input to the service discovery and the security sections. Thanks to Dave Thaler for providing key input to the IP multicast address allocation sections. Thanks to Stuart Cheshire for providing key input to the introduction and IP interface configuration sections. Thanks to Myron Hattig for acting as editor for previous versions of this document. Additional recognition goes the following people for their influential contributions to this document and its predecessors: Brent Miller, Thomas Narten, Marcia Peters, Bill Woodcock, Bob Quinn, John Tavs, Matt Squire, Daniel Senie, Cuneyt Akinlar, Karl Auerbach, Kanchei Loa, Dongyan Wang, James Kempf, Yaron Goland, and Bernard Aboba, Ran Atkinson. Normative References Informative References [I-D.ietf-ssm-arch] Cain, B. and H. Holbrook, "Source-Specific Multicast for IP", draft-ietf-ssm-arch-00 (work in progress), February 2002. [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. Williams Expires March 19, 2003 [Page 19] Internet-Draft Zeroconf Requirements September 2002 [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC1827] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [RFC2535] Eastlake, D., "Domain Name System Security Williams Expires March 19, 2003 [Page 20] Internet-Draft Zeroconf Requirements September 2002 Extensions", RFC 2535, March 1999. [RFC2541] Eastlake, D., "DNS Security Operational Considerations", RFC 2541, March 1999. [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [RFC2730] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999. [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures ( SIG(0)s)", RFC 2931, September 2000. [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix- based IPv6 Multicast Addresses", RFC 3306, August 2002. Author's Address Aidan Williams Motorola Australian Research Centre Locked Bag 5028 Botany, NSW 1455 Australia Phone: +61 2 9666 0500 EMail: Aidan.Williams@motorola.com URI: http://www.motorola.com.au/marc/ Williams Expires March 19, 2003 [Page 21] Internet-Draft Zeroconf Requirements September 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Williams Expires March 19, 2003 [Page 22] --------------010704070006050909030209-- From owner-zeroconf@merit.edu Mon Sep 23 14:32:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19950 for ; Mon, 23 Sep 2002 14:32:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 26C77912A5; Mon, 23 Sep 2002 14:33:58 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E459A912A8; Mon, 23 Sep 2002 14:33:57 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BA077912A5 for ; Mon, 23 Sep 2002 14:33:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9D9165E00C; Mon, 23 Sep 2002 14:33:56 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 524C15DE17 for ; Mon, 23 Sep 2002 14:33:56 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8NIXr024229; Mon, 23 Sep 2002 14:33:53 -0400 (EDT) Message-Id: <200209231833.g8NIXr024229@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Aidan Williams Cc: zeroconf@merit.edu, Erik Nordmark , Thomas Narten , Erik Guttman , Stuart Cheshire Subject: Re: DNS/zeroconf name resolution co-existance text In-reply-to: (Your message of "Mon, 23 Sep 2002 16:34:21 +1000.") <3D8EB5ED.50205@motorola.com> Date: Mon, 23 Sep 2002 14:33:53 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk a couple of comments on DNS/zeroconf name resolution scenarios 1. having scenarios is fine but I don't think we should publish a requirements document without having consensus on requirements for each of those scenarios. if recent discussion has revealed that we don't have that consensus, maybe we need to do more work. 2. while it's certainly appropriate to mention the security aspect, spoofing of responses is not the only potential source of inconsistency between DNS and a zeroconf service - the scenario where DNS-connected hosts see a different set of RRs than those which are using zeroconf will arise entirely out of normal operation, with no malice or ill intent on anyone's part. Keith > 3.2.2 Relationship to the DNS > > Zeroconf name resolution protocols cannot be directly equated with > the DNS even though they may have a number of similarities. For > example, the DNS protocols as deployed today rely on a server > infrastructure that may not be present in a zeroconf environment. > Host names used in zeroconf networks are inherently locally scoped > whereas DNS names are global and unique by design. > > At the time of writing, consensus on how zeroconf name resolution > protocols should interact with the DNS has not been reached. The > next sections will attempt to capture the flavour of the different > approaches that have been proposed. > > 3.2.2.1 Close coupling > > In this approach an application may look up a DNS name (e.g. > "www.someco.com") using an existing API and receive and answer from a > zeroconf name resolution protocol. The zeroconf name resolution > protocol makes use of existing on-the-wire DNS formats, resource > record definitions, and namespace. Some names may have a DNS suffix > that identifies them as being local in scope. > > Issues yet to be resolved with this approach relate to security and > consistency. If the zeroconf name resolution involves multicasting > the request on a local network then the risk of spoofed responses to > global DNS names like "www.someco.com" is increased. If the > namespace is the same, then doing a zeroconf name lookup should > return results consistent with DNS lookup for the same name. What is > meant by this consistency is not agreed. Should the zeroconf lookup > only be used when the DNS lookup has failed? Should that lookup > reflect what would have been returned by the DNS? How should the > probing for uniqueness of a zeroconf name relate to updating of a DNS > record? > > 3.2.2.2 Completely orthogonal > > Another approach is to ensure that the zeroconf namespace and the DNS > namespace are completely orthogonal. There is therefore no > possibility of any application using the DNS via existing APIs > behaving differently after a zeroconf name resolution protocol is > deployed. Applications would need to explicitly use a zeroconf name > lookup API in order to resolve names using a zeroconf lookup > protocol. Conversely, existing applications will derive no benefit > from zeroconf protocols unless they are re-written. Deployment of a > zeroconf name resolution protocol would necessitate application > upgrade. > > 3.2.2.3 API compatible > > In this approach the zeroconf namespace is distinct from the DNS > namespace however zeroconf names may be resolved using an existing > API. A number of operating systems use generalised name service > interfaces that transparently allow a variety of name lookup > protocols to be used to resolve hostnames for applications. A > zeroconf name resolution protocol could be incorporated into such a > system in a straightforward manner as just one more namespace and > lookup protocol. > > Again, there is increased risk of spoofed responses if the multicast > zeroconf name resolution protocol is used to resolve > "www.someco.com". One possible way of minimising the security risk > is to ensure that locally scoped names are distinguishable from DNS > names, perhaps via a known reserved DNS suffix or by virtue of not > containing a dot. A multicast zeroconf resolution protocol could > then avoid making requests for names which look like global DNS > names. Alternatively, we could require that zeroconf name lookups > only be performed when the equivalent DNS lookup has failed. From owner-zeroconf@merit.edu Mon Sep 23 19:41:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29397 for ; Mon, 23 Sep 2002 19:41:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CF4B491253; Mon, 23 Sep 2002 19:42:47 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9AF2891283; Mon, 23 Sep 2002 19:42:47 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B1F6B91253 for ; Mon, 23 Sep 2002 19:42:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 947AB5E024; Mon, 23 Sep 2002 19:42:45 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 376C95DE39 for ; Mon, 23 Sep 2002 19:42:45 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8NNgh025548; Mon, 23 Sep 2002 19:42:43 -0400 (EDT) Message-Id: <200209232342.g8NNgh025548@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: iesg@ietf.org Subject: last call comments on draft-ietf-zeroconf-ipv4-linklocal-07 Cc: moore@cs.utk.edu, zeroconf@merit.edu From: Keith Moore Date: Mon, 23 Sep 2002 19:42:43 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk These are Last Call comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt They are being sent after the last call deadline because it's taken me that long to put them together in this form. I realize that much of this has been presented before in other forms, I hope that this presentation makes it clearer as to how the various concerns fit together. Unfortunately, I still haven't had time to put together comments on specific text in the document, but I will try to do that within the next few days. Keith 0. Introduction This proposal subtly changes the behavior of the Internet Protocol. As there is a tremendous investment in IP and a great many valuable and essential services depend on it, it seems prudent to examine in some detail the potential for this proposal to have an adverse effect on applications, hosts, or networks. Whereas for most candiates for standards track we are satisfied if the protocol has no _known_ technical omissions with respect to the requirements placed on it, for a candidate that affects the fundamental Internet Protocol it seems entirely appropriate to insist that there be _high_confidence_ that there are no such omissions. To put it a different way, for proposed changes to fundamental internet protocols there is an implicit requirement that the changes not be disruptive to existing uses of those fundamental protocols, to the operation of IP networks, or to the ability of IP-based networks to support a wide variety of current and future applications. This review is an attempt to analyze whether, under what conditions, and for what purposes, such confidence is justified. It identifies some areas where this level of confidence appears to be justified, and other areas where this level of confidence does not appear to be justified. By the word 'analyze' I mean a methodical technique which provides exhaustive coverage of scenarios which might cause failure. Formalism is not my strong suit, and I do not claim rigor for these arguments. I also realize that attempting to provide exhaustive coverage of potential problems requires at least some discussion of areas that are 'obviously' not problematic, which is tedious for readers as well as for the writer. However, it also forces consideration of potential problem areas that might have been previously ignored. Introduction of unicast link-local addressing into IPv4 has several broad effects which can be further analyzed for potential problems. In particular, - LL generates network traffic, and thus consumes resources, during both negotiation and use, - The introduction of LL addresses makes those addresses visible in some contexts, - Special considerations apply to use of LL addresses beyond those associated with "normal" IPv4 addresses, and to some degree even beyond those associated with "private" IPv4 addresses, and - The introduction of LL facilitates new communications paths. Indeed this is its entire purpose. From these broad classes the following questions are derived, which this document attempts to answer: - Can use of LL be avoided if it is found to cause problems? - Will the resources consumed by LL traffic cause problems for networks, hosts, or applications? - Will the visibility of LL addresses by networks, hosts, and applications cause problems for networks, hosts or applications? - Will the special considerations that apply to use of LL addresses cause problems for current or future applications? - Will the capability to send messages using LL addresses cause problems for networks, hosts, or applications? 0.1 Notation The arguments below are based on draft-ietf-zeroconf-ipv4-linklocal-07, which will be referred to as "the draft specification". For the sake of brevity the letters "LL" will be used to denote IPv4 unicast link-local addressing as defined in the draft specification. Use of "LL" is not intended to refer to broadcast link-local addressing or multicast link-local addressing, nor to IPv6 unicast link-local addressing. Note: While some of the problems identified here with LL also apply to IPv6 unicast link-local and/or site-local addressing, they are not the focus of this document. For instance, the impact of the late introduction of LL into IPv4 is different than the impact of having unicast link-local and site-local addressing as part of the original design of IPv6. While the comparison between the two cases is interesting, it would distract from the purpose of this document to consider the v4 and v6 cases separately. 1. Can use of LL be avoided if it is found to cause problems? 1.1 LL will be imposed on applications, hosts, and networks Several existing Apple and Microsoft platforms currently ship with a pre-standard version of this technology. Given the similarity of their implementations with the protocol described in this draft, and the affiliation of two of the draft authors, it seems reasonable to assume that these two vendors (at least) will implement a standard version of v4 LL if and when it is approved (or perhaps even in anticipation of approval). These two vendors supply operating system software for the vast majority of computing platforms in use today, especially 'desktop' and 'laptop' platforms. Therefore it seems likely that most 'desktop' and 'laptop' computers sold, and most operating system upgrades for such systems, will support the IETF v4 LL standard soon after it is adopted and for the next several years. Furthermore it also seems likely that, as new computers are added to existing IP networks, and as existing computers are replaced or upgraded to more recent opreating systems, IP networks and IP-based applications will be exposed to LL traffic without either the network operators or the users taking any action to enable it. According to the descriptions of existing implementations in the appendix of this document, several existing implementations do not attempt to claim and/or use LL addresses if and when a DHCP server responds to queries from the host. This provides a readily- available means of allowing a network to suppress use of LL addresses by these implementations. However this feature is specifically forbidden in the draft specification, and the draft specification provides no other mechanism with which use of LL addresses may be disabled by either a host or a network. (Note that while the claim-defend protocol provides a means to deny a host the ability to claim any particular LL address, it provides no means to discourage a host from attempting to claim other addresses, indefinitely, at a rate of up to one address per minute per host) Therefore, the draft specification would impose LL on existing hosts (as they are upgraded to later operating systems), applications, and networks, with little means of avoiding it or disabling it should it be found to have an adverse effect. 1.2 Conditions under which LL traffic will appear Since presumably LL will only affect applications, hosts, or networks if it is actually used, in order to understand whether LL can be avoided it is necessary to understand the conditions under which LL traffic will appear. a. Claim-defend protocol One kind of LL traffic consists of arp requests and replies that are used to claim and defend LL addresses. These are link-local broadcast packets, so they should reach every host on the local network. The claim-defend protocol will be invoked whenever a host wishes to allocate a link-local address. The draft specification seems to assume that this will happen at power-on or bootstrap time (after a random delay). Other implementations may be consistent with the letter of the draft specification. For instance, a host could allocate a link-local address whenever an application requested to send traffic to a link-local address, or whenever an application explicitly requested to listen for traffic on a link-local address. However such implementations would probably violate the stated intent of the draft specification to make link-local addresses "available all the time". Use of the claim-defend protocol continues as long as the LL address is "in use" by that host, though no definition of "in use" is given. While a particular platform might provide a nonstandard means to disable use of LL addresses, causing them to no longer be "in use" by the host, it seems consistent with the intent of this specification to assume that most hosts that implement this specification will claim a link-local address at power-on or bootstrap time, and defend or claim a new address on a link during any period that the host is operating and has access to the link. It is therefore assumed that the claim-defend protocol will unavoidably appear on any network to which LL-capable hosts are attached, and that in due time this will apply to essentially all IP-based networks. b. LL addresses used as IP source or destinations The other kind of LL traffic consists of IP packets with LL source and/or destination addresses. Such traffic will occur whenever a application sends traffic to an LL destination, or whenever an application on a host with only an LL address sends traffic to a routable destination. Most applications do not send unicast traffic to arbitrary hosts, or to all "known hosts", but only to specific hosts which they have reason to believe will contribute usefully to the purpose of the application. Therefore, most applications will send traffic to LL destinations only when those destinations are somehow exposed as being useful to that application. If LL addresses for those destinations are not exposed, they will not be used. Such exposure can occur via a variety of means: - explicit configuration by users or operators - a general-purpose service discovery protocol - a referral from another component of the application - a referral from a different application (for example, a file obtained by FTP can request that form data be sent via HTTP to a literal IP address) - being associated with the name of a host, service, or other resource that is declared to be useful (in DNS or another name lookup service) - from a host's network interface or ARP tables - from the source address of an IP datagram or connection - from network management protocols such as SNMP Some sources of LL address exposure, and thus some sources of LL use, are controllable. For instance, operators can be cautioned to eschew exposure of LL addresses in DNS, service discovery protocols, etc., and thereby to limit the use of LL addresses to some degree. However, application behavior varies widely. Some applications use the source addresses of IP datagrams as destinations of subsequent datagrams, or use such addresses in referrals to other components. (For instance, in a NATted environment the source address is more reliable than an address passed in the payload). Other applications provide referrals to other components using addresses obtained from interface tables. (For instance, to help the application to cope with limited-scope addresses by listing each of a host's addresses in referrals to other components of the application, allowing components to try multiple addresses until they find one that works.) Such applications will use LL addresses and generate LL traffic without being explicitly configured to do so. Thus it is not generally possible to insulate hosts, networks, or applications from LL merely by eshewing use of LL addresses in managed name lookup services, service discovery protocols, and application configuration. The degree to which LL addresses are used "accidentally" depends on the specific set of applications that are used on a particular network. This can be expected to vary considerably from one network to the next. 2. Will the resources consumed by LL traffic cause problems for networks, hosts, or applications? 2.1 Effects of LL resource consumption on network operations a. bandwidth consumption - unicast LL traffic Unicast LL traffic imposes no more overhead on the local network than unicast traffic to a local routable address. It is possible that introduction of LL will increase the amount of traffic on a network by facilitating new applications. We would generally consider this a sign of success, though the possibility exists that increased usage would cause short-term operational problems for networks that are nearly saturated. - broadcasts resulting from claim-defend protocol Under normal conditions (e.g. networks with <= 1000 hosts) LL claim-defend appears to generate approximately the same amount of traffic as would be generated by a normal use of ARP for duplicate address detection of a local routable address. - broadcasts resulting from normal ARP requests/replies (not claim/defend) One difference between ARP for LL and ARP for routable addresses is that ARP replies for LL addresses are broadcast where as normal ARP replies are unicast. In L2-switched networks this will consume bandwidth in portions of the network where unicast ARP replies did not. This is assumed to be a minor effect as long as the number of hosts on an L2 network is relatively small. The impact might become significant on large L2 switched networks. On a network with an average of 1000 active connections to unique (to a host) LL destinations, between hosts whose ARP caches time out in 20 minutes, this is an average of 1.67 broadcast packets / second. (counting both ARP requests and replies) This could result from 1000 hosts each with a single active connection to an LL address, or by 100 hosts each with active connections to ten different LL addresses. A network with 1000 hosts, each with 10 active connections to LL addresses, would generate 16.7 packets / second on average. Thus the maximum practical size of a network using LL might be somewhat smaller than the 1300 hosts cited in section 1.2 of the draft specification if a significant fraction of those hosts have active connections to LL destinations. It should be restated that this is only an issue for switched networks -- for "bus" networks (like classic Ethernet) the overhead _on the network_ (not on hosts) for broadcast packets is the same as that for unicast packets. Even for switched networks, LL ARP request/replies are only twice as many broadcast packets as LL requests on "bus" Ethernets. b. network availability / reliablity / stability LL does not appear to affect network availability or reliability as long as the additional traffic does not cause the network to become saturated. 2.2 Effects of LL resource consumption on hosts a. Hosts which implement LL Hosts which implement LL can reasonably be expected to cope with the amount and type of traffic generated by LL on a reasonably-sized network. The network code on such hosts will presumably have been implemented with LL in mind and tested in an LL environment. b. Other hosts Hosts which do not implement LL can still be expected to implement ARP on interfaces that require it, and for the most part LL usage is consistent with ARP. There is some chance that platforms which do not implement LL might be confused by LL's requirement that LL ARP replies be sent using link-layer broadcast instead of link-layer unicast (draft spec, bottom page 11). A correct implementation of RFC 826 would not be confused, as it would only process response for which the answer to the question "Am I the target protocol address?" (from the ARP response payload, not the Ethernet header) were "yes". c. All hosts The need to process additional broadcast packets generated by LL ARP replies may result in increased overhead for all hosts, and in increased hardware costs for new hosts to permit them to handle an increase in interrupts needed to broadcast packets, even if they are promptly discarded. This seems unlikely to significantly affect general-purpose hosts (desktops, laptops, servers) but may affect "appliance" or "fixed-function" hosts (especially those designed for the consumer market), which which operate with less margin in CPU cycles. 2.3 Effect of LL resource consumption on applications In general, an application should consume no more resources for LL traffic than for traffic between routable unicast addresses. However, if an application naively responds to LL traffic in a situation where use of LL will cause the application to fail, and that application persists in trying to use LL, the application's performance may be adversely impacted. 3. Will the visibility of LL addresses by networks, hosts, and applications, cause problems for networks, hosts, or applications? 3.1 Effects of LL visibility on networks Since LL addresses are not tightly bound to hosts, there is no association of host identity with LL address, it becomes necessary for traffic monitors to associate hosts with layer 2 addresses rather than layer 3 addresses, even if they are monitoring layer 3 traffic. With the introduction of LL, DNS cannot be used to provide reliable address-to-name mapping even on networks where it might be reliable for routable addresses (e.g. when DHCP and DNS are coordinated). 3.2 Effects of LL visibility on hosts The effects of LL visibility on hosts appear to be reasonably well covered in the draft specification. 3.3 Effects of LL visibility on applications As implied earlier, when LL addresses become visible to apps (e.g. via interface or ARP tables) they will then be used by some apps that use addresses in referrals to other apps. a. address scope problems due to referrals Because LL address-to-host bindings are only valid on a particular link, when applications use LL IP addresses in referrals to other applications (or other components of the same application) those referrals may fail when those IP addresses are not valid for the host that received those addresses. b. address stability problems with referrals Because LL address-to-host bindings are only valid on a particular link, applications which use LL IP addresses in referrals to or from other applications may fail when those IP addresses are no longer bound to the same host as when the referral was generated, even if the host which received the referral has access to the same network link for which the LL address was valid. 4. Will the special considerations that apply to use of LL addresses cause problems for current or future applications? a. address scope problems with multiple intefaces Because LL address-to-host bindings are only valid on a particular link, applications on hosts that have multiple interfaces supporting LL may be unable to connect to LL IP addresses, or may find certain LL addresses ambiguous. Allowing an application to select a source interface does not solve the problem, since existing applications will not know how to do this, and even new applications will rarely be aware of which interface is associated with which address. b. non-uniqueness of addresses Because LL addresses are not unique, applications which use IP addresses as unique tokens may fail. Some will say that private addresses and NATs have already caused this problem, and that applications can no longer depend on addresses being unique. This is an over-generalization that applies only to mass-market apps. Despite the existence and wide deployment of NATs, there are still many cases where some degree of address uniqueness is a reasonable assumption, and for which LL would cause that assumption to fail. For instance, applications used only within a local network can often assume that addresses of other hosts in that are uniquely assigned to those hosts. While a network can choose how it uses private address space and how it configures NATs, it will have little choice about the imposition of LL. c. address stability effect on connection duration Because LL address-to-host bindings are subject to (occasional) change without notice, applications may fail when their hosts' addresses change. It is not always feasible or even possible for applications to recover from such failures. For instance: - TCP lacks the ability to survive an address change of either endpoint, so applications cannot count on lower layers to effect recovery. - Few applications protocols have explicit application-level acknowledgements or checkpoint/restart procedures which allow them to recover from broken connections in mid-session, so the entire session must be restarted. - In some cases the IP address is the only usable name by which an application component can communicate with a peer. When the address is invalidated the peer can no longer be reached. Some will claim that DHCP already allows addresses to be unstable. This is an overgeneralization because DHCP is optional, because DHCP is often configured in a way which allows addresses to be moderately stable (by assigning long lease times, indefinitely renewing leases, and/or binding L3 addresses to L2 addresses). A network can choose which DHCP servers to use and how to configure them, but it has little choice about the imposition of LL. 5. Will the capability to send messages using LL addresses cause problems for networks, hosts, or applications? a. security problems LL facilitates communications between hosts under circumstances, and over paths, which did not previously permit communication. In the case of wireless links the introduction of LL can cause purely "accidental" communications paths to be established, as hosts with wireless links can connect to one another in the absence of any explicit effort by users or administrators to facilitate such communications (and despite efforts to limit such communications). This introduces new risks for both networks and hosts, especially networks and hosts that rely (as most do) on the ability to do some kind of ingress filtering as part of their security implementation. Consider the following example scenario: --------------------------+ +-------------------------- company A meatspace | | company B meatspace | | company A | | company B network | | network / | wall | \ / +--------+ | | +--------+ \ ==========| laptop |]~~~~~~~~~~~~~~~~~~[| laptop |========= +--------+ | ^ | +--------+ | | | | | | --------------------------+ | +-------------------------- | covert LL wireless channel Company A and company B maintain separate networks. Each has its own policy for what kinds of traffic to permit on those network, and each company's network policy is implemented using a firewall. However if the laptops have (presumably built-in) wireless interfaces supporting LL, a covert channel may exist between machines on the different networks. This situation can exist anytime the laptops allow "ad hoc" operation on their wireless interfaces. It has several implications: - Existing firewalls are bypassed, so existing threat countermeasures are circumvented. Granted, it's a bad idea to completely rely on firewalls since many threats are internal, but the reality is that this is currently both conventional wisdom and common practice. - Company A is implicitly trusting company B's firewall (and the security of company B's hosts) and vice versa. - Company A's hosts can attack company B's hosts, and vice versa. Note that a single compromised host can serve as a platform from which other attacks can be launched. Even if A does not attack B or vice versa, a successful attack on a host on either network may facilitate a (presumably easier) attack on the other network. It is not difficult to see how a worm or virus could propagate using LL covert channels. Another scenario is similar -- a nomadic laptop which connects to various ad hoc LL networks as it moves potentially exposes the laptop to new security threats in each new network. A laptop which was compromised using LL may then be used to attack a company's private network when it is connected to that network. b. support issues In addition to difficulty of traffic monitoring, introduction of LL may cause application failures which are difficult to isolate, diagnose, or fix. This causes issues for those who support networks and network-based applications. 6. Summary - If the draft specification is implemented in its current form, it is impractical to avoid imposition of LL on networks, hosts and applications using current measures. - LL seems unlikely to cause resource depletion for most networks. However it may cause resource depletion in nearly-saturated networks and large L2-switched networks. Some limited function hosts may not be able to cope with additional CPU load due to additional broadcast packets on large networks. Applications which are incompatible with LL and which use LL "accidentally" may cause additional consumption of network resources if they persistently retry operations that failed due to LL. - For various reasons, some applications are incompatible with LL. Some of these applications will fail if configured to use an LL address or a name that binds to an LL address. Others will fail when LL is introduced merely because those LL addresses are visible via interface or ARP tables, and/or because they will begin to see traffic from LL addresses. - Imposition of LL circumvents existing security mechanisms and creates additional security risks for networks, hosts, and applications. - Imposition of LL creates new support burdens for users, networks, and application maintainers. 7. Recommendations - There needs to be a standard way for managed networks to disable LL traffic, both on the network and on hosts connected to that network. One way to do this that preserves the ability of LL and DHCP-assigned addresses to coexist would be to design a different response to the claim-defend protocol that disables LL, and which LL hosts were required to honor as a matter of standards compliance. Another way to do this would be to define a DHCP "disable LL" option. Either would provide a means of allowing networks to avoid security problems associated with LL and/or to avoid impact on existing applications which do not work well in the presence of LL. - As a matter of standards compliance, hosts need to be required to provide a means to disable LL traffic, both entirely and on a per-interface basis. - Because there are valid reasons to disable LL, and for other reasons, the specification should discourage the expectation that a host that implements only LL can expect to communicate with other IP hosts, even those on the same network segment. Hosts should implement DHCP and/or support static address configuration if they wish to have the capability to communicate with other hosts using IP. - Even when LL is enabled on a host or an interface, there needs to be a way of isolating existing applications from LL traffic and from the visibility of LL addresses. - LL should be disabled by default on wireless interfaces, requiring explicit configuration of such interfaces to support LL. Enabling the wireless interface to support LL on a specific wireless network should be separate from enabling a wireless interface to support LL on an ad hoc network. - When wireless interfaces are allowed to use LL on ad hoc networks (as opposed to configured wireless networks), there should be a means to prevent applications from being exposed to traffic from such networks, so the host will accept traffic only for those applications that are believed to be safe from arbitrary, anonymous traffic. - More study is needed before the security implications of LL can be fully understood. LL should not be deployed until those implications are understood and suitable countermeasures exist. In addition to these major changes, other specific changes to the draft specification are also desirable. But this review is already long enough. 8. Conclusions LL is potentially a very useful technology, and there are compelling reasons to deploy it. However if deployed in the form specified in the draft specification, it will break some applications, invite new kinds of attack on hosts and networks, and create new means of propagating viruses. I do not believe that the current draft specification meets either explicit or implicit requirements for Proposed Standard status. From owner-zeroconf@merit.edu Mon Sep 23 22:02:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03611 for ; Mon, 23 Sep 2002 22:02:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A707A9128E; Mon, 23 Sep 2002 22:04:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 748BB9128F; Mon, 23 Sep 2002 22:04:16 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 39F9E9128E for ; Mon, 23 Sep 2002 22:04:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0273D5E041; Mon, 23 Sep 2002 22:04:15 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id AC47A5E03E for ; Mon, 23 Sep 2002 22:04:12 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g8O24Bh29221 for ; Mon, 23 Sep 2002 19:04:11 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 23 Sep 2002 19:04:05 -0700 Received: from apple.com (vpn-gh-599.apple.com [17.254.138.86]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g8O245304522; Mon, 23 Sep 2002 19:04:05 -0700 (PDT) Date: Tue, 24 Sep 2002 10:03:26 +0800 Subject: Re: last call comments on draft-ietf-zeroconf-ipv4-linklocal-07 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: iesg@ietf.org, zeroconf@merit.edu To: Keith Moore From: Joshua Graessley In-Reply-To: <200209232342.g8NNgh025548@astro.cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Keith, a good analysis. My comments follow. On Tuesday, September 24, 2002, at 07:42 AM, Keith Moore wrote: > 2.3 Effect of LL resource consumption on applications > > In general, an application should consume no more resources > for LL traffic than for traffic between routable unicast addresses. > However, if an application naively responds to LL traffic in a > situation where use of LL will cause the application to fail, > and that application persists in trying to use LL, the application's > performance may be adversely impacted. The same could be said of any IPv4 address where connectivity is impossible. A similar scenario occurs with firewalls and FTP where an FTP client may connect to a server and send it's IP address. The server may be unable to establish a connection back to the client due to a firewall. Applications should already gracefully handle cases where acquire an address that they can not reach. > 5. Will the capability to send messages using LL addresses cause > problems for networks, hosts, or applications? > > a. security problems > > LL facilitates communications between hosts under circumstances, > and over paths, which did not previously permit communication. > In the case of wireless links the introduction of LL can cause > purely "accidental" communications paths to be established, > as hosts with wireless links can connect to one another in the > absence of any explicit effort by users or administrators to > facilitate such communications (and despite efforts to limit > such communications). This introduces new risks for both > networks > and hosts, especially networks and hosts that rely (as most do) > on the ability to do some kind of ingress filtering as part of > their security implementation. > > Consider the following example scenario: > > > --------------------------+ +-------------------------- > company A meatspace | | company B meatspace > | | > company A | | company B > network | | network > / | wall | \ > / +--------+ | | +--------+ \ > ==========| laptop |]~~~~~~~~~~~~~~~~~~[| laptop |========= > +--------+ | ^ | +--------+ > | | | > | | | > --------------------------+ | +-------------------------- > | > covert LL wireless channel > > Company A and company B maintain separate networks. Each > has its own policy for what kinds of traffic to permit on > those network, and each company's network policy is implemented > using a firewall. However if the laptops have (presumably > built-in) wireless interfaces supporting LL, a covert channel > may exist between machines on the different networks. This > situation can exist anytime the laptops allow "ad hoc" operation > on their wireless interfaces. It has several implications: > > - Existing firewalls are bypassed, so existing threat > countermeasures are circumvented. Granted, it's a bad idea to > completely rely on firewalls since many threats are internal, > but the reality is that this is currently both conventional > wisdom and common practice. > > - Company A is implicitly trusting company B's firewall (and the > security of company B's hosts) and vice versa. > > - Company A's hosts can attack company B's hosts, and vice versa. > > Note that a single compromised host can serve as a platform from > which other attacks can be launched. Even if A does not attack > B or vice versa, a successful attack on a host on either network > may facilitate a (presumably easier) attack on the other network. > It is not difficult to see how a worm or virus could propagate > using LL covert channels. > > Another scenario is similar -- a nomadic laptop which > connects to various ad hoc LL networks as it moves potentially > exposes the laptop to new security threats in each new network. > A laptop which was compromised using LL may then be used to > attack a company's private network when it is connected to > that network. In this example, if 802.11 is used, one of the two clients would need to be setup as an access point and the other client would need to be configured to connect to the access point. This requires some configuration. If the laptop in company B was trying to be malicious and attack the laptop in company A, the laptop in company B would need to be configured as an access point and the laptop on company A would need to somehow automatically pick company B's laptop as the access point to which it would connect. Since company B's laptop would need to be configured as an access point, there is no reason it could not also be configured as a DHCP server. Link local addressing has no effect on the insecurity of wireless networks. > 7. Recommendations > > - There needs to be a standard way for managed networks to disable > LL > traffic, both on the network and on hosts connected to that > network. > > One way to do this that preserves the ability of LL and > DHCP-assigned > addresses to coexist would be to design a different response to > the > claim-defend protocol that disables LL, and which LL hosts were > required to honor as a matter of standards compliance. Another > way > to do this would be to define a DHCP "disable LL" option. > Either would provide a means of allowing networks to avoid > security > problems associated with LL and/or to avoid impact on existing > applications which do not work well in the presence of LL. Most cable modem companies use DHCP to assign addresses and they will only assign one address per household (unless a tax is paid to the ISP for extra IP addresses). If I have a printer and a few other IP devices at home that don't need connectivity to the internet, LL would serve me well for communicating with those other devices. If my ISP has an easy way to disable LL so they could charge me more, I have no doubt they would make use of it. > 8. Conclusions > > LL is potentially a very useful technology, and there are compelling > reasons to deploy it. However if deployed in the form specified in > the draft specification, it will break some applications, invite > new kinds of attack on hosts and networks, and create new means > of propagating viruses. You do point out a few situations where applications may break due to link local, very similar to the way that private address ranges can break network applications. LL does not "invite new kinds of attacks on hosts and networks", nor does it "create new means of propagating viruses". Your wireless example of how LL could supposedly be used to compromise security is bogus. The use of LL addresses makes no difference, since an attacker could simply use DHCP to assign addresses. In addition, the victim would have to join the attackers network by selecting his access point. -josh From owner-zeroconf@merit.edu Mon Sep 23 23:03:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05303 for ; Mon, 23 Sep 2002 23:03:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 18F2D91293; Mon, 23 Sep 2002 23:05:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DCB2691298; Mon, 23 Sep 2002 23:05:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9014391293 for ; Mon, 23 Sep 2002 23:05:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 77BB95E05E; Mon, 23 Sep 2002 23:05:16 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 220F15DF17 for ; Mon, 23 Sep 2002 23:05:16 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8O35B026343; Mon, 23 Sep 2002 23:05:11 -0400 (EDT) Message-Id: <200209240305.g8O35B026343@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Keith Moore , iesg@ietf.org, zeroconf@merit.edu Subject: Re: last call comments on draft-ietf-zeroconf-ipv4-linklocal-07 In-reply-to: (Your message of "Tue, 24 Sep 2002 10:03:26 +0800.") Date: Mon, 23 Sep 2002 23:05:11 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > Keith, a good analysis. My comments follow. > > On Tuesday, September 24, 2002, at 07:42 AM, Keith Moore wrote: > > > 2.3 Effect of LL resource consumption on applications > > > > In general, an application should consume no more resources > > for LL traffic than for traffic between routable unicast addresses. > > However, if an application naively responds to LL traffic in a > > situation where use of LL will cause the application to fail, > > and that application persists in trying to use LL, the application's > > performance may be adversely impacted. > > The same could be said of any IPv4 address where connectivity is > impossible. A similar scenario occurs with firewalls and FTP where an > FTP client may connect to a server and send it's IP address. The server > may be unable to establish a connection back to the client due to a > firewall. indeed, this can happen for other reasons, as you suggest. however these are artifacts of the local network configuration (i.e. the network administrator has a choice of whether to do off-site FTP) and they are implemented as a matter of security policy. this is in contrast to LL where the failures are not the result of choices made by the network administrator and are not > Applications should already gracefully handle cases where > acquire an address that they can not reach. perhaps, but the application has no way of knowing whether the address is permanently unreachable or temporarily unreachable. email typically retries once every 30-60 minutes for several days before giving up. would you call that graceful handling or too much resource consumption? I should say that I don't see this particular case as an extremely likely scenario - it was just something I noticed while trying to list possible reasons for failure caused by LL resource consumption. > > 5. Will the capability to send messages using LL addresses cause > > problems for networks, hosts, or applications? > > > > a. security problems > > > > LL facilitates communications between hosts under circumstances, > > and over paths, which did not previously permit communication. > > In the case of wireless links the introduction of LL can cause > > purely "accidental" communications paths to be established, > > as hosts with wireless links can connect to one another in the > > absence of any explicit effort by users or administrators to > > facilitate such communications (and despite efforts to limit > > such communications). This introduces new risks for both > > networks > > and hosts, especially networks and hosts that rely (as most do) > > on the ability to do some kind of ingress filtering as part of > > their security implementation. > > > > Consider the following example scenario: > > > > > > --------------------------+ +-------------------------- > > company A meatspace | | company B meatspace > > | | > > company A | | company B > > network | | network > > / | wall | \ > > / +--------+ | | +--------+ \ > > ==========| laptop |]~~~~~~~~~~~~~~~~~~[| laptop |========= > > +--------+ | ^ | +--------+ > > | | | > > | | | > > --------------------------+ | +-------------------------- > > | > > covert LL wireless channel > > > > Company A and company B maintain separate networks. Each > > has its own policy for what kinds of traffic to permit on > > those network, and each company's network policy is implemented > > using a firewall. However if the laptops have (presumably > > built-in) wireless interfaces supporting LL, a covert channel > > may exist between machines on the different networks. This > > situation can exist anytime the laptops allow "ad hoc" operation > > on their wireless interfaces. It has several implications: > > > > - Existing firewalls are bypassed, so existing threat > > countermeasures are circumvented. Granted, it's a bad idea to > > completely rely on firewalls since many threats are internal, > > but the reality is that this is currently both conventional > > wisdom and common practice. > > > > - Company A is implicitly trusting company B's firewall (and the > > security of company B's hosts) and vice versa. > > > > - Company A's hosts can attack company B's hosts, and vice versa. > > > > Note that a single compromised host can serve as a platform from > > which other attacks can be launched. Even if A does not attack > > B or vice versa, a successful attack on a host on either network > > may facilitate a (presumably easier) attack on the other network. > > It is not difficult to see how a worm or virus could propagate > > using LL covert channels. > > > > Another scenario is similar -- a nomadic laptop which > > connects to various ad hoc LL networks as it moves potentially > > exposes the laptop to new security threats in each new network. > > A laptop which was compromised using LL may then be used to > > attack a company's private network when it is connected to > > that network. > > In this example, if 802.11 is used, one of the two clients would need > to be setup as an access point and the other client would need to be > configured to connect to the access point. This requires some > configuration. If the laptop in company B was trying to be malicious > and attack the laptop in company A, the laptop in company B would need > to be configured as an access point and the laptop on company A would > need to somehow automatically pick company B's laptop as the access > point to which it would connect. Since company B's laptop would need to > be configured as an access point, there is no reason it could not also > be configured as a DHCP server. Link local addressing has no effect on > the insecurity of wireless networks. - 802.11 is not the only wireless technology - another scenario is that two laptops automatically connect to a neutral access point - I considered the DHCP scenario also. But there's a subtle difference between accidental covert channels and deliberate covert channels such as might be set up with DHCP. - Also, the existence of a flaw in DHCP does not justify having a similar flaw in LL. And host support for DHCP can generally be turned off. > > > 7. Recommendations > > > > - There needs to be a standard way for managed networks to disable > > LL > > traffic, both on the network and on hosts connected to that > > network. > > > > One way to do this that preserves the ability of LL and > > DHCP-assigned > > addresses to coexist would be to design a different response to > > the > > claim-defend protocol that disables LL, and which LL hosts were > > required to honor as a matter of standards compliance. Another > > way > > to do this would be to define a DHCP "disable LL" option. > > Either would provide a means of allowing networks to avoid > > security > > problems associated with LL and/or to avoid impact on existing > > applications which do not work well in the presence of LL. > > Most cable modem companies use DHCP to assign addresses and they will > only assign one address per household (unless a tax is paid to the ISP > for extra IP addresses). If I have a printer and a few other IP devices > at home that don't need connectivity to the internet, LL would serve me > well for communicating with those other devices. If my ISP has an easy > way to disable LL so they could charge me more, I have no doubt they > would make use of it. well, it's a good point to make that the network owner doesn't necessarily control the DHCP server. (really unfortunate that we don't have a well-defined boundary between what the ISP is responsible for and what the customer is responsible for, but zeroconf can't solve that). so perhaps the DHCP option isn't the best idea. but something is needed. > > 8. Conclusions > > > > LL is potentially a very useful technology, and there are compelling > > reasons to deploy it. However if deployed in the form specified in > > the draft specification, it will break some applications, invite > > new kinds of attack on hosts and networks, and create new means > > of propagating viruses. > > You do point out a few situations where applications may break due to > link local, very similar to the way that private address ranges can > break network applications. LL does not "invite new kinds of attacks on > hosts and networks", nor does it "create new means of propagating > viruses". Your wireless example of how LL could supposedly be used to > compromise security is bogus. The use of LL addresses makes no > difference, since an attacker could simply use DHCP to assign > addresses. In addition, the victim would have to join the attackers > network by selecting his access point. reread the example again. the assumption is not that either A or B is actively trying to compromise the other - it's that the existence of an unwanted "zero configuration" channel between A and B provides a new path by which attacks can be mounted by a third party. and again, the existence of a flaw in DHCP does not justify a flaw in LL. Keith From owner-zeroconf@merit.edu Mon Sep 23 23:07:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05386 for ; Mon, 23 Sep 2002 23:07:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B101D91298; Mon, 23 Sep 2002 23:09:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8086B9129C; Mon, 23 Sep 2002 23:09:04 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76AFF91298 for ; Mon, 23 Sep 2002 23:09:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 595395E05F; Mon, 23 Sep 2002 23:09:03 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by segue.merit.edu (Postfix) with ESMTP id 400245E05D for ; Mon, 23 Sep 2002 23:09:03 -0400 (EDT) Received: from repligate ([67.37.178.198]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020924030902.FPLQ1118.mailhost.chi1.ameritech.net@repligate>; Mon, 23 Sep 2002 22:09:02 -0500 Message-ID: <110001c26377$c4d55ad0$c6b22543@repligate> From: "Jim Fleming" To: "Joshua Graessley" Cc: , References: Subject: "...unless a tax is paid to the ISP..." Date: Mon, 23 Sep 2002 22:09:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Joshua Graessley" > > Most cable modem companies use DHCP to assign addresses and they will > only assign one address per household (unless a tax is paid to the ISP > for extra IP addresses). Are you opposed to paying the I* society $1 per year per domain name (even 3rd level ones) ? Are you opposed to paying $10 per month for one static 32-bit IP address ? If so... How are all of the insiders going to pay for all of their world travel, and the other parties and .ORGies that they have planned ? There are people lining up to get one of those $250,000 per year patronage jobs watching the paint dry. They need more money from you to pay them. How will they fund all of the people needed to make sure Africa gets plenty of IP addresses ? Do you see any /8 allocations here for Africa ?...yet... http://www.iana.org/assignments/ipv4-address-space http://www.washingtonpost.com/wp-dyn/articles/A43976-2002Sep20.html "Victory, who heads Commerce's National Telecommunications and Information Administration (NTIA), is on her way today to an International Telecommunications Union meeting in Marrakech, Morocco, and was not available for comment." ===== What about all of the parties in Latin America in March 2003 ?...it is Winter in the U.S. time for some fun in the sun. http://www.icann.org/calendar.htm March 2003 ICANN Meetings TBD (in Latin America) http://lacnic.net/en/transition.html Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer... http://www.netfilter.org/ http://www.analogx.com/contents/dnsdig.htm http://ipv8.dyndns.tv http://ipv8.yi.org http://ipv8.dyns.cx http://ipv8.no-ip.com http://ipv8.no-ip.org http://ipv8.no-ip.biz http://ipv8.no-ip.info http://ipv8.myip.us http://ipv8.dyn.ee http://ipv8.community.net.au http://ipv8.ods.org From owner-zeroconf@merit.edu Mon Sep 23 23:28:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05795 for ; Mon, 23 Sep 2002 23:28:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A2B39129C; Mon, 23 Sep 2002 23:29:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25A8A9129D; Mon, 23 Sep 2002 23:29:41 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0BD219129C for ; Mon, 23 Sep 2002 23:29:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DC9815E062; Mon, 23 Sep 2002 23:29:39 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 665355DE2E for ; Mon, 23 Sep 2002 23:29:39 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8O3TY026749; Mon, 23 Sep 2002 23:29:34 -0400 (EDT) Message-Id: <200209240329.g8O3TY026749@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Keith Moore , iesg@ietf.org, zeroconf@merit.edu Subject: Re: last call comments on draft-ietf-zeroconf-ipv4-linklocal-07 In-reply-to: (Your message of "Tue, 24 Sep 2002 10:03:26 +0800.") Date: Mon, 23 Sep 2002 23:29:34 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk Josh, another followup, after some more thought: > You do point out a few situations where applications may break due to > link local, very similar to the way that private address ranges can > break network applications. LL does not "invite new kinds of attacks on > hosts and networks", nor does it "create new means of propagating > viruses". Your wireless example of how LL could supposedly be used to > compromise security is bogus. The use of LL addresses makes no > difference, since an attacker could simply use DHCP to assign > addresses. In addition, the victim would have to join the attackers > network by selecting his access point. On reflection I agree that unqualified "invites new kinds of attacks on hosts and networks" and "creates new means of propagating viruses" may be a bit strong - or at least aren't justified by the text. And yet I think that there is something to the wireless example. It should hardly be a surprise that if hosts automatically configure themselves to a wireless network ("zero configuration", remember?) that this would create commmunications paths that could be used for attacks, no matter what means was used to allocate IP addresses for those hosts. automatic L2 configuration is possible for 802.11, and some consider it advantageous. For this specific problem the fix may be as simple as saying "don't automatically run LL on any wireless interface that's not explicitly configured" - which I hope would not cause either the WG or vendors much grief. I think there would still be a need for a way to disable LL on a host or network, for other reasons mentioned in the review. Keith From owner-zeroconf@merit.edu Tue Sep 24 10:16:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28794 for ; Tue, 24 Sep 2002 10:16:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D38891213; Tue, 24 Sep 2002 10:18:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B06891238; Tue, 24 Sep 2002 10:18:31 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 24C3391213 for ; Tue, 24 Sep 2002 10:18:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F34715DF2E; Tue, 24 Sep 2002 10:18:28 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 52C895DDB3 for ; Tue, 24 Sep 2002 10:18:28 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01062; Tue, 24 Sep 2002 07:18:22 -0700 (PDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8OEIJl12677; Tue, 24 Sep 2002 16:18:19 +0200 (MEST) Date: Tue, 24 Sep 2002 16:18:19 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: iesg@ietf.org, zeroconf@merit.edu Cc: Keith Moore , Erik Guttman Subject: Re: last call comments on draft-ietf-zeroconf-ipv4-linklocal-07 In-Reply-To: <200209232342.g8NNgh025548@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Working group members, esteemed IESG members, I want to point out that this (late) review is the second such response to an IETF last call. Indeed, the only reason for the second last call is the difficult long process in responsing to Keith's previous set of issues. It is also important to note that this protocol has been widely deployed for some time and the document has received wide and extensive peer review. In summary of the points I make below, I argue that Keith has a number of points where he disagrees with the output of the ZEROCONF WG. This is acceptable, as the criteria for advancing a specification on the standards track is rough consenses not total agreement. None of Keith's points, whether newly made in this set of comments, or repeated from his previous last call comments, merit holding the specification back from being advanced. I apologize for the length of this response. I wanted to be entirely clear that I no point Keith brings up is neglected. I omit details of Keith's comments when my response covers an entire section. I strongly urge the IESG to proceed to ballot upon the v4LL and to advance the specification as it currently reads. ------------------------------------------------------------------ With all due respect, I consider Keith's points to either (a) be unsubstantive (b) cover ground which has been covered before (c) pose unreasonable requirements to place on a standards track protocol where the burden of proof is never to prove that no harm could be done (d) be repudiated by experience with Appletalk and Netbios (e) be repudiated by experience with v4 LL autoconfiguration since 1998 (f) (and in several cases) incorrectly state, exaggerate or mistakenly assert features of the protocol I elide text which is not substantive (introduction or exposition). On Mon, 23 Sep 2002, Keith Moore wrote: > These are Last Call comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt > > 0. Introduction > > This proposal subtly changes the behavior of the Internet Protocol. This is true. There are rules for how datagrams are sent and received which differ from established practice and standards. > Whereas for most > candiates for standards track we are satisfied if the protocol has no > _known_ technical omissions with respect to the requirements placed on it, > for a candidate that affects the fundamental Internet Protocol it seems > entirely appropriate to insist that there be _high_confidence_ > that there are no such omissions. To put it a different way, for > proposed changes to fundamental internet protocols there is an > implicit requirement that the changes not be disruptive to > existing uses of those fundamental protocols, to the operation > of IP networks, or to the ability of IP-based networks to support > a wide variety of current and future applications. This is an unreasonable requirement. Link local IP is on by default in a significant percentage of internet hosts and has not proven disruptive. - - - - - - - Keith's outline of issues follows. The outline of my responses is interjected. [...] > Introduction of unicast link-local addressing into IPv4 has several > broad effects which can be further analyzed for potential problems. > In particular, > > - LL generates network traffic, and thus consumes resources, > during both negotiation and use, This question has been debated at length in the WG and is therefore inappropriate in the WG last call. > - The introduction of LL addresses makes those addresses > visible in some contexts, This question was brought up in the previous last call and we have WG consenses that there are sufficient caveats in the document in response to the risks. It is clear Keith disagrees, but this is a rehashing of the same issue which is settled, as far as the working group is concerned. > - Special considerations apply to use of LL addresses beyond > those associated with "normal" IPv4 addresses, and to some > degree even beyond those associated with "private" IPv4 > addresses, and This is true, but all these aspects are dealt with clearly in the specification. > - The introduction of LL facilitates new communications paths. > Indeed this is its entire purpose. > > From these broad classes the following questions are derived, > which this document attempts to answer: > > - Can use of LL be avoided if it is found to cause problems? The specification considers how to use LL not how to avoid it. > - Will the resources consumed by LL traffic cause problems for > networks, hosts, or applications? No. > - Will the visibility of LL addresses by networks, hosts, and > applications cause problems for networks, hosts or applications? > > - Will the special considerations that apply to use of LL addresses > cause problems for current or future applications? > > - Will the capability to send messages using LL addresses > cause problems for networks, hosts, or applications? They may. This is acceptable. These issues are considered at length in the specification, along with warnings and limitations to applicability statement. This is not acknowledged in any way in Keith's remarks. [...] > 1. Can use of LL be avoided if it is found to cause problems? > > 1.1 LL will be imposed on applications, hosts, and networks > > Several existing Apple and Microsoft platforms currently ship with > a pre-standard version of this technology. [...] > These two vendors supply operating system software for the > vast majority of computing platforms in use today, especially > 'desktop' and 'laptop' platforms. Therefore it seems likely > that most 'desktop' and 'laptop' computers sold, and most > operating system upgrades for such systems, will support the > IETF v4 LL standard soon after it is adopted and for the next > several years. This is the reason that a standard to guide implementation and to arrive at common practice is so important. > Furthermore it also seems likely that, as new computers are > added to existing IP networks, and as existing computers are > replaced or upgraded to more recent opreating systems, IP networks > and IP-based applications will be exposed to LL traffic without > either the network operators or the users taking any action > to enable it. Right. Network operators should at least know what the protocol is that is running on their networks. This is another reason why a standard for this protocol is vital. > According to the descriptions of existing implementations in the > appendix of this document, several existing implementations > do not attempt to claim and/or use LL addresses if and when a DHCP > server responds to queries from the host. This provides a readily- > available means of allowing a network to suppress use of LL addresses > by these implementations. However this feature is specifically > forbidden in the draft specification, and the draft specification > provides no other mechanism with which use of LL addresses may be > disabled by either a host or a network. This is an *inappropriate comment.* This was discussed at length in the WG and the WG consensus supports this decision. This point was discussed in the preceding IETF last call. Keith is pointing out that he does not concur with WG consensus on this point, as he has before. > (Note that while the claim-defend protocol provides a means to > deny a host the ability to claim any particular LL address, > it provides no means to discourage a host from attempting to > claim other addresses, indefinitely, at a rate of up to one > address per minute per host) This is an insignificant amount of traffic even with many hosts on a low bandwidth shared access network. One must consider that there is a large amount of ARP traffic on networks with fixed addresses already. > Therefore, the draft specification would impose LL on > existing hosts (as they are upgraded to later operating systems), > applications, and networks, with little means of avoiding it or > disabling it should it be found to have an adverse effect. This is *not a substantive statement.* Any new protocol introduced to the network is 'imposed' upon existing hosts in the same way. Existing hosts which do not care about the new protocol will ignore it except in so far as it generates more traffic. In this sense, the above is an *incorrect statement,* as LL autoconf does not generate much traffic. LL autoconf is quite similar to Appletalk, which has been run unnoticed on many IP networks for over a decade. > 1.2 Conditions under which LL traffic will appear > > Since presumably LL will only affect applications, hosts, or > networks if it is actually used, in order to understand whether > LL can be avoided it is necessary to understand the conditions > under which LL traffic will appear. Huh? We are discussing the LL autoconf protocol, not avoiding it. We are not discussing alternatives. We are discussing only if the protocol the WG and leading members of industry have put forth is fit for publication. > a. Claim-defend protocol > > One kind of LL traffic consists of arp requests and replies > that are used to claim and defend LL addresses. These are > link-local broadcast packets, so they should reach every > host on the local network. LL autoconf uses ARP. ARP has broadcast requests and unicast replies. LL autoconf broadcasts the replies. > The claim-defend protocol will be invoked whenever a host > wishes to allocate a link-local address. The draft > specification seems to assume that this will happen at > power-on or bootstrap time (after a random delay). The specification also indicates that autoconfiguration can be triggered due to media sense, while running. The specification does not rule out autoconfiguration at any time subsequent to booting. > Other implementations may be consistent with the letter of > the draft specification. For instance, a host could allocate a > link-local address whenever an application requested to send > traffic to a link-local address, or whenever an application > explicitly requested to listen for traffic on a link-local > address. However such implementations would probably violate > the stated intent of the draft specification to make link-local > addresses "available all the time". This is an implementation detail, left to vendor discretion. > Use of the claim-defend protocol continues as long as the > LL address is "in use" by that host, though no definition > of "in use" is given. While a particular platform might > provide a nonstandard means to disable use of LL addresses, > causing them to no longer be "in use" by the host, it seems > consistent with the intent of this specification to assume that > most hosts that implement this specification will claim a > link-local address at power-on or bootstrap time, and > defend or claim a new address on a link during any period > that the host is operating and has access to the link. This is not a substantive statement. Just as a vendor has discretion when to use DHCP and when not to, a vendor has discretion when to use V4LL and when not to. A host which has an interface configured using V4 LL autoconf will answer to ARP requests, exactly as it does according to IPv4, except that the replies are broadcast not unicast. Only if there is a conflict detected, is there any further claiming. Experince with Appletalk shows this very rarely occurs. > It is therefore assumed that the claim-defend protocol will > unavoidably appear on any network to which LL-capable > hosts are attached, and that in due time this will apply to > essentially all IP-based networks. This is not a substantive statement. This is little more than saying that ARP will unavoidably appear on any network with IPv4-capable hosts. Only during initial configuration and in case of conflicts is there any additional protocol activity. Both initial configuration and conflict handling are rare events. > b. LL addresses used as IP source or destinations > [...] The material in this section largely restates concerns which were brought up in the preceding IETF last call for this document. A new section was added to the specification which addresses these concerns. In particular, draft 7 states Use of IPv4 link-local autoconfigured addresses presents additional challenges to writers of applications and may result in existing application software failing. This is acceptable to the (rough consensus expressed by the) WG. > [...] applications [...] send unicast traffic [...] to > specific hosts [...] only when those destinations are > somehow exposed [...] to that application. [...] > Such exposure can occur via a variety of means: > > - explicit configuration by users or operators > - a general-purpose service discovery protocol > - a referral from another component of the application > - a referral from a different application > (for example, a file obtained by FTP can request that > form data be sent via HTTP to a literal IP address) > - being associated with the name of a host, service, > or other resource that is declared to be useful > (in DNS or another name lookup service) > - from a host's network interface or ARP tables > - from the source address of an IP datagram or connection > - from network management protocols such as SNMP While true, this has no bearing on v4LL addressing. In each case the destination configured could be v4LL address. > Some sources of LL address exposure, and thus some sources of > LL use, are controllable. For instance, operators can be > cautioned to eschew exposure of LL addresses in DNS, service > discovery protocols, etc., and thereby to limit the use of LL > addresses to some degree. This is only marginally true. Service discovery and naming protocols which use LL addresses will operate peer to peer, which is to say, the operator will have very little control over whether they are used. Appletalk and especially netbios are examples of this. > However, application behavior varies widely. Some applications > use the source addresses of IP datagrams as destinations of > subsequent datagrams, or use such addresses in referrals to other > components. (For instance, in a NATted environment the source address > is more reliable than an address passed in the payload). Other > applications provide referrals to other components using addresses > obtained from interface tables. (For instance, to help the > application to cope with limited-scope addresses by listing > each of a host's addresses in referrals to other components > of the application, allowing components to try multiple addresses > until they find one that works.) Such applications will use LL > addresses and generate LL traffic without being explicitly > configured to do so. This point was made in the preceding IETF last call comments. Applications which are sensitive to these problems may break. New versions of these applications which follow recommendations from section 7 of the specification may do better. These recommendations include application awareness of v4 LL addresses to counter the problems Keith considers above. > Thus it is not generally possible to insulate hosts, networks, > or applications from LL merely by eshewing use of LL addresses > in managed name lookup services, service discovery protocols, and > application configuration. The degree to which LL addresses are > used "accidentally" depends on the specific set of applications > that are used on a particular network. This can be expected > to vary considerably from one network to the next. This is correct. The ZEROCONF WG (rough) consensus is that this is acceptable. The rhetorical emphasis of the statement (eschew, accidentally, etc) indicate that the author considers the protocol to be undesirable and unavoidable. If this were the case, there would be great concern over the use of Netbios on LANs, which has most of the same functions Keith describes (local and dynamic name to address resolution, entirely beyond an operator's ability to control or avoid). This concern does not exist. > 2. Will the resources consumed by LL traffic cause problems for networks, > hosts, or applications? > > 2.1 Effects of LL resource consumption on network operations > > a. bandwidth consumption > > - unicast LL traffic > > Unicast LL traffic imposes no more overhead on the local network > than unicast traffic to a local routable address. It is possible > that introduction of LL will increase the amount of traffic on a > network by facilitating new applications. We would generally > consider this a sign of success, though the possibility exists > that increased usage would cause short-term operational problems > for networks that are nearly saturated. This is argument fails to introduce material not previously covered by the previous last call. It is also a very weak argument. First, theoretically, because normal operation, outside of initial configuration, does not increase traffic at all. The only increase in activity, from a host perspective, is in that V4LL address ARP replies are broadcast instead of unicast. Second, this has not proven disruptive on existing appletalk networks. Third, the only case where one sees a substantial amount of broadcast ARP replies or lengthy and inconclusive claim and defend cycles is when the limit of O(10^3) is approached. The specification clearly warns that this is the scaling limit of the protocol, after which operators should arrange links differntly. Last, the WG has extensively reviewed this result and (rough) consensus strongly supports it. > b. network availability / reliablity / stability > > LL does not appear to affect network availability or reliability > as long as the additional traffic does not cause the network to > become saturated. This statement disagrees with the consensus of the WG. Network availability, reliability and stability are radically improved for hosts using v4LL as they can operate in environments where IP hosts fail otherwise. For example, in the presense of improperly configured DHCP servers, or the absense of configuration and knowledgeable operators. > 2.2 Effects of LL resource consumption on hosts > > a. Hosts which implement LL > > Hosts which implement LL can reasonably be expected to cope > with the amount and type of traffic generated by LL on a > reasonably-sized network. This traffic is negligible and acceptable within the domain of applicability of the protocol. See Section 1.2. > b. Other hosts > > Hosts which do not implement LL can still be expected to > implement ARP on interfaces that require it, and for the most > part LL usage is consistent with ARP. There is some chance that > platforms which do not implement LL might be confused by LL's > requirement that LL ARP replies be sent using link-layer > broadcast instead of link-layer unicast (draft spec, bottom page 11). This has not proven the case so far, where the protocol has been used. It is not required that a protocol prove that it will not break any existing code to advance to proposed standard. > c. All hosts > > The need to process additional broadcast packets generated by > LL ARP replies may result in increased overhead for all hosts, > and in increased hardware costs for new hosts to permit them > to handle an increase in interrupts needed to broadcast packets, > even if they are promptly discarded. This seems unlikely to > significantly affect general-purpose hosts (desktops, laptops, > servers) but may affect "appliance" or "fixed-function" hosts > (especially those designed for the consumer market), which > which operate with less margin in CPU cycles. How significant are these effects? Normally, ARP requests are broadcasts, while ARP replies are unicast. Networks with thousands of hosts produce more broadcast ARP requests than a v4LL network could produce (given the protocol), and yet on such networks, ARP has not been identified as a limit to scalability. The point is v4LL adds 50% more broadcast messages to ARP exchanges, which are infrequent. Since no one seriously suggests that ARP is inappropriate on a network with > 2600 hosts, it is not a reasonable argument that v4LL is inappropriate on a network with < 1300 hosts. This argument explores only the limit cases, which is beside the point. This protocol is used on networks with a handful of hosts: homes, small offices, conference rooms, ad hoc networks. In these cases, the overhead of the protocol is modest. In cases where there are many hosts, additional overhead exists, but is acceptable, as per prior discussion and consensus actions in the ZEROCONF WG. (Note that equivalent comments arose during the previous IETF last call for this document and were not accepted by the WG then.) > 2.3 Effect of LL resource consumption on applications > > In general, an application should consume no more resources > for LL traffic than for traffic between routable unicast addresses. Why not? Why shouldn't an incremental cost be acceptable? The incremental cost is extremely modest, as has been argued. > However, if an application naively responds to LL traffic in a > situation where use of LL will cause the application to fail, > and that application persists in trying to use LL, the application's > performance may be adversely impacted. 7. Application Programming Considerations Use of IPv4 link-local autoconfigured addresses presents additional challenges to writers of applications and may result in existing application software failing. > 3. Will the visibility of LL addresses by networks, hosts, and > applications, cause problems for networks, hosts, or applications? > > 3.1 Effects of LL visibility on networks > > Since LL addresses are not tightly bound to hosts, there is no > association of host identity with LL address, it becomes necessary > for traffic monitors to associate hosts with layer 2 addresses rather > than layer 3 addresses, even if they are monitoring layer 3 traffic. This protocol does not facilitate traffic monitoring. This is fine. > With the introduction of LL, DNS cannot be used to provide reliable > address-to-name mapping even on networks where it might be reliable > for routable addresses (e.g. when DHCP and DNS are coordinated). Yes. Section 2.9: As link-local addresses may change at any time and have limited scope, storing link-local addresses in the DNS is not well understood and it is NOT RECOMMENDED. > 3.3 Effects of LL visibility on applications > [...] > LL addresses become visible to apps [...] will then be used > by some apps that use addresses in referrals to other apps. > > a. address scope problems due to referrals > > Because LL address-to-host bindings are only valid on a > particular link, when applications use LL IP addresses in > referrals to other applications (or other components of the > same application) those referrals may fail when those IP > addresses are not valid for the host that received > those addresses. > > b. address stability problems with referrals > > Because LL address-to-host bindings are only valid on a > particular link, applications which use LL IP addresses in > referrals to or from other applications may fail when > those IP addresses are no longer bound to the same host > as when the referral was generated, even if the host which > received the referral has access to the same network link > for which the LL address was valid. This point was raised in the preceding IETF last call. Section 7.2 of the document was added. WG (rough) consensus supports the current text (warning and admonishing the implementor to consider these issues). These issues arise with all scoped addresses. > 4. Will the special considerations that apply to use of LL addresses > cause problems for current or future applications? > > a. address scope problems with multiple intefaces > b. non-uniqueness of addresses > c. address stability effect on connection duration These issues are well documented in the v4LL specification, as well as a thorough discussion of application implications in section 7. These identical points were raised in the preceding IETF last call. (Rough) WG consenss supports the current text. > 5. Will the capability to send messages using LL addresses cause > problems for networks, hosts, or applications? > > a. security problems > > LL facilitates communications between hosts under circumstances, > and over paths, which did not previously permit communication. > In the case of wireless links the introduction of LL can cause > purely "accidental" communications paths to be established, I leave aside the wireless aspect of the comment, because I believe it exacerbates the issue, but is not fundamental to it. Configuration of IP has been so difficult for IP that it either required manual address configuration or DHCP. This has no longer been true since 98. A Windows system using v4LL and Netbios allows communication without configuration (except of some names on the host). Similarly, Appletalk has allowed hosts without configuration to communicate. In neither case is this communication 'accidental.' Applications communicate using established protocols, users locate resources by name and type. The fact that the addresses they use are established automatically is unimportant. The question is whether use of v4LL addresses constitutes a 'different path' than use of configured addresses. The answer is no. > as hosts with wireless links can connect to one another in the > absence of any explicit effort by users or administrators to > facilitate such communications (and despite efforts to limit > such communications). This is again a de jure argument. The possibility of doing this has been true de facto for 5 years. > This introduces new risks for both networks > and hosts, especially networks and hosts that rely (as most do) > on the ability to do some kind of ingress filtering as part of > their security implementation. This comment is wrong in that it states there are new risks and objectionable in that it introduces the requirement for ingress filtering. From a security perspective, it is important to document the risks introduced by use of the protocol. This has been done by the v4LL spec. There is no requirement to support ingress filtering in order to advance a protocol to proposed standard. The domain of applicability of this protocol is an IPv4 link, which uses ARP. Anyone with access to a link that can listen to and inject ARP messages can already spoof L2 and L3 addresses. There is no force in the argument above that anything new has been introduced. If anything is new, it is that hosts can communicate easier, with fewer hurdles. The IPv4 network is just as dangerous as it was; v4LL makes it easier than ever to join it. > Consider the following example scenario: > > > --------------------------+ +-------------------------- > company A meatspace | | company B meatspace > | | > company A | | company B > network | | network > / | wall | \ > / +--------+ | | +--------+ \ > ==========| laptop |]~~~~~~~~~~~~~~~~~~[| laptop |========= > +--------+ | ^ | +--------+ > | | | > | | | > --------------------------+ | +-------------------------- > | > covert LL wireless channel > > Company A and company B maintain separate networks. Each > has its own policy for what kinds of traffic to permit on > those network, and each company's network policy is implemented > using a firewall. However if the laptops have (presumably > built-in) wireless interfaces supporting LL, a covert channel > may exist between machines on the different networks. This > situation can exist anytime the laptops allow "ad hoc" operation > on their wireless interfaces. It has several implications: > > - Existing firewalls are bypassed, so existing threat > countermeasures are circumvented. Granted, it's a bad idea to > completely rely on firewalls since many threats are internal, > but the reality is that this is currently both conventional > wisdom and common practice. > > - Company A is implicitly trusting company B's firewall (and the > security of company B's hosts) and vice versa. > > - Company A's hosts can attack company B's hosts, and vice versa. > > Note that a single compromised host can serve as a platform from > which other attacks can be launched. Even if A does not attack > B or vice versa, a successful attack on a host on either network > may facilitate a (presumably easier) attack on the other network. > It is not difficult to see how a worm or virus could propagate > using LL covert channels. This example has nothing specific to do with v4LL. It illustrates the risks of insecured wireless link layers and neighbor discovery. The same scenario could occur if the host used DHCP on the foreign network or simply scavenged an address (take one which appears to be unused in the same range as those which are being used actively.) v4LL may facilitate illicit access but it neither allows it nor significantly changes the fundamental risk. > Another scenario is similar -- a nomadic laptop which > connects to various ad hoc LL networks as it moves potentially > exposes the laptop to new security threats in each new network. > A laptop which was compromised using LL may then be used to > attack a company's private network when it is connected to > that network. This comment does not address v4LL directly and poses unreasonable expectionations. The only true network security is to stay off the network entirely. A nomadic computer can be compromised if it is manually configured or configured using DHCP when it attaches to a new network. > b. support issues > > In addition to difficulty of traffic monitoring, introduction of > LL may cause application failures which are difficult to isolate, > diagnose, or fix. This causes issues for those who support networks > and network-based applications. This is true. It is much much worse if vendor implementations vary and there is no standards based document one can refer to and attempt to hold vendors accountable to. Without a standards track document, it will be extremely difficult to understand what v4LL behavior is or should be. This is one of the main reasons why publication of the specification as a proposed standard is urgent! > 6. Summary > > - If the draft specification is implemented in its current form, > it is impractical to avoid imposition of LL on networks, hosts > and applications using current measures. Or from a users perspective, it is impossible to be prevented from local communication by an improperly configured network. Home users will not be prevented from using local networking by a home gateway, cable modem, etc. Who is imposing on whom? > - LL seems unlikely to cause resource depletion for most networks. > However it may cause resource depletion in nearly-saturated > networks and large L2-switched networks. Some limited function > hosts may not be able to cope with additional CPU load due to > additional broadcast packets on large networks. Applications which > are incompatible with LL and which use LL "accidentally" may > cause additional consumption of network resources if they > persistently retry operations that failed due to LL. There is a domain of applicability for the protocol and well specified mechanisms to cause it to fail gracefully in networks which excede its intended scope. It is not reasonable to require a proof that a protocol will not harm any conceivable network before it gets advanced to proposed standard. > - For various reasons, some applications are incompatible with LL. > Some of these applications will fail if configured to use an LL > address or a name that binds to an LL address. Others will fail > when LL is introduced merely because those LL addresses are visible > via interface or ARP tables, and/or because they will begin to > see traffic from LL addresses. These objections were raised in the preceding IETF last call. They were met with section 7 in the current draft. No new objections are added by this set of last call comments. > - Imposition of LL circumvents existing security mechanisms and > creates additional security risks for networks, hosts, and > applications. This has been shown to be false in the arguments above. > - Imposition of LL creates new support burdens for users, networks, > and application maintainers. While this may be true, one could argue that IPv4 creates its own support burdens for users netowrk and application maintainers which are significantly alleviated through adoption of v4 LL. This is certainly the opinion of WG participants (from major client and network infrastucture vendor companies) involved with this work. > 7. Recommendations > > - There needs to be a standard way for managed networks to disable LL > traffic, both on the network and on hosts connected to that network. This point was made in the last IETF last call and rejected by the WG. > - As a matter of standards compliance, hosts need to be required > to provide a means to disable LL traffic, both entirely and on a > per-interface basis. Vendors are free to add this feature. There are many vendors who produce equipment for which any manual configuration is impossible. It is definitely not acceptable to exclude this equipment from the protocol's domain of applicability. > - Because there are valid reasons to disable LL, and for other reasons, > the specification should discourage the expectation that a host that > implements only LL can expect to communicate with other IP hosts, > even those on the same network segment. Hosts should implement DHCP > and/or support static address configuration if they wish to have > the capability to communicate with other hosts using IP. This statement was made and rejected during extensive debate on the WG mailing list. Keith was in the minority (of one) during these debates. Further, this point was included in the previous set of last call comments and rejected by WG consensus action. > - Even when LL is enabled on a host or an interface, there needs > to be a way of isolating existing applications from LL traffic > and from the visibility of LL addresses. Others disagree. Under most circumstances, those in which v4LL is likely to be used, LL works just fine and not bother most common applications at all. Address assignment will be stable and communication, restricted to the LAN anyway, will function fully as the application expects. If there is a link local web proxy most users will not know the difference. We accept that some applications will not work with v4LL addresses or may work less than perfectly in some circumstances. The user has choices. She can get a new application that works better. She can demand better software from her vendors. She can demand a switch to turn link local addressing off. Last I checked, this can be done using all versions of Mac OS and Windows that support v4LL. Scoped, renumberable address awareness is required for applications to support IPv6, in any case. > - LL should be disabled by default on wireless interfaces, requiring > explicit configuration of such interfaces to support LL. Enabling > the wireless interface to support LL on a specific wireless network > should be separate from enabling a wireless interface to support LL > on an ad hoc network. The WG has consistently disagreed with Keith on the question of whether v4LL should be on by default and whether it should be turned off. The only argumented presented above concerning the use of v4LL over wireless links was in the security section. I demonstrated that v4LL exposes no new security threats over that of an unsecured link layer using insecure neighbor discovery. > - When wireless interfaces are allowed to use LL on ad hoc networks > (as opposed to configured wireless networks), there should be a > means to prevent applications from being exposed to traffic from > such networks, so the host will accept traffic only for those > applications that are believed to be safe from arbitrary, anonymous > traffic. There are mechanisms to do this: L2, L3 and L7 security. It is inaccurate to blame address autoconfiguration for reduced security in networks without these mechanisms. An attacker could easily pursue the same vulnerabilities, and more, simply by monitoring and injecting the right ARP messages on the unsecured link. > - More study is needed before the security implications of LL can > be fully understood. LL should not be deployed until those > implications are understood and suitable countermeasures exist. It is absolutely inappropriate to insist that a protocol not be advanced solely on the basis of it not being fully understood. There has been careful security assessment of this protocol, that has not been challenged in this set of remarks. Further, there is going on five years of actual deployment. If the bar is this high, the IETF might just as well shut down immediately. > 8. Conclusions > > LL is potentially a very useful technology, and there are compelling > reasons to deploy it. It is useful and it is deployed. This is not open to debate. > However if deployed in the form specified in > the draft specification, it will break some applications, Yes, it could. The WG accepts this and text specifically warning and admonishing implementors was added as a result of the previous IESG last call. > invite new kinds of attack on hosts and networks, The comments above dispute this point. > and create new means of propagating viruses. This is specious. > I do not believe that the current draft specification meets either > explicit or implicit requirements for Proposed Standard status. This is clearly the case. This email documents precisely the way in which Keith forms the 'rough' part of ZEROCONF WG consensus. I would support Keith's publication of these arguments in a document, say an Informational RFC, entitled "A Dissenting Opinion on Dynamic Configuration of IPv4 Link-Local Addresses". Respectfully, Erik ZEROCONF WG cochair From owner-zeroconf@merit.edu Tue Sep 24 14:36:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08446 for ; Tue, 24 Sep 2002 14:36:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1904E9124C; Tue, 24 Sep 2002 14:37:44 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCA1F91258; Tue, 24 Sep 2002 14:37:43 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DF94C9124C for ; Tue, 24 Sep 2002 14:37:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB4F25E10E; Tue, 24 Sep 2002 14:37:41 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 6F60D5DDBC for ; Tue, 24 Sep 2002 14:37:41 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA00995 for ; Tue, 24 Sep 2002 14:37:40 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA28998 for ; Tue, 24 Sep 2002 14:37:40 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA06474 for ; Tue, 24 Sep 2002 14:37:40 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 24 Sep 2002 14:37:37 -0400 Subject: Re: last call comments on draft-ietf-zeroconf-ipv4-linklocal-07 From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA08446 On 09/24/2002 10:18, "Erik Guttman" wrote: Comments from an IT/implementation use perspective, where LL addressing is a fact of life, and dealt with rather simply, and pretty much, in support of Erik's comments, perhaps from a different view point: >> Whereas for most >> candiates for standards track we are satisfied if the protocol has no >> _known_ technical omissions with respect to the requirements placed on it, >> for a candidate that affects the fundamental Internet Protocol it seems >> entirely appropriate to insist that there be _high_confidence_ >> that there are no such omissions. To put it a different way, for >> proposed changes to fundamental internet protocols there is an >> implicit requirement that the changes not be disruptive to >> existing uses of those fundamental protocols, to the operation >> of IP networks, or to the ability of IP-based networks to support >> a wide variety of current and future applications. > > This is an unreasonable requirement. > > Link local IP is on by default in a significant percentage of internet > hosts and has not proven disruptive. If there is a better argument that 4+ years of LL is on, working, and hasn't killed the internet, or anyone's network in that time, I'd be surprised. While not a substitute for analysis, and Keith's is thorough, even if I really think he is being unreasonable in some of his objections, (with his requirements, we wouldn't have DHCP.), that fact that Link Local is working and has worked with no real disruptions to non-LL traffic is something to be heavily weighted. >> - LL generates network traffic, and thus consumes resources, >> during both negotiation and use, > > This question has been debated at length in the WG and is therefore > inappropriate in the WG last call. Keith argues that LL creates traffic. So does everything that uses a network. That is rather an obvious point, and I'm unsure as to it's significance. Web connections, FTP, Telnet, all services that use a network, regardless of underlying protocol. NFS creates a great deal of network traffic when in use. If generating traffic is a bad thing, then sneakernet is our only choice. The correct question would be, does it generate a *harmful* amount of traffic, which is answered as "Maybe". It really depends on the individual network's definition of harmful. In any event, it is not the WG's place to define that for network admins. Show us the traffic generated, we're all smart enough to decide for ourselves if it's acceptable or not. >> - The introduction of LL facilitates new communications paths. >> Indeed this is its entire purpose. >> >> From these broad classes the following questions are derived, >> which this document attempts to answer: >> >> - Can use of LL be avoided if it is found to cause problems? > > The specification considers how to use LL not how to avoid it. If you know how to use it, then avoiding it is easy enough. But again, it's not the WG's place to define that. If that was the case, then how many other IETF specifications list how to avoid using the protocol/new toy that the specification refers to? > >> - Will the resources consumed by LL traffic cause problems for >> networks, hosts, or applications? > > No. > >> - Will the visibility of LL addresses by networks, hosts, and >> applications cause problems for networks, hosts or applications? >> >> - Will the special considerations that apply to use of LL addresses >> cause problems for current or future applications? >> >> - Will the capability to send messages using LL addresses >> cause problems for networks, hosts, or applications? > > They may. This is acceptable. > > These issues are considered at length in the specification, along with > warnings and limitations to applicability statement. This is not > acknowledged in any way in Keith's remarks. I can ask the same questions of anything about the future. Will DNS cause me problems? Well, in the future, we don't know. Will something bad happen? We don't know. We cannot predict the future, and if someone has the protocol for that, where's *that* working group's mailing list? In all seriousness, as long as the current state of v4LL addressing is well documented, then it is up to the individual network admins to decide on suitability for their environment. No two networks will have the same answer. >> Furthermore it also seems likely that, as new computers are >> added to existing IP networks, and as existing computers are >> replaced or upgraded to more recent opreating systems, IP networks >> and IP-based applications will be exposed to LL traffic without >> either the network operators or the users taking any action >> to enable it. > > Right. Network operators should at least know what the protocol is > that is running on their networks. This is another reason why a > standard for this protocol is vital. This is all the standard needs to do. For example, I don't need the FTP standard to list every possible bad thing that can happen with FTP. That's not what a standard does. I need the standard to give me the information on FTP so I can make an informed decision as an admin, and so ISV's can make informed decisions as ISVs. >> Therefore, the draft specification would impose LL on >> existing hosts (as they are upgraded to later operating systems), >> applications, and networks, with little means of avoiding it or >> disabling it should it be found to have an adverse effect. > > This is *not a substantive statement.* Any new protocol introduced > to the network is 'imposed' upon existing hosts in the same way. > > Existing hosts which do not care about the new protocol will ignore > it except in so far as it generates more traffic. In this sense, > the above is an *incorrect statement,* as LL autoconf does not > generate much traffic. LL autoconf is quite similar to Appletalk, > which has been run unnoticed on many IP networks for over a decade. Um...IPv6 is going to be 'imposed' on my network regardless of my opinions on using it. If I never use it, then I really don't care, as long as I can get work done. If I need to block it for some odd reason, then the standard will give me enough information on how it works and how to use it so I can block it in accordance with my needs. To come up with every way to avoid a standard would bog down the IETF even more than it already is, and shove the IETF at high speeds to a condition of uselessness. We can all agree this is a bad thing. >> the draft specification. For instance, a host could allocate a >> link-local address whenever an application requested to send >> traffic to a link-local address, or whenever an application >> explicitly requested to listen for traffic on a link-local >> address. However such implementations would probably violate >> the stated intent of the draft specification to make link-local >> addresses "available all the time". > > This is an implementation detail, left to vendor discretion. It wouldn't be a used implementation for long either. >> It is therefore assumed that the claim-defend protocol will >> unavoidably appear on any network to which LL-capable >> hosts are attached, and that in due time this will apply to >> essentially all IP-based networks. > > This is not a substantive statement. > > This is little more than saying that ARP will unavoidably appear on > any network with IPv4-capable hosts. Only during initial configuration > and in case of conflicts is there any additional protocol activity. > Both initial configuration and conflict handling are rare events. Well, any network with a Mac or a windows box running any versions of those OS's built since 1998 is doing that now. Experience dictates that no real problems arise in systems that ignore LL addressing. >> b. network availability / reliablity / stability >> >> LL does not appear to affect network availability or reliability >> as long as the additional traffic does not cause the network to >> become saturated. > > This statement disagrees with the consensus of the WG. Network > availability, reliability and stability are radically improved for hosts > using v4LL as they can operate in environments where IP hosts fail > otherwise. For example, in the presense of improperly configured DHCP > servers, or the absense of configuration and knowledgeable operators. Poorly configured Ethernet hardware can cause problems, yet we accept the risks of stupidity, and use Ethernet. I have found *far* more problems from multimedia streams eating a network alive than I have from LL addressing, and my colleagues in the area network management generally concur. Being slashdotted is *far* more hazardous to your web site than two Macs using iChat over Rendezvous. >> 2.3 Effect of LL resource consumption on applications >> >> In general, an application should consume no more resources >> for LL traffic than for traffic between routable unicast addresses. > > Why not? Why shouldn't an incremental cost be acceptable? > The incremental cost is extremely modest, as has been argued. Um...the application's use of bandwidth should be *totally* independent of the IP address assignment method. In fact, unless the application is designed around networking at that layer, it shouldn't care. As well, how will the addressing method affect the fact that an MPEG4 server eats a lot of bandwidth? > >> However, if an application naively responds to LL traffic in a >> situation where use of LL will cause the application to fail, >> and that application persists in trying to use LL, the application's >> performance may be adversely impacted. > > 7. Application Programming Considerations > > Use of IPv4 link-local autoconfigured addresses presents additional > challenges to writers of applications and may result in existing > application software failing. This happened when multihoming became more common. Networked application programmers had to learn that you can't just directly tickly en0, it may not be the interface that will work. This happened with DHCP, when you couldn¹t guarantee a predefined address in a config file. If the application is written correctly, then it should have minimal, if any problems. If it isn't then it was broken anyway, and needed fixing. >> 3.3 Effects of LL visibility on applications >> [...] >> LL addresses become visible to apps [...] will then be used >> by some apps that use addresses in referrals to other apps. >> >> a. address scope problems due to referrals >> >> Because LL address-to-host bindings are only valid on a >> particular link, when applications use LL IP addresses in >> referrals to other applications (or other components of the >> same application) those referrals may fail when those IP >> addresses are not valid for the host that received >> those addresses. There are very few reasons for an application to statically bind to specific interface and IP address. For those that do need that, there are well documented ways to establish which interface and address should be bound to. >> 5. Will the capability to send messages using LL addresses cause >> problems for networks, hosts, or applications? >> >> a. security problems >> >> LL facilitates communications between hosts under circumstances, >> and over paths, which did not previously permit communication. >> In the case of wireless links the introduction of LL can cause >> purely "accidental" communications paths to be established, > > I leave aside the wireless aspect of the comment, because I believe > it exacerbates the issue, but is not fundamental to it. In any case, LL isn't *creating* a new physical layer connection. It cannot, unless you have a computer that is building it's own circuitry on the fly. It can only use access methods that are already there. If the security and configuration of those access methods are poorly set up, that is not the fault of the LL machine, and LL isn't responsible for fixing a bad network config. >> as hosts with wireless links can connect to one another in the >> absence of any explicit effort by users or administrators to >> facilitate such communications (and despite efforts to limit >> such communications). > > This is again a de jure argument. The possibility of doing this has > been true de facto for 5 years. How is LL going to generate a WEP/VPN/RADIU/KERBEROS connection? If the device isn't equipped with a wireless card, it's not going to use wireless. If a wireless device's MAC address isn't on the ACL for that wireless link, LL isn't going to spoof it. >> Consider the following example scenario: >> >> >> --------------------------+ +-------------------------- >> company A meatspace | | company B meatspace >> | | >> company A | | company B >> network | | network >> / | wall | \ >> / +--------+ | | +--------+ \ >> ==========| laptop |]~~~~~~~~~~~~~~~~~~[| laptop |========= >> +--------+ | ^ | +--------+ >> | | | >> | | | >> --------------------------+ | +-------------------------- >> | >> covert LL wireless channel >> >> Company A and company B maintain separate networks. Each >> has its own policy for what kinds of traffic to permit on >> those network, and each company's network policy is implemented >> using a firewall. However if the laptops have (presumably >> built-in) wireless interfaces supporting LL, a covert channel >> may exist between machines on the different networks. This >> situation can exist anytime the laptops allow "ad hoc" operation >> on their wireless interfaces. It has several implications: >> >> - Existing firewalls are bypassed, so existing threat >> countermeasures are circumvented. Granted, it's a bad idea to >> completely rely on firewalls since many threats are internal, >> but the reality is that this is currently both conventional >> wisdom and common practice. >> >> - Company A is implicitly trusting company B's firewall (and the >> security of company B's hosts) and vice versa. >> >> - Company A's hosts can attack company B's hosts, and vice versa. >> >> Note that a single compromised host can serve as a platform from >> which other attacks can be launched. Even if A does not attack >> B or vice versa, a successful attack on a host on either network >> may facilitate a (presumably easier) attack on the other network. >> It is not difficult to see how a worm or virus could propagate >> using LL covert channels. > > This example has nothing specific to do with v4LL. It illustrates the > risks of insecured wireless link layers and neighbor discovery. The > same scenario could occur if the host used DHCP on the foreign network > or simply scavenged an address (take one which appears to be unused in > the same range as those which are being used actively.) > > v4LL may facilitate illicit access but it neither allows it nor > significantly changes the fundamental risk. As well, it would be very odd for a network admin to go through the trouble of protecting wired access and then install an open wireless network behind a firewall. LL has nothing to do with the humans being silly. > >> Another scenario is similar -- a nomadic laptop which >> connects to various ad hoc LL networks as it moves potentially >> exposes the laptop to new security threats in each new network. >> A laptop which was compromised using LL may then be used to >> attack a company's private network when it is connected to >> that network. > > This comment does not address v4LL directly and poses unreasonable > expectionations. > > The only true network security is to stay off the network entirely. > A nomadic computer can be compromised if it is manually configured > or configured using DHCP when it attaches to a new network. Indeed, that laptop could be just as exposed by a DHCP network at a trade show. It will cause just as many problems as the LL laptop. So should we now stop all forms of non-mannual address assignment. I can do far more damage with a wireless packet sniffer and a big hard drive than I can trying to pervert a LL laptop. > >> b. support issues >> >> In addition to difficulty of traffic monitoring, introduction of >> LL may cause application failures which are difficult to isolate, >> diagnose, or fix. This causes issues for those who support networks >> and network-based applications. > > This is true. It is much much worse if vendor implementations vary and > there is no standards based document one can refer to and attempt to > hold vendors accountable to. Without a standards track document, it > will be extremely difficult to understand what v4LL behavior is or > should be. This is one of the main reasons why publication of the > specification as a proposed standard is urgent! Those support issues apply in precisely the same way to all aspects of computing, or indeed any device more complicated than a rock. And rocks cause problems too, especially if flung through a laptop. > >> 6. Summary >> >> - If the draft specification is implemented in its current form, >> it is impractical to avoid imposition of LL on networks, hosts >> and applications using current measures. > > Or from a users perspective, it is impossible to be prevented from > local communication by an improperly configured network. Home users > will not be prevented from using local networking by a home gateway, > cable modem, etc. Who is imposing on whom? As opposed to the last four years of LL traffic anyway? This standard is playing catch-up to something that's in use by *millions* of devices. Don't confuse that fact with the idea that the standard is predicting anything. That's why we *need* a standard, so that new devices at least have the possibility of being based on the same specifications. That *reduces* problems. LL addressing is here to stay. > >> - LL seems unlikely to cause resource depletion for most networks. >> However it may cause resource depletion in nearly-saturated >> networks and large L2-switched networks. Some limited function >> hosts may not be able to cope with additional CPU load due to >> additional broadcast packets on large networks. Applications which >> are incompatible with LL and which use LL "accidentally" may >> cause additional consumption of network resources if they >> persistently retry operations that failed due to LL. > > There is a domain of applicability for the protocol and well > specified mechanisms to cause it to fail gracefully in networks > which excede its intended scope. > > It is not reasonable to require a proof that a protocol will not > harm any conceivable network before it gets advanced to proposed > standard. If 200 laptops doing LL kills your network, it was about to die anyway, and you were already having problems. >> - Imposition of LL creates new support burdens for users, networks, >> and application maintainers. > > While this may be true, one could argue that IPv4 creates its own > support burdens for users netowrk and application maintainers which > are significantly alleviated through adoption of v4 LL. This is > certainly the opinion of WG participants (from major client and > network infrastucture vendor companies) involved with this work. If I wanted to drop my support burden *radically*, I'd go all Mac, ban anything but straight AppleTalk, and sleep late for the rest of my life. Avoidance of support issues is a guideline not a requirement. If you can make something easy to support, great. But if the benefits are clear, and real, which they are here, then you just make sure the spec is clear, to help mitigate support issues. >> 7. Recommendations >> >> - There needs to be a standard way for managed networks to disable LL >> traffic, both on the network and on hosts connected to that network. > > This point was made in the last IETF last call and rejected by the WG. That's out of scope for a standard. > >> - As a matter of standards compliance, hosts need to be required >> to provide a means to disable LL traffic, both entirely and on a >> per-interface basis. > > Vendors are free to add this feature. There are many vendors who > produce equipment for which any manual configuration is impossible. > It is definitely not acceptable to exclude this equipment from the > protocol's domain of applicability. There are well over a hundred different operating environments on the Internet today. How do you propose to create a standard way to configure all of them? >> - More study is needed before the security implications of LL can >> be fully understood. LL should not be deployed until those >> implications are understood and suitable countermeasures exist. > > It is absolutely inappropriate to insist that a protocol not be > advanced solely on the basis of it not being fully understood. > There has been careful security assessment of this protocol, that > has not been challenged in this set of remarks. Further, there is > going on five years of actual deployment. If the bar is this high, > the IETF might just as well shut down immediately. That is a completely, (pardon my descent into slang) bogus requirement that is not, and has not ever been required of *any* protocol or standard. I fail to see how LL is SO harmful, outside of personal prejudice, as to impose an absolutely unique set of requirements on it that will de facto guarantee that it will never get past the 'mailing list argument' stage...which I suspect is the intent of those requirements. >> However if deployed in the form specified in >> the draft specification, it will break some applications, > > Yes, it could. The WG accepts this and text specifically warning > and admonishing implementors was added as a result of the previous > IESG last call. This applies to all new protocols. Note by 'new', I mean something that hasn't been in use for the last four years. > >> invite new kinds of attack on hosts and networks, > > The comments above dispute this point. You mean for a change? There's some group of l33t sk8t3r b0yz just waiting for an LL standard to work their evil? This is just alarmist. > >> and create new means of propagating viruses. > > This is specious. And more correctly, simply FUD. john -- John C. Welch IT Manager MIT Police (617) 253 - 3093 work (508) 579 - 7380 cell (617) 253 - 8822 fax From owner-zeroconf@merit.edu Tue Sep 24 15:58:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10613 for ; Tue, 24 Sep 2002 15:58:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D8B7291207; Tue, 24 Sep 2002 15:59:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E71391217; Tue, 24 Sep 2002 15:59:41 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC6BC91207 for ; Tue, 24 Sep 2002 15:59:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD77F5E121; Tue, 24 Sep 2002 15:59:38 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 126745DDC8 for ; Tue, 24 Sep 2002 15:59:38 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8OJxQ024650; Tue, 24 Sep 2002 15:59:26 -0400 (EDT) Message-Id: <200209241959.g8OJxQ024650@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Guttman Cc: iesg@ietf.org, zeroconf@merit.edu, Keith Moore Subject: Re: last call comments on draft-ietf-zeroconf-ipv4-linklocal-07 In-reply-to: (Your message of "Tue, 24 Sep 2002 16:18:19 +0200.") Date: Tue, 24 Sep 2002 15:59:26 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk okay, I want to make a few things clear: 1. I have not disputed whether there is WG consensus on the current document. I suspect that there is such consensus, though I really haven't tried to see (for instance) whether each topic was discussed and consensus reached for each topic, on the mailing list. But as 2026 makes clear, WG consensus is not sufficient justification to put this document on the standards track. The issues I have raised are mostly about the quality of the protocol that is proposed in the document. There are also a few issues about the quality of the document itself and whether the document is within the WG's scope. But if it weren't for the protocol quality problems I probably wouldn't be pressing on the other issues. 2. Similarly, "satisfying Keith" is not the issue. It never has been. The issue is fixing the technical problems with this document. 3. Most of the delays in getting this document out the door are due to the working group's failure to either consider, or to adequately address the problems with the document. Fixing these problems does not require substantial changes to either the protocol or the document text, nor does it break compatibility with existing deployed implementations. Fixing these problems mostly requires a willingness to admit that the current proposal does cause problems for apps and networks and the willingness to make minimal changes to address them. > > Working group members, esteemed IESG members, > > I want to point out that this (late) review is the second such > response to an IETF last call. Indeed, the only reason for the > second last call is the difficult long process in responding to > Keith's previous set of issues. you make it sound like I'm the one causing the problem when it's the WG that has failed to adequately consider those issues in the first place. in other words, you're trying to cast this as a personal issue rather than a technical one - which I find highly inappropriate. > It is also important to note that this protocol has been widely > deployed for some time and the document has received wide and > extensive peer review. most versions of the protocol that have been widely deployed do not exhibit the worst flaw that the proposed specification has - which is that there is no way for a network to disable LL. so using the wide deployment to justify the current proposal simply doesn't wash - it makes far more sense to use the wide deployment to justify some of the changes I'm recommending. > In summary of the points I make below, I argue that Keith has a number > of points where he disagrees with the output of the ZEROCONF WG. This > is acceptable, as the criteria for advancing a specification on the > standards track is rough consensus not total agreement. None of > Keith's points, whether newly made in this set of comments, or > repeated from his previous last call comments, merit holding the > specification back from being advanced. I respectfully disagree. > > Whereas for most > > candidates for standards track we are satisfied if the protocol has no > > _known_ technical omissions with respect to the requirements placed on it, > > for a candidate that affects the fundamental Internet Protocol it seems > > entirely appropriate to insist that there be _high_confidence_ > > that there are no such omissions. To put it a different way, for > > proposed changes to fundamental internet protocols there is an > > implicit requirement that the changes not be disruptive to > > existing uses of those fundamental protocols, to the operation > > of IP networks, or to the ability of IP-based networks to support > > a wide variety of current and future applications. > > This is an unreasonable requirement. > > Link local IP is on by default in a significant percentage of internet > hosts and has not proven disruptive. False. As the draft spec clearly indicates, for most of these implementations LL is not "on" whenever DHCP is in use, and my experiments with a couple of these implementations indicate that (for those I've tested) LL is not "on" when an address is statically assigned. Thus I suspect that LL is not "on" by default for the vast majority of Internet hosts. Even if it were, this misses the point. There is no disagreement that many apps and networks are tolerant of LL. The question is whether apps and networks that aren't tolerant of LL are forced to deal with the disruption that LL causes, or whether they can turn it off. > > Keith's outline of issues follows. The outline of my responses > is interjected. > > [...] > > Introduction of unicast link-local addressing into IPv4 has several > > broad effects which can be further analyzed for potential problems. > > In particular, > > > > - LL generates network traffic, and thus consumes resources, > > during both negotiation and use, > > This question has been debated at length in the WG and is therefore > inappropriate in the WG last call. - This is an IESG last call, not a WG last call. IESG has to make a determination about the quality of this protocol, and it's entirely appropriate to provide input to IESG about that decision. - Perhaps more to the point, my LC message was attempting to do analysis of possible problem areas. In order to do that it has to consider various areas where problems _might_ occur whether or not there is ultimately a conclusion that those areas do have problems. So I mentioned this area of potential problems mostly to be sure that I was covering all of the bases, as explained in my LC message. WRT this problem the conclusion is that consumption of bandwidth was unlikely to be significant except in marginal cases - large L2 switched networks, nearly-saturated networks, appliance hosts with limited CPUs. Whether these are significant enough by themselves to require changes to the protocol or to the document is up for IESG to decide - personally I doubt I would think that protocol changes were necessary, though some additional documentation might be appropriate. > > > - The introduction of LL addresses makes those addresses > > visible in some contexts, > > This question was brought up in the previous last call and we have > WG consensus that there are sufficient caveats in the document in > response to the risks. It is clear Keith disagrees, but this is a > rehashing of the same issue which is settled, as far as the > working group is concerned. again, WG consensus is only one of the necessary conditions. even if the WG has consensus on a protocol, IESG has the responsibility to determine whether it meets the requirements for standards track, and these comments were intended as input to those deliberations. > > > - Special considerations apply to use of LL addresses beyond > > those associated with "normal" IPv4 addresses, and to some > > degree even beyond those associated with "private" IPv4 > > addresses, and > > This is true, but all these aspects are dealt with clearly in the > specification. False. They are scarcely touched on by the specification, and in cases where the specification does mention these issues it imposes unreasonable requirements on both existing and future applications. (my previous LC comments didn't address the actual text - this is one area where comments on the actual text are also needed) > > > - The introduction of LL facilitates new communications paths. > > Indeed this is its entire purpose. > > > > From these broad classes the following questions are derived, > > which this document attempts to answer: > > > > - Can use of LL be avoided if it is found to cause problems? > > The specification considers how to use LL not how to avoid it. true, but the fact that the specification essentially forces the user to use LL is probably it's most serious flaw. > > - Will the capability to send messages using LL addresses > > cause problems for networks, hosts, or applications? > > They may. This is acceptable. I think it's inexcusably arrogant for this WG to assume that it has either the technical ability or the authority to determine whether or not the harm that LL will cause is "acceptable" for the wide variety of applications, networks, and users that it will affect. > These issues are considered at length in the specification, along with > warnings and limitations to applicability statement. This is not > acknowledged in any way in Keith's remarks. again, the worst problem is not that LL causes problems for some apps, hosts, or networks, it's that there's no way to turn LL off. > [...] > > > 1. Can use of LL be avoided if it is found to cause problems? > > > > 1.1 LL will be imposed on applications, hosts, and networks > > > > Several existing Apple and Microsoft platforms currently ship with > > a pre-standard version of this technology. > [...] > > These two vendors supply operating system software for the > > vast majority of computing platforms in use today, especially > > 'desktop' and 'laptop' platforms. Therefore it seems likely > > that most 'desktop' and 'laptop' computers sold, and most > > operating system upgrades for such systems, will support the > > IETF v4 LL standard soon after it is adopted and for the next > > several years. > > This is the reason that a standard to guide implementation and to > arrive at common practice is so important. It's also the reason that a standard needs to avoid causing harm. > > According to the descriptions of existing implementations in the > > appendix of this document, several existing implementations > > do not attempt to claim and/or use LL addresses if and when a DHCP > > server responds to queries from the host. This provides a readily- > > available means of allowing a network to suppress use of LL addresses > > by these implementations. However this feature is specifically > > forbidden in the draft specification, and the draft specification > > provides no other mechanism with which use of LL addresses may be > > disabled by either a host or a network. > > This is an *inappropriate comment.* No, Erik, it's entirely appropriate. The fact that the WG has discussed this before is irrelevant if the WG did not fix the problem. Again, these comments are input to IESG deliberations, not WG deliberations. The WG was cc'ed on these comments as a courtesy to the WG, and to allow the WG to respond to those comments more quickly and more directly than would normally be the case. > > (Note that while the claim-defend protocol provides a means to > > deny a host the ability to claim any particular LL address, > > it provides no means to discourage a host from attempting to > > claim other addresses, indefinitely, at a rate of up to one > > address per minute per host) > > This is an insignificant amount of traffic even with many hosts on > a low bandwidth shared access network. One must consider that there > is a large amount of ARP traffic on networks with fixed addresses > already. If you're seriously proposing that the way to "turn off" LL on a network is to defeat the claim-defend protocol, then the document needs to say so. and the impact needs to be analyzed. Offhand I think (a) it's a pretty inefficient way of doing it, (b) the interrupt overhead might be onerous for some hosts, and (c) might also be onerous for some networks - particularly if the per-minute broadcasts were to sync up - as periodic broadcasts tend to do on loaded networks. But for the present document I'll continue to claim that there's no good way to "turn off" LL and the problems it causes. > > Therefore, the draft specification would impose LL on > > existing hosts (as they are upgraded to later operating systems), > > applications, and networks, with little means of avoiding it or > > disabling it should it be found to have an adverse effect. > > This is *not a substantive statement.* Any new protocol introduced > to the network is 'imposed' upon existing hosts in the same way. False. Most protocols are quite obviously optional. I can think of few other protocol extensions that a) affect every application that uses IP, and b) insist that they always be enabled. > Existing hosts which do not care about the new protocol will ignore > it except in so far as it generates more traffic. perhaps true, but "hosts" are not the only affected party. > In this sense, > the above is an *incorrect statement,* as LL autoconf does not > generate much traffic. False. "much" is a relative term. I tried to explore this in sufficient detail to see when "much" was "too much". I agree that in most cases LL autoconf does not generate "much" traffic, but I also was able to identify a few corner cases where the impact could be significant. I believe that IESG is in a much better position to make decisions about whether the impact is acceptable if it understands the cases in which the impact is likely to be significant. > > 1.2 Conditions under which LL traffic will appear > > > > Since presumably LL will only affect applications, hosts, or > > networks if it is actually used, in order to understand whether > > LL can be avoided it is necessary to understand the conditions > > under which LL traffic will appear. > > Huh? > > We are discussing the LL autoconf protocol, not avoiding it. We > are not discussing alternatives. We are discussing only if the > protocol the WG and leading members of industry have put forth > is fit for publication. if avoiding the LL protocol is operationally necessary for some parties, then whether the protocol can be avoided is a valid question for the technical evaluation of the protocol. Perhaps the WG has failed to provide for that, but I argue that by failing to provide for that the WG has failed to produce a protocol that meets the requirements for standards track. > > The claim-defend protocol will be invoked whenever a host > > wishes to allocate a link-local address. The draft > > specification seems to assume that this will happen at > > power-on or bootstrap time (after a random delay). > > The specification also indicates that autoconfiguration can be triggered > due to media sense, while running. The specification does not rule out > autoconfiguration at any time subsequent to booting. we concur on this. > > Other implementations may be consistent with the letter of > > the draft specification. For instance, a host could allocate a > > link-local address whenever an application requested to send > > traffic to a link-local address, or whenever an application > > explicitly requested to listen for traffic on a link-local > > address. However such implementations would probably violate > > the stated intent of the draft specification to make link-local > > addresses "available all the time". > > This is an implementation detail, left to vendor discretion. it's actually a fairly important detail because it can tremendously affect the impact on applications. > > Use of the claim-defend protocol continues as long as the > > LL address is "in use" by that host, though no definition > > of "in use" is given. While a particular platform might > > provide a nonstandard means to disable use of LL addresses, > > causing them to no longer be "in use" by the host, it seems > > consistent with the intent of this specification to assume that > > most hosts that implement this specification will claim a > > link-local address at power-on or bootstrap time, and > > defend or claim a new address on a link during any period > > that the host is operating and has access to the link. > > This is not a substantive statement. Just as a vendor has discretion > when to use DHCP and when not to, a vendor has discretion when to use > V4LL and when not to. this is not clear from the specification, especially when the specification states that LL addresses should be available all the time. > > It is therefore assumed that the claim-defend protocol will > > unavoidably appear on any network to which LL-capable > > hosts are attached, and that in due time this will apply to > > essentially all IP-based networks. > > This is not a substantive statement. False. It's used to support the argument (later on) that the claim-defend protocol can cause harm in corner cases. If the claim- defend protocol could be avoided, then the harm that it occasionally does could also be avoided, and that protocol would not impose the same burden on hosts and networks that this one does. > This is little more than saying that ARP will unavoidably appear on > any network with IPv4-capable hosts. The only substantive difference is in the frequency of broadcasts, as my comments took pains to point out. Still there are cases where this will make a difference. I've seen a sane IP stack melt down when connected to a network with lots of broadcast packets, because its network drivers imposed too much overhead. so I know it can happen. > > b. LL addresses used as IP source or destinations > > > [...] > > The material in this section largely restates concerns which were > brought up in the preceding IETF last call for this document. A > new section was added to the specification which addresses these > concerns. In particular, draft 7 states > > Use of IPv4 link-local autoconfigured addresses presents additional > challenges to writers of applications and may result in existing > application software failing. > > This is acceptable to the (rough consensus expressed by the) WG. Whether it is acceptable for PS status is a separate question. > > > [...] applications [...] send unicast traffic [...] to > > specific hosts [...] only when those destinations are > > somehow exposed [...] to that application. [...] > > > Such exposure can occur via a variety of means: > > > > - explicit configuration by users or operators > > - a general-purpose service discovery protocol > > - a referral from another component of the application > > - a referral from a different application > > (for example, a file obtained by FTP can request that > > form data be sent via HTTP to a literal IP address) > > - being associated with the name of a host, service, > > or other resource that is declared to be useful > > (in DNS or another name lookup service) > > - from a host's network interface or ARP tables > > - from the source address of an IP datagram or connection > > - from network management protocols such as SNMP > > While true, this has no bearing on v4LL addressing. False. the exposure of v4LL addresses to applications that quite reasonably expect well-behaved (stable, global, and/or routable) v4 addresses will cause problems for those applications. the point of this section is to illustrate that e.g. merely not exposing them in DNS is not sufficient to prevent those addresses from causing problems. > > Some sources of LL address exposure, and thus some sources of > > LL use, are controllable. For instance, operators can be > > cautioned to eschew exposure of LL addresses in DNS, service > > discovery protocols, etc., and thereby to limit the use of LL > > addresses to some degree. > > This is only marginally true. Service discovery and naming protocols > which use LL addresses will operate peer to peer, which is to say, > the operator will have very little control over whether they are > used. Appletalk and especially netbios are examples of this. I said "some" sources were controllable. certainly not all of them are, which was the very point I was trying to make. > > However, application behavior varies widely. Some applications > > use the source addresses of IP datagrams as destinations of > > subsequent datagrams, or use such addresses in referrals to other > > components. (For instance, in a NATted environment the source address > > is more reliable than an address passed in the payload). Other > > applications provide referrals to other components using addresses > > obtained from interface tables. (For instance, to help the > > application to cope with limited-scope addresses by listing > > each of a host's addresses in referrals to other components > > of the application, allowing components to try multiple addresses > > until they find one that works.) Such applications will use LL > > addresses and generate LL traffic without being explicitly > > configured to do so. > > This point was made in the preceding IETF last call comments. Indeed. I'm repeating this and other points in the hope of making them clearer than last time - on the assumption (and also based on some feedback) that my previous comments were unclear. > > Thus it is not generally possible to insulate hosts, networks, > > or applications from LL merely by eschewing use of LL addresses > > in managed name lookup services, service discovery protocols, and > > application configuration. The degree to which LL addresses are > > used "accidentally" depends on the specific set of applications > > that are used on a particular network. This can be expected > > to vary considerably from one network to the next. > > This is correct. The ZEROCONF WG (rough) consensus is that this is > acceptable. Again, it's not within the purview of this WG to determine what is acceptable for all applications, hosts, or networks that use IP. > The rhetorical emphasis of the statement (eschew, accidentally, etc) > indicate that the author considers the protocol to be undesirable and > unavoidable. you're reading too much into this. actually I believe the protocol to be highly desirable - *provided* that (a) it doesn't ultimately compromise the flexibility of the network to support existing kinds of applications (granted that the applications may need some tweaking) and (b) reasonable measures are taken to minimize harm to existing apps, hosts, and networks (which is why there needs to be a way to disable it). I don't think either of these is unreasonable or requires substantial changes to what is being proposed. but I'm extremely frustrated with this WG's refusal to fix these problems and its willingness to say (in effect) "screw the existing apps... LL works fine on my laptop". > If this were the case, there would be great concern over > the use of Netbios on LANs, which has most of the same functions Keith > describes (local and dynamic name to address resolution, entirely beyond > an operator's ability to control or avoid). This concern does not exist. Netbios is not IP, and applications written to expect IP behavior are not generally affected by Netbios. > > 2. Will the resources consumed by LL traffic cause problems for networks, > > hosts, or applications? > > > > 2.1 Effects of LL resource consumption on network operations > > > > a. bandwidth consumption > > > > - unicast LL traffic > > > > Unicast LL traffic imposes no more overhead on the local network > > than unicast traffic to a local routable address. It is possible > > that introduction of LL will increase the amount of traffic on a > > network by facilitating new applications. We would generally > > consider this a sign of success, though the possibility exists > > that increased usage would cause short-term operational problems > > for networks that are nearly saturated. > > This is argument fails to introduce material not previously covered > by the previous last call. It is also a very weak argument. The discussion of this case is included only for completeness, so that all of the cases are covered. The introduction to my comments made this clear. Indeed these comments were not written as "arguments against LL". They were written as "what kinds of problems can LL cause?". the idea is to clearly identify the problems so that the fixes become apparent, not to defeat adoption of LL. > > b. network availability / reliability / stability > > > > LL does not appear to affect network availability or reliability > > as long as the additional traffic does not cause the network to > > become saturated. > > This statement disagrees with the consensus of the WG. Network > availability, reliability and stability are radically improved for hosts > using v4LL as they can operate in environments where IP hosts fail > otherwise. For example, in the presence of improperly configured DHCP > servers, or the absence of configuration and knowledgeable operators. Agreed that LL _can_ increase _effective_ network availability in some cases where the failure of a DHCP server could cause an app to fail that might work in the presence of LL. But this particular section is about the effect of bandwidth consumption, and in general these comments are about the harm that can be caused to existing functionality. It is of course the case that LL provides new functionality, including in some cases the ability to use networks when DHCP etc. is down or not present. I do not think it's axiomatically appropriate to "trade off" existing functionality for new functionality, especially not without a clear understanding of what existing functionality is being compromised. > > 2.2 Effects of LL resource consumption on hosts > > > > a. Hosts which implement LL > > > > Hosts which implement LL can reasonably be expected to cope > > with the amount and type of traffic generated by LL on a > > reasonably-sized network. > > This traffic is negligible and acceptable within the domain of > applicability of the protocol. See Section 1.2. agreed, and that's pretty much what you're expected to conclude from reading this section. > > b. Other hosts > > > > Hosts which do not implement LL can still be expected to > > implement ARP on interfaces that require it, and for the most > > part LL usage is consistent with ARP. There is some chance that > > platforms which do not implement LL might be confused by LL's > > requirement that LL ARP replies be sent using link-layer > > broadcast instead of link-layer unicast (draft spec, bottom page 11). > > This has not proven the case so far, where the protocol has been used. > It is not required that a protocol prove that it will not break any > existing code to advance to proposed standard. perhaps not explicitly, but surely operational concerns are worthy of consideration? and IIRC it's not clear from the spec whether existing implementations use broadcast for LL ARP replies in all cases (as opposed to just claim-defend). > > c. All hosts > > > > The need to process additional broadcast packets generated by > > LL ARP replies may result in increased overhead for all hosts, > > and in increased hardware costs for new hosts to permit them > > to handle an increase in interrupts needed to broadcast packets, > > even if they are promptly discarded. This seems unlikely to > > significantly affect general-purpose hosts (desktops, laptops, > > servers) but may affect "appliance" or "fixed-function" hosts > > (especially those designed for the consumer market), which > > which operate with less margin in CPU cycles. > > How significant are these effects? IMHO, not very, in most cases. which is why I said "this seems unlikely to significantly affect...". however I have seen hosts affected by large #s of broadcasts on an Ethernet, and most of those broadcasts were ARPs. so I know that it _can_ happen. > This argument explores only the limit cases, which is beside the point. the limit cases are not beside the point - they are the only thing that give you an idea of whether the design decision is reasonable. that doesn't mean the limit cases should all be accommodated - but unless you take the time to understand which cases could cause problems you have no reason to have confidence that the protocol will not cause problems. > This protocol is used on networks with a handful of hosts: homes, > small offices, conference rooms, ad hoc networks. In these cases, the > overhead of the protocol is modest. this protocol, as currently defined, will be used (whether it is wanted or not) in essentially every IP network in existence. whether the overhead is modest in small networks is irrelevant if the overhead causes problems for large networks. > > 2.3 Effect of LL resource consumption on applications > > > > In general, an application should consume no more resources > > for LL traffic than for traffic between routable unicast addresses. > > Why not? Why shouldn't an incremental cost be acceptable? > The incremental cost is extremely modest, as has been argued. perhaps my wording is unclear here - what I meant is that I don't expect the additional resources consumed by LL traffic to impact applications. > > However, if an application naively responds to LL traffic in a > > situation where use of LL will cause the application to fail, > > and that application persists in trying to use LL, the application's > > performance may be adversely impacted. > > 7. Application Programming Considerations > > Use of IPv4 link-local autoconfigured addresses presents additional > challenges to writers of applications and may result in existing > application software failing. merely mentioning that LL may cause problems for apps does not automatically make the document meet the requirements for proposed standard. surely it's appropriate to at least attempt to minimize those problems? > > 3. Will the visibility of LL addresses by networks, hosts, and > > applications, cause problems for networks, hosts, or applications? > > > > 3.1 Effects of LL visibility on networks > > > > Since LL addresses are not tightly bound to hosts, there is no > > association of host identity with LL address, it becomes necessary > > for traffic monitors to associate hosts with layer 2 addresses rather > > than layer 3 addresses, even if they are monitoring layer 3 traffic. > > This protocol does not facilitate traffic monitoring. This is fine. again, (a) I'm trying to examine a wide variety of possible impacts for LL, and (b) it's not within the purview or expertise of this WG to determine what is "fine" for operations of others' networks. > > With the introduction of LL, DNS cannot be used to provide reliable > > address-to-name mapping even on networks where it might be reliable > > for routable addresses (e.g. when DHCP and DNS are coordinated). > > Yes. Section 2.9: > > As link-local addresses may change at any time and have limited > scope, storing link-local addresses in the DNS is not well > understood and it is NOT RECOMMENDED. the point of this comment is that LL impairs existing network monitoring functionality. there is increased difficulty in monitoring network traffic between routable addresses, compared with monitoring LL network traffic. one way in which the difficulty is increases is that existing techniques of associating traffic with host names (e.g. looking up the L3 address in DNS) no longer work. this is one of many reasons that a network might want to disallow LL traffic. > > > 3.3 Effects of LL visibility on applications > > [...] > > LL addresses become visible to apps [...] will then be used > > by some apps that use addresses in referrals to other apps. > > > > a. address scope problems due to referrals > > > > Because LL address-to-host bindings are only valid on a > > particular link, when applications use LL IP addresses in > > referrals to other applications (or other components of the > > same application) those referrals may fail when those IP > > addresses are not valid for the host that received > > those addresses. > > > > b. address stability problems with referrals > > > > Because LL address-to-host bindings are only valid on a > > particular link, applications which use LL IP addresses in > > referrals to or from other applications may fail when > > those IP addresses are no longer bound to the same host > > as when the referral was generated, even if the host which > > received the referral has access to the same network link > > for which the LL address was valid. > > This point was raised in the preceding IETF last call. Section 7.2 > of the document was added. WG (rough) consensus supports the current > text (warning and admonishing the implementor to consider these > issues). > > These issues arise with all scoped addresses. again, I don't think it's appropriate for the zeroconf WG to impose constraints on all present and future applications running on all IP networks. the zeroconf WG lacks the necessary breadth and expertise (not to mention charter) to make such decisions. and yes, these issues do arise with scoped addresses (and I'm working on a draft about that) - but the fact that the problems exist elsewhere and for other reasons is not a justification for this WG to exacerbate those problems. > > 4. Will the special considerations that apply to use of LL addresses > > cause problems for current or future applications? > > > > a. address scope problems with multiple interfaces > > b. non-uniqueness of addresses > > c. address stability effect on connection duration > > These issues are well documented in the v4LL specification, as well > as a thorough discussion of application implications in section 7. > These identical points were raised in the preceding IETF last call. > (Rough) WG consensus supports the current text. again, if WG consensus is that it's okay to cause harm to current apps, then I hope IESG has the good sense to tell the WG that it's wrong. > > 5. Will the capability to send messages using LL addresses cause > > problems for networks, hosts, or applications? > > > > a. security problems > > > > LL facilitates communications between hosts under circumstances, > > and over paths, which did not previously permit communication. > > In the case of wireless links the introduction of LL can cause > > purely "accidental" communications paths to be established, > > I leave aside the wireless aspect of the comment, because I believe > it exacerbates the issue, but is not fundamental to it. the difference is that plugging in a wire requires an explicit act on the part of a user - if the user wants to avoid connecting to a network for fear of security problems he can avoid plugging in the wire. with a wireless network the connection can potentially exist even though the user has taken no explicit action at all. > Configuration of IP has been so difficult for IP that it either > required manual address configuration or DHCP. This has no longer > been true since 98. A Windows system using v4LL and Netbios allows > communication without configuration (except of some names on the > host). Similarly, Appletalk has allowed hosts without configuration > to communicate. yes, but the vast majority of existing IP networks use either manual address configuration or DHCP (or a combination of both) and so the experience "since 98" of the impact on production networks is actually fairly minimal. > In neither case is this communication 'accidental.' Applications > communicate using established protocols, users locate resources > by name and type. The fact that the addresses they use are > established automatically is unimportant. here's the thing - if there was previously a barrier that prevented accidental communication between hosts, and that barrier is removed by the introduction of LL, then LL may expose a security hole even though that hole is incidental to LL. the point is that sometimes these barriers are useful, or even necessary, and LL should not insist that these barriers be removed as a matter of standards compliance. > The question is whether use of v4LL addresses constitutes a 'different > path' than use of configured addresses. The answer is no. it would be more correct to say that introduction of LL may remove a barrier that previously existed to use of paths that previously existed. > > as hosts with wireless links can connect to one another in the > > absence of any explicit effort by users or administrators to > > facilitate such communications (and despite efforts to limit > > such communications). > > This is again a de jure argument. The possibility of doing this has > been true de facto for 5 years. false, because for most deployed implementations the LL will have been disabled as a consequence of normal network operations. > > This introduces new risks for both networks > > and hosts, especially networks and hosts that rely (as most do) > > on the ability to do some kind of ingress filtering as part of > > their security implementation. > > This comment is wrong in that it states there are new risks and > objectionable in that it introduces the requirement for ingress > filtering. > > From a security perspective, it is important to document the risks > introduced by use of the protocol. This has been done by the v4LL > spec. > > There is no requirement to support ingress filtering in order to > advance a protocol to proposed standard. the point is that existing networks rely on ingress filtering for security (for better or worse). bypassing this filtering creates an operational concern, which IMHO is appropriate for IESG to consider. > The domain of applicability of this protocol is an IPv4 link, which > uses ARP. Anyone with access to a link that can listen to and > inject ARP messages can already spoof L2 and L3 addresses. There > is no force in the argument above that anything new has been > introduced. If anything is new, it is that hosts can communicate > easier, with fewer hurdles. yes but those hurdles were at least occasionally useful from a security perspective. [security example omitted] > This example has nothing specific to do with v4LL. LL removes one barrier to an attacker exploiting the wireless channel - with LL the laptop can connect to the wireless channel whether or not it is explicitly configured to do so. At least with DHCP you can usually turn it off. > v4LL may facilitate illicit access but it neither allows it nor > significantly changes the fundamental risk. I think it does significantly change the risk, precisely by 'facilitating illicit access'. > > Another scenario is similar -- a nomadic laptop which > > connects to various ad hoc LL networks as it moves potentially > > exposes the laptop to new security threats in each new network. > > A laptop which was compromised using LL may then be used to > > attack a company's private network when it is connected to > > that network. > > This comment does not address v4LL directly and poses unreasonable > expectionations. again, the point is that LL allows the laptop to connect to networks completely without the user's knowledge or approval. this is probably not desirable. > > b. support issues > > > > In addition to difficulty of traffic monitoring, introduction of > > LL may cause application failures which are difficult to isolate, > > diagnose, or fix. This causes issues for those who support networks > > and network-based applications. > > This is true. It is much much worse if vendor implementations vary and > there is no standards based document one can refer to and attempt to > hold vendors accountable to. well, in this case, most of the existing implementations seem to be better (in the sense that they have less impact on existing managed networks) than the standard. so while in general I think standardization is a Good Thing, it's not axiomatic that a poor standard is better than current practice. > Without a standards track document, it > will be extremely difficult to understand what v4LL behavior is or > should be. This is one of the main reasons why publication of the > specification as a proposed standard is urgent! don't you think it's appropriate to understand what v4LL behavior "should be" in order to minimize impact _before_ publishing it? hurried publication of a flawed standard can do more harm than good. > > 6. Summary > > > > - If the draft specification is implemented in its current form, > > it is impractical to avoid imposition of LL on networks, hosts > > and applications using current measures. > > Or from a users perspective, it is impossible to be prevented from > local communication by an improperly configured network. Home users > will not be prevented from using local networking by a home gateway, > cable modem, etc. Who is imposing on whom? Home users are not prevented from using local networking in any case. But it's not axiomatic that having hosts talk to each other without any configuration or approval is better than requiring that configuration or approval. > > - LL seems unlikely to cause resource depletion for most networks. > > However it may cause resource depletion in nearly-saturated > > networks and large L2-switched networks. Some limited function > > hosts may not be able to cope with additional CPU load due to > > additional broadcast packets on large networks. Applications which > > are incompatible with LL and which use LL "accidentally" may > > cause additional consumption of network resources if they > > persistently retry operations that failed due to LL. > > There is a domain of applicability for the protocol and well > specified mechanisms to cause it to fail gracefully in networks > which exceed its intended scope. where are those well-specified mechanisms? I don't see them. > It is not reasonable to require a proof that a protocol will not > harm any conceivable network before it gets advanced to proposed > standard. strongly disagree. it's quite reasonable for new standards to avoid breaking existing standards. what's unreasonable - no, downright irresponsible - is for a single WG to assume that it has the authority or the expertise to decide when it's okay to break existing standards or applications, without even bothering to do an analysis so that it could understand what is being broken! > > - Imposition of LL circumvents existing security mechanisms and > > creates additional security risks for networks, hosts, and > > applications. > > This has been shown to be false in the arguments above. false. > > - Imposition of LL creates new support burdens for users, networks, > > and application maintainers. > > While this may be true, one could argue that IPv4 creates its own > support burdens for users network and application maintainers which > are significantly alleviated through adoption of v4 LL. This is > certainly the opinion of WG participants (from major client and > network infrastructure vendor companies) involved with this work. IPv4 certainly does have support burdens. but LL doesn't alleviate them; it increases the number of cases that have to be dealt with. > > 7. Recommendations > > > > - There needs to be a standard way for managed networks to disable LL > > traffic, both on the network and on hosts connected to that network. > > This point was made in the last IETF last call and rejected by the WG. we agree that the WG has spoken. this is input to IESG. > > - As a matter of standards compliance, hosts need to be required > > to provide a means to disable LL traffic, both entirely and on a > > per-interface basis. > > Vendors are free to add this feature. There are many vendors who > produce equipment for which any manual configuration is impossible. > It is definitely not acceptable to exclude this equipment from the > protocol's domain of applicability. first, the spec is not clear that vendors are free to add this feature, and it implies the opposite. second, the feature is operationally necessary for some networks. third, manual configuration is not the only means by which LL can be disabled even on a per-interface basis. (it should be sufficient to control it from the network with that granularity) > > - Because there are valid reasons to disable LL, and for other reasons, > > the specification should discourage the expectation that a host that > > implements only LL can expect to communicate with other IP hosts, > > even those on the same network segment. Hosts should implement DHCP > > and/or support static address configuration if they wish to have > > the capability to communicate with other hosts using IP. > > This statement was made and rejected during extensive debate on the WG > mailing list. Keith was in the minority (of one) during these debates. > Further, this point was included in the previous set of last call > comments and rejected by WG consensus action. again, this is not for the WG to decide. > > - Even when LL is enabled on a host or an interface, there needs > > to be a way of isolating existing applications from LL traffic > > and from the visibility of LL addresses. > > Others disagree. perhaps they don't know what they're talking about. I tend to disregard arguments of the form "the apps on my laptop work just fine" when I work daily with apps that will be affected by this. > Under most circumstances, those in which v4LL is likely to be used, as currently defined, v4LL is likely to be used on all networks, whether the users or network admins want it or not. > LL works just fine and not bother most common applications at all. it's not sufficient for LL to work for "most common applications" those are the wrong criteria. > Address assignment will be stable and communication, restricted to > the LAN anyway, will function fully as the application expects. false. > If there is a link local web proxy most users will not know the difference. there are a lot more applications out there than the web. > We accept that some applications will not work with v4LL addresses or > may work less than perfectly in some circumstances. The user has > choices. She can get a new application that works better. She can > demand better software from her vendors. She can demand a switch to > turn link local addressing off. Last I checked, this can be done > using all versions of Mac OS and Windows that support v4LL. since it's obviously necessary, why not require it as part of the standard? > Scoped, renumberable address awareness is required for applications to > support IPv6, in any case. that's a separate problem that needs to be solved elsewhere. the existence of a problem with v6 is not a justification for introducing a problem to v4 - especially to existing apps that aren't written with v6 in mind. > > - LL should be disabled by default on wireless interfaces, requiring > > explicit configuration of such interfaces to support LL. Enabling > > the wireless interface to support LL on a specific wireless network > > should be separate from enabling a wireless interface to support LL > > on an ad hoc network. > > The WG has consistently disagreed with Keith on the question of whether > v4LL should be on by default and whether it should be turned off. the WG has consistently disregarded the impact of its proposals on existing apps and networks. it's entirely possible that the WG is wrong. > The only argumented presented above concerning the use of v4LL over > wireless links was in the security section. I demonstrated that v4LL > exposes no new security threats over that of an unsecured link layer > using insecure neighbor discovery. actually you demonstrated that it does introduce new security threats, by removing barriers to communication that were previously there and which in many cases were previously relied on to provide security. > > - When wireless interfaces are allowed to use LL on ad hoc networks > > (as opposed to configured wireless networks), there should be a > > means to prevent applications from being exposed to traffic from > > such networks, so the host will accept traffic only for those > > applications that are believed to be safe from arbitrary, anonymous > > traffic. > > There are mechanisms to do this: L2, L3 and L7 security. It is > inaccurate to blame address autoconfiguration for reduced security in > networks without these mechanisms. so you create a problem and then claim that it's somebody else's problem... > > - More study is needed before the security implications of LL can > > be fully understood. LL should not be deployed until those > > implications are understood and suitable countermeasures exist. > > It is absolutely inappropriate to insist that a protocol not be > advanced solely on the basis of it not being fully understood. we *know* this protocol will do harm, and you're insisting that it be standardized anyway, in clear violation of both the spirit and the letter of 2026. > There has been careful security assessment of this protocol, that > has not been challenged in this set of remarks. Further, there is > going on five years of actual deployment. existing deployment is irrelevant as it is not of the same protocol that is being proposed here. > > However if deployed in the form specified in > > the draft specification, it will break some applications, > > Yes, it could. The WG accepts this and text specifically warning > and admonishing implementors was added as a result of the previous > IESG last call. this is not for the WG to "accept" and impose on users. > > invite new kinds of attack on hosts and networks, > > The comments above dispute this point. no, they validate it. Keith From owner-zeroconf@merit.edu Tue Sep 24 18:23:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14049 for ; Tue, 24 Sep 2002 18:23:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CF5069128F; Tue, 24 Sep 2002 18:25:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9CA2F91291; Tue, 24 Sep 2002 18:25:04 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 888FA9128F for ; Tue, 24 Sep 2002 18:25:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 63DF15DF09; Tue, 24 Sep 2002 18:25:03 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 300FA5DE4D for ; Tue, 24 Sep 2002 18:25:03 -0400 (EDT) Received: from procyon (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id BEB0959889; Tue, 24 Sep 2002 23:25:06 +0100 (BST) Message-ID: <031701c26419$39518900$5801a8c0@localdomain> From: "Philip Nye" To: "Keith Moore" , "Erik Guttman" Cc: , , "Keith Moore" References: <200209241959.g8OJxQ024650@astro.cs.utk.edu> Subject: Re: last call comments on draft-ietf-zeroconf-ipv4-linklocal-07 Date: Tue, 24 Sep 2002 23:25:01 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit While it is late in the day, I want to back up Keith's concerns here. There is big difference between the major commonly deployed LL implementations and the current proposal in that those implementations use an "either/or" approach while the current proposal mandates "as well". While these issues have indeed been recirculated ad-nauseam by Keith, I have seen little in the way of hard technical counters to his arguments and justification for the requirement in the draft seems weak. In the light of this difference the argument that LL "protocol has been widely deployed for some time" is almost entirely spurious yet that seems to be the main thrust of the argument. At the very least the difference means that LL traffic is likely to appear all sorts of places where it has previously been absent because hosts were configured with alternatives. regards, Philip Nye From owner-zeroconf@merit.edu Tue Sep 24 22:42:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18966 for ; Tue, 24 Sep 2002 22:42:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9157E9120E; Tue, 24 Sep 2002 22:43:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F2E49121B; Tue, 24 Sep 2002 22:43:41 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3EAAF9120E for ; Tue, 24 Sep 2002 22:43:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1E9615E136; Tue, 24 Sep 2002 22:43:40 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id B159C5DD8F for ; Tue, 24 Sep 2002 22:43:39 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA29446 for ; Tue, 24 Sep 2002 22:43:39 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA16063 for ; Tue, 24 Sep 2002 22:41:33 -0400 (EDT) Received: from [10.0.0.2] (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id WAA00643 for ; Tue, 24 Sep 2002 22:41:32 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 24 Sep 2002 22:41:30 -0400 Subject: Re: last call comments on draft-ietf-zeroconf-ipv4-linklocal-07 From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <031701c26419$39518900$5801a8c0@localdomain> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 09/24/2002 18:25, "Philip Nye" wrote: > There is big difference between the major commonly deployed LL implementations > and the current proposal in that those implementations use an "either/or" > approach while the current proposal mandates "as well". While these issues > have indeed been recirculated ad-nauseam by Keith, I have seen little in the > way of hard technical counters to his arguments and justification for the > requirement in the draft seems weak. In the light of this difference the > argument that LL "protocol has been widely deployed for some time" is almost > entirely spurious yet that seems to be the main thrust of the argument. > > At the very least the difference means that LL traffic is likely to appear all > sorts of places where it has previously been absent because hosts were > configured with alternatives. While I will definitely agree that we have not seen this *type* of LL deployment before, that is the only change. LL traffic is not new, neither are ARP broadcasts. In fact, not much with this spec is *new* in the sense of "Not ever seen before", but rather "Never been implemented like this before". Rather than making things harder to troubleshoot, I say it will make things easier, because you don't have as much new info to learn. It's rather like going from a '68 Beetle to a 2003 Beetle, as opposed to going from a '68 Beetle to a Boeing 777. The security/virus arguments are just FUD, and belong in dev/null. LL introduces nothing new in this arena. john -- John C. Welch IT Manager MIT Police (617) 253 - 3093 work (508) 579 - 7380 cell (617) 253 - 8822 fax From owner-zeroconf@merit.edu Wed Sep 25 05:50:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20391 for ; Wed, 25 Sep 2002 05:50:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF6E19129F; Wed, 25 Sep 2002 05:51:46 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7AADF912A0; Wed, 25 Sep 2002 05:51:46 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4A3FD9129F for ; Wed, 25 Sep 2002 05:51:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2D6FD5DDB0; Wed, 25 Sep 2002 05:51:45 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id C823C5DDA8 for ; Wed, 25 Sep 2002 05:51:44 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03312; Wed, 25 Sep 2002 03:51:42 -0600 (MDT) Received: from sr-ehdb03-01 (sr-ehdb03-01 [129.157.142.202]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8P9pel17402; Wed, 25 Sep 2002 11:51:40 +0200 (MEST) Date: Wed, 25 Sep 2002 11:51:41 +0200 (MEST) From: Erik Guttman X-Sender: erikg@sr-ehdb03-01 Reply-To: Erik Guttman To: Keith Moore Cc: Erik Guttman , iesg@ietf.org, zeroconf@merit.edu Subject: Re: last call comments on draft-ietf-zeroconf-ipv4-linklocal-07 In-Reply-To: <200209241959.g8OJxQ024650@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Keith, Thank you for clarifying your position. I believe the matter is now in the hands of the IESG who have to make a decision about advancing the draft or not. Your position is clearly that of the 'rough' part of the consensus. I reply only to a few of the points below. > 3. Most of the delays in getting this document out the door are due to > the working group's failure to either consider, or to adequately > address the problems with the document. As WG chair, and now coauthor of this document I accept a large part of the blame for the delays. I should have pushed for 'rough consensus' earlier. The debate we are reiterating will not change the outcome. > > I want to point out that this (late) review is the second such > > response to an IETF last call. Indeed, the only reason for the > > second last call is the difficult long process in responding to > > Keith's previous set of issues. > > you make it sound like I'm the one causing the problem when it's > the WG that has failed to adequately consider those issues in the > first place. in other words, you're trying to cast this as > a personal issue rather than a technical one - which I find highly > inappropriate. The process by which disagreements are supposed to be resolved is the last call. It is to your credit that you worked long and diligently, despite opposition to see the specification improved. And it has substantially improved due to your input. That said, it is unfortunate that you did not bring up these issues during the WG last call on the changes which were intended to answer your objections in the first IETF last call! > > Link local IP is on by default in a significant percentage of internet > > hosts and has not proven disruptive. > > False. As the draft spec clearly indicates, for most of these implementations > LL is not "on" whenever DHCP is in use, and my experiments with a couple of > these implementations indicate that (for those I've tested) LL is not "on" > when an address is statically assigned. Thus I suspect that LL is not > "on" by default for the vast majority of Internet hosts. Many environments lack DHCP. LL is on by default in this case in most PCs and Macs today. In the case where addresses assigned are used instead of LL addresses, this does not invalidate the point that LL is on by default. > > > - The introduction of LL facilitates new communications paths. > > > Indeed this is its entire purpose. > > > > > > From these broad classes the following questions are derived, > > > which this document attempts to answer: > > > > > > - Can use of LL be avoided if it is found to cause problems? > > > > The specification considers how to use LL not how to avoid it. > > true, but the fact that the specification essentially forces the user > to use LL is probably it's most serious flaw. No host is forced to use LL. Today, no one *is able to communicate with* an unconfigured host. Hosts that do not support LL will be in the same position as they are in today. > But for the present document I'll continue to claim that there's no > good way to "turn off" LL and the problems it causes. You are right. There is no way to "turn off" LL. This is not part of the protocol. The WG input to the IESG does not have this feature. > > > Therefore, the draft specification would impose LL on > > > existing hosts (as they are upgraded to later operating systems), > > > applications, and networks, with little means of avoiding it or > > > disabling it should it be found to have an adverse effect. > > > > This is *not a substantive statement.* Any new protocol introduced > > to the network is 'imposed' upon existing hosts in the same way. > > False. Most protocols are quite obviously optional. > > I can think of few other protocol extensions that > a) affect every application that uses IP, and > b) insist that they always be enabled. No one is proposing that this protocol be anything other than an elective standard. > if avoiding the LL protocol is operationally necessary for some parties, > then whether the protocol can be avoided is a valid question for the > technical evaluation of the protocol. We have yet to hear that this is an issue from network operators, except for one case: a university which wanted to prevent students from using LANs without first registering their equipment. This led to RFC 2563 "DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients" This standard has not yet been implemented, but if customers demanded it, I am sure vendors would support it. > this is not clear from the specification, especially when the specification > states that LL addresses should be available all the time. The specification does not mandate *use* of LL, when a host supports it. Nor does it state when a host can or cannot stop using LL autoconfiguration. The specification simply describes how the protocol works, *when* it is used. On this point the spec says only This document describes a method by which a host may ^^^ automatically configure an interface with an IPv4 address in the 169.254/16 prefix that is valid for link-local communication on that interface. and This document describes a method by which a host may automatically ^^^ configure an interface with an IPv4 address in the 169.254/16 prefix that is valid for link-local communication on that interface. and in previous implementations, link-local addresses were only available after a host had tried and failed to contact a DHCP server. This standard removes that restriction, making link-local addresses available all ^^^^^^^^^^^^^^^^^^^^^^^^ the time, independent of DHCP. > > This argument explores only the limit cases, which is beside the point. > > the limit cases are not beside the point - they are the only thing > that give you an idea of whether the design decision is reasonable. > that doesn't mean the limit cases should all be accommodated - but > unless you take the time to understand which cases could cause > problems you have no reason to have confidence that the protocol > will not cause problems. We have explored the limit cases in the WG. Your contribution to the IESG will help them to assess whether or not we have done a good job. > here's the thing - if there was previously a barrier that prevented > accidental communication between hosts, and that barrier is removed > by the introduction of LL, then LL may expose a security hole even > though that hole is incidental to LL. > > the point is that sometimes these barriers are useful, or even > necessary, and LL should not insist that these barriers be removed > as a matter of standards compliance. The vulnerabilities exposed by LL should be fixed. LL exposes but does not cause these problems. Further, LL is unable to solve these problems since it uses ARP. There are workable L2 solutions for securing ARP. > > > - LL seems unlikely to cause resource depletion for most networks. > > > > There is a domain of applicability for the protocol and well > > specified mechanisms to cause it to fail gracefully in networks > > which exceed its intended scope. > > where are those well-specified mechanisms? I don't see them. When a host wishes to configure a link-local address, it selects an address using a pseudo-random number generator ... After it has selected an address, a host MUST test to see if the address is already in use before beginning to use it. On a network such as Ethernet that supports ARP, this test is done using ARP probes. ... When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range zero to two seconds, and should then send four probe packets, spaced two seconds apart. This initial random delay helps ensure that a large number of hosts powered on at the same time do not all send their initial probe packets simultaneously. ... A host should maintain a counter of the number of address collisions it has experienced in the process of trying to acquire an address, and if the number of collisions exceeds ten then the host MUST limit the rate at which it probes for new addresses to no more than one new address per minute. This is to prevent catastrophic ARP storms in pathological failure cases ... > > It is not reasonable to require a proof that a protocol will not > > harm any conceivable network before it gets advanced to proposed > > standard. > > strongly disagree. it's quite reasonable for new standards to avoid > breaking existing standards. what's unreasonable - no, downright > irresponsible - is for a single WG to assume that it has the authority > or the expertise to decide when it's okay to break existing standards > or applications, without even bothering to do an analysis so that it > could understand what is being broken! Scoped addresses and address renumbering exists. LL exposes this. The document describes the issues and remedies in Section 7. > > The WG has consistently disagreed with Keith on the question of whether > > v4LL should be on by default and whether it should be turned off. > > the WG has consistently disregarded the impact of its proposals on existing > apps and networks. it's entirely possible that the WG is wrong. This remark is unjustified. Your input resulted in section 7 and a complete rewrite of the security section - which is now mostly text you wrote as input, verbatim. The WG has not followed *all* your suggestions, however. Erik From owner-zeroconf@merit.edu Wed Sep 25 09:44:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25909 for ; Wed, 25 Sep 2002 09:44:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 56D60912AA; Wed, 25 Sep 2002 09:45:44 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A3CA912AF; Wed, 25 Sep 2002 09:45:44 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B7576912AA for ; Wed, 25 Sep 2002 09:45:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9FCE25DE21; Wed, 25 Sep 2002 09:45:42 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 280995DE0F for ; Wed, 25 Sep 2002 09:45:42 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8PDj1024132; Wed, 25 Sep 2002 09:45:01 -0400 (EDT) Message-Id: <200209251345.g8PDj1024132@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Guttman Cc: Keith Moore , iesg@ietf.org, zeroconf@merit.edu Subject: Re: last call comments on draft-ietf-zeroconf-ipv4-linklocal-07 In-reply-to: (Your message of "Wed, 25 Sep 2002 11:51:41 +0200.") Date: Wed, 25 Sep 2002 09:45:01 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > I reply only to a few of the points below. > > > 3. Most of the delays in getting this document out the door are due to > > the working group's failure to either consider, or to adequately > > address the problems with the document. > > As WG chair, and now coauthor of this document I accept a large part of > the blame for the delays. I should have pushed for 'rough consensus' > earlier. The debate we are reiterating will not change the outcome. well, respectfully, I hope it does change the document that is approved. Frankly I think it usually works better (in general, perhaps not in this case) to try to address substantive technical disagreements before going to IESG - even if it's an disagreement between one and the many. But clearly there's a point of diminishing returns at which the WG should say "here's the document we have near/rough consensus on, and there's also this disagreement that we were unable to resolve, we'll let that party tell you about it". And perhaps it would speed things up to work that way. > That said, it is unfortunate that you did not bring up these issues > during the WG last call on the changes which were intended to answer > your objections in the first IETF last call! Agreed. I was swamped due to having to meet deadlines. > Many environments lack DHCP. LL is on by default in this case in > most PCs and Macs today. In the case where addresses assigned are used > instead of LL addresses, this does not invalidate the point that LL is > on by default. I'll concede that point, though I'll note that "on by default" does not mean "on in most existing networks that are connected to the internet" and I'll continue to maintain that the experience with the existing LL is not a good indicator of how the draft specification would affect applications or networks. > No host is forced to use LL. well, no. not if you leave the host turned off, or if you don't run the OS on the host that you need to use to run the applications that you are required to use, you're not forced to use LL. but the bottom line is most hosts will end up using LL without any choice being made to enable it (that choice being forced by the choice of OS), and (as I read the draft specification) without any way to disable it. > Today, no one *is able to communicate > with* an unconfigured host. true, but sometimes this is an advantage, and it's not a huge deal to configure the host. granted that LL could be an immense benefit to unsophisticated users _who choose_ to allow their hosts to communicate with other hosts - it would let them do so without having to allocate and specify an address, netmask, etc. but I don't think it's a good idea for that choice to be made simply by using an OS (often there is no choice in that matter) that happens to implement LL. > Hosts that do not support LL will be in > the same position as they are in today. not quite true, because there are some impacts on such hosts, as I outlined earlier. > No one is proposing that this protocol be anything other than an > elective standard. no, but if an implementor does "elect" to include LL, it will cause problems for apps and networks. it's easier and more beneficial to "fix" LL to minimize those problems (e.g. by providing ways to turn it off as a matter of standards compliance) than to "fix" LL by not including it in a product. the latter is just too coarse-grained a knob to be useful. > > if avoiding the LL protocol is operationally necessary for some parties, > > then whether the protocol can be avoided is a valid question for the > > technical evaluation of the protocol. > > We have yet to hear that this is an issue from network operators, > except for one case: a university which wanted to prevent students > from using LANs without first registering their equipment. like most WGs, I doubt this WG is terribly visible outside of IETF, especially to network operators - or for that matter, to authors of distributed computing software like myself. > This > led to RFC 2563 "DHCP Option to Disable Stateless Auto-Configuration > in IPv4 Clients" This standard has not yet been implemented, but if > customers demanded it, I am sure vendors would support it. Why not at least refer to it in this document? For that matter, why is this WG so reluctant to give users and network operators the ability to minimize the harm that LL will cause? Why wait for customers to experience the problems which analysis indicates _will_ exist and force them to wait months for vendors to provide ways to resolve them? > The specification does not mandate *use* of LL, when a host > supports it. I'll go through the spec and identify the places that seem to imply that LL is used "all the time" and send those in a separate message. > The vulnerabilities exposed by LL should be fixed. LL exposes but does > not cause these problems. Further, LL is unable to solve these problems > since it uses ARP. There are workable L2 solutions for securing ARP. I think this is missing the point. LL exposes vulnerabilities other than those which exist with ARP. > > > > - LL seems unlikely to cause resource depletion for most networks. > > > > > > There is a domain of applicability for the protocol and well > > > specified mechanisms to cause it to fail gracefully in networks > > > which exceed its intended scope. > > > > where are those well-specified mechanisms? I don't see them. > > When a host wishes to configure a link-local address, it selects > an address using a pseudo-random number generator > ... > After it has selected an address, a host MUST test to see if the > address is already in use before beginning to use it. On a network > such as Ethernet that supports ARP, this test is done using ARP > probes. > ... > When ready to begin probing, the host should then wait for a > random time interval selected uniformly in the range zero to two > seconds, and should then send four probe packets, spaced two > seconds apart. This initial random delay helps ensure that a > large number of hosts powered on at the same time do not all send > their initial probe packets simultaneously. > ... > A host should maintain a counter of the number of address collisions > it has experienced in the process of trying to acquire an address, > and if the number of collisions exceeds ten then the host MUST limit > the rate at which it probes for new addresses to no more than one new > address per minute. This is to prevent catastrophic ARP storms in > pathological failure cases ... I don't think it's reasonable to cite these as a mechanism for disabling LL, at least not with the current text which doesn't mention even mention the potential to use this to disable LL and which implies that this scenario is a pathological failure case rather than something that might reasonably be used in normal operation. I also doubt that it's technically reasonable to "disable" LL in a way that causes each host to ARP once a minute, particularly when there is no specified mechanism to keep those ARPs from synchronizing. > > strongly disagree. it's quite reasonable for new standards to avoid > > breaking existing standards. what's unreasonable - no, downright > > irresponsible - is for a single WG to assume that it has the authority > > or the expertise to decide when it's okay to break existing standards > > or applications, without even bothering to do an analysis so that it > > could understand what is being broken! > > Scoped addresses and address renumbering exists. strictly speaking, as a matter of standards, scoped addresses do not exist in IPv4 except on isolated networks, where scope isn't an issue anyway. use of private addresses by NATs violates not only IP but also RFC 1918. even when such addresses are used as scoped addresses, this is generally an explicit choice - not something that is forced on hosts and applications everywhere on the net without anyone's knowledge. addess renumbering currently exists on networks as a managed event, not something that happens at random without notice and without the potential for consideration of its effects on applications. there are ISPs that impose NAT on their customers and there are ISPs that force their customers to renumber frequently. one hopes those customers have the ability to choose other ISPs. the fact that some ISPs can cause problems for their customers is not a justification for zeroconf causing problems for IP users. > LL exposes this. > The document describes the issues and remedies in Section 7. I need to separately address section 7 also - some of the suggested remedies are onerous. Keith From owner-zeroconf@merit.edu Wed Sep 25 10:25:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27409 for ; Wed, 25 Sep 2002 10:25:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 408FC912BA; Wed, 25 Sep 2002 10:26:53 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08048912BD; Wed, 25 Sep 2002 10:26:52 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 95238912BA for ; Wed, 25 Sep 2002 10:26:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7F3615DE35; Wed, 25 Sep 2002 10:26:51 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 1B48F5DE31 for ; Wed, 25 Sep 2002 10:26:51 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA29443 for ; Wed, 25 Sep 2002 10:26:50 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA17942 for ; Wed, 25 Sep 2002 10:26:50 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA13934 for ; Wed, 25 Sep 2002 10:26:49 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 25 Sep 2002 10:26:48 -0400 Subject: Re: last call comments on draft-ietf-zeroconf-ipv4-linklocal-07 From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200209251345.g8PDj1024132@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 09/25/2002 09:45, "Keith Moore" wrote: > no, but if an implementor does "elect" to include LL, it will > cause problems for apps and networks. it's easier and more beneficial > to "fix" LL to minimize those problems (e.g. by providing ways to turn > it off as a matter of standards compliance) than to "fix" LL by not > including it in a product. the latter is just too coarse-grained a > knob to be useful. The problem is, that now the standard is specifying Implementation techniques. This is of course way out of scope for a standard, because what environments do you include? Well, to be a standard, all of them. And as we all know, there is no such thing as a standard implementation of anything across platforms. The only realistic choice, and the only one that won't be ignored by vendors *anyway* is to give all the information about LL in the standard, so that *if* a vendor has a need to add an 'off' switch, they can. It is not the IETF's place to tell anyone how to implement. It is their place to make the standard as simple and clean as possible so that implementations can be simple and clean. If you have too convoluted of a standard, (which adding in howto's on avoiding the standard will guarantee) then you won't ever get a decent implementation. >> We have yet to hear that this is an issue from network operators, >> except for one case: a university which wanted to prevent students >> from using LANs without first registering their equipment. > > like most WGs, I doubt this WG is terribly visible outside of IETF, > especially to network operators - or for that matter, to authors of > distributed computing software like myself. Um...maybe not to programmers, but the IT community is *very* interested in ZeroConf. We are the ones who are going to support it and deal with the implementations that arise from these standards. In fact, you'll find most IT managers quite conversant with IETF standards, as they are a great troubleshooting tool. Perhaps if more authors of networked applications were more conversant with the IETF, then things wouldn't break so much. > >> This >> led to RFC 2563 "DHCP Option to Disable Stateless Auto-Configuration >> in IPv4 Clients" This standard has not yet been implemented, but if >> customers demanded it, I am sure vendors would support it. > > Why not at least refer to it in this document? For that matter, why > is this WG so reluctant to give users and network operators the ability > to minimize the harm that LL will cause? Why wait for customers to > experience the problems which analysis indicates _will_ exist and > force them to wait months for vendors to provide ways to resolve them? Because again, you cannot tell a vendor *how* to implement a standard. You simply cannot allow for all the variations that exist. You can only give them the 'what' and the 'why'. The 'how' and the 'when' aren't the domain of the IETF, and any attempts by the IETF to change that will be ignored anyway. Besides, if a vendor's work is breaking a network, and they take months to fix it, they won't be a vendor for long. >> The vulnerabilities exposed by LL should be fixed. LL exposes but does >> not cause these problems. Further, LL is unable to solve these problems >> since it uses ARP. There are workable L2 solutions for securing ARP. > > I think this is missing the point. LL exposes vulnerabilities other > than those which exist with ARP. Exposes. Not creates. Exposes. *If* LL *created* vulnerabilities, then you'd have an excellent point. But *any* new use of a network is going to show up holes that you didn't know/think about before. NFS, LPR, FTP, etc, they've all done this. You'll note that BugTraq doesn't have messages about a standard being buggy. Standards don't create bugs. Hardware and software create bugs. Standards are not a lockstep development howto. They're a guide that tells you how your implementation should behave when in use. >>> where are those well-specified mechanisms? I don't see them. >> >> When a host wishes to configure a link-local address, it selects >> an address using a pseudo-random number generator >> ... >> After it has selected an address, a host MUST test to see if the >> address is already in use before beginning to use it. On a network >> such as Ethernet that supports ARP, this test is done using ARP >> probes. >> ... >> When ready to begin probing, the host should then wait for a >> random time interval selected uniformly in the range zero to two >> seconds, and should then send four probe packets, spaced two >> seconds apart. This initial random delay helps ensure that a >> large number of hosts powered on at the same time do not all send >> their initial probe packets simultaneously. >> ... >> A host should maintain a counter of the number of address collisions >> it has experienced in the process of trying to acquire an address, >> and if the number of collisions exceeds ten then the host MUST limit >> the rate at which it probes for new addresses to no more than one new >> address per minute. This is to prevent catastrophic ARP storms in >> pathological failure cases ... > > I don't think it's reasonable to cite these as a mechanism for disabling > LL, at least not with the current text which doesn't mention even > mention the potential to use this to disable LL and which implies that > this scenario is a pathological failure case rather than something that > might reasonably be used in normal operation. I also doubt that it's > technically reasonable to "disable" LL in a way that causes each host to > ARP once a minute, particularly when there is no specified mechanism to > keep those ARPs from synchronizing. If you are going to require specific disabling techniques, then we need specific techniques to re-enable it. That's only logical here. In fact, if we do this here, then from now on *every* IETF standard needs to include this information, and it would be a good idea to retrofit existing standards too. FTP is a horrible security hole, why doesn't the standard tell me how to disable it. The same for telnet. Let's stop doing anything at all until instead of a standard, the IETF is now creating API's for all platforms. Why, that would give the world decades to adjust to a new standard, because that's about how long it would take. The argument over languages to support alone would be a good five years of flame wars. Yes, the IETF should take implementation in to account when creating a standard. They should think about the effort required to implement a standard, and if reasonable analysis shows that the implementation will be more difficult than it needs to be, perhaps simplify the standard to deal with this. But when the standard starts telling a vendor *how* to do something, it is instantly irrelevant. john -- John C. Welch IT Manager MIT Police (617) 253 - 3093 work (508) 579 - 7380 cell (617) 253 - 8822 fax From owner-zeroconf@merit.edu Wed Sep 25 10:25:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27447 for ; Wed, 25 Sep 2002 10:25:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 59F85912BF; Wed, 25 Sep 2002 10:27:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 13272912BE; Wed, 25 Sep 2002 10:27:27 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D06F3912BF for ; Wed, 25 Sep 2002 10:27:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B83E15DE35; Wed, 25 Sep 2002 10:27:23 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id 56FF15DE31 for ; Wed, 25 Sep 2002 10:27:23 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06372; Wed, 25 Sep 2002 08:27:21 -0600 (MDT) Received: from sr-ehdb03-01 (sr-ehdb03-01 [129.157.142.202]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8PERIl26338; Wed, 25 Sep 2002 16:27:18 +0200 (MEST) Date: Wed, 25 Sep 2002 16:27:19 +0200 (MEST) From: Erik Guttman X-Sender: erikg@sr-ehdb03-01 To: Keith Moore Cc: Erik Guttman , iesg@ietf.org, zeroconf@merit.edu Subject: Re: last call comments on draft-ietf-zeroconf-ipv4-linklocal-07 In-Reply-To: <200209251345.g8PDj1024132@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Wed, 25 Sep 2002, Keith Moore wrote: >>>>> - LL seems unlikely to cause resource depletion for most networks. >>>> >>>> There is a domain of applicability for the protocol and well >>>> specified mechanisms to cause it to fail gracefully in networks >>>> which exceed its intended scope. >>> >>> where are those well-specified mechanisms? I don't see them. >> >>{section 2.1 and 2.2 text} >> > I don't think it's reasonable to cite these as a mechanism for disabling > LL, This text is not about disabling the protocol. The citation is my response to your assertion that there are no mechanisms to ensure that the protocol will fail gracefully in networks which exceed the intended scope. Best regards, Erik From owner-zeroconf@merit.edu Wed Sep 25 10:35:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27837 for ; Wed, 25 Sep 2002 10:35:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E5C01912B4; Wed, 25 Sep 2002 10:36:46 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3484912B5; Wed, 25 Sep 2002 10:36:46 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7AFAD912B4 for ; Wed, 25 Sep 2002 10:36:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 61E655DE35; Wed, 25 Sep 2002 10:36:45 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by segue.merit.edu (Postfix) with ESMTP id 46B905DE20 for ; Wed, 25 Sep 2002 10:36:45 -0400 (EDT) Received: from repligate ([67.37.234.214]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020925143643.VACA1118.mailhost.chi1.ameritech.net@repligate>; Wed, 25 Sep 2002 09:36:43 -0500 Message-ID: <000d01c264a1$057a2b40$d6ea2543@repligate> From: "Jim Fleming" To: "John C. Welch" , "Zeroconf" References: Subject: "It is not the IETF's place to tell anyone how to implement." Date: Wed, 25 Sep 2002 09:37:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit From: "John C. Welch" "It is not the IETF's place to tell anyone how to implement." ==== Most standards bodies are trailing edge. They come around after the fact and after the marketplace has set the standard. Some people **think** they can be leading edge and set the standard and dictate to the market what they will use. The marketplace just routes around those dictators. The.C@t says... Vote Early and Often... http://www.kvtek.com/ddnsservices.asp 128-bit DNS AAAA Record Flag Day Formats 2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] [YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] 1-bit to set the Reserved/Spare ("SNOOPY") bit in Fragment Offset [S] 1-bit to set the Don't Fragment (DF) bit [D] 2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL] 1-bit for Options Control [O] 7-bits to set the Identification Field(dst) [FFFFFFF] 4-bits to set the TOS(dst) Field [TTTT] Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000 FFF.FFFF.TTTT = GGG.SSSS.SSSS SNOOPY = 0 on all these packets... ----- Original Message ----- From: "John C. Welch" To: "Zeroconf" Sent: Wednesday, September 25, 2002 9:26 AM Subject: Re: last call comments on draft-ietf-zeroconf-ipv4-linklocal-07 > On 09/25/2002 09:45, "Keith Moore" wrote: > > > no, but if an implementor does "elect" to include LL, it will > > cause problems for apps and networks. it's easier and more beneficial > > to "fix" LL to minimize those problems (e.g. by providing ways to turn > > it off as a matter of standards compliance) than to "fix" LL by not > > including it in a product. the latter is just too coarse-grained a > > knob to be useful. > > The problem is, that now the standard is specifying Implementation > techniques. This is of course way out of scope for a standard, because what > environments do you include? Well, to be a standard, all of them. And as we > all know, there is no such thing as a standard implementation of anything > across platforms. The only realistic choice, and the only one that won't be > ignored by vendors *anyway* is to give all the information about LL in the > standard, so that *if* a vendor has a need to add an 'off' switch, they can. > It is not the IETF's place to tell anyone how to implement. It is their > place to make the standard as simple and clean as possible so that > implementations can be simple and clean. If you have too convoluted of a > standard, (which adding in howto's on avoiding the standard will guarantee) > then you won't ever get a decent implementation. > > >> We have yet to hear that this is an issue from network operators, > >> except for one case: a university which wanted to prevent students > >> from using LANs without first registering their equipment. > > > > like most WGs, I doubt this WG is terribly visible outside of IETF, > > especially to network operators - or for that matter, to authors of > > distributed computing software like myself. > > Um...maybe not to programmers, but the IT community is *very* interested in > ZeroConf. We are the ones who are going to support it and deal with the > implementations that arise from these standards. In fact, you'll find most > IT managers quite conversant with IETF standards, as they are a great > troubleshooting tool. Perhaps if more authors of networked applications were > more conversant with the IETF, then things wouldn't break so much. > > > > >> This > >> led to RFC 2563 "DHCP Option to Disable Stateless Auto-Configuration > >> in IPv4 Clients" This standard has not yet been implemented, but if > >> customers demanded it, I am sure vendors would support it. > > > > Why not at least refer to it in this document? For that matter, why > > is this WG so reluctant to give users and network operators the ability > > to minimize the harm that LL will cause? Why wait for customers to > > experience the problems which analysis indicates _will_ exist and > > force them to wait months for vendors to provide ways to resolve them? > > Because again, you cannot tell a vendor *how* to implement a standard. You > simply cannot allow for all the variations that exist. You can only give > them the 'what' and the 'why'. The 'how' and the 'when' aren't the domain of > the IETF, and any attempts by the IETF to change that will be ignored > anyway. Besides, if a vendor's work is breaking a network, and they take > months to fix it, they won't be a vendor for long. > > >> The vulnerabilities exposed by LL should be fixed. LL exposes but does > >> not cause these problems. Further, LL is unable to solve these problems > >> since it uses ARP. There are workable L2 solutions for securing ARP. > > > > I think this is missing the point. LL exposes vulnerabilities other > > than those which exist with ARP. > > Exposes. Not creates. Exposes. *If* LL *created* vulnerabilities, then you'd > have an excellent point. But *any* new use of a network is going to show up > holes that you didn't know/think about before. NFS, LPR, FTP, etc, they've > all done this. You'll note that BugTraq doesn't have messages about a > standard being buggy. Standards don't create bugs. Hardware and software > create bugs. Standards are not a lockstep development howto. They're a guide > that tells you how your implementation should behave when in use. > > >>> where are those well-specified mechanisms? I don't see them. > >> > >> When a host wishes to configure a link-local address, it selects > >> an address using a pseudo-random number generator > >> ... > >> After it has selected an address, a host MUST test to see if the > >> address is already in use before beginning to use it. On a network > >> such as Ethernet that supports ARP, this test is done using ARP > >> probes. > >> ... > >> When ready to begin probing, the host should then wait for a > >> random time interval selected uniformly in the range zero to two > >> seconds, and should then send four probe packets, spaced two > >> seconds apart. This initial random delay helps ensure that a > >> large number of hosts powered on at the same time do not all send > >> their initial probe packets simultaneously. > >> ... > >> A host should maintain a counter of the number of address collisions > >> it has experienced in the process of trying to acquire an address, > >> and if the number of collisions exceeds ten then the host MUST limit > >> the rate at which it probes for new addresses to no more than one new > >> address per minute. This is to prevent catastrophic ARP storms in > >> pathological failure cases ... > > > > I don't think it's reasonable to cite these as a mechanism for disabling > > LL, at least not with the current text which doesn't mention even > > mention the potential to use this to disable LL and which implies that > > this scenario is a pathological failure case rather than something that > > might reasonably be used in normal operation. I also doubt that it's > > technically reasonable to "disable" LL in a way that causes each host to > > ARP once a minute, particularly when there is no specified mechanism to > > keep those ARPs from synchronizing. > > If you are going to require specific disabling techniques, then we need > specific techniques to re-enable it. That's only logical here. In fact, if > we do this here, then from now on *every* IETF standard needs to include > this information, and it would be a good idea to retrofit existing standards > too. FTP is a horrible security hole, why doesn't the standard tell me how > to disable it. The same for telnet. Let's stop doing anything at all until > instead of a standard, the IETF is now creating API's for all platforms. > Why, that would give the world decades to adjust to a new standard, because > that's about how long it would take. The argument over languages to support > alone would be a good five years of flame wars. > > Yes, the IETF should take implementation in to account when creating a > standard. They should think about the effort required to implement a > standard, and if reasonable analysis shows that the implementation will be > more difficult than it needs to be, perhaps simplify the standard to deal > with this. But when the standard starts telling a vendor *how* to do > something, it is instantly irrelevant. > > john > > -- > John C. Welch > IT Manager > MIT Police > (617) 253 - 3093 work > (508) 579 - 7380 cell > (617) 253 - 8822 fax > > From owner-zeroconf@merit.edu Wed Sep 25 11:26:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29363 for ; Wed, 25 Sep 2002 11:26:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1663B9122E; Wed, 25 Sep 2002 11:27:49 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE869912B0; Wed, 25 Sep 2002 11:27:48 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE6F79122E for ; Wed, 25 Sep 2002 11:27:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CD9135DE43; Wed, 25 Sep 2002 11:27:47 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 682AF5DDB4 for ; Wed, 25 Sep 2002 11:27:47 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA01683 for ; Wed, 25 Sep 2002 11:27:46 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA29632 for ; Wed, 25 Sep 2002 11:27:46 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA12945 for ; Wed, 25 Sep 2002 11:27:46 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 25 Sep 2002 11:27:45 -0400 Subject: Re: "It is not the IETF's place to tell anyone how to implement." From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <000d01c264a1$057a2b40$d6ea2543@repligate> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 09/25/2002 10:37, "Jim Fleming" wrote: > Most standards bodies are trailing edge. They come around after the fact and > after > the marketplace has set the standard. Some people **think** they can be > leading edge > and set the standard and dictate to the market what they will use. The > marketplace just > routes around those dictators. The idea with standards, IMO, is to say, "We have a lot of people using blah. To make life easier, and avoid problems with blah, let's sit down, and standardize how blah should work, interact with blech and yearg, etc." Telling anyone how to implement a standard is a fool's errand. john -- John C. Welch IT Manager MIT Police (617) 253 - 3093 work (508) 579 - 7380 cell (617) 253 - 8822 fax From owner-zeroconf@merit.edu Wed Sep 25 11:42:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29822 for ; Wed, 25 Sep 2002 11:42:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5BD1E912C2; Wed, 25 Sep 2002 11:44:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2CECA912C5; Wed, 25 Sep 2002 11:44:27 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2180C912C2 for ; Wed, 25 Sep 2002 11:44:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0FCC35DE48; Wed, 25 Sep 2002 11:44:26 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by segue.merit.edu (Postfix) with ESMTP id E6A715DE46 for ; Wed, 25 Sep 2002 11:44:25 -0400 (EDT) Received: from repligate ([67.37.234.214]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020925154425.XPBF1118.mailhost.chi1.ameritech.net@repligate>; Wed, 25 Sep 2002 10:44:25 -0500 Message-ID: <002f01c264aa$7aa77d10$d6ea2543@repligate> From: "Jim Fleming" To: "John C. Welch" , "Zeroconf" References: Subject: Re: "It is not the IETF's place to tell anyone how to implement." Date: Wed, 25 Sep 2002 10:44:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "John C. Welch" To: "Zeroconf" Sent: Wednesday, September 25, 2002 10:27 AM Subject: Re: "It is not the IETF's place to tell anyone how to implement." > On 09/25/2002 10:37, "Jim Fleming" wrote: > > > Most standards bodies are trailing edge. They come around after the fact and > > after > > the marketplace has set the standard. Some people **think** they can be > > leading edge > > and set the standard and dictate to the market what they will use. The > > marketplace just > > routes around those dictators. > > The idea with standards, IMO, is to say, "We have a lot of people using > blah. To make life easier, and avoid problems with blah, let's sit down, and > standardize how blah should work, interact with blech and yearg, etc." > > Telling anyone how to implement a standard is a fool's errand. > Agreed.....and most standards efforts are composed of people who really do not care about the details of the outcome, because they have a more global common objective. As an example, do people really care if the bit order is SDLL, or DSLL, or LLDS ? 128-bit DNS AAAA Record Flag Day Formats 2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] [YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address] 1-bit to set the Reserved/Spare ("SNOOPY") bit in Fragment Offset [S] 1-bit to set the Don't Fragment (DF) bit [D] 2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL] 1-bit for Options Control [O] 7-bits to set the Identification Field(dst) [FFFFFFF] 4-bits to set the TOS(dst) Field [TTTT] Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000 FFF.FFFF.TTTT = GGG.SSSS.SSSS There are only 128-bits, not 129. They can only have so many values. People writing code just want to know what order other people writing code are using. They also of course do not want some Innovation Extermination Task Force coming in and saying, you can't arrange the bits that way, or all of the arrangements have changed, because we need to fund our insiders with jobs changing the bits. The.C@t says... Vote Early and Often... http://www.kvtek.com/ddnsservices.asp From owner-zeroconf@merit.edu Wed Sep 25 16:05:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08700 for ; Wed, 25 Sep 2002 16:05:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 18762912E2; Wed, 25 Sep 2002 16:06:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E7CC9912E0; Wed, 25 Sep 2002 16:06:13 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4E3A0912D1 for ; Wed, 25 Sep 2002 16:06:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3CD015DE86; Wed, 25 Sep 2002 16:06:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id BD9085DE46 for ; Wed, 25 Sep 2002 16:06:07 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8PK67026745; Wed, 25 Sep 2002 16:06:07 -0400 (EDT) Message-Id: <200209252006.g8PK67026745@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: zeroconf@merit.edu Subject: text in linklocal-07 supporting an "always on" interpretation Cc: moore@cs.utk.edu, iesg@iesg.org From: Keith Moore Date: Wed, 25 Sep 2002 16:06:07 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk this one is actually brief. I said I would cite specific text from linklocal-07 that leads me to believe that the intent is to require hosts to always have linklocal enabled. (emphasis mine) Abstract: "It would be beneficial for a host to have some useful subset of IP networking that it can depend on to be *always functional*..." Introduction, 3rd pp: "...This standard removes that restriction, making link-local addresses available *all the time*, independent of DHCP" section 1.2, last pp: The text suggests that network operators with more than 1300 hosts on a single link may want to consider dividing that single link into two or more subnets, but doesn't suggest disabling link-local addressing as a feasible alternative. suggested rewording: Abstract: "It would be beneficial for a host to have the option of using IP network even in the absence of DHCP or explicit configuration" Introduction, 3rd pp: "This standard makes link-local addresses potentially available even on networks that support DHCP" section 1.2, last pp: "...may want to consider dividing that single link into two or more subnets, or disabling link-local addressing using the DHCP extension defined in RFC 2563". (and subsequently, or elsewhere as appropriate) "Hosts that implement both this specification and DHCP MUST honor the DHCP option defined in RFC 2563". these simple fixes would solve the worst problems with this document. other clarifications would also IMHO be appropriate; I'll detail those in a separate message. Keith From owner-zeroconf@merit.edu Wed Sep 25 17:42:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11078 for ; Wed, 25 Sep 2002 17:42:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0F873912BC; Wed, 25 Sep 2002 17:44:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB218912D1; Wed, 25 Sep 2002 17:44:10 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 539CC912BC for ; Wed, 25 Sep 2002 17:44:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 383A55DEA1; Wed, 25 Sep 2002 17:44:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id A72C95DE9F for ; Wed, 25 Sep 2002 17:44:08 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8PLi3027088; Wed, 25 Sep 2002 17:44:03 -0400 (EDT) Message-Id: <200209252144.g8PLi3027088@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: iesg@ietf.org Subject: specific comments on draft-ietf-zeroconf-ipv4-linklocal-07 Cc: moore@cs.utk.edu, zeroconf@merit.edu From: Keith Moore Date: Wed, 25 Sep 2002 17:44:03 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk yeah, I know. this is a lot of text. In some cases I quoted text from the existing document to make it clear exactly what kinds of changes I recommend. I have tried to mark existing text with ">" and suggested new text with "]". unlike my earlier LC comments, these comments relate specifically to the text in linklocal-07 and need to be considered separately. most of these suggested changes are orthogonal to those suggested in my earlier comments. these changes by themselves do not suffice to fix all of the problems in the document, but I think they should be made anyway. Keith section 1.4: > Administrators wishing to configure their own local addresses > (using manual configuration, a DHCP server, or any other mechanism > not described in this document) should use one of the existing > private address prefixes [RFC 1918], not the 169.254/16 prefix. this is slightly overbroad, as RFC 1918 is intended for disconnected networks only. suggest it be changed to: ] Administrators of networks that are isolated from the Internet, ] who wish to configure their own local addresses (using manual ] configuration, a DHCP server, or any other mechanism not ] described in this document) SHOULD use one of the existing ] private address prefixes [RFC 1918], rather than the 169.254/16 ] prefix or any other prefix not assigned to that network. section 2.6, 3rd pp (nit): > If the destination address is the 255.255.255.255 broadcast address > or a multicast address, then the host may use either its link-local > source address or a routable address, as appropriate. change to: ] If the destination address is the 255.255.255.255 broadcast address ] or a multicast address, then the host MAY use either its link-local ] source address or a routable address, as appropriate. section 2.6, last pp (nit): > In the case where two hosts on the same link each have both a link- > local address and another address configured via some other means, > the host may use either its link-local source address or a routable change to: ] In the case where two hosts on the same link each have both a link- ] local address and another address configured via some other means, ] the host MAY use either its link-local source address or a routable section 2.8: the section is still misleading. devices may assume that link-local packets are originated from the local link, but this does not imply _anything_ in terms of security. for instance, it doesn't mean that the packet payloads originated from the local link, nor does it mean that the packets were generated by a trusted source. (especially in a wireless network) it is not reasonable for a device vendor to assume that the LL environment is "safer" or "more secure" than a configured environment. nor is it reasonable to recommend that a device designer rely on outside controls to implement security. here's an attempt to rewrite this section: ]2.8 Devices MUST NOT assume Link-Local traffic is trustworthy ] ] The non-forwarding rule means that hosts may assume that all ] 169.254/16 destination addresses are "on-link" and directly ] reachable. The 169.254/16 address prefix MUST NOT be subnetted. ] This specification utilizes ARP-based address collision detection, ] which functions by broadcasting on the local subnet. Since such ] broadcasts are not forwarded, were subnetting to be allowed then ] address conflicts could remain undetected. To some degree this ] limits the set of hosts which can originate link-local traffic. ] ] Designers of many kinds of devices, in particular simple network ] appliances, wish for a protected network environment in which ] security threats are diminished and which therefore reduces the ] burden to implement security within the device. Link-local addressing ] DOES NOT inherently reduce that burden, and (especially in the ] case of a wireless network or a wired network bridge to a wireless ] network) may even expose devices to threats which are not present ] in an explicitly configured network. Such threats may be presented ] either directly from attackers or indirectly via other hosts on the ] local network which have been compromised. some more on this: I don't know of any way for a protocol that allows a device to accept traffic to _reduce_ the threats to which that device might be subjected. any additional input to the device is a potential threat that wasn't present before the device could accept that input. what the WG seems to want, and what I think is inherently untenable, is a general-purpose LL protocol that can be expected to be implemented on (almost) *every* host, potentially allowing (almost) *any* host (whatever its purpose or security level) to be attached to a network along with LL devices, and *which somehow makes those other hosts trustworthy*. that's just not going to happen. if you want to assume that all hosts that speak LL are trustworthy then you need at a minimum to impose some fairly serious constraints on those hosts - constraints which clearly cannot be applied to the wide range of hosts which are likely to support LL. section 2.9 seems incomplete. here's an attempt at a rewrite: ] 2.9 Higher-Layer Protocol Considerations ] ] Similar considerations apply at layers above IP. ] ] Any application which uses IP addresses to in referrals that are ] sent to other hosts will fail if link-local IP addresses are ] sent to hosts that are unable to use them. This could happen ] for a variety of reasons: (a) the host receiving the address does ] not have access to the same link, (b) the host receiving the address ] has multiple interfaces supporting link-local addressing, causing ] the link-local address to be ambiguous, or (c) the host receiving ] the address does not support link-local addressing. ] ] For example, if web pages (including automatically generated web ] pages) contain links with embedded link-local addresses, those ] links will fail if those pages are accessible from (perhaps via ] a cache or proxy) hosts outside the local link where the addresses ] are valid, or if the host migrates outside that local link. ] ] Applications that are aware of link-local addressing SHOULD ] avoid using them in referrals to other hosts. In general it ] is difficult for an application to know whether an address ] means the same thing to another host as it means to the local ] host - even if the other host is on the same link - and thus ] it is difficult for an application to determine whether it ] is safe to use link-local addresses in referrals. In addition, ] there is always a chance that a link-local address-to-host ] binding will be revoked due to an address conflict. ] ] It should be noted that DNS is an example of an application ] that performs address referrals. For these reasons storing ] use of DNS to return link-local addresses is NOT RECOMMENDED. section 3, 2nd pp: > For applications that send packets (or initiate outgoing > connections) without identifying a desired source interface, by > interface identifier, source IP address, or any other means, an > operating system that configures link-local addresses on multiple > interfaces has two choices. It can either restrict such > applications to using link-local addresses on only one default > interface, or it can ARP for the given destination address on all > interfaces, and use the first reply it gets. While clearly sub- > optimal, in most cases this heuristic approach will successfully > establish communication with the desired correspondent host. change to: ] For applications that send packets (or initiate outgoing ] connections) without identifying a desired source interface, by ] interface identifier, source IP address, or any other means, an ] operating system that configures link-local addresses on multiple ] interfaces has two choices. It can either restrict such ] applications to using link-local addresses on only one default ] interface, or it can ARP for the given destination address on all ] interfaces, and use the first reply it gets. In most cases this ] heuristic approach will successfully establish communication ] with the desired correspondent host. However, it does have the ] potential to establish communications with the wrong host. section 3.3, 4th pp: > This uniqueness requirement simplifies host software layers above > IP (application software and transport protocols) by allowing them > to identify connections using only the source and destination IP > addresses, without also needing interface identifiers. Since link- > local addresses are only unique per-link, hosts on different links > could be using the same link-local address. Uniqueness of source > addresses on the multi-homed host allows connections to the same > destination address on different links to be disambiguated by their > different source addresses. this certainly doesn't "simplify" host software - it makes it more complex by increasing the burden on apps - it's no longer sufficient for an app to just specify a destination IP address to reach a host, it now has to specify a source,destination pair. suggested rewrite: ] This uniqueness requirement allows host software layers above ] IP (application software and transport protocols) to identify ] connections using both the source and destination IP addresses. ] While this does increase the complexity of such software, it ] also facilitates more reliable use of link-local addresses which ] might otherwise be ambiguous. section 5, 1st pp: > The use of IPv4 Link-Local Addresses may open a network host to new > attacks. In particular, a host that previously did not have an IP > address, and no IP stack running, was not susceptible to IP-based > attacks. By configuring a working address, the host may now be > vulnerable to IP-based attacks. add at the end: ] Similarly, a host which was protected (to whatever degree) ] from threats from other hosts via an external filter or firewall ] may be exposed to new and different threats as a consequence of ] link-local addressing. 2nd pp: > The ARP protocol [RFC 826] is insecure. A malicious host may send > fraudulent ARP packets on the network, interfering with the correct > operation of other hosts. For example, it is easy for a host to > answer all ARP requests with replies giving its own hardware address, > thereby claiming ownership of every address on the network. suggested improvement: ] Link-local address negotiation uses the ARP protocol [RFC 826] which ] is known to be insecure. A malicious host may send fraudulent ARP ] packets on the network, interfering with the correct operation of ] other hosts. For example, it is easy for a host to answer some or ] all ARP requests with replies giving its own hardware address, thereby ] claiming ownership of those addresses, causing their traffic to be ] mis-directed, and generally denying use of the network to those hosts. ] These threats exist for any use of unsecured ARP, whether for link-local ] addresses or routable addresses. 3rd pp: > Implementers are advised that the Internet Protocol architecture > expects every networked device or host must implement security > which is adequate to protect the resources to which the device > or host has access, including the network itself, against known > or credible threats. Even though use of link-local addresses > may reduce the number of threats to which a device is exposed, > implementers of devices supporting the Internet Protocol must > not assume that a customer's local network is free from security > risks. change to: ] Implementers are advised that the Internet Protocol architecture ] expects every networked device or host must implement security ] which is adequate to protect the resources to which the device ] or host has access, including the network itself, against known ] or credible threats. Use of link-local addresses cannot be assumed ] to reduce the number of threats to which a device is exposed, ] and in fact it may expose such devices to new threats - particularly ] if the devices are attached (directly or through a bridge) to ] unsecured wireless networks. Implementers of devices supporting the ] Internet Protocol therefore MUST NOT assume that a customer's local ] network is free from security risks. section 7.1, 2nd pp: this is onerous, as it tries to apply to all applications whether it is appropriate or not. delete > Vendors producing application software which will be used on IP > implementations supporting IPv4 link-local address configuration > SHOULD detect and cope with address change events. Vendors > producing IP implementations supporting IPv4 link-local address > configuration SHOULD expose address change events to applications. and replace with ] Because the probability of, and the consequences of, such failures ] will differ from one application to another, no single remedy is ] appropriate for all applications. Some applications (for instance, ] those whose communications with other hosts are typically brief) ] may be able to simply accept an increased failure rate. Other ] applications may be able to detect and recover from address changes. ] Others may elect to avoid using link-local addresses, or to use ] them only as a last resort. section 7.2, change entire section to: ] IPv4 link-local addresses SHOULD NOT be forwarded via an application ] protocol (for example in a URL, or some other referral using IP ] addresses), to a destination which is not link-local, on the same link. ] However in general there is no way for an application to know whether the ] destination (or some other party to which the address is subsequently ] forwarded) can make use of a link-local address being forwarded. ] ] Applications that are aware of link-local addresses SHOULD NOT ] assume that a link-local address is valid for any other host, ] even another host on the same link. Similarly, because link-local ] addresses are inherently ambiguous, applications that are aware of ] link-local addresses MUST NOT treat a link-local address by itself ] as any kind of identity for a host. Such applications MAY attempt ] to contact a host at a link-local address and subsequently verify ] that host's (perhaps application-specific) identity via other means. ] ] This issue is discussed further in Section 2.9 and 3. section 7.3, change entire section to: ] Application software run on a multihomed IP host which supports ] IPv4 link-local address configuration on more than one interface ] may fail. This is because application software assumes that an IP ] address is unambiguous, that it can refer to only one host. IPv4 ] link-local addresses are unique only on a single link. A host ] attached to multiple links can easily encounter a situation where ] the same address is present on more than one interface, or first on ] one interface, later on another; in any case associated with more ] than one host. This is similar to the problem with forwarding ] addresses from one host to another - in either case the address ] is potentially being used on a link on which it is invalid or ] associated with a different host. ] ] This is a significant departure from the Internet Protocol v4 ] architecture that assumes uniqueness of addresses. Most existing ] software is therefore not prepared for this ambiguity. Some ] of the problems can be addressed by increased complexity in ] applications software and by changes to application programming ] interfaces, but in general the lack of a global address space ] makes many operations difficult or infeasible. From owner-zeroconf@merit.edu Wed Sep 25 22:29:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16008 for ; Wed, 25 Sep 2002 22:29:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 09C88912C8; Wed, 25 Sep 2002 22:30:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3843912CB; Wed, 25 Sep 2002 22:30:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8707B912C8 for ; Wed, 25 Sep 2002 22:30:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 35F695DE92; Wed, 25 Sep 2002 22:30:16 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id B5F2E5DF23 for ; Wed, 25 Sep 2002 22:30:15 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id TAA01714; Wed, 25 Sep 2002 19:30:40 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id TAA27397; Wed, 25 Sep 2002 19:30:11 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g8Q2U57C022275; Thu, 26 Sep 2002 12:30:05 +1000 (EST) Message-ID: <3D92712C.7090807@motorola.com> Date: Thu, 26 Sep 2002 12:30:04 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zeroconf@merit.edu, ipng@sunroof.eng.sun.com Cc: Thomas Narten Subject: zerouter bof Content-Type: multipart/mixed; boundary="------------070302080305080205030801" Sender: owner-zeroconf@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------070302080305080205030801 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, I have requested a bof on zeroconf routers in Atlanta. You can find a draft charter attached to this email. Please use the zerouter email list if you would like to participate in the discussion: zerouter@internet.motlabs.com http://internet.motlabs.com/mailman/listinfo/zerouter -- regards aidan ____ :wq! Sydney Network Research Lab aidan.williams@motorola.com Motorola Australian Research Centre phone: +61 2 9666 0649 Locked Bag 5028, Botany NSW 1455 phax: +61 2 9666 0501 Australia http://marc.labs.mot.com/snrl/ --------------070302080305080205030801 Content-Type: text/plain; name="zerouter-charter.txt" Content-Disposition: inline; filename="zerouter-charter.txt" Content-Transfer-Encoding: 7bit Draft Zeroconf Router WG Charter ================================ Mailing List: zerouter@internet.motlabs.com http://internet.motlabs.com/mailman/listinfo/zerouter IP networks are in widespread use in environments like the home where there is no network administrator. With IPv6 deployment delegating /48 prefixes and the increasing complexity and variety of home networks, automatic configuration of routers in the home is desirable. Host auto-configuration mechanisms exist for IPv6 and IPv4 however no protocols have been standardised that support autoconfiguration of a mesh of routers. The objective of this working group is to define protocol mechanisms that will allow consistent IP subnet prefixes to be automatically assigned in a mesh of routers. Such networks are expected to connect to IP infrastructure and will need to receive configuration parameters in order to operate (e.g. delegated IPv6 prefix). IP router auto-configuration is complementary to Layer-2 bridging. Many commodity home networking products today use Layer-2 bridging and work satisfactorily for simple networks. Achieving a robust L2 bridged network requires 802.1d spanning tree (often not implemented). Efficient multicast forwarding requires IGMP/MLD snooping, GARP/GMRP or a similar mechanism. Sometimes L2 bridging is not possible, for example between IEEE1394 and ethernet, or between FDDI and ethernet. A Layer-3 approach allows existing unicast and multicast routing protocols to be used to create a robust and efficient auto-configured home network. Work areas: 1. Parameter propagation Specify mechanisms to: - Propogate a delegated address range through a mesh of routers. - Propagate configuration parameters to hosts, through the mesh of routers (e.g. default DNS domain suffix, DNS server). 2. Automatic assignment of subnet identifiers to links. - Specify protocols that will automatically generate consistent subnet numbers in a mesh of routers. 3. Specify how automatic address assignment interacts with specific unicast and multicast routing protocols. Scope statements: - Zerouter protocols are intended to be used in leaf networks. Auto-configuration of transit networks is out of scope. - Whilst there are some similarities to MANET routing protocols, zerouter protocols will be used in a different environment. Differences are no/low mobility, and a strong emphasis on address configuration. - Auto-configuration of L2 media parameters is out of scope (e.g. virtual circuit IDs and the like). Existing drafts: draft-haberman-ipngwg-auto-prefix-02.txt draft-troan-dhcpv6-opt-prefix-delegation-00.txt draft-lutchann-ipv6-delegate-option-00.txt draft-white-zeroconf-uiap-00.txt draft-white-zeroconf-subnet-alloc-00.txt draft-chelius-router-autoconf-00.txt --------------070302080305080205030801-- From owner-zeroconf@merit.edu Thu Sep 26 05:31:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01145 for ; Thu, 26 Sep 2002 05:31:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 59F6F912A6; Thu, 26 Sep 2002 05:33:23 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EBDDB912A9; Thu, 26 Sep 2002 05:33:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D00B912A6 for ; Thu, 26 Sep 2002 05:33:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7A2C25DFB7; Thu, 26 Sep 2002 05:33:15 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id F17E15DF33 for ; Thu, 26 Sep 2002 05:33:14 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15083; Thu, 26 Sep 2002 03:33:13 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g8Q9XBl04380; Thu, 26 Sep 2002 11:33:11 +0200 (MEST) Date: Thu, 26 Sep 2002 11:33:10 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: Keith Moore Cc: iesg@ietf.org, zeroconf@merit.edu Subject: Re: specific comments on draft-ietf-zeroconf-ipv4-linklocal-07 In-Reply-To: <200209252144.g8PLi3027088@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk There are specific areas where Keith suggests wording changes which improve the draft (may to MAY, for example.) In many cases, I believe the changes would detract from the clarity or intent of the document. This is my interpretation of WG (rough) consensus. If I am misrepresenting the WG, please disagree, please express this on the list. On Wed, 25 Sep 2002, Keith Moore wrote: > these changes by themselves do not suffice to fix all of the > problems in the document, but I think they should be made anyway. Keith, Do you intend to send more comments at a later time? > section 1.4: > > > Administrators wishing to configure their own local addresses > > (using manual configuration, a DHCP server, or any other mechanism > > not described in this document) should use one of the existing > > private address prefixes [RFC 1918], not the 169.254/16 prefix. > > this is slightly overbroad, as RFC 1918 is intended for disconnected > networks only. suggest it be changed to: > > ] Administrators of networks that are isolated from the Internet, > ] who wish to configure their own local addresses (using manual > ] configuration, a DHCP server, or any other mechanism not > ] described in this document) SHOULD use one of the existing > ] private address prefixes [RFC 1918], rather than the 169.254/16 > ] prefix or any other prefix not assigned to that network. The SHOULD is OK. The bit about disconnected networks is not OK. This document does not describe network address assignment policy, that is on which sort of networks an administrator might assign whatever addresses he or she decides to configure. This paragraph says only that if there is such a policy, the addresses SHOULD be from the RFC 1918 range not from the LL range. > section 2.6, 3rd pp (nit): > > > If the destination address is the 255.255.255.255 broadcast address > > or a multicast address, then the host may use either its link-local > > source address or a routable address, as appropriate. > > change to: > > ] If the destination address is the 255.255.255.255 broadcast address > ] or a multicast address, then the host MAY use either its link-local > ] source address or a routable address, as appropriate. OK. > section 2.6, last pp (nit): > > > In the case where two hosts on the same link each have both a link- > > local address and another address configured via some other means, > > the host may use either its link-local source address or a routable > > change to: > > ] In the case where two hosts on the same link each have both a link- > ] local address and another address configured via some other means, > ] the host MAY use either its link-local source address or a routable > OK. > section 2.8: Stuart, please take this up with Keith. > section 2.9 seems incomplete. here's an attempt at a rewrite: > > ] 2.9 Higher-Layer Protocol Considerations > ] > ] Similar considerations apply at layers above IP. Similar to what? > ] Any application which uses IP addresses to in referrals that are > ] sent to other hosts will fail if link-local IP addresses are > ] sent to hosts that are unable to use them. This could happen > ] for a variety of reasons: (a) the host receiving the address does > ] not have access to the same link, (b) the host receiving the address > ] has multiple interfaces supporting link-local addressing, causing > ] the link-local address to be ambiguous, or (c) the host receiving > ] the address does not support link-local addressing. (c) is false. The host receiving the LL address reference does not need to *have* a LL address to know how to receive from a LL source or send to a LL destination. (a) and (b) are covered in section 7 as are the next two paragraphs. > ] For example, if web pages (including automatically generated web > ] pages) contain links with embedded link-local addresses, those > ] links will fail if those pages are accessible from (perhaps via > ] a cache or proxy) hosts outside the local link where the addresses > ] are valid, or if the host migrates outside that local link. > ] > ] Applications that are aware of link-local addressing SHOULD > ] avoid using them in referrals to other hosts. In general it > ] is difficult for an application to know whether an address > ] means the same thing to another host as it means to the local > ] host - even if the other host is on the same link - and thus > ] it is difficult for an application to determine whether it > ] is safe to use link-local addresses in referrals. In addition, > ] there is always a chance that a link-local address-to-host > ] binding will be revoked due to an address conflict. --- > ] It should be noted that DNS is an example of an application > ] that performs address referrals. For these reasons storing > ] use of DNS to return link-local addresses is NOT RECOMMENDED. This text is much stronger than that which is in the current draft. The current text, BTW, was crafted with your assistance, Keith. > section 3, 2nd pp: > > > For applications that send packets (or initiate outgoing > > connections) without identifying a desired source interface, by > > interface identifier, source IP address, or any other means, an > > operating system that configures link-local addresses on multiple > > interfaces has two choices. It can either restrict such > > applications to using link-local addresses on only one default > > interface, or it can ARP for the given destination address on all > > interfaces, and use the first reply it gets. While clearly sub- > > optimal, in most cases this heuristic approach will successfully > > establish communication with the desired correspondent host. > > change to: > > ] For applications that send packets (or initiate outgoing > ] connections) without identifying a desired source interface, by > ] interface identifier, source IP address, or any other means, an > ] operating system that configures link-local addresses on multiple > ] interfaces has two choices. It can either restrict such > ] applications to using link-local addresses on only one default > ] interface, or it can ARP for the given destination address on all > ] interfaces, and use the first reply it gets. In most cases this > ] heuristic approach will successfully establish communication > ] with the desired correspondent host. However, it does have the > ] potential to establish communications with the wrong host. OK. > section 3.3, 4th pp: > > > This uniqueness requirement simplifies host software layers above > > IP (application software and transport protocols) by allowing them > > to identify connections using only the source and destination IP > > addresses, without also needing interface identifiers. Since link- > > local addresses are only unique per-link, hosts on different links > > could be using the same link-local address. Uniqueness of source > > addresses on the multi-homed host allows connections to the same > > destination address on different links to be disambiguated by their > > different source addresses. > > this certainly doesn't "simplify" host software - it makes it more > complex by increasing the burden on apps - it's no longer sufficient > for an app to just specify a destination IP address to reach a host, > it now has to specify a source,destination pair. suggested rewrite: > > ] This uniqueness requirement allows host software layers above > ] IP (application software and transport protocols) to identify > ] connections using both the source and destination IP addresses. > ] While this does increase the complexity of such software, it > ] also facilitates more reliable use of link-local addresses which > ] might otherwise be ambiguous. OK, except your suggested text lacks the final sentence of the preceding paragraph, which clarifies the intent and mechanism and cannot be dropped. The resulting paragraph would be: This uniqueness requirement allows host software layers above IP (application software and transport protocols) to identify connections using both the source and destination IP addresses. While this does increase the complexity of such software, it also facilitates more reliable use of link-local addresses which might otherwise be ambiguous. Uniqueness of source addresses on the multi-homed host allows connections to the same destination address on different links to be disambiguated by their different source addresses. > section 5, 1st pp: > > > The use of IPv4 Link-Local Addresses may open a network host to new > > attacks. In particular, a host that previously did not have an IP > > address, and no IP stack running, was not susceptible to IP-based > > attacks. By configuring a working address, the host may now be > > vulnerable to IP-based attacks. > > add at the end: > > ] Similarly, a host which was protected (to whatever degree) > ] from threats from other hosts via an external filter or firewall > ] may be exposed to new and different threats as a consequence of > ] link-local addressing. 'New and different' here means something like 'previously prevented' right? The threats are not new or different. If the firewall/filter were to fail or be improperly configured, the *same* threats would arise. The hidden assumption: LL is being used on a link which is more accessible than the link protected by the firewall/filter. This may be the case, but it is just as likely as the host being attached to an insecure link using non-LL configuration. There is nothing specific to LL which adds or exposes new threats, except that a - an attacker may subvert LL configuration in the first place b - hosts may communicate where before they would fail to, lacking configuration An attacker wishing to deny service, could use ARP to accomplish this just as easily as the attack (a). The ad absurdum conclusion of your text and (b) above are that any network configuration which enables communication exposes a host to new and different (previously prevented) threats. While this is true, it is hardly worth pointing out. If any text is to be added (and let's not), it should be this: "Once a host is configured and can operate on an IP network, it may be exposed to previously prevented threats." > 2nd pp: > > > The ARP protocol [RFC 826] is insecure. A malicious host may send > > fraudulent ARP packets on the network, interfering with the correct > > operation of other hosts. For example, it is easy for a host to > > answer all ARP requests with replies giving its own hardware address, > > thereby claiming ownership of every address on the network. > > suggested improvement: > > ] Link-local address negotiation uses the ARP protocol [RFC 826] which > ] is known to be insecure. A malicious host may send fraudulent ARP > ] packets on the network, interfering with the correct operation of > ] other hosts. For example, it is easy for a host to answer some or > ] all ARP requests with replies giving its own hardware address, thereby > ] claiming ownership of those addresses, causing their traffic to be > ] mis-directed, and generally denying use of the network to those hosts. > ] These threats exist for any use of unsecured ARP, whether for link-local > ] addresses or routable addresses. OK. > 3rd pp: > > > Implementers are advised that the Internet Protocol architecture > > expects every networked device or host must implement security > > which is adequate to protect the resources to which the device > > or host has access, including the network itself, against known > > or credible threats. Even though use of link-local addresses > > may reduce the number of threats to which a device is exposed, > > implementers of devices supporting the Internet Protocol must > > not assume that a customer's local network is free from security > > risks. > > change to: > > ] Implementers are advised that the Internet Protocol architecture > ] expects every networked device or host must implement security > ] which is adequate to protect the resources to which the device > ] or host has access, including the network itself, against known > ] or credible threats. Use of link-local addresses cannot be assumed > ] to reduce the number of threats to which a device is exposed, > ] and in fact it may expose such devices to new threats - particularly > ] if the devices are attached (directly or through a bridge) to > ] unsecured wireless networks. Implementers of devices supporting the > ] Internet Protocol therefore MUST NOT assume that a customer's local > ] network is free from security risks. Keith, you are revising your own verbatim text submitted after the preceding IETF last call! The wordsmithing of this security section has gone on for three years. > section 7.1, 2nd pp: > > this is onerous, as it tries to apply to all applications whether > it is appropriate or not. delete > > > Vendors producing application software which will be used on IP > > implementations supporting IPv4 link-local address configuration > > SHOULD detect and cope with address change events. Vendors > > producing IP implementations supporting IPv4 link-local address > > configuration SHOULD expose address change events to applications. > > and replace with > > ] Because the probability of, and the consequences of, such failures > ] will differ from one application to another, no single remedy is > ] appropriate for all applications. Some applications (for instance, > ] those whose communications with other hosts are typically brief) > ] may be able to simply accept an increased failure rate. Other > ] applications may be able to detect and recover from address changes. > ] Others may elect to avoid using link-local addresses, or to use > ] them only as a last resort. An application which can accept an increased failure rate can detect and cope with address change events already. Exposing address change events doesn't *require* applications to take heed of them, it simply *enables* them to do so, if this is required. The section is fine. > section 7.2, change entire section to: > > ] IPv4 link-local addresses SHOULD NOT be forwarded via an application ^^^^^^^^^^ This was MUST NOT. Changing this text to to SHOULD NOT invites failure but does enable much more interaction (ie. with hosts which do not support LL configuration). > ] protocol (for example in a URL, or some other referral using IP > ] addresses), to a destination which is not link-local, on the same link. > ] However in general there is no way for an application to know whether the > ] destination (or some other party to which the address is subsequently > ] forwarded) can make use of a link-local address being forwarded. If LL locators are forwarded only to LL addresses on the same link, one can be pretty sure the recipient can make use of the locator. I believe we should reject this change until such a time that applications are more aware of scoped addresses. RFC 3111, Service Location Protocol Modifications for IPv6 is an example of protocol modifications required to accomodate scoping rules. > ] Applications that are aware of link-local addresses SHOULD NOT > ] assume that a link-local address is valid for any other host, > ] even another host on the same link. What does this mean? Of course applications must assume that the address of their peer is valid. Otherwise what is the point of communication? The application may determine it was wrong - but in this case it needs to find the address again (using service discovery or name resolution) and attempt to resume communication. Yes - this is a change from the current practice. But it is a very useful change. Appletalk works this way. > ] Similarly, because link-local > ] addresses are inherently ambiguous, LL addresses may be ambiguous outside of their scope, or for very short intervals on the same link, but your statement goes further. We already suggest that applications support renumbering and peers which renumber. > ] applications that are aware of > ] link-local addresses MUST NOT treat a link-local address by itself > ] as any kind of identity for a host. Such applications MAY attempt > ] to contact a host at a link-local address and subsequently verify > ] that host's (perhaps application-specific) identity via other means. It is inappropriate to explain to application authors how to construe the identity of hosts on the network. This is a barrel of worms. We already state that hosts can renumber. Obviously, any static association of an address with a host in this environment would be bound to fail. > section 7.3, change entire section to: > > ] Application software run on a multihomed IP host which supports > ] IPv4 link-local address configuration on more than one interface > ] may fail. This is because application software assumes that an IP > ] address is unambiguous, that it can refer to only one host. IPv4 > ] link-local addresses are unique only on a single link. A host > ] attached to multiple links can easily encounter a situation where > ] the same address is present on more than one interface, or first on > ] one interface, later on another; in any case associated with more > ] than one host. OK. > ] This is similar to the problem with forwarding > ] addresses from one host to another - in either case the address > ] is potentially being used on a link on which it is invalid or > ] associated with a different host. Not OK. This implies that forwarding from one LL scope to another is allowed, which it is not. If it is an example it is not clear what it means. > ] This is a significant departure from the Internet Protocol v4 > ] architecture that assumes uniqueness of addresses. Most existing > ] software is therefore not prepared for this ambiguity. Some > ] of the problems can be addressed by increased complexity in > ] applications software and by changes to application programming > ] interfaces, but in general the lack of a global address space > ] makes many operations difficult or infeasible. This paragraph adds only dire admonition to the content above. It detracts from the current text: Most existing software is not prepared for this ambiguity. In the future, application programming interfaces could be developed to prevent this problem. This issue is discussed in Section 3. Best regards, Erik From owner-zeroconf@merit.edu Thu Sep 26 09:02:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05581 for ; Thu, 26 Sep 2002 09:02:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF4A9912CB; Thu, 26 Sep 2002 09:04:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A200912CD; Thu, 26 Sep 2002 09:04:00 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E4111912CB for ; Thu, 26 Sep 2002 09:03:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C44D35DFD7; Thu, 26 Sep 2002 09:03:53 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 35C405DF20 for ; Thu, 26 Sep 2002 09:03:53 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8QD3n024872; Thu, 26 Sep 2002 09:03:49 -0400 (EDT) Message-Id: <200209261303.g8QD3n024872@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Guttman Cc: Keith Moore , iesg@ietf.org, zeroconf@merit.edu Subject: Re: specific comments on draft-ietf-zeroconf-ipv4-linklocal-07 In-reply-to: (Your message of "Thu, 26 Sep 2002 11:33:10 +0200.") Date: Thu, 26 Sep 2002 09:03:49 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > On Wed, 25 Sep 2002, Keith Moore wrote: > > these changes by themselves do not suffice to fix all of the > > problems in the document, but I think they should be made anyway. > > Keith, > > Do you intend to send more comments at a later time? well, I'll probably reply to some of the responses to my comments. (though not to everyone's responses) but I consider the three sets of comments I've sent: - the analysis comments - the comments and suggested changes specifically about "always on" operation - the other suggested changes to the text to be substantially complete. > > section 1.4: > > > > > Administrators wishing to configure their own local addresses > > > (using manual configuration, a DHCP server, or any other mechanism > > > not described in this document) should use one of the existing > > > private address prefixes [RFC 1918], not the 169.254/16 prefix. > > > > this is slightly overbroad, as RFC 1918 is intended for disconnected > > networks only. suggest it be changed to: > > > > ] Administrators of networks that are isolated from the Internet, > > ] who wish to configure their own local addresses (using manual > > ] configuration, a DHCP server, or any other mechanism not > > ] described in this document) SHOULD use one of the existing > > ] private address prefixes [RFC 1918], rather than the 169.254/16 > > ] prefix or any other prefix not assigned to that network. > > The SHOULD is OK. The bit about disconnected networks is not OK. I don't think it's OK for this WG to extend the scope of RFC 1918. This is not within the zeroconf WG's charter. RFC 1918 was very carefully limited in scope for good reasons, and the use of RFC 1918 for other purposes has been demonstrated to be harmful. > This document does not describe network address assignment policy, that > is on which sort of networks an administrator might assign whatever > addresses he or she decides to configure. This paragraph says only that > if there is such a policy, the addresses SHOULD be from the RFC 1918 > range not from the LL range. and this document is incorrect in doing so. RFC 1918 addresses should be used consistently with RFC 1918. it's certainly appropriate to mention RFC 1918, but not to specify conditions for use of RFC 1918 addresses that are more liberal than those in RFC 1918. > > section 2.9 seems incomplete. here's an attempt at a rewrite: > > > > ] 2.9 Higher-Layer Protocol Considerations > > ] > > ] Similar considerations apply at layers above IP. > > Similar to what? I think this was left over from earlier text; I don't see a problem in deleting that line. > > ] Any application which uses IP addresses to in referrals that are > > ] sent to other hosts will fail if link-local IP addresses are > > ] sent to hosts that are unable to use them. This could happen > > ] for a variety of reasons: (a) the host receiving the address does > > ] not have access to the same link, (b) the host receiving the address > > ] has multiple interfaces supporting link-local addressing, causing > > ] the link-local address to be ambiguous, or (c) the host receiving > > ] the address does not support link-local addressing. > > (c) is false. The host receiving the LL address reference does not need > to *have* a LL address to know how to receive from a LL source or send > to a LL destination. (c) is correct. if an app sends an LL address in a referral to a host that is not able to use the LL address for any reason, this can cause the app to fail. one reason the host might not be able to use the LL address is that it doesn't support LL addressing - i.e. it treats the LL address as if it were an ordinary IPv4 address, and sends it to the default router. note that (c) doesn't say "...host receiving the address does not have an LL address" it says "...does not support link-local addressing". > (a) and (b) are covered in section 7 as are the next two paragraphs. there is some redundancy between the two. I don't mind if these are consolidated as long as the result is complete and accurate. > > ] For example, if web pages (including automatically generated web > > ] pages) contain links with embedded link-local addresses, those > > ] links will fail if those pages are accessible from (perhaps via > > ] a cache or proxy) hosts outside the local link where the addresses > > ] are valid, or if the host migrates outside that local link. > > ] > > ] Applications that are aware of link-local addressing SHOULD > > ] avoid using them in referrals to other hosts. In general it > > ] is difficult for an application to know whether an address > > ] means the same thing to another host as it means to the local > > ] host - even if the other host is on the same link - and thus > > ] it is difficult for an application to determine whether it > > ] is safe to use link-local addresses in referrals. In addition, > > ] there is always a chance that a link-local address-to-host > > ] binding will be revoked due to an address conflict. > > --- > > > ] It should be noted that DNS is an example of an application > > ] that performs address referrals. For these reasons storing > > ] use of DNS to return link-local addresses is NOT RECOMMENDED. > > This text is much stronger than that which is in the current draft. > The current text, BTW, was crafted with your assistance, Keith. understood - I think this text is clearer and better integrated with the other text I suggested. > > section 3.3, 4th pp: > > > > > This uniqueness requirement simplifies host software layers above > > > IP (application software and transport protocols) by allowing them > > > to identify connections using only the source and destination IP > > > addresses, without also needing interface identifiers. Since link- > > > local addresses are only unique per-link, hosts on different links > > > could be using the same link-local address. Uniqueness of source > > > addresses on the multi-homed host allows connections to the same > > > destination address on different links to be disambiguated by their > > > different source addresses. > > > > this certainly doesn't "simplify" host software - it makes it more > > complex by increasing the burden on apps - it's no longer sufficient > > for an app to just specify a destination IP address to reach a host, > > it now has to specify a source,destination pair. suggested rewrite: > > > > ] This uniqueness requirement allows host software layers above > > ] IP (application software and transport protocols) to identify > > ] connections using both the source and destination IP addresses. > > ] While this does increase the complexity of such software, it > > ] also facilitates more reliable use of link-local addresses which > > ] might otherwise be ambiguous. > > OK, except your suggested text lacks the final sentence of the preceding > paragraph, which clarifies the intent and mechanism and cannot be > dropped. The resulting paragraph would be: > > This uniqueness requirement allows host software layers above > IP (application software and transport protocols) to identify > connections using both the source and destination IP addresses. > While this does increase the complexity of such software, it > also facilitates more reliable use of link-local addresses which > might otherwise be ambiguous. Uniqueness of source addresses on > the multi-homed host allows connections to the same destination > address on different links to be disambiguated by their different > source addresses. okay, I guess I thought the last sentence was redundant, but there's nothing incorrect about it, so I don't object to leaving it in. > > section 5, 1st pp: > > > > > The use of IPv4 Link-Local Addresses may open a network host to new > > > attacks. In particular, a host that previously did not have an IP > > > address, and no IP stack running, was not susceptible to IP-based > > > attacks. By configuring a working address, the host may now be > > > vulnerable to IP-based attacks. > > > > add at the end: > > > > ] Similarly, a host which was protected (to whatever degree) > > ] from threats from other hosts via an external filter or firewall > > ] may be exposed to new and different threats as a consequence of > > ] link-local addressing. > > 'New and different' here means something like 'previously prevented' > right? The threats are not new or different. If the firewall/filter > were to fail or be improperly configured, the *same* threats would > arise. no, it's a potentially different set of threats - because the set of threats that had previously existed from a wired/configured interface (which were perhaps dealt with by filters/firewalls) may be combined with a new set of threats from a wireless/unconfigured interface. (or a wired/unconfigured interface that is bridged to a wireless network). it's the same broad class of threats - in that they are attacks mounted from a network - the point is that you need to do a different threat analysis on the new threats. > The hidden assumption: LL is being used on a link which is more > accessible than the link protected by the firewall/filter. This > may be the case, but it is just as likely as the host being attached to > an insecure link using non-LL configuration. There is nothing specific > to LL which adds or exposes new threats, except that I'd say that LL is being used on a link which is *differently* accessible than the link protected by the firewall/filter, and thus LL is potentially subject to *different* threats. If 'new' seems too sensitive, I'd consider the following sufficient: ] Similarly, a host which was protected (to whatever degree) ] from threats from other hosts via an external filter or firewall ] may be exposed to a different set of threats as a consequence of ] link-local addressing. ...perhaps with the caveat that these threats require separate analysis and potentially different countermeasures. > > a - an attacker may subvert LL configuration in the first place > > b - hosts may communicate where before they would fail to, lacking > configuration > > An attacker wishing to deny service, could use ARP to accomplish > this just as easily as the attack (a). > > The ad absurdum conclusion of your text and (b) above are that any > network configuration which enables communication exposes a host to new > and different (previously prevented) threats. While this is true, it is > hardly worth pointing out. I disagree strongly - the real security danger of LL is that it introduces new threats to a host or network without anyone at that host or network doing anything except to upgrade to an OS that supports LL (or to get a new machine whose OS supports LL). A warning in the RFC at least puts people on notice, and we require all RFCs to adequately document security considerations. Why does zeroconf merit an exception to this rule? documenting security considerations isn't about blame - it's about making people aware of the consequences of using this technology. actually it should be more-or-less understood that these problems aren't zeroconf's "fault" - if they could feasibly be addressed by zeroconf then our process expects zeroconf to address them. as it is, about the only thing that zeroconf can do to address these security problems and still provide linklocal addressing is to provide a way to turn LL off - which is why I've insisted that this option be available. > If any text is to be added (and let's not), it should be this: > > "Once a host is configured and can operate on an IP network, it > may be exposed to previously prevented threats." that's subtly misleading - the real point is that you have to deal differently with threats coming from LL than you do with threats coming from a configured network that has means of filtering. if you discover a new threat from your configured network (not one which was "previously prevented") you probably have to deal with it on LL also, just in a different way. one consequence of LL might be that admins have to rely more on host-based filtering than firewall-based filtering. which I'd probably see as a Good Thing. > > 3rd pp: > > > > > Implementers are advised that the Internet Protocol architecture > > > expects every networked device or host must implement security > > > which is adequate to protect the resources to which the device > > > or host has access, including the network itself, against known > > > or credible threats. Even though use of link-local addresses > > > may reduce the number of threats to which a device is exposed, > > > implementers of devices supporting the Internet Protocol must > > > not assume that a customer's local network is free from security > > > risks. > > > > change to: > > > > ] Implementers are advised that the Internet Protocol architecture > > ] expects every networked device or host must implement security > > ] which is adequate to protect the resources to which the device > > ] or host has access, including the network itself, against known > > ] or credible threats. Use of link-local addresses cannot be assumed > > ] to reduce the number of threats to which a device is exposed, > > ] and in fact it may expose such devices to new threats - particularly > > ] if the devices are attached (directly or through a bridge) to > > ] unsecured wireless networks. Implementers of devices supporting the > > ] Internet Protocol therefore MUST NOT assume that a customer's local > > ] network is free from security risks. > > Keith, you are revising your own verbatim text submitted after the > preceding IETF last call! yes, it's subsequently become apparent to me that LL does not necessarily reduce threats - it changes them. so the text I suggested earlier was misleading in this way. > The wordsmithing of this security section has gone on for three years. security is often difficult to get right, particularly when people are in denial about the problems. though it's not as if we didn't know that there would be security issues with zeroconf - I seem to recall such issues being raised at two separate zeroconf BOFs even before the WG was formed. > > section 7.1, 2nd pp: > > > > this is onerous, as it tries to apply to all applications whether > > it is appropriate or not. delete > > > > > Vendors producing application software which will be used on IP > > > implementations supporting IPv4 link-local address configuration > > > SHOULD detect and cope with address change events. Vendors > > > producing IP implementations supporting IPv4 link-local address > > > configuration SHOULD expose address change events to applications. > > > > and replace with > > > > ] Because the probability of, and the consequences of, such failures > > ] will differ from one application to another, no single remedy is > > ] appropriate for all applications. Some applications (for instance, > > ] those whose communications with other hosts are typically brief) > > ] may be able to simply accept an increased failure rate. Other > > ] applications may be able to detect and recover from address changes. > > ] Others may elect to avoid using link-local addresses, or to use > > ] them only as a last resort. > > An application which can accept an increased failure rate can detect > and cope with address change events already. Exposing address > change events doesn't *require* applications to take heed of them, it > simply *enables* them to do so, if this is required. no it doesn't "enable" them to do so, because it doesn't provide them with the mechanism to do so - and many application protocols simply lack such mechanisms. that's part of why SHOULD is onerous. the other part is that it's painting with too broad a brush - as I point out, different apps need to cope with this in different ways. > > > section 7.2, change entire section to: > > > > ] IPv4 link-local addresses SHOULD NOT be forwarded via an application > ^^^^^^^^^^ > This was MUST NOT. Changing this text to to SHOULD NOT invites failure > but does enable much more interaction (ie. with hosts which do not > support LL configuration). again, the idea is that different apps need to deal with LL in different ways- categorically forbidding apps to use LL in referrals to nonlocal hosts may prevent them from working even when they take appropriate measures in using those referrals. hint: the host that an address referral is initially sent to may not be the one that ends up trying to use that address. > > ] protocol (for example in a URL, or some other referral using IP > > ] addresses), to a destination which is not link-local, on the same link. > > ] However in general there is no way for an application to know whether the > > ] destination (or some other party to which the address is subsequently > > ] forwarded) can make use of a link-local address being forwarded. > > If LL locators are forwarded only to LL addresses on the same link, one > can be pretty sure the recipient can make use of the locator. again, the issue is not where the address is initially forwarded, it's which hosts eventually end up trying to use that address, and also whether they apply appropriate checks or blindly trust it. > I believe we should reject this change until such a time that > applications are more aware of scoped addresses. RFC 3111, Service > Location Protocol Modifications for IPv6 is an example of protocol > modifications required to accomodate scoping rules. I believe the zeroconf WG should stop pretending it understands the needs of all applications well enough to dictate their behavior. In other words, it should state the limitations on use of LL addresses (they're only valid on the same link), rather than prescribe how apps should implement those limitations. > > ] Applications that are aware of link-local addresses SHOULD NOT > > ] assume that a link-local address is valid for any other host, > > ] even another host on the same link. > > What does this mean? Of course applications must assume that the address > of their peer is valid. Otherwise what is the point of communication? the point is that just because you have an LL-address-to-host binding that was valid at one time from one location does not mean that it is valid at another time and at a different location, so you need to use some other means (like an application-specific ID) to verify that the address you have is still valid. perhaps it could be stated more clearly. > The application may determine it was wrong - but in this case it needs > to find the address again (using service discovery or name resolution) > and attempt to resume communication. right - or it might use its own internal referral system to try to get a more recent address. > Yes - this is a change from the current practice. But it is a very > useful change. Appletalk works this way. application developers might or might not see the imposition of LL as "useful". LL can be anywhere from very useful to a major hinderance depending on the application. > > > ] Similarly, because link-local > > ] addresses are inherently ambiguous, > > LL addresses may be ambiguous outside of their scope, or for very short > intervals on the same link, but your statement goes further. We already > suggest that applications support renumbering and peers which renumber. never mind that it's often impractical for apps to do that, that there's no support in TCP or most apps protocols to deal with address changes. apps developers are supposed to wave a magic wand and pull a rabbit out of the hat because the zeroconf WG told them to. > > ] applications that are aware of > > ] link-local addresses MUST NOT treat a link-local address by itself > > ] as any kind of identity for a host. Such applications MAY attempt > > ] to contact a host at a link-local address and subsequently verify > > ] that host's (perhaps application-specific) identity via other means. > > It is inappropriate to explain to application authors how to construe > the identity of hosts on the network. This is a barrel of worms. We > already state that hosts can renumber. Obviously, any static > association of an address with a host in this environment would be bound > to fail. well, I thought I was stating the obvious here. LL addresses are not stably bound to hosts, and are subject to change without notice, so they're not host identities in any sense. even DHCP assigned routable addresses are bound to those hosts for the duration of the lease. it seems that you don't want the limitations of LL addresses to be clearly explained. it's hard to see how this attitude serves the internet community. > > section 7.3, change entire section to: > > > > ] Application software run on a multihomed IP host which supports > > ] IPv4 link-local address configuration on more than one interface > > ] may fail. This is because application software assumes that an IP > > ] address is unambiguous, that it can refer to only one host. IPv4 > > ] link-local addresses are unique only on a single link. A host > > ] attached to multiple links can easily encounter a situation where > > ] the same address is present on more than one interface, or first on > > ] one interface, later on another; in any case associated with more > > ] than one host. > > OK. > > > ] This is similar to the problem with forwarding > > ] addresses from one host to another - in either case the address > > ] is potentially being used on a link on which it is invalid or > > ] associated with a different host. > > Not OK. This implies that forwarding from one LL scope to another is > allowed, which it is not. If it is an example it is not clear what it > means. No, it's not acceptable for this group to insist that apps forward addresses only along the lines of network topology. If an app has a referral service that exists on a node that doesn't happen to be local, then the app needs to be able to forward addresses to that node. It's recognized that those addresses are only valid on the same link, but insisting that the app needs to implement a separate referral service on every link in order to use LL addresses is overbroad. > > ] This is a significant departure from the Internet Protocol v4 > > ] architecture that assumes uniqueness of addresses. Most existing > > ] software is therefore not prepared for this ambiguity. Some > > ] of the problems can be addressed by increased complexity in > > ] applications software and by changes to application programming > > ] interfaces, but in general the lack of a global address space > > ] makes many operations difficult or infeasible. > > This paragraph adds only dire admonition to the content above. > It detracts from the current text: > > Most existing software is not prepared for this > ambiguity. In the future, application programming interfaces could > be developed to prevent this problem. This issue is discussed in > Section 3. The "current" text is incorrect because it states that API changes could prevent the problem. the text I suggested is entirely correct "in general the lack of a global address space makes many operations difficult or infeasible". it's high time we stopped lying about the limitations of scoped addresses. Keith From owner-zeroconf@merit.edu Thu Sep 26 10:56:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10418 for ; Thu, 26 Sep 2002 10:56:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F34B8912DC; Thu, 26 Sep 2002 10:57:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC9ED912DD; Thu, 26 Sep 2002 10:57:54 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5994C912DC for ; Thu, 26 Sep 2002 10:57:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 46DAD5DFE9; Thu, 26 Sep 2002 10:57:53 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 133D25DD93 for ; Thu, 26 Sep 2002 10:57:53 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA04639 for ; Thu, 26 Sep 2002 10:57:52 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA10590 for ; Thu, 26 Sep 2002 10:54:19 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA09177 for ; Thu, 26 Sep 2002 10:49:41 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Thu, 26 Sep 2002 10:49:39 -0400 Subject: Re: specific comments on draft-ietf-zeroconf-ipv4-linklocal-07 From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200209261303.g8QD3n024872@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 09/26/2002 09:03, "Keith Moore" wrote: >> 'New and different' here means something like 'previously prevented' >> right? The threats are not new or different. If the firewall/filter >> were to fail or be improperly configured, the *same* threats would >> arise. > > no, it's a potentially different set of threats - because the set > of threats that had previously existed from a wired/configured interface > (which were perhaps dealt with by filters/firewalls) may be combined with > a new set of threats from a wireless/unconfigured interface. (or a > wired/unconfigured interface that is bridged to a wireless network). > it's the same broad class of threats - in that they are attacks mounted > from a network - the point is that you need to do a different threat > analysis on the new threats. The threats are going to be exactly the same. The sources will be different. However, a conscientious network admin will have taken LL and new IETF standards into account as they are released. LL is old enough that it shouldn't be a surprise to anyone. As well, if a threat is *truly* new...i.e. Has never been seen before, then, logic dictates that you cannot analyze it until it has happened at least once, and been documented in enough detail to be analyzed. This is analogous to the way any countermeasures work. Threat happens -> Threat is documented => Countermeasures are developed and tested => Countermeasure are deployed. Exactly how can any standard change that procedure? > >> The hidden assumption: LL is being used on a link which is more >> accessible than the link protected by the firewall/filter. This >> may be the case, but it is just as likely as the host being attached to >> an insecure link using non-LL configuration. There is nothing specific >> to LL which adds or exposes new threats, except that > > I'd say that LL is being used on a link which is *differently* > accessible than the link protected by the firewall/filter, and > thus LL is potentially subject to *different* threats. > > If 'new' seems too sensitive, I'd consider the following sufficient: > > ] Similarly, a host which was protected (to whatever degree) > ] from threats from other hosts via an external filter or firewall > ] may be exposed to a different set of threats as a consequence of > ] link-local addressing. > > ...perhaps with the caveat that these threats require separate > analysis and potentially different countermeasures. Most likely. But the information in the standard will tell anyone with the correct training and experience exactly that anyway. In addition, if the standard attempts to propose specific solutions to as - yet unknown threats, (we'll assume predicting the future is possible in Einsteinian space-time for the sake of argument), then anyone developing threats would have to be quite stupid to use a threat method that is well-documented with well-documented countermeasures. It *will* however make a handy guidebook to what *not* to do, and encourage even more innovation in the area of attacking systems. That's the biggest reason for not including howtos in a standard. In the end, you gain nothing from it, while encouraging ISV's to ignore that part, if not all of the standard. I assume that encouraging irrelevance is not part of the WG's charter. > >> If any text is to be added (and let's not), it should be this: >> >> "Once a host is configured and can operate on an IP network, it >> may be exposed to previously prevented threats." > > that's subtly misleading - the real point is that you have to deal differently > with threats coming from LL than you do with threats coming from a > configured network that has means of filtering. if you discover a new > threat from your configured network (not one which was "previously > prevented") you probably have to deal with it on LL also, just in > a different way. If I filter out the entire LL subnet as being invalid on all my hosts, then I've effectively shut it off. Of course, that means destroying a significant bit of functionality. That's always the balance in security. But once again, LL is not going to create new attacks. It's not even creating a new window for the attack. About the only thing that's remotely new is that *depending on implementation*, that window is going to be there, open or not. So you have to deal with that. I also fail to see how the constant existence of LL will create new threats. If it does, then I propose that all forms of LL be removed from all networks, including IPv6 immediately. > > one consequence of LL might be that admins have to rely more on > host-based filtering than firewall-based filtering. which I'd probably > see as a Good Thing. Any good admin is doing this anyway for critical hosts. ^^^^^^^^^^ >> This was MUST NOT. Changing this text to to SHOULD NOT invites failure >> but does enable much more interaction (ie. with hosts which do not >> support LL configuration). > > again, the idea is that different apps need to deal with LL in different > ways- categorically forbidding apps to use LL in referrals to nonlocal > hosts may prevent them from working even when they take appropriate measures > in using those referrals. hint: the host that an address referral > is initially sent to may not be the one that ends up trying to use > that address. Which is why applications should not assume that an IP address is tied to a host. DHCP, even bootp introduced this problem as well, and it's been being handled for quite some time now. This is why there are far better ways of dealing with connecting to a specific physical host than IP address. >> If LL locators are forwarded only to LL addresses on the same link, one >> can be pretty sure the recipient can make use of the locator. > > again, the issue is not where the address is initially forwarded, it's which > hosts eventually end up trying to use that address, and also whether they > apply appropriate checks or blindly trust it. Blindly trusting an address is pretty silly behavior when you realize that bootp and DHCP have meant you can't trust IP addresss assignment for some time now. > >> I believe we should reject this change until such a time that >> applications are more aware of scoped addresses. RFC 3111, Service >> Location Protocol Modifications for IPv6 is an example of protocol >> modifications required to accomodate scoping rules. > > I believe the zeroconf WG should stop pretending it understands the needs > of all applications well enough to dictate their behavior. In other words, > it should state the limitations on use of LL addresses (they're only valid > on the same link), rather than prescribe how apps should implement those > limitations. But you are advocating the WG create implementation standards for LL on/off and security. >> What does this mean? Of course applications must assume that the address >> of their peer is valid. Otherwise what is the point of communication? > > the point is that just because you have an LL-address-to-host binding > that was valid at one time from one location does not mean that it > is valid at another time and at a different location, so you need to > use some other means (like an application-specific ID) to verify that > the address you have is still valid. perhaps it could be stated more > clearly. How does this problem differ from DHCP and/or bootp, or any protocol that does dynamic address assignment. This problem has been solved for years now. >> Yes - this is a change from the current practice. But it is a very >> useful change. Appletalk works this way. > > application developers might or might not see the imposition of LL > as "useful". LL can be anywhere from very useful to a major > hinderance depending on the application. I fail to see how it is a change from current practices at all. Dynamic address assignment is a standard now, and means that you cannot assume the validity of a given address outside of a specific connection. Just because an address was assigned to host 'foo' an hour ago, doesn't mean that host 'foo' is going to have it now. If the host never disconnects from the link, then it isn't going normally change it's address, although there are DHCP setups where this will happen. So we already *now*, *today* are dealing with: 1) Inconsistent IP address to Host assignments between connections to the link. 2) Inconsistent IP address to Host assignments for during a given connections on the link. So LL is introducing absolutely no *new* problems here. Which means we can really stop worrying that it is. >> LL addresses may be ambiguous outside of their scope, or for very short >> intervals on the same link, but your statement goes further. We already >> suggest that applications support renumbering and peers which renumber. > > never mind that it's often impractical for apps to do that, that there's > no support in TCP or most apps protocols to deal with address changes. > apps developers are supposed to wave a magic wand and pull a rabbit out > of the hat because the zeroconf WG told them to. Then how are DHCP/bootP/other dynamic assignment schemes functional. Apps are dealing with this now, and have been for many years now. >> It is inappropriate to explain to application authors how to construe >> the identity of hosts on the network. This is a barrel of worms. We >> already state that hosts can renumber. Obviously, any static >> association of an address with a host in this environment would be bound >> to fail. > > well, I thought I was stating the obvious here. LL addresses are not > stably bound to hosts, and are subject to change without notice, so they're > not host identities in any sense. even DHCP assigned routable addresses > are bound to those hosts for the duration of the lease. But the lease can change, the address can change. You can't assume that any address will be assigned to any host five minutes from now. Any application that does so is broken. > > it seems that you don't want the limitations of LL addresses to be clearly > explained. it's hard to see how this attitude serves the internet community. Because the limitations you speak of exist in DHCP and other dynamic addressing standards. I fail to see how refusing to realize this serves this WG. >> This paragraph adds only dire admonition to the content above. >> It detracts from the current text: >> >> Most existing software is not prepared for this >> ambiguity. In the future, application programming interfaces could >> be developed to prevent this problem. This issue is discussed in >> Section 3. > > The "current" text is incorrect because it states that API changes could > prevent the problem. the text I suggested is entirely correct "in general > the lack of a global address space makes many operations difficult or > infeasible". How is this suddenly new to LL? john -- John C. Welch IT Manager MIT Police (617) 253 - 3093 work (508) 579 - 7380 cell (617) 253 - 8822 fax From owner-zeroconf@merit.edu Thu Sep 26 11:10:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11012 for ; Thu, 26 Sep 2002 11:10:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 99AD7912DE; Thu, 26 Sep 2002 11:12:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B081912DF; Thu, 26 Sep 2002 11:12:29 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F587912DE for ; Thu, 26 Sep 2002 11:12:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4D3055E00B; Thu, 26 Sep 2002 11:12:28 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id CCF915E009 for ; Thu, 26 Sep 2002 11:12:27 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g8QFCR026156; Thu, 26 Sep 2002 11:12:27 -0400 (EDT) Message-Id: <200209261512.g8QFCR026156@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: zeroconf@merit.edu Subject: another wrinkle Cc: moore@cs.utk.edu From: Keith Moore Date: Thu, 26 Sep 2002 11:12:27 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk I've seen a couple of people (most recently Erik Nordmark on the v6ops list) suggest using v4LL as a means to allow hosts to acquire v4 addresses that can then be used in conjunction with NATs to give those hosts external access. I don't think either the security implications of this approach or the impact on applications associated with this approach have been adequately examined. I don't know what changes to suggest to the LL document except perhaps to state the above, and as yet another good reason to weaken the "hosts may assume LL addresses are local" claim. Keith From owner-zeroconf@merit.edu Thu Sep 26 11:16:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11153 for ; Thu, 26 Sep 2002 11:16:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 72F4B9122D; Thu, 26 Sep 2002 11:17:01 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 317E2912DF; Thu, 26 Sep 2002 11:17:01 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 050589122D for ; Thu, 26 Sep 2002 11:16:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D568F5DFF5; Thu, 26 Sep 2002 11:16:59 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 732975DE83 for ; Thu, 26 Sep 2002 11:16:59 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA18175 for ; Thu, 26 Sep 2002 11:16:58 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA26062 for ; Thu, 26 Sep 2002 11:16:58 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA22890 for ; Thu, 26 Sep 2002 11:16:58 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Thu, 26 Sep 2002 11:16:56 -0400 Subject: Re: another wrinkle From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200209261512.g8QFCR026156@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 09/26/2002 11:12, "Keith Moore" wrote: > I've seen a couple of people (most recently Erik Nordmark on the v6ops list) > suggest using v4LL as a means to allow hosts to acquire v4 addresses that > can then be used in conjunction with NATs to give those hosts external access. > > I don't think either the security implications of this approach or the > impact on applications associated with this approach have been adequately > examined. > > I don't know what changes to suggest to the LL document except perhaps > to state the above, and as yet another good reason to weaken the > "hosts may assume LL addresses are local" claim. None. There is absolutely no way to cleanly deal with that inside of ten pages of implementation details. The problem you talk about WRT LL and NAT exists now with any other address assignment method and NAT anyway. Restating the obvious is a waste of electrons. john -- John C. Welch IT Manager MIT Police (617) 253 - 3093 work (508) 579 - 7380 cell (617) 253 - 8822 fax