From owner-zeroconf@merit.edu Wed Feb 5 06:50:57 2003 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 GAA19453 for ; Wed, 5 Feb 2003 06:50:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 780CC91212; Wed, 5 Feb 2003 06:54:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 35ABD91257; Wed, 5 Feb 2003 06:54:26 -0500 (EST) 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 08F8191212 for ; Wed, 5 Feb 2003 06:54:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id D320B5DF6E; Wed, 5 Feb 2003 06:54:24 -0500 (EST) 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 822F15DF6C for ; Wed, 5 Feb 2003 06:54:24 -0500 (EST) 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 EAA20862 for ; Wed, 5 Feb 2003 04:54:18 -0700 (MST) Received: from Sun.COM (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 ESMTP id h15BsGl21102 for ; Wed, 5 Feb 2003 12:54:16 +0100 (MET) Message-ID: <3E40FB68.1D4AF1B0@Sun.COM> Date: Wed, 05 Feb 2003 12:54:16 +0100 From: erik guttman Reply-To: Erik.Guttman@Sun.COM Organization: Sun Microsystems X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: WG consensus action: when to configure LL addrs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit This messages is an assessment of working group consensus from discussion on the WG mailing list in the past weeks as a response to Thomas Narten's posting below. The summary of the consensus follows. ACCEPTED: IPv4 LL configuration of interfaces has restricted applicability to the case where an interface does not obtain configuration in any other way (such as manual configuration, DHCP, etc.) A host obtaining such a configuration MUST NOT continue using the IPv4 LL configuration as well. NOTE WELL: This is a major change to the existing draft. ACCEPTED: Hosts conforming to the specification which receive an datagram with an IPv4 LL source address MUST NOT reply by sending a datagram to a router for forwarding. The host MUST use ARP to resolve the address and forward the datagram to the destination the IPv4 LL address resolves to. NOTE WELL: A compliant host can communicate with a peer which has IPv4 LL address even if the host has a global address by applying this datagram forwarding policy. WG chair assessment: On both of these points there was clear WG consensus. This resolves a number of issues of source address selection. The above also ameliorates issues arising from application interoperability when using addresses of mixed scopes since (a) systems will not operate with both link-local and global scope addresses and (b) it is likely that if DHCP or manual configuration is performed, it will be to all (not some subset) of hosts on the network *eventually.* Further: This is how IPv4 LL autoconfiguration works today in Windows systems and most versions of Apple Macintosh. REJECTED: This specification will define or require some additional mechanism to disable IPv4 LL autoconfiguration. WG chair assessment: This suggestion has been brought up in past last calls and again in this discussion. There again fails to be anything like working group consensus to support or introduce this feature. There are very clear and unchallenged technical arguments from Ted Lemon indicating that there are severe security considerations with coercive deactivation IPv4 LL autoconfiguration. These changes will result in changes to the IPv4 LL specification (the text of which is not included in this message). A few comments are interspersed with Thomas's original message. Sender: Thomas Narten Date: 22.01.03 15:50 Subject: WG decision: when to configure LL addrs > This WG needs to declare consensus on some basic issues, or it will > never get done. > > The note below from Keith summarizes what I see a lot of other folk > seeming to agree with. > > So, I would like to ask the WG to answer the following questions: > > 1) Should the ID recommend that LL addresses only be configured as per > below. Please answer clearly, along the lines of > > a) yes, I think this is what the document should say (maybe with > some small tweaks, which then need to be explained) 1a received general support. > b) no, this is a showstopper for me (and explain why, so the rest > of the WG can understand and then agree or disagree with your > position) > > c) Not my first choice, but I can live with it. > > Note that two things need to happen. First, get general agreement on > the direction, second, agreement on the exact text to go in the > document. > > It would be helpful if folk would post their views (including lurkers) > but also to restrict themselves to answering the above questions. If > only a small number of the usual suspects post, we will risk not have > enough input to make a clear consensus call. Thus, everyone who cares > should speak up. > > Thomas > > Keith Moore writes: > > >>> On Wed, 22 Jan 2003 10:01:30 +1000 (EST) >>> Ian Lister wrote: >>> On Tue, 21 Jan 2003, Philip Nye wrote: >>>>Joshua, >>>> >>>>> This problem is not as significant as it may seem. If IPv4LLs are >>>>> only acquired on an interface when no global address can be (no >>>>> DHCP, manual config, or other config method), the device will be >>>>> unable to communicate with anything off of the local link through >>>>> that interface. >>>> >>>> Your analysis is reasonable - but it is rather off the track >>>> because the current draft recommends that IPv4LL be turned on >>>> even when a global address IS found - and this is the source >>>> of the problems. >>> >>> It is not off track if the draft is amended to specify the behaviour >>> Joshua described (which is currently implemented in Mac OS and IMO >>> is the most appropriate behaviour). With that behaviour IPv4LL is >>> used only where there is no alternative, so there can be no >>> accusations of breakage. Is there anybody who actually wants to >>> argue against this? >> >> now I'm losing track of what is meant by "used" - >> >> - when should an IPv4LL address be configured by a host? >> >> suggest: if the host is explicitly configured to do so, OR >> if the host has attempted and failed to acquire a routable >> address via DHCP >> (alternative: provide a lighter weight mechanism by which a >> host can acquire a routable address, netmask, and default >> route, in response to its attempt to claim an IPv4LL address) Aidan Williams suggested: > The word "routable" is not relevant and should be dropped. > A host may also choose not to use DHCP and use a LL address instead, > but perhaps that is adequately covered by "explicitly configured". This was generally agreed to by those who responded. I take this to imply that an interface will be configured with an IPv4 LL address *only if it does not obtain address configuration by some other means.* This takes Keith's text and generalizes it, removing the 'routable' qualifier to the address and the mention of DHCP. (There are other ways to obtain an address - RARP, manual configuration, etc). >> - when should an IPv4LL address be used by a host as a source >> address? >> >> suggest: when the only addresses available to the host are >> IPv4LL addresses, OR >> when the application has explicitly specified the source >> address to use, OR >> when the application has explicitly specified the interface to >> use and the IPv4LL address is the only address associated with >> that interface. Aidan responded: > I don't agree with the "only address associated with the interface" > part. If you *have* an IPv4-LL address it should be used when > connecting to IPv4-LL destinations. > > I'm happy with Section 2.6, "Source Address Selection" as it is. Given that an interface will now only have an IPv4 LL address configured if it does not have any other address configuration, I do not see that there is any difference between Keith and Aidan's positions. >> - when should a host honor an attempt to connect to an IPv4LL >> address that was once configured by that host? >> >> suggest: anytime the address is still valid (e.g. there have >> been no conflicting claims) and there is a process listening >> for connections either specifically to that address or >> for incoming connections at any of the host's addresses. >> >> - when should an application attempt to connect to a IPv4LL >> address? >> >> suggest: only when the address is literally specified, or if >> there are no other routable addresses for the destination host >> known to the application. Aidan suggested replacement text for the suggestion which enjoyed wide support: > An application with a choice between connecting to LL address and > non-LL address SHOULD prefer the non-LL address. >> - when should an application send an IPv4LL address in a referral >> to another host? >> >> suggest: only when there are no routable addresses for the >> destination host known to the application. even then, care >> needs to be taken that a host reached at a particular IPv4LL >> address is really the one intended - since IPv4LL addresses >> can be reassigned without notice and/or reused on different >> network segments. Erik Guttman ZEROCONF WG cochair From owner-zeroconf@merit.edu Wed Feb 5 07:03:56 2003 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 HAA20808 for ; Wed, 5 Feb 2003 07:03:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A789C91257; Wed, 5 Feb 2003 07:07:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C90A9127E; Wed, 5 Feb 2003 07:07:26 -0500 (EST) 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 F1B6891257 for ; Wed, 5 Feb 2003 07:07:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id D41F35DDB9; Wed, 5 Feb 2003 07:07:24 -0500 (EST) 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 E28A55DD92 for ; Wed, 5 Feb 2003 07:07:23 -0500 (EST) 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 h15C7Ijf007007; Wed, 5 Feb 2003 22:07:19 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id h15C7He75128; Wed, 5 Feb 2003 22:07:17 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Wed, 5 Feb 2003 22:07:17 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: erik guttman Cc: zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs In-Reply-To: <3E40FB68.1D4AF1B0@Sun.COM> 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 Sounds great - ship it! :-) Actually, just one minor note below. On Wed, 5 Feb 2003, erik guttman wrote: >ACCEPTED: > IPv4 LL configuration of interfaces has restricted applicability > to the case where an interface does not obtain configuration in > any other way (such as manual configuration, DHCP, etc.) A host > obtaining such a configuration MUST NOT continue using the IPv4 > LL configuration as well. I agree that is fine in the absence of explicit configuration to the contrary on the host, but I don't think the protocol should forbid the implementation from allowing the user to manually keep using IPv4LL after a global address has been acquired. I can't imagine that would be too contentious but if it is then forget I mentioned it... Ian From owner-zeroconf@merit.edu Wed Feb 5 07:52:23 2003 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 HAA23316 for ; Wed, 5 Feb 2003 07:52:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6C9169125B; Wed, 5 Feb 2003 07:55:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 363E99127E; Wed, 5 Feb 2003 07:55:52 -0500 (EST) 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 344639125B for ; Wed, 5 Feb 2003 07:55:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1CB155DF73; Wed, 5 Feb 2003 07:55:51 -0500 (EST) 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 A1D215DF70 for ; Wed, 5 Feb 2003 07:55:50 -0500 (EST) 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 HAA29579 for ; Wed, 5 Feb 2003 07:55:50 -0500 (EST) 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 HAA25658 for ; Wed, 5 Feb 2003 07:53:10 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id HAA15232 for ; Wed, 5 Feb 2003 07:50:26 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 05 Feb 2003 07:50:25 -0500 Subject: Re: WG consensus action: when to configure LL addrs From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <3E40FB68.1D4AF1B0@Sun.COM> 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 02/05/2003 06:54, "erik guttman" wrote: > ACCEPTED: > IPv4 LL configuration of interfaces has restricted applicability > to the case where an interface does not obtain configuration in > any other way (such as manual configuration, DHCP, etc.) A host > obtaining such a configuration MUST NOT continue using the IPv4 > LL configuration as well. > > NOTE WELL: This is a major change to the existing draft. I'm so tired of this argument, that I no longer care, but I think that this is going to bite us in the heiny big time. And I see "DHCP DeathTraps" as the fun new prank this year. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Feb 5 11:06:44 2003 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 LAA29641 for ; Wed, 5 Feb 2003 11:06:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 67B7791278; Wed, 5 Feb 2003 11:10:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D3879127E; Wed, 5 Feb 2003 11:10:05 -0500 (EST) 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 D66E591278 for ; Wed, 5 Feb 2003 11:10:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id C0F755DED2; Wed, 5 Feb 2003 11:10:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from home.karahalios.org (dsl093-162-009.tus1.dsl.speakeasy.net [66.93.162.9]) by segue.merit.edu (Postfix) with ESMTP id 2E26A5DDAB for ; Wed, 5 Feb 2003 11:10:03 -0500 (EST) Received: from Outersoft.com (usr2.Karahalios.org [192.168.2.2]) by home.karahalios.org (8.11.1/8.10.1) with ESMTP id h15GA1603038; Wed, 5 Feb 2003 09:10:02 -0700 Date: Wed, 5 Feb 2003 09:10:00 -0700 Subject: Re: WG consensus action: when to configure LL addrs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Erik.Guttman@Sun.COM From: Alex Karahalios In-Reply-To: <3E40FB68.1D4AF1B0@Sun.COM> Message-Id: <46D52C8E-3924-11D7-ADF7-00039377AD70@Outersoft.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Erik, I'm not sure how you arrived at a consensus on this point? I think that there were some very vocal people in favor of this. Maybe this weighs more heavily than those of us who were not as vocal and would rather see that IPv4 and other configurations coexist. My view comes from actually implementing IPv4 and DHCP in a small embedded device. It's much easier to leave both configurations around rather than "pulling the plug" from IPv4 after a DHCP address is obtained. Many times, services on a small embedded device are tied to specific IP addresses and having one of those addresses go away defeats the purpose of the device. This "major change" is not a show stopper - it just means more development time spent adding code to a memory restricted device to handle the case of IPv4 addresses no longer being valid. I still don't see how having both types of addresses on a device does any harm to anything but the device itself. I think this spec. should not be dictating to us how many IP addresses we may use at any time - just like there is no spec telling us that we cannot use multiple static IP addresses. Thanks for listening, Alex Karahalios On Wednesday, February 5, 2003, at 04:54 AM, erik guttman wrote: > The summary of the consensus follows. > > ACCEPTED: > IPv4 LL configuration of interfaces has restricted applicability > to the case where an interface does not obtain configuration in > any other way (such as manual configuration, DHCP, etc.) A host > obtaining such a configuration MUST NOT continue using the IPv4 > LL configuration as well. > > NOTE WELL: This is a major change to the existing draft. > From owner-zeroconf@merit.edu Wed Feb 5 12:15:00 2003 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 MAA02282 for ; Wed, 5 Feb 2003 12:15:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 78A4D9127A; Wed, 5 Feb 2003 12:18:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4244C9127B; Wed, 5 Feb 2003 12:18:28 -0500 (EST) 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 3D47C9127A for ; Wed, 5 Feb 2003 12:18:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 00C485DDA2; Wed, 5 Feb 2003 12:18:03 -0500 (EST) 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 25AC95DD9D for ; Wed, 5 Feb 2003 12:18:02 -0500 (EST) 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 h15HI1I10824 for ; Wed, 5 Feb 2003 09:18:01 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 5 Feb 2003 09:18:00 -0800 Received: from apple.com (lubet1.apple.com [17.202.40.146]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id h15HI0Q08304; Wed, 5 Feb 2003 09:18:00 -0800 (PST) Date: Wed, 5 Feb 2003 09:18:34 -0800 Subject: Re: WG consensus action: when to configure LL addrs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Erik.Guttman@Sun.COM From: Vincent Lubet In-Reply-To: <3E40FB68.1D4AF1B0@Sun.COM> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, February 5, 2003, at 03:54 AM, erik guttman wrote: > This messages is an assessment of working group consensus from > discussion on the WG mailing list in the past weeks as a response > to Thomas Narten's posting below. > > The summary of the consensus follows. > > ACCEPTED: > IPv4 LL configuration of interfaces has restricted applicability > to the case where an interface does not obtain configuration in > any other way (such as manual configuration, DHCP, etc.) A host > obtaining such a configuration MUST NOT continue using the IPv4 > LL configuration as well. > > NOTE WELL: This is a major change to the existing draft. I do not think there was a clear consensus on "MUST NOT". Many opinions expressed on this topic where much more nuanced so I think the text should read "SHOULD NOT". I remember the argument was made that if before acquiring a non LL address the host had established communications using IPv4 LL address, the host should be able to continue to use IPv4 LL. The typical example is a host at home that starts a long print job using LL and the the home router to the Internet. The home router assigns a DHCP address to the host that is still talking to printer with IPv4 LL. I don't think the print job should be aborted at that point. Vincent From owner-zeroconf@merit.edu Wed Feb 5 12:38:19 2003 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 MAA03140 for ; Wed, 5 Feb 2003 12:38:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D0FA89125C; Wed, 5 Feb 2003 12:41:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 988C691260; Wed, 5 Feb 2003 12:41:49 -0500 (EST) 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 805449125C for ; Wed, 5 Feb 2003 12:41:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6EE455DEE4; Wed, 5 Feb 2003 12:41:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by segue.merit.edu (Postfix) with ESMTP id 4D8BB5DD9D for ; Wed, 5 Feb 2003 12:41:48 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18gTYI-0000a6-00; Wed, 05 Feb 2003 09:41:38 -0800 Date: Wed, 5 Feb 2003 12:39:30 -0500 From: Keith Moore To: Vincent Lubet Cc: moore@cs.utk.edu, Erik.Guttman@Sun.COM, zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs Message-Id: <20030205123930.4a79df03.moore@cs.utk.edu> In-Reply-To: References: <3E40FB68.1D4AF1B0@Sun.COM> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > ACCEPTED: > > IPv4 LL configuration of interfaces has restricted applicability > > to the case where an interface does not obtain configuration in > > any other way (such as manual configuration, DHCP, etc.) A host > > obtaining such a configuration MUST NOT continue using the IPv4 > > LL configuration as well. > > > > NOTE WELL: This is a major change to the existing draft. > > I do not think there was a clear consensus on "MUST NOT". Many opinions > expressed on this topic where much more nuanced so I think the text > should read "SHOULD NOT". > > I remember the argument was made that if before acquiring a non LL > address the host had established communications using IPv4 LL address, > the host should be able to continue to use IPv4 LL. > > The typical example is a host at home that starts a long print job > using LL and the the home router to the Internet. The home router > assigns a DHCP address to the host that is still talking to printer > with IPv4 LL. I don't think the print job should be aborted at that > point. Agree "MUST NOT continue using" is too strong and too imprecise. I would argue for "MAY continue using" the LLv4 address on already-open connections, "SHOULD discontinue" accepting new connections sent to the LLv4 destination address, and "SHOULD discontinue" using the LLv4 address as a source address for new connections. However I'd also argue that a reasonable effort SHOULD be made to acquire an address via DHCP before a host ever attempts to configure or use an LLv4 address. The intent is that the host should play well in the network environment in which it finds itself, not that operations that are already in progress should be disrupted. But since the best way to do this may vary from one kind of host to another (especially for special-purpose hosts), it seems appropriate to allow some implementor discretion in determining the best way to do this. I would also support "hosts MAY provide a means for users to manually override use of DHCP" language. Keith From owner-zeroconf@merit.edu Wed Feb 5 12:49:20 2003 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 MAA03616 for ; Wed, 5 Feb 2003 12:49:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BE30F9127B; Wed, 5 Feb 2003 12:52:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DE969127D; Wed, 5 Feb 2003 12:52:50 -0500 (EST) 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 81D7D9127B for ; Wed, 5 Feb 2003 12:52:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6D92D5DF98; Wed, 5 Feb 2003 12:52:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 7E2305DF84 for ; Wed, 5 Feb 2003 12:52:48 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h15HrMQF026560; Wed, 5 Feb 2003 19:53:22 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h15HrKT3026559; Wed, 5 Feb 2003 19:53:20 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Erik.Guttman@Sun.COM Cc: zeroconf@merit.edu In-Reply-To: <3E40FB68.1D4AF1B0@Sun.COM> References: <3E40FB68.1D4AF1B0@Sun.COM> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044467600.1516.30.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Feb 2003 19:53:20 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-05 at 13:54, erik guttman wrote: > ACCEPTED: > IPv4 LL configuration of interfaces has restricted applicability > to the case where an interface does not obtain configuration in > any other way (such as manual configuration, DHCP, etc.) A host > obtaining such a configuration MUST NOT continue using the IPv4 > LL configuration as well. > > NOTE WELL: This is a major change to the existing draft. This sounds like a really bad idea. Any sessions already using the LL address would be forcibly torn down when a global address appears. This is an implementation nightmare. Implementations capable of having multiple addresses per interface should be allowed to keep their LL address. Regards, MikaL From owner-zeroconf@merit.edu Wed Feb 5 13:00:26 2003 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 NAA04310 for ; Wed, 5 Feb 2003 13:00:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 12A9F9127D; Wed, 5 Feb 2003 13:03:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE5F49127E; Wed, 5 Feb 2003 13:03:55 -0500 (EST) 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 A9FB49127D for ; Wed, 5 Feb 2003 13:03:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 86FC15DDE5; Wed, 5 Feb 2003 13:03:54 -0500 (EST) 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 07B345DDCB for ; Wed, 5 Feb 2003 13:03:54 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id h15I3rI04215 for ; Wed, 5 Feb 2003 10:03:53 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 5 Feb 2003 10:03:50 -0800 Received: from apple.com (vpn-scv-x4-130.apple.com [17.219.194.130]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id h15I3nQ13802; Wed, 5 Feb 2003 10:03:49 -0800 (PST) Date: Wed, 5 Feb 2003 10:03:51 -0800 Subject: Re: WG consensus action: when to configure LL addrs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Vincent Lubet , Erik.Guttman@Sun.COM, zeroconf@merit.edu To: Keith Moore From: joe holt In-Reply-To: <20030205123930.4a79df03.moore@cs.utk.edu> Message-Id: <2E63586E-3934-11D7-89A3-000393120D46@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, February 5, 2003, at 09:39 AM, Keith Moore wrote: > >>> ACCEPTED: >>> IPv4 LL configuration of interfaces has restricted applicability >>> to the case where an interface does not obtain configuration in >>> any other way (such as manual configuration, DHCP, etc.) A host >>> obtaining such a configuration MUST NOT continue using the IPv4 >>> LL configuration as well. >>> >>> NOTE WELL: This is a major change to the existing draft. >> >> I do not think there was a clear consensus on "MUST NOT". Many >> opinions >> expressed on this topic where much more nuanced so I think the text >> should read "SHOULD NOT". >> >> I remember the argument was made that if before acquiring a non LL >> address the host had established communications using IPv4 LL address, >> the host should be able to continue to use IPv4 LL. >> >> The typical example is a host at home that starts a long print job >> using LL and the the home router to the Internet. The home router >> assigns a DHCP address to the host that is still talking to printer >> with IPv4 LL. I don't think the print job should be aborted at that >> point. > > Agree "MUST NOT continue using" is too strong and too imprecise. > > I would argue for "MAY continue using" the LLv4 address on already-open > connections, "SHOULD discontinue" accepting new connections sent to > the LLv4 > destination address, and "SHOULD discontinue" using the LLv4 address > as a > source address for new connections. However I'd also argue that a > reasonable > effort SHOULD be made to acquire an address via DHCP before a host ever > attempts to configure or use an LLv4 address. > > The intent is that the host should play well in the network > environment in > which it finds itself, not that operations that are already in > progress should > be disrupted. But since the best way to do this may vary from one kind > of host > to another (especially for special-purpose hosts), it seems > appropriate to > allow some implementor discretion in determining the best way to do > this. > > I would also support "hosts MAY provide a means for users to manually > override > use of DHCP" language. > > Keith I agree with Vincent and Keith that MUST NOT is too strong, and I support Keith's suggested changes in wording. Existing LLv4 connections should not be torn down or disrupted. A client should try to switch over to using a non-LLv4 address when it becomes available. /joe -------- Joe Holt Manager, Utilities Applications Apple Computer, Inc. From owner-zeroconf@merit.edu Wed Feb 5 13:04:04 2003 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 NAA04440 for ; Wed, 5 Feb 2003 13:04:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 026AF9127E; Wed, 5 Feb 2003 13:07:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C22F491280; Wed, 5 Feb 2003 13:07:33 -0500 (EST) 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 A9F939127E for ; Wed, 5 Feb 2003 13:07:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B4CC5DDCB; Wed, 5 Feb 2003 13:07:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id A04565DDA4 for ; Wed, 5 Feb 2003 13:07:31 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h15I7qQF026640; Wed, 5 Feb 2003 20:07:52 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h15I7oRb026639; Wed, 5 Feb 2003 20:07:50 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Keith Moore Cc: Vincent Lubet , Erik.Guttman@Sun.COM, zeroconf@merit.edu In-Reply-To: <20030205123930.4a79df03.moore@cs.utk.edu> References: <3E40FB68.1D4AF1B0@Sun.COM> <20030205123930.4a79df03.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044468469.1516.40.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Feb 2003 20:07:49 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-05 at 19:39, Keith Moore wrote: > I would argue for "MAY continue using" the LLv4 address on already-open > connections, "SHOULD discontinue" accepting new connections sent to the LLv4 > destination address, and "SHOULD discontinue" using the LLv4 address as a > source address for new connections. I don't see any reason not to continue using LL source address with LL destination addresses. The source address selection rules should take care of this automatically. > However I'd also argue that a reasonable > effort SHOULD be made to acquire an address via DHCP before a host ever > attempts to configure or use an LLv4 address. This is too slow for ad-hoc configurations in environments like Buetooth PAN. The rational way for devices like these would be to configure LL addresses in parallel with trying DHCP and to support at least two addresses per interface. Otherwise the address configuration delay becomes prohibitive to the user. Besides, going for rules different from IPv6 just causes headaches for hybrid IPv4/IPv6 stack implementors. MikaL From owner-zeroconf@merit.edu Wed Feb 5 15:06:37 2003 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 PAA08717 for ; Wed, 5 Feb 2003 15:06:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 21B1C91289; Wed, 5 Feb 2003 15:07:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E368391293; Wed, 5 Feb 2003 15:07:40 -0500 (EST) 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 0E18E91289 for ; Wed, 5 Feb 2003 15:07:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id F07D35DE3D; Wed, 5 Feb 2003 15:07:35 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 4D0565DD9D for ; Wed, 5 Feb 2003 15:07:35 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h15K85QF029819; Wed, 5 Feb 2003 22:08:06 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h15K84ME029818; Wed, 5 Feb 2003 22:08:04 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Keith Moore Cc: zeroconf@merit.edu In-Reply-To: <20030205135840.4a7306b9.moore@cs.utk.edu> References: <3E40FB68.1D4AF1B0@Sun.COM> <20030205123930.4a79df03.moore@cs.utk.edu> <1044468469.1516.40.camel@devil> <20030205135840.4a7306b9.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044475683.29573.31.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Feb 2003 22:08:04 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-05 at 20:58, Keith Moore wrote: > > I don't see any reason not to continue using LL source address with LL > > destination addresses. The source address selection rules should take > > care of this automatically. > > relying on source address selection is a pretty dubious idea anyway. Not sure what you mean. Surely it is preferable to select a source address that has a matching scope with the destination address, rather than recommending that the node select a source address with a different scope? The recommendation should be that applications should choose a global destination address over a link local one, whenever possible. This places the onus on the mechanism by which a destination address is acquired (e.g. LL Multicast Name Resolution). As for source address selection rules, longest prefix match seems to work well enough for IPv6. Why not for IPv4? > .. "SHOULD discontinue" accepting new connections sent to the LLv4 destination address This is even worse. If the peer only knows your LL address, this causes loss of connectivity. > > > However I'd also argue that a reasonable > > > effort SHOULD be made to acquire an address via DHCP before a host > > > ever attempts to configure or use an LLv4 address. > > > > This is too slow for ad-hoc configurations in environments like > > Buetooth PAN. The rational way for devices like these would be to > > configure LL addresses in parallel with trying DHCP and to support at > > least two addresses per interface. Otherwise the address configuration > > delay becomes prohibitive to the user. > > well, the whole purpose of SHOULD is to allow some latitude. I appreciate that. I just think that this does not need to be said. If a node is allowed to have multiple addresses, including a link local one, the order in which the addresses are acquired is irrelevant. > > Besides, going for rules different from IPv6 just causes headaches for > > hybrid IPv4/IPv6 stack implementors. > > if you want us to say that v4LL should only be used for the same > purposes that v6LL is intended to be used for (e.g. router/neighbor > discovery), and not for normal applications, that's quite fine with me. Ideally, the same recommendations should apply. Of course, applications are likely to use LL addresses when nothing else is available. Again, Bluetooth PAN is one example. > Keith MikaL From owner-zeroconf@merit.edu Wed Feb 5 15:28:07 2003 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 PAA09569 for ; Wed, 5 Feb 2003 15:28:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1EBD791294; Wed, 5 Feb 2003 15:31:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE64391297; Wed, 5 Feb 2003 15:31:30 -0500 (EST) 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 4DDD691294 for ; Wed, 5 Feb 2003 15:31:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 788B85DFB5; Wed, 5 Feb 2003 15:31:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 573A95DF7C for ; Wed, 5 Feb 2003 15:31:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id EE98F14087; Wed, 5 Feb 2003 15:31:08 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 12178-01; Wed, 5 Feb 2003 15:31:04 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 565A014088; Wed, 5 Feb 2003 15:31:04 -0500 (EST) Date: Wed, 5 Feb 2003 15:31:04 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs Message-Id: <20030205153104.11ed9254.moore@cs.utk.edu> In-Reply-To: <1044475683.29573.31.camel@devil> References: <3E40FB68.1D4AF1B0@Sun.COM> <20030205123930.4a79df03.moore@cs.utk.edu> <1044468469.1516.40.camel@devil> <20030205135840.4a7306b9.moore@cs.utk.edu> <1044475683.29573.31.camel@devil> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 6eb4ea0db4e8c16db3d2cfcd9c13a2bddc491f1e Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > relying on source address selection is a pretty dubious idea anyway. > > Not sure what you mean. Surely it is preferable to select a source > address that has a matching scope with the destination address, rather > than recommending that the node select a source address with a > different scope? Nope. It is far preferable to always use the widest scope address that is available and to avoid using limited-scoped addresses as much as possible, for both source and destination. > The recommendation should be that applications should choose a global > destination address over a link local one, whenever possible. This > places the onus on the mechanism by which a destination address is > acquired (e.g. LL Multicast Name Resolution). The idea that you can control use of scoped addresses by the means by which hosts acquire addersses is a fallacy. There are too many ways in which hosts acquire addresses, and it's not reasonable to expect hosts to keep track of network topology. > As for source address selection rules, longest prefix match seems to > work well enough for IPv6. Why not for IPv4? It's broken for IPv6 also. At least, the idea that it's useful to use a limited scope address when a larger scoped one is available is broken, and address selection can't solve the problems that result. > > .. "SHOULD discontinue" accepting new connections sent to the LLv4 > destination address > > This is even worse. If the peer only knows your LL address, this > causes loss of connectivity. Notice I didn't say "SHOULD immediately discontinue". One of the reasons I phrased it this way was to provide some chance for hosts that already had LL addresses to discover and begin using the new address. But the bottom line is that scoped and limited-duration addresses are both broken. They create a lot of problems that can't be fixed. They are useful for limited cases such as ad hoc newtorks, but their limitations need to be respected, and they need to be used sparingly. Which implies, among other things, that it's far better for a device to start out using a stable, routable address whenever possible, than to start out using an LL address and try to fail over to a routable one at a later time. As for trying to use both, this doesn't play well with existing networks and applications. And why use an LL address when a routable one will work better? > > > > However I'd also argue that a reasonable > > > > effort SHOULD be made to acquire an address via DHCP before a > > > > host ever attempts to configure or use an LLv4 address. > > > > > > This is too slow for ad-hoc configurations in environments like > > > Buetooth PAN. The rational way for devices like these would be to > > > configure LL addresses in parallel with trying DHCP and to support > > > at least two addresses per interface. Otherwise the address > > > configuration delay becomes prohibitive to the user. > > > > well, the whole purpose of SHOULD is to allow some latitude. > > I appreciate that. I just think that this does not need to be said. If > a node is allowed to have multiple addresses, including a link local > one, the order in which the addresses are acquired is irrelevant. This gets back to the question of whether it is reasonable for a device to use a different IP address other than the one assigned to it by DHCP. I think that by default the device needs to respect what the network assigns to it. If you want to define a separate way that the network can say "it's okay to use LL also" or for that matter "it's okay to use these N IPv4 addresses" then fine, but that seems out of scope for this WG. At least that question should be deferred for the time being so that we can get this RFC out the door. Keith From owner-zeroconf@merit.edu Wed Feb 5 16:47:49 2003 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 QAA12173 for ; Wed, 5 Feb 2003 16:47:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7BEED9125E; Wed, 5 Feb 2003 16:51:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4BBCE91288; Wed, 5 Feb 2003 16:51:18 -0500 (EST) 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 CDF539125E for ; Wed, 5 Feb 2003 16:51:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id AE0C15DF98; Wed, 5 Feb 2003 16:51:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id D83525DF8D for ; Wed, 5 Feb 2003 16:51:15 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h15LplQF030279; Wed, 5 Feb 2003 23:51:47 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h15LpjH6030278; Wed, 5 Feb 2003 23:51:45 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Keith Moore Cc: zeroconf@merit.edu In-Reply-To: <20030205153104.11ed9254.moore@cs.utk.edu> References: <3E40FB68.1D4AF1B0@Sun.COM> <20030205123930.4a79df03.moore@cs.utk.edu> <1044468469.1516.40.camel@devil> <20030205135840.4a7306b9.moore@cs.utk.edu> <1044475683.29573.31.camel@devil> <20030205153104.11ed9254.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044481904.29574.126.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 05 Feb 2003 23:51:44 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-05 at 22:31, Keith Moore wrote: > > > relying on source address selection is a pretty dubious idea anyway. > > > > Not sure what you mean. Surely it is preferable to select a source > > address that has a matching scope with the destination address, rather > > than recommending that the node select a source address with a > > different scope? > > Nope. It is far preferable to always use the widest scope address that > is available and to avoid using limited-scoped addresses as much as > possible, for both source and destination. You're just proposing a different source address selection rule. I would be happy enough with this if you can get the same rule applied for IPv6 as well. I don't think the benefits outweigh the burden of having different rules for IPv4 and IPv6. > > The recommendation should be that applications should choose a global > > destination address over a link local one, whenever possible. This > > places the onus on the mechanism by which a destination address is > > acquired (e.g. LL Multicast Name Resolution). > > The idea that you can control use of scoped addresses by the means by > which hosts acquire addersses is a fallacy. There are too many ways in > which hosts acquire addresses, and it's not reasonable to expect hosts > to keep track of network topology. I was suggesting that applications should choose a global scope destination address whenever one is available. That is a simple enough rule, and can be implemented as part of a name resolver. In fact, above you just proposed this very same rule yourself. Applying this rule to destinationa address selection is enough to cause new connections to not use LL addresses. > > > .. "SHOULD discontinue" accepting new connections sent to the LLv4 > > destination address > > > > This is even worse. If the peer only knows your LL address, this > > causes loss of connectivity. > > Notice I didn't say "SHOULD immediately discontinue". One of the > reasons I phrased it this way was to provide some chance for hosts that > already had LL addresses to discover and begin using the new address. If the node continues to accept connections to the LL address, it might as well do so indefinitely, since there is no way to come up with a meaningful deprecation period. > But the bottom line is that scoped and limited-duration addresses are > both broken. They create a lot of problems that can't be fixed. They > are useful for limited cases such as ad hoc newtorks, but their > limitations need to be respected, and they need to be used sparingly. I agree on principle, scoped addresses are a pain. As an implementor, however, I disagree with needlessly specifying divergent behaviour between IPv4 and IPv6. That is more pain. > Which implies, among other things, that it's far better for a device to > start out using a stable, routable address whenever possible, than to > start out using an LL address and try to fail over to a routable one at > a later time. This recommendation is only relevant for implementations that are limited to a single address per interface. Let's not make it a straight-jacket for implementations that aren't. > As for trying to use both, this doesn't play well with > existing networks and applications. And why use an LL address when a > routable one will work better? Experience with our implementation does not support this view. > If you want to define a separate way that the network can say "it's okay to use LL also" or for that matter "it's okay to use these N IPv4 > addresses" then fine, but that seems out of scope for this WG. I agree, mechanisms that allow the network to dictate policy are out of scope. So is making assumptions about what that policy might be. MikaL From owner-zeroconf@merit.edu Wed Feb 5 18:13:03 2003 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 SAA14897 for ; Wed, 5 Feb 2003 18:13:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 882B691261; Wed, 5 Feb 2003 18:16:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 515F291288; Wed, 5 Feb 2003 18:16:29 -0500 (EST) 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 9AB8A91261 for ; Wed, 5 Feb 2003 18:16:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 45E625DFD9; Wed, 5 Feb 2003 18:16:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 2BF545DFD8 for ; Wed, 5 Feb 2003 18:16:21 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h15NGrQF030630; Thu, 6 Feb 2003 01:16:53 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h15NGqQM030629; Thu, 6 Feb 2003 01:16:52 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Keith Moore Cc: zeroconf@merit.edu In-Reply-To: <20030205174609.604d1c84.moore@cs.utk.edu> References: <3E40FB68.1D4AF1B0@Sun.COM> <20030205123930.4a79df03.moore@cs.utk.edu> <1044468469.1516.40.camel@devil> <20030205135840.4a7306b9.moore@cs.utk.edu> <1044475683.29573.31.camel@devil> <20030205153104.11ed9254.moore@cs.utk.edu> <1044481904.29574.126.camel@devil> <20030205174609.604d1c84.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044487011.29574.143.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 06 Feb 2003 01:16:52 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Keith, This is getting out of hand and I'm not interested in a shouting match. I think I've made my point to the WG and I'll just say this. I'd agree to language such as: "IPv4 LL configuration of interfaces has limited applicability beyond the case where an interface does not obtain configuration in any other way (such as manual configuration, DHCP, etc.) A host obtaining such a configuration MAY continue using the IPv4 LL configuration as well. However, such a host SHOULD make every effort to deprecate the LL configuration when initiating new connections." Leave the other things as implementation details, as they should be. MikaL On Thu, 2003-02-06 at 00:46, Keith Moore wrote: > > > > Surely it is preferable to select a source > > > > address that has a matching scope with the destination address, > > > > rather than recommending that the node select a source address > > > > with a different scope? > > > > > > Nope. It is far preferable to always use the widest scope address > > > that is available and to avoid using limited-scoped addresses as > > > much as possible, for both source and destination. > > > > You're just proposing a different source address selection rule. > > That's only part of it. The more important part of what I'm proposing > is that we stop pretending that scoped addresses are satisfactory for > most purposes. Fortunately, IPv6 folks seem to be figuring this out > already. > > > I don't think the benefits outweigh the burden of having different > > rules for IPv4 and IPv6. > > Well, I don't think the benefits of v4LL outweigh having to support LL > addresses in both IPv4 and IPv6. v6LL should be sufficient, especially > once you acknowledge that v4LL isn't suitable for general purposes > either. But I've been assuming that the WG is going to get v4LL anyway, > so have been trying to minimize the harm done. > > > > > The recommendation should be that applications should choose a > > > > global destination address over a link local one, whenever > > > > possible. This places the onus on the mechanism by which a > > > > destination address is acquired (e.g. LL Multicast Name > > > > Resolution). > > > > > > The idea that you can control use of scoped addresses by the means > > > by which hosts acquire addersses is a fallacy. There are too many > > > ways in which hosts acquire addresses, and it's not reasonable to > > > expect hosts to keep track of network topology. > > > > I was suggesting that applications should choose a global scope > > destination address whenever one is available. That is a simple enough > > rule, and can be implemented as part of a name resolver. > > NO IT CANNOT. It is completely unreasonable to assume that applications > only get their addresses via a single API or protocol. > > > In fact, above you just proposed this very same rule yourself. > > Nope. Address selection and name resolver API are very different. > > > > Notice I didn't say "SHOULD immediately discontinue". One of the > > > reasons I phrased it this way was to provide some chance for hosts > > > that already had LL addresses to discover and begin using the new > > > address. > > > > If the node continues to accept connections to the LL address, it > > might as well do so indefinitely, since there is no way to come up > > with a meaningful deprecation period. > > No, it doesn't follow. Given a choice between "terminate immediately" > and "accept connections indefinitely" the former is preferable. But a > more reasonable choice would be somewhere in the middle. Exactly where > in the middle probably depends on the characteristics of the > applications supported by the host. > > Perhaps language like "SHOULD cease to accept new connections at the > v4LL address as soon as practicable" would be better. > > > > But the bottom line is that scoped and limited-duration addresses > > > are both broken. They create a lot of problems that can't be fixed. > > > They are useful for limited cases such as ad hoc newtorks, but their > > > limitations need to be respected, and they need to be used > > > sparingly. > > > > I agree on principle, scoped addresses are a pain. As an implementor, > > however, I disagree with needlessly specifying divergent behaviour > > between IPv4 and IPv6. That is more pain. > > Then you presumably agree that we shouldn't be bothering with v4LL at > all? That would certainly minimize the special casing. > > There will always be some differences between IPv4 and IPv6, and for > good reason. v6 deliberately changed some things from v4 behavior. On > the other hand, there's no need to worry about the impact of v6LL on > v4 apps, but there is a need to worry about the impact of v4LL on v4 > apps. > > > > Which implies, among other things, that it's far better for a device > > > to start out using a stable, routable address whenever possible, > > > than to start out using an LL address and try to fail over to a > > > routable one at a later time. > > > > This recommendation is only relevant for implementations that are > > limited to a single address per interface. > > No, it makes sense to apply this on a per-interface basis. > > > > As for trying to use both, this doesn't play well with > > > existing networks and applications. And why use an LL address when > > > a routable one will work better? > > > > Experience with our implementation does not support this view. > > And experience with our applications does not support your view. > > > > If you want to define a separate way that the network can say "it's > > > okay to use LL also" or for that matter "it's okay to use these N > > > IPv4 addresses" then fine, but that seems out of scope for this WG. > > > > I agree, mechanisms that allow the network to dictate policy are out > > of scope. So is making assumptions about what that policy might be. > > Well then you'd agree that it's not appropriate for this WG to assume > that it's okay to send LL on a network that assigns a routable v4 > address - because that's making an assumption about that network's > policy. > > Look, the "don't use LL if you have a DHCP address" is a compromise, and > we shouldn't pretend that it's anything other than that. Ideally the > network would be able to clearly specify what addresses a host could > use as a matter of policy. Ideally hosts could reliably determine > whether such policy specifications were actually being made on authority > of the network operator and ignore those that aren't. Ideally hosts > could reliably determine whether they were on a network for which there > was an explicit policy or whether they were on a network (say an ad hoc > network) for which there was no such policy. Ideally all hosts would be > given stable, globally routable addresses. > > For various reasons, we're not currently able to provide these ideal > conditions. What we're trying to do is to pick some sort of balance > that minimizes the harm until we can improve conditions. Using and > trusting DHCP (by default, in the absence of manual configuration) as an > indication that a host should not use LL is better than either requiring > manual configuration of LL in all cases or having LL automatically > configured in all cases. For the cases where it doesn't work, manual > configuration is a backup. Eventually, perhaps, we can provide > mechanisms which are more flexible and/or more secure than this, which > maintain the required balance of interests with fewer failures and less > user effort. > > But I really have to wonder whether it's worth it to invest any more > effort in v4LL anyway, given that the limitations of v4 are really > starting to show. > > Keith From owner-zeroconf@merit.edu Wed Feb 5 18:53:11 2003 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 SAA15775 for ; Wed, 5 Feb 2003 18:53:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 356519128B; Wed, 5 Feb 2003 18:56:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00E1C9128C; Wed, 5 Feb 2003 18:56:40 -0500 (EST) 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 E13E19128B for ; Wed, 5 Feb 2003 18:56:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id C34775DDF0; Wed, 5 Feb 2003 18:56:39 -0500 (EST) 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 A5CA05DDEA for ; Wed, 5 Feb 2003 18:56:39 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h15NudWa015662 for ; Wed, 5 Feb 2003 16:56:39 -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 QAA03662 for ; Wed, 5 Feb 2003 16:56:37 -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 h15Nuao3005964; Thu, 6 Feb 2003 10:56:36 +1100 (EST) Message-ID: <3E41A4B3.8050602@motorola.com> Date: Thu, 06 Feb 2003 10:56:35 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik.Guttman@Sun.COM Cc: zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs References: <3E40FB68.1D4AF1B0@Sun.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 Firstly, thanks Erik for grasping the nettle once again in an attempt to get some closure on this. erik guttman wrote: > ACCEPTED: > IPv4 LL configuration of interfaces has restricted applicability > to the case where an interface does not obtain configuration in > any other way (such as manual configuration, DHCP, etc.) A host > obtaining such a configuration MUST NOT continue using the IPv4 > LL configuration as well. > > NOTE WELL: This is a major change to the existing draft. > What is missing in this (as other people have also pointed out) is the idea that existing v4 LL connections can continue, but that new LL connections should make use of the non-LL address. > >> - when should an IPv4LL address be used by a host as a source > >> address? > >> > >> suggest: when the only addresses available to the host are > >> IPv4LL addresses, OR > >> when the application has explicitly specified the source > >> address to use, OR > >> when the application has explicitly specified the interface to > >> use and the IPv4LL address is the only address associated with > >> that interface. > > Aidan responded: > > I don't agree with the "only address associated with the interface" > > part. If you *have* an IPv4-LL address it should be used when > > connecting to IPv4-LL destinations. > > > > I'm happy with Section 2.6, "Source Address Selection" as it is. > > Given that an interface will now only have an IPv4 LL address > configured if it does not have any other address configuration, > I do not see that there is any difference between Keith and > Aidan's positions. > Hmm. I would like the text not to be more restrictive than it needs to be -- just dropping the "and the IPv4LL address is the only address associated with that interface" text would work for me. If an administrator chooses to allow the v4-LL address to co-exist on an interface, why should we prohibit it? - aidan From owner-zeroconf@merit.edu Wed Feb 5 19:03:42 2003 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 TAA16134 for ; Wed, 5 Feb 2003 19:03:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5C4BE9128C; Wed, 5 Feb 2003 19:07:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29E119128D; Wed, 5 Feb 2003 19:07:12 -0500 (EST) 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 07E3B9128C for ; Wed, 5 Feb 2003 19:07:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id DDE6D5DDEA; Wed, 5 Feb 2003 19:07:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by segue.merit.edu (Postfix) with ESMTP id BA23B5DDA4 for ; Wed, 5 Feb 2003 19:07:10 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18gZZM-0005IF-00; Wed, 05 Feb 2003 16:07:08 -0800 Date: Wed, 5 Feb 2003 19:05:03 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs Message-Id: <20030205190503.23961932.moore@cs.utk.edu> In-Reply-To: <1044487011.29574.143.camel@devil> References: <3E40FB68.1D4AF1B0@Sun.COM> <20030205123930.4a79df03.moore@cs.utk.edu> <1044468469.1516.40.camel@devil> <20030205135840.4a7306b9.moore@cs.utk.edu> <1044475683.29573.31.camel@devil> <20030205153104.11ed9254.moore@cs.utk.edu> <1044481904.29574.126.camel@devil> <20030205174609.604d1c84.moore@cs.utk.edu> <1044487011.29574.143.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > I'd agree to language such as: > > "IPv4 LL configuration of interfaces has limited applicability beyond > the case where an interface does not obtain configuration in any other > way (such as manual configuration, DHCP, etc.) A host obtaining such a > configuration MAY continue using the IPv4 LL configuration as well. > However, such a host SHOULD make every effort to deprecate the LL > configuration when initiating new connections." That's simply not acceptable, as the last several months' worth of discussion should have made clear. From owner-zeroconf@merit.edu Wed Feb 5 19:17:34 2003 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 TAA16295 for ; Wed, 5 Feb 2003 19:17:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6560591263; Wed, 5 Feb 2003 19:21:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 351E79128D; Wed, 5 Feb 2003 19:21:04 -0500 (EST) 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 16C4391263 for ; Wed, 5 Feb 2003 19:21:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id E1A075DDF0; Wed, 5 Feb 2003 19:21:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by segue.merit.edu (Postfix) with ESMTP id BEBB95DDEA for ; Wed, 5 Feb 2003 19:21:02 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18gZmj-0004kK-00; Wed, 05 Feb 2003 16:20:58 -0800 Date: Wed, 5 Feb 2003 19:18:56 -0500 From: Keith Moore To: Aidan Williams Cc: moore@cs.utk.edu, Erik.Guttman@Sun.COM, zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs Message-Id: <20030205191856.58daaf1d.moore@cs.utk.edu> In-Reply-To: <3E41A4B3.8050602@motorola.com> References: <3E40FB68.1D4AF1B0@Sun.COM> <3E41A4B3.8050602@motorola.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > >> - when should an IPv4LL address be used by a host as a source > > >> address? > > >> > > >> suggest: when the only addresses available to the host are > > >> IPv4LL addresses, OR > > >> when the application has explicitly specified the source > > >> address to use, OR > > >> when the application has explicitly specified the interface to > > >> use and the IPv4LL address is the only address associated with > > >> that interface. > > > > Aidan responded: > > > I don't agree with the "only address associated with the interface" > > > part. If you *have* an IPv4-LL address it should be used when > > > connecting to IPv4-LL destinations. > > > > > > I'm happy with Section 2.6, "Source Address Selection" as it is. > > > > Given that an interface will now only have an IPv4 LL address > > configured if it does not have any other address configuration, > > I do not see that there is any difference between Keith and > > Aidan's positions. > > Hmm. I would like the text not to be more restrictive than it > needs to be -- just dropping the "and the IPv4LL address is the > only address associated with that interface" text would work for me. > If an administrator chooses to allow the v4-LL address to > co-exist on an interface, why should we prohibit it? The point of the "only address associated with the interface" was that if the use of LL is implicit in some other explicit choice (such as that of the interface) made by the application, then it seems appropriate to use LL. That and I was trying to avoid having the text forbid use of LL in a case where there was no other way to satisfy the application's request. But you don't ever want to use an LL source address when a routable source address will do. Keith From owner-zeroconf@merit.edu Wed Feb 5 19:25:44 2003 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 TAA16467 for ; Wed, 5 Feb 2003 19:25:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9479C9128D; Wed, 5 Feb 2003 19:29:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61FF59128E; Wed, 5 Feb 2003 19:29:14 -0500 (EST) 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 665A89128D for ; Wed, 5 Feb 2003 19:29:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4DCD75DEC1; Wed, 5 Feb 2003 19:29:13 -0500 (EST) 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 F16BF5DE64 for ; Wed, 5 Feb 2003 19:29:12 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h160TB8o014518; Wed, 5 Feb 2003 17:29:11 -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 RAA10233; Wed, 5 Feb 2003 17:29:08 -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 h160T6o3007843; Thu, 6 Feb 2003 11:29:06 +1100 (EST) Message-ID: <3E41AC50.8090309@motorola.com> Date: Thu, 06 Feb 2003 11:29:04 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Cc: Erik.Guttman@Sun.COM, zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs References: <3E40FB68.1D4AF1B0@Sun.COM> <3E41A4B3.8050602@motorola.com> <20030205191856.58daaf1d.moore@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: > The point of the "only address associated with the interface" was that if the > use of LL is implicit in some other explicit choice (such as that of the > interface) made by the application, then it seems appropriate to use LL. > That and I was trying to avoid having the text forbid use of LL in a case > where there was no other way to satisfy the application's request. > So, can you live with dropping the "and the IPv4LL address is the only address associated with that interface" ? - aidan From owner-zeroconf@merit.edu Wed Feb 5 19:26:28 2003 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 TAA16506 for ; Wed, 5 Feb 2003 19:26:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 14F279128E; Wed, 5 Feb 2003 19:29:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D25369129D; Wed, 5 Feb 2003 19:29:57 -0500 (EST) 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 CEC459128E for ; Wed, 5 Feb 2003 19:29:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id BE9405DE64; Wed, 5 Feb 2003 19:29:56 -0500 (EST) 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 541E15DDEA for ; Wed, 5 Feb 2003 19:29:56 -0500 (EST) 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 TAA02147 for ; Wed, 5 Feb 2003 19:29:55 -0500 (EST) 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 TAA08336 for ; Wed, 5 Feb 2003 19:29:55 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id TAA07672 for ; Wed, 5 Feb 2003 19:29:51 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 05 Feb 2003 19:29:49 -0500 Subject: Re: WG consensus action: when to configure LL addrs From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030205190503.23961932.moore@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 02/05/2003 19:05, "Keith Moore" wrote: >> "IPv4 LL configuration of interfaces has limited applicability beyond >> the case where an interface does not obtain configuration in any other >> way (such as manual configuration, DHCP, etc.) A host obtaining such a >> configuration MAY continue using the IPv4 LL configuration as well. >> However, such a host SHOULD make every effort to deprecate the LL >> configuration when initiating new connections." > > That's simply not acceptable, as the last several months' worth of discussion > should have made clear. v4LL, having come far too close to a consensus shall now return back into argument mode john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Feb 5 19:40:06 2003 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 TAA16721 for ; Wed, 5 Feb 2003 19:40:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 174FD9128F; Wed, 5 Feb 2003 19:43:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD0EF9129D; Wed, 5 Feb 2003 19:43:35 -0500 (EST) 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 C128B9128F for ; Wed, 5 Feb 2003 19:43:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id A50715DEE4; Wed, 5 Feb 2003 19:43:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by segue.merit.edu (Postfix) with ESMTP id 8412F5DEC1 for ; Wed, 5 Feb 2003 19:43:34 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ga8X-0004Jb-00; Wed, 05 Feb 2003 16:43:29 -0800 Date: Wed, 5 Feb 2003 19:41:28 -0500 From: Keith Moore To: Aidan Williams Cc: moore@cs.utk.edu, Erik.Guttman@Sun.COM, zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs Message-Id: <20030205194128.0dbfb7bb.moore@cs.utk.edu> In-Reply-To: <3E41AC50.8090309@motorola.com> References: <3E40FB68.1D4AF1B0@Sun.COM> <3E41A4B3.8050602@motorola.com> <20030205191856.58daaf1d.moore@cs.utk.edu> <3E41AC50.8090309@motorola.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Thu, 06 Feb 2003 11:29:04 +1100 Aidan Williams wrote: > Keith Moore wrote: > > The point of the "only address associated with the interface" was that if > > the use of LL is implicit in some other explicit choice (such as that of > > the interface) made by the application, then it seems appropriate to use > > LL. That and I was trying to avoid having the text forbid use of LL in a > > case where there was no other way to satisfy the application's request. > > So, can you live with dropping the "and the IPv4LL address is the > only address associated with that interface" ? No. I'm sure there is another way to specify the same thing, probably with better precision or greater clarity than what I suggested. But simply dropping that text fragment would allow use of LL source addresses in situations where it should not be used, and I don't think it's a good idea for this document to define behavior in terms of a specific API. perhaps: "SHOULD NOT use an LL source address unless the application has unambiguously requested this." Keith From owner-zeroconf@merit.edu Wed Feb 5 19:45:04 2003 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 TAA16835 for ; Wed, 5 Feb 2003 19:45:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F16CC9129E; Wed, 5 Feb 2003 19:48:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA9D59129F; Wed, 5 Feb 2003 19:48:33 -0500 (EST) 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 DDEA89129E for ; Wed, 5 Feb 2003 19:48:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id C46025DE13; Wed, 5 Feb 2003 19:48:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by segue.merit.edu (Postfix) with ESMTP id A3E885DDB8 for ; Wed, 5 Feb 2003 19:48:16 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18gaD8-0001Lh-00; Wed, 05 Feb 2003 16:48:14 -0800 Date: Wed, 5 Feb 2003 19:46:13 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs Message-Id: <20030205194613.7f22bef1.moore@cs.utk.edu> In-Reply-To: References: <20030205190503.23961932.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Wed, 05 Feb 2003 19:29:49 -0500 "John C. Welch" wrote: > On 02/05/2003 19:05, "Keith Moore" wrote: > > >> "IPv4 LL configuration of interfaces has limited applicability beyond > >> the case where an interface does not obtain configuration in any other > >> way (such as manual configuration, DHCP, etc.) A host obtaining such a > >> configuration MAY continue using the IPv4 LL configuration as well. > >> However, such a host SHOULD make every effort to deprecate the LL > >> configuration when initiating new connections." > > > > That's simply not acceptable, as the last several months' worth of > > discussion should have made clear. > > v4LL, having come far too close to a consensus shall now return back into > argument mode If consensus can only be achieved by making the document deliberately imprecise in order to gloss over the failure to resove a known problem, then we're better off without it. However, my reading is that the group does have rough consensus on this. It's vague language like "MAY continue using the IPv4 LL configuration" that I'm objecting to. I should have made that clearer in my previous message. Keith From owner-zeroconf@merit.edu Wed Feb 5 20:00:19 2003 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 UAA17151 for ; Wed, 5 Feb 2003 20:00:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A7D589129F; Wed, 5 Feb 2003 20:03:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 756F5912A0; Wed, 5 Feb 2003 20:03:42 -0500 (EST) 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 8D5CB9129F for ; Wed, 5 Feb 2003 20:03:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 32E275DDEA; Wed, 5 Feb 2003 20:03:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by segue.merit.edu (Postfix) with ESMTP id A6B825DDB8 for ; Wed, 5 Feb 2003 20:03:36 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h1613Xr3012496; Wed, 5 Feb 2003 18:03:33 -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 SAA28227; Wed, 5 Feb 2003 18:02:22 -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 h1613To3010186; Thu, 6 Feb 2003 12:03:31 +1100 (EST) Message-ID: <3E41B461.2030305@motorola.com> Date: Thu, 06 Feb 2003 12:03:29 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Cc: Erik.Guttman@Sun.COM, zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs References: <3E40FB68.1D4AF1B0@Sun.COM> <3E41A4B3.8050602@motorola.com> <20030205191856.58daaf1d.moore@cs.utk.edu> <3E41AC50.8090309@motorola.com> <20030205194128.0dbfb7bb.moore@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: > perhaps: "SHOULD NOT use an LL source address unless the application has > unambiguously requested this." > Remarkable. I can live with that. - aidan From owner-zeroconf@merit.edu Wed Feb 5 20:10:09 2003 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 UAA17379 for ; Wed, 5 Feb 2003 20:10:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BEC19912A1; Wed, 5 Feb 2003 20:13:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C4EC912A4; Wed, 5 Feb 2003 20:13:39 -0500 (EST) 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 7C4D7912A1 for ; Wed, 5 Feb 2003 20:13:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 646205DF84; Wed, 5 Feb 2003 20:13:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by segue.merit.edu (Postfix) with ESMTP id 435265DDEA for ; Wed, 5 Feb 2003 20:13:38 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18gabe-0006X8-00; Wed, 05 Feb 2003 17:13:34 -0800 Date: Wed, 5 Feb 2003 20:11:34 -0500 From: Keith Moore To: Aidan Williams Cc: moore@cs.utk.edu, Erik.Guttman@Sun.COM, zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs Message-Id: <20030205201134.5153eeda.moore@cs.utk.edu> In-Reply-To: <3E41B461.2030305@motorola.com> References: <3E40FB68.1D4AF1B0@Sun.COM> <3E41A4B3.8050602@motorola.com> <20030205191856.58daaf1d.moore@cs.utk.edu> <3E41AC50.8090309@motorola.com> <20030205194128.0dbfb7bb.moore@cs.utk.edu> <3E41B461.2030305@motorola.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > perhaps: "SHOULD NOT use an LL source address unless the application has > > unambiguously requested this." > > > > Remarkable. I can live with that. woohoo! is it (virtual) beer time yet? Keith From owner-zeroconf@merit.edu Thu Feb 6 05:20:22 2003 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 FAA11333 for ; Thu, 6 Feb 2003 05:20:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 169B491257; Thu, 6 Feb 2003 05:23:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D67649125B; Thu, 6 Feb 2003 05:23:51 -0500 (EST) 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 DC9EB91257 for ; Thu, 6 Feb 2003 05:23:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id C16FC5DDD6; Thu, 6 Feb 2003 05:23:50 -0500 (EST) 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 494115DD8F for ; Thu, 6 Feb 2003 05:23:50 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id h16ANnI22988 for ; Thu, 6 Feb 2003 02:23:49 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 6 Feb 2003 02:23:49 -0800 Received: from [17.219.194.13] (vpn-scv-x3-13.apple.com [17.219.194.13]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h16ANnQ22740 for ; Thu, 6 Feb 2003 02:23:49 -0800 (PST) Message-Id: <200302061023.h16ANnQ22740@scv2.apple.com> Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt Date: Thu, 6 Feb 2003 02:23:53 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk I have just finished reading the 569 messages posted during the month of January. This is hard work at times. Even averaging just two minutes per message, that was still 19 straight hours of reading. I have prepared some responses to the IESG comments. However, before I send that, I have also prepared some comments concerning what I feel are certain common misunderstandings. I will send these as a series of six separate emails, one topic per email. The purpose of these comments is not to stir up further debate, and I strongly request that people resist any urge to stir up further debate. If you disagree with me, please do so privately, and I will answer your emails. The purpose of these comments is to try to give some context for the subsequent discussions. I have been working on Zero Configuration Networking since 1997, since before Zeroconf even had that name. I have given the subject a great deal of thought. In that time I have been with the Zeroconf Working Group since the first NITS BOF. I implemented, debugged, shipped and supported the IPv4LL code for Mac OS 9 in the late 1990s. I wrote most of the text in draft-ietf-zeroconf-ipv4-linklocal-xx. Some people seem to act as if they believe I have given the subject no thought at all. This is of course nonsense. You may disagree with me, but to claim I have given the subject no thought at all is clearly nonsense. The intent of these comments is that when I subsequently write something that may appear nonsense to you, this background may help explain why what I wrote is not nonsense to me. That may not make you agree with it, but at least it may help provide a common ground for discussion so we can understand each other better. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Feb 6 05:21:14 2003 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 FAA11363 for ; Thu, 6 Feb 2003 05:21:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1A6329125B; Thu, 6 Feb 2003 05:24:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7F179125C; Thu, 6 Feb 2003 05:24:43 -0500 (EST) 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 D84719125B for ; Thu, 6 Feb 2003 05:24:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id C5E975DDD6; Thu, 6 Feb 2003 05:24:42 -0500 (EST) 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 4E7775DD8F for ; Thu, 6 Feb 2003 05:24:42 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id h16AOfI23066 for ; Thu, 6 Feb 2003 02:24:41 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 6 Feb 2003 02:24:41 -0800 Received: from [17.219.194.13] (vpn-scv-x3-13.apple.com [17.219.194.13]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h16AOfQ22841 for ; Thu, 6 Feb 2003 02:24:41 -0800 (PST) Message-Id: <200302061024.h16AOfQ22841@scv2.apple.com> Subject: 1. Engineering philosophy Date: Thu, 6 Feb 2003 02:24:45 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk I have observed two attitudes towards engineering: Attitude 1. The engineers creating the products should be willing to do a lot of hard work to make the lives of the end users easier, more pleasant, and more productive. Attitude 2. The customers buying the products should be willing to do work to make the lives of the engineers easier. I make no apology for following principle number 1, and that attitude is common at Apple. Some people follow principle number 2. They believe that when there is an unavoidable decision to be made between (a) extra work for the application programmers creating the products, or (b) extra work for the people using the products, the correct answer is that the end-users should suffer to make life easier for the application programmers. Such people are entitled to hold their views, but they won't persuade Apple to produce its products according to that principle. My sincere goal is to have as little impact as possible on application software, but when we do arrive at an unavoidable engineering trade-off between making life easier for the end-users or making life easier for application programmers, we have to decide what our priorities are. I will state my position very clearly: As an engineer and programmer, I am willing to work hard to make life easier for end-users, and I think I am justified to take pride in the software and hardware I have produced by following that philosophy. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Feb 6 05:23:43 2003 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 FAA11408 for ; Thu, 6 Feb 2003 05:23:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9F48A9125C; Thu, 6 Feb 2003 05:27:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60D9A9125E; Thu, 6 Feb 2003 05:27:13 -0500 (EST) 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 50ADA9125C for ; Thu, 6 Feb 2003 05:27:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D9155DDD6; Thu, 6 Feb 2003 05:27:12 -0500 (EST) 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 9A3AF5DD8F for ; Thu, 6 Feb 2003 05:27:11 -0500 (EST) 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 h16ARAI23294 for ; Thu, 6 Feb 2003 02:27:10 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Feb 2003 02:27:09 -0800 Received: from [17.219.194.13] (vpn-scv-x3-13.apple.com [17.219.194.13]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h16ARAf23194 for ; Thu, 6 Feb 2003 02:27:10 -0800 (PST) Message-Id: <200302061027.h16ARAf23194@scv3.apple.com> Subject: 2. Disabling LL -- or -- How does a host know if it is configured correctly? Date: Thu, 6 Feb 2003 02:27:13 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Christian Huitema wrote: >What would be wrong would be to force systems that already have >a DHCP address to also acquire a more ambiguous, scoped address. Keith Moore wrote: >there is no situation where you need both v4LL and a >routable address on the same interface. One of the goals I believe is important is creating reliable networking that doesn't fail. Just having a configured routable address doesn't mean that it is necessarily correct or currently usable. Windows machines have a tendency to cling to their DHCP leases until they expire, even though sleep and restarts. If you and I meet while waiting for a flight at an airport and want to exchange files, it is entirely possible that my laptop still has an unexpired lease from my network, and your laptop still has an unexpired lease from your network. If we connect the two laptops with an Ethernet cable, they cannot communicate using those addresses. The addresses and subnet masks are are incompatible. The configured router addresses are unreachable. If our laptops were to configure IPv4LL addresses in this situation, despite having configured routable addresses, then that would enable smart application software to try both, and find that even though the configured routable address does not work, the IPv4LL address does, and that allows the users to exchange their files. Allowing the users to succeed where otherwise they would have failed seems like a good thing. Too many networking geeks confuse understanding a problem with solving it. In the situation above, the friendly networking geek might run a packet sniffer, work out what was wrong, and chuckle and explain condescendingly to the poor computer users how it was their fault for failing to remember to manually release their DHCP leases! What's wrong with this is that diagnosing a problem is not the same as solving it. Solving it means changing the software so that the problem never happens again. Before anyone rushes to criticize Windows here, there's a good argument that the Windows behaviour is correct. We have had many customer reports of problems where they have unreliable DHCP servers that keep crashing. When this happens, the Windows machines cling to their DHCP leases though sleep and restarts and continue to work, whereas the Macs, unable to get a response from the DHCP server after a reboot, fall back to a self-assigned link-local address. You can lecture these people about having reliable DHCP servers that don't keep crashing, but from their point of view the Windows machines work and the Macs don't so it's a Mac problem. If the machines were to cling to their old DHCP leases *and* configure a self-assigned link-local address, then you'd have the best of both worlds: * When you don't hear from the DHCP server because it crashed, you nevertheless can continue to use your routable address. * When you don't hear from the DHCP server because you've moved to a different network that doesn't have a DHCP server, you have a link- local that works for all other compatible hosts on that physical link. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Feb 6 05:24:42 2003 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 FAA11441 for ; Thu, 6 Feb 2003 05:24:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0777E9125E; Thu, 6 Feb 2003 05:28:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B706491261; Thu, 6 Feb 2003 05:28:10 -0500 (EST) 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 BF4379125E for ; Thu, 6 Feb 2003 05:28:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id A68B15DFD8; Thu, 6 Feb 2003 05:28:09 -0500 (EST) 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 172725DF6A for ; Thu, 6 Feb 2003 05:28:09 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id h16AS8I23387 for ; Thu, 6 Feb 2003 02:28:08 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 6 Feb 2003 02:28:08 -0800 Received: from [17.219.194.13] (vpn-scv-x3-13.apple.com [17.219.194.13]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h16AS7Q23329 for ; Thu, 6 Feb 2003 02:28:07 -0800 (PST) Message-Id: <200302061028.h16AS7Q23329@scv2.apple.com> Subject: 3. Who are we talking about? Date: Thu, 6 Feb 2003 02:28:11 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk One mistake I see made repeatedly is being vague about which party we are discussing. Statements like the following are common: *You* know if *you* are using NAT. *You* can choose if *you* want to use NAT, but *you* have no choice about whether *you* want to use LL. Who is "you" in this sentence? There are (at least) three parties who may be involved: 1. The person who owns (or uses, or is responsible for) the computer. 2. The person who owns/manages/maintains the network. 3. The person who wrote the application software. In the case of a business traveler running Outlook Express on their laptop in a hotel room, the application writer has no control over the network environment, and neither does the business traveler. Some people on this list seem to be primarily concerned with the environment where (1), (2) and (3) are all the same person. I think it is a mistake to focus our efforts on this one specialized environment. Most general-purpose application programmers have to try to make software that will run in whatever environment the software finds itself in. The more predictable the target environment, the easier that it. This is why, in many ways, writing PlayStation games is much easier than writing games for PCs -- on the PlayStation you know the exact processor speed, amount of RAM, screen resolution, etc. The knowledge of the unvarying execution environment makes the application programming easier. The more user-controlled customization and configuration options we provide, the harder we make it for application programmers to produce quality software that will work reliably in all possible environments. To relate this to Zeroconf: There have been suggestions to make the DHCP server (or similar) control whether v4LL is active or not. This assumes that the desires of the DHCP server operator are in alignment with the desires of the computer user. If they are not, then it assumes that the person running the DHCP server has the right and the authority to overrule the computer user. In many cases, it is not clear that the person running the DHCP server does have this right. For example, does the person running the rogue DHCP server on his laptop at an IETF meeting have the right and the authority to shut down communication on other computers? Specifically, do they have the right and the authority to shut down communication on the computers being used by the people running the IETF meeting network, who are trying to fix the problem? Another suggestion was a manual control to enable/disable v4LL. This is better, but still has problems. Who controls that manual setting? The computer user? The network operator (by coercing the computer user in some way)? The application writer (by putting instructions in the manual)? What if one application manual says "You MUST turn on v4LL to use this application" and another says "You MUST turn off v4LL to use this application"? What is the poor user supposed to do? If v4LL is always on, and all applications work correctly with it, then it may be more work for some of the application writers, but it's much easier for the user. Which is more important, ease for the application writer or ease for the user? Answers that seem obvious when (1), (2) and (3) are all the same person often don't work when (1), (2) and (3) may not be the same person, and indeed when (1), (2) and (3) may not even be cooperating with each other. The people who own their laptops want to be in control. The people who operate the network want to be in control. The people who own write the applications want to be in control. When those three people want different things, you can't please all of them. A common (and unfortunate) attitude among many IETF participants is that the network operator is god, and everyone else is subservient to their wishes. I do not accept that this attitude is universally correct. In many cases, the network should be there to serve the needs of the users, not the desires of the network operator. However, in cases where the network operator does have the right and the authority to restrict what the users can do, that authority should be enforced at the appropriate level, which in my opinion is 802.1X per-port physical access control, not IP-level controls which do nothing to control use of the physical link via other protocols like AppleTalk, IPX, NetBEUI, etc. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Feb 6 05:26:20 2003 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 FAA11474 for ; Thu, 6 Feb 2003 05:26:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BC3A691261; Thu, 6 Feb 2003 05:29:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BF1491263; Thu, 6 Feb 2003 05:29:50 -0500 (EST) 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 983D191261 for ; Thu, 6 Feb 2003 05:29:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 808095DDD6; Thu, 6 Feb 2003 05:29:49 -0500 (EST) 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 056C25DD8F for ; Thu, 6 Feb 2003 05:29:49 -0500 (EST) 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 h16ATmI23536 for ; Thu, 6 Feb 2003 02:29:48 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Feb 2003 02:29:47 -0800 Received: from [17.219.194.13] (vpn-scv-x3-13.apple.com [17.219.194.13]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h16ATls00632 for ; Thu, 6 Feb 2003 02:29:47 -0800 (PST) Message-Id: <200302061029.h16ATls00632@scv1.apple.com> Subject: 4. Does OS X currently assign both LL and global address at the same time? Date: Thu, 6 Feb 2003 02:29:51 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Several people have asserted that OS X currently does not assign both LL and global addresses at the same time, and have gone on to conclude from this that the LL spec should not encourage (or even allow) a host to have both LL and global addresses at the same time, because there is no operational experience of this behaviour. The initial assertion is false (and, unavoidably, that means that any conclusions drawn from this incorrect assertion are also suspect). To see this for yourself, do the following: 1. Open the Network Control Panel and make sure that both Ethernet and AirPort are enabled. Make sure that Ethernet is listed first as the preferred interface, and AirPort second. Make sure that both are set to "DHCP". 2a. Join an active working wireless network, so that your AirPort interface obtains a routable address via DHCP. 2b. Verify that you can browse the web, etc. 3a. Directly connect some kind of Rendezvous device (another Mac, Rendezvous network camera, Rendezvous network printer, etc.) to your Mac using an Ethernet cable. There being no DHCP server on this Ethernet cable, both the Mac and the other Rendezvous device will self-assign link-local addresses on this link. 3b. Verify that you can communicate usefully with this Rendezvous device (e.g. print a web page on the Rendezvous printer). Result: Macs today *do* assign both LL and global addresses at the same time, and furthermore, doing this enables useful end-user functionality. Implications of this: 1. Applications having to deal with LL and routable is not a new thing introduced by the draft. It is with us today. In this example the addresses were assigned on different interfaces, but the implications for application software running on that host are substantially the same as if both were on the same physical interface. 2. Applications having to deal with addresses with different reachability is not a new thing introduced by IPv4LL. It is with us today. In the above scenario, we could have attached a DHCP server to the Ethernet link, and it could have assigned 10.0.0.2 to the Mac and 10.0.0.3 to the printer. In that case there would be no IPv4LL addresses involved, but any applications running on the multi-homed host would still have had to deal with the fact that the machine had an address 10.0.0.2 which was useful for communicating with the printer, but had no useful applicability outside that physical link. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Feb 6 05:27:44 2003 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 FAA11505 for ; Thu, 6 Feb 2003 05:27:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0C64C91263; Thu, 6 Feb 2003 05:30:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C0EB39127A; Thu, 6 Feb 2003 05:30:41 -0500 (EST) 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 B6EF091263 for ; Thu, 6 Feb 2003 05:30:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F5685DD8F; Thu, 6 Feb 2003 05:30:34 -0500 (EST) 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 A9DB05DF6A for ; Thu, 6 Feb 2003 05:30:33 -0500 (EST) 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 h16AUXI23647 for ; Thu, 6 Feb 2003 02:30:33 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Feb 2003 02:30:32 -0800 Received: from [17.219.194.13] (vpn-scv-x3-13.apple.com [17.219.194.13]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h16AUWs00766 for ; Thu, 6 Feb 2003 02:30:32 -0800 (PST) Message-Id: <200302061030.h16AUWs00766@scv1.apple.com> Subject: 5. IPv4LL is not about "dumbing down" current hosts Date: Thu, 6 Feb 2003 02:30:36 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk I have seen assertions that the idea of a device that implements only IPv4LL addresses is to take a fully-functional IP host and "dumb it down" so it can't talk to anything further away than the local link. I will try to explain the real issue below, and I will thank people for making an honest effort to understand and internalize this information. Willful refusal to understand this issue and willful misrepresentation of it does not help us reach a conclusion. First I will describe two classes of device: 1. Current IP hosts. These support world wide connectivity to millions of other hosts, over distances of thousands of miles. 2. Current USB peripherals. These are limited to small clusters of a handful of devices, with cable lengths limited to about 16 feet. My goal here is NOT to take existing fully-functional IP devices and dumb them down to make them less functional. One of my hoped-for goals for Zeroconf is to take the current USB peripherals and move them up them to networks of a hundred devices, with cable lengths in the hundreds of feet, using standard IP-based communication protocols, instead of the device-specific communication protocols currently used by USB, FireWire, Bluetooth, etc. Ideally we'd like to do this while keeping the same price-point as current USB peripherals like printers. This makes the device better and more useful than it was when it was only a USB device. If we can acheive this (and we are starting to), then the next goal is to encourage printer vendors to make printers with full global IP connectivity -- and the requisite security to go with it -- and to continue to do it at an affordable price point. Please try to think of IPv4LL-only in terms of a step forward for a device that is currently even more limited, not a step backwards for a device that already has full IP functionality. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Feb 6 05:30:12 2003 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 FAA11559 for ; Thu, 6 Feb 2003 05:30:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9070C9127A; Thu, 6 Feb 2003 05:33:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50E599127B; Thu, 6 Feb 2003 05:33:31 -0500 (EST) 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 342E89127A for ; Thu, 6 Feb 2003 05:32:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 128B45DFD8; Thu, 6 Feb 2003 05:32:19 -0500 (EST) 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 8CCAF5DDD6 for ; Thu, 6 Feb 2003 05:32:18 -0500 (EST) 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 h16AWII23815 for ; Thu, 6 Feb 2003 02:32:18 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Feb 2003 02:32:17 -0800 Received: from [17.219.194.13] (vpn-scv-x3-13.apple.com [17.219.194.13]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h16AWHs01068 for ; Thu, 6 Feb 2003 02:32:17 -0800 (PST) Message-Id: <200302061032.h16AWHs01068@scv1.apple.com> Subject: 6. Zeroconf Charter? Date: Thu, 6 Feb 2003 02:32:21 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk John Welch wrote that we want to, "make IP as easy, or easier to use as Appletalk." Keith Moore replied: >This is not in this group's charter. If this group is trying to >do that, it's violating its charter and it needs a mercy killing. I think that many of the people doing genuine work in this working group believed that an important part of the group's charter was to make networking easier to use, particularly in the case of small networks used by inexpert users. If, as Keith asserts, making networking easier to use is a violation of the group's charter, then perhaps that means the charter was poorly worded and failed to clearly convey the true intent of the people who created it. Perhaps the charter did not clearly state that one of the goals was a solution that was both reliable and easy to use, but I do not believe that the charter specifically prohibited it. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Feb 6 05:37:48 2003 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 FAA11764 for ; Thu, 6 Feb 2003 05:37:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C7ED69127B; Thu, 6 Feb 2003 05:41:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 835889127D; Thu, 6 Feb 2003 05:41:15 -0500 (EST) 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 EB8DB9127B for ; Thu, 6 Feb 2003 05:41:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id D2D6E5DF6A; Thu, 6 Feb 2003 05:41:13 -0500 (EST) 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 5992B5DD8F for ; Thu, 6 Feb 2003 05:41:13 -0500 (EST) 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 h16AfCI27738 for ; Thu, 6 Feb 2003 02:41:12 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 6 Feb 2003 02:41:11 -0800 Received: from [17.219.194.13] (vpn-scv-x3-13.apple.com [17.219.194.13]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h16AfBQ25367 for ; Thu, 6 Feb 2003 02:41:11 -0800 (PST) Message-Id: <200302061041.h16AfBQ25367@scv2.apple.com> Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt Date: Thu, 6 Feb 2003 02:41:15 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >The IESG discussed this document recently, and has the following >comments. > >DISCUSS: >======== >Harald: > >Three objections, based on a quick scan: > >1) >The document gives no (zero) examples of applications that can >successfully and safely be used with link-local addresses. *ALL* application protocols can successfully and safely be used with link-local addresses on a single isolated link. This is the whole point of Zeroconf. If the majority of applications have to be changed, then a major part of the benefit of Zeroconf is lost. If the majority of applications have to be changed before they work, then why not change them to use the USB APIs, or the FireWire APIs, or the Bluetooth APIs? One major benefit of Zeroconf is that you can just plug two laptops together, and your current ftp client works. Your current NFS client works. Your current Web browser works. The entire wealth of software that you can use on the world wide Internet can also be used on a tiny network consisting of just two laptops and a cable. Between a group of hosts on a single isolated link, to my best current knowledge, *ALL* current application protocols work unchanged. That is not to say that all possible *uses* of all application protocols work. For example, HTTP can usually be used to buy books from Amazon.com, but this use of HTTP is not possible if you are not able to communicate with Amazon.com. However, the same Web browser software *can* use the same HTTP protocol to communicate with other local devices, such as checking the status page showing the ink levels in your local network printer. Using link-local addresses on a link that also has connectivity to the rest of the Internet raises more issues, but I do not believe it creates any new issues that do not already exist by virtue of NATs, multi-homing, private addressing (e.g. Net 10) and any other issues relating to hosts that have multiple addresses with differing reachability with respect to the peers that host can talk to. >2) > >The following section: > > > 2.10 Higher-Layer Protocol Considerations > > > > Similar considerations apply at layers above IP. > > > > For example, designers of Web pages (including automatically > > generated web pages) SHOULD NOT contain links with embedded > > link-local addresses if those pages are viewable from hosts outside > > the local link where the addresses are valid. > > > > As link-local addresses may change at any time and have limited > > scope, storing link-layer addresses in the DNS is not well > > understood and it is NOT RECOMMENDED. > >is not sufficiently draconian. > >It should probably say something like: > >The following set of protocols: > >- FTP >- DNS >- NFS >- IPSEC using IPv4 as an identifier >- BGP >- OSPF >- RTP/RTCP > <<>> > >will fail if applications use a link-local address instead of a >globally unique address when sending the address of its interface in >a protocol packet. This statement is false. Between a group of hosts on a single isolated link, all of those protocols work fine, to the extent that they are applicable to a group of hosts on a single isolated link (routing protocols like BGP are the one case that comes to mind as something that makes no sense to run between a group of hosts on a single isolated link). The fact that FTP, NFS, telnet, http, ssh, RTP, etc., work fine (in the sense that they allow the user to accomplish useful work) can be easily verified by connecting two Macs (or two Windows machines) with an Ethernet cable and trying them. >3) > >Security consideration, section 2.8: > > > The non-forwarding rule is important because it is expected that > > many link-local-only devices will be extremely simple devices of > > the kind that currently use X10 [X10], USB [USB] or FireWire [1394]. > > > > The designers of these devices currently assume that they will > > communicate only with other local devices, and this allows them to > > produce cost-effective devices by implementing a degree of security > > appropriate for that expected environment. Any network gateway device > > that blindly forwards the contents of link-local IP packets off the > > local link (or onto the local link) exposes simple link-local-only > > devices to a much greater degree of risk than their designers may > > have planned for. > >In the world of wireless LANs, this seems to be an extremely stupid >idea. (not that it was a smart move before.....for kicks, try plugging >an X10 controller into your neighbour's outdoor electrical socket and >start playing....) >I would suggest to add a NOTE: > >NOTE: The existence of local links without physical security, such as >LANs with attached wireless base stations, means that expecting all >local links to be secure enough that normal precautions can be dispensed >with is an extremely dangerous practice, which will expose users to >considerable risks. I have no objection to adding this note to the document, and will do so unless I hear opposition from the Working Group. >Steve: >How do current hosts behave with respect to this: > > All ARP packets (*replies* as well as requests) that contain a > link-local 'sender IP address' MUST be sent using link-level > broadcast instead of link-level unicast. This aids timely > detection of duplicate addresses. An example illustrating how this > helps is given in Section 4. > >(I understand the necessity, but is it done? I suspect not. 1. It is not a "necessity". It aids in faster detection of duplicate addresses. This is a good thing, but by no means a "necessity". 2. This has been done in Mac OS since IPv4LL first shipped four years ago. As far as I know, it is not done in any version of Windows. As far as I know, no work at all has been done on IPv4LL in Windows since it first shipped four years ago. I am told that Microsoft is waiting for this document to be published as RFC before deciding whether to make any changes to their IPv4LL implementation. >This suggests that there be a warning that link-local addresses >SHOULD NOT be manually configured.) This is what the document currently says. Is this sufficient? 1.4. 169.254/16 Not To Be Used for Other Purposes Note that addresses in the 169.254/16 prefix SHOULD NOT be configured manually >I have vague recollections of an RFC that permits hosts to ignore >spontaneous ARP replies, i.e., those not in response to a query, in an >effort to block connection hijacking. I think that some hosts actually >do this. That would interfere with the claim-and-defend mechanism, and >with renumbering, I believe. 1. I am not aware of any such RFC 2. This document does not advocate spontaneous ARP replies 3. In any case, I do not see how it would interfere with the claim-and-defend mechanism. >What use is link-local security in a world of wireless bridges? What assumption is there that all devices will be connected to wireless bridges? One application of IPv4LL is for communication between components inside a sealed computer chassis. Physical security is applicable in those situations where physical security is applicable. USB and FireWire connections typically rely on the physical security of the cable, and there may be some cases where the same level of security is appropriate for IP-based replacements for those technologies. I do not think this document should claim that physical security is always adequate security; nor do I think that this document should claim that physical security is never adequate security. >The Security Considerations section should note that address-based IKE >certificates [RFC2409, I think] MUST NOT be issued for link-local >addresses. I do not want to draft text on a subject on which I am not an expert. If you can offer precise text, I have no objection to adding it to the document, in the absence of any opposition from the Working Group. Are you CERTAIN that there is no situation in which IKE certificates could not be usefully used between a group of hosts on a single isolated link? >Alex: > Seems to me that a "routing considerations" section is required. > Some things that should be described: > > - should a route be installed in the routing table based > on the link-local address on an interface? Isn't this an implementation issue, not a protocol issue? How a host implements its own internal data structures is private to the host, is it not? > - should/can the 169.254/16 prefix be announced by dynamic > routing protocols? > > - if received from a routing protocol, should the prefix > be installed in the RT? > > - what the behavior should be if the prefix somehow > made it to the RT (static route, old routing proto)? I do not want to draft text on a subject on which I am not an expert. If you can offer precise text, I have no objection to adding it to the document, in the absence of any opposition from the Working Group. However, even though the document doesn't mandate how a host should implement its networking software, I think it is already pretty clear on what the correct end behavior is: If the destination address is in the 169.254/16 prefix ... The host MUST NOT send the packet to any router for forwarding. ... send its packet, with a link-local source IP address ... directly to its destination on the same physical link. The host MUST NOT send the packet to any router for forwarding. An IPv4 packet whose source and/or destination address is in the 169.254/16 prefix MUST NOT be sent to any router for forwarding, and any network device receiving such a packet MUST NOT forward it, regardless of the TTL in the IP header. This restriction also applies to multicast packets. IP packets with a link-local source address MUST NOT be forwarded off the local link even if they have a multicast destination address. >Erik: >The abstract and first paragraph in the introduction can easily >be read as these addresses being a full-fledged replacement of >DHCP assigned addresses. >Having the text explicitly say that such addresses can not be used >for communication outside a single link would make sense. Unless I hear opposition from the Working Group, I will add the following text: Link-local communication using link-local addresses is only suitable for communication with other devices connected to the same physical (or logical) link. Link-local communication using link-local addresses is not suitable for communication with devices not directly connected to the same physical (or logical) link. >In the applicability section it would make sense to add explicit >warnings about issues for applications. One issue is the addresses >are of limited scope which might cause problems for multi-party >applications that pass IP addresses between parties. The document already says: 7.2 Limited Forwarding of Locators IPv4 link-local addresses MUST NOT be forwarded via an application protocol (for example in a URL), to a destination which is not link-local, on the same link. This is discussed further in Section 2.9 and 3. Is there additional text you would like to see? Perhaps it could be worded better as follows? 7.2 Limited Forwarding of Locators The forwarding of IPv4 link-local addresses via an application protocol (for example in a URL), to a destination which is not link-local, on the same link, may result in unexpected failures. This is discussed further in Section 2.9 and 3. Does this wording make the requirement less of a burden on the application writer, and more of a warning to the user that if they do inappropriate things, things may not work as expected? Is that better, or worse? >The other issue is that these addresses might have much shorter and >unpredictable lifetime, which would have an impact on applications >using them on the link. (This is true especially given the >suggestions in section 2.5 to pick a new address when a conflict is >detected after the address has been used for a while.) This is a common misconception. IPv4 link-local addresses DO NOT change randomly at whim. IPv4 link-local addresses only change in the event of catastrophic failure from which there is no other way to recover. Previously, IP hosts typically had no recovery mechanism in the even of two hosts using the same IP address, leaving the hosts useless until manual intervention fixes them. In the case of hosts with no screen and keyboard, which are only controlled via telnet or http connections over the network, the complete failure of networking left them in an unrecoverable situation. I myself have been at IETF meetings where network operators have had to physically yank the power cables from wireless base stations that had become accidentally misconfigured this way. The fact that the IPv4 link-local specification includes a provision to automatically recover from this previously unrecoverable error scenario has frequently been misunderstood and cited as a weakness of the design instead of a strength. These frequent arguments have led to people demanding that the document includes text that implies that link-local address changes are frequent and random and unpredictable and unreasonable for applications to deal with. This text in the document then leads yet more people to believe that the ability to recover even from catastrophic failure scenarios is a weakness of the design, instead of a strength. In reality, IPv4 link-local are frequently *more* stable that other forms of address. Every time I take my laptop from home to work and back it gets a different DHCP address, yet it rarely (if ever) encounters a conflict where it has to change its IPv4 link-local address. >The text in section 2.5 says that in some cases the host MUST cease >using the address. Since it is easy for an on-link attacker to spoof >the ARP packets it can cause the host to break all its connections by >switching to a new address. The document should at least warn against >this in section 2.5, and presumably also discuss it in the security >considerations section. Section 2.5 already says: Forced address reconfiguration may be disruptive, causing TCP connections to be broken. However, this notion that this is a weakness of IPv4 link-local is another common myth. In an on-link attacker spoofs ARP packets, then in reality you will lose all your TCP connections to resets and timeouts, even if you do refuse to pick a new address. The difference is that if you refuse to pick a new address, you will be unable to establish any reliable new TCP connections either. If you don't believe me, open a bunch of telnet or ssh connections, and then set another local machine to the same IP address and see what happens. (Note: don't try to do this with a Mac, because Macs implement IPv4ACD to guard against accidentally or deliberately setting two hosts to the same IP address. Using some other OS you should be able to set two machines to the same IP address and see what happens.) > And here is a "bonus" I didn't mention on the call: > The time values specified above are intended for use on > technologies such as Ethernet, where switches that implement > Spanning Tree [802.1d] often silently discard all packets for > several seconds. The time values specified above result in a > delay of 8-10 seconds before a chosen IP address may be used. > For a desktop machine on Ethernet, > > FWIW when 802.1d is enabled on the port I plug in my laptop at the > office, the delay before the switch starts forwarding packets is 45 > seconds. (I think the 802.1d spec indicates a default time of around > 30 seconds.) So 10 seconds don't seem to do much good. I am also working with IEEE people to solve the spanning tree problem. I don't think it is appropriate to put all of that protocol detail into an IETF document. The document already says this: Should future versions of the IEEE Spanning Tree Protocol be enhanced to inform clients when the link is ready to begin forwarding packets, then the shorter time values may be used on these networks too. > 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 for a link-local multicast destination. But for other multicast > destinations I assume it SHOULD use any routable address instead of > the link-local. Unless I hear opposition from the Working Group, I will add the following text: If the destination address is the 255.255.255.255 broadcast address or a link-local multicast address, then the host may use either its link-local source address or a routable address, as appropriate. If the destination address is a multicast address with scope larger than link-local then the host SHOULD use an appropriate routable source address, if available, or its link-local source address otherwise. > section 3.2: > Some operating systems have networking APIs that allow > applications to specify network interfaces by name, index value, > or other local identifier, and to identify interfaces this way > both for incoming and outgoing packets/connections. For operating > systems that have this capability (and have application software > that makes use of it) it is sufficient to configure all interfaces > with a single common IPv4 link-local address, and defend that > address on all interfaces. > > Add warning that uses the same address on all interfaces makes the host > more suceptible to attacks and other reasons for duplicate addresses > being detected late, resulting in a shorter lifetime for the link-local > addresses. Using a separate address per interface limits the "damage" > in such a case to a single link. Unless I hear opposition from the Working Group, I will add the following text: Note that this may make forced reconfigurations more costly, since a conflict on a single interface in effect causes all interfaces to have to reconfigure to a new address. > section 3.3 > In addition, this kind of host should probe for, and defend, all > of its link-local addresses on all of its active interfaces that > are using link-local addresses. > > When bringing up a new interface, the host SHOULD first probe > for all of its existing link-local addresses on that new interface. > If any of the addresses are found to be already in use by some > other host on that new link, then the interfaces in question MUST > be reconfigured to select new unique link-local addresses. The > host should then select a link-local address for the new interface, > and probe on all of its active interfaces to verify that this new > address is unique on all the links that the host has connections to. > > The above breaks if multiple interfaces on the host are connected > to the same link. I do not believe it does. Please explain how. > It also isn't clear to me why this is needed; > presumably the interfaces can be managed indepdently as long as the host > ensures that it doesn't assign the same link-local address to more than > one interface. 3.3.1 "Example Illustrating (Incorrect) Ambiguous Address Re-Use" explains why this is beneficial to hosts that choose to implement it that way. >Thomas: > > 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. Unless I hear opposition from the Working Group, I will change the text as follows: 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 MUST 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 the destination on the same physical link. In many network stacks, achieving this functionality may be as simple as adding a routing table entry indicating that 169.254/16 is directly reachable on the local link. The host MUST NOT send a packet with a link-local destination address to any router for forwarding. If the destination address is a unicast address outside the 169.254/16 prefix, then the host SHOULD use an appropriate routable source address, if it has one. If the host does not have an appropriate routable source address, then it MUST ARP for the destination address and then send its packet, with a link-local source IP address and a routable destination IP address, directly to the destination on the same physical link. In the case of a device with only a link-local address, this requirement can be paraphrased as "ARP for everything". In many network stacks, achieving this "ARP for everything" behaviour may be as simple as having no primary IP router configured, having the primary IP router address configured to 0.0.0.0, or having the primary IP router address set to be the same as the host's own link-local IP address. In any event, the host MUST NOT send a packet with a link-local source address to any router for forwarding. >COMMENT >------- >Scott: notes: > references not split > this can get fixed when Harald's discuss is delt with Noted. This will be fixed. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Feb 6 05:43:03 2003 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 FAA11994 for ; Thu, 6 Feb 2003 05:43:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 430B19128C; Thu, 6 Feb 2003 05:46:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2C759128D; Thu, 6 Feb 2003 05:46:31 -0500 (EST) 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 8EDE09128C for ; Thu, 6 Feb 2003 05:46:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3C0815DDD1; Thu, 6 Feb 2003 05:45:51 -0500 (EST) 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 B38A05DD8F for ; Thu, 6 Feb 2003 05:45:50 -0500 (EST) 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 h16AjoI28247 for ; Thu, 6 Feb 2003 02:45:50 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Feb 2003 02:45:49 -0800 Received: from [17.219.194.13] (vpn-scv-x3-13.apple.com [17.219.194.13]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h16Ajns04118 for ; Thu, 6 Feb 2003 02:45:49 -0800 (PST) Message-Id: <200302061045.h16Ajns04118@scv1.apple.com> Subject: BusinessWeek: Home Is Where the Tech Is Date: Thu, 6 Feb 2003 02:45:53 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk I found this article in BusinessWeek particularly topical, considering our discussions around the topic of "reliable and easy to use": >For consumer-electronics manufacturers and retailers to prosper in an >increasingly competitive environment, they'll have to provide better >customer support. This means improved service as well as more >consumer education. A lot of people now know how to take snapshots >with digital cameras, but that doesn't mean they know how to e-mail >pictures to friends, display them on a big screen, or back them up on >their PCs. Customer-service reps at Linksys report that increasing >numbers of callers wait to hear a live voice before they even tear >the shrink-wrap off the box. Finding ways to both lessen the >frustration of consumers who can't assemble their costly purchases >and keep profits up will be a challenge for many companies, as more >and more novices buy increasingly sophisticated gear. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Feb 6 06:34:13 2003 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 GAA13867 for ; Thu, 6 Feb 2003 06:34:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 78D6A9128F; Thu, 6 Feb 2003 06:37:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E598391294; Thu, 6 Feb 2003 06:37:41 -0500 (EST) 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 D9A489128F for ; Thu, 6 Feb 2003 06:37:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id B28435DFF9; Thu, 6 Feb 2003 06:37:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id E9AE65DE06 for ; Thu, 6 Feb 2003 06:37:34 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h16Baen23134; Thu, 6 Feb 2003 18:36:40 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h16BXKb13643; Thu, 6 Feb 2003 18:33:21 +0700 (ICT) From: Robert Elz To: Erik.Guttman@Sun.COM Cc: zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs In-Reply-To: <3E40FB68.1D4AF1B0@Sun.COM> References: <3E40FB68.1D4AF1B0@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Feb 2003 18:33:20 +0700 Message-ID: <13641.1044531200@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 05 Feb 2003 12:54:16 +0100 From: erik guttman Message-ID: <3E40FB68.1D4AF1B0@Sun.COM> | The summary of the consensus follows. There's been enough discussion of your first couple of points already, I don't see the need to add more. But ... | REJECTED: | This specification will define or require some additional mechanism | to disable IPv4 LL autoconfiguration. | | WG chair assessment: | This suggestion has been brought up in past last calls and again in | this discussion. There again fails to be anything like working group | consensus to support or introduce this feature. I'd agree with that assessment, but not with the conclusion. You could just as easily say that there fails to be anything like WG consensus to exclude it. What this eventually comes down to is that the doc author writes whatever he likes, and unless there's WG consensus to change it, it stays the way it is written. That's not the way the IETF works (or it isn't the way it is supposed to work). What's supposed to happen, is that the WG is supposed to reach at least rough consensus that the document is acceptable, which does not mean reaching a stage where there are no remaining issues upon which consensus can be reached, so the rest just get left however they happen to exist. One way or another, some kind of (rough) consensus needs to be reached on this issue (note: we're not debating here whether an existing protocol should be changed, where you can say "no consensus to make a change"). But this part | There are very clear | and unchallenged technical arguments from Ted Lemon indicating that | there are severe security considerations with coercive deactivation | IPv4 LL autoconfiguration. is simply wrong. I certainly challenged Ted's arguments (several times). Ted didn't even reply to my last message on the issue (whether that was due to exhaustion, or finally realising his mistake, I can't tell). The security considerations argument against this is simply bogus. That of itself doesn't necessarily mean that there must necessarily be a way to tell a device to not configure itself on a LAN at all, but using the bogy man of "security" as if it were an unassailable argument against this is not going to achieve anything. kre From owner-zeroconf@merit.edu Thu Feb 6 06:41:10 2003 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 GAA14109 for ; Thu, 6 Feb 2003 06:41:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D984491294; Thu, 6 Feb 2003 06:44:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9CB1E9129E; Thu, 6 Feb 2003 06:44:40 -0500 (EST) 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 98E3B91294 for ; Thu, 6 Feb 2003 06:44:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 75E885DE06; Thu, 6 Feb 2003 06:44:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 9FF935DD8F for ; Thu, 6 Feb 2003 06:44:37 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h16Bhin26016; Thu, 6 Feb 2003 18:43:46 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h16BeBb13659; Thu, 6 Feb 2003 18:40:20 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs In-Reply-To: <1044468469.1516.40.camel@devil> References: <1044468469.1516.40.camel@devil> <3E40FB68.1D4AF1B0@Sun.COM> <20030205123930.4a79df03.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Feb 2003 18:40:11 +0700 Message-ID: <13657.1044531611@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 05 Feb 2003 20:07:49 +0200 From: Mika Liljeberg Message-ID: <1044468469.1516.40.camel@devil> | > However I'd also argue that a reasonable | > effort SHOULD be made to acquire an address via DHCP before a host ever | > attempts to configure or use an LLv4 address. | | This is too slow for ad-hoc configurations in environments like Buetooth | PAN. I suspect that you're overestimating what is required of "reasonable effort". I'd be happy if a node sent a DHCPDISCOVER, got no reply in 0.2 seconds, sent another, again got no reply (perhaps just wait 0.1 seconds this time) and then, said "OK, I'll do the LL thing" - while continuing to look for a DHCP answer in parallel. Even there, those times are probably more than really required. Most of the time, nodes will get replies to DHCP requests quite quickly, when one doesn't appear promptly, the chances are that there won't be one, so at that point, starting to get a LL address seems reasonable to me. That is, there's no need to wait until all hope of obtaining a LL address has been abandoned (for now anyway) - but avoiding starting on the ARP merry-go-round for LL addresses, when a (quite short) delay would have avoided that seems like a very good idea to me. | Besides, going for rules different from IPv6 just causes headaches for | hybrid IPv4/IPv6 stack implementors. All this stuff is completely different in IPv6, there is simply no comparison. kre From owner-zeroconf@merit.edu Thu Feb 6 07:02:59 2003 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 HAA14791 for ; Thu, 6 Feb 2003 07:02:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 061D79129E; Thu, 6 Feb 2003 07:06:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BFBF69129F; Thu, 6 Feb 2003 07:06:29 -0500 (EST) 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 B5D339129E for ; Thu, 6 Feb 2003 07:06:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id A45D05E01B; Thu, 6 Feb 2003 07:06:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id BC1F95E01A for ; Thu, 6 Feb 2003 07:06:00 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h16C4wn01546; Thu, 6 Feb 2003 19:04:59 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h16C1Ab13695; Thu, 6 Feb 2003 19:01:15 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: 2. Disabling LL -- or -- How does a host know if it is configured correctly? In-Reply-To: <200302061027.h16ARAf23194@scv3.apple.com> References: <200302061027.h16ARAf23194@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Feb 2003 19:01:10 +0700 Message-ID: <13693.1044532870@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 6 Feb 2003 02:27:13 -0800 From: Stuart Cheshire Message-ID: <200302061027.h16ARAf23194@scv3.apple.com> | One of the goals I believe is important is creating reliable networking | that doesn't fail. There is no such thing. | Just having a configured routable address doesn't mean that it is | necessarily correct or currently usable. Nor does having a LL address mean that it is usable. If an address has been configured for a node, and it is a bad address, then it ought to be fixed (in the same way it was originally configured, however that was). That needs to be done anyway. Papering over the misconfiguration by making the node seem to work for some things does a dis-service to everyone in the long run. At the very least it increases confusion. Users might not be very happy when they learn that someone screwed up their configuration, so they can't use the net - but they also understand human error, and cope with it (are you also planning to handle the case where someone screwed up the wiring to the interface cable, in the cases where there is one?) On the other hand, allow the user to see that their system is "working" (see, I can print, access files, ...) but they can't do everything, and they're going to assume that something else is broken instead, and often refuse to believe that their system has any kind of problem at all "it works, I proved it". | Windows machines have a tendency to cling to their DHCP leases until they | expire, even though sleep and restarts. If you and I meet while waiting | for a flight at an airport and want to exchange files, it is entirely | possible that my laptop still has an unexpired lease from my network, and | your laptop still has an unexpired lease from your network. If we connect | the two laptops with an Ethernet cable, they cannot communicate using | those addresses. The addresses and subnet masks are are incompatible. The | configured router addresses are unreachable. That's a bug. I'll come to why in a minute. | Too many networking geeks confuse understanding a problem with solving | it. In the situation above, the friendly networking geek might run a | packet sniffer, work out what was wrong, and chuckle and explain | condescendingly to the poor computer users how it was their fault for | failing to remember to manually release their DHCP leases! I suppose a "geek" might just do that. Someone who really understands would explain that the software that acted this way is broken, and should be returned for repair... Just the same as if the problem turned out to be a broken wireless card that wasn't actually transmitting. | Before anyone rushes to criticize Windows here, there's a good argument | that the Windows behaviour is correct. No there isn't. | We have had many customer reports | of problems where they have unreliable DHCP servers that keep crashing. | When this happens, the Windows machines cling to their DHCP leases though | sleep and restarts and continue to work, As they should. But that isn't the situation you described above. Here, the system is still on the link where the address works. Above it wasn't. When no DHCP server responds, the client should examine its existing leases, see if any remain valid (have not expired - and note that there might be many of those, not just one) and then attempt to see if one of those still appears to work. The easy way to do that is to see if any of the addresses that the previous lease contained respond to ping (the default router, the time server, ...) If none answer, then there's a very good chance that what has happened is that the node has moved to a new net with no DHCP, and its leases should all be ignored. That's your airport example - so you just configure your LL address and continue. On the other hand, if the DHCP server has just crashed (a phenomenon which happens much less frequently these days than it used to) it is very unlikely that the router, NTP server, printer server (anything else that was in the DHCP response from before) have also all crashed. | whereas the Macs, unable to get | a response from the DHCP server after a reboot, fall back to a | self-assigned link-local address. That's also broken. If it has a lease which is still valid, and which still works, it should go ahead and use the thing. | You can lecture these people about | having reliable DHCP servers that don't keep crashing, but from their | point of view the Windows machines work and the Macs don't so it's a Mac | problem. And if you observe the DHCP mailing lists, you'll see frequent cursing of Windows systems for just this behaviour (though much of it probably relates to earlier, even more broken, behaviour). They're both wrong. Please refer back to your Engineering philosophy - the software engineers should be doing more work in order for the users to have to do less, and for things to break less often. In this case, assuming what you say is correct (I use neither Windows nor Apple stuff), then the software engineers simply haven't done enough work in either of those systems yet. kre From owner-zeroconf@merit.edu Thu Feb 6 07:49:28 2003 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 HAA16160 for ; Thu, 6 Feb 2003 07:49:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ABE1F91278; Thu, 6 Feb 2003 07:52:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B98B9128B; Thu, 6 Feb 2003 07:52:58 -0500 (EST) 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 F406E91278 for ; Thu, 6 Feb 2003 07:52:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id D612A5DDFB; Thu, 6 Feb 2003 07:52:56 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 827A75DDF1 for ; Thu, 6 Feb 2003 07:52:54 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h16Cq3n03536; Thu, 6 Feb 2003 19:52:03 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h16Cpab13766; Thu, 6 Feb 2003 19:51:36 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: 3. Who are we talking about? In-Reply-To: <200302061028.h16AS7Q23329@scv2.apple.com> References: <200302061028.h16AS7Q23329@scv2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Feb 2003 19:51:36 +0700 Message-ID: <13764.1044535896@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 6 Feb 2003 02:28:11 -0800 From: Stuart Cheshire Message-ID: <200302061028.h16AS7Q23329@scv2.apple.com> | Some people on this list seem to be primarily concerned with the | environment where (1), (2) and (3) are all the same person. Really? I haven't detected that from anyone at all. But... | I think it is a mistake to focus our efforts on this one specialized | environment. It certainly would be, if anyone was doing that. But not even the people I most disagree with seem to be doing that. And you know I'm not, because some of my arguments have been aimed at having the network manager be able to override what the software author (and perhaps the user) would like to do... | Most general-purpose application programmers have to try to make software | that will run in whatever environment the software finds itself in. Yes. | The more predictable the target environment, the easier that it. yes, but do remember your engineering philosophy - the programmer is supposed to be doing more work to make it easier for the user. | The more | user-controlled customization and configuration options we provide, the | harder we make it for application programmers to produce quality software | that will work reliably in all possible environments. Yes, it is harder. But without (some) configuration options, we make it impossible instead. That is, we don't get to control the environment by assuming one nice (for us) case where everything just works, which means that the end user is screwed when he happens to end up in an environment which is different from the one we're pretending exists. Refer back to your ... | There have been suggestions to make the DHCP server (or similar) control | whether v4LL is active or not. This assumes that the desires of the DHCP | server operator are in alignment with the desires of the computer user. No. It most certainly does not. It assumes that the DHCP server operator is the one in charge, and gets to dictate to the user. | If they are not, then it assumes that the person running the DHCP server | has the right and the authority to overrule the computer user. Yes. That's inherent in the design of DHCP (and given that it is in use). | In many cases, it is not clear that the person running the DHCP server | does have this right. That's true too. | For example, does the person running the rogue DHCP server on | his laptop at an IETF meeting have the right and the authority to shut | down communication on other computers? Of course not. They also don't have the right to prevent others from obtaining a properly routable address. Saying to an IETF attendee "here, you can have this bogus address, which won't work" would not be nice at all. Allowing the IETF attendee to also get a LL address, which is useless to 99% of them (who just want to get home and read their mail, and aren't in the slightest interested in exchanging files with anyone) doesn't help. Whether they're turned off completely, or just made useless, makes no difference. Just the same applies to people who make themselves appear to be access points, and screw up the wireless LAN. Are you proposing a magic solution for that as well? Where (as is almost always the case, from my experience anyway) this has happened it is because of an accident, then the right solution would be to make it much harder for accidents to happen like this - that is, for the software engineers who implement this stuff to do more work ... Where someone is deliberately being malicious, this particular method of attack is the very last one I'd be worried about, attackers connected to the net have much more potent weapons, readily available. Also note that the "disable all addresses" option that has been proposed is effective only when *all* DHCP servers that are available send it. If a single one does not, then the node will be able to acquire an address (DHCP always allows the client to select which of the offers it prefers). So, for this particular issue anyway, some stray user at an IETF meeting sending out "unlink yourself from the network" is not going to work, unless they can also manage to prevent the real DHCP server from replying. | Specifically, do they have the | right and the authority to shut down communication on the computers being | used by the people running the IETF meeting network, who are trying to | fix the problem? Of course not. But no-one is suggesting that manual overrides should not win in any of these debates. That is, if the user says "use this address" or even "Go run the LL algorithm and configure an address" then that's what the node does, regardless of what any DHCP server might happen to say. What's more, if in that situation, the "people" were stupid enough to (attempt to) configure themselves LL addresses to try and diagnose the problem, then I'd be seriously questioning their competence to be running any network, let alone one as stressful as an IETF meeting. | Another suggestion was a manual control to enable/disable v4LL. This is | better, but still has problems. Who controls that manual setting? The | computer user? Of course. Otherwise it wouldn't be a manual setting. | The network operator (by coercing the computer user in some way)? That too, if it works, but that's the computer user again, the only difference is the rationale for their actions. Specifying that is way out of our charter. | The application writer (by putting instructions in the manual)? I would certainly hope not - as, as above, the application writer has no idea of the environment in which the software will be used - their job is to make it work, whatever the environment, whenever it is possible. | What if one application manual says "You MUST turn on v4LL to | use this application" and another says "You MUST turn off v4LL to use | this application"? What is the poor user supposed to do? Throw out both pieces of software, and get some that functions. (Of course, this is a very contrived example anyway, it is hard to conceive of anything which would actually care what kind of address the node has, as long as it has one - whether the address the node has is going to be successful to reach a peer is something that the software can only ever tell by trying it - then if it fails, all the software can do is report that, we don't currently have any method of somehow guessing what address would have worked to reach that other guy who simply didn't answer). | If v4LL is always on, and all applications work correctly with it, That's an assumption. Not that the application writers would have to do more work, but that it is actually possible to do the work. If it turns out to be impossible, what then? | Which is more important, ease for the application writer or | ease for the user? Ease for the user of course - but that doesn't mean "LL is always on" is the answer, it means "application writers must write code that works with or without LL addresses". | The people who own their laptops want to be in control. Of course they do, and they can be, as much as they're able - and of course, assuming they're aware that when they start dictating how things should be, they have to be responsible when that causes things to fail. | The people who operate the network want to be in control. Of course, it is their network, they are in control. | The people who own write the applications want to be in control. They shouldn't. Remember the engineering principles - they're supposed to do more work ... | A common (and unfortunate) attitude among many IETF participants is that | the network operator is god, and everyone else is subservient to their | wishes. The problem is that this all depends upon the level at which you look at this. | I do not accept that this attitude is universally correct. In | many cases, the network should be there to serve the needs of the users, Of course it should. And it is the network operator's job to make it so (in those cases - there are others where the network is not intended to serve any needs of random users at all.) | not the desires of the network operator. A common problem here seems to be the assumption that the network operator is some evil bastard deliberately attempting to make life difficult for the users. That's not how it is (usually - and where it is, that network operator should be sent to some more appropriate occupation). Where problems arise is when the network operator is attempting to serve the needs of all the users, rather than one in particular, and that one believes that their needs should be supreme to all others, which is a very common scenario. Just because the user doesn't understand the reasons for what the network operator is doing (which may mean that better communication is needed) or simply doesn't like it because it interferes, doesn't mean that the user should be blindly overriding things (even if we're not about to say here that they can't). It most certainly doesn't mean that the user's system should be blindly overriding the network operator, without even asking the user's consent, on the assumption that "of course this way will be better". | However, in cases where the | network operator does have the right and the authority to restrict what | the users can do, that authority should be enforced at the appropriate | level, which in my opinion is 802.1X per-port physical access control, Sometimes that's entirely appropriate. But it certainly isn't always. Most times the network operator isn't trying to lock the user out (which is what this would be doing, it is a pretty blunt instrument) but to assist the user interoperate correctly with all the other users of the network. The network operator tends to be the one with the information required to make that happen. Users should have very good reasons before deciding to override that (and then should be prepared to have 802.1X type controls applied to them when it turns out they're wrong). kre From owner-zeroconf@merit.edu Thu Feb 6 09:39:07 2003 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 JAA19468 for ; Thu, 6 Feb 2003 09:39:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5D1EB9129F; Thu, 6 Feb 2003 09:42:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30C22912A1; Thu, 6 Feb 2003 09:42:35 -0500 (EST) 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 28E429129F for ; Thu, 6 Feb 2003 09:42:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0A9645DDFB; Thu, 6 Feb 2003 09:42:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 7C93C5DE52 for ; Thu, 6 Feb 2003 09:42:24 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h16Efhn07808; Thu, 6 Feb 2003 21:41:43 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h16EfGb14155; Thu, 6 Feb 2003 21:41:16 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: <200302061041.h16AfBQ25367@scv2.apple.com> References: <200302061041.h16AfBQ25367@scv2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Feb 2003 21:41:15 +0700 Message-ID: <14153.1044542475@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 6 Feb 2003 02:41:15 -0800 From: Stuart Cheshire Message-ID: <200302061041.h16AfBQ25367@scv2.apple.com> Most of what was in this message I have no great problems with, but this one ... | This is a common misconception. IPv4 link-local addresses DO NOT change | randomly at whim. "At whim" no - they change (as currently documented) whenever some random other node tells the node in question to change its addresses (which it does by simply claiming to own the address in question, of course). | IPv4 link-local addresses only change in the event of catastrophic | failure from which there is no other way to recover. This is clearly false - you also have addresses changing when ever a node enables a new interface, if the address (on some other interface) happens to be in use on the new one. That's not "catastrophic failure" by any definition. And nor should "I like that address you've got, so I'm taking it for myself" be really considered as a failure - it is the definition of the protocol that allows that (if nodes wouldn't renumber in that situation, communications might fail, but the other node wouldn't be able to take the address, and with it, perhaps any TCP connections that happened to be established at the time, if the interloper so desires). | Previously, IP hosts | typically had no recovery mechanism in the even of two hosts using the | same IP address, leaving the hosts useless until manual intervention | fixes them. Believe it or not, there are times where that is the best possible outcome. It isn't nice for this to happen, but "you can take over my identity, whenever you want" which is the current solution to this problem, is much worse. | In reality, IPv4 link-local are frequently *more* stable that other forms | of address. Every time I take my laptop from home to work and back it | gets a different DHCP address, yet it rarely (if ever) encounters a | conflict where it has to change its IPv4 link-local address. Actually, while it probably rarely encounters a conflict, its address *is* changing every time it moves links that way. It is just (I assume) managing to hide that from the applications (which in some cases really ought to be able to find out) by not changing the bit pattern that represents the address. But I can assure you that 169.254.1.1 on one link is not the same address as 169.254.1.1 on a different link. So, what you're describing is a situation where the address actually is changing, but you're deceiving the applications into thinking it has not. You'd almost certainly be better off not deceiving them, and deliberately picking a different bit pattern to represent the address when it has in fact changed, so that the applications can be aware of that. And often, they need to be aware. | > FWIW when 802.1d is enabled on the port I plug in my laptop at the | > office, the delay before the switch starts forwarding packets is 45 | > seconds. (I think the 802.1d spec indicates a default time of around | > 30 seconds.) So 10 seconds don't seem to do much good. | | I am also working with IEEE people to solve the spanning tree problem. I | don't think it is appropriate to put all of that protocol detail into an | IETF document. I suspect that you missed the point. That is, if the delay isn't going to be 45 seconds (which, counting from when the link became active, not from when LL assignment commenced) is the delay it really needs to be, then there's no point making it as long as 10 seconds, that does nothing at all when dealing with most popular 802.1d implementations. If you don't get an answer in 1 second, you won't get one in 10 either (though you might after 45, or perhaps 30). Or in other words, the algorithm (well, the timers that the algorithm uses) in section 2.2 are useless, and nodes might just as well use 2.3's timers always. If things are to be reliable in the presence of 802.1d devices, then the timers in 2.2 need to be made much longer (and be measured from the correct timebase, which isn't when the LL algorithm starts, it would be before that - sometimes very soon before, other times, much earlier, one example being when a node is selecting a new address because of a conflict that has appeared.) kre ps: I totally fail to understand why a multi-homed node would want to defend its LL address from interface 1, on interface 2 as well (section 3.3). I understand why it wants to have different LL addresses on each interface (in this OS model), but not why it would care whether some other host on link 1 happens to have the address this host assigned to its interface to link 2. The justification (3.3.1) is that someone might believe the host might get confused, and think it is trying to talk to itself - but that would have to be broken software, as the draft (correctly) requires the strong ES model for LL addresses, so one interface cannot directly communicate with another. So, that cannot be it. Ie: there is no potential for confusion here (a host that wants to talk to itself already has 127/8 available). From owner-zeroconf@merit.edu Thu Feb 6 10:15:39 2003 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 KAA20896 for ; Thu, 6 Feb 2003 10:15:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2FFD391203; Thu, 6 Feb 2003 10:19:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EDE7E91206; Thu, 6 Feb 2003 10:19:08 -0500 (EST) 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 C955291203 for ; Thu, 6 Feb 2003 10:19:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id B7D395DE68; Thu, 6 Feb 2003 10:19:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by segue.merit.edu (Postfix) with ESMTP id 9627B5DDCB for ; Thu, 6 Feb 2003 10:19:07 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18gnn1-0005Ee-00; Thu, 06 Feb 2003 07:18:11 -0800 Date: Thu, 6 Feb 2003 10:16:09 -0500 From: Keith Moore To: Robert Elz Cc: moore@cs.utk.edu, Erik.Guttman@Sun.COM, zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs Message-Id: <20030206101609.2497d1e2.moore@cs.utk.edu> In-Reply-To: <13641.1044531200@munnari.OZ.AU> References: <3E40FB68.1D4AF1B0@Sun.COM> <13641.1044531200@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 I generally agree with KRE here. My suggestion is that we agree to move forward with the current compromise (by default, implementations use a DHCP address in preference to an LL address) and that we agree that explicit indication from DHCP to enable LL, explicit indication from DHCP to disable LL, and protection of clients from denial-of-service due to spoofed DHCP, are all topics for future study - perhaps even by another group (since they all have to do with DHCP). I'll note that DHCP already has a worked-out solution for authentication, which, though not widely deployed, may at least serve as a starting point for those with the last concern. Keith > | REJECTED: > | This specification will define or require some additional mechanism > | to disable IPv4 LL autoconfiguration. > | > | WG chair assessment: > | This suggestion has been brought up in past last calls and again in > | this discussion. There again fails to be anything like working group > | consensus to support or introduce this feature. > > I'd agree with that assessment, but not with the conclusion. > > You could just as easily say that there fails to be anything like WG > consensus to exclude it. > > What this eventually comes down to is that the doc author writes whatever > he likes, and unless there's WG consensus to change it, it stays the way > it is written. > > That's not the way the IETF works (or it isn't the way it is supposed to > work). What's supposed to happen, is that the WG is supposed to reach > at least rough consensus that the document is acceptable, which does not > mean reaching a stage where there are no remaining issues upon which > consensus can be reached, so the rest just get left however they happen > to exist. > > One way or another, some kind of (rough) consensus needs to be reached > on this issue (note: we're not debating here whether an existing protocol > should be changed, where you can say "no consensus to make a change"). > > But this part > > | There are very clear > | and unchallenged technical arguments from Ted Lemon indicating that > | there are severe security considerations with coercive deactivation > | IPv4 LL autoconfiguration. > > is simply wrong. I certainly challenged Ted's arguments (several times). > Ted didn't even reply to my last message on the issue (whether that was due > to exhaustion, or finally realising his mistake, I can't tell). The > security considerations argument against this is simply bogus. That of > itself doesn't necessarily mean that there must necessarily be a way to tell > a device to not configure itself on a LAN at all, but using the bogy man of > "security" as if it were an unassailable argument against this is not going > to achieve anything. > > kre > From owner-zeroconf@merit.edu Thu Feb 6 11:02:44 2003 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 LAA23693 for ; Thu, 6 Feb 2003 11:02:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 76DC49120A; Thu, 6 Feb 2003 11:06:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 367C091213; Thu, 6 Feb 2003 11:06:13 -0500 (EST) 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 387D39120A for ; Thu, 6 Feb 2003 11:06:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 20A045DFDB; Thu, 6 Feb 2003 11:06:12 -0500 (EST) 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 A214C5DFD3 for ; Thu, 6 Feb 2003 11:06:11 -0500 (EST) 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 LAA11962 for ; Thu, 6 Feb 2003 11:06:10 -0500 (EST) 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 LAA18994 for ; Thu, 6 Feb 2003 11:06:10 -0500 (EST) Received: from [18.18.3.76] (WINDEL1.MIT.EDU [18.18.3.76]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA28649 for ; Thu, 6 Feb 2003 11:06:10 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 06 Feb 2003 11:06:08 -0500 Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <14153.1044542475@munnari.OZ.AU> 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 02/06/2003 09:41, "Robert Elz" wrote: > "At whim" no - they change (as currently documented) whenever some random > other node tells the node in question to change its addresses (which it > does by simply claiming to own the address in question, of course). No, they don't. They only give up their existing address when the new node insists on claiming that address, and won't seek another address. That is to prevent multiple nodes getting into an endless 'acquire and defend' loop, and spewing ARP packets with no way of stopping. It is a very logical way to deal with a broken device. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Feb 6 11:29:37 2003 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 LAA24785 for ; Thu, 6 Feb 2003 11:29:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2A022912A6; Thu, 6 Feb 2003 11:32:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE0E691213; Thu, 6 Feb 2003 11:32:50 -0500 (EST) 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 7D28791265 for ; Thu, 6 Feb 2003 11:31:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 03EDF5E02A; Thu, 6 Feb 2003 11:31:14 -0500 (EST) 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 74EEC5DE77 for ; Thu, 6 Feb 2003 11:31:13 -0500 (EST) 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 h16GVDI18639 for ; Thu, 6 Feb 2003 08:31:13 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Feb 2003 08:31:12 -0800 Received: from [17.219.194.13] (vpn-scv-x3-13.apple.com [17.219.194.13]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h16GVCs28838 for ; Thu, 6 Feb 2003 08:31:12 -0800 (PST) Message-Id: <200302061631.h16GVCs28838@scv1.apple.com> Subject: Lets all please try not to get stuck in rat-holes Date: Thu, 6 Feb 2003 08:31:17 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk I'd like to ask everyone to focus on sending only those messages that help us move towards a better understanding of the issues, and closer to completing the document. An unending back-and-forth exchange of line-by-line dissections of the previous message does not get us closer to completion. I also ask that people resist the urge to always get the last word in any exchange of messages. This also perpetuates fruitless threads that do not get us closer to completion. I wrote: >One of the goals I believe is important is creating reliable networking >that doesn't fail. Robert Elz wrote: >There is no such thing. I consider that we have both expressed our beliefs unambiguously. I will not respond to Robert's email with another line-by-line dissection picking out every point on which we disagree. I think Robert has made it clear what his views are, and I hope I have made my views clear too. Further tit-for-tat exchanges that only re-iterate why we (still) disagree do not contribute towards forward progress. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Feb 6 14:09:41 2003 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 OAA00604 for ; Thu, 6 Feb 2003 14:09:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0A65E91217; Thu, 6 Feb 2003 14:13:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C63869121A; Thu, 6 Feb 2003 14:13:11 -0500 (EST) 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 B601A91217 for ; Thu, 6 Feb 2003 14:13:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8D32F5DE99; Thu, 6 Feb 2003 14:13:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 754B85DE66 for ; Thu, 6 Feb 2003 14:13:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 1211114027; Thu, 6 Feb 2003 14:13:10 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 08111-03; Thu, 6 Feb 2003 14:13:09 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 6AB6A13FF4; Thu, 6 Feb 2003 14:13:09 -0500 (EST) Date: Thu, 6 Feb 2003 14:13:09 -0500 From: Keith Moore To: Stuart Cheshire Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: 6. Zeroconf Charter? Message-Id: <20030206141309.293ca549.moore@cs.utk.edu> In-Reply-To: <200302061032.h16AWHs01068@scv1.apple.com> References: <200302061032.h16AWHs01068@scv1.apple.com> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: cead5270d6d5b792c51863d970deb171ce260b52 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think it should be various obvious by now that the charter was poorly worded. It's one thing to make IP networking easier to use, quite another to design a way to configure IP addresses for hosts on isolated, ad hoc networks. v4LL can largely addresss the second problem, but the existence of v4LL makes it even more difficult to solve the first problem. It's very unfortuante that people have been trying to justify v4LL as a solution to the first problem. Keith > John Welch wrote that we want to, "make IP as easy, or easier to use > as Appletalk." > > Keith Moore replied: > > >This is not in this group's charter. If this group is trying to > >do that, it's violating its charter and it needs a mercy killing. > > I think that many of the people doing genuine work in this working > group believed that an important part of the group's charter was to > make networking easier to use, particularly in the case of small > networks used by inexpert users. > > If, as Keith asserts, making networking easier to use is a violation > of the group's charter, then perhaps that means the charter was poorly > worded and failed to clearly convey the true intent of the people who > created it. > > Perhaps the charter did not clearly state that one of the goals was a > solution that was both reliable and easy to use, but I do not believe > that the charter specifically prohibited it. From owner-zeroconf@merit.edu Thu Feb 6 14:10:57 2003 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 OAA00651 for ; Thu, 6 Feb 2003 14:10:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8843B9121A; Thu, 6 Feb 2003 14:14:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 520AE91265; Thu, 6 Feb 2003 14:14:26 -0500 (EST) 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 561119121A for ; Thu, 6 Feb 2003 14:14:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4281D5DE84; Thu, 6 Feb 2003 14:14:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id B4D995DEA8 for ; Thu, 6 Feb 2003 14:14:24 -0500 (EST) Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h16JE6P01747; Thu, 6 Feb 2003 13:14:07 -0600 (CST) Date: Thu, 6 Feb 2003 13:14:21 -0600 Subject: Re: WG consensus action: when to configure LL addrs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Erik.Guttman@Sun.COM, zeroconf@merit.edu To: Robert Elz From: Ted Lemon In-Reply-To: <13641.1044531200@munnari.OZ.AU> Message-Id: <3279F82D-3A07-11D7-A2AE-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Ted didn't even reply to my last message on the issue (whether that > was due > to exhaustion, or finally realising his mistake, I can't tell). It was due to the fact that it didn't seem productive. You simply don't agree with me about this. What am I supposed to do about that? Erik asked us to stop flaming endlessly about this stuff. I think it was a reasoable request. So I'd like to honor it. From owner-zeroconf@merit.edu Thu Feb 6 14:14:25 2003 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 OAA00762 for ; Thu, 6 Feb 2003 14:14:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 344E991267; Thu, 6 Feb 2003 14:17:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A35B91266; Thu, 6 Feb 2003 14:17:04 -0500 (EST) 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 E87A691265 for ; Thu, 6 Feb 2003 14:16:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0C47C5DE93; Thu, 6 Feb 2003 14:15:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id AC62A5DE84 for ; Thu, 6 Feb 2003 14:15:57 -0500 (EST) Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h16JFcP01751; Thu, 6 Feb 2003 13:15:38 -0600 (CST) Date: Thu, 6 Feb 2003 13:15:53 -0600 Subject: Re: WG consensus action: when to configure LL addrs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Mika Liljeberg , zeroconf@merit.edu To: Robert Elz From: Ted Lemon In-Reply-To: <13657.1044531611@munnari.OZ.AU> Message-Id: <694174FD-3A07-11D7-A2AE-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I'd be happy if a node sent a DHCPDISCOVER, got no reply in 0.2 > seconds, > sent another, again got no reply (perhaps just wait 0.1 seconds this > time) > and then, said "OK, I'll do the LL thing" - while continuing to look > for > a DHCP answer in parallel. Many DHCP servers wait a full second for the ping test to happen, so these timeframes aren't really going to help - functionally, this is equivalent to not waiting at all. From owner-zeroconf@merit.edu Thu Feb 6 14:29:32 2003 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 OAA01200 for ; Thu, 6 Feb 2003 14:29:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0B1CD91265; Thu, 6 Feb 2003 14:32:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAB9E91266; Thu, 6 Feb 2003 14:32:55 -0500 (EST) 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 3D83491265 for ; Thu, 6 Feb 2003 14:32:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1B1E35DE4E; Thu, 6 Feb 2003 14:32:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id F19E55DE3F for ; Thu, 6 Feb 2003 14:32:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id C308314031; Thu, 6 Feb 2003 14:32:33 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 10443-05; Thu, 6 Feb 2003 14:32:32 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id CD2A713FF4; Thu, 6 Feb 2003 14:32:32 -0500 (EST) Date: Thu, 6 Feb 2003 14:31:10 -0500 From: Keith Moore To: Stuart Cheshire Cc: moore@cs.utk.edu Message-Id: <20030206143110.55a9b950.moore@cs.utk.edu> In-Reply-To: <200302061631.h16GVCs28838@scv1.apple.com> References: <200302061631.h16GVCs28838@scv1.apple.com> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV Subject: Re: Lets all please try not to get stuck in rat-holes X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: f858097d098693e996bfbe0ee5189d39f86ec0b6 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I'd like to ask everyone to focus on sending only those messages that > help us move towards a better understanding of the issues, and closer > to completing the document. > > An unending back-and-forth exchange of line-by-line dissections of the > previous message does not get us closer to completion. Neither does repeating old and tired arguments that have been soundly refuted before. Neither does misrepresenting other people's views. > I also ask that people resist the urge to always get the last word in > any exchange of messages. Okay, but let it also be understood that when a co-chair posts several long messages to the group that are mostly repeats of old arguments, and specifically asks people to not respond in similar detail, that the resulting lack of response should not be taken as an indicator that his arguments were persuasive in the least. Keith From owner-zeroconf@merit.edu Thu Feb 6 14:39:28 2003 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 OAA01588 for ; Thu, 6 Feb 2003 14:39:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D107A91266; Thu, 6 Feb 2003 14:42:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9898D91269; Thu, 6 Feb 2003 14:42:58 -0500 (EST) 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 9ACA491266 for ; Thu, 6 Feb 2003 14:42:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 81E705DEA5; Thu, 6 Feb 2003 14:42:57 -0500 (EST) 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 2FBA55DEA4 for ; Thu, 6 Feb 2003 14:42:57 -0500 (EST) 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 MAA12838 for ; Thu, 6 Feb 2003 12:42:55 -0700 (MST) Received: from sun.com (vpn-129-159-0-48.EMEA.Sun.COM [129.159.0.48]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h16Jgrl02189 for ; Thu, 6 Feb 2003 20:42:53 +0100 (MET) Message-ID: <3E42BAA1.7050606@sun.com> Date: Thu, 06 Feb 2003 20:42:25 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: new issue tracking for ZEROCONF WG Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have transferred our existing issues into a tracking system based on the one used for the AAA WG. This will simplify our ability to keep focus on a single issue at a time and come to closure on it. Please see: http://www.spybeam.org/issues.html Is anything missing? Is anything misrepresented? ----------------------------------------------------------- Please submit new issues using the following template: Description of issue: (short single line description of issue) Submitter name: Your_Name_Here Submitter email address: Your_Email_Address_Here Date first submitted: Insert_Date_Here Reference: URL to e-mail describing problem, if available Comment type: ['T'echnical | 'E'ditorial] Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Section: Insert_Section_Number_Here Rationale/Explanation of issue: Lengthy description of problem Or, if you want to be a pal, submit them in html using the template at http://www.spybeam.org/issue-template.html ----------------------------------------------------------- I will start discussions to try to close some of these issues tomorrow. Best regards, Erik Guttman ZEROCONF wg cochair From owner-zeroconf@merit.edu Thu Feb 6 17:13:02 2003 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 RAA06564 for ; Thu, 6 Feb 2003 17:13:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0EE679126D; Thu, 6 Feb 2003 17:16:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9D0491271; Thu, 6 Feb 2003 17:16:29 -0500 (EST) 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 0FE059126D for ; Thu, 6 Feb 2003 17:16:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 096105DE43; Thu, 6 Feb 2003 17:15:44 -0500 (EST) 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 913055DD91 for ; Thu, 6 Feb 2003 17:15:43 -0500 (EST) 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 RAA19955 for ; Thu, 6 Feb 2003 17:15:43 -0500 (EST) 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 RAA11628 for ; Thu, 6 Feb 2003 17:13:18 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA00669 for ; Thu, 6 Feb 2003 17:08:21 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 06 Feb 2003 17:08:17 -0500 Subject: Re: 6. Zeroconf Charter? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030206141309.293ca549.moore@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 02/06/2003 14:13, "Keith Moore" wrote: > I think it should be various obvious by now that the charter was poorly > worded. It's one thing to make IP networking easier to use, quite > another to design a way to configure IP addresses for hosts on isolated, > ad hoc networks. v4LL can largely addresss the second problem, but the > existence of v4LL makes it even more difficult to solve the first > problem. > > It's very unfortuante that people have been trying to justify v4LL as a > solution to the first problem. Because it's the only way to get IPv4 to be usable by non-geeks inside of the next decade? IPv4 Networking is an overly complex mess that should have never been allowed to be used by anyone with less than two years of networking experience. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Feb 6 17:55:31 2003 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 RAA07758 for ; Thu, 6 Feb 2003 17:55:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1BB1B9127A; Thu, 6 Feb 2003 17:59:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF855912A1; Thu, 6 Feb 2003 17:59:00 -0500 (EST) 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 BF31A9127A for ; Thu, 6 Feb 2003 17:58:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id A3A1B5DE9F; Thu, 6 Feb 2003 17:58:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by segue.merit.edu (Postfix) with ESMTP id 837DB5DD8D for ; Thu, 6 Feb 2003 17:58:59 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18guyt-00051U-00; Thu, 06 Feb 2003 14:58:55 -0800 Date: Thu, 6 Feb 2003 17:56:52 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: 6. Zeroconf Charter? Message-Id: <20030206175652.55703ad5.moore@cs.utk.edu> In-Reply-To: References: <20030206141309.293ca549.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Thu, 06 Feb 2003 17:08:17 -0500 "John C. Welch" wrote: > On 02/06/2003 14:13, "Keith Moore" wrote: > > > I think it should be various obvious by now that the charter was poorly > > worded. It's one thing to make IP networking easier to use, quite > > another to design a way to configure IP addresses for hosts on isolated, > > ad hoc networks. v4LL can largely addresss the second problem, but the > > existence of v4LL makes it even more difficult to solve the first > > problem. > > > > It's very unfortuante that people have been trying to justify v4LL as a > > solution to the first problem. > > Because it's the only way to get IPv4 to be usable by non-geeks inside of > the next decade? It doesn't solve that problem, and trying to make it solve that problem makes IPv4 less usable for everyone. No matter whether you're a geek or not, using v4LL isn't going to get your computer talking to the web, it isn't going to get your email working, it isn't going to let you play distributed games, and it isn't going to let you use netmeeting. Now will you please stop the ridiculous claims? They're insulting to the whole group, and they're hindering progress. Keith From owner-zeroconf@merit.edu Thu Feb 6 18:06:27 2003 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 SAA08005 for ; Thu, 6 Feb 2003 18:06:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 626BC912A1; Thu, 6 Feb 2003 18:09:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38158912A5; Thu, 6 Feb 2003 18:09:58 -0500 (EST) 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 3448D912A1 for ; Thu, 6 Feb 2003 18:09:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1D29C5DE43; Thu, 6 Feb 2003 18:09:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from broadviewnet.net (ols.broadviewnet.net [64.115.0.8]) by segue.merit.edu (Postfix) with SMTP id 984F45DE24 for ; Thu, 6 Feb 2003 18:09:56 -0500 (EST) Received: (qmail 14760 invoked from network); 6 Feb 2003 23:08:55 -0000 Received: from unknown (HELO kabilla) (66.219.68.108) by smtp.broadviewnet.net with SMTP; 6 Feb 2003 23:08:55 -0000 Message-ID: <001701c2ce34$dcb16630$6401a8c0@kabilla> From: "Bill Rees" To: "Keith Moore" , "John C. Welch" Cc: , References: <20030206141309.293ca549.moore@cs.utk.edu> <20030206175652.55703ad5.moore@cs.utk.edu> Subject: Re: 6. Zeroconf Charter? Date: Thu, 6 Feb 2003 15:09:48 -0800 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.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Keith, I've gone back looking for your suggestions on a solution to this problem but I can't seem to find them. If I want to design a standard for automating networking for consumer devices so there's no configuration needed, what would this look like? bill ----- Original Message ----- > It doesn't solve that problem, and trying to make it solve that problem makes > IPv4 less usable for everyone. No matter whether you're a geek or not, using > v4LL isn't going to get your computer talking to the web, it isn't going to > get your email working, it isn't going to let you play distributed games, and > it isn't going to let you use netmeeting. > > Now will you please stop the ridiculous claims? They're insulting to the > whole group, and they're hindering progress. > > Keith > > From owner-zeroconf@merit.edu Thu Feb 6 18:18:44 2003 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 SAA08411 for ; Thu, 6 Feb 2003 18:18:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B58E391272; Thu, 6 Feb 2003 18:22:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83271912A5; Thu, 6 Feb 2003 18:22:07 -0500 (EST) 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 6D05B91272 for ; Thu, 6 Feb 2003 18:22:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5DA055DE78; Thu, 6 Feb 2003 18:22:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by segue.merit.edu (Postfix) with ESMTP id 3C94A5DD8D for ; Thu, 6 Feb 2003 18:22:06 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18gvLH-0003H0-00; Thu, 06 Feb 2003 15:22:03 -0800 Date: Thu, 6 Feb 2003 18:19:59 -0500 From: Keith Moore To: "Bill Rees" Cc: moore@cs.utk.edu, jwelch@MIT.EDU, zeroconf@merit.edu Subject: Re: 6. Zeroconf Charter? Message-Id: <20030206181959.03cc941c.moore@cs.utk.edu> In-Reply-To: <001701c2ce34$dcb16630$6401a8c0@kabilla> References: <20030206141309.293ca549.moore@cs.utk.edu> <20030206175652.55703ad5.moore@cs.utk.edu> <001701c2ce34$dcb16630$6401a8c0@kabilla> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > I've gone back looking for your suggestions on a solution to this > problem but I can't seem to find them. If I want to design a standard for > automating networking for consumer devices so there's no configuration > needed, what would this look like? As a first approximation which is more-or-less compatible with the installed base, DHCP (or maybe RARP/BOOTP) with v4LL used as a last resort. (either that or IPv6 - if you're taking the long view) If you want that mechanism to be less failure-prone, you need to tweak DHCP here and there to enable networks (and hosts) to more gracefully recover from DHCP server and network failures, and/or make some recommendations about DHCP server operation and configuration. If you want a more secure mechanism, there's no way to do this without distributing authentication information to the devices. But at least DHCP already has an authentication mechanism defined, which seems to be fairly optimal. Keith From owner-zeroconf@merit.edu Thu Feb 6 18:25:03 2003 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 SAA08579 for ; Thu, 6 Feb 2003 18:25:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 807BD912A8; Thu, 6 Feb 2003 18:28:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 41E26912B4; Thu, 6 Feb 2003 18:28:03 -0500 (EST) 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 424D4912A8 for ; Thu, 6 Feb 2003 18:27:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 288E65DE78; Thu, 6 Feb 2003 18:27:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 0D9615DE17 for ; Thu, 6 Feb 2003 18:27:57 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h16NSVQF004670; Fri, 7 Feb 2003 01:28:31 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h16NSTsH004669; Fri, 7 Feb 2003 01:28:29 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: new issue tracking for ZEROCONF WG From: Mika Liljeberg To: Erik Guttman Cc: zeroconf@merit.edu In-Reply-To: <3E42BAA1.7050606@sun.com> References: <3E42BAA1.7050606@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044574108.2625.35.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Feb 2003 01:28:29 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-02-06 at 21:42, Erik Guttman wrote: > Is anything missing? Is anything misrepresented? I propose to add the following issue. Section 2.6, paragraph 4 reads: If the destination address is a unicast address outside the 169.254/16 prefix, then the host SHOULD use an appropriate routable source address, if it has one. If the host does not have a routable source address, then it MAY choose to ARP for the destination address and then send its packet, with a link-local source IP address and a routable destination IP address, directly to its destination on the same physical link. The host MUST NOT send the packet to any router for forwarding. Problem: If the peer is not v4LL-compliant, it will not have an on-link route for the 169.254/16 prefix. Hence, if a v4LL node chooses to use its LL address as source address when sending packets to a non-compliant peer, response packets from the peer are likely be directed to the default router. Suggest rewording: If the destination address is a unicast address outside the 169.254/16 prefix, then the host MUST use an appropriate routable source address. MikaL From owner-zeroconf@merit.edu Thu Feb 6 19:00:00 2003 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 TAA09625 for ; Thu, 6 Feb 2003 19:00:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4FB1E912AA; Thu, 6 Feb 2003 19:02:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 13100912AB; Thu, 6 Feb 2003 19:01:59 -0500 (EST) 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 1DBFD912AA for ; Thu, 6 Feb 2003 19:01:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id F2E2B5DFF2; Thu, 6 Feb 2003 19:01:58 -0500 (EST) 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 77A545DEB4 for ; Thu, 6 Feb 2003 19:01:58 -0500 (EST) 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 h1701vI12207 for ; Thu, 6 Feb 2003 16:01:57 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Feb 2003 16:01:56 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h1701us03143 for ; Thu, 6 Feb 2003 16:01:56 -0800 (PST) Message-Id: <200302070001.h1701us03143@scv1.apple.com> Subject: Re: new issue tracking for ZEROCONF WG Date: Thu, 6 Feb 2003 16:01:54 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >I have transferred our existing issues into a tracking >system based on the one used for the AAA WG. This will >simplify our ability to keep focus on a single issue at >a time and come to closure on it. > >Please see: http://www.spybeam.org/issues.html > >Is anything missing? Is anything misrepresented? Thank you for setting up this tracking system Erik. You explained how to submit new issues, but what is the procedure for discussion of existing issues, to bring them to closure? Is there a convention for what goes in the subject line? Is the intention that the tracking system should include a brief summary of which people are on which side of the debate on each particular issue, in order to help ascertain whether or not the group has exhibited a rough consensus of opinion on each particular issue? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Feb 7 03:01:24 2003 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 DAA00882 for ; Fri, 7 Feb 2003 03:01:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9E93891217; Fri, 7 Feb 2003 03:04:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 768B69121A; Fri, 7 Feb 2003 03:04:55 -0500 (EST) 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 768DC91217 for ; Fri, 7 Feb 2003 03:04:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A3605E037; Fri, 7 Feb 2003 03:04:54 -0500 (EST) 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 C49CC5E032 for ; Fri, 7 Feb 2003 03:04:53 -0500 (EST) 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 AAA13709; Fri, 7 Feb 2003 00:04:51 -0800 (PST) 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 h1784ml06749; Fri, 7 Feb 2003 09:04:48 +0100 (MET) Date: Fri, 7 Feb 2003 09:04:48 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: new issue tracking for ZEROCONF WG In-Reply-To: <200302070001.h1701us03143@scv1.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Thu, 6 Feb 2003, Stuart Cheshire wrote: > >I have transferred our existing issues into a tracking > >system based on the one used for the AAA WG. This will > >simplify our ability to keep focus on a single issue at > >a time and come to closure on it. > > > >Please see: http://www.spybeam.org/issues.html > > > >Is anything missing? Is anything misrepresented? > > Thank you for setting up this tracking system Erik. > > You explained how to submit new issues, but what is the procedure for > discussion of existing issues, to bring them to closure? Is there a > convention for what goes in the subject line? Is the intention that the > tracking system should include a brief summary of which people are on > which side of the debate on each particular issue, in order to help > ascertain whether or not the group has exhibited a rough consensus of > opinion on each particular issue? The most important thing to do first is get the issues into the tracking system that we are going to discuss. We want to get rapid closure on remaining issues and not wander. We also need a way to ensure we do not cycle on issues which have already been resolved. We will not keep a list of proponents & opponents of suggestions. We are not voting nor working toward unanimity (we obviously won't come close in this WG!) Instead, we will make rough consensus calls and reject as many peripheral issues and initiatives as possible. We will take the issues, one at a time, and discuss them for a fixed period of time to reach closure. We need suggested text for all our issues before we can effectively discuss them. When discussing an issue, please put the issue number and title in the subject line, for instance Subject: Re: [LL1] Preferred use of configured to v4 LL address Subject: Text needed for [LL1]: Preferred use of configured to v4 LL address etc. For last calls on particular issues the subject line will look like: Subject: WG action - 1 week to discuss [LL1] And later Subject: WG action - [LL1] Accepted (or Rejected, etc.) Is everyone OK with this procedure? It worked for the AAA WG, which had many more documents and issues than we do. If we get snagged we can find out what that WG did with the particular issues list procedure as advice. Best regards, Erik From owner-zeroconf@merit.edu Fri Feb 7 05:31:15 2003 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 FAA04216 for ; Fri, 7 Feb 2003 05:31:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 18A1591257; Fri, 7 Feb 2003 05:34:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D87529125B; Fri, 7 Feb 2003 05:34:44 -0500 (EST) 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 B1F9891257 for ; Fri, 7 Feb 2003 05:34:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9548B5DDA4; Fri, 7 Feb 2003 05:34:43 -0500 (EST) 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 4AA485DD96 for ; Fri, 7 Feb 2003 05:34:43 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 095FC598F7 for ; Fri, 7 Feb 2003 10:34:40 +0000 (GMT) Message-ID: <00e801c2ce94$860f0c50$131010ac@aldebaran> From: "Philip Nye" To: References: <200302061024.h16AOfQ22841@scv2.apple.com> Subject: Re: 1. Engineering philosophy Date: Fri, 7 Feb 2003 10:34:41 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Stuart Cheshire" > > Attitude 1. The engineers creating the products should be willing to do a > lot of hard work to make the lives of the end users easier, more > pleasant, and more productive. Darn right they should. My conclusion is that we - as a group of engineers - have not done enough hard work. The evidence is that we are unable to agree what the zeroconf draft should say after lengthy debate which swings from side to side but rarely if ever forward. I certainly don't see many people here suggesting that end users should make engineers lives easier - what I do see is a lot of differing views of who the end users are and how they are best serrved. My experience as an engineer confronted with this sort of situation is generally that you need to stand back and question whether you are solving the right problem - or whether it needs solving at all. We have beaten this particular draft to within an inch of its life and if it eventually gets through it will as likely be from exhaustion and disenchantment as from real engineering agreement. The zeroconf WG seems to have a bad charter. Nearly all the sticking points are to do with how v4LL scales from the single link network to larger ones which means interaction with DHCP (on larger networks DHCP effectively zeroconfig networking from the users viewpoint). This highlights the fact that v4LL does not exist in isolation - oh for that luxury! I think we should look outside the current LL draft at the bigger picture. If this means revising the WG charter or making it part of the DHCP group or something then so be it - that is in the ultimate interests of the user. My belief is that what most people here recognise that the problem of how to get an IP address on a single link unmanaged network is not an isolated case but is one extreme of a space which extends through home networks with NAT right upto large complex heavily managed networks and also includes networks of embedded systems where user interfaces are few, far between and extremely restricted. On the one hand we have the "restrict LL" people who (rightly) point out that allowing v4LL to operate unrestricted on routed networks causes all sorts of trouble. On the other hand we have the "LL for all" people who (rightly) point out that waiting minutes for your system to go through some lengthy and unreliable configuration and checking process before finally reluctantly falling back to a LL only address is unacceptable. So I suggest that the "restrict LL" camp look at how they can address the problems of unreliability and unacceptable configuration time, while the "LL for all" camp look at how they can answer the issues of broken applications and lack of proper functionality as the network scales. Simply denying the problems isn't going to work and it is pretty obvious that no simple definition of when to turn LL on or off is going to either without some change in other areas. Do a bit more hard work instead of bickering over the work that has been done already which obviously doesn't cut it! Philip From owner-zeroconf@merit.edu Fri Feb 7 05:50:46 2003 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 FAA04596 for ; Fri, 7 Feb 2003 05:50:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 87D179125B; Fri, 7 Feb 2003 05:54:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F6179125C; Fri, 7 Feb 2003 05:54:17 -0500 (EST) 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 2F0D59125B for ; Fri, 7 Feb 2003 05:54:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 12E4B5DF02; Fri, 7 Feb 2003 05:54:16 -0500 (EST) 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 8E2905DEF1 for ; Fri, 7 Feb 2003 05:54:15 -0500 (EST) 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 CAA12347; Fri, 7 Feb 2003 02:54:13 -0800 (PST) Received: from sun.com (vpn-129-159-0-23.EMEA.Sun.COM [129.159.0.23]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h17AsAl12948; Fri, 7 Feb 2003 11:54:11 +0100 (MET) Message-ID: <3E439034.1090006@sun.com> Date: Fri, 07 Feb 2003 11:53:40 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: New issue [LL19] If possible do not use v4LL source address to non-v4LL destinations References: <3E42BAA1.7050606@sun.com> <1044574108.2625.35.camel@devil> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mika, I have entered this as issue LL19, see http://www.spybeam.org/ll19.html Please review it. It would help if you supplied the issue in the form of the template, as I had to guess the priority and some other fields. Thanks, Erik Mika Liljeberg wrote: > On Thu, 2003-02-06 at 21:42, Erik Guttman wrote: > >>Is anything missing? Is anything misrepresented? > > > I propose to add the following issue. > > Section 2.6, paragraph 4 reads: > > If the destination address is a unicast address outside the > 169.254/16 prefix, then the host SHOULD use an appropriate routable > source address, if it has one. If the host does not have a routable > source address, then it MAY choose to ARP for the destination address > and then send its packet, with a link-local source IP address and a > routable destination IP address, directly to its destination on the > same physical link. The host MUST NOT send the packet to any router > for forwarding. > > Problem: If the peer is not v4LL-compliant, it will not have an on-link > route for the 169.254/16 prefix. Hence, if a v4LL node chooses to use > its LL address as source address when sending packets to a non-compliant > peer, response packets from the peer are likely be directed to the > default router. > > Suggest rewording: > > If the destination address is a unicast address outside the > 169.254/16 prefix, then the host MUST use an appropriate routable > source address. > > MikaL > From owner-zeroconf@merit.edu Fri Feb 7 06:21:27 2003 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 GAA05325 for ; Fri, 7 Feb 2003 06:21:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 98A6D9125E; Fri, 7 Feb 2003 06:24:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6237F91261; Fri, 7 Feb 2003 06:24:58 -0500 (EST) 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 5841A9125E for ; Fri, 7 Feb 2003 06:24:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F3FC5E02A; Fri, 7 Feb 2003 06:24:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id E3A125DF09 for ; Fri, 7 Feb 2003 06:24:25 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h17BNln24483; Fri, 7 Feb 2003 18:23:47 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h17BNTb18197; Fri, 7 Feb 2003 18:23:32 +0700 (ICT) From: Robert Elz To: Ted Lemon Cc: Erik.Guttman@Sun.COM, zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs In-Reply-To: <3279F82D-3A07-11D7-A2AE-00039367340A@nominum.com> References: <3279F82D-3A07-11D7-A2AE-00039367340A@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Feb 2003 18:23:29 +0700 Message-ID: <18195.1044617009@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 6 Feb 2003 13:14:21 -0600 From: Ted Lemon Message-ID: <3279F82D-3A07-11D7-A2AE-00039367340A@nominum.com> | It was due to the fact that it didn't seem productive. You simply | don't agree with me about this. What am I supposed to do about that? We should probably attempt to work out just what it is that one of us is not understanding about the other's position (argument, belief) that has led to this. This isn't an issue where the arguments are just based upon religious views (on either side), but one of us seems to be seeing something that isn't being communicated very well to the other. | Erik asked us to stop flaming endlessly about this stuff. I think it | was a reasoable request. So I'd like to honor it. I don't think that either of us was "flaming" on this particular issue. In general, I like to work these things out in public, so everyone (and the archives) have a record of just what happened, and why (and that's true when when it means that the outcome is that it becomes obvious that I had no idea what I was talking about). But if you would like to explain to me what about the last message I sent was wrong in your opinion, I'd be happy to receive it, even in private mail. kre From owner-zeroconf@merit.edu Fri Feb 7 06:32:35 2003 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 GAA05544 for ; Fri, 7 Feb 2003 06:32:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D925991263; Fri, 7 Feb 2003 06:36:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 989E791265; Fri, 7 Feb 2003 06:36:05 -0500 (EST) 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 8E99B91263 for ; Fri, 7 Feb 2003 06:36:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7D6845E037; Fri, 7 Feb 2003 06:36:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id B692C5DD96 for ; Fri, 7 Feb 2003 06:35:58 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h17BZan29325; Fri, 7 Feb 2003 18:35:37 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h17BZXb18240; Fri, 7 Feb 2003 18:35:33 +0700 (ICT) From: Robert Elz To: Ted Lemon Cc: Mika Liljeberg , zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs In-Reply-To: <694174FD-3A07-11D7-A2AE-00039367340A@nominum.com> References: <694174FD-3A07-11D7-A2AE-00039367340A@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Feb 2003 18:35:33 +0700 Message-ID: <18238.1044617733@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 6 Feb 2003 13:15:53 -0600 From: Ted Lemon Message-ID: <694174FD-3A07-11D7-A2AE-00039367340A@nominum.com> | Many DHCP servers wait a full second for the ping test to happen, Yes, I know that. | so these timeframes aren't really going to help - functionally, this is | equivalent to not waiting at all. Not quite. But if you believe that waiting a very short while to see if a DHCP response appears is functionally no different to not waiting, then there can't really be an objection to the delay. Why it makes a difference, is that (using the short timer figures from 2.3 of the draft) it takes just about a second for the LL ARP probe cycle to complete. That is, if it is started at just the same time as the DHCP query, and there's a DHCP server that does wait a second (plus overheads) for a ping response (to fail to arrive) then with the extra 0.3 second or so delay, it is still likely that the DHCP answer will be available before the node has concluded that its LL address is really free (so the node can simply abandon its LL allocation in progress, and use the DHCP provided address). On the other hand, without that extra delay, the LL ARP probe is likely to finish before this kind of DHCP server will ever reply, so the node will always end up picking a LL address, using it for some fraction of a second (just enough time to get started) and then have that overridden by the DHCP answer. In either case, either a "fast" (sloppy if you like) DHCP server, in which case the node would be able to avoid even starting the LL ARP probes, or with a "slow" (safe if you like) DHCP server, it will at least normally avoid the LL address allocation completing. Of course, for any node using the 8-10 second timers for LL allocation, none of this really makes much difference, with that amount of delay (as useless as it actually is for claimed purpose), the node may as well wait several seconds for a DHCP answer before starting, it is only a small (percentage) increase in the overall delay. kre From owner-zeroconf@merit.edu Fri Feb 7 07:14:33 2003 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 HAA06542 for ; Fri, 7 Feb 2003 07:14:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4723C91265; Fri, 7 Feb 2003 07:18:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0AB3391266; Fri, 7 Feb 2003 07:18:02 -0500 (EST) 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 3B57A91265 for ; Fri, 7 Feb 2003 07:16:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id E621A5DE86; Fri, 7 Feb 2003 07:16:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id D4ED05DDC5 for ; Fri, 7 Feb 2003 07:16:35 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h17CF0n14448; Fri, 7 Feb 2003 19:15:00 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h17CEdb18289; Fri, 7 Feb 2003 19:14:39 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: new issue tracking for ZEROCONF WG In-Reply-To: <3E42BAA1.7050606@sun.com> References: <3E42BAA1.7050606@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Feb 2003 19:14:39 +0700 Message-ID: <18287.1044620079@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 06 Feb 2003 20:42:25 +0100 From: Erik Guttman Message-ID: <3E42BAA1.7050606@sun.com> | I have transferred our existing issues into a tracking | system based on the one used for the AAA WG. This will | simplify our ability to keep focus on a single issue at | a time and come to closure on it. | | Please see: http://www.spybeam.org/issues.html | | Is anything missing? Is anything misrepresented? Missing, perhaps in a different sense than you meant there. Sometimes there are multiple suggestions for changes, your pages only ever list one. While just being able to say yes/no to one specific change is an attractive way to move forward quickly, it can also make it very hard to achieve a good result, when the best outcome is perhaps neither to accept or reject a suggested change, but to do something different entirely. For example, to take one of the (currently) less contentious issues. LL3: TTL=255 on send, check on receive? [Aside: what you have Thomas Narten saying there doesn't look to be even slightly related to the issue - looks to be a cut/paste or include wrong file error of some kind]. The suggested resolution there is almost a do nothing (just soften the wording a little) Others have suggested requiring TTL=1 on send (that isn't mentioned at all). My suggestion is (was) to simply rip out all mention of TTL's from the LL draft completely (with the possible exception of a note documenting what the current implementations do, so future implementors can know with what they're dealing). This message isn't intended as an attempt to debate those - rather to ask what is the preferred method of dealing with this? You could just add multiple possible resolutions (LL3a LL3b ...) to the page, then they could be discussed, ones that find no favour marked "dead" and eventually (we hope) there would be one left. In this case, one possible resolution should be added to all issues, which would be "change nothing". Or, we could just make every new suggested resolution a new issue, so we'd end up (in this case) with at least 3 issues related to setting the TTL on sending, with interdependencies, in that only one can possibly be accepted. In that case, the issues page would need links between the related issues I think. If these (multiple possible resolutions) should be treated as new issues, then I'll send some new ones in... On the other hand, if adding multiple possible resolutions to the issues is better (I think I prefer that one if it is possible easily - it makes comparing the various proposals easier) then please indicate how extra/different resolution suggestions should be sent. kre From owner-zeroconf@merit.edu Fri Feb 7 09:02:30 2003 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 JAA11648 for ; Fri, 7 Feb 2003 09:02:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 26BA99125B; Fri, 7 Feb 2003 09:06:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E48669125E; Fri, 7 Feb 2003 09:06:01 -0500 (EST) 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 ABC709125B for ; Fri, 7 Feb 2003 09:06:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9336A5DEFC; Fri, 7 Feb 2003 09:06:00 -0500 (EST) 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 422E75DDDE for ; Fri, 7 Feb 2003 09:06:00 -0500 (EST) 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 HAA01950; Fri, 7 Feb 2003 07:05:55 -0700 (MST) 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 h17E5ql19901; Fri, 7 Feb 2003 15:05:52 +0100 (MET) Date: Fri, 7 Feb 2003 15:05:53 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Robert Elz Cc: Erik Guttman , zeroconf@merit.edu Subject: Re: new issue tracking for ZEROCONF WG In-Reply-To: <18287.1044620079@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Robert, On Fri, 7 Feb 2003, Robert Elz wrote: > | I have transferred our existing issues into a tracking > | system based on the one used for the AAA WG. This will > | simplify our ability to keep focus on a single issue at > | a time and come to closure on it. > | > | Please see: http://www.spybeam.org/issues.html > | > | Is anything missing? Is anything misrepresented? > > Missing, perhaps in a different sense than you meant there. Sometimes > there are multiple suggestions for changes, your pages only ever list one. We must present all offered alternatives so we can pick one. > While just being able to say yes/no to one specific change is an attractive > way to move forward quickly, it can also make it very hard to achieve a > good result, when the best outcome is perhaps neither to accept or reject > a suggested change, but to do something different entirely. Well that is why we are going to *discuss* each issue not just rotate thumbs. > For example, to take one of the (currently) less contentious issues. > LL3: TTL=255 on send, check on receive? > > [Aside: what you have Thomas Narten saying there doesn't look to be even > slightly related to the issue - looks to be a cut/paste or include wrong > file error of some kind]. Thanks for pointing this out. I will find the proper point to cite for this issue, when Thomas launched this discussion on the list. > The suggested resolution there is almost a do nothing (just soften the > wording a little) > > Others have suggested requiring TTL=1 on send (that isn't mentioned at all). I suggest you file a new issue or suggest some replacement text in this case. I am making every effort to be fair, inclusive and represent all the views in the WG. > My suggestion is (was) to simply rip out all mention of TTL's from the LL > draft completely (with the possible exception of a note documenting what > the current implementations do, so future implementors can know with what > they're dealing). > > This message isn't intended as an attempt to debate those - rather to > ask what is the preferred method of dealing with this? > > You could just add multiple possible resolutions (LL3a LL3b ...) to the > page, then they could be discussed, ones that find no favour marked "dead" > and eventually (we hope) there would be one left. In this case, one > possible resolution should be added to all issues, which would be "change > nothing". I agree. > Or, we could just make every new suggested resolution a new issue, so we'd > end up (in this case) with at least 3 issues related to setting the TTL > on sending, with interdependencies, in that only one can possibly be > accepted. In that case, the issues page would need links between the > related issues I think. > > If these (multiple possible resolutions) should be treated as new issues, > then I'll send some new ones in... On the other hand, if adding multiple > possible resolutions to the issues is better (I think I prefer that one if > it is possible easily - it makes comparing the various proposals easier) > then please indicate how extra/different resolution suggestions should be > sent. I agree with you. Let's keep it to one resolution per issue. The danger is that we will have issues for which resolutions do not clearly compete - that the scope of the problems they are solving will not be coextensive. If possible, let's *refer to the problem statement* in another issue and just offer a different resolution. This will minimize confusion. Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n N1 Installation and Provisioning cell: +49 172 865 5497 Sun Microsystems pager: 01728655497@d2-message.de From owner-zeroconf@merit.edu Fri Feb 7 10:18:28 2003 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 KAA13209 for ; Fri, 7 Feb 2003 10:18:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 152329125B; Fri, 7 Feb 2003 10:22:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6AA69125E; Fri, 7 Feb 2003 10:21:59 -0500 (EST) 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 681F09125B for ; Fri, 7 Feb 2003 10:21:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 894C15E03D; Fri, 7 Feb 2003 10:21:57 -0500 (EST) 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 1AF415E02D for ; Fri, 7 Feb 2003 10:21:57 -0500 (EST) 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 KAA00269 for ; Fri, 7 Feb 2003 10:21:56 -0500 (EST) 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 KAA23867 for ; Fri, 7 Feb 2003 10:21:56 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA20626 for ; Fri, 7 Feb 2003 10:21:55 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 07 Feb 2003 10:21:53 -0500 Subject: Re: 1. Engineering philosophy From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <00e801c2ce94$860f0c50$131010ac@aldebaran> 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 02/07/2003 05:34, "Philip Nye" wrote: > The zeroconf WG seems to have a bad charter. Nearly all the sticking points > are to do with how v4LL scales from the single link network to larger ones > which means interaction with DHCP (on larger networks DHCP effectively > zeroconfig networking from the users viewpoint). This highlights the fact > that v4LL does not exist in isolation - oh for that luxury! I think we > should look outside the current LL draft at the bigger picture. If this > means revising the WG charter or making it part of the DHCP group or > something then so be it - that is in the ultimate interests of the user. > > My belief is that what most people here recognise that the problem of how to > get an IP address on a single link unmanaged network is not an isolated case > but is one extreme of a space which extends through home networks with NAT > right upto large complex heavily managed networks and also includes networks > of embedded systems where user interfaces are few, far between and extremely > restricted. I don't think you can solve this problem in a way that makes everyone happy, and maybe we shouldn't try. But what we can do is make incorporating some standard form of IP in any device that talks to another device without requiring a third party configuration server dead simple. You cannot do this with DHCP. We can argue until the cows come home, but there is only one way to *guarantee* the presence of a DHCP server and that is to have *everything* be a DHCP server. Since DHCP turns into a stinking mess when this happens, especially when you have dozens of DHCP servers coming up and down, this will never be a good solution. As well, regardless of personal feelings towards NAT, it is here, and it is widespread, and we have to deal with this as well. We don't have to make it work, we just have to acknowledge that any standard we define will, not may, but *WILL* be used in a NAT environment. It is far better to deal with this as adults, rather than "I don't like it so I'm not dealing with it" manner. Finally, we need to make this easy to use. Yes I know, a good percentage of the people on this list are still angry about common folk on the Public internet. Oh well, they pay the bills. We cannot require that every single device using IP have a permanent global address. There are emotional reasons, and monetary reasons this won't happen. Under IPv4, there are numerical reasons this simply cannot happen. So we're kind of stuck with IPv4LL. Now, some would like to guarantee this WG accomplishes nothing until IPv6 makes this all moot. But the world has work to do that cannot wait the 4-7 years it will require for this to happen. So now, we have to deal with how to avoid harm. How not to break what is there. First, we cannot completely avoid harm. All changes break stuff. So at best we minimize it. I'm not going to address the security boogeyman, I have yet to see verifiable, repeatable evidence that v4LL introduces any threats that aren't there now. A properly run and secured network will have people who deal with this, one that isn't won't, and no amount of standard verbiage will compensate for the latter. So when to use v4LL? It's pretty obvious that you want to use it in cases where you don't have any other sort of managed network. That's obvious. But what about managed networks? There's some complications either way. If you use DHCP, then implementation details *are required*. You cannot simply say , "DHCP disables v4LL". That's dumb, and any third year EE student will show you why. If you have a manually set address, then automatically disabling v4LL is even dumber, because now you will be unable to join an ad hoc network without reconfiguring your machine to use DHCP, and hoping that there isn't a DHCP server nearby, wired or otherwise. So the other option is to leave v4LL active all the time. There are of course problems with this as well, but not as many as people think, or try to make it out to be. First of all, multiple addresses per interface are a no-brainer. Been done for years, everyone knows how to deal with this. That by itself is not a major issue. So the problem then is what do you do with an address that is far more limited in scope than a 'standard' address. That is going to be the problem to solve right there. So now, from the people on the list who do IP stack implementation and programming, how would you go about solving that problem? (I'm limiting this to them, because they have far more of a clue than the rest of us who never have, or no longer do that sort of work. Now, the next issue this raises is how to keep v4LL traffic off your network when you don't want it there. I'm going to agree with Keith here and say that there are times when you need to be able to control a network at that level. However, this problem is not universal. If you have a switch that can filter traffic, then you simply block v4LL on your network, and you're done. Wireless can be a little harder here, but again, a firmware update can add that capability to a wireless router, and if a given vendor can't or won't offer that capability, then the market will deal with them appropriately, (via Adam Smith's lesser well known invisible middle finger.) *BUT* you do have the issue of k-12 schools, small businesses, etc using older equipment that doesn't have this feature, and may never have this feature, and they can't upgrade anytime soon due to budget issues. (If you don't believe me, check out Massachusetts budget cuts these days...k-12 ain't got money for squat!) So, switch blocking isn't an option. But, there is a way to do this, and that's with a manual setting. Yes, I know it's tasteless, but it's needed. Now, I don't mean manual as in 'requires physical contact with the keyboard'. I mean manual in the sense that ifconfig settings, top, kill, ping, etc. are manual. This switch would have to be set by default to allow v4LL. It doesn't have to be even an traditional switch. For example, on Mac OS X 10.2, the switch could be *not* setting a Rendezvous name, or better yet, a config option in Directory Services. Even better, a switch to ifconfig. But there is another problem, and that is laptops. Desktops are easy, they don't move much. Laptops are another issue. So, you treat them different, and you put the v4LL switch in an obvious place in the UI. (Before anyone starts about onerous requirements to the vendor, they have special UI features for laptops NOW...oddly enough my tower doesn't seem to have a way to configure power consumption on battery power.) Stuart's right about one thing, v4LL has to be easily available. Keith's right about one thing, there has to be a way to turn it off when needed. You cannot rely on an automatic network configuration method, because manual addressing will blow it all to hell. As well, in the case of a rogue DHCP server, you need a way to override the DHCP cutoff for v4LL. I'll bet a bottle of Guiness right now that even if you manage to force the issue of automatic restriction *only* for v4LL, it will be either so roundly ignored, or a manual setting will be included *anyway*, because it's needed, that it will end up being part of the standard. Oh, on the issue of accidentally routing v4LL addresses...Cisco and the rest can handle that with a firmware update, so that's not a big deal at all. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Feb 7 10:44:55 2003 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 KAA13864 for ; Fri, 7 Feb 2003 10:44:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4B1609121D; Fri, 7 Feb 2003 10:48:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 211159125E; Fri, 7 Feb 2003 10:48:16 -0500 (EST) 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 F28569121D for ; Fri, 7 Feb 2003 10:48:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id DE65A5E040; Fri, 7 Feb 2003 10:48:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id C56A65DDAA for ; Fri, 7 Feb 2003 10:48:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 83245140A6; Fri, 7 Feb 2003 10:48:11 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 20502-04; Fri, 7 Feb 2003 10:48:11 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id E61F41409C; Fri, 7 Feb 2003 10:48:10 -0500 (EST) Date: Fri, 7 Feb 2003 10:48:10 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: 1. Engineering philosophy Message-Id: <20030207104810.02fdb8dc.moore@cs.utk.edu> In-Reply-To: References: <00e801c2ce94$860f0c50$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 0d76d16ac6315890d986857de13b97d6984e6d49 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit John, Face it, v4LL is dysfunctional. It's better than nothing for ad hoc, disconnected networks. But the cases where it will work better on connected networks are so marginal that the complexity that results with trying to deal with a mixture of v4LL and routable addresses is simply not worth the gain. Keith From owner-zeroconf@merit.edu Fri Feb 7 10:59:33 2003 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 KAA14108 for ; Fri, 7 Feb 2003 10:59:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7DBC69125E; Fri, 7 Feb 2003 11:03:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA93C91263; Fri, 7 Feb 2003 11:03:02 -0500 (EST) 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 4668E9125E for ; Fri, 7 Feb 2003 11:01:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 08DC35E046; Fri, 7 Feb 2003 11:01:18 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 7CED05DE40 for ; Fri, 7 Feb 2003 11:01:16 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h17G14n06041; Fri, 7 Feb 2003 23:01:04 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h17G0pb19060; Fri, 7 Feb 2003 23:00:51 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: new issue tracking for ZEROCONF WG In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Feb 2003 23:00:51 +0700 Message-ID: <19058.1044633651@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 7 Feb 2003 15:05:53 +0100 (CET) From: Erik Guttman Message-ID: | Thanks for pointing this out. I will find the proper point to cite for | this issue, when Thomas launched this discussion on the list. When you're fixing that, you might also want to fix the HTML page titles - all of them claim to be LL1 (this is just more trivia). | > Others have suggested requiring TTL=1 on send | | I suggest you file a new issue or suggest some replacement text in this | case. That one I will leave to someone who supports that approach (if there are any left). | I am making every effort to be fair, inclusive and represent | all the views in the WG. Please don't misinterpret my message - I was just trying to ask a question on which method you wanted to use to get this kind of issue (multiple possible outcomes, of which only one can possibly be adopted) handled on your web pages. The TTL case I just picked as an easy (and I hoped, non-inflamatory) example. | I agree with you. I'm not sure what you're agreeing with, because I was just asking a question, but ... | Let's keep it to one resolution per issue. Fine, that's an answer that will work. | The | danger is that we will have issues for which resolutions do not clearly | compete - that the scope of the problems they are solving will not be | coextensive. Yes, might happen. | If possible, let's *refer to the problem statement* in | another issue and just offer a different resolution. This will minimize | confusion. OK, will do that. kre From owner-zeroconf@merit.edu Fri Feb 7 11:29:42 2003 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 LAA14744 for ; Fri, 7 Feb 2003 11:29:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C8B0D9121D; Fri, 7 Feb 2003 11:33:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E2EE9125B; Fri, 7 Feb 2003 11:33:03 -0500 (EST) 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 9F6DF9121D for ; Fri, 7 Feb 2003 11:32:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 779495E043; Fri, 7 Feb 2003 11:32:02 -0500 (EST) 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 01CA95DEFC for ; Fri, 7 Feb 2003 11:32:01 -0500 (EST) 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 LAA08313 for ; Fri, 7 Feb 2003 11:32:01 -0500 (EST) 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 LAA08103 for ; Fri, 7 Feb 2003 11:32:01 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA26751 for ; Fri, 7 Feb 2003 11:32:00 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 07 Feb 2003 11:31:58 -0500 Subject: Re: 1. Engineering philosophy From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030207104810.02fdb8dc.moore@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 02/07/2003 10:48, "Keith Moore" wrote: > Face it, v4LL is dysfunctional. It's better than nothing for ad hoc, > disconnected networks. But the cases where it will work better on > connected networks are so marginal that the complexity that results with > trying to deal with a mixture of v4LL and routable addresses is simply > not worth the gain. I disagree...it's been here for years, and with things like bluetooth creating things that won't need or want a global address, there's a need to make it work correctly with larger networks. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Feb 7 11:54:48 2003 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 LAA15357 for ; Fri, 7 Feb 2003 11:54:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B97959121D; Fri, 7 Feb 2003 11:58:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 855039125B; Fri, 7 Feb 2003 11:58:18 -0500 (EST) 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 854109121D for ; Fri, 7 Feb 2003 11:58:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 69B295DEE6; Fri, 7 Feb 2003 11:58:17 -0500 (EST) 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 359E25DEEC for ; Fri, 7 Feb 2003 11:58:17 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id D95055990A for ; Fri, 7 Feb 2003 16:58:19 +0000 (GMT) Message-ID: <031b01c2ceca$1e4d6720$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf" References: Subject: Re: 1. Engineering philosophy Date: Fri, 7 Feb 2003 16:58:20 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "John C. Welch" > > On 02/07/2003 10:48, "Keith Moore" wrote: > > > Face it, v4LL is dysfunctional. It's better than nothing for ad hoc, > > disconnected networks... > > I disagree... ...there's a need to > make it work correctly with larger networks. Will you two just stop it! You are both right - how can you disagree? You both agree that v4LL fulfills some need and you both agree that it has problems and seem to recognise what they are even if you give them differing relative importance. So go and work out how to fix them then come back and tell us all about it. Philip From owner-zeroconf@merit.edu Fri Feb 7 12:18:59 2003 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 MAA15933 for ; Fri, 7 Feb 2003 12:18:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C33979121D; Fri, 7 Feb 2003 12:22:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9726E91222; Fri, 7 Feb 2003 12:22:30 -0500 (EST) 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 6A77D9121D for ; Fri, 7 Feb 2003 12:22:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 508F55DEE6; Fri, 7 Feb 2003 12:22:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id E9E825DDD4 for ; Fri, 7 Feb 2003 12:22:27 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h17HN1QF009011; Fri, 7 Feb 2003 19:23:02 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h17HMwEx009010; Fri, 7 Feb 2003 19:22:58 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: New issue [LL19] If possible do not use v4LL source address to non-v4LL destinations From: Mika Liljeberg To: Erik Guttman Cc: zeroconf@merit.edu In-Reply-To: <3E439034.1090006@sun.com> References: <3E42BAA1.7050606@sun.com> <1044574108.2625.35.camel@devil> <3E439034.1090006@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044638577.8765.12.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Feb 2003 19:22:57 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-02-07 at 12:53, Erik Guttman wrote: > I have entered this as issue LL19, see http://www.spybeam.org/ll19.html > Please review it. It would help if you supplied the issue in the form > of the template, as I had to guess the priority and some other fields. Thanks Erik, I meant to write the template info but I forgot, sorry about that. Please update the following fields: Description of Issue: Do not use v4LL source address to non-v4LL destinations Rationale: Conversing with non-v4LL nodes using a v4LL source address causes response packets to escape the link. Priority: S The other fields are fine. Regards, MikaL From owner-zeroconf@merit.edu Fri Feb 7 12:36:43 2003 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 MAA16300 for ; Fri, 7 Feb 2003 12:36:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CD7C391222; Fri, 7 Feb 2003 12:40:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F59C9125B; Fri, 7 Feb 2003 12:40:13 -0500 (EST) 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 7113F91222 for ; Fri, 7 Feb 2003 12:40:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1432E5DF1A; Fri, 7 Feb 2003 12:40:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 08B335DF0B for ; Fri, 7 Feb 2003 12:40:11 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h17HekQF009106; Fri, 7 Feb 2003 19:40:46 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h17Hehoh009105; Fri, 7 Feb 2003 19:40:43 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Robert Elz Cc: Ted Lemon , zeroconf@merit.edu In-Reply-To: <18238.1044617733@munnari.OZ.AU> References: <694174FD-3A07-11D7-A2AE-00039367340A@nominum.com> <18238.1044617733@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044639642.8765.21.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 07 Feb 2003 19:40:43 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-02-07 at 13:35, Robert Elz wrote: > Date: Thu, 6 Feb 2003 13:15:53 -0600 > From: Ted Lemon > Message-ID: <694174FD-3A07-11D7-A2AE-00039367340A@nominum.com> > > | Many DHCP servers wait a full second for the ping test to happen, > > Yes, I know that. > > | so these timeframes aren't really going to help - functionally, this is > | equivalent to not waiting at all. > > Not quite. But if you believe that waiting a very short while to see > if a DHCP response appears is functionally no different to not waiting, > then there can't really be an objection to the delay. >From the user perspective waiting just a short period is certainly better than waiting for the DHCP client to give up. However, this still creates a dependency between the DHCP implementation and the v4LL implementation, which I would like to avoid. These could be completely separated in the implementation architecture. If it is ok to run DHCP and v4LL configuration in parallel in a staggered fashion, it must be ok to run them in parallel without any timing interdependencies. Another (minor) point is that certain wireless links have latencies substantially higher than 0.1 seconds (e.g. 0.5..1 seconds for Bluetooth). Any such devices would have to wait for somewhat longer in order to discover a DHCP server. MikaL From owner-zeroconf@merit.edu Fri Feb 7 12:48:38 2003 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 MAA16552 for ; Fri, 7 Feb 2003 12:48:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C16849121D; Fri, 7 Feb 2003 12:52:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 975D39125B; Fri, 7 Feb 2003 12:52:08 -0500 (EST) 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 871B89121D for ; Fri, 7 Feb 2003 12:52:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 60A385DF0B; Fri, 7 Feb 2003 12:52:07 -0500 (EST) 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 32E3C5DEE6 for ; Fri, 7 Feb 2003 12:52:07 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id E17B4599A9 for ; Fri, 7 Feb 2003 17:52:09 +0000 (GMT) Message-ID: <003601c2ced1$a376bdf0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <031b01c2ceca$1e4d6720$131010ac@aldebaran> <20030207121316.150ff194.moore@cs.utk.edu> Subject: Re: 1. Engineering philosophy Date: Fri, 7 Feb 2003 17:52:10 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Keith Moore" > > that's just the point - the problems aren't not worth the trouble to > fix. or to put it another way, the best fix is to not use v4LL > whenever you have a routable address that you can use instead. Sorry - not good enough. There are genuine problems with knowing whether you have a routable address which works, or with taking too long to find out, or too long to get it, or with it being unreliable. Fix these problems and the objections go away. You hinted at a possible solution when you replied to Bill Rees yesterday. Give us the detail, not just hints: Philip From owner-zeroconf@merit.edu Fri Feb 7 12:49:33 2003 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 MAA16587 for ; Fri, 7 Feb 2003 12:49:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 94F549125B; Fri, 7 Feb 2003 12:53:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E9589125E; Fri, 7 Feb 2003 12:53:03 -0500 (EST) 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 490749125B for ; Fri, 7 Feb 2003 12:53:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 201865DF0B; Fri, 7 Feb 2003 12:53:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 946765DEE6 for ; Fri, 7 Feb 2003 12:53:01 -0500 (EST) Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h17HqaP11716 for ; Fri, 7 Feb 2003 11:52:36 -0600 (CST) Date: Fri, 7 Feb 2003 11:53:00 -0600 Subject: Re: WG consensus action: when to configure LL addrs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <18195.1044617009@munnari.OZ.AU> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > We should probably attempt to work out just what it is that one of us > is not understanding about the other's position (argument, belief) that > has led to this. I really tried, and believe I failed. I do not really understand how the facts you've stated support your position, and I don't see how to get you to how the facts I've stated support mine. I don't think there's a disconnect in terms of each other's factual basis for drawing our conclusions. Rather, I think that you and I disagree on the hypothetical gravity of two situations that haven't been tested in the real world. Honest engineers can have such disagreements. > This isn't an issue where the arguments are just > based upon religious views (on either side), but one of us seems to be > seeing something that isn't being communicated very well to the other. I think you're right that this isn't religious. That doesn't make it tractable, unfortunately. > I don't think that either of us was "flaming" on this particular issue. I don't mean flaming in the sense of yelling. I mean flaming in the sense of going 'round and 'round without making progress. In that sense, we were both flaming. > But if you would like to explain to me what about the last message I > sent > was wrong in your opinion, I'd be happy to receive it, even in private > mail. I have explained, over and over again. I've wasted countless hours of my employer's time trying to resolve my differences with you and with a couple of other people on this mailing list, to no avail. I need to go back to doing the work they pay me to do. From owner-zeroconf@merit.edu Fri Feb 7 13:22:43 2003 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 NAA17255 for ; Fri, 7 Feb 2003 13:22:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CCA8E9125E; Fri, 7 Feb 2003 13:26:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A50F91263; Fri, 7 Feb 2003 13:26:14 -0500 (EST) 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 77F4C9125E for ; Fri, 7 Feb 2003 13:26:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 54C355E04F; Fri, 7 Feb 2003 13:26:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id E626F5DF2E for ; Fri, 7 Feb 2003 13:26:12 -0500 (EST) Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h17IPhP11974; Fri, 7 Feb 2003 12:25:43 -0600 (CST) Date: Fri, 7 Feb 2003 12:26:06 -0600 Subject: Re: WG consensus action: when to configure LL addrs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Mika Liljeberg , zeroconf@merit.edu To: Robert Elz From: Ted Lemon In-Reply-To: <18238.1044617733@munnari.OZ.AU> Message-Id: <9F413250-3AC9-11D7-A2AE-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Not quite. But if you believe that waiting a very short while to see > if a DHCP response appears is functionally no different to not waiting, > then there can't really be an objection to the delay. I see where you're coming from, but your argument could easily go in exactly the opposite direction with the same supporting facts. Sure, if we delay 0.3 seconds, we are never going to get a response from the DHCP server in that time anyway, so it doesn't delay IPv4ll configuration more than 0.3 seconds. On the other hand, if we're never going to get a response from the DHCP server during the allotted timeout anyway, why bother waiting? If we need to wait until a DHCP server has had a reasonable time to respond, our specification needs to be a lot more complicated than it is. For example, let's say we want to delay until a DHCP transaction has either succeeded or failed. So we wait, say, 1.5 seconds to give the DHCP server time to send us a DHCPOFFER. And during that time, the DHCPOFFER arrives. Okay, now our DHCP client is engaged, and following its own timing requirements. Now that we have the DHCPOFFER, does the DHCP client tell the IPv4ll state machine to wait? If so, for how long? Until the transaction has completed? What if it doesn't complete? What do we write in the draft to account for this situation? Is it even the right thing to do to try to account for this in the draft? Honestly, I think it's best not to say, because if we do say, we open up a huge can of worms, and this becomes the DHCP+IPv4ll draft, not the IPv4ll draft. If DHCP and IPv4ll interfered with each other strongly, we'd need to address this. But they don't. If I get an IPv4ll address, and then two seconds later I get a DHCP address, the draft already says what to do, and what it says to do will work just fine. So there is no need to further address this in the draft, and furthermore I think it would be dangerous and harmful to try to do so. From owner-zeroconf@merit.edu Fri Feb 7 16:11:21 2003 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 QAA21625 for ; Fri, 7 Feb 2003 16:11:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 311C99125B; Fri, 7 Feb 2003 16:14:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D68279125E; Fri, 7 Feb 2003 16:14:51 -0500 (EST) 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 6B1399125B for ; Fri, 7 Feb 2003 16:14:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F44D5E05C; Fri, 7 Feb 2003 16:14:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 2AC9C5DE8A for ; Fri, 7 Feb 2003 16:14:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id E3BB9140AA; Fri, 7 Feb 2003 16:14:49 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 07025-01; Fri, 7 Feb 2003 16:14:49 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id F026A140B5; Fri, 7 Feb 2003 16:14:48 -0500 (EST) Date: Fri, 7 Feb 2003 16:14:48 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: 1. Engineering philosophy Message-Id: <20030207161448.179a39a4.moore@cs.utk.edu> In-Reply-To: <003601c2ced1$a376bdf0$131010ac@aldebaran> References: <031b01c2ceca$1e4d6720$131010ac@aldebaran> <20030207121316.150ff194.moore@cs.utk.edu> <003601c2ced1$a376bdf0$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: c1b0d03a7f7a836b1f25d37d771fe2ef01913bcf Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > that's just the point - the problems aren't not worth the trouble to > > fix. or to put it another way, the best fix is to not use v4LL > > whenever you have a routable address that you can use instead. > > Sorry - not good enough. > > There are genuine problems with knowing whether you have a routable > address which works, or with taking too long to find out, or too long > to get it, or with it being unreliable. Fix these problems and the > objections go away. You hinted at a possible solution when you replied > to Bill Rees yesterday. Give us the detail, not just hints: 1. v4LL is too dysfunctional to be used as a realistic backup for DHCP on the vast majority of connected networks. If DHCP is unreliable, DHCP needs to be fixed rather than expecting v4LL to solve the problem. But fixes to DHCP need to be made by the DHC working group. The most this WG should do about those is state the problems for which fixes are needed. (Note that to the extent these problems exist, they exist independently of LL.) 2. As for "knowing whether you have a routable address that works": If there's a misconfigured DHCP server that's handing out useless addresses, this is a network configuration problem. LL-capable hosts shouldn't be trying to second-guess network configuration even when the server appears to be misconfigured. The most they should do is say "there's a network configuration problem". 3. As for rogue DHCP servers, DHCP authentication is already defined in RFC 3118, and any LL-capable device is free to implement that. If there's some suggestion that this group can make for making it easier to use RFC 3118, I'm sure the DHC group would love to hear it. 4. As for "too long to get the address", the most that I think this group should specify regarding interaction of LL and DHCP is this: a) minimum amount of time a device should wait for a DHCP reply before starting to configure LL (T1 in the diagram below). (suggestion: 0-2 seconds) b) mininum amount of time a device should wait for a DHCP reply before starting to use the LL address as either a source or destination address (T2) (suggestion: 5-10 seconds) c) minimum and maximum intervals to wait before attempting again to get an address from DHCP after having failed to obtain one (T3, T4) (suggestion: 5 minutes, 10 minutes) d) maximum amount of time a device should continue to use the LL address as a source address for new connections after obtaining an address from DHCP (T5) (suggestion: a few seconds) e) maximum amount of time a device should accept new connection attempts at an LL address after obtaining an address from DHCP (T6) (suggestion: 5-10 minutes) start DHCP start LL start using start DHCP discovery configuration LL address discovery again | / | | | / | | | / | | ------------------------------------------------------------------------ +----T1--->| | | +---------------T2------------->| | +---------------------------T3 + rand(T4-T3)-------------------------->| notes: T2 > T1, T3 > T2 address obtained stop using stop using from DHCP LL source address LL destination | | | | | | | | | ----------------------------------------------------------------- +--------------T5--------------->| | +--------------------------------T6---------------------------->| notes: T5 could be greater than, less than, or equal to T6. ----------------------------------------------------------------------- The other idea I keep coming back to is to define some sort of magic ARP response to an ARP broadcast reply for an LL address to mean "try using DHCP before configuring LL". For instance, an ARP reply associating the LL host's ethernet address with some well-known IP address (say 127.0.0.255) would be an indication to that host that it should try to get an address from DHCP and wait at least T2 seconds after trying before using any LL address. (So in this scenario, the LL host would "start LL configuration" first, and if it didn't see any "magic ARP response" or conflict within the required interval, it would then start using the LL address. It should still try DHCP discovery immediately, and again at irregular but bounded intervals, but it doesn't have to wait T2 seconds before using the LL address - it would be immediately available.) The purpose of this is that by giving the network a way to quickly say "don't use LL", the network can discourage LL without forcing LL-capable hosts to time out waiting for a DHCP response on networks that don't have a DHCP server. The worst that would happen is that, on networks that did support DHCP and did not provide the magic ARP response, LL-capable hosts would configure an LL address that they would quickly abandon. This should be a simple change to LL host code because it would not require the LL host to recognize a different packet type while waiting for responses to its ARP broadcast. All it has to do is look for responses with the same Ethernet address that it's using in addition to responses with the same IP address that it's claiming. Obvious drawbacks: a) It can be spoofed. But the effect of the spoofing is just to delay use of the LL address by T2 seconds. (Once an LL address is configured, the host should keep using it until it gets a DHCP address, even if on subsequent attempts to defend the LL address it gets the magic ARP message that says "try DHCP first") b) It requires networks that care to have a couple of servers sitting around that listen for, and send out, these ARPs. For convenience in packaging, this could be an option (disabled by default) in DHCP servers. (If you believe that networks won't need to do this, then this shouldn't bother you much.) c) I'm not sure it's worth the trouble. It depends on how important it is for LL-capable devices to be able to start working quickly on ad hoc networks. Keith From owner-zeroconf@merit.edu Fri Feb 7 17:00:25 2003 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 RAA22829 for ; Fri, 7 Feb 2003 17:00:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9D35D9125B; Fri, 7 Feb 2003 17:03:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6EF4491266; Fri, 7 Feb 2003 17:03:48 -0500 (EST) 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 42E3E9125B for ; Fri, 7 Feb 2003 17:03:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1CC625DEC0; Fri, 7 Feb 2003 17:03:44 -0500 (EST) 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 C8A815DE1B for ; Fri, 7 Feb 2003 17:03:43 -0500 (EST) 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 h17M3eI26182 for ; Fri, 7 Feb 2003 14:03:40 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 7 Feb 2003 14:03:38 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h17M3cs20348 for ; Fri, 7 Feb 2003 14:03:38 -0800 (PST) Message-Id: <200302072203.h17M3cs20348@scv1.apple.com> Subject: Lets do this one at a time Date: Fri, 7 Feb 2003 14:03:37 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk A number of people have made good well-thought-out comments, but I am going to ask everyone to refrain from the current disorganized collection of independent discussions, and instead follow Erik's procedure of discuss each issue singly, in turn. If there is an issue related to the draft which you want to discuss, then we should add it to the list of issues, and discuss it when its turn comes around. There may be cases where there are interdependencies between issues, where one issue cannot be resolved without also knowing the resolution of another, but we can deal with those interdependent issues when we get to them. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Feb 7 17:08:23 2003 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 RAA23080 for ; Fri, 7 Feb 2003 17:08:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C1E2691266; Fri, 7 Feb 2003 17:11:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F83291267; Fri, 7 Feb 2003 17:11:53 -0500 (EST) 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 6101091266 for ; Fri, 7 Feb 2003 17:11:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 448035DFE3; Fri, 7 Feb 2003 17:11:52 -0500 (EST) 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 CF2C45DE1B for ; Fri, 7 Feb 2003 17:11:51 -0500 (EST) 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 RAA23276 for ; Fri, 7 Feb 2003 17:11:51 -0500 (EST) 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 RAA25676 for ; Fri, 7 Feb 2003 17:11:50 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA24979 for ; Fri, 7 Feb 2003 17:11:50 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 07 Feb 2003 17:11:48 -0500 Subject: Re: 1. Engineering philosophy From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030207161448.179a39a4.moore@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 02/07/2003 16:14, "Keith Moore" wrote: >> There are genuine problems with knowing whether you have a routable >> address which works, or with taking too long to find out, or too long >> to get it, or with it being unreliable. Fix these problems and the >> objections go away. You hinted at a possible solution when you replied >> to Bill Rees yesterday. Give us the detail, not just hints: > > 1. v4LL is too dysfunctional to be used as a realistic backup for DHCP > on the vast majority of connected networks. If DHCP is unreliable, DHCP > needs to be fixed rather than expecting v4LL to solve the problem. > But fixes to DHCP need to be made by the DHC working group. The most > this WG should do about those is state the problems for which fixes are > needed. (Note that to the extent these problems exist, they exist > independently of LL.) It's not supposed to be a backup in that sense. It's a way to self configure a local link network address...why would you even consider it as a backup for DHCP which has a different scope and purpose. > > 2. As for "knowing whether you have a routable address that works": > If there's a misconfigured DHCP server that's handing out useless > addresses, this is a network configuration problem. LL-capable hosts > shouldn't be trying to second-guess network configuration even when the > server appears to be misconfigured. The most they should do is say > "there's a network configuration problem". True > > 3. As for rogue DHCP servers, DHCP authentication is already defined in > RFC 3118, and any LL-capable device is free to implement that. If > there's some suggestion that this group can make for making it easier to > use RFC 3118, I'm sure the DHC group would love to hear it. Rogue DHCP servers are the reason for not making DHCP the sole decision for disabling v4LL on a link. You have older servers, etc. What do you do about manually configured addresses when the machine 'wakes up' in a situation where a v4LL ad hoc network needs to be configured? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Feb 7 17:15:25 2003 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 RAA23208 for ; Fri, 7 Feb 2003 17:15:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A33EC91209; Fri, 7 Feb 2003 17:18:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7532491208; Fri, 7 Feb 2003 17:18:48 -0500 (EST) 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 46D069125B for ; Fri, 7 Feb 2003 17:18:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1A0795E05F; Fri, 7 Feb 2003 17:18:46 -0500 (EST) 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 93CE05E057 for ; Fri, 7 Feb 2003 17:18:45 -0500 (EST) 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 h17MIjI00746 for ; Fri, 7 Feb 2003 14:18:45 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 7 Feb 2003 14:18:44 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h17MIis00095 for ; Fri, 7 Feb 2003 14:18:44 -0800 (PST) Message-Id: <200302072218.h17MIis00095@scv1.apple.com> Subject: Magic ARP response Date: Fri, 7 Feb 2003 14:18:43 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >The other idea I keep coming back to is to define some sort of magic >ARP response Keith Moore makes a good suggestion here. I will follow my own advice, and refrain from any further comment. The issue of disabling v4LL is already listed as LL2; I will make my comments when its turn comes around. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Feb 7 17:28:25 2003 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 RAA23485 for ; Fri, 7 Feb 2003 17:28:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 21E099128F; Fri, 7 Feb 2003 17:31:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E798191291; Fri, 7 Feb 2003 17:31:42 -0500 (EST) 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 8B3BF9128F for ; Fri, 7 Feb 2003 17:31:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6F0745DFE8; Fri, 7 Feb 2003 17:31:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 4E2CA5DD91 for ; Fri, 7 Feb 2003 17:31:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 05FD6140B7; Fri, 7 Feb 2003 17:31:36 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 16632-08; Fri, 7 Feb 2003 17:31:35 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 64EB0140B5; Fri, 7 Feb 2003 17:31:35 -0500 (EST) Date: Fri, 7 Feb 2003 17:31:35 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: 1. Engineering philosophy Message-Id: <20030207173135.3adb4b8d.moore@cs.utk.edu> In-Reply-To: References: <20030207161448.179a39a4.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: fbcbdb0eee511cb20227cad5e22a58a00752513d Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > 1. v4LL is too dysfunctional to be used as a realistic backup for > > DHCP on the vast majority of connected networks. If DHCP is > > unreliable, DHCP needs to be fixed rather than expecting v4LL to > > solve the problem. But fixes to DHCP need to be made by the DHC > > working group. The most this WG should do about those is state the > > problems for which fixes are needed. (Note that to the extent these > > problems exist, they exist independently of LL.) > > It's not supposed to be a backup in that sense. It's a way to self > configure a local link network address...why would you even consider > it as a backup for DHCP which has a different scope and purpose. People have argued in favor of simultaneous configuration of LL and routable addresses using the justification that LL will keep working even if the routable address fails. This was a response to that argument. > > 3. As for rogue DHCP servers, DHCP authentication is already defined > > in RFC 3118, and any LL-capable device is free to implement that. > > If there's some suggestion that this group can make for making it > > easier to use RFC 3118, I'm sure the DHC group would love to hear > > it. > > Rogue DHCP servers are the reason for not making DHCP the sole > decision for disabling v4LL on a link. No, they are not a justification for that. v4LL on the link doesn't solve the problem of rogue DHCP servers. A host that configures LL on a link that expects hosts to have routable addresses is still, in most cases and for most purposes, dysfunctional. The only way a host can hope to distinguish between a rogue DHCP server and a legitimate one is to be configured to require authentication. > What do you do about manually configured addresses when the machine > 'wakes up' in a situation where a v4LL ad hoc network needs to be > configured? The same thing you'd do if you found yourself on a network with a rogue DHCP server - you manually change the configuration to enable LL. Manual configuration does have its problems, one of which is that once you've explicitly set the network address you can no longer expect the machine to adapt to changes in network conditions until you turn off the manual configuration. Keith From owner-zeroconf@merit.edu Fri Feb 7 20:49:57 2003 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 UAA27273 for ; Fri, 7 Feb 2003 20:49:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 80AB191209; Fri, 7 Feb 2003 20:53:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 465B19120D; Fri, 7 Feb 2003 20:53:29 -0500 (EST) 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 19B1991209 for ; Fri, 7 Feb 2003 20:53:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id F3BCC5DEC9; Fri, 7 Feb 2003 20:53:28 -0500 (EST) 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 87CB05DD91 for ; Fri, 7 Feb 2003 20:53:27 -0500 (EST) 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 UAA28257 for ; Fri, 7 Feb 2003 20:53:26 -0500 (EST) 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 UAA12383 for ; Fri, 7 Feb 2003 20:53:26 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id UAA01915 for ; Fri, 7 Feb 2003 20:53:25 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 07 Feb 2003 20:53:24 -0500 Subject: Re: 1. Engineering philosophy From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030207173135.3adb4b8d.moore@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 02/07/2003 17:31, "Keith Moore" wrote: >> It's not supposed to be a backup in that sense. It's a way to self >> configure a local link network address...why would you even consider >> it as a backup for DHCP which has a different scope and purpose. > > People have argued in favor of simultaneous configuration of LL and > routable addresses using the justification that LL will keep working > even if the routable address fails. This was a response to that > argument. Ah. Well, in the sense that being able to see something is better than sitting around waiting for the IS folks to get your network back up, then yes. But it's better stated as an alternative configuration method than a backup, which is how I at least, view it. >> >> Rogue DHCP servers are the reason for not making DHCP the sole >> decision for disabling v4LL on a link. > > No, they are not a justification for that. v4LL on the link doesn't > solve the problem of rogue DHCP servers. A host that configures LL on a > link that expects hosts to have routable addresses is still, in most > cases and for most purposes, dysfunctional. > > The only way a host can hope to distinguish between a rogue DHCP server > and a legitimate one is to be configured to require authentication. You aren't going to get it, unless you get everyone to update all DHCP servers to require authentication and all clients to *ignore* DHCP servers they aren't authenticated for. It's a very good idea, but it's not going to happen for v4. > >> What do you do about manually configured addresses when the machine >> 'wakes up' in a situation where a v4LL ad hoc network needs to be >> configured? > > The same thing you'd do if you found yourself on a network with a rogue > DHCP server - you manually change the configuration to enable LL. > Manual configuration does have its problems, one of which is that once > you've explicitly set the network address you can no longer expect the > machine to adapt to changes in network conditions until you turn off > the manual configuration. But right now, there's no way to override the automatic behavior. Any attempt to insert that type of behavior has been shot down. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sat Feb 8 02:18:31 2003 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 CAA14256 for ; Sat, 8 Feb 2003 02:18:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BE7B791209; Sat, 8 Feb 2003 02:21:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 926849120D; Sat, 8 Feb 2003 02:21:08 -0500 (EST) 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 59D7391209 for ; Sat, 8 Feb 2003 02:21:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3DE285DDF2; Sat, 8 Feb 2003 02:21:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by segue.merit.edu (Postfix) with ESMTP id E2FEB5DDA1 for ; Sat, 8 Feb 2003 02:21:06 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18hPIM-0004RR-00; Fri, 07 Feb 2003 23:21:02 -0800 Date: Sat, 8 Feb 2003 02:18:53 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: DHCP auth / manual override (was Re: 1. Engineering philosophy) Message-Id: <20030208021853.31156564.moore@cs.utk.edu> In-Reply-To: References: <20030207173135.3adb4b8d.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > The only way a host can hope to distinguish between a rogue DHCP server > > and a legitimate one is to be configured to require authentication. > > You aren't going to get it, unless you get everyone to update all DHCP > servers to require authentication and all clients to *ignore* DHCP servers > they aren't authenticated for. It's a very good idea, but it's not going to > happen for v4. Note that the threat of a rogue DHCP server is independent of LL. The fact that DHCP authentication hasn't become widely deployed may be due to a lack of good tools to do it (I suspect a uniform means of configuring hosts from an isolated network connection would help immensely), or a chicken-and-egg problem (why upgrade servers/hosts if the hosts/servers don't support it?). Or perhaps it's not (yet) been a significant problem in practice. Or perhaps the problem when it does occur is more easily solved by other mechanisms, such as monitoring and alarms. I don't really know the reason DHCP authentication hasn't succeeded yet. But I'm quite certain that this WG is not going to produce a better solution for making hosts resistant to rogue DHCP servers. > > The same thing you'd do if you found yourself on a network with a rogue > > DHCP server - you manually change the configuration to enable LL. > > Manual configuration does have its problems, one of which is that once > > you've explicitly set the network address you can no longer expect the > > machine to adapt to changes in network conditions until you turn off > > the manual configuration. > > But right now, there's no way to override the automatic behavior. Any > attempt to insert that type of behavior has been shot down. Actually I read it completely opposite - I haven't seen any objection to allowing manual override of automatic behavior. If the question of manual override isn't on the issue list, why not ask to have it added? Keith From owner-zeroconf@merit.edu Sat Feb 8 08:24:17 2003 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 IAA21133 for ; Sat, 8 Feb 2003 08:24:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4BB2291209; Sat, 8 Feb 2003 08:27:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F9EA9120E; Sat, 8 Feb 2003 08:27:49 -0500 (EST) 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 0537391209 for ; Sat, 8 Feb 2003 08:27:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id DDDD65DF76; Sat, 8 Feb 2003 08:27:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 602025DF4A for ; Sat, 8 Feb 2003 08:27:46 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h18DRZn05616; Sat, 8 Feb 2003 20:27:36 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h18DREb27577; Sat, 8 Feb 2003 20:27:14 +0700 (ICT) From: Robert Elz To: Ted Lemon Cc: zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs In-Reply-To: <9F413250-3AC9-11D7-A2AE-00039367340A@nominum.com> References: <9F413250-3AC9-11D7-A2AE-00039367340A@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Feb 2003 20:27:14 +0700 Message-ID: <27575.1044710834@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 7 Feb 2003 12:26:06 -0600 From: Ted Lemon Message-ID: <9F413250-3AC9-11D7-A2AE-00039367340A@nominum.com> | On the other hand, if we're | never going to get a response from the DHCP server during the allotted | timeout anyway, why bother waiting? Not never Ted, just never from your (or some other) servers. Servers that don't do the ping test (which includes the way I use your server) will usually send an offer much quicker than that - but I certainly take the point that someone else made that all of these timers depend upon the network technology in use, and I'd suggest probably should be specified to vary based upon that - otherwise we can't do otherwise than end up with timer values set to allow the slowest technologies to cope - and the slowest I'm aware of are 802.x nets with 802.1d enabled on the link. For those, even the timer values in section 2.2 aren't nearly long enough. | Now that we have the | DHCPOFFER, does the DHCP client tell the IPv4ll state machine to wait? I would, yes. | If so, for how long? Until the transaction has completed? What if | it doesn't complete? Yes to Q2 there, which answers Q1, and if it fails, then the LL thing can just start again. I'm not about to worry much about that case, this is a very rare event, and attempting to put in special cases to handle rare events isn't worth the bother. Once a week, somewhere in the world, a device will wait an extra 10 seconds or so before giving itself an LL address. Why worry? | What do we write in the draft to account for this situation? Is it | even the right thing to do to try to account for this in the draft? | Honestly, I think it's best not to say, because if we do say, we open | up a huge can of worms, and this becomes the DHCP+IPv4ll draft, not the | IPv4ll draft. If this draft did no more that define v4LL addresses, and say how they can be configured (that is, explain the ARP probes, etc), I'd tend to agree with you. But it doesn't - it also tries to tell nodes that they should all configure LL addresses, and always keep the things (the latter part in the process of being removed now). That means that it is already getting involved with what should be configured, or not configured, and when. | If DHCP and IPv4ll interfered with each other strongly, we'd need to | address this. But they don't. I agree, they don't. Where things get messy is when the node ends up having an address from both. The WG already seems agreed that that should not happen, it should be one or the other (with the open question of "neither" not relevant here). This particular issue (the timers) relates to how to get from nothing, to having a single address, in the smoothest way possible (and ideally as quickly as possible). kre From owner-zeroconf@merit.edu Sat Feb 8 08:44:37 2003 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 IAA21584 for ; Sat, 8 Feb 2003 08:44:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BBEAE9120E; Sat, 8 Feb 2003 08:48:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAE1491223; Sat, 8 Feb 2003 08:47:40 -0500 (EST) 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 2E7CE9120E for ; Sat, 8 Feb 2003 08:47:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id BDDEB5DEF4; Sat, 8 Feb 2003 08:47:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id B397C5DE0E for ; Sat, 8 Feb 2003 08:47:06 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h18DlfQF016947; Sat, 8 Feb 2003 15:47:41 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h18DlbwZ016946; Sat, 8 Feb 2003 15:47:37 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Robert Elz Cc: Ted Lemon , zeroconf@merit.edu In-Reply-To: <27575.1044710834@munnari.OZ.AU> References: <9F413250-3AC9-11D7-A2AE-00039367340A@nominum.com> <27575.1044710834@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044712056.11519.5.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 08 Feb 2003 15:47:37 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-08 at 15:27, Robert Elz wrote: > | If DHCP and IPv4ll interfered with each other strongly, we'd need to > | address this. But they don't. > > I agree, they don't. Where things get messy is when the node ends up > having an address from both. People keep saying that without offering any real evidence. Things only get messy when nodes start mixing an LL source address with a routable destination address, or vice versa. If the scopes of the source and destionation addresses are required match, things become very clear indeed. > The WG already seems agreed that that should not happen, it should be > one or the other (with the open question of "neither" not relevant here). I don't. And I've seen comments from others who don't seem to agree either. MikaL From owner-zeroconf@merit.edu Sat Feb 8 08:48:56 2003 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 IAA21662 for ; Sat, 8 Feb 2003 08:48:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC33F9121C; Sat, 8 Feb 2003 08:52:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1EB89121F; Sat, 8 Feb 2003 08:52:28 -0500 (EST) 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 BA0589121C for ; Sat, 8 Feb 2003 08:52:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id A42905DE0E; Sat, 8 Feb 2003 08:52:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 3CB6D5DEF3 for ; Sat, 8 Feb 2003 08:52:26 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h18DqKn08953 for ; Sat, 8 Feb 2003 20:52:21 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h18DqGb27865 for ; Sat, 8 Feb 2003 20:52:16 +0700 (ICT) From: Robert Elz To: zeroconf@merit.edu Subject: New Issue: TTL=255 on send, check on receive? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Feb 2003 20:52:16 +0700 Message-ID: <27863.1044712336@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Description of issue: TTL=255 on send, check on receive? Submitter name: Robert Elz Submitter email address: kre@munnari.OZ.AU Date first submitted: 2003-02-08 Reference: http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00041.html Comment type: ['T'echnical | 'E'ditorial] T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] S Section: 2.7 Rationale/Explanation of issue: See LL3 Lengthy description of problem: See LL3 Requested Change: Delete the first two paragraphs of section 2.7 From owner-zeroconf@merit.edu Sat Feb 8 09:07:59 2003 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 JAA21880 for ; Sat, 8 Feb 2003 09:07:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BA32A9121F; Sat, 8 Feb 2003 09:11:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83F0F91223; Sat, 8 Feb 2003 09:11:31 -0500 (EST) 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 77C499121F for ; Sat, 8 Feb 2003 09:11:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5A3125DEF3; Sat, 8 Feb 2003 09:11:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id D663E5DE0E for ; Sat, 8 Feb 2003 09:11:28 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h18EBKn10836 for ; Sat, 8 Feb 2003 21:11:23 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h18EBIb27897 for ; Sat, 8 Feb 2003 21:11:18 +0700 (ICT) From: Robert Elz To: zeroconf@merit.edu Subject: New Issue: TTL=255 on send, check on receive? Mime-Version: 1.0 Content-Type: text/plain Date: Sat, 08 Feb 2003 21:11:18 +0700 Message-ID: <27895.1044713478@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Description of issue: Don't configure needless LL addresses Submitter name: Robert Elz Submitter email address: kre@munnari.OZ.AU Date first submitted: 2003-02-08 Reference: http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00262.html http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00548.html http://www.merit.edu/mail.archives/zeroconf/2003-02/msg00000.html Comment type: ['T'echnical | 'E'ditorial] T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] S Section: 1.5 Rationale/Explanation of issue: See LL1 Lengthy description of problem: See LL1 Requested Change: Delete all of section 1.5, and replace it with: Having addresses of multiple different scopes assigned to an interface with no adequate way to determine in what circumstances each address should be used leads to complexity for applications and confusion for users. A node with any address assigned for a link can communicate with all other devices on that link, whether those other devices use link-local addresses, or routable addresses. For this reason, a host that obtains, or is configured with, a routable address on an interface, SHOULD NOT attempt to configure a link-local address on the same interface. Where a link-local address has been configured on an interface, and a routable address is later configured on the same interface, the host MUST always use the routable address when initiating new communications, and MUST cease advertising the availability of the link-local address through whatever mechanisms that address had been made known to others. A host SHOULD continue to use the link-local address for communications underway when the routable address was configured, and MAY continue to accept new communications addressed to the link-local address. From owner-zeroconf@merit.edu Sat Feb 8 09:17:37 2003 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 JAA22012 for ; Sat, 8 Feb 2003 09:17:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 004D491223; Sat, 8 Feb 2003 09:21:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C864891224; Sat, 8 Feb 2003 09:21:09 -0500 (EST) 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 BA20E91223 for ; Sat, 8 Feb 2003 09:21:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 93AE25DF54; Sat, 8 Feb 2003 09:21:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 70ADE5DEF3 for ; Sat, 8 Feb 2003 09:21:03 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h18EKrn12179 for ; Sat, 8 Feb 2003 21:20:56 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h18EKgb27920 for ; Sat, 8 Feb 2003 21:20:42 +0700 (ICT) From: Robert Elz To: zeroconf@merit.edu Subject: New Issue: Delete inappropriate advice to network operators Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Feb 2003 21:20:42 +0700 Message-ID: <27918.1044714042@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Description of issue: Delete inappropriate advice to network operators Submitter name: Robert Elz Submitter email address: kre@munnari.OZ.AU Date first submitted: 2003-02-08 Reference: Comment type: ['T'echnical | 'E'ditorial] T & E Priority: ['S' Must fix | '1' Should fix | '2' May fix ] 1 Section: 1.2 Rationale/Explanation of issue: The draft attempts to give advice to network operators as to how they should build their networks. That is out of scope, unjustified, and unnecessary. Lengthy description of problem: The text in section 1.2 explains ... "This protocol is intended for small ad-hoc networks..." and then goes on to justify that, and give an estimate of what is "small" (or can be regarded as that for the purposes of the draft). That's all fine. Unfortunately, instead of explaining how to avoid using the protocol when the network happens to not be small, the draft instead says "This does not mean that a host should attempt to count the number of other hosts on the link and refuse to operate if it finds there are more than 1300." which is fine in itself, and then continues "It does mean 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." which is entirely inappropriate for this document. Requested Change: Delete the last sentence of section 1.2, and substitute: It does mean that network operators with more than 1300 hosts on a single link may want to ensure that most of the hosts on the link are not assigned link-local addresses. From owner-zeroconf@merit.edu Sat Feb 8 09:34:33 2003 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 JAA22348 for ; Sat, 8 Feb 2003 09:34:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 68D9D91224; Sat, 8 Feb 2003 09:38:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 34A7F9125B; Sat, 8 Feb 2003 09:38:05 -0500 (EST) 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 225DB91224 for ; Sat, 8 Feb 2003 09:38:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 08E9F5DF82; Sat, 8 Feb 2003 09:38:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 873CA5DF81 for ; Sat, 8 Feb 2003 09:38:02 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h18Ebnn14649; Sat, 8 Feb 2003 21:37:51 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h18Ebdb27969; Sat, 8 Feb 2003 21:37:41 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs In-Reply-To: <1044712056.11519.5.camel@devil> References: <1044712056.11519.5.camel@devil> <9F413250-3AC9-11D7-A2AE-00039367340A@nominum.com> <27575.1044710834@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Feb 2003 21:37:39 +0700 Message-ID: <27967.1044715059@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 08 Feb 2003 15:47:37 +0200 From: Mika Liljeberg Message-ID: <1044712056.11519.5.camel@devil> | If the scopes of the source and destionation addresses are required match, | things become very clear indeed. Yes, but you cannot require that - not in the sense that it is not a good idea, in the sense that it is impossible. A link can have nodes on it that have only v4LL addresses (to satisfy everyone, let's assume that such a node attempted to get an address via DHCP, failed to get a response, and then assigned itself a LL address, though how it happened doesn't matter). A link can also have nodes on it that have never heard of v4LL addresses, and have only old fashioned "routable" addresses. If some other node, that has both addresses (link local and routable) wants to send a multicast or broadcast packet, that both of the others will (or might) receive, which source address would it use, given your proposed rule? If both of the others want to reply to that packet, how is that accomplished using your rule? I think (hope) that you'll see that you can't require what you want. So, we are stuck with mixed scope address packets, and mixed communications. We could just require that a node not use its LL address if it has a global one (that's close enough to what IPv6 does - LL addresses, aside from a few uses that don't exist at all in v4, just aren't used at all if a node has a global address - the global address is used instead) - but if that's going to be the outcome, what use is having the LL address in the first place? It is just going to sit there doing nothing (this is unlike IPv6 where those other few defined uses demand that the LL address exist). | I don't. And I've seen comments from others who don't seem to agree | either. Of course there are some who don't agree. But see Erik's summary of the last time this debate was held ... http://www.merit.edu/mail.archives/zeroconf/2003-02/msg00000.html This is the first issue in that message. kre From owner-zeroconf@merit.edu Sat Feb 8 10:08:15 2003 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 KAA22933 for ; Sat, 8 Feb 2003 10:08:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 51C9091209; Sat, 8 Feb 2003 10:11:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 215D19125B; Sat, 8 Feb 2003 10:11:48 -0500 (EST) 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 BA22391209 for ; Sat, 8 Feb 2003 10:11:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9C8A65DEF3; Sat, 8 Feb 2003 10:11:46 -0500 (EST) 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 50FCD5DDA8 for ; Sat, 8 Feb 2003 10:11:46 -0500 (EST) 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 HAA26121; Sat, 8 Feb 2003 07:11:40 -0800 (PST) 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 h18FBcl01724; Sat, 8 Feb 2003 16:11:39 +0100 (MET) Date: Sat, 8 Feb 2003 16:11:37 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Keith Moore Cc: Philip Nye , zeroconf@merit.edu Subject: Re: 1. Engineering philosophy In-Reply-To: <20030207161448.179a39a4.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Keith, This is a valuable posting. Thank you, Keith. Can we reformulate it as a potential solution to LL2? Could you post an 'issue' to cover it? If (a) a host is required to attempt to get configuration (ie. using DHCP, RARP, manual configuration, whatever) and then (b) to transition *in an orderly way, as non-disruptively as possible* to using that configured address, we do not need to specify some additional RFC 2563-like mechanism, right? (I am eeking to flesh out middle ground between the v4LL-aways and v4LL-mimosa camps.) Erik > > > that's just the point - the problems aren't not worth the trouble to > > > fix. or to put it another way, the best fix is to not use v4LL > > > whenever you have a routable address that you can use instead. > > > > Sorry - not good enough. > > > > There are genuine problems with knowing whether you have a routable > > address which works, or with taking too long to find out, or too long > > to get it, or with it being unreliable. Fix these problems and the > > objections go away. You hinted at a possible solution when you replied > > to Bill Rees yesterday. Give us the detail, not just hints: > > 1. v4LL is too dysfunctional to be used as a realistic backup for DHCP > on the vast majority of connected networks. If DHCP is unreliable, DHCP > needs to be fixed rather than expecting v4LL to solve the problem. > But fixes to DHCP need to be made by the DHC working group. The most > this WG should do about those is state the problems for which fixes are > needed. (Note that to the extent these problems exist, they exist > independently of LL.) > > 2. As for "knowing whether you have a routable address that works": > If there's a misconfigured DHCP server that's handing out useless > addresses, this is a network configuration problem. LL-capable hosts > shouldn't be trying to second-guess network configuration even when the > server appears to be misconfigured. The most they should do is say > "there's a network configuration problem". > > 3. As for rogue DHCP servers, DHCP authentication is already defined in > RFC 3118, and any LL-capable device is free to implement that. If > there's some suggestion that this group can make for making it easier to > use RFC 3118, I'm sure the DHC group would love to hear it. > > 4. As for "too long to get the address", the most that I think this > group should specify regarding interaction of LL and DHCP is this: > > a) minimum amount of time a device should wait for a DHCP reply before > starting to configure LL (T1 in the diagram below). > (suggestion: 0-2 seconds) > > b) mininum amount of time a device should wait for a DHCP reply before > starting to use the LL address as either a source or destination address > (T2) (suggestion: 5-10 seconds) > > c) minimum and maximum intervals to wait before attempting again to get > an address from DHCP after having failed to obtain one (T3, T4) > (suggestion: 5 minutes, 10 minutes) > > d) maximum amount of time a device should continue to use the LL address > as a source address for new connections after obtaining an address from > DHCP (T5) (suggestion: a few seconds) > > e) maximum amount of time a device should accept new connection attempts > at an LL address after obtaining an address from DHCP (T6) > (suggestion: 5-10 minutes) > > > > start DHCP start LL start using start DHCP > discovery configuration LL address discovery again > | / | | > | / | | > | / | | > ------------------------------------------------------------------------ > +----T1--->| | | > +---------------T2------------->| | > +---------------------------T3 + rand(T4-T3)-------------------------->| > > notes: T2 > T1, T3 > T2 > > address obtained stop using stop using > from DHCP LL source address LL destination > | | | > | | | > | | | > ----------------------------------------------------------------- > +--------------T5--------------->| | > +--------------------------------T6---------------------------->| > > notes: T5 could be greater than, less than, or equal to T6. > > ----------------------------------------------------------------------- > > The other idea I keep coming back to is to define some sort of magic > ARP response to an ARP broadcast reply for an LL address to mean "try > using DHCP before configuring LL". For instance, an ARP reply > associating the LL host's ethernet address with some well-known IP > address (say 127.0.0.255) would be an indication to that host that it > should try to get an address from DHCP and wait at least T2 seconds > after trying before using any LL address. > > (So in this scenario, the LL host would "start LL configuration" > first, and if it didn't see any "magic ARP response" or conflict within > the required interval, it would then start using the LL address. It > should still try DHCP discovery immediately, and again at > irregular but bounded intervals, but it doesn't have to wait T2 > seconds before using the LL address - it would be immediately > available.) > > The purpose of this is that by giving the network a way to quickly say > "don't use LL", the network can discourage LL without forcing LL-capable > hosts to time out waiting for a DHCP response on networks that don't > have a DHCP server. The worst that would happen is that, on networks > that did support DHCP and did not provide the magic ARP response, > LL-capable hosts would configure an LL address that they would quickly > abandon. > > This should be a simple change to LL host code because it would not > require the LL host to recognize a different packet type while waiting > for responses to its ARP broadcast. All it has to do is look for > responses with the same Ethernet address that it's using in addition > to responses with the same IP address that it's claiming. > > Obvious drawbacks: > > a) It can be spoofed. But the effect of the spoofing is just to delay > use of the LL address by T2 seconds. (Once an LL address is configured, > the host should keep using it until it gets a DHCP address, even if on > subsequent attempts to defend the LL address it gets the magic ARP > message that says "try DHCP first") > > b) It requires networks that care to have a couple of servers sitting > around that listen for, and send out, these ARPs. For convenience in > packaging, this could be an option (disabled by default) in DHCP > servers. (If you believe that networks won't need to do this, then this > shouldn't bother you much.) > > c) I'm not sure it's worth the trouble. It depends on how important it > is for LL-capable devices to be able to start working quickly on ad hoc > networks. > > Keith > > > > ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n N1 Installation and Provisioning cell: +49 172 865 5497 Sun Microsystems pager: 01728655497@d2-message.de From owner-zeroconf@merit.edu Sat Feb 8 10:16:44 2003 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 KAA23044 for ; Sat, 8 Feb 2003 10:16:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4E8069125B; Sat, 8 Feb 2003 10:20:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A29391266; Sat, 8 Feb 2003 10:20:17 -0500 (EST) 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 BB3149125B for ; Sat, 8 Feb 2003 10:20:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9AA955DDDF; Sat, 8 Feb 2003 10:20:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id E0A4A5DDA8 for ; Sat, 8 Feb 2003 10:20:14 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h18FKoQF017250; Sat, 8 Feb 2003 17:20:50 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h18FKmB1017249; Sat, 8 Feb 2003 17:20:48 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Robert Elz Cc: zeroconf@merit.edu In-Reply-To: <27967.1044715059@munnari.OZ.AU> References: <1044712056.11519.5.camel@devil> <9F413250-3AC9-11D7-A2AE-00039367340A@nominum.com> <27575.1044710834@munnari.OZ.AU> <27967.1044715059@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044717647.11513.34.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 08 Feb 2003 17:20:47 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-08 at 16:37, Robert Elz wrote: > Date: 08 Feb 2003 15:47:37 +0200 > From: Mika Liljeberg > Message-ID: <1044712056.11519.5.camel@devil> > > | If the scopes of the source and destionation addresses are required match, > | things become very clear indeed. > > Yes, but you cannot require that - not in the sense that it is not > a good idea, in the sense that it is impossible. It is not impossible, it's the conservative approach. Making this requirement simply restricts what v4LL addresses can be used for, namely it restricts them for communicating with other v4LL compliant nodes. The idea that v4LL nodes should be able to communicate with non-v4LL nodes is simply faulty. The whole can of worms in crawling free in this WG is due to that misconception. > A link can have nodes on it that have only v4LL addresses (to satisfy > everyone, let's assume that such a node attempted to get an address via > DHCP, failed to get a response, and then assigned itself a LL address, > though how it happened doesn't matter). > > A link can also have nodes on it that have never heard of v4LL addresses, > and have only old fashioned "routable" addresses. If a link has routable addresses available, all nodes on that link should be able to acquire one. Whether some of them will also have v4LL addresses is irrelevant. > If some other node, that has both addresses (link local and routable) > wants to send a multicast or broadcast packet, that both of the others > will (or might) receive, which source address would it use, given your > proposed rule? A non-v4LL node would use a routable one. A v4LL node with a non-v4LL application would do the same. A v4LL-aware application on a v4LL node might broadcast using both. > If both of the others want to reply to that packet, how is that accomplished > using your rule? A node with only a v4LL address would not reply to broadcasts or multicasts with a routable source address. The applicability of v4LL addresses is limited. It should be expected that not all services on a routed network will be available to nodes that only have a v4LL address. The other path leads to the endless bog. > I think (hope) that you'll see that you can't require what you want. No, I don't. Sorry. > | I don't. And I've seen comments from others who don't seem to agree > | either. > > Of course there are some who don't agree. But see Erik's summary of > the last time this debate was held ... > > http://www.merit.edu/mail.archives/zeroconf/2003-02/msg00000.html > > This is the first issue in that message. Review the responses. I counted as many as 6 immediate objections to this point. That's pretty far from a consensus. MikaL From owner-zeroconf@merit.edu Sat Feb 8 11:07:25 2003 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 LAA23851 for ; Sat, 8 Feb 2003 11:07:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 65EF191267; Sat, 8 Feb 2003 11:10:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39AE591272; Sat, 8 Feb 2003 11:10:57 -0500 (EST) 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 0307B91267 for ; Sat, 8 Feb 2003 11:10:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id D743F5DE41; Sat, 8 Feb 2003 11:10:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by segue.merit.edu (Postfix) with ESMTP id B6A075DE0A for ; Sat, 8 Feb 2003 11:10:55 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18hXXA-0000W1-00; Sat, 08 Feb 2003 08:08:53 -0800 Date: Sat, 8 Feb 2003 11:06:43 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, Ted.Lemon@nominum.com, zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs Message-Id: <20030208110643.10dea0e1.moore@cs.utk.edu> In-Reply-To: <1044712056.11519.5.camel@devil> References: <9F413250-3AC9-11D7-A2AE-00039367340A@nominum.com> <27575.1044710834@munnari.OZ.AU> <1044712056.11519.5.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 08 Feb 2003 15:47:37 +0200 Mika Liljeberg wrote: > On Sat, 2003-02-08 at 15:27, Robert Elz wrote: > > | If DHCP and IPv4ll interfered with each other strongly, we'd need to > > | address this. But they don't. > > > > I agree, they don't. Where things get messy is when the node ends up > > having an address from both. > > People keep saying that without offering any real evidence. > > Things only get messy when nodes start mixing an LL source address with > a routable destination address, or vice versa. If the scopes of the > source and destionation addresses are required match, things become very > clear indeed. False, because not all applications involve only two parties. Keith From owner-zeroconf@merit.edu Sat Feb 8 11:08:56 2003 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 LAA23918 for ; Sat, 8 Feb 2003 11:08:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ACFB391272; Sat, 8 Feb 2003 11:12:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 80B3791273; Sat, 8 Feb 2003 11:12:29 -0500 (EST) 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 4C18B91272 for ; Sat, 8 Feb 2003 11:12:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3B4055DE41; Sat, 8 Feb 2003 11:12:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by segue.merit.edu (Postfix) with ESMTP id 1A5235DE0A for ; Sat, 8 Feb 2003 11:12:28 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18hXaZ-0005qT-00; Sat, 08 Feb 2003 08:12:24 -0800 Date: Sat, 8 Feb 2003 11:10:13 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu Subject: Re: 1. Engineering philosophy Message-Id: <20030208111013.6e914481.moore@cs.utk.edu> In-Reply-To: References: <20030207161448.179a39a4.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Sat, 8 Feb 2003 16:11:37 +0100 (CET) Erik Guttman wrote: > > Keith, > > This is a valuable posting. Thank you, Keith. Can we reformulate it as > a potential solution to LL2? Could you post an 'issue' to cover it? I think there are probably multiple issues here. Let me see if I can distill them out. > If (a) a host is required to attempt to get configuration (ie. using > DHCP, RARP, manual configuration, whatever) and then (b) to transition > *in an orderly way, as non-disruptively as possible* to using that > configured address, we do not need to specify some additional RFC > 2563-like mechanism, right? Maybe not. At least, I suspect it makes some of the justifications for a 2563 mechanism marginal enough that they're not an immediate concern. Keith From owner-zeroconf@merit.edu Sat Feb 8 11:10:58 2003 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 LAA23959 for ; Sat, 8 Feb 2003 11:10:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C0E0191273; Sat, 8 Feb 2003 11:14:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E44191274; Sat, 8 Feb 2003 11:14:31 -0500 (EST) 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 889A991273 for ; Sat, 8 Feb 2003 11:14:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6BC165DF90; Sat, 8 Feb 2003 11:14:30 -0500 (EST) 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 E21125DF5F for ; Sat, 8 Feb 2003 11:14:29 -0500 (EST) 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 JAA00441 for ; Sat, 8 Feb 2003 09:14:28 -0700 (MST) 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 h18GERl03440 for ; Sat, 8 Feb 2003 17:14:27 +0100 (MET) Date: Sat, 8 Feb 2003 17:14:25 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: Issues clean up and text needed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Please see http://www.spybeam.org/issues.html - page titles fixed - added text for many issues (Thanks Stuart!) - corrected issue LL19 Please send text for LL2, LL4, LL5 and Ll15 which still need suggested text. Erik From owner-zeroconf@merit.edu Sat Feb 8 11:15:08 2003 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 LAA24120 for ; Sat, 8 Feb 2003 11:15:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A826291205; Sat, 8 Feb 2003 11:18:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DE5791274; Sat, 8 Feb 2003 11:18:34 -0500 (EST) 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 1963291205 for ; Sat, 8 Feb 2003 11:18:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 468EE5DEB3; Sat, 8 Feb 2003 11:18:12 -0500 (EST) 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 BBAB05DE41 for ; Sat, 8 Feb 2003 11:18:11 -0500 (EST) 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 JAA22946 for ; Sat, 8 Feb 2003 09:18:10 -0700 (MST) 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 h18GI9l03592 for ; Sat, 8 Feb 2003 17:18:09 +0100 (MET) Date: Sat, 8 Feb 2003 17:18:07 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: New issue: [LL20] Alternate text for LL12 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Please see http://www.spybeam.org/ll20.html Note that this issue is a distinct alternative to LL12. We will have to choose between them. Erik From owner-zeroconf@merit.edu Sat Feb 8 11:21:42 2003 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 LAA24262 for ; Sat, 8 Feb 2003 11:21:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AF05691274; Sat, 8 Feb 2003 11:25:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7497891278; Sat, 8 Feb 2003 11:25:14 -0500 (EST) 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 7CD6291274 for ; Sat, 8 Feb 2003 11:25:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 688B55DF87; Sat, 8 Feb 2003 11:25:13 -0500 (EST) 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 DE4F35DF5F for ; Sat, 8 Feb 2003 11:25:12 -0500 (EST) 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 JAA19997 for ; Sat, 8 Feb 2003 09:25:11 -0700 (MST) 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 h18GPAl03822 for ; Sat, 8 Feb 2003 17:25:10 +0100 (MET) Date: Sat, 8 Feb 2003 17:25:08 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: new issue [LL21] Alternate text for LL3 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Please see http://www.spybeam.org/ll21.html Please note that this issue presents text which is an alternative to the text in LL3. We will have to choose between the two. Erik From owner-zeroconf@merit.edu Sat Feb 8 11:22:31 2003 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 LAA24284 for ; Sat, 8 Feb 2003 11:22:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 475F291278; Sat, 8 Feb 2003 11:26:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 150DB9127A; Sat, 8 Feb 2003 11:26:02 -0500 (EST) 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 EADD991278 for ; Sat, 8 Feb 2003 11:26:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id D837E5DF5F; Sat, 8 Feb 2003 11:26:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id D91A55DE41 for ; Sat, 8 Feb 2003 11:25:59 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h18GQUQF017447; Sat, 8 Feb 2003 18:26:31 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h18GQTUL017446; Sat, 8 Feb 2003 18:26:29 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Keith Moore Cc: kre@munnari.OZ.AU, Ted.Lemon@nominum.com, zeroconf@merit.edu In-Reply-To: <20030208110643.10dea0e1.moore@cs.utk.edu> References: <9F413250-3AC9-11D7-A2AE-00039367340A@nominum.com> <27575.1044710834@munnari.OZ.AU> <1044712056.11519.5.camel@devil> <20030208110643.10dea0e1.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044721588.11519.43.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 08 Feb 2003 18:26:28 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-08 at 18:06, Keith Moore wrote: > > > I agree, they don't. Where things get messy is when the node ends up > > > having an address from both. > > > > People keep saying that without offering any real evidence. > > > > Things only get messy when nodes start mixing an LL source address with > > a routable destination address, or vice versa. If the scopes of the > > source and destionation addresses are required match, things become very > > clear indeed. > > False, because not all applications involve only two parties. Give us a concrete example illustrating the problem and let's examine it. MikaL From owner-zeroconf@merit.edu Sat Feb 8 11:22:45 2003 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 LAA24297 for ; Sat, 8 Feb 2003 11:22:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5E73E9127A; Sat, 8 Feb 2003 11:26:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 052539127B; Sat, 8 Feb 2003 11:26:07 -0500 (EST) 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 734089127A for ; Sat, 8 Feb 2003 11:26:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 601A85DE41; Sat, 8 Feb 2003 11:26:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id DAEE95DDDF for ; Sat, 8 Feb 2003 11:26:03 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16301 for ; Sat, 8 Feb 2003 08:25:58 -0800 (PST) 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 h18GPul03894 for ; Sat, 8 Feb 2003 17:25:56 +0100 (MET) Date: Sat, 8 Feb 2003 17:25:55 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: new issue [LL22] Delete inappropriate advice to network operators Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Please see http://www.spybeam.org/ll22.html Erik From owner-zeroconf@merit.edu Sat Feb 8 11:29:46 2003 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 LAA24429 for ; Sat, 8 Feb 2003 11:29:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BBE6A9126D; Sat, 8 Feb 2003 11:33:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48AEE9127B; Sat, 8 Feb 2003 11:33:18 -0500 (EST) 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 E03399126D for ; Sat, 8 Feb 2003 11:33:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id BAFD45DF5F; Sat, 8 Feb 2003 11:33:10 -0500 (EST) 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 3AFCD5DE41 for ; Sat, 8 Feb 2003 11:33:10 -0500 (EST) 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 JAA22053; Sat, 8 Feb 2003 09:33:07 -0700 (MST) 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 h18GX5l04154; Sat, 8 Feb 2003 17:33:05 +0100 (MET) Date: Sat, 8 Feb 2003 17:33:04 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: chair@ietf.org Subject: WG action - 1 week to discuss [LL6] Add security considerations note regarding wireless LANs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk http://www.spybeam.org/ll6.html This issue seems fairly straightforward to address. Please discuss this in the next week, ending 15 Feb 2003. If there are no comments, we will assume the new text is accepted. Harald - as you were the submitter, please see if the text is satisfactory. You submitted it, so I suspect it will be ;-) Erik From owner-zeroconf@merit.edu Sat Feb 8 11:33:50 2003 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 LAA24506 for ; Sat, 8 Feb 2003 11:33:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0CEB09127B; Sat, 8 Feb 2003 11:37:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA9FA9128C; Sat, 8 Feb 2003 11:37:21 -0500 (EST) 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 CCD689127B for ; Sat, 8 Feb 2003 11:37:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id B542B5DF5F; Sat, 8 Feb 2003 11:37:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 3A6675DE41 for ; Sat, 8 Feb 2003 11:37:20 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19711; Sat, 8 Feb 2003 08:36:51 -0800 (PST) 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 h18Gaol04318; Sat, 8 Feb 2003 17:36:50 +0100 (MET) Date: Sat, 8 Feb 2003 17:36:48 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: Alex Conta Subject: WG action - 1 week to discuss [LL8] Is additional Routing Consideration text needed? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Please see http://www.spybeam.org/ll8.html This does not seem particularly contentious. If there is no discussion, we will accept the recommendation to add no text. A decision will be reached by 15 Feb 2003. Alex, As you were the one who submitted the issue, please see whether the response satisfies you. If you have trouble recalling - this is regarding draft-ietf-zeroconf-ipv4-linklocal-07.txt Thanks, Erik From owner-zeroconf@merit.edu Sat Feb 8 11:34:31 2003 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 LAA24524 for ; Sat, 8 Feb 2003 11:34:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CAAA19128C; Sat, 8 Feb 2003 11:38:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A2709128F; Sat, 8 Feb 2003 11:38:01 -0500 (EST) 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 6DD619128C for ; Sat, 8 Feb 2003 11:38:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 55D8F5DF5F; Sat, 8 Feb 2003 11:38:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by segue.merit.edu (Postfix) with ESMTP id 34DD85DE41 for ; Sat, 8 Feb 2003 11:38:00 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18hXxS-00073X-00; Sat, 08 Feb 2003 08:36:02 -0800 Date: Sat, 8 Feb 2003 11:33:53 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, Ted.Lemon@nominum.com, zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs Message-Id: <20030208113353.18fd08e8.moore@cs.utk.edu> In-Reply-To: <1044721588.11519.43.camel@devil> References: <9F413250-3AC9-11D7-A2AE-00039367340A@nominum.com> <27575.1044710834@munnari.OZ.AU> <1044712056.11519.5.camel@devil> <20030208110643.10dea0e1.moore@cs.utk.edu> <1044721588.11519.43.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > > Things only get messy when nodes start mixing an LL source address with > > > a routable destination address, or vice versa. If the scopes of the > > > source and destionation addresses are required match, things become very > > > clear indeed. > > > > False, because not all applications involve only two parties. > > Give us a concrete example illustrating the problem and let's examine > it. I've already done that on multiple occasions. Maybe I'll put something on a web page in a few days so that I won't have to try to explain this anew everytime somebody makes a blanket assertion like this one. From owner-zeroconf@merit.edu Sat Feb 8 11:37:21 2003 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 LAA24568 for ; Sat, 8 Feb 2003 11:37:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5C6059128F; Sat, 8 Feb 2003 11:40:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 299C491290; Sat, 8 Feb 2003 11:40:52 -0500 (EST) 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 2A2EF9128F for ; Sat, 8 Feb 2003 11:40:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 123F45DF6C; Sat, 8 Feb 2003 11:40:51 -0500 (EST) 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 8D0475DF5F for ; Sat, 8 Feb 2003 11:40:50 -0500 (EST) 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 IAA20582 for ; Sat, 8 Feb 2003 08:40:49 -0800 (PST) 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 h18Gell04466; Sat, 8 Feb 2003 17:40:47 +0100 (MET) Date: Sat, 8 Feb 2003 17:40:45 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Cc: erik.nordmark@sun.com Subject: WG action - 1 week to discuss [LL7] Add warnings to applicability statement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Please see http://www.spybeam.org/ll10.html This does not seem to be particularly controversial. A consensus call on discussion will occur 15 Feb 2003. Erik, as you were the one who raised the comment in the IESG last call of draft-ietf-zeroconf-ipv4-linklocal-07.txt, could you please confirm that the wording of this issue is appropriate? Thanks, Erik From owner-zeroconf@merit.edu Sat Feb 8 11:40:24 2003 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 LAA24648 for ; Sat, 8 Feb 2003 11:40:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5883891290; Sat, 8 Feb 2003 11:43:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 260FA91291; Sat, 8 Feb 2003 11:43:55 -0500 (EST) 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 2854A91290 for ; Sat, 8 Feb 2003 11:43:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 16D875DE0A; Sat, 8 Feb 2003 11:43:54 -0500 (EST) 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 8B7E45DD99 for ; Sat, 8 Feb 2003 11:43:53 -0500 (EST) 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 JAA01651 for ; Sat, 8 Feb 2003 09:43:52 -0700 (MST) 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 h18Ghol04507; Sat, 8 Feb 2003 17:43:51 +0100 (MET) Date: Sat, 8 Feb 2003 17:43:49 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Cc: erik.nordmark@sun.com Subject: WG action - 1 week to discuss [LL11] Add security consideration for the threat where an attacker forces address reconfiguration Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Please see http://www.spybeam.org/ll11.html This does not seem like it is a controversial issue. It was suggested some time ago and has gotten no further comment. Please comment by 15 Feb 2003 when the issue will be decided. If no comment is made, the recommended text will be accepted. Erik, since you raised this issue during the iesg review of draft-ietf-zeroconf-ipv4-linklocal-07.txt could you please review the recommended fix? Thanks, Erik From owner-zeroconf@merit.edu Sat Feb 8 11:45:03 2003 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 LAA24751 for ; Sat, 8 Feb 2003 11:45:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0D8F391291; Sat, 8 Feb 2003 11:48:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB36C91294; Sat, 8 Feb 2003 11:48:26 -0500 (EST) 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 515D091291 for ; Sat, 8 Feb 2003 11:47:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2FBC65DE43; Sat, 8 Feb 2003 11:47:10 -0500 (EST) 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 A3BDF5DE41 for ; Sat, 8 Feb 2003 11:47:09 -0500 (EST) 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 JAA02667; Sat, 8 Feb 2003 09:47:04 -0700 (MST) 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 h18Gl2l04618; Sat, 8 Feb 2003 17:47:03 +0100 (MET) Date: Sat, 8 Feb 2003 17:47:01 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Cc: Scott Bradner Subject: WG action - 1 week to discuss [LL16] split references Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Please see: http://www.spybeam.org/ll16.html This will not be a controversial issue. Please send your comments by Feb 15. If no comment is received by then, we will accept the recommended text. Scott, you raised the issue that normative and informative references were not split during the IESG review of draft-ietf-zeroconf-ipv4-linklocal-07.txt. The text you will find through the link gives a separation for those references. If there is any problem with them, please let us know. Thank you, Erik From owner-zeroconf@merit.edu Sat Feb 8 11:45:55 2003 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 LAA24776 for ; Sat, 8 Feb 2003 11:45:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 27C0391294; Sat, 8 Feb 2003 11:49:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED70F9129E; Sat, 8 Feb 2003 11:49:18 -0500 (EST) 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 8C2F791294 for ; Sat, 8 Feb 2003 11:49:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 72AC05DE41; Sat, 8 Feb 2003 11:49:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 7D5165DD99 for ; Sat, 8 Feb 2003 11:49:16 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h18GnnQF017558; Sat, 8 Feb 2003 18:49:49 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h18Gnmpp017557; Sat, 8 Feb 2003 18:49:48 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Keith Moore Cc: kre@munnari.OZ.AU, Ted.Lemon@nominum.com, zeroconf@merit.edu In-Reply-To: <20030208113353.18fd08e8.moore@cs.utk.edu> References: <9F413250-3AC9-11D7-A2AE-00039367340A@nominum.com> <27575.1044710834@munnari.OZ.AU> <1044712056.11519.5.camel@devil> <20030208110643.10dea0e1.moore@cs.utk.edu> <1044721588.11519.43.camel@devil> <20030208113353.18fd08e8.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044722987.11513.58.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 08 Feb 2003 18:49:48 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-08 at 18:33, Keith Moore wrote: > > > > Things only get messy when nodes start mixing an LL source address with > > > > a routable destination address, or vice versa. If the scopes of the > > > > source and destionation addresses are required match, things become very > > > > clear indeed. > > > > > > False, because not all applications involve only two parties. > > > > Give us a concrete example illustrating the problem and let's examine > > it. > > I've already done that on multiple occasions. Maybe I'll put something on a > web page in a few days so that I won't have to try to explain this anew > everytime somebody makes a blanket assertion like this one. I'm not asking for a treatise on the subject. Just a concrete case study of an application that fails with the scoping rules I propose: - for unicast, source and destination scopes must match - for multicast & broadcast, a routable source address must be used unless the application (sender) explicitly requests a v4LL source address Note: it could be argued that v4LL source addresses should not be used at all with multicast/broadcast destinations, as there are potential failure modes with non-v4LL compliant nodes. Depends on how conservative one wants to be. If you've already done such a case study, perhaps you could post a pointer to the archive? MikaL From owner-zeroconf@merit.edu Sat Feb 8 11:54:15 2003 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 LAA24922 for ; Sat, 8 Feb 2003 11:54:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 03A919129E; Sat, 8 Feb 2003 11:57:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C92699129F; Sat, 8 Feb 2003 11:57:46 -0500 (EST) 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 B10C79129E for ; Sat, 8 Feb 2003 11:57:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 98F3F5DE43; Sat, 8 Feb 2003 11:57:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by segue.merit.edu (Postfix) with ESMTP id 78BDE5DE41 for ; Sat, 8 Feb 2003 11:57:45 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18hYIN-0006ah-00; Sat, 08 Feb 2003 08:57:40 -0800 Date: Sat, 8 Feb 2003 11:55:30 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, zeroconf@merit.edu, sob@harvard.edu Subject: Re: WG action - 1 week to discuss [LL16] split references Message-Id: <20030208115530.35e7c15e.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 If DHCP ends up being required (as I believe it should) then RFC 2131 becomes a normative reference. Keith From owner-zeroconf@merit.edu Sat Feb 8 12:45:10 2003 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 MAA26059 for ; Sat, 8 Feb 2003 12:45:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8593491227; Sat, 8 Feb 2003 12:48:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B9EF91228; Sat, 8 Feb 2003 12:48:41 -0500 (EST) 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 6645B91227 for ; Sat, 8 Feb 2003 12:47:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 433FF5DE72; Sat, 8 Feb 2003 12:47:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from dhcp.blacksburg.ntc-com.net (dhcp.blacksburg.ntc-com.net [208.35.68.2]) by segue.merit.edu (Postfix) with SMTP id 02C5B5DE41 for ; Sat, 8 Feb 2003 12:47:20 -0500 (EST) Received: (qmail 5812 invoked from network); 8 Feb 2003 17:39:54 -0000 Received: from unknown (HELO Vijay) (204.212.237.190) by dhcp.blacksburg.ntc-com.net with SMTP; 8 Feb 2003 17:39:54 -0000 From: "Vijayanand Ballapuram" To: Subject: Zero Conf in Wireless and Mobile Adhoc Networks Date: Sat, 8 Feb 2003 12:49:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi All, am new member to this mailing list. I am a student just started to work on Zero Configuration Protocols for Wireless and Mobile Ad hoc Networks for my Thesis. Please let me know research that have been done so far for “Establishing Connectivity and other services” in Wireless Networks (with a Base Station) and also Mobile Ahoc Networks( which are formed on the fly) with “minimum human intervention”. Also, please point to papers published in this area and research groups in Company/Universities working in this area. I have read the Internet Draft on “Requirements for Automatic Configuration of IP Hosts “ which states that the Zero Conf protocol can be applied to only · Hosts in the same network. · Hosts in different networks connected by a single router/gateway. So I wanted to know whether Zero Conf protocols can be applied to Mobile Ad Hoc Networks like Ships in a sea, in which ships connect and leave the network dynamically and there is possibility of many gateways as each ship/node needs a Gateway/router to connect with the neighbour nodes. Thanks in Advance, Regards, From owner-zeroconf@merit.edu Sat Feb 8 14:30:00 2003 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 OAA28778 for ; Sat, 8 Feb 2003 14:30:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 46BA891228; Sat, 8 Feb 2003 14:33:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 108069122A; Sat, 8 Feb 2003 14:33:30 -0500 (EST) 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 B1C3F91228 for ; Sat, 8 Feb 2003 14:32:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B78B5DF9D; Sat, 8 Feb 2003 14:32:32 -0500 (EST) 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 1EB615DF9C for ; Sat, 8 Feb 2003 14:32:32 -0500 (EST) 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 OAA11720 for ; Sat, 8 Feb 2003 14:32:31 -0500 (EST) 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 OAA14088 for ; Sat, 8 Feb 2003 14:32:31 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA12697 for ; Sat, 8 Feb 2003 14:32:30 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Sat, 08 Feb 2003 14:32:30 -0500 Subject: LL2 comment From: "John C. Welch" To: Zeroconf Message-ID: 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 If this is the incorrect way to respond, I apologize. In addition to this reason: " The reason is because the net manager knows what will, and won't work properly on their net, and can provide advice to the nodes as to what they should do in order to work well in the local environment." There are also environments where the configuration has to be explicitly set / limited. Even where DHCP is used, and would implicitly disable v4LL, that is not enough of a guarantee that v4LL is turned off. I would propose that the default configuration MUST be that v4LL is enabled, and that the first use of this 'switch' would be to turn it off. This way, you have zeroconf by default, yet can ensure it is off, regardless of global address config mechanism. (if you have that need.) Recommendations for the mechanism would include a switch to ifconfig, if appropriate, or a checkbox on a web config page, an option on a cl config screen, etc. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sat Feb 8 15:43:19 2003 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 PAA00245 for ; Sat, 8 Feb 2003 15:43:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1D161912A8; Sat, 8 Feb 2003 15:46:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7F1F912AA; Sat, 8 Feb 2003 15:46:50 -0500 (EST) 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 81F0A912A8 for ; Sat, 8 Feb 2003 15:46:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 66E2E5DD99; Sat, 8 Feb 2003 15:46:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 145295DD93 for ; Sat, 8 Feb 2003 15:46:48 -0500 (EST) Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h18KdmP28478; Sat, 8 Feb 2003 14:39:49 -0600 (CST) Date: Sat, 8 Feb 2003 14:40:23 -0600 Subject: Re: WG consensus action: when to configure LL addrs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Robert Elz , zeroconf@merit.edu To: Mika Liljeberg From: Ted Lemon In-Reply-To: <1044712056.11519.5.camel@devil> Message-Id: <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> The WG already seems agreed that that should not happen, it should be >> one or the other (with the open question of "neither" not relevant >> here). > > I don't. And I've seen comments from others who don't seem to agree > either. Right, I mistakenly interpreted some things that had been said here as indicating that a node would not have a v4ll address if it had another address, but at least according to Stuart I was mistaken. And I certainly don't participate in the supposed consensus that if a host has a non-v4ll address it can't have a v4ll address. From owner-zeroconf@merit.edu Sat Feb 8 16:54:10 2003 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 QAA01503 for ; Sat, 8 Feb 2003 16:54:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 301279122B; Sat, 8 Feb 2003 16:57:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EBED89122C; Sat, 8 Feb 2003 16:57:40 -0500 (EST) 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 BB7F39122B for ; Sat, 8 Feb 2003 16:57:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id A7D1A5DEC6; Sat, 8 Feb 2003 16:57:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by segue.merit.edu (Postfix) with ESMTP id 8631B5DDE7 for ; Sat, 8 Feb 2003 16:57:39 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18hcyf-0007Z5-00; Sat, 08 Feb 2003 13:57:37 -0800 Date: Sat, 8 Feb 2003 16:55:27 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL2 comment Message-Id: <20030208165527.0ff9080b.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > I would propose that the default configuration MUST be that v4LL is enabled, > and that the first use of this 'switch' would be to turn it off. This way, > you have zeroconf by default, yet can ensure it is off, regardless of global > address config mechanism. (if you have that need.) absolutely, totally unacceptable, and without a shred of justification. Keith From owner-zeroconf@merit.edu Sat Feb 8 17:00:23 2003 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 RAA01618 for ; Sat, 8 Feb 2003 17:00:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D9BE89122C; Sat, 8 Feb 2003 17:03:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D744912AA; Sat, 8 Feb 2003 17:03:56 -0500 (EST) 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 3ADAE9122C for ; Sat, 8 Feb 2003 17:02:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1BD2A5DE72; Sat, 8 Feb 2003 17:02:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by segue.merit.edu (Postfix) with ESMTP id E349F5DDE7 for ; Sat, 8 Feb 2003 17:02:41 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18hd1d-00051P-00; Sat, 08 Feb 2003 14:00:41 -0800 Date: Sat, 8 Feb 2003 16:58:31 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, mika.liljeberg@welho.com, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs Message-Id: <20030208165831.5caae827.moore@cs.utk.edu> In-Reply-To: <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> References: <1044712056.11519.5.camel@devil> <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Right, I mistakenly interpreted some things that had been said here as > indicating that a node would not have a v4ll address if it had another > address, but at least according to Stuart I was mistaken. And I > certainly don't participate in the supposed consensus that if a host > has a non-v4ll address it can't have a v4ll address. A node should definitely not automatically use a v4LL address if it has a routable address. There is no good reason for it to do so. Having it do so only increases the complexity of the network and applications and with it, the liklihood of failure. From owner-zeroconf@merit.edu Sun Feb 9 04:30:15 2003 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 EAA23927 for ; Sun, 9 Feb 2003 04:30:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8CAC191201; Sun, 9 Feb 2003 04:33:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5482791205; Sun, 9 Feb 2003 04:33:47 -0500 (EST) 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 1D6B891201 for ; Sun, 9 Feb 2003 04:32:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id C05185DFB8; Sun, 9 Feb 2003 04:32:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 435205DDE0 for ; Sun, 9 Feb 2003 04:32:26 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h199W9n06256; Sun, 9 Feb 2003 16:32:09 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h199Vtb03691; Sun, 9 Feb 2003 16:31:56 +0700 (ICT) From: Robert Elz To: Ted Lemon Cc: Mika Liljeberg , zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs In-Reply-To: <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> References: <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Feb 2003 16:31:55 +0700 Message-ID: <3689.1044783115@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sat, 8 Feb 2003 14:40:23 -0600 From: Ted Lemon Message-ID: <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> | And I | certainly don't participate in the supposed consensus that if a host | has a non-v4ll address it can't have a v4ll address. It has become clear that we need to choose our words very carefully here. No-one (that I recall anyway) is saying that any node "cannot" have a v4ll address. The issue he is that this is zeroconf - in the absence of any configuration a node configures itself a v4LL address. When there is configuration, the node does what the configuration tells it to do. That can be (in some cases) just to configure itself a v4LL address. In other cases it may be to configure itself a routable address, and not to configure a v4LL address. In other cases, it may be to configure both. In still other cases, of course, it could be to configure neither. Thus far, I'd hope, I have said nothing that anyone will object to. That is, if there's anyone out there who is proposing to require that my laptop MUST have some particular kind of address, no matter how I manually configure it, they're in some dreamland. What remains is merely to decide what kinds of configuration information (assuming some exists) should cause a node to adopt one of the strategies different from LL only. Fairly clearly, I hope, manual configuration - that is, the owner/operator of the node explicitly configuring it in some way is the ultimate winner in all debates, and whatever is configured (even if it is totally stupid, like configuring 127.1.2.3/17 on an ethernet) is what wins. Where we have some disagreements, it seems, is with what should be done in cases where there is some configuration, not done manually by the owner of the system. Here the common (and obvious) example is DHCP - but as has been mentioned before, some nodes use RARP, or MOP (or whatever that is), and there's also PPP for serial links that can supply addresses as well. Here, most (though certainly not unanimous) opinion on the list has been that a node that receives an address via one of those other configuration mechanisms should use that address, and not configure a LL address (by default - it can still be instructed to). The reasoning is pretty simple - having one address makes lots of things simpler than having two, and having one that is able to reach more nodes is better than one which reaches less (access controls can still limit access any way desired of course). A routable address can communicate with everything a LL address can communicate with, and more, so having the LL address in addition to the routable one is extra complexity for no gain. If you disagree with this, ask yourself if you really intend that a node that implements LL addressing, is required (absent human config to the contrary of course) to configure itself a LL address on a PPP link, after PPP has assigned it an address to use there (as I understand PPP, which isn't much, I suspect it isn't possible before, as the address, I think, gets assigned during the link setup process). kre From owner-zeroconf@merit.edu Sun Feb 9 04:55:35 2003 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 EAA24252 for ; Sun, 9 Feb 2003 04:55:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 81EFA91205; Sun, 9 Feb 2003 04:59:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4BB639120E; Sun, 9 Feb 2003 04:59:08 -0500 (EST) 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 3D7C291205 for ; Sun, 9 Feb 2003 04:59:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 210E05DFBC; Sun, 9 Feb 2003 04:59:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 308735DDE0 for ; Sun, 9 Feb 2003 04:59:01 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h199wtn09268 for ; Sun, 9 Feb 2003 16:58:56 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h199web03729 for ; Sun, 9 Feb 2003 16:58:40 +0700 (ICT) From: Robert Elz To: zeroconf@merit.edu Subject: [LL7] Add warnings to applicability statement In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Feb 2003 16:58:40 +0700 Message-ID: <3727.1044784720@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sat, 8 Feb 2003 17:40:45 +0100 (CET) From: Erik Guttman Message-ID: | This does not seem to be particularly controversial. A consensus call | on discussion will occur 15 Feb 2003. Just one point... The proposed solution to this issue was to point out that the text already says (in section 1.4) Note that addresses in the 169.254/16 prefix SHOULD NOT be configured manually It might be worth adding text making it clear that this means that people shouldn't go and (attempt to) assign 169.254.3.17 to some host. On the other hand, it does not mean that people should not be able to explicitly (manually) configure a node to run the LL assignment algorithm and have a LL address assigned. I think to fix this, it would be sufficient to have the note included above changed to read Note that specific addresses in the 169.254/16 ... (or s/specific/particular/ or something). A aide issue might be to explicitly assign one (or both) of the currently unused fragments of address space (169.254.0/24 and 169.254.255/24) for manual assignment, so should someone turn up to an ad-hoc network, where LL addresses (and only LL addresses) are in use, they can actually configure themselves one on a system which is too old to implement LL addresses. I know that they could just as easily manually configure 10.1.2.3 and that should work along with appropriate other configuration, but that's harder to explain to people how to do, and why it will work. (Future nodes, that know about LL addressing, should be able to handle the "appropriate extra configuration" automatically, even if the node has no LL address, but old "legacy" systems aren't going to do that). How they figure out which address to configure from a range set aside for this purpose would be beyond the scope of this document - but that's not a problem, for people with legacy systems connecting to an ad-hoc net with no address assignment management have to handle that, one way or another, already. kre From owner-zeroconf@merit.edu Sun Feb 9 05:18:06 2003 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 FAA24887 for ; Sun, 9 Feb 2003 05:18:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 61C2B9120E; Sun, 9 Feb 2003 05:21:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 298139120F; Sun, 9 Feb 2003 05:21:41 -0500 (EST) 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 25B349120E for ; Sun, 9 Feb 2003 05:21:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0A3B65DFB8; Sun, 9 Feb 2003 05:21:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 6EE065DE0B for ; Sun, 9 Feb 2003 05:21:38 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h19ALSn12622 for ; Sun, 9 Feb 2003 17:21:28 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h19ALBb03827 for ; Sun, 9 Feb 2003 17:21:11 +0700 (ICT) From: Robert Elz To: zeroconf@merit.edu Subject: [LL8] Is additional Routing Consideration text needed? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Feb 2003 17:21:11 +0700 Message-ID: <3825.1044786071@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sat, 8 Feb 2003 17:36:48 +0100 (CET) From: Erik Guttman Message-ID: | Please see http://www.spybeam.org/ll8.html | | This does not seem particularly contentious. No, It should not be, but ... | If there is no discussion, | we will accept the recommendation to add no text. I think that response missed the point completely, and isn't adequate. What is currently in the draft (which was pointed out in the response) is text that says that packets using LL addresses must not be forwarded through routers. The issue raised wasn't about that, but about the effect upon routing protocols, and what they should do. By default, most routing protocols will discover what addresses are assigned to links on the router running the protocol, and advertise them to other routers. That is, by default, if a router sees that one of its interfaces has been configured with 169.254.1.1/16 it would advertise 169.254.0.0/16 via RIP, or OSPF, or ... (maybe even BGP in some cases, though that one usually needs to be explicitly told to advertise prefixes). That's clearly not useful, nor what anyone would want. And while it might seem obvious that if packets to/from 169.254/16 can't be forwarded through a router, then the router should not advertise that it knows how to get to that net, the text currently doesn't say that. It easily can, and should. Add somewhere (a new section someplace) Routing Protocols The link local address block (169.254/16) MUST NOT be included as a reachable prefix in any dynamic routing protocol. Subnets of that address block (which should not exist - see sect N.M) MUST NOT be included either. Rewording of that abomination much appreciated (I just can't think of a better way to express it right now). kre From owner-zeroconf@merit.edu Sun Feb 9 05:38:52 2003 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 FAA25324 for ; Sun, 9 Feb 2003 05:38:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4610D9120F; Sun, 9 Feb 2003 05:42:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 17ED491211; Sun, 9 Feb 2003 05:42:26 -0500 (EST) 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 EDA149120F for ; Sun, 9 Feb 2003 05:42:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id D47E25DFB8; Sun, 9 Feb 2003 05:42:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 4E59B5DE0B for ; Sun, 9 Feb 2003 05:42:23 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h19AgHn15756 for ; Sun, 9 Feb 2003 17:42:17 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h19Ag2b03869 for ; Sun, 9 Feb 2003 17:42:02 +0700 (ICT) From: Robert Elz To: zeroconf@merit.edu Subject: [LL11] Add security consideration for the threat where an attacker forces address reconfiguration In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Feb 2003 17:42:02 +0700 Message-ID: <3867.1044787322@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sat, 8 Feb 2003 17:43:49 +0100 (CET) From: Erik Guttman Message-ID: | Please see http://www.spybeam.org/ll11.html | This does not seem like it is a controversial issue. It was suggested | some time ago and has gotten no further comment. Please comment by 15 | Feb 2003 when the issue will be decided. If no comment is made, the | recommended text will be accepted. Everything that is there looks fine - but it doesn't really go far enough in exposing the problem that the subject of this issue raises. I'd ask that the following text also be included in the security considerations section to address this point... Implementations and users should also note that a node that gives up an address and reconfigures, as required by section 2.5, allows the possibility that another node can easily successfully hijack existing TCP connections. Before abandoning an address due to a conflict, hosts SHOULD actively attempt to reset any existing connections using that address. The issue of course, is that on many net technologies where a node has the ability to issue ARP packets, nodes also have the ability to snoop packets. Such a node can, if it desires, watch a TCP connection be established, go through the authentication phase, and then start sending (many) ARP packets claiming to own the address of the system which just authenticated itself. That system (following section 2.5) reconfigures to a new address, leaving the old one available for the node that usurped it. That node has all the information it needs (sequence numbers, port numbers, ...) to successfully masquerade as the node that was previously authenticated. This is a very serious (and new) security issue posed by using LL addresses as demanded in section 2.5. (new in the sense that it doesn't exist in earlier IP stacks - not new to this e-mail of course). At the very least this needs explicit mention in the security considerations. It may be that this is actually serious enough that the algorithm of section 2.5 should just be deleted, and hosts left to continue attempting to use their usurped address (which will might mean, two nodes attempting to communicate with the peer, or one node communicating, and the other being confused, and sending TCP reset - but in any case, generally prevents the worst possibilities of connection hijacking). However, if nodes do actively send RESET from the old address before abandoning it, that would I think be good enough to avoid this. (Sending RESET should also be mentioned in section 2.5 itself). This only deals with TCP, of course, UDP "connections" can still be hijacked this way, there there is no real "reset" that can prevent it. On the other hand, authenticated UDP services are few and far between. Anyone dumb enough to attempt to use NFS (without kerberos or similar, and excepting read only public access) using LL addresses deserves all they receive. kre From owner-zeroconf@merit.edu Sun Feb 9 05:40:20 2003 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 FAA25366 for ; Sun, 9 Feb 2003 05:40:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7D95F91211; Sun, 9 Feb 2003 05:43:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 497369121C; Sun, 9 Feb 2003 05:43:53 -0500 (EST) 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 27CD291211 for ; Sun, 9 Feb 2003 05:43:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 06FA85DFB8; Sun, 9 Feb 2003 05:43:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 57FE45DE0B for ; Sun, 9 Feb 2003 05:43:51 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h19AiPQF020954; Sun, 9 Feb 2003 12:44:26 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h19AiNk9020953; Sun, 9 Feb 2003 12:44:23 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Robert Elz Cc: Ted Lemon , zeroconf@merit.edu In-Reply-To: <3689.1044783115@munnari.OZ.AU> References: <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> <3689.1044783115@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044787452.11519.93.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 09 Feb 2003 12:44:12 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-02-09 at 11:31, Robert Elz wrote: [...] > Where we have some disagreements, it seems, is with what should be done in > cases where there is some configuration, not done manually by the owner of > the system. Here the common (and obvious) example is DHCP - but as has > been mentioned before, some nodes use RARP, or MOP (or whatever that is), > and there's also PPP for serial links that can supply addresses as well. I agree with your summation this far. > Here, most (though certainly not unanimous) opinion on the list has been > that a node that receives an address via one of those other configuration > mechanisms should use that address, and not configure a LL address (by > default - it can still be instructed to). > > The reasoning is pretty simple - having one address makes lots of things > simpler than having two, and having one that is able to reach more nodes > is better than one which reaches less (access controls can still limit > access any way desired of course). A routable address can communicate > with everything a LL address can communicate with, The reasoning here is perhaps too simple. It holds only if ALL nodes on the link will have a routable address. I don't think this is necessarily true. In general, a routable address can only be used to communicate safely with other routable addresses. Note well: the only reliable way to recognize a v4LL compliant destination is from the fact that it has a v4LL address. In all other cases, it is unsafe to use a v4LL source address, because the destination might be non-v4LL compliant and could send its response packets to a router instead. > and more, so having the > LL address in addition to the routable one is extra complexity for no gain. What of implementation complexity? From an implementation perspective having all these special conditions on when v4LL addresses can be configured only adds to complexity. I'm not being the "lazy engineer" here. A good engineer works very very hard to arrive at a simple design. Implementation complexity is usually a sign of bad design. > If you disagree with this, ask yourself if you really intend that a node > that implements LL addressing, is required (absent human config to the > contrary of course) to configure itself a LL address on a PPP link, after > PPP has assigned it an address to use there (as I understand PPP, which > isn't much, I suspect it isn't possible before, as the address, I think, > gets assigned during the link setup process). No, of course not. Zeroconf is only applicable to links that use ARP. PPP doesn't. With PPP you'd use either routable or private addresses, negotiated as part of the IPCP handshake. MikaL From owner-zeroconf@merit.edu Sun Feb 9 05:47:01 2003 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 FAA25448 for ; Sun, 9 Feb 2003 05:47:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1DB3D9121C; Sun, 9 Feb 2003 05:50:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DBA649121F; Sun, 9 Feb 2003 05:50:34 -0500 (EST) 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 C542A9121C for ; Sun, 9 Feb 2003 05:50:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC7005DE0B; Sun, 9 Feb 2003 05:50:33 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id A0A805DDB6 for ; Sun, 9 Feb 2003 05:50:32 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h19Ap9QF020992; Sun, 9 Feb 2003 12:51:09 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h19Ap5vh020991; Sun, 9 Feb 2003 12:51:05 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [LL7] Add warnings to applicability statement From: Mika Liljeberg To: Robert Elz Cc: zeroconf@merit.edu In-Reply-To: <3727.1044784720@munnari.OZ.AU> References: <3727.1044784720@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044787864.11519.98.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 09 Feb 2003 12:51:05 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-02-09 at 11:58, Robert Elz wrote: > The proposed solution to this issue was to point out that the text > already says (in section 1.4) > > Note that addresses in the 169.254/16 prefix SHOULD NOT be configured > manually Incidentally I think the text in 1.4: "Note that addresses in the 169.254/16 prefix SHOULD NOT be configured manually or by a DHCP server." Should be clarified to: "Note that addresses in the 169.254/16 prefix SHOULD NOT be configured manually, by a DHCP server, or by any mechanism other than the one described in this document." The plugs a perceived loop hole regarding address configuration methods other than v4LL, DHCP, or manual configuration. Can we do this as part of LL7 or should I file another issue? MikaL From owner-zeroconf@merit.edu Sun Feb 9 05:53:51 2003 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 FAA25552 for ; Sun, 9 Feb 2003 05:53:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B4869121F; Sun, 9 Feb 2003 05:57:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F10C091223; Sun, 9 Feb 2003 05:57:24 -0500 (EST) 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 050C09121F for ; Sun, 9 Feb 2003 05:57:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id E286B5DE0B; Sun, 9 Feb 2003 05:57:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 7D5145DDB6 for ; Sun, 9 Feb 2003 05:57:22 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h19AvHn17084 for ; Sun, 9 Feb 2003 17:57:17 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h19Av8b03912 for ; Sun, 9 Feb 2003 17:57:08 +0700 (ICT) From: Robert Elz To: zeroconf@merit.edu Subject: Proposed text for LL2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Feb 2003 17:57:08 +0700 Message-ID: <3910.1044788228@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Here's some text that could be added to the document to deal with issue LL2. I'd suggest adding it as a new section 1.3 between what is now 1.2 and 1.3 (making 1.3 become 1.4, and so on, of course). 1.3 Alternate Configuration Mechanisms As explained in the previous section (1.2), the link-local addresses assigned by this protocol are intended for small ad-hoc networks. However, it is very rare for a system to be constructed that can only ever be connected to such networks. When connected to a properly managed network, nodes should operate correctly for that network. To allow for this, all nodes that implement this protocol MUST also provide some mechanism to allow for routable addresses to be configured. That mechanism MAY use the DHCP protocol [RFC2131] in appropriate cases, but other means, such as manual configuration, are also adequate. Many nodes using this protocol, on large networks, can cause excessive traffic as explained in the previous section (1.2). For this reason, and others, it can be necessary to disable use of link-local addresses in some situations where they are not required. The configuration mechanism provided MUST provide a mechanism to disable the assignment of link local addresses on an interface. Where that configuration mechanism uses DHCP, the node MUST implement the DHCP option to disable stateless auto-configuration in IPv4 clients [RFC2563]. From owner-zeroconf@merit.edu Sun Feb 9 06:23:10 2003 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 GAA25981 for ; Sun, 9 Feb 2003 06:23:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 19FE991223; Sun, 9 Feb 2003 06:26:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3E8791224; Sun, 9 Feb 2003 06:26:44 -0500 (EST) 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 AB3CC91223 for ; Sun, 9 Feb 2003 06:26:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B42C5DFBE; Sun, 9 Feb 2003 06:26:43 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 0FBC45DE0B for ; Sun, 9 Feb 2003 06:26:42 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h19BQVn21216; Sun, 9 Feb 2003 18:26:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h19BQFb04302; Sun, 9 Feb 2003 18:26:15 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs In-Reply-To: <1044787452.11519.93.camel@devil> References: <1044787452.11519.93.camel@devil> <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> <3689.1044783115@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Feb 2003 18:26:15 +0700 Message-ID: <4300.1044789975@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 09 Feb 2003 12:44:12 +0200 From: Mika Liljeberg Message-ID: <1044787452.11519.93.camel@devil> | The reasoning here is perhaps too simple. It holds only if ALL nodes on | the link will have a routable address. No, it doesn't. | I don't think this is necessarily true. I agree with that. | In general, a routable address can only be used to communicate safely | with other routable addresses. No, a routable address can communicate perfectly well with a LL address. | Note well: the only reliable way to recognize a v4LL compliant | destination is from the fact that it has a v4LL address. That isn't a reliable way. I can easily manually configure an address that looks like a LL address on any ancient node, and what's more, will do exactly that if it turns out to be the easy way to get that node talking to other newer ones on some ad-hoc net. | In all other | cases, it is unsafe to use a v4LL source address, because the | destination might be non-v4LL compliant and could send its response | packets to a router instead. Yes, that might happen. But so what? If the router is "doing the right thing" all this will mean is that the response will get dropped at the router (though there have been suggestions in this group that to avoid that, routers be permitted to forward such packets back onto the link from which they originated - I see no real problem with that). But even if the router knows nothing about LL addresses either, and hasn't even been configured to filter them, all it can end up doing is forwarding the packet aimlessly toward the network core, where it should die for lack of a route. This is no different to what would happen without LL addresses, if one node on a net is misconfigured. There's no real harm from this - communication doesn't work, but nor would it using your proposal. On the other hand, allowing communication between LL and routable addresses allows communication to succeed in many cases where your proposal prevents it. | What of implementation complexity? Every time an address is to be used, the node needs to choose one. What's more, applications that care about addresses also get to see more than one, and also need to choose which they use. A DNS server would typically have to listen on 2 sockets (and yes, the code to do that is there already but it still means extra overhead). | From an implementation perspective | having all these special conditions on when v4LL addresses can be | configured only adds to complexity. Unless you're demanding that every node MUST always configure a LL address, even if I, the owner of the node, want to explicitly configure it not to, there already needs to be a mechanism to disable it. "All these special conditions" (for which there really aren't many in that "all") amount to no more than setting the switch which really already has to be there. | No, of course not. Zeroconf is only applicable to links that use ARP. No it isn't. The current document only defines how to do it on links that use ARP, but do see section 1.2 ... Link-layer network technologies that do not support ARP may be able to use other techniques for determining whether a particular IP address is currently in use. However, the application of claim-and- defend mechanisms to such networks is left to a future document. PPP could trivially define an option to negotiate LL addresses (it does already for IPv6 I believe, though as I said, PPP is outside my area of expertise). Once LL addresses exist, I see no reason the PPP people would not go ahead and define the mechanism. After all, that allows ad-hoc PPP links to be established between two nodes, with no configuration required at either end. kre From owner-zeroconf@merit.edu Sun Feb 9 07:23:57 2003 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 HAA27006 for ; Sun, 9 Feb 2003 07:23:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5720A91224; Sun, 9 Feb 2003 07:27:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2714891227; Sun, 9 Feb 2003 07:27:29 -0500 (EST) 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 DE36591224 for ; Sun, 9 Feb 2003 07:27:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id B9B545DFD6; Sun, 9 Feb 2003 07:27:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id CE0075DDC9 for ; Sun, 9 Feb 2003 07:27:26 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h19CS3QF021384; Sun, 9 Feb 2003 14:28:03 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h19CS2lu021382; Sun, 9 Feb 2003 14:28:02 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Robert Elz Cc: zeroconf@merit.edu In-Reply-To: <4300.1044789975@munnari.OZ.AU> References: <1044787452.11519.93.camel@devil> <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> <3689.1044783115@munnari.OZ.AU> <4300.1044789975@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044793681.21186.107.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 09 Feb 2003 14:28:02 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-02-09 at 13:26, Robert Elz wrote: > Date: 09 Feb 2003 12:44:12 +0200 > From: Mika Liljeberg > Message-ID: <1044787452.11519.93.camel@devil> > > | The reasoning here is perhaps too simple. It holds only if ALL nodes on > | the link will have a routable address. > > No, it doesn't. > > | I don't think this is necessarily true. > > I agree with that. > > | In general, a routable address can only be used to communicate safely > | with other routable addresses. > > No, a routable address can communicate perfectly well with a LL address. Only if both nodes are v4LL compliant. It is not safe to talk to a non-v4LL node using a v4LL address. I'm expecting networks to have a lot of non-v4LL compliant nodes. > | Note well: the only reliable way to recognize a v4LL compliant > | destination is from the fact that it has a v4LL address. > > That isn't a reliable way. I can easily manually configure an address > that looks like a LL address on any ancient node, and what's more, will > do exactly that if it turns out to be the easy way to get that node > talking to other newer ones on some ad-hoc net. Ahh, manual configuration. You can always shoot yourself in the foot, no? The draft already says that v4LL addresses should not be configured manually. > | In all other > | cases, it is unsafe to use a v4LL source address, because the > | destination might be non-v4LL compliant and could send its response > | packets to a router instead. > > Yes, that might happen. But so what? If the router is "doing the > right thing" all this will mean is that the response will get dropped > at the router (though there have been suggestions in this group that to > avoid that, routers be permitted to forward such packets back onto the > link from which they originated - I see no real problem with that). So you say all routers should be v4LL compliant? Yeah, you can blackhole it manually. Despite best efforts to the contrary even private addresses still leak out all the time. Again: I'm expecting a *lot* of non-v4LL comliant nodes out there. > But even if the router knows nothing about LL addresses either, and > hasn't even been configured to filter them, all it can end up doing > is forwarding the packet aimlessly toward the network core, where it > should die for lack of a route. This is no different to what would > happen without LL addresses, if one node on a net is misconfigured. I'd wager you would *not* want to be the poor bastard who is at the receiving end of that black hole. > There's no real harm from this - communication doesn't work, but nor > would it using your proposal. On the other hand, allowing communication > between LL and routable addresses allows communication to succeed in many > cases where your proposal prevents it. > > | What of implementation complexity? > > Every time an address is to be used, the node needs to choose one. We already do that. Not a big deal. > What's more, applications that care about addresses also get to > see more than one, and also need to choose which they use. Where do these addresses come from? They always come from: a) manual configuration You can always shoot yourself in the foot. b) a name resolution process. Normal (stupid) applications usually take the first address they get from the resolver. It is a simple matter to implement name resolver APIs on v4LL compliant nodes in such a way that they always return routable addresses first. c) a communicating peer as part of the application layer protocol Ask yourself where the peer got the address. Repeat until you get either a) or b) as the answer. > A DNS > server would typically have to listen on 2 sockets (and yes, the code > to do that is there already but it still means extra overhead). Any v4LL compliant node with a routable address will use that to communicate with DNS. So, you need to do this only if you want to support DNS for nodes that only have a v4LL address. > | From an implementation perspective > | having all these special conditions on when v4LL addresses can be > | configured only adds to complexity. > > Unless you're demanding that every node MUST always configure a LL > address, even if I, the owner of the node, want to explicitly > configure it not to, there already needs to be a mechanism to > disable it. > "All these special conditions" (for which there really aren't many > in that "all") amount to no more than setting the switch which really > already has to be there. I'm not opposed to manual configuration. I was talking about the implementation dependencies to other automated mechanisms that have been proposed. I can see that network admins might want to disable the use of v4LL completely on their networks, but I submit that network management software is beyond the scope of this WG. > | No, of course not. Zeroconf is only applicable to links that use ARP. > > No it isn't. The current document only defines how to do it on links > that use ARP, but do see section 1.2 ... Right, I had a careless turn of phrase there. What I meant is that this specification is limited to links that use ARP. To address your earlier argument: I am not saying that "every v4LL-compliant node MUST have a v4LL address". I am saying: - A node MUST be allowed to have a v4LL together with a routable address on the same interface - A node MUST NOT use the v4LL address when communicating with a non-v4LL compliant node - PLEASE don't create unnecessary implementation dependencies between v4LL and other address configuration mechanisms I hope I made my position clear on that. :) MikaL From owner-zeroconf@merit.edu Sun Feb 9 08:10:38 2003 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 IAA27807 for ; Sun, 9 Feb 2003 08:10:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 446F591214; Sun, 9 Feb 2003 08:14:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 145AF91218; Sun, 9 Feb 2003 08:14:11 -0500 (EST) 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 E7EEA91214 for ; Sun, 9 Feb 2003 08:14:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id D044E5DE6F; Sun, 9 Feb 2003 08:14:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 2525B5DE16 for ; Sun, 9 Feb 2003 08:14:09 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h19DEjQF021565; Sun, 9 Feb 2003 15:14:45 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h19DEipc021564; Sun, 9 Feb 2003 15:14:44 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Proposed text for LL2 From: Mika Liljeberg To: Robert Elz Cc: zeroconf@merit.edu In-Reply-To: <3910.1044788228@munnari.OZ.AU> References: <3910.1044788228@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044796483.21383.156.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 09 Feb 2003 15:14:43 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-02-09 at 12:57, Robert Elz wrote: > Here's some text that could be added to the document to deal with > issue LL2. LL2 isn't officially up for discussion yet, but since you started... > I'd suggest adding it as a new section 1.3 between what is now 1.2 and > 1.3 (making 1.3 become 1.4, and so on, of course). > > > 1.3 Alternate Configuration Mechanisms > > As explained in the previous section (1.2), the link-local addresses > assigned by this protocol are intended for small ad-hoc networks. > However, it is very rare for a system to be constructed that can > only ever be connected to such networks. When connected to a > properly managed network, nodes should operate correctly for that > network. > > To allow for this, all nodes that implement this protocol MUST also > provide some mechanism to allow for routable addresses to be configured. > That mechanism MAY use the DHCP protocol [RFC2131] in appropriate cases, > but other means, such as manual configuration, are also adequate. A very restricted device that is never intended to operate in a routed network might not need anything besides v4LL. If this paragraph is needed at all, I suggest rewording "nodes that are likely to be connected into a managed network ...". > Many nodes using this protocol, on large networks, can cause excessive > traffic as explained in the previous section (1.2). For this reason, > and others, it can be necessary to disable use of link-local addresses > in some situations where they are not required. The configuration > mechanism provided MUST provide a mechanism to disable the assignment > of link local addresses on an interface. Where that configuration > mechanism uses DHCP, the node MUST implement the DHCP option to disable > stateless auto-configuration in IPv4 clients [RFC2563]. I guess I've already made clear what I think about mechanisms like this. The problem with this is that it creates an unnecessary dependency between DHCP and v4LL configuration. If something like this is considered mandatory, it should be defined as part of the v4LL mechanism itself rather than as part of every other potential mechanism. MikaL From owner-zeroconf@merit.edu Sun Feb 9 08:16:23 2003 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 IAA27925 for ; Sun, 9 Feb 2003 08:16:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7024691218; Sun, 9 Feb 2003 08:19:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DFA091227; Sun, 9 Feb 2003 08:19:55 -0500 (EST) 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 4C26691218 for ; Sun, 9 Feb 2003 08:19:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 391E15DDE0; Sun, 9 Feb 2003 08:19:54 -0500 (EST) 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 D55945DEF5 for ; Sun, 9 Feb 2003 08:19:53 -0500 (EST) 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 GAA03848; Sun, 9 Feb 2003 06:19:52 -0700 (MST) 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 h19DJol18040; Sun, 9 Feb 2003 14:19:50 +0100 (MET) Date: Sun, 9 Feb 2003 14:19:48 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Mika Liljeberg Cc: Robert Elz , zeroconf@merit.edu Subject: issue discussion procedure In-Reply-To: <1044787864.11519.98.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > The plugs a perceived loop hole regarding address configuration methods > other than v4LL, DHCP, or manual configuration. > > Can we do this as part of LL7 or should I file another issue? This is part of the discussion of LL7. As long as we are all pulling on the same rope, we'll hone the text, agree, Accept and close the issue. If we have contention, we have five possible avenues - in descending order of preference. 1. There is a clear technical answer. Dissenters are dismissed. 2. There is no clear technical answer. One group overwhelms the other. We go with rough consensus. This is for yes/no questions. NOTE: We try to deal with each issue as a yes/no issue first since it is much easier to understand this and conclude discussion. 3. The dissenter posts a competing issue. We choose the group with overwhelming support. This is for multiple choice questions. 4. We have a split we cannot overcome and even make a rough consenus call. Can we drop the goal, accomodate or compromise? 5. We have a split, with no rough consensus possible. We fail. Throw up our hands and let a thousand mutant flowers blossom. Comments? Erik From owner-zeroconf@merit.edu Sun Feb 9 08:31:00 2003 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 IAA28152 for ; Sun, 9 Feb 2003 08:31:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC3DE91227; Sun, 9 Feb 2003 08:34:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 803A591228; Sun, 9 Feb 2003 08:34:32 -0500 (EST) 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 259A191227 for ; Sun, 9 Feb 2003 08:34:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0D3925DF69; Sun, 9 Feb 2003 08:34:31 -0500 (EST) 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 7ABE25DE16 for ; Sun, 9 Feb 2003 08:34:30 -0500 (EST) 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 FAA15621; Sun, 9 Feb 2003 05:34:23 -0800 (PST) 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 h19DYMl18400; Sun, 9 Feb 2003 14:34:22 +0100 (MET) Date: Sun, 9 Feb 2003 14:34:20 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Mika Liljeberg Cc: Robert Elz , zeroconf@merit.edu Subject: Re: Proposed text for LL2 In-Reply-To: <1044796483.21383.156.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On 9 Feb 2003, Mika Liljeberg wrote: > On Sun, 2003-02-09 at 12:57, Robert Elz wrote: > > Here's some text that could be added to the document to deal with > > issue LL2. > > LL2 isn't officially up for discussion yet, but since you started... > > As explained in the previous section (1.2), the link-local addresses > > assigned by this protocol are intended for small ad-hoc networks. > > However, it is very rare for a system to be constructed that can > > only ever be connected to such networks. When connected to a > > properly managed network, nodes should operate correctly for that > > network. > > > > To allow for this, all nodes that implement this protocol MUST also > > provide some mechanism to allow for routable addresses to be configured. > > That mechanism MAY use the DHCP protocol [RFC2131] in appropriate cases, > > but other means, such as manual configuration, are also adequate. > > A very restricted device that is never intended to operate in a routed > network might not need anything besides v4LL. If this paragraph is > needed at all, I suggest rewording "nodes that are likely to be > connected into a managed network ...". [WG chair hat off, WG participant hat on.] The WG has members who assert there is a use case for a v4LL only device. This group will probably not accept any text which states that configuration is required. The IESG on the other hand will likely reject a document which is seen to promote v4LL-only devices as a recommended configuration. The MUST above can be satisified by vendors in different ways (i.e. a device can receive a protocol message which assigns parameters. Common example: The device maintains a web server which allows posting of new parameters.) Please bear this in mind when responding to Robert. > > Many nodes using this protocol, on large networks, can cause excessive > > traffic as explained in the previous section (1.2). For this reason, > > and others, it can be necessary to disable use of link-local addresses > > in some situations where they are not required. The configuration > > mechanism provided MUST provide a mechanism to disable the assignment > > of link local addresses on an interface. Where that configuration > > mechanism uses DHCP, the node MUST implement the DHCP option to disable > > stateless auto-configuration in IPv4 clients [RFC2563]. [WG chair hat on] Robert, thanks for the text suggestion. It helps to have a concrete proposal to consider. I will post it today. I will wait to announce a 1 week discussion call until we have alternative text. This is the central issue we have to resolve. Erik From owner-zeroconf@merit.edu Sun Feb 9 08:38:27 2003 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 IAA28298 for ; Sun, 9 Feb 2003 08:38:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BB4B691228; Sun, 9 Feb 2003 08:42:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8112A9122B; Sun, 9 Feb 2003 08:42:00 -0500 (EST) 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 5C72691228 for ; Sun, 9 Feb 2003 08:41:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3E4225DF69; Sun, 9 Feb 2003 08:41:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id CD5F65DEF5 for ; Sun, 9 Feb 2003 08:41:57 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h19Dfkn08943; Sun, 9 Feb 2003 20:41:47 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h19Dfcb04800; Sun, 9 Feb 2003 20:41:38 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs In-Reply-To: <1044793681.21186.107.camel@devil> References: <1044793681.21186.107.camel@devil> <1044787452.11519.93.camel@devil> <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> <3689.1044783115@munnari.OZ.AU> <4300.1044789975@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Feb 2003 20:41:38 +0700 Message-ID: <4798.1044798098@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 09 Feb 2003 14:28:02 +0200 From: Mika Liljeberg Message-ID: <1044793681.21186.107.camel@devil> | Only if both nodes are v4LL compliant. It is not safe to talk to a | non-v4LL node using a v4LL address. I believe it is safe enough. | I'm expecting networks to have a lot of non-v4LL compliant nodes. Yes, agreed. | Ahh, manual configuration. You can always shoot yourself in the foot, | no? Yes, you can, but you can also make things work that way where they would have failed other ways. But where this came up was that you said that noticing LL addresses was a reliable way to detect that the destination understands what LL means. I was just pointing out that that is not so - it is not reliable. | The draft already says that v4LL addresses should not be configured | manually. And given a choice between failing to communicate, and doing what a draft or RFC (that the user probably hasn't ever heard of) says, which do you expect to happen? | So you say all routers should be v4LL compliant? No, that isn't what I said at all. | Yeah, you can blackhole it manually. Despite best efforts to the | contrary even private addresses still leak out all the time. Of course. Part of the issue there naturally is that routers cannot block 1918 addresses by default, whereas they can block LL's, so at least new router (software) will be able to assist. But of course that will take a long time to get deployed. | Again: I'm expecting a *lot* of non-v4LL comliant nodes out there. yes. | I'd wager you would *not* want to be the poor bastard who is at the | receiving end of that black hole. The receiving end of the black hole is a LL address, remember. Which poor bastard would that actually be ? People send packets to bogus addresses all the time - they don't get answered, for the vast majority of these cases, the node sends a few packets, spaced by varying amounts, and then gives up. This one just happens to be an easy one to deal with, as the dest addr is one that manifestly cannot reach anyone useful, once it has passed through a router. So even if the site in question hasn't blackholed it, their ISP can (and if there's enough of such bogus traffic, almost certainly will - it avoids traffic on their links). If there's not enough of it for them to notice (from all their customers combined), why would we care? | So, you need to do this only if you want to support DNS for nodes that | only have a v4LL address. No, I meant running a DNS server on a node which would normally have just a routable address, but which you want to demand have a LL address as well so it can communicate with LL-only nodes. NB: it is not the DNS server application that wants to communicate with the LL nodes, as you say, they're unlikely to be using DNS anyway (though they might, but that's not important here). Some other applocation on the node wants to communicate with LL only nodes. So, the node has to have 2 addresses (your theory) - which now the DNS server needs to deal with, for no reason worth knowing. This is just an example of the extra complexity. | I'm not opposed to manual configuration. I was talking about the | implementation dependencies to other automated mechanisms that have been | proposed. The other mechanism proposed is that when a node configures some other address, it turns off LL by default. That means, as part of the addr config mechanism you set the "no LL" switch for the interface. This really sounds difficult... | I can see that network admins might want to disable the use of v4LL | completely on their networks, but I submit that network management | software is beyond the scope of this WG. Network management software??? What has that to do with anything? The issue (an issue) is whether or not a node should configure a LL address, having it configured, and then disabled with some random other software is not at all appropriate. Not configured, means not configured (at all). | Right, I had a careless turn of phrase there. What I meant is that this | specification is limited to links that use ARP. no, not even that. Most of what is there applies to LL addresses in general. The only part of it that is specific to ARP networks is that part that describes how to probe and defend addresses. | To address your earlier argument: I am not saying that "every | v4LL-compliant node MUST have a v4LL address". I am saying: | - A node MUST be allowed to have a v4LL together with a routable address | on the same interface I don't have a problem with that, if a node wants to have both, and is configured to have both, that's fine. | - A node MUST NOT use the v4LL address when communicating with a | non-v4LL compliant node I disagree with that. | - PLEASE don't create unnecessary implementation dependencies between | v4LL and other address configuration mechanisms Address configuration mechanisms (of whatever kind) assuming there is more than one of them (and there clearly is) have all kinds of dependencies between them. That's unavoidable - they're all configuring essentially the same thing, so they have to interact. kre From owner-zeroconf@merit.edu Sun Feb 9 09:00:21 2003 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 JAA28646 for ; Sun, 9 Feb 2003 09:00:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 363C69122B; Sun, 9 Feb 2003 09:03:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 042F89122C; Sun, 9 Feb 2003 09:03:46 -0500 (EST) 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 1AAA89122B for ; Sun, 9 Feb 2003 09:03:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 08ACB5DF69; Sun, 9 Feb 2003 09:03:46 -0500 (EST) 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 826D65DE4A for ; Sun, 9 Feb 2003 09:03:45 -0500 (EST) 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 GAA23561 for ; Sun, 9 Feb 2003 06:03:44 -0800 (PST) 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 h19E3gl19134 for ; Sun, 9 Feb 2003 15:03:42 +0100 (MET) Date: Sun, 9 Feb 2003 15:03:41 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG action - 1 week to discuss [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Please see http://www.spybeam.org/ll17.html This issue evoked no comment during the not-very-successful recent "WG consensus action: when to configure LL addrs" Just to verify that it has been accepted, please consider this issue before 16 Feb 2003. If there is no comment, we will assume it is acceptable. Erik From owner-zeroconf@merit.edu Sun Feb 9 09:18:24 2003 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 JAA29076 for ; Sun, 9 Feb 2003 09:18:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 680139122C; Sun, 9 Feb 2003 09:21:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31D6691232; Sun, 9 Feb 2003 09:21:58 -0500 (EST) 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 4813C9122C for ; Sun, 9 Feb 2003 09:21:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 304055DFED; Sun, 9 Feb 2003 09:21:57 -0500 (EST) 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 C1DE75DFEB for ; Sun, 9 Feb 2003 09:21:56 -0500 (EST) 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 HAA07970; Sun, 9 Feb 2003 07:21:55 -0700 (MST) 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 h19ELrl19642; Sun, 9 Feb 2003 15:21:53 +0100 (MET) Date: Sun, 9 Feb 2003 15:21:51 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Robert Elz Cc: zeroconf@merit.edu, erik.nordmark@sun.com Subject: Re: [LL11] Add security consideration for the threat where an attacker forces address reconfiguration In-Reply-To: <3867.1044787322@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Robert suggests we add: On Sun, 9 Feb 2003, Robert Elz wrote: > Implementations and users should also note that a node that > gives up an address and reconfigures, as required by section 2.5, > allows the possibility that another node can easily successfully > hijack existing TCP connections. Before abandoning an address > due to a conflict, hosts SHOULD actively attempt to reset any > existing connections using that address. [WG chair hat off, WG participant hat on] Looks good to me! [WG chair hat on] When suggesting text, please put it front and center and separate it from argumentation. Erik ----- Brevity is the soul of wit. From owner-zeroconf@merit.edu Sun Feb 9 09:27:38 2003 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 JAA29223 for ; Sun, 9 Feb 2003 09:27:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B469791232; Sun, 9 Feb 2003 09:30:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63D4291235; Sun, 9 Feb 2003 09:30:34 -0500 (EST) 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 CCAEE91232 for ; Sun, 9 Feb 2003 09:30:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 324245DE4A; Sun, 9 Feb 2003 09:30:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 558E25DFED for ; Sun, 9 Feb 2003 09:30:27 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h19EULn15026 for ; Sun, 9 Feb 2003 21:30:21 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h19EU9b05132 for ; Sun, 9 Feb 2003 21:30:09 +0700 (ICT) From: Robert Elz To: zeroconf@merit.edu Subject: Re: [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Feb 2003 21:30:08 +0700 Message-ID: <5130.1044801008@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 9 Feb 2003 15:03:41 +0100 (CET) From: Erik Guttman Message-ID: | Please see http://www.spybeam.org/ll17.html I agree with that one as proposed. kre From owner-zeroconf@merit.edu Sun Feb 9 09:33:55 2003 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 JAA29396 for ; Sun, 9 Feb 2003 09:33:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2B34091235; Sun, 9 Feb 2003 09:37:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E935891237; Sun, 9 Feb 2003 09:37:27 -0500 (EST) 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 EF2DF91235 for ; Sun, 9 Feb 2003 09:37:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id C848A5DFEB; Sun, 9 Feb 2003 09:37:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id DFF5B5DF69 for ; Sun, 9 Feb 2003 09:37:08 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h19Eb0n16073; Sun, 9 Feb 2003 21:37:00 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h19Eafb05146; Sun, 9 Feb 2003 21:36:41 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: Re: Proposed text for LL2 In-Reply-To: <1044796483.21383.156.camel@devil> References: <1044796483.21383.156.camel@devil> <3910.1044788228@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Feb 2003 21:36:41 +0700 Message-ID: <5144.1044801401@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 09 Feb 2003 15:14:43 +0200 From: Mika Liljeberg Message-ID: <1044796483.21383.156.camel@devil> | LL2 isn't officially up for discussion yet, but since you started... No, If I was going to argue it, you would have seen a completely different message. All I was doing there was responding to Erik's request for proposed text for LL2, LL4, LL5 and LL15. (See the message with the Subject "Issues clean up and text needed"). That was suggested text for LL2. I'm not going to bother with LL4, LLl5 or LL15, those three I consider to be typical IESG noise, and not worth spending any effort on. On the other hand, since they are typical IESG noise, if no-one spends any effort on them, the IESG will probably just keep holding up the document forever... (Note: this isn't saying that none of the points from the IESG are worth effort, I am referring exclusively to those three). I won't respond to the rest of your message until we actually are debating LL2. Erik: it probably would be better if this one were left until after LL23 (or whatever it gets to be called when it is posted) is dealt with. kre From owner-zeroconf@merit.edu Sun Feb 9 10:08:58 2003 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 KAA00058 for ; Sun, 9 Feb 2003 10:08:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0E50C91237; Sun, 9 Feb 2003 10:12:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D005191238; Sun, 9 Feb 2003 10:12:30 -0500 (EST) 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 6877191237 for ; Sun, 9 Feb 2003 10:12:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F4435DFFC; Sun, 9 Feb 2003 10:12:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 7D31A5DFF7 for ; Sun, 9 Feb 2003 10:12:27 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h19FD2QF021969; Sun, 9 Feb 2003 17:13:03 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h19FCxuq021968; Sun, 9 Feb 2003 17:12:59 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Robert Elz Cc: zeroconf@merit.edu In-Reply-To: <4798.1044798098@munnari.OZ.AU> References: <1044793681.21186.107.camel@devil> <1044787452.11519.93.camel@devil> <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> <3689.1044783115@munnari.OZ.AU> <4300.1044789975@munnari.OZ.AU> <4798.1044798098@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044803577.21383.233.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 09 Feb 2003 17:12:59 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-02-09 at 15:41, Robert Elz wrote: > Date: 09 Feb 2003 14:28:02 +0200 > From: Mika Liljeberg > Message-ID: <1044793681.21186.107.camel@devil> > > | Only if both nodes are v4LL compliant. It is not safe to talk to a > | non-v4LL node using a v4LL address. > > I believe it is safe enough. Are you saying that we should relax the admonishment that v4LL addresses should not be configured manually? > | I'm expecting networks to have a lot of non-v4LL compliant nodes. > > Yes, agreed. > > | Ahh, manual configuration. You can always shoot yourself in the foot, > | no? > > Yes, you can, but you can also make things work that way where they would > have failed other ways. Meaning, you can allow nodes that only have a v4LL address to converse with non-v4LL compliant nodes that have a manually configured v4LL address. That is clearly a fringe case. The failure mode here is very simple to understand. That is not true of the alternative. > But where this came up was that you said that noticing LL addresses was > a reliable way to detect that the destination understands what LL means. > I was just pointing out that that is not so - it is not reliable. > > | The draft already says that v4LL addresses should not be configured > | manually. > > And given a choice between failing to communicate, and doing what a > draft or RFC (that the user probably hasn't ever heard of) says, which > do you expect to happen? I expect the implementations to do what the RFC says. Why else do we write these things? As for users, we can't protect them from stupidity. What we can do, is make sure v4LL nodes in routed networks will try to get a routable address and use that whenever they connect to another routable address. That way your special case above won't even come up. > | Yeah, you can blackhole it manually. Despite best efforts to the > | contrary even private addresses still leak out all the time. > > Of course. Part of the issue there naturally is that routers cannot > block 1918 addresses by default, whereas they can block LL's, so at > least new router (software) will be able to assist. But of course > that will take a long time to get deployed. Exactly. > | Again: I'm expecting a *lot* of non-v4LL comliant nodes out there. > > yes. > > | I'd wager you would *not* want to be the poor bastard who is at the > | receiving end of that black hole. > > The receiving end of the black hole is a LL address, remember. Which > poor bastard would that actually be ? Does it matter? If the packets escape the link they must end up somewhere and use up someone's bandwith, as will the ICMP errors coming back. > People send packets to bogus addresses all the time - they don't get > answered, for the vast majority of these cases, the node sends a few > packets, spaced by varying amounts, and then gives up. This usually only happens when someone mistypes an address. What you're proposing is of a different magnitude completely. Frankly, I think this is a far more serious problem than providing no connectivity between v4LL nodes that have no routable address and non-v4LL compliant nodes. If you disagree, then we have a difference of opinion that cannot be resolved on technical grounds. > This one just happens to be an easy one to deal with, as the dest addr > is one that manifestly cannot reach anyone useful, once it has passed > through a router. So even if the site in question hasn't blackholed it, > their ISP can (and if there's enough of such bogus traffic, almost > certainly will - it avoids traffic on their links). If there's not > enough of it for them to notice (from all their customers combined), > why would we care? > > | So, you need to do this only if you want to support DNS for nodes that > | only have a v4LL address. > > No, I meant running a DNS server on a node which would normally have > just a routable address, but which you want to demand have a LL address > as well so it can communicate with LL-only nodes. A DNS server doesn't need an LL address (although it could have one). v4LL-compliant nodes should acquire a routable address when they are part of a routed network. If they don't, they have no business talking to DNS anyway, or trying to connect to any addresses that they would get from DNS, which are more than likely to be unreachable (behind a router). > NB: it is not the > DNS server application that wants to communicate with the LL nodes, as > you say, they're unlikely to be using DNS anyway (though they might, but > that's not important here). Some other applocation on the node wants > to communicate with LL only nodes. So, the node has to have 2 addresses > (your theory) - which now the DNS server needs to deal with, for no > reason worth knowing. This is just an example of the extra complexity. Actually, the DNS server only needs to deal with routable addresses. You *don't* want to put LL addresses into DNS. v4LL addresses will be resolved with something like Rendezvous or Link-local Multicast Name Resolution, anyway. The DNS server has no part in that. > | I'm not opposed to manual configuration. I was talking about the > | implementation dependencies to other automated mechanisms that have been > | proposed. > > The other mechanism proposed is that when a node configures some other > address, it turns off LL by default. That means, as part of the addr > config mechanism you set the "no LL" switch for the interface. > > This really sounds difficult... To do it gracefully requires that the node support two addresses per interface, even if one of the addresses is in deprecated state. This is how I would implement it if I had to, DHCP option or not, since our implementation already supports multiple addresses per interface. However, I don't subscribe to the "disable v4LL" idea in the first place. > | I can see that network admins might want to disable the use of v4LL > | completely on their networks, but I submit that network management > | software is beyond the scope of this WG. > > Network management software??? What has that to do with anything? That's how network admins manage the nodes on their networks. It can be used to twiddle settings like "enable/disable v4LL". Maybe I'm using the wrong term. Does "remote configuration software" sound right? > | Right, I had a careless turn of phrase there. What I meant is that this > | specification is limited to links that use ARP. > > no, not even that. Most of what is there applies to LL addresses in > general. The only part of it that is specific to ARP networks is that > part that describes how to probe and defend addresses. Now it's my turn to refer you back to section 1.2. First paragraph. > | To address your earlier argument: I am not saying that "every > | v4LL-compliant node MUST have a v4LL address". I am saying: > | - A node MUST be allowed to have a v4LL together with a routable address > | on the same interface > > I don't have a problem with that, if a node wants to have both, and > is configured to have both, that's fine. Excellent. > | - A node MUST NOT use the v4LL address when communicating with a > | non-v4LL compliant node > > I disagree with that. Hrrm. > | - PLEASE don't create unnecessary implementation dependencies between > | v4LL and other address configuration mechanisms > > Address configuration mechanisms (of whatever kind) assuming there is > more than one of them (and there clearly is) have all kinds of > dependencies between them. That's unavoidable - they're all configuring > essentially the same thing, so they have to interact. No they don't. Given a proper API, they will just add and remove addresses from network interfaces independent of each other. MikaL From owner-zeroconf@merit.edu Sun Feb 9 10:18:27 2003 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 KAA00199 for ; Sun, 9 Feb 2003 10:18:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 453AB91221; Sun, 9 Feb 2003 10:22:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06ED491230; Sun, 9 Feb 2003 10:22:00 -0500 (EST) 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 F2DE991221 for ; Sun, 9 Feb 2003 10:21:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id DDB715DFED; Sun, 9 Feb 2003 10:21:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id E82115DFD5 for ; Sun, 9 Feb 2003 10:21:58 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h19FMXQF022012; Sun, 9 Feb 2003 17:22:34 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h19FMUAN022011; Sun, 9 Feb 2003 17:22:30 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG action - 1 week to discuss [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses From: Mika Liljeberg To: Erik Guttman Cc: zeroconf@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044804147.21383.235.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 09 Feb 2003 17:22:28 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-02-09 at 16:03, Erik Guttman wrote: > Please see http://www.spybeam.org/ll17.html > > This issue evoked no comment during the not-very-successful recent > "WG consensus action: when to configure LL addrs" > > Just to verify that it has been accepted, please consider this issue > before 16 Feb 2003. If there is no comment, we will assume it is > acceptable. There is a dependency to LL19, which I believe must be resolved first. MikaL From owner-zeroconf@merit.edu Sun Feb 9 10:49:02 2003 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 KAA00780 for ; Sun, 9 Feb 2003 10:49:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 87A7391230; Sun, 9 Feb 2003 10:52:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D6E291233; Sun, 9 Feb 2003 10:52:35 -0500 (EST) 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 34FA991230 for ; Sun, 9 Feb 2003 10:52:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 192815DFD5; Sun, 9 Feb 2003 10:52:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id A114F5DFB7 for ; Sun, 9 Feb 2003 10:52:32 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h19FqJn25637; Sun, 9 Feb 2003 22:52:20 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h19Fq8b05585; Sun, 9 Feb 2003 22:52:10 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs In-Reply-To: <1044803577.21383.233.camel@devil> References: <1044803577.21383.233.camel@devil> <1044793681.21186.107.camel@devil> <1044787452.11519.93.camel@devil> <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> <3689.1044783115@munnari.OZ.AU> <4300.1044789975@munnari.OZ.AU> <4798.1044798098@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Feb 2003 22:52:08 +0700 Message-ID: <5583.1044805928@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 09 Feb 2003 17:12:59 +0200 From: Mika Liljeberg Message-ID: <1044803577.21383.233.camel@devil> | Are you saying that we should relax the admonishment that v4LL addresses | should not be configured manually? Somewhere our contexts have totally diverged. No. What I meant was that I believe it is safe enough for a nodes with LL addresses to communicate with nodes with routable addresses (and vice versa of course). Or if you like, I oppose LL19. | Meaning, you can allow nodes that only have a v4LL address to converse | with non-v4LL compliant nodes that have a manually configured v4LL | address. | | That is clearly a fringe case. Yes, but one to keep in mind. | The failure mode here is very simple to understand. That is not true of | the alternative. When the alternative fails, it fails - as it would with LL19 imposed upon everyone, the only variation is in the effect of the failure upon what packets go where. For most purposes the difference is irrelevant. | I expect the implementations to do what the RFC says. Why else do we | write these things? I would expect that too. But to achieve that the RFC has to be written such that it allows people to do what they want to do - otherwise they simply ignore it. | What we can do, is make sure v4LL nodes in routed networks will try to | get a routable address and use that whenever they connect to another | routable address. That way your special case above won't even come up. Yes, whenever that happens there will be no problem. But no-one is pretending that all nodes must be given a routable address (and there are, or seem to be, some people who want to have nodes which cannot ever have a routable address). When nodes with no routable address appear on a net, and they will for one reason or another, we need to deal with them - including when they want to communicate with all the nodes without LL addresses (old and new). | Does it matter? If the packets escape the link they must end up | somewhere and use up someone's bandwith, as will the ICMP errors coming | back. And if that every gets to be enough of a problem to matter, someone will block the packets. So, does it matter? | If you disagree, then we have a difference of opinion that cannot be | resolved on technical grounds. I disagree, and so ... | A DNS server doesn't need an LL address (although it could have one). I agree that it doesn't need one. But, using your model, if the node upon which the DNS server is running (this being some generic *BSD or Linux box most likely) happens to be running some other application which needs to communicate with LL only nodes, what then? I'd prefer to just leave he system with its routable address (and not require anything more). | v4LL-compliant nodes should acquire a routable address when they are | part of a routed network. If they don't, they have no business talking | to DNS anyway, or trying to connect to any addresses that they would get | from DNS, which are more than likely to be unreachable (behind a | router). You're still missing my point, which had nothing at all to do with anyone (relevant) attempting to talk to the DNS, or using any results they may gain that way. Please do remember that a "DNS server" is not a computer with a network attachment, it is a piece of software that runs on a computer that might also be running all kinds of other software. | Actually, the DNS server only needs to deal with routable addresses. You | *don't* want to put LL addresses into DNS. Something that we actually agree upon. Violently I suspect. | That's how network admins manage the nodes on their networks. It can be | used to twiddle settings like "enable/disable v4LL". Maybe I'm using the | wrong term. Does "remote configuration software" sound right? It doesn't matter what you call it, the problem is that it works only after the node is configured and running on the (a) network in the first place. If LL addresses are to be disabled, that should happen as part of the node's startup sequence, not sometime later. Please do not assume that the node necessarily has any stable storage in which you can stick a configuration setting to be used thereafter. | Now it's my turn to refer you back to section 1.2. First paragraph. Which says ... The specifications in this document apply to any IEEE 802 media Note it does not say "apply only to". So, you keep on reading and eventually get to the third paragraph, which clearly extends things to other media as well - just as it should. This doc could conceivably be divided into two - one specifying the general properties of LL, and another specifying how to configure LL on 802.x (and similar) networks. But, it is common in these cases to just put the most common case (which is clearly 802.x) in the base spec, and then as other technologies require it, write the extra specs. That's what happened for ARP, as just one example... | No they don't. Given a proper API, they will just add and remove | addresses from network interfaces independent of each other. That doesn't work. The obvious example is that when you manually configure a node's address, you almost never want it (also) going and doing DHCP to get a different one (either as a replacement, or in addition). LL doesn't need to to be much different than that. You (the user, or the device manufacturer) pick which address assignment method to use (or which sequence to try until one succeeds) and then just let them run. kre From owner-zeroconf@merit.edu Sun Feb 9 12:05:37 2003 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 MAA02009 for ; Sun, 9 Feb 2003 12:05:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 512CF91234; Sun, 9 Feb 2003 12:09:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F03091238; Sun, 9 Feb 2003 12:09:10 -0500 (EST) 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 CC13091234 for ; Sun, 9 Feb 2003 12:09:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id B2C635E003; Sun, 9 Feb 2003 12:09:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 5B9BB5E000 for ; Sun, 9 Feb 2003 12:09:07 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h19H9hQF022298; Sun, 9 Feb 2003 19:09:43 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h19H9fH5022297; Sun, 9 Feb 2003 19:09:41 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Robert Elz Cc: zeroconf@merit.edu In-Reply-To: <5583.1044805928@munnari.OZ.AU> References: <1044803577.21383.233.camel@devil> <1044793681.21186.107.camel@devil> <1044787452.11519.93.camel@devil> <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> <3689.1044783115@munnari.OZ.AU> <4300.1044789975@munnari.OZ.AU> <4798.1044798098@munnari.OZ.AU> <5583.1044805928@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044810580.21186.302.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 09 Feb 2003 19:09:41 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-02-09 at 17:52, Robert Elz wrote: > Date: 09 Feb 2003 17:12:59 +0200 > From: Mika Liljeberg > Message-ID: <1044803577.21383.233.camel@devil> > > | Are you saying that we should relax the admonishment that v4LL addresses > | should not be configured manually? > > Somewhere our contexts have totally diverged. > > No. > > What I meant was that I believe it is safe enough for a nodes with > LL addresses to communicate with nodes with routable addresses (and vice > versa of course). Such communication is only possible if you configure at least a 169.254/16 on-link route on those nodes manually (admittedly, the route is enough). > Or if you like, I oppose LL19. So I gathered. :) > | Meaning, you can allow nodes that only have a v4LL address to converse > | with non-v4LL compliant nodes that have a manually configured v4LL > | address. > | > | That is clearly a fringe case. > > Yes, but one to keep in mind. I don't get that. Could you give me some examples of these v4LL nodes that participate in a routed network but are unable to get a routable address? > | The failure mode here is very simple to understand. That is not true of > | the alternative. > > When the alternative fails, it fails - as it would with LL19 imposed > upon everyone, the only variation is in the effect of the failure upon > what packets go where. For most purposes the difference is irrelevant. The alternative is multiple different failure modes, which makes them more difficult to handle. It also means the an application, on a node that only has a routable address, can get a LL address from getpeername() or directly from the peer as part of the application protocol. This leads to exactly those application problems that Keith has been complaining about. > | I expect the implementations to do what the RFC says. Why else do we > | write these things? > > I would expect that too. But to achieve that the RFC has to be written > such that it allows people to do what they want to do - otherwise they > simply ignore it. I doubt there would be enough incentive to willfully break the RFC in this case. The obvious solution (even for a user) is to get a routable address to all nodes on the link. > | What we can do, is make sure v4LL nodes in routed networks will try to > | get a routable address and use that whenever they connect to another > | routable address. That way your special case above won't even come up. > > Yes, whenever that happens there will be no problem. > > But no-one is pretending that all nodes must be given a routable > address (and there are, or seem to be, some people who want to > have nodes which cannot ever have a routable address). As part of a routed network? Let's take an example: a printer that configures a LLv4 address and uses rendezvous to advertise itself. The printer does not have a routable address. Four points: 1) The printer has no need to initiate connections to other nodes. 2) Nodes that support rendezvous can contact to the printer directly. 3) Nodes that do not support rendezvous cannot print directly to the printer even if they have the manually configured 169.254/16 on-link route, because they have no way of finding the IP address of the printer. 4) the obvious solution to 3) is to put up a print server that serves the non-rendezvous nodes. > When nodes with no routable address appear on a net, and they will > for one reason or another, we need to deal with them - including when > they want to communicate with all the nodes without LL addresses > (old and new). > > | Does it matter? If the packets escape the link they must end up > | somewhere and use up someone's bandwith, as will the ICMP errors coming > | back. > > And if that every gets to be enough of a problem to matter, someone will > block the packets. So, does it matter? Someone will block the packets and, no doubt, complain virulently. :) > | If you disagree, then we have a difference of opinion that cannot be > | resolved on technical grounds. > > I disagree, and so ... When in doubt, I tend to go for "DO NO HARM". That means that, when there is potential for harm when v4LL only nodes are introduced into a routed network, the harm should befall the v4LL nodes and not any others. > | A DNS server doesn't need an LL address (although it could have one). > > I agree that it doesn't need one. But, using your model, if the node > upon which the DNS server is running (this being some generic *BSD or > Linux box most likely) happens to be running some other application which > needs to communicate with LL only nodes, what then? We already agreed that this is a fringe case. Two possible solutions, both simple: 1) The v4LL node should acquire a routable address. 2) The host with the DNS server should be v4LL compliant and acquire a v4LL address. (This has no implications to the DNS server application) > I'd prefer to just leave he system with its routable address (and not > require anything more). That doesn't make sense to me. > | v4LL-compliant nodes should acquire a routable address when they are > | part of a routed network. If they don't, they have no business talking > | to DNS anyway, or trying to connect to any addresses that they would get > | from DNS, which are more than likely to be unreachable (behind a > | router). > > You're still missing my point, which had nothing at all to do with > anyone (relevant) attempting to talk to the DNS, or using any results > they may gain that way. > > Please do remember that a "DNS server" is not a computer with a network > attachment, it is a piece of software that runs on a computer that > might also be running all kinds of other software. I know that. You argued that the DNS server *program* would have to listen to both the routable and the v4LL address. I responded to that argument. I argued that it only has to listen to the routable address, for the reasons above. So you're right. I probably missed your real point. > | Actually, the DNS server only needs to deal with routable addresses. You > | *don't* want to put LL addresses into DNS. > > Something that we actually agree upon. Violently I suspect. Excellent! :) > | That's how network admins manage the nodes on their networks. It can be > | used to twiddle settings like "enable/disable v4LL". Maybe I'm using the > | wrong term. Does "remote configuration software" sound right? > > It doesn't matter what you call it, the problem is that it works only > after the node is configured and running on the (a) network in the > first place. If LL addresses are to be disabled, that should happen > as part of the node's startup sequence, not sometime later. Ok, point taken. > Please do not assume that the node necessarily has any stable storage > in which you can stick a configuration setting to be used thereafter. > > | Now it's my turn to refer you back to section 1.2. First paragraph. > > Which says ... > > The specifications in this document apply to any IEEE 802 media > > Note it does not say "apply only to". So, you keep on reading and > eventually get to the third paragraph, which clearly extends things to > other media as well - just as it should. If that's what it means, perhaps it should be said more clearly. That is certainly not how I read it. > | No they don't. Given a proper API, they will just add and remove > | addresses from network interfaces independent of each other. > > That doesn't work. It does work. We have an API like that. > The obvious example is that when you manually > configure a node's address, you almost never want it (also) going and > doing DHCP to get a different one (either as a replacement, or in addition). That makes sense in normal configurations (and the user interface may guide you to do this), but there is no need to enforce this within the TCPIP stack or in the protocol specifications. You can legally have two addresses on the same interface. > LL doesn't need to to be much different than that. You (the user, or > the device manufacturer) pick which address assignment method to use (or > which sequence to try until one succeeds) and then just let them run. s/method/methods/ and I would agree. MikaL From owner-zeroconf@merit.edu Sun Feb 9 18:07:20 2003 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 SAA08768 for ; Sun, 9 Feb 2003 18:07:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9F8DD91205; Sun, 9 Feb 2003 18:10:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F7A89120E; Sun, 9 Feb 2003 18:10:54 -0500 (EST) 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 57EE891205 for ; Sun, 9 Feb 2003 18:10:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0C60F5DF60; Sun, 9 Feb 2003 18:10:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 75DDC5DF5F for ; Sun, 9 Feb 2003 18:10:51 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h19Lwdm10130 for ; Sun, 9 Feb 2003 13:58:39 -0800 Date: Sun, 9 Feb 2003 13:58:39 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I accept the problem description of this issue, as far as it goes. Essentially, this is really about determining whether the destination host supports v4LL or not. If it does, then there is not a problem with using a v4LL source address, since the response will go on the local link. If it doesn't, then the response goes to the router, which is undesirable. However, one must ask the question "How was the address of the non-V4LL destination obtained in the first place?" It could have been learned as the result of receiving a packet from that host. However, in that case we know that the host supports v4LL, since otherwise, the packet would have been sent to the gateway router instead, and would not have arrived. Another way it could have been learned is via LLMNR. That is the v4LL sent an LLMNR request and received the routable address in response. Assuming that LLMNR also requires implementation of v4LL (a reasonable assumption, I believe), again we can assume that the destination host is v4LL capable. In fact, the only way it would appear to me that the v4LL host could learn a routable address without also knowing that the destination host was v4LL capable would be if the DNS server is on the local link with a v4LL address, and the v4LL host is somehow configured to use it. In this case, I believe it is also reasonable to assume that the v4LL host also has a routable address -- and I agree that the routable address MUST be used in that case. Given this, here is how I would proposed to modify Section 2.6, paragraph 4: "If the destination address is a unicast address outside the 169.254/16 prefix, then the host MUST use an appropriate routable source address, if it has one. If the host does not have a routable source address, then it MAY choose to ARP for the destination address and then send its packet, with a link-local source IP address and a routable destination IP address, directly to its destination on the same physical link. The host MUST NOT send the packet to any router for forwarding." From owner-zeroconf@merit.edu Sun Feb 9 18:59:50 2003 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 SAA09513 for ; Sun, 9 Feb 2003 18:59:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DED3B9120E; Sun, 9 Feb 2003 19:03:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE8609120F; Sun, 9 Feb 2003 19:03:23 -0500 (EST) 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 86C139120E for ; Sun, 9 Feb 2003 19:02:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 57DAE5DDE4; Sun, 9 Feb 2003 19:02:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by segue.merit.edu (Postfix) with ESMTP id 30D905DD9D for ; Sun, 9 Feb 2003 19:02:08 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18i1OW-0007gd-00; Sun, 09 Feb 2003 16:01:56 -0800 Date: Sun, 9 Feb 2003 18:59:37 -0500 From: Keith Moore To: Bernard Aboba Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination Message-Id: <20030209185937.0437cc68.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Sun, 9 Feb 2003 13:58:39 -0800 (PST) Bernard Aboba wrote: > I accept the problem description of this issue, as far as it > goes. Essentially, this is really about determining whether > the destination host supports v4LL or not. Not really. Even if the destination supports v4LL, the source SHOULD use a routable source address if it has one. The only exception that comes to mind is for diagnostic tools - to test the ability of the destination to reply to a v4LL address. > If it does, then > there is not a problem with using a v4LL source address, > since the response will go on the local link. Actually that's not true. First, the effect of using a v4LL source address is not limited to the destination host. Second, the destination host could move off-link but still stay connected to the Internet. > However, one must ask the question "How was the address > of the non-V4LL destination obtained in the first place?" That's irrelevant, or should be, for a number of reasons. There are many ways that a host can obtain an address, including some that don't necessarily use v4LL. It's highly undesirable to limit the ways in which addresses propagate, and it's also highly undesirable to make source address selection dependent on the source from which the destination address was obtained. > It could have been learned as the result of receiving > a packet from that host. However, in that case we know > that the host supports v4LL, since otherwise, the packet > would have been sent to the gateway router instead, and > would not have arrived. No, because even a host that doesn't know how to configure its own LL address can still be programmed or configured to ARP for an LL address, and it's probably desirable for hosts to do so. > Another way it could have been learned is via LLMNR. > That is the v4LL sent an LLMNR request and received > the routable address in response. Assuming that LLMNR > also requires implementation of v4LL (a reasonable > assumption, I believe), again we can assume that the > destination host is v4LL capable. a) LLMNR is a mess; we need to scrap it and start completely over. b) no, it's not reasonable to assume that LLMNR (or its successor) uses v4LL. It could as easily use IPv6, and we really don't want to build more "v4-only" assumptions into the architecture. > In fact, the only way it would appear to me that the > v4LL host could learn a routable address without > also knowing that the destination host was v4LL > capable would be if the DNS server is on the local link > with a v4LL address, and the v4LL host is somehow > configured to use it. You appear to be assuming that a host can learn an LL address through only a small number of paths (of your choosing), which is completely false. Nor would it be desirable to bulid such a limitation into the architecture. > Given this, here is how I would proposed to modify > Section 2.6, paragraph 4: > > "If the destination address is a unicast address outside the > 169.254/16 prefix, then the host MUST use an appropriate routable > source address, if it has one. If the host does not have a routable > source address, then it MAY choose to ARP for the destination address > and then send its packet, with a link-local source IP address and a > routable destination IP address, directly to its destination on the > same physical link. That's really not a good idea. Use of LL source addresses should be avoided as much as possible, to minimize their potential for leakage and harm. From owner-zeroconf@merit.edu Sun Feb 9 19:24:36 2003 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 TAA09984 for ; Sun, 9 Feb 2003 19:24:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 298B89120F; Sun, 9 Feb 2003 19:28:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EDA4191211; Sun, 9 Feb 2003 19:28:07 -0500 (EST) 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 D52349120F for ; Sun, 9 Feb 2003 19:28:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id B0B3D5DDE4; Sun, 9 Feb 2003 19:28:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 193295DDBC for ; Sun, 9 Feb 2003 19:28:06 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h19NFqf14438; Sun, 9 Feb 2003 15:15:52 -0800 Date: Sun, 9 Feb 2003 15:15:52 -0800 (PST) From: Bernard Aboba To: Keith Moore Cc: zeroconf@merit.edu Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination In-Reply-To: <20030209185937.0437cc68.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > Not really. Even if the destination supports v4LL, the source SHOULD use a > routable source address if it has one. The only exception that comes to mind > is for diagnostic tools - to test the ability of the destination to reply to a > v4LL address. I'd agree with this. > > If it does, then > > there is not a problem with using a v4LL source address, > > since the response will go on the local link. > > Actually that's not true. First, the effect of using a v4LL source address is > not limited to the destination host. I don't understand what you mean by this. If the destination host is V4LL capable, then the packet will not go to the router. So other than the destination and source hosts, who else does the packet effect? > Second, the destination host could move > off-link but still stay connected to the Internet. That is true, but if the destination host is V4LL capable, this will only result in it ARP'ing for the v4LL address, and not getting a reply. No harm done. > > However, one must ask the question "How was the address > > of the non-V4LL destination obtained in the first place?" > > That's irrelevant, or should be, for a number of reasons. It's very relevant -- because my claim is that there are no ways that this can be accomplished by a host with a only a v4LL address that also don't prove that the destination host is v4LL capable. > No, because even a host that doesn't know how to configure its own LL address > can still be programmed or configured to ARP for an LL address, and it's > probably desirable for hosts to do so. There are no such hosts today -- and the spec can be written so that such hosts do not exist in the future if we choose to do so. > You appear to be assuming that a host can learn an LL address through only a > small number of paths (of your choosing), which is completely false. Nor > would it be desirable to bulid such a limitation into the architecture. If it is completely false -- why don't you provide a counterexample? From owner-zeroconf@merit.edu Sun Feb 9 19:44:51 2003 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 TAA10304 for ; Sun, 9 Feb 2003 19:44:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8ADB191211; Sun, 9 Feb 2003 19:48:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 56C0791214; Sun, 9 Feb 2003 19:48:24 -0500 (EST) 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 E51DF91211 for ; Sun, 9 Feb 2003 19:48:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id BF17A5DE5D; Sun, 9 Feb 2003 19:48:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by segue.merit.edu (Postfix) with ESMTP id 7AC3D5DF14 for ; Sun, 9 Feb 2003 19:48:10 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18i27D-0001xZ-00; Sun, 09 Feb 2003 16:48:07 -0800 Date: Sun, 9 Feb 2003 19:45:53 -0500 From: Keith Moore To: Bernard Aboba Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination Message-Id: <20030209194553.05938214.moore@cs.utk.edu> In-Reply-To: References: <20030209185937.0437cc68.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > > If it does, then > > > there is not a problem with using a v4LL source address, > > > since the response will go on the local link. > > > > Actually that's not true. First, the effect of using a v4LL source > > address is not limited to the destination host. > > I don't understand what you mean by this. If the destination host is V4LL > capable, then the packet will not go to the router. So other than the > destination and source hosts, who else does the packet effect? any other host that the destination host sends the address to. > > Second, the destination host could move > > off-link but still stay connected to the Internet. > > That is true, but if the destination host is V4LL capable, this will only > result in it ARP'ing for the v4LL address, and not getting a reply. No > harm done. it just means that the routable address would have been a better choice for the source address. > > > However, one must ask the question "How was the address > > > of the non-V4LL destination obtained in the first place?" > > > > That's irrelevant, or should be, for a number of reasons. > > It's very relevant -- because my claim is that there are no ways that this > can be accomplished by a host with a only a v4LL address that also don't > prove that the destination host is v4LL capable. that's false. any app that does referrals can refer an LL address, either deliberately or because it doesn't know better than to not do so. > > No, because even a host that doesn't know how to configure its own LL > > address can still be programmed or configured to ARP for an LL address, > > and it's probably desirable for hosts to do so. > > There are no such hosts today -- and the spec can be written so that such > hosts do not exist in the future if we choose to do so. it's been argued that you can configure a UNIX box to arp for LL addresses on a link. have you tried it yourself? Keith From owner-zeroconf@merit.edu Sun Feb 9 20:18:40 2003 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 UAA10885 for ; Sun, 9 Feb 2003 20:18:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 48A1F91214; Sun, 9 Feb 2003 20:22:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 188DD91218; Sun, 9 Feb 2003 20:22:13 -0500 (EST) 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 0634591214 for ; Sun, 9 Feb 2003 20:22:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id E0A1E5DE2B; Sun, 9 Feb 2003 20:22:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 4ECA55DE11 for ; Sun, 9 Feb 2003 20:22:11 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1A09wA17357; Sun, 9 Feb 2003 16:09:58 -0800 Date: Sun, 9 Feb 2003 16:09:58 -0800 (PST) From: Bernard Aboba To: Keith Moore Cc: zeroconf@merit.edu Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination In-Reply-To: <20030209194553.05938214.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > it just means that the routable address would have been a better choice > for the source address. Absolutely. We agree that if the source host has a routable address, it should use that instead. This is about the situation in which it *doesn't* have a routable address -- just a v4LL one. The question is whether it is possible to communicate between hosts with *only* a routable address, and hosts with *only* a v4LL address. I believe that this is valuable -- because there can be simple devices that will only want to use v4LL addresses even when a DHCP server is available. If they can't communicate with hosts with routable addresses, then they would have to obtain a routable address -- and they may not want one. > that's false. any app that does referrals can refer an LL address, either > deliberately or because it doesn't know better than to not do so. Say a host with a routable address gets a referral to a v4LL address, then attempts to contact a host at that address. If the host was not v4LL capable, then it will send the packet to the gateway and it will go nowhere. However, if the host is v4LL capable then it will ARP for the v4LL address and possibly deliver it. In that case, the host has demonstrated that it is v4LL capable. So your counterexample doesn't work. Care to try another one? > > > No, because even a host that doesn't know how to configure its own LL > > > address can still be programmed or configured to ARP for an LL address, > > > and it's probably desirable for hosts to do so. > > > > There are no such hosts today -- and the spec can be written so that such > > hosts do not exist in the future if we choose to do so. > > it's been argued that you can configure a UNIX box to arp for LL addresses on > a link. have you tried it yourself? The point is that it isn't configured this way out of the box. And I'd argue that it shouldn't be if the box doesn't support v4LL. From owner-zeroconf@merit.edu Sun Feb 9 21:44:59 2003 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 VAA12730 for ; Sun, 9 Feb 2003 21:44:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DC0AC91205; Sun, 9 Feb 2003 21:48:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1C5F9120F; Sun, 9 Feb 2003 21:48:32 -0500 (EST) 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 9DA7891205 for ; Sun, 9 Feb 2003 21:48:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 87EDE5DF8C; Sun, 9 Feb 2003 21:48:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 0CBD15DE07 for ; Sun, 9 Feb 2003 21:48:31 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1A1aIK22239 for ; Sun, 9 Feb 2003 17:36:18 -0800 Date: Sun, 9 Feb 2003 17:36:18 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: [Issue 1]: Preferred use of configured to v4LL address Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I agree with the proposed resolution to this issue in general, but wonder about some of the implications. For example, are we saying that a host having determined its IPv4LL address MUST first determine whether it can obtain a routable address (wait for DHCPv4 to complete) before claiming the address or defending it? Are is the prohibition only to apply situations other than claim/defend? Also, what if the host is unable to obtain a routable address? Then it would seem like it is able to use the LLv4 address. Is the host supposed to continue to try to obtain a routable address (e.g. try DHCP at some interval as the original implementations did)? If it obtains a routable address eventually, is it supposed to shut down connections that it established previously at the LLv4 address? My advice would be to continue to allow the host to use existing connections, but prohibit it from establishing new ones once it has obtained a routable address. Also if you want to go this route, then you need to put in some language about continuing to try to obtain a routable address. From owner-zeroconf@merit.edu Sun Feb 9 21:49:34 2003 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 VAA12812 for ; Sun, 9 Feb 2003 21:49:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 811F29120F; Sun, 9 Feb 2003 21:53:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4EF4D91214; Sun, 9 Feb 2003 21:53:08 -0500 (EST) 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 4ADDF9120F for ; Sun, 9 Feb 2003 21:53:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 292C55DE07; Sun, 9 Feb 2003 21:53:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B5B885DDBE for ; Sun, 9 Feb 2003 21:53:06 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1A1est22490 for ; Sun, 9 Feb 2003 17:40:54 -0800 Date: Sun, 9 Feb 2003 17:40:54 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: [Issue 2] Explicit Additional Mechanism to disable v4LL Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I agree that this issue should be rejected. If we go the route of preferring routable addresses to V4LL ones if both are available, then the way to control use of v4LL is to make sure that hosts get a routable address -- in other words, keep your DHCPv4 server running. From owner-zeroconf@merit.edu Sun Feb 9 21:54:26 2003 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 VAA12885 for ; Sun, 9 Feb 2003 21:54:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 35E8991214; Sun, 9 Feb 2003 21:57:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 03BE991218; Sun, 9 Feb 2003 21:57:58 -0500 (EST) 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 E799491214 for ; Sun, 9 Feb 2003 21:57:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id D22875DFAC; Sun, 9 Feb 2003 21:57:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by segue.merit.edu (Postfix) with ESMTP id B1B9C5DE07 for ; Sun, 9 Feb 2003 21:57:57 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18i48p-0000Fd-00; Sun, 09 Feb 2003 18:57:55 -0800 Date: Sun, 9 Feb 2003 21:55:40 -0500 From: Keith Moore To: Bernard Aboba Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination Message-Id: <20030209215540.613f59c8.moore@cs.utk.edu> In-Reply-To: References: <20030209194553.05938214.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Sun, 9 Feb 2003 16:09:58 -0800 (PST) Bernard Aboba wrote: > > it just means that the routable address would have been a better choice > > for the source address. > > Absolutely. We agree that if the source host has a routable address, it > should use that instead. This is about the situation in which it *doesn't* > have a routable address -- just a v4LL one. > > The question is whether it is possible to communicate between hosts with > *only* a routable address, and hosts with *only* a v4LL address. I believe > that this is valuable -- because there can be simple devices that will > only want to use v4LL addresses even when a DHCP server is available. such devices should not be permitted by the standard. period. From owner-zeroconf@merit.edu Sun Feb 9 21:54:43 2003 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 VAA12899 for ; Sun, 9 Feb 2003 21:54:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B482291218; Sun, 9 Feb 2003 21:58:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 723569121C; Sun, 9 Feb 2003 21:58:16 -0500 (EST) 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 22ED891218 for ; Sun, 9 Feb 2003 21:58:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 116205DFD4; Sun, 9 Feb 2003 21:58:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 99B985DE07 for ; Sun, 9 Feb 2003 21:58:14 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1A1k2V22840 for ; Sun, 9 Feb 2003 17:46:02 -0800 Date: Sun, 9 Feb 2003 17:46:02 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: [Issue 3] TTL=255 on send, check on receive? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I support the proposed resolution of this issue. Note that Thomas Narten's concern (part of the Problem Description) probably belongs in another issue (Issue 19?) and is not addressed by the Requested change. I'd suggest that it be moved somewhere more appropriate so we can make sure that we address that too. From owner-zeroconf@merit.edu Sun Feb 9 21:58:25 2003 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 VAA12950 for ; Sun, 9 Feb 2003 21:58:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 250969120E; Sun, 9 Feb 2003 22:01:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0F3C91211; Sun, 9 Feb 2003 22:01:58 -0500 (EST) 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 D2B059120E for ; Sun, 9 Feb 2003 22:01:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id B93CE5DFFE; Sun, 9 Feb 2003 22:01:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 49C455DE07 for ; Sun, 9 Feb 2003 22:01:57 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1A1nig23013 for ; Sun, 9 Feb 2003 17:49:45 -0800 Date: Sun, 9 Feb 2003 17:49:44 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: [Issue 9] Not a replacement for a DHCP assigned address Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I agree with the proposed change, as far as it goes. However, if we feel that it is inappropriate for a host to *only* support obtaining an IPv4LL address, we should say so explicitly. Personally, I think that a host MAY wish to only support static configuration and IPv4LL, not DHCPv4 (although the benefits of this might be debatable). From owner-zeroconf@merit.edu Sun Feb 9 22:01:24 2003 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 WAA13029 for ; Sun, 9 Feb 2003 22:01:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0960091211; Sun, 9 Feb 2003 22:04:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD70B9121C; Sun, 9 Feb 2003 22:04:57 -0500 (EST) 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 C53B391211 for ; Sun, 9 Feb 2003 22:04:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id ABC525DFFE; Sun, 9 Feb 2003 22:04:56 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 43B215DFF4 for ; Sun, 9 Feb 2003 22:04:56 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1A1qIL23138 for ; Sun, 9 Feb 2003 17:52:33 -0800 Date: Sun, 9 Feb 2003 17:52:18 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: [Issue 6] Security Considerations regarding Wireless LANs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I agree with the general sentiment here -- on public links, LLv4 confers no security benefits. However, I wonder whether there are other implications -- such as whether there is any justification for a host not bothering to obtain a DHCPv4 address (as in Issue 9). From owner-zeroconf@merit.edu Sun Feb 9 22:06:25 2003 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 WAA13125 for ; Sun, 9 Feb 2003 22:06:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CBCE79121C; Sun, 9 Feb 2003 22:09:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99B3D9121F; Sun, 9 Feb 2003 22:09:57 -0500 (EST) 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 855489121C for ; Sun, 9 Feb 2003 22:09:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5F9685DFFE; Sun, 9 Feb 2003 22:09:56 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id CDDD45E002 for ; Sun, 9 Feb 2003 22:09:55 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1A1vhp23399 for ; Sun, 9 Feb 2003 17:57:43 -0800 Date: Sun, 9 Feb 2003 17:57:43 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: [Issue 11] Attacker forces address reconfiguration Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On this issue, I'm struck that you can't have your cake and eat it too. If we're going to say that a host should prefer a routable address if available (Issue 1), then a host with only a v4LL address that subsequently obtains a routable address will break its connections and enable the attack described in Issue 11. For example, an attacker could bring up a rogue DHCP server, hand out bogus routable addresses and bring down existing connections. I'd suggest that an additional paragraph about this attack should be added, depending on what the chosen approach is. My advice would be to continue to use existing connections, just not establish new ones, in which case the attack won't break existing connections. From owner-zeroconf@merit.edu Sun Feb 9 22:17:27 2003 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 WAA13341 for ; Sun, 9 Feb 2003 22:17:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0CE4B9121F; Sun, 9 Feb 2003 22:21:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCD6891221; Sun, 9 Feb 2003 22:20:59 -0500 (EST) 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 B87E79121F for ; Sun, 9 Feb 2003 22:20:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D0145E008; Sun, 9 Feb 2003 22:20:58 -0500 (EST) 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 26B745E007 for ; Sun, 9 Feb 2003 22:20:58 -0500 (EST) 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 WAA14283 for ; Sun, 9 Feb 2003 22:20:57 -0500 (EST) 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 WAA01060 for ; Sun, 9 Feb 2003 22:20:57 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id WAA12364 for ; Sun, 9 Feb 2003 22:20:56 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Sun, 09 Feb 2003 22:20:58 -0500 Subject: Re: [Issue 2] Explicit Additional Mechanism to disable v4LL From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: 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 02/09/2003 20:40, "Bernard Aboba" wrote: > I agree that this issue should be rejected. > > If we go the route of preferring routable addresses to V4LL ones if both > are available, then the way to control use of v4LL is to make sure that > hosts get a routable address -- in other words, keep your DHCPv4 server > running. If you are in a high security environment, the implicit disabling of v4LL due to the presence of a DHCP address is not enough. If you are trying to set up an ad hoc network in range of an open DHCP server, you'll never be able to. If you have a manual address configured, and you need to print at a new location to a v4LL printer, you won't be able to. If your DHCP server goes down, and you can't get another one up, because you're on a home network, your DHCP server is your little cable router and you don't know how to reset your DHCP leases, (because you're using a Mac, and OS X doesn't give you an easy way to do this), you can't even talk to the computers in your house until the lease expires. There are a host of reasons for having a human override to automatic configurations, they exist *now*...manual config can overrride DHCP config. I'm saying, let's make v4LL's easy and flexible. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sun Feb 9 22:28:09 2003 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 WAA13538 for ; Sun, 9 Feb 2003 22:28:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2D15491205; Sun, 9 Feb 2003 22:31:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1D3191221; Sun, 9 Feb 2003 22:31:33 -0500 (EST) 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 A274291205 for ; Sun, 9 Feb 2003 22:31:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id D5DD75DDBE; Sun, 9 Feb 2003 22:31:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 6E6BE5DDBD for ; Sun, 9 Feb 2003 22:31:01 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1A2IlA24639; Sun, 9 Feb 2003 18:18:48 -0800 Date: Sun, 9 Feb 2003 18:18:47 -0800 (PST) From: Bernard Aboba To: Keith Moore Cc: zeroconf@merit.edu Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination In-Reply-To: <20030209215540.613f59c8.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > such devices should not be permitted by the standard. period. Then the standard should say so explicitly. From owner-zeroconf@merit.edu Sun Feb 9 22:34:22 2003 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 WAA13925 for ; Sun, 9 Feb 2003 22:34:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7572091221; Sun, 9 Feb 2003 22:37:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 495EF91223; Sun, 9 Feb 2003 22:37:55 -0500 (EST) 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 3919791221 for ; Sun, 9 Feb 2003 22:37:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0EF305E002; Sun, 9 Feb 2003 22:37:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 835DD5DF8C for ; Sun, 9 Feb 2003 22:37:53 -0500 (EST) Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1A3b3P16468; Sun, 9 Feb 2003 21:37:04 -0600 (CST) Date: Sun, 9 Feb 2003 21:37:51 -0600 Subject: Re: [Issue 11] Attacker forces address reconfiguration Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Bernard Aboba From: Ted Lemon In-Reply-To: Message-Id: <08336B52-3CA9-11D7-A2AE-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > If we're going to say that a host should prefer a routable address if > available (Issue 1), then a host with only a v4LL address that > subsequently obtains a routable address will break its connections and > enable the attack described in Issue 11. For example, an attacker could > bring up a rogue DHCP server, hand out bogus routable addresses and > bring > down existing connections. Not only does it bring down existing connections, but it prevents future connections with ipv4ll-aware hosts that have been attacked similarly - this was the big disagreement that kre and I had last week. Consider the case where you have a bad guy who wants to prevent devices on a link with no DHCP server from communicating using IPv4ll. This bad guy sets up a DHCP server which gives every host an IP address on a different subnet, and provides a bogus default route that prevents communication. In this case, even if all of the nodes on the subnet are IPv4ll-aware, and all of them are doing LLMNS, there is no way for any of them to communicate - each one will publish its "global" IP address with LLMNS, but none of the global addresses are reachable, so no communication is possible in this case. This is a similarly nasty attack to the one allowed by RFC2563. From owner-zeroconf@merit.edu Mon Feb 10 02:52:26 2003 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 CAA28943 for ; Mon, 10 Feb 2003 02:52:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 503469120F; Mon, 10 Feb 2003 02:55:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E18391214; Mon, 10 Feb 2003 02:55:59 -0500 (EST) 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 1BFB79120F for ; Mon, 10 Feb 2003 02:55:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 015915DECD; Mon, 10 Feb 2003 02:55:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7583C5DDA6 for ; Mon, 10 Feb 2003 02:55:57 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1A6hh406549 for ; Sun, 9 Feb 2003 22:43:44 -0800 Date: Sun, 9 Feb 2003 22:43:43 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: [Issue 10] Warnings in Applicability Statement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk "Existing applications fundamentally assume addresses of communicating peers are routable, relatively unchanging and unique. These assumptions no longer hold with IPv4 link-local addresses." They also may not hold for DHCPv4 assigned addresses. Without failover or clustering support, DHCPv4 outages are more likely than many of us would like to believe -- and so are address conflicts, if experience at IETF meetings is any guide. For example, nowadays DHCPv4 servers are often provided on devices without the "stable storage" required by RFC 2131. When those devices reboot (which can be frequent) all address state is lost. DHCPv4 server configurations which provide multiple offers from distinct address pools will result in address changes whenever the renewing server is down or even heavily loaded. Often organizations try to get around these problems by lengthening the lease time to days or even weeks. Of course, private addresses are commonly assigned by DHCPv4 mechanisms. So let's not be under the illusion that outside of LLv4, there is a world where IPv4 "routable, relatively unchanging and unique" addresses are always available. If they were, we wouldn't need IPv6 :) This means, among other things, that switching between LLv4 and DHCPv4 assigned addresses should be carefully thought through. If not handled carefully, it can make the problem worse, not better. I would recommend that the text be changed to: "Existing applications fundamentally assume addresses of communicating peers are routable, relatively unchanging and unique. These assumptions no longer hold with IPv4 link-local addresses, particularly on networks with an unstable DHCPv4 configuration or a substantial number of hosts." From owner-zeroconf@merit.edu Mon Feb 10 02:52:46 2003 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 CAA28967 for ; Mon, 10 Feb 2003 02:52:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7025E91214; Mon, 10 Feb 2003 02:56:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31D4091218; Mon, 10 Feb 2003 02:56:11 -0500 (EST) 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 04CA591214 for ; Mon, 10 Feb 2003 02:56:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF3D55DECD; Mon, 10 Feb 2003 02:56:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from home.karahalios.org (dsl093-162-009.tus1.dsl.speakeasy.net [66.93.162.9]) by segue.merit.edu (Postfix) with ESMTP id 4D6D85DDA6 for ; Mon, 10 Feb 2003 02:56:07 -0500 (EST) Received: from Outersoft.com (usr2.Karahalios.org [192.168.2.2]) by home.karahalios.org (8.11.1/8.10.1) with ESMTP id h1A7u6622583 for ; Mon, 10 Feb 2003 00:56:06 -0700 Date: Mon, 10 Feb 2003 00:56:04 -0700 Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Alex Karahalios To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030209215540.613f59c8.moore@cs.utk.edu> Message-Id: <1A8A74B6-3CCD-11D7-833C-00039377AD70@Outersoft.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Keith, I guess putting the word "period." at the end of your sentence makes it more definitive ;) But I think the standard should permit such simple devices. Not every device has the luxury of implementing a DHCP client. And there is no requirement for a DHCP server on an IP network. There are many cases for simple IP devices coexisting with more complex ones. For example, in HVAC control, devices can communicate with each other using v4LL addresses and be oblivious of a DHCP server. Usually a machine is set up as a master controller that communicates with the devices and a more global scoped IP network. These devices may be physically on the same network cable as other full fledged IP devices, although logically they only see each other. Alex Karahalios On Sunday, February 9, 2003, at 07:55 PM, Keith Moore wrote: >> The question is whether it is possible to communicate between hosts >> with >> *only* a routable address, and hosts with *only* a v4LL address. I >> believe >> that this is valuable -- because there can be simple devices that will >> only want to use v4LL addresses even when a DHCP server is available. > > such devices should not be permitted by the standard. period. From owner-zeroconf@merit.edu Mon Feb 10 04:00:01 2003 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 EAA00872 for ; Mon, 10 Feb 2003 04:00:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 97DE991207; Mon, 10 Feb 2003 04:03:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 800BB9121F; Mon, 10 Feb 2003 04:02:45 -0500 (EST) 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 EA3A591207 for ; Mon, 10 Feb 2003 04:02:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id BFACF5DE5A; Mon, 10 Feb 2003 04:02:09 -0500 (EST) 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 37EBC5DDAE for ; Mon, 10 Feb 2003 04:02:09 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03748 for ; Mon, 10 Feb 2003 01:02:06 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1A91HP21988; Mon, 10 Feb 2003 10:02:01 +0100 (MET) Date: Mon, 10 Feb 2003 09:57:37 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: WG action - 1 week to discuss [LL7] Add warnings to applicability statement To: Erik Guttman Cc: zeroconf@merit.edu, erik.nordmark@sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > Please see http://www.spybeam.org/ll10.html > > This does not seem to be particularly controversial. A consensus call > on discussion will occur 15 Feb 2003. > > Erik, as you were the one who raised the comment in the IESG last call > of draft-ietf-zeroconf-ipv4-linklocal-07.txt, could you please confirm > that the wording of this issue is appropriate? I'm confused whether the suggestion is to be applied to section 1.2 or section 7 since the web page seems to say both. The information needs to be up front in the document and not hidden in the back. Erik From owner-zeroconf@merit.edu Mon Feb 10 04:00:12 2003 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 EAA00886 for ; Mon, 10 Feb 2003 04:00:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2FA2B9121F; Mon, 10 Feb 2003 04:03:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BA159121C; Mon, 10 Feb 2003 04:03:32 -0500 (EST) 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 1970491221 for ; Mon, 10 Feb 2003 04:03:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id E10EE5DE08; Mon, 10 Feb 2003 04:03:27 -0500 (EST) 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 5AD9D5DDAE for ; Mon, 10 Feb 2003 04:03:27 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04433 for ; Mon, 10 Feb 2003 01:03:25 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h1A93EP22132; Mon, 10 Feb 2003 10:03:14 +0100 (MET) Date: Mon, 10 Feb 2003 09:59:35 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: WG action - 1 week to discuss [LL11] Add security consideration for the threat where an attacker forces address reconfiguration To: Erik Guttman Cc: zeroconf@merit.edu, erik.nordmark@sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > Please see http://www.spybeam.org/ll11.html > > This does not seem like it is a controversial issue. It was suggested > some time ago and has gotten no further comment. Please comment by 15 > Feb 2003 when the issue will be decided. If no comment is made, the > recommended text will be accepted. > > Erik, since you raised this issue during the iesg review of > draft-ietf-zeroconf-ipv4-linklocal-07.txt could you please review the > recommended fix? Looks like what I said. Erik From owner-zeroconf@merit.edu Mon Feb 10 04:01:38 2003 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 EAA00936 for ; Mon, 10 Feb 2003 04:01:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1CEC491218; Mon, 10 Feb 2003 04:05:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DCDEF9121C; Mon, 10 Feb 2003 04:05:10 -0500 (EST) 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 D2AF491218 for ; Mon, 10 Feb 2003 04:05:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id B3B145DD98; Mon, 10 Feb 2003 04:05:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id CC2A35DECA for ; Mon, 10 Feb 2003 04:05:03 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1A93an00535; Mon, 10 Feb 2003 16:03:37 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1A93Fb12311; Mon, 10 Feb 2003 16:03:18 +0700 (ICT) From: Robert Elz To: Bernard Aboba Cc: Keith Moore , zeroconf@merit.edu Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Feb 2003 16:03:15 +0700 Message-ID: <12309.1044867795@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 9 Feb 2003 15:15:52 -0800 (PST) From: Bernard Aboba Message-ID: | It's very relevant -- because my claim is that there are no ways that this | can be accomplished by a host with a only a v4LL address that also don't | prove that the destination host is v4LL capable. That's obviously not true. One way is that I type "ifconfig -a" (or some other OS equivalent) on the system I am intending to be the destination, notice an address assigned to the network interface, swivel in my chair, and type telnet ip.add.re.ss on the other system. Not all IP address discovery uses any kind of network protocol. For ad-hoc type connectivity, this kind of communication is actually likely. Eg: someone comes into my office with a system, connects to my local LAN, and asks me "tell me your IP address and I will send you this file", so I do just that. My IP address is a global/routable one, but being an unknown outsider, my DHCP server didn't give him an address, so he's just got a LL address. In this scenario whether my system is LL aware or not is completely unknown. kre From owner-zeroconf@merit.edu Mon Feb 10 04:12:38 2003 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 EAA01193 for ; Mon, 10 Feb 2003 04:12:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 49D9C9121C; Mon, 10 Feb 2003 04:15:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D92291221; Mon, 10 Feb 2003 04:15:45 -0500 (EST) 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 E53869121C for ; Mon, 10 Feb 2003 04:15:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4BBE35DE5A; Mon, 10 Feb 2003 04:15:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 3323E5DE08 for ; Mon, 10 Feb 2003 04:15:32 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1A9Ekn09488; Mon, 10 Feb 2003 16:14:47 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1A9EEb12330; Mon, 10 Feb 2003 16:14:14 +0700 (ICT) From: Robert Elz To: Bernard Aboba Cc: Keith Moore , zeroconf@merit.edu Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Feb 2003 16:14:14 +0700 Message-ID: <12328.1044868454@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 9 Feb 2003 16:09:58 -0800 (PST) From: Bernard Aboba Message-ID: | The question is whether it is possible to communicate between hosts with | *only* a routable address, and hosts with *only* a v4LL address. I believe | that this is valuable So do I. I take it from this that you're opposing LL19? That hasn't been clear in any of your other messages... The text you proposed in your original message is fine, except the "MAY choose to ARP" should turn into "MUST ARP". (That's more or less LL17, in reverse, and that issue should be discussed under that subject). | -- because there can be simple devices that will | only want to use v4LL addresses even when a DHCP server is available. Keith's "such devices shouldn't exist" (whether true or not) is irrelevant here. The issue isn't whether a DHCP server is available or not, nor whether the device is able to, or actually does, request a routable addr, but whether the DHCP server offers an address to the node. If the DHCP server doesn't offer an address, and also doesn't say "don't use LL", then clearly the node gets an LL address, and that's all it has. On most established (managed) networks, this will be the normal case for LL addresses to exist and be used. There's no reason I can see to prohibit such a device from communicating with devices which (for whatever reason) don't have a LL address. Issue LL19 prohibits it. So, reject LL19. We don't need to stray into all of the other side issues on this one. kre From owner-zeroconf@merit.edu Mon Feb 10 04:15:08 2003 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 EAA01252 for ; Mon, 10 Feb 2003 04:15:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A66E091221; Mon, 10 Feb 2003 04:18:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63C4A91223; Mon, 10 Feb 2003 04:18:34 -0500 (EST) 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 BA62491221 for ; Mon, 10 Feb 2003 04:18:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D6EE5DE5A; Mon, 10 Feb 2003 04:18:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 05A475DE08 for ; Mon, 10 Feb 2003 04:17:54 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1A9H6n11470; Mon, 10 Feb 2003 16:17:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1A9GZb12340; Mon, 10 Feb 2003 16:16:35 +0700 (ICT) From: Robert Elz To: Bernard Aboba Cc: zeroconf@merit.edu Subject: Re: [Issue 2] Explicit Additional Mechanism to disable v4LL In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Feb 2003 16:16:35 +0700 Message-ID: <12338.1044868595@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 9 Feb 2003 17:40:54 -0800 (PST) From: Bernard Aboba Message-ID: | If we go the route of preferring routable addresses to V4LL ones if both | are available, That's very likely I think. | then the way to control use of v4LL is to make sure that | hosts get a routable address -- in other words, keep your DHCPv4 server | running. That assumes that the DHCP server wants the node in question connected (at all) to the network it is attached to, doesn't it? What do you do when the DHCP server wants to say "you are on the wrong network" ? kre From owner-zeroconf@merit.edu Mon Feb 10 04:22:30 2003 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 EAA01386 for ; Mon, 10 Feb 2003 04:22:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 92B4A91223; Mon, 10 Feb 2003 04:26:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 609CD91224; Mon, 10 Feb 2003 04:26:03 -0500 (EST) 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 5045C91223 for ; Mon, 10 Feb 2003 04:26:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 309155DEB6; Mon, 10 Feb 2003 04:26:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id D406B5DE08 for ; Mon, 10 Feb 2003 04:25:47 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1A9Ogn17864; Mon, 10 Feb 2003 16:24:43 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1A9O5b12359; Mon, 10 Feb 2003 16:24:05 +0700 (ICT) From: Robert Elz To: Bernard Aboba Cc: zeroconf@merit.edu Subject: Re: [Issue 1]: Preferred use of configured to v4LL address In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Feb 2003 16:24:05 +0700 Message-ID: <12357.1044869045@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 9 Feb 2003 17:36:18 -0800 (PST) From: Bernard Aboba Message-ID: | For example, are we saying that a host having determined its IPv4LL | address MUST first determine whether it can obtain a routable address | (wait for DHCPv4 to complete) before claiming the address or defending it? That makes no sense, you can't have determined your IPv4 LL address without claiming it (and once claimed, it must be defended if it is to be retained). This issue (which will become more explicit in LL23, or some other number, once that one eventually appears on the web site - that is, LL23 (LLnn) is al alternate proposed resolution for LL1) | Also, what if the host is unable to obtain a routable address? Then it | would seem like it is able to use the LLv4 address. Yes. | Is the host supposed to continue to try to obtain a routable address Yes, just as it would now (before LL exists) - if its DHCP (or other mechanisms) fail, it should (from time to time) try again. | If it obtains a routable | address eventually, is it supposed to shut down connections that it | established previously at the LLv4 address? No, the text I proposed in LL23 (LLnn where nn might become 23) makes that clear I think. | My advice would be to continue to allow the host to use existing | connections, but prohibit it from establishing new ones once it has | obtained a routable address. My proposed text doesn't quite go that far - rather, it prohibits it from initiating new connections, but not from establishing a new one initiated from some other host (which might have previously learned the LL address and isn't yet aware that a routable address exists). | Also if you want to go this route, then you | need to put in some language about continuing to try to obtain a routable | address. Yes, that would be a good idea. kre ps: you can find my intended LL23 (or LLnn) in a message with the Subject: header "New Issue: TTL=255 on send, check on receive?" (I inadvertantly sent the message with the wrong Subject line...) It was the second of the two with the same Subject sent last Sat. From owner-zeroconf@merit.edu Mon Feb 10 04:29:52 2003 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 EAA01591 for ; Mon, 10 Feb 2003 04:29:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8628D91224; Mon, 10 Feb 2003 04:33:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4DEF891226; Mon, 10 Feb 2003 04:33:26 -0500 (EST) 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 503D591224 for ; Mon, 10 Feb 2003 04:32:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2B63E5DECA; Mon, 10 Feb 2003 04:32:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by segue.merit.edu (Postfix) with ESMTP id 50F725DE58 for ; Mon, 10 Feb 2003 04:32:39 -0500 (EST) Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) with ESMTP id h1A9WbiC008277 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 10 Feb 2003 11:32:37 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) id h1A9WbGJ008273; Mon, 10 Feb 2003 11:32:37 +0200 Date: Mon, 10 Feb 2003 11:32:37 +0200 Message-Id: <200302100932.h1A9WbGJ008273@burp.tkv.asdf.org> From: Markku Savela To: zeroconf@merit.edu In-reply-to: <12328.1044868454@munnari.OZ.AU> (message from Robert Elz on Mon, 10 Feb 2003 16:14:14 +0700) Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination References: <12328.1044868454@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk If I have an interface configured with three addresses (and nets) 10.0.0.1 10/8 169.254.2.3 169.254/16 global-addr global/net then, if I'm connecting to 10/8 destination I want my source address to be 10.0.0.1, and for global destination the source should be global-addr. This appears to be the way my linux works, and this is how I use it at home (I want my internal connections between home machines to use 10/8 addresses, even if each of them has also global address). Why should 169.254/16 be anything different and require exception handling in the source address selection? If destination is in 169.254/16, the source should be also 169.254.2.3 (if host has a matching address). Picking an ip.ad.re.ss which happens to be LL from host and trying telnet ip.ad.re.ss on other host will fail miserably, if ip.ad.re.ss is LL, unless "other host" is also LL aware and has 169.254/16 onlink route installed. (Similar failure occurs with 10/8 addresses, LL brings nothing new to the situation). From owner-zeroconf@merit.edu Mon Feb 10 04:34:51 2003 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 EAA01752 for ; Mon, 10 Feb 2003 04:34:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A46D891226; Mon, 10 Feb 2003 04:38:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7852291227; Mon, 10 Feb 2003 04:38:25 -0500 (EST) 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 7237891226 for ; Mon, 10 Feb 2003 04:38:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 563235DE08; Mon, 10 Feb 2003 04:38:24 -0500 (EST) 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 D051E5DDA6 for ; Mon, 10 Feb 2003 04:38:23 -0500 (EST) 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 BAA23943 for ; Mon, 10 Feb 2003 01:38:22 -0800 (PST) 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 h1A9cLl11513 for ; Mon, 10 Feb 2003 10:38:21 +0100 (MET) Date: Mon, 10 Feb 2003 10:38:19 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: WG action - 1 week to discuss [LL19] Do not use v4LL source address to non-v4LL destinations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Sorry for adding yet another issue to the list, but this one has to be decided before we can make much progress. Please see http://www.spybeam.org/ll19.html The proposal makes it impossible for a host with a host with only a v4LL address to communicate with a host with a non-v4LL configuration. This constitutes a major limitation to the protocol. NOTE WELL: Although we are accepting any issues from anyone, we are not opening the protocol up for a complete redesign. For this reason, major changes to the protocol have to be backed up with extremely convincing technical argument. Please discuss this issue until 17 Feb 2003. Unless there is a strong consensus backing this issue, it will be rejected. Erik From owner-zeroconf@merit.edu Mon Feb 10 04:42:37 2003 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 EAA02174 for ; Mon, 10 Feb 2003 04:42:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 89BFD91227; Mon, 10 Feb 2003 04:45:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F36691228; Mon, 10 Feb 2003 04:45:29 -0500 (EST) 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 3AD9F91227 for ; Mon, 10 Feb 2003 04:45:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0ACEA5DDF9; Mon, 10 Feb 2003 04:45:26 -0500 (EST) 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 4B8775DDA6 for ; Mon, 10 Feb 2003 04:45:25 -0500 (EST) 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 CAA04410; Mon, 10 Feb 2003 02:45:17 -0700 (MST) 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 h1A9jGl11681; Mon, 10 Feb 2003 10:45:16 +0100 (MET) Date: Mon, 10 Feb 2003 10:45:15 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Markku Savela Cc: zeroconf@merit.edu Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination In-Reply-To: <200302100932.h1A9WbGJ008273@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Markku, [WG cochair hat on] Do you accept issue 19 or reject it? (Please state this!) [WG participant hat on] Note that LL1 would prefer the a non-LL address and LL17 would enable a host with a non-LL address to communicate with a LL device. We are discussing changing (conforming) hosts. Thus, the argument that Linux works a certain way (today) is not very cogent. Erik ----- On Mon, 10 Feb 2003, Markku Savela wrote: > If I have an interface configured with three addresses (and nets) > > 10.0.0.1 10/8 > 169.254.2.3 169.254/16 > global-addr global/net > > then, if I'm connecting to 10/8 destination I want my source address > to be 10.0.0.1, and for global destination the source should be > global-addr. This appears to be the way my linux works, and this is > how I use it at home (I want my internal connections between home > machines to use 10/8 addresses, even if each of them has also global > address). > > Why should 169.254/16 be anything different and require exception > handling in the source address selection? If destination is in > 169.254/16, the source should be also 169.254.2.3 (if host has a > matching address). > > Picking an ip.ad.re.ss which happens to be LL from host and trying > > telnet ip.ad.re.ss > > on other host will fail miserably, if ip.ad.re.ss is LL, unless "other > host" is also LL aware and has 169.254/16 onlink route > installed. (Similar failure occurs with 10/8 addresses, LL brings > nothing new to the situation). > ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n N1 Installation and Provisioning cell: +49 172 865 5497 Sun Microsystems pager: 01728655497@d2-message.de From owner-zeroconf@merit.edu Mon Feb 10 04:45:42 2003 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 EAA02242 for ; Mon, 10 Feb 2003 04:45:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D3BA991228; Mon, 10 Feb 2003 04:49:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B8169122B; Mon, 10 Feb 2003 04:49:15 -0500 (EST) 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 851B291228 for ; Mon, 10 Feb 2003 04:49:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7267E5DEAA; Mon, 10 Feb 2003 04:49:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 611EC5DDA6 for ; Mon, 10 Feb 2003 04:49:00 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1A9lqn06136; Mon, 10 Feb 2003 16:47:57 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1A9lZb12398; Mon, 10 Feb 2003 16:47:42 +0700 (ICT) From: Robert Elz To: Ted Lemon Cc: Bernard Aboba , zeroconf@merit.edu Subject: Re: [Issue 11] Attacker forces address reconfiguration In-Reply-To: <08336B52-3CA9-11D7-A2AE-00039367340A@nominum.com> References: <08336B52-3CA9-11D7-A2AE-00039367340A@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Feb 2003 16:47:35 +0700 Message-ID: <12396.1044870455@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 9 Feb 2003 21:37:51 -0600 From: Ted Lemon Message-ID: <08336B52-3CA9-11D7-A2AE-00039367340A@nominum.com> | Not only does it bring down existing connections, but it prevents future | connections with ipv4ll-aware hosts that have been attacked similarly - | this was the big disagreement that kre and I had last week. Yes, though we thought that we were disagreeing on a different point (and from the outside, I suspect most others also thought we were disagreeing on a different point - for the list, Ted and I discussed this more in off-list mail, and eventually realised where the disconnect was happening). But, if done properly, it shouldn't "bring down existing connections" (unless the node desires that outcome) but it certainly might prevent future connections. This is really the "security considerations" which is currently applied to LL2 in the issues list - really it belongs to LL1 (and LL23 (??)) as issues (LL11 is just noting security considerations text). | Consider the case where you have a bad guy who wants to prevent devices | on a link with no DHCP server from communicating using IPv4ll. This | bad guy sets up a DHCP server which gives every host an IP address on a | different subnet, and provides a bogus default route that prevents | communication. Yes, this one is certainly possible. Of course, the bad guy who can do this can also prevent IPv4LL from working just by the ARP attack (defend every possible IPv4LL address), so it isn't really very new. How devices recover from each of those kinds of attacks depends entirely upon how the device reacts in these circumstances. That is, 2.2 of the draft says that a node that gets more than 10 LL addresses rejected, as to slow down to no more than one attempt a minute, but doesn't actually say it has to keep on trying - a node could just give up and turn itself off if no LL address is available to it. Similarly, a node given a (trash) DHCP address, with a (trash) default router (etc) can just go away and sulk until its lease is due for renewal, or it can notice that the address it was given doesn't seem to actually work very well (it is not receiving any replies, not receiving any queries), and decide that perhaps it should just try again to get a DHCP assigned address. The effect is that either attack may be successful as a one off, but to truly succeed, the attacker has to wait around and be prepared to repeat the attack over and over again. The DHCP attack (but not the ARP attack) is also theoretically possible from off-link. In practice, the difficulty of guessing a 32 bit (random) transaction I-D, and detecting just when the correct time to send a packet, makes this one so improbable that it can mostly be ignored. | This is a similarly nasty attack to the one allowed by RFC2563. The "2563 attack" is exactly the same attack as this one, not "similarly nasty". If we decide to the attack isn't something that we really need to worry about here, for this issue, then it no longer exists as far as 2563 is concerned either. What this really boils down to, is whether we believe that the extra method of denying a host a v4LL address that defining DHCP to work this way certainly allows (but an extra method is all that it is), is something so heinous that we need to abandon the general simplicity of only using one routable address, most of the time (that is, exactly what IP hosts have been doing - with the possibility of this attack ever since DHCP was invented and started being used - for many years now). My opinion is that there's nothing here bad enough, or new enough, that it needs anything much more than noting in the security considerations, just as the possibility of attacks on the ARP probe packets are mentioned. Mentioning that a host that has an assigned address is entirely free to reconfirm that address at any time, and should do so it it seems that the address doesn't work, would be something useful for the security considerations. Depending upon the host, and its manual configuration method, even a host that has been manually assigned an address might sometimes decide to detect that the assigned address doesn't work, and (attempt to) assign itself a LL address. kre From owner-zeroconf@merit.edu Mon Feb 10 05:15:24 2003 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 FAA03124 for ; Mon, 10 Feb 2003 05:15:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7A0639122B; Mon, 10 Feb 2003 05:18:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3596D9122C; Mon, 10 Feb 2003 05:18:57 -0500 (EST) 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 C843D9122B for ; Mon, 10 Feb 2003 05:18:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id A58945DEB6; Mon, 10 Feb 2003 05:18:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id E695B5DD98 for ; Mon, 10 Feb 2003 05:18:53 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1AAHxn28821; Mon, 10 Feb 2003 17:18:04 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1AAHeb12435; Mon, 10 Feb 2003 17:17:40 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs In-Reply-To: <1044810580.21186.302.camel@devil> References: <1044810580.21186.302.camel@devil> <1044803577.21383.233.camel@devil> <1044793681.21186.107.camel@devil> <1044787452.11519.93.camel@devil> <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> <3689.1044783115@munnari.OZ.AU> <4300.1044789975@munnari.OZ.AU> <4798.1044798098@munnari.OZ.AU> <5583.1044805928@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Feb 2003 17:17:40 +0700 Message-ID: <12433.1044872260@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 09 Feb 2003 19:09:41 +0200 From: Mika Liljeberg Message-ID: <1044810580.21186.302.camel@devil> | Such communication is only possible if you configure at least a | 169.254/16 on-link route on those nodes manually (admittedly, the route | is enough). If the node is a legacy node, yes (that, or the router needs to understand LL addresses, and return packets mistakenly sent to it back to the link they came from). Nodes that understand LL addressing, but don't happen to have an LL address assigned to them shouldn't need this kind of configuration, that should be implicit. | Could you give me some examples of these v4LL nodes that participate in | a routed network but are unable to get a routable address? Huh? If you take a node to my network (LL aware or not) and attempt get get a routable address, you'll fail. DHCP (which works there) is set to only assign addresses to known systems. The DHCP server there won't send a 2563 reply (by default anyway - I'd typically only do that to specific clients that I know about, not just to anything unknown) and so you would get to assign yourself a LL address. So, now your v4LL node would be on a routed network, and unable to get a routable address. Aside from the "bus stop" or "airport" case (purely ad-hoc networks) this is all exactly how v4LL addresses actually work today. The nodes that implement them attempt to get a routable address, if that succeeds they use it. When it fails, they (attempt to) assign a LL address, and they use that. Have you never seen that happen? | It also means the an application, on a node that only has a routable | address, can get a LL address from getpeername() or directly from the | peer as part of the application protocol. Yes. | This leads to exactly those | application problems that Keith has been complaining about. Yes. I know that. But I don't believe that "never allow LL and routable addresses to communicate" fixes that. Even if it did, it would be too high a price to pay. "Prefer routable addresses" (which is something I certainly agree with) deals with most of the issue (most cases). The prohibition wouldn't fix the issue, as you still have to deal with nodes that have both LL and routable addresses (which your proposal would require to exist) which will then still expose both addresses to applications. | I doubt there would be enough incentive to willfully break the RFC in | this case. This of course is all guesswork on both sides, so I will say no more but ask you to look at other RFCs that have prohibited things that users want to do (even when another RFC provides a mechanism). Consider the prohibition on characters outside 0..0x7F in e-mail (and that MIME provides an alternative) and count the users that ignore all of that... | The obvious solution (even for a user) is to get a routable | address to all nodes on the link. If you have one node with only a LL address, then perhaps. But if you have many nodes with LL addresses on some ad-hoc network, and one legacy system that doesn't understand LL?? | 1) The printer has no need to initiate connections to other nodes. How does it report when it needs its paper tray or toner refilled ? | 2) Nodes that support rendezvous can contact to the printer directly. Sure. | 3) Nodes that do not support rendezvous cannot print directly to the | printer even if they have the manually configured 169.254/16 on-link | route, because they have no way of finding the IP address of the | printer. "Hey Mika, what's the IP address of that printer you're using?" | 4) the obvious solution to 3) is to put up a print server that serves | the non-rendezvous nodes. On a managed network, perhaps. For three friends and one of those portable network printers in an airport? Really? | When in doubt, I tend to go for "DO NO HARM". That means that, when | there is potential for harm when v4LL only nodes are introduced into a | routed network, the harm should befall the v4LL nodes and not any | others. Absolute rules rarely work (they just turn into dogma). What's needed is to evaluate the potential harm, weigh the costs of ignoring it, implementing a workaround, or submitting and saying "no". | 2) The host with the DNS server should be v4LL compliant and acquire a | v4LL address. (This has no implications to the DNS server application) Where I first used this as an example is precisely because your parenthetical remark is incorrect. | > I'd prefer to just leave he system with its routable address (and not | > require anything more). | That doesn't make sense to me. I meant, after (s/he/the/) that if a system has a routable address, it needs nothing more, if it is LL aware, or configured, it can communicate with LL addresses - it doesn't need to have its own LL address, and is simpler not to. | I know that. You argued that the DNS server *program* would have to | listen to both the routable and the v4LL address. I responded to that | argument. I argued that it only has to listen to the routable address, | for the reasons above. Oh, now I see what you were saying, but it really doesn't work that way. To make that happen (even assuming that it was a desirable outcome) would require even more complexity than is now required (the server would have to look at each individual address, and determine whether or not that one was one that might be used, or probably wouldn't ever be). | If that's what it means, perhaps it should be said more clearly. That is | certainly not how I read it. OK, then this should be a new "Editorial" issue (the first such issue on the list...) Anytime that different people reading the text come (reasonably) to different conclusions, implies that the text is not clear enough. Once the edtorial issue is cleared up (one way or the other) then there might be some technical issue as to whether what it says is correct, but it is pointless debating that when everyone believes it is correct, because they read it their own way. Do you want to send in an issue for that one, or should I? | That makes sense in normal configurations (and the user interface may | guide you to do this), but there is no need to enforce this within the | TCPIP stack or in the protocol specifications. You can legally have two | addresses on the same interface. Yes, I know, that's fine. The question is more whether you actually want to, given no particularly good reason to do so. | > LL doesn't need to to be much different than that. You (the user, or | > the device manufacturer) pick which address assignment method to use (or | > which sequence to try until one succeeds) and then just let them run. | | s/method/methods/ and I would agree. Oh, good, because I don't mind that change. That is, I don't object to a node being able to be configured explicitly to have multiple addresses (including where one, or more, of them are link local addresses), if that's what someone wants to do with it. And, provided that I have a way to explicitly configure it to have only one address, and that having only one won't prevent me from communicating with anyone else (that the particular address, or address type, I choose is able to reach). All that's left is to decide what the default should be when there is no explicit configuration, and for that, I prefer the simplicity of just one address, of the broadest possible scope available. kre From owner-zeroconf@merit.edu Mon Feb 10 05:41:25 2003 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 FAA03640 for ; Mon, 10 Feb 2003 05:41:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 04AF79122C; Mon, 10 Feb 2003 05:44:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4A1F91230; Mon, 10 Feb 2003 05:44:55 -0500 (EST) 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 B86E29122C for ; Mon, 10 Feb 2003 05:44:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 961325DF2F; Mon, 10 Feb 2003 05:44:54 -0500 (EST) 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 673F25DD98 for ; Mon, 10 Feb 2003 05:44:54 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 98A4359928 for ; Mon, 10 Feb 2003 10:44:52 +0000 (GMT) Message-ID: <011f01c2d0f1$7407f710$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination Date: Mon, 10 Feb 2003 10:44:56 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Bernard Aboba" > > Say a host with a routable address gets a referral to a v4LL address, then > attempts to contact a host at that address... > ... if the host is v4LL capable then it will ARP for the > v4LL address and possibly deliver it... It will also possibly deliver it to a fourth host which just happens to have the same LL address but an another link (a different scope)! I'm not a security expert but isn't there a possible arcane new mechanism for attack from off-link here? Philip From owner-zeroconf@merit.edu Mon Feb 10 07:29:31 2003 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 HAA06656 for ; Mon, 10 Feb 2003 07:29:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 85CA791230; Mon, 10 Feb 2003 07:33:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F9E191232; Mon, 10 Feb 2003 07:33:06 -0500 (EST) 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 CFAEB91230 for ; Mon, 10 Feb 2003 07:32:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id ACE2E5DF62; Mon, 10 Feb 2003 07:32:23 -0500 (EST) 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 61AC35DF55 for ; Mon, 10 Feb 2003 07:32:23 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 57ABC5992A for ; Mon, 10 Feb 2003 12:32:25 +0000 (GMT) Message-ID: <016001c2d100$75b274f0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" Subject: Section 2.6 Date: Mon, 10 Feb 2003 12:32:21 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The heart of much of the controversy over when to use which kind of address is in section 2.6 "Source Address Selection" although LL1 actually only refers to section 1.5 "Supporting Multiple Addresses per Interface" Several of the proposed changes are exacerbated by the fact that 2.6 depite its title "Source Address Selection" actually talks a lot about how to reach destination addresses. I propose that 2.6 be split into two sections (I've numbered them 2.6 and 2.6a for now) to allow issues of source address selection and reaching destination addresses to be treated separately. Based on the existing text in draft 7 these sections would become as below. This text would be potentially modified by issues LL1, LL13, LL17, LL19 and maybe others. Philip 2.6 Source Address Selection Since each interface on a host may have a link-local address in addition to zero or more other addresses configured by other means (e.g. manually or via a DHCP server), a host may have to make a choice about what source address to use when it sends a packet or initiates a TCP connection. 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 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. If the destination address is a unicast address outside the 169.254/16 prefix, then the host SHOULD use an appropriate routable source address, if it has one. If the host does not have a routable source address, then it MAY choose to send its packet, with a link-local source IP address and a routable destination IP address. 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 address, depending on which is expected to be more likely to remain stable for the expected lifetime of the connection. Note that link- local addresses may be forced to change over time, as described in Section 2.5. 2.6a Accessing destination addresses If the destination address of a packet to be sent is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), the host MAY choose to ARP for the destination address and then send its packet, with 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. If the destination address is a unicast address outside the 169.254/16 prefix and the source address is a Link-Local address, then the sender MAY choose to ARP for the destination address and then send its packet, with a link-local source IP address and a routable destination IP address, directly to its destination on the same physical link. The host MUST NOT send the packet to any router for forwarding. From owner-zeroconf@merit.edu Mon Feb 10 09:10:13 2003 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 JAA09662 for ; Mon, 10 Feb 2003 09:10:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F1CAC91234; Mon, 10 Feb 2003 09:13:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDA7A91236; Mon, 10 Feb 2003 09:13:46 -0500 (EST) 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 AF5A991234 for ; Mon, 10 Feb 2003 09:13:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id A01EE5E08E; Mon, 10 Feb 2003 09:13:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 27D5D5E08B for ; Mon, 10 Feb 2003 09:13:45 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1ACwEl27764; Mon, 10 Feb 2003 04:58:14 -0800 Date: Mon, 10 Feb 2003 04:58:13 -0800 (PST) From: Bernard Aboba To: Robert Elz Cc: zeroconf@merit.edu Subject: Re: [Issue 1]: Preferred use of configured to v4LL address In-Reply-To: <12357.1044869045@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > Yes, just as it would now (before LL exists) - if its DHCP (or other > mechanisms) fail, it should (from time to time) try again. But the spec doesn't require this -- or provide guidance on how frequently this should happen, as the original did. > No, the text I proposed in LL23 (LLnn where nn might become 23) makes > that clear I think. Good. > My proposed text doesn't quite go that far - rather, it prohibits it > from initiating new connections, but not from establishing a new one > initiated from some other host (which might have previously learned the > LL address and isn't yet aware that a routable address exists). Good. > | Also if you want to go this route, then you > | need to put in some language about continuing to try to obtain a routable > | address. > > Yes, that would be a good idea. I agree. From owner-zeroconf@merit.edu Mon Feb 10 09:12:45 2003 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 JAA09759 for ; Mon, 10 Feb 2003 09:12:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1936B91236; Mon, 10 Feb 2003 09:15:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2E2991237; Mon, 10 Feb 2003 09:15:16 -0500 (EST) 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 B28BF91236 for ; Mon, 10 Feb 2003 09:15:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 67C2E5DED1; Mon, 10 Feb 2003 09:15:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by segue.merit.edu (Postfix) with ESMTP id 4E6F55E089 for ; Mon, 10 Feb 2003 09:15:12 -0500 (EST) Received: from e35.co.us.ibm.com (e35.esmtp.ibm.com [9.14.4.133]) by pokfb.esmtp.ibm.com (8.12.2/8.12.2) with ESMTP id h1ACex7s102170 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 10 Feb 2003 07:40:59 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e35.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1ACdgBl050688; Mon, 10 Feb 2003 07:39:42 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-229-83.mts.ibm.com [9.65.229.83]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1ACbAPY137196; Mon, 10 Feb 2003 05:37:10 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h1ACYnX21683; Mon, 10 Feb 2003 07:34:49 -0500 Message-Id: <200302101234.h1ACYnX21683@cichlid.adsl.duke.edu> To: "John C. Welch" Cc: Zeroconf Subject: Re: LL2 comment In-Reply-To: Message from jwelch@MIT.EDU of "Sat, 08 Feb 2003 14:32:30 EST." Date: Mon, 10 Feb 2003 07:34:49 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk "John C. Welch" writes: > There are also environments where the configuration has to be explicitly set > / limited. Even where DHCP is used, and would implicitly disable v4LL, that > is not enough of a guarantee that v4LL is turned off. The above seems to say that if DHCP is used, it would implicitely disable v4LL. (I also assume, that the more precise statement here is that i a node sends out DHC requests, and a DHC server responds and assigns the device an address, that is the mechanism for disabling the need to configure a LL address). Why is this not enough to deal with the problem? Note: there is _no_ way to guarantee that v4ll is turned off. Implementations can be broken. Implementations can chose to ignore the specs, etc. Thus, we're not looking for a 100% solution. We're looking for one that works good enough in practice. But if there is a clear way to indicate "LL does not need to be used on this network", why is this not sufficient? Thomas From owner-zeroconf@merit.edu Mon Feb 10 09:13:03 2003 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 JAA09789 for ; Mon, 10 Feb 2003 09:13:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D21EA91235; Mon, 10 Feb 2003 09:16:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 996E291237; Mon, 10 Feb 2003 09:16:35 -0500 (EST) 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 EBE2591235 for ; Mon, 10 Feb 2003 09:16:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0E47C5E089; Mon, 10 Feb 2003 09:16:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8B58A5DED1 for ; Mon, 10 Feb 2003 09:16:29 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1ACqdx27499; Mon, 10 Feb 2003 04:52:39 -0800 Date: Mon, 10 Feb 2003 04:52:39 -0800 (PST) From: Bernard Aboba To: Robert Elz Cc: Keith Moore , Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination In-Reply-To: <12309.1044867795@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > One way is that I type "ifconfig -a" (or some other OS equivalent) > on the system I am intending to be the destination, notice an address > assigned to the network interface, swivel in my chair, and type > > telnet ip.add.re.ss > > on the other system. Actually, this is also not a counter-example. If TCP actually completes the three-way handshake, then the system on which you typed telnet 169.254.X.Y supports LLv4. If it didn't, the TCP SYN would have been sent to the gateway and routed off into nether-space. From owner-zeroconf@merit.edu Mon Feb 10 09:16:19 2003 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 JAA09873 for ; Mon, 10 Feb 2003 09:16:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3263A91239; Mon, 10 Feb 2003 09:19:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F265B9123B; Mon, 10 Feb 2003 09:19:51 -0500 (EST) 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 F24D691239 for ; Mon, 10 Feb 2003 09:19:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id D5E3E5E089; Mon, 10 Feb 2003 09:19:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by segue.merit.edu (Postfix) with ESMTP id 741425E086 for ; Mon, 10 Feb 2003 09:19:50 -0500 (EST) Received: from e32.co.us.ibm.com (e32.esmtp.ibm.com [9.14.4.130]) by pokfb.esmtp.ibm.com (8.12.2/8.12.2) with ESMTP id h1ACtk7s049756 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 10 Feb 2003 07:55:50 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e32.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1ACsUKI100654; Mon, 10 Feb 2003 07:54:30 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-229-83.mts.ibm.com [9.65.229.83]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1ACrDPY170830; Mon, 10 Feb 2003 05:53:13 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h1ACoqA21720; Mon, 10 Feb 2003 07:50:52 -0500 Message-Id: <200302101250.h1ACoqA21720@cichlid.adsl.duke.edu> To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: WG action - 1 week to discuss [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses In-Reply-To: Message from Erik.Guttman@Sun.COM of "Sun, 09 Feb 2003 15:03:41 +0100." Date: Mon, 10 Feb 2003 07:50:52 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk > This issue evoked no comment during the not-very-successful recent > "WG consensus action: when to configure LL addrs" From the issues page: > This will replace the similar text in the specification: > > 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 MUST 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 the destination > on the same physical link. In many network stacks, achieving this > functionality may be as simple as adding a routing table entry > indicating that 169.254/16 is directly reachable on the local link. > The host MUST NOT send a packet with a link-local destination address > to any router for forwarding. The above text is blurring two issues. I agree that when sending a packet to a 169.254/16 destination, the packet should just be sent out on the link, i.e., after ARPing for the destination. But this should happen regardless of what source address in use. The above text seems to tie the use of ARP to when the source address is global. Is there a need for that? Thoams From owner-zeroconf@merit.edu Mon Feb 10 09:17:35 2003 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 JAA09897 for ; Mon, 10 Feb 2003 09:17:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B1529123B; Mon, 10 Feb 2003 09:21:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0CFA29123C; Mon, 10 Feb 2003 09:21:00 -0500 (EST) 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 1510A9123B for ; Mon, 10 Feb 2003 09:21:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 046545DED1; Mon, 10 Feb 2003 09:21:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by segue.merit.edu (Postfix) with ESMTP id 99B645DDB9 for ; Mon, 10 Feb 2003 09:20:59 -0500 (EST) Received: from e33.co.us.ibm.com (e33.esmtp.ibm.com [9.14.4.131]) by pokfb.esmtp.ibm.com (8.12.2/8.12.2) with ESMTP id h1ACnG7s093640 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 10 Feb 2003 07:49:17 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e33.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1ACltUn057442; Mon, 10 Feb 2003 07:47:58 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-229-83.mts.ibm.com [9.65.229.83]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1AClrPY168228; Mon, 10 Feb 2003 05:47:53 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h1ACjXr21706; Mon, 10 Feb 2003 07:45:33 -0500 Message-Id: <200302101245.h1ACjXr21706@cichlid.adsl.duke.edu> To: Robert Elz Cc: zeroconf@merit.edu Subject: Re: Proposed text for LL2 In-Reply-To: Message from kre@munnari.OZ.AU of "Sun, 09 Feb 2003 17:57:08 +0700." <3910.1044788228@munnari.OZ.AU> Date: Mon, 10 Feb 2003 07:45:32 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk I continue to be confused about the subtle arguments about disabling LL. Robert Elz writes: > Many nodes using this protocol, on large networks, can cause excessive > traffic as explained in the previous section (1.2). For this reason, > and others, it can be necessary to disable use of link-local addresses > in some situations where they are not required. What does this mean exactly? If those devices have normal addresses assigned to them, they won't need to be using LL and the problem no longer exists. Right? Why on a managed network would there still be devices around that insist on assigning LL addresses to their interfaces? Thomas From owner-zeroconf@merit.edu Mon Feb 10 09:20:32 2003 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 JAA09964 for ; Mon, 10 Feb 2003 09:20:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 824109123C; Mon, 10 Feb 2003 09:24:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 501609123D; Mon, 10 Feb 2003 09:24:05 -0500 (EST) 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 49F889123C for ; Mon, 10 Feb 2003 09:24:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F7345DFC7; Mon, 10 Feb 2003 09:24:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B6F9E5DDF3 for ; Mon, 10 Feb 2003 09:24:03 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1ACtRc27645; Mon, 10 Feb 2003 04:55:27 -0800 Date: Mon, 10 Feb 2003 04:55:27 -0800 (PST) From: Bernard Aboba To: Robert Elz Cc: zeroconf@merit.edu Subject: Re: [Issue 2] Explicit Additional Mechanism to disable v4LL In-Reply-To: <12338.1044868595@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > That assumes that the DHCP server wants the node in question connected > (at all) to the network it is attached to, doesn't it? What do you do > when the DHCP server wants to say "you are on the wrong network" ? Normally, the DHCP server sends a NAK in that circumstance, no? From owner-zeroconf@merit.edu Mon Feb 10 09:29:46 2003 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 JAA10192 for ; Mon, 10 Feb 2003 09:29:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 419EA9123D; Mon, 10 Feb 2003 09:33:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D7C99123E; Mon, 10 Feb 2003 09:33:19 -0500 (EST) 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 E358D9123D for ; Mon, 10 Feb 2003 09:33:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id B77385DDC2; Mon, 10 Feb 2003 09:33:18 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 3283D5DD92 for ; Mon, 10 Feb 2003 09:33:17 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1ACsdh27595; Mon, 10 Feb 2003 04:54:40 -0800 Date: Mon, 10 Feb 2003 04:54:39 -0800 (PST) From: Bernard Aboba To: Robert Elz Cc: Keith Moore , Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination In-Reply-To: <12328.1044868454@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > | The question is whether it is possible to communicate between hosts with > | *only* a routable address, and hosts with *only* a v4LL address. I believe > | that this is valuable > > So do I. I take it from this that you're opposing LL19? That hasn't > been clear in any of your other messages... Yes, I oppose LL19. > The text you proposed in your original message is fine, except the > "MAY choose to ARP" should turn into "MUST ARP". (That's more or > less LL17, in reverse, and that issue should be discussed under that subject). Yes. > | -- because there can be simple devices that will > | only want to use v4LL addresses even when a DHCP server is available. > > Keith's "such devices shouldn't exist" (whether true or not) is irrelevant > here. The issue isn't whether a DHCP server is available or not, nor > whether the device is able to, or actually does, request a routable addr, but > whether the DHCP server offers an address to the node. If the DHCP server > doesn't offer an address, and also doesn't say "don't use LL", then > clearly the node gets an LL address, and that's all it has. I agree. From owner-zeroconf@merit.edu Mon Feb 10 09:37:54 2003 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 JAA10487 for ; Mon, 10 Feb 2003 09:37:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 96C4F9123E; Mon, 10 Feb 2003 09:41:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A7549123F; Mon, 10 Feb 2003 09:41:26 -0500 (EST) 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 3A3B89123E for ; Mon, 10 Feb 2003 09:41:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E79C5E08A; Mon, 10 Feb 2003 09:41:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 944E25E089 for ; Mon, 10 Feb 2003 09:41:24 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1AD2l328113; Mon, 10 Feb 2003 05:02:47 -0800 Date: Mon, 10 Feb 2003 05:02:47 -0800 (PST) From: Bernard Aboba To: Robert Elz Cc: Ted Lemon , Subject: Re: [Issue 11] Attacker forces address reconfiguration In-Reply-To: <12396.1044870455@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > The effect is that either attack may be successful as a one off, but to > truly succeed, the attacker has to wait around and be prepared to repeat > the attack over and over again. Unless the implementation gives up at some point. That's a bad idea -- but is a likely choice unless we explicitly address this in the spec. > My opinion is that there's nothing here bad enough, or new enough, that > it needs anything much more than noting in the security considerations, > just as the possibility of attacks on the ARP probe packets are mentioned. Yes, this one has been around a long time -- and is not unique to LLv4. > Mentioning that a host that has an assigned address is entirely free to > reconfirm that address at any time, and should do so it it seems that the > address doesn't work, would be something useful for the security > considerations. And for reliability too. > Depending upon the host, and its manual configuration > method, even a host that has been manually assigned an address might > sometimes decide to detect that the assigned address doesn't work, and > (attempt to) assign itself a LL address. The trick of course is how to know that "the assigned address doesn't work". From owner-zeroconf@merit.edu Mon Feb 10 09:39:13 2003 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 JAA10522 for ; Mon, 10 Feb 2003 09:39:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 70B029123F; Mon, 10 Feb 2003 09:42:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44ABF91240; Mon, 10 Feb 2003 09:42:46 -0500 (EST) 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 241AA9123F for ; Mon, 10 Feb 2003 09:42:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0C3955DDB9; Mon, 10 Feb 2003 09:42:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by segue.merit.edu (Postfix) with ESMTP id DF7125DD92 for ; Mon, 10 Feb 2003 09:42:44 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18iF82-0003wV-00; Mon, 10 Feb 2003 06:41:50 -0800 Date: Mon, 10 Feb 2003 09:39:33 -0500 From: Keith Moore To: Bernard Aboba Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination Message-Id: <20030210093933.50d919b1.moore@cs.utk.edu> In-Reply-To: References: <12309.1044867795@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Mon, 10 Feb 2003 04:52:39 -0800 (PST) Bernard Aboba wrote: > > One way is that I type "ifconfig -a" (or some other OS equivalent) > > on the system I am intending to be the destination, notice an address > > assigned to the network interface, swivel in my chair, and type > > > > telnet ip.add.re.ss > > > > on the other system. > > Actually, this is also not a counter-example. If TCP actually > completes the three-way handshake, then the system on which you typed > telnet 169.254.X.Y supports LLv4. not necessarily. it could have been configured to ARP for that prefix. or it could be programmed to ARP for that prefix even if it could not configure an LL address by itself. as far as I can tell it would be a good idea to recommend that v4 hosts arp for LL addresses even if they don't have code to configure LL addresses. That would allow them to communicate with hosts that, for whatever reason, don't have a routable address. however I want to think more about the multiple interface case before I'm confident of that. and I wonder how many platforms would "partially" implement LL rather than doing either all or nothing. From owner-zeroconf@merit.edu Mon Feb 10 09:59:31 2003 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 JAA11257 for ; Mon, 10 Feb 2003 09:59:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 88B5491241; Mon, 10 Feb 2003 10:02:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36F4791242; Mon, 10 Feb 2003 10:02:57 -0500 (EST) 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 BD94F91241 for ; Mon, 10 Feb 2003 10:02:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 76EA85E089; Mon, 10 Feb 2003 10:02:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id F25595DDFC for ; Mon, 10 Feb 2003 10:02:40 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1AF2Ln17231; Mon, 10 Feb 2003 22:02:21 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1AF2Hb14254; Mon, 10 Feb 2003 22:02:17 +0700 (ICT) From: Robert Elz To: Bernard Aboba Cc: zeroconf@merit.edu Subject: Re: [Issue 2] Explicit Additional Mechanism to disable v4LL In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Feb 2003 22:02:17 +0700 Message-ID: <14252.1044889337@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 10 Feb 2003 04:55:27 -0800 (PST) From: Bernard Aboba Message-ID: | Normally, the DHCP server sends a NAK in that circumstance, no? no. kre From owner-zeroconf@merit.edu Mon Feb 10 09:59:36 2003 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 JAA11270 for ; Mon, 10 Feb 2003 09:59:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BB6FD91243; Mon, 10 Feb 2003 10:02:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CED491240; Mon, 10 Feb 2003 10:02:58 -0500 (EST) 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 9DCF391240 for ; Mon, 10 Feb 2003 10:02:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 721245DFC7; Mon, 10 Feb 2003 10:02:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id F35325DF55 for ; Mon, 10 Feb 2003 10:02:40 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1AF2Dn17203; Mon, 10 Feb 2003 22:02:13 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1AF1xb14244; Mon, 10 Feb 2003 22:01:59 +0700 (ICT) From: Robert Elz To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: Proposed text for LL2 In-Reply-To: <200302101245.h1ACjXr21706@cichlid.adsl.duke.edu> References: <200302101245.h1ACjXr21706@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Feb 2003 22:01:59 +0700 Message-ID: <14242.1044889319@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 10 Feb 2003 07:45:32 -0500 From: Thomas Narten Message-ID: <200302101245.h1ACjXr21706@cichlid.adsl.duke.edu> | Why on a managed network would there still be devices around that | insist on assigning LL addresses to their interfaces? Thomas, if I bring my laptop to your office in IBM (wherever you are located) and plug it in, I assume I'm likely to be on a managed network. I also assume your managed network will never have heard of my laptop, and depending on how it is run, might not want to allocate me a routable address, right? In that case, my laptop has 2 options. Either it assigns itself a LL address, or it does not. Obviously I can cause it to do either of those (it is mind after all), but assuming I am willing to accede to the wishes of IBM's network managers (given I am connecting to their net, I should), don't you think they should have some way to indicate which of the two options they'd like my laptop to select? kre From owner-zeroconf@merit.edu Mon Feb 10 10:02:29 2003 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 KAA11381 for ; Mon, 10 Feb 2003 10:02:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CC84591240; Mon, 10 Feb 2003 10:06:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A3A791242; Mon, 10 Feb 2003 10:06:01 -0500 (EST) 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 9641C91240 for ; Mon, 10 Feb 2003 10:06:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C6A65DED1; Mon, 10 Feb 2003 10:06:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id E00225DD92 for ; Mon, 10 Feb 2003 10:05:54 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1AF5mn17790; Mon, 10 Feb 2003 22:05:48 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1AF5db14265; Mon, 10 Feb 2003 22:05:39 +0700 (ICT) From: Robert Elz To: Bernard Aboba Cc: Ted Lemon , zeroconf@merit.edu Subject: Re: [Issue 11] Attacker forces address reconfiguration In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Feb 2003 22:05:39 +0700 Message-ID: <14263.1044889539@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 10 Feb 2003 05:02:47 -0800 (PST) From: Bernard Aboba Message-ID: | The trick of course is how to know that "the assigned address doesn't | work". Sending packets and receiving replies is a good indication of "does work". Getting (relevant) queries or messages also (where relevant probably means addressed to a port where there's something waiting). Having neither of those happen is a good clue to "not work" - it doesn't need to be perfect, in a situation where the address would work, but the net just happens to be quiet, the cost of wrongly assuming that the config is broken is 1 DHCP exchange (4 packets if done all the way, which it probably should be for this). kre From owner-zeroconf@merit.edu Mon Feb 10 10:19:07 2003 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 KAA11868 for ; Mon, 10 Feb 2003 10:19:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E3F4491242; Mon, 10 Feb 2003 10:22:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A77D891244; Mon, 10 Feb 2003 10:22:38 -0500 (EST) 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 A184E91242 for ; Mon, 10 Feb 2003 10:22:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 85D955E089; Mon, 10 Feb 2003 10:22:37 -0500 (EST) 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 526325DDFC for ; Mon, 10 Feb 2003 10:22:37 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id F1D565992E for ; Mon, 10 Feb 2003 15:22:39 +0000 (GMT) Message-ID: <01da01c2d118$3dcf20c0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <200302101250.h1ACoqA21720@cichlid.adsl.duke.edu> Subject: Re: WG action - 1 week to discuss [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses Date: Mon, 10 Feb 2003 15:22:36 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Thomas Narten" > > From the issues page: > > > This will replace the similar text in the specification: > > > > 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 MUST 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 the destination > > on the same physical link. In many network stacks, achieving this > > functionality may be as simple as adding a routing table entry > > indicating that 169.254/16 is directly reachable on the local link. > > The host MUST NOT send a packet with a link-local destination address > > to any router for forwarding. > > The above text is blurring two issues. I agree that when sending a > packet to a 169.254/16 destination, the packet should just be sent out > on the link, i.e., after ARPing for the destination. But this should > happen regardless of what source address in use. The above text seems > to tie the use of ARP to when the source address is global. Is there > a need for that? I have already posted an issue to separate these two issues. See my email "Section 2.6" earlier today which I have now sent as an issue. There is a need to consider the source address in picking what to do with the destination ONLY when the source address is LL - in which case the packet must not be sent to a router and the options are either to ARP for the destination (whether global or LL) or to simply drop the packet. Philip From owner-zeroconf@merit.edu Mon Feb 10 10:45:42 2003 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 KAA12852 for ; Mon, 10 Feb 2003 10:45:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DB5A691244; Mon, 10 Feb 2003 10:49:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD02A91245; Mon, 10 Feb 2003 10:49:16 -0500 (EST) 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 C9A2791244 for ; Mon, 10 Feb 2003 10:49:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id B30835DE4C; Mon, 10 Feb 2003 10:49:15 -0500 (EST) 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 85F875DDAC for ; Mon, 10 Feb 2003 10:49:15 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 455EA598AC for ; Mon, 10 Feb 2003 15:49:18 +0000 (GMT) Message-ID: <01f901c2d11b$f66a77d0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <12328.1044868454@munnari.OZ.AU> Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination Date: Mon, 10 Feb 2003 15:49:14 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Robert Elz" > > The text you proposed in your original message is fine, except the > "MAY choose to ARP" should turn into "MUST ARP". (That's more or > less LL17, in reverse, and that issue should be discussed under that subject). Given that the text also says you MUST NOT forward to a router what is the alternative(s) suggested by "MAY choose to ARP"? Without rewording, the only alternative I can see is to drop the packet so I don't think the rewording is as big an issue as you suggest. Philip From owner-zeroconf@merit.edu Mon Feb 10 10:48:32 2003 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 KAA12951 for ; Mon, 10 Feb 2003 10:48:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF76891245; Mon, 10 Feb 2003 10:52:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8300191246; Mon, 10 Feb 2003 10:52:05 -0500 (EST) 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 5E93691245 for ; Mon, 10 Feb 2003 10:52:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4E26E5E008; Mon, 10 Feb 2003 10:52:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 358005DE4C for ; Mon, 10 Feb 2003 10:52:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id CB18914047; Mon, 10 Feb 2003 10:52:03 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 20746-03; Mon, 10 Feb 2003 10:52:03 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 0BEE014019; Mon, 10 Feb 2003 10:52:03 -0500 (EST) Date: Mon, 10 Feb 2003 10:52:02 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: handling of conflicting proposals for an issue (was Re: New issue: [LL20] Alternate text for LL12) Message-Id: <20030210105202.78061452.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 97c99e1a955ac807a59fd27ddd2dfab7aa9b000a Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Please see http://www.spybeam.org/ll20.html > > Note that this issue is a distinct alternative to LL12. We will have > to choose between them. Mumble. when there are alternate proposed resolutions to a single question I suspect it works better to file them under the same issue than to number them separately. It's hard enough to keep track of the various issues as-is. Keith From owner-zeroconf@merit.edu Mon Feb 10 10:51:31 2003 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 KAA13213 for ; Mon, 10 Feb 2003 10:51:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8BB2991246; Mon, 10 Feb 2003 10:55:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B62891247; Mon, 10 Feb 2003 10:55:04 -0500 (EST) 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 3F1F791246 for ; Mon, 10 Feb 2003 10:55:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 12FF25DF70; Mon, 10 Feb 2003 10:55:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by segue.merit.edu (Postfix) with ESMTP id A93F85DE4C for ; Mon, 10 Feb 2003 10:55:02 -0500 (EST) Received: from e35.co.us.ibm.com (e35.esmtp.ibm.com [9.14.4.133]) by pokfb.esmtp.ibm.com (8.12.2/8.12.2) with ESMTP id h1ADHw7s040418 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Mon, 10 Feb 2003 08:18:04 -0500 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e35.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1ADFPBl036396; Mon, 10 Feb 2003 08:15:25 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-229-83.mts.ibm.com [9.65.229.83]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1ADFNih154862; Mon, 10 Feb 2003 06:15:24 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h1ADD3n21793; Mon, 10 Feb 2003 08:13:03 -0500 Message-Id: <200302101313.h1ADD3n21793@cichlid.adsl.duke.edu> To: Markku Savela Cc: zeroconf@merit.edu Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination In-Reply-To: Message from msa@burp.tkv.asdf.org of "Mon, 10 Feb 2003 11:32:37 +0200." <200302100932.h1A9WbGJ008273@burp.tkv.asdf.org> Date: Mon, 10 Feb 2003 08:13:03 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk > If I have an interface configured with three addresses (and nets) > 10.0.0.1 10/8 > 169.254.2.3 169.254/16 > global-addr global/net Question: to what degree is the above supported by existing IPv4 clients? Granted, I don't doubt linux supports this, but there are no IETF documents AFAIK that talk about IPv4 devices needing to support multiple addresses per interface and all the details that implies. I suspect that many plaforms don't, or do it in an ad hoc way. We (in this WG) are not going to change that. In IPv6 we've specified the desirable behavior for multiple addresses on an interface, and it's fairly complicated. There is an entire document on address selection rules (draft-ietf-ipv6-default-addr-select-09.txt), for instance. I don't believe we want to have to do the equivalent of that document for IPv4 as part of specifying LL addresses. What I think we're trying to do here is make LL addresses work reasonably well with one other global address, since we expect that to happen at times, even if we don't really want that to be the normal (or recommended) behavior. Certainly, we want the intended behavior to be clear, if a device has only a LL address and attempts to communicate with a device having only a non-LL address. > Why should 169.254/16 be anything different and require exception > handling in the source address selection? If destination is in > 169.254/16, the source should be also 169.254.2.3 (if host has a > matching address). Because we don't really have general address selection rules for IPv4, and we probably don't want to go there. Thomas From owner-zeroconf@merit.edu Mon Feb 10 10:53:54 2003 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 KAA13306 for ; Mon, 10 Feb 2003 10:53:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BC4E191247; Mon, 10 Feb 2003 10:57:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C05F91248; Mon, 10 Feb 2003 10:57:28 -0500 (EST) 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 77D6C91247 for ; Mon, 10 Feb 2003 10:57:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 619C25DDB9; Mon, 10 Feb 2003 10:57:27 -0500 (EST) 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 290175DDAC for ; Mon, 10 Feb 2003 10:57:27 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 2785B5993A for ; Mon, 10 Feb 2003 15:57:30 +0000 (GMT) Message-ID: <021101c2d11d$1b976a80$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: Subject: Detection of working configured address Date: Mon, 10 Feb 2003 15:57:25 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Bernard Aboba" > > > Depending upon the host, and its manual configuration > > method, even a host that has been manually assigned an address might > > sometimes decide to detect that the assigned address doesn't work, and > > (attempt to) assign itself a LL address. > > The trick of course is how to know that "the assigned address doesn't > work". This is particularly relevent when a host detects a reconnection or wakes up after shutdown or sleep. It may have a static address or a perfectly valid DHCP lease. How does it detect whether it is still on the same network where these were valid? In the case of DHCP it can attempt to renew, but that can take a long time and might fail for other reasons - because the DHCP server is down doesn't mean that the existing lease can't be used. One quick method would be to ARP for the default router (and any other routes). If it can't get to a router then assigning a LL address is probably a good bet. Is there any mileage in putting discussion of this case in the draft? Philip From owner-zeroconf@merit.edu Mon Feb 10 11:05:05 2003 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 LAA13600 for ; Mon, 10 Feb 2003 11:05:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 14D1B91248; Mon, 10 Feb 2003 11:08:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D07F491249; Mon, 10 Feb 2003 11:08:37 -0500 (EST) 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 9DEFB91248 for ; Mon, 10 Feb 2003 11:08:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7ABE55DDB9; Mon, 10 Feb 2003 11:08:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 62A7C5DDAC for ; Mon, 10 Feb 2003 11:08:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 27F6014019; Mon, 10 Feb 2003 11:08:36 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 23486-01; Mon, 10 Feb 2003 11:08:35 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 752D413FF5; Mon, 10 Feb 2003 11:08:35 -0500 (EST) Date: Mon, 10 Feb 2003 11:08:35 -0500 From: Keith Moore To: zeroconf@merit.edu Cc: moore@cs.utk.edu Subject: too many issues with short fuses / suggestion for issue page Message-Id: <20030210110835.2febf964.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Spam-Status: No, hits=0.8 tagged_above=0.0 required=7.0 tests=SPAM_PHRASE_00_01 X-Spam-Level: X X-Razor-id: ebbc29c41e2df1b4e1021c6b38c3f0f3766cbe97 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit okay, there are too many issues with short fuses. as far as I can tell, there are one-week timeouts on 6, 7, 8, 11, 16, 17, 19. that's about 2 times too many, and some of these issues are complex or ill-formed enough that one week simply isn't enough. also, it would help if the issue status page had some indication of which issues were in short-fuse mode. Keith From owner-zeroconf@merit.edu Mon Feb 10 11:06:34 2003 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 LAA13649 for ; Mon, 10 Feb 2003 11:06:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1798091249; Mon, 10 Feb 2003 11:10:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF82C9124A; Mon, 10 Feb 2003 11:10:08 -0500 (EST) 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 E1AAD91249 for ; Mon, 10 Feb 2003 11:10:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id CF2805DDB9; Mon, 10 Feb 2003 11:10:07 -0500 (EST) 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 A0E945DDAC for ; Mon, 10 Feb 2003 11:10:07 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id BAD0759934 for ; Mon, 10 Feb 2003 16:10:10 +0000 (GMT) Message-ID: <024e01c2d11e$e0ea9810$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <200302101245.h1ACjXr21706@cichlid.adsl.duke.edu> Subject: Re: Proposed text for LL2 Date: Mon, 10 Feb 2003 16:10:06 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Thomas Narten" > > What does this mean exactly? If those devices have normal addresses > assigned to them, they won't need to be using LL and the problem no > longer exists. Right? > > Why on a managed network would there still be devices around that > insist on assigning LL addresses to their interfaces? Even in the case where hosts only get a LL address if they don't have a global one there are reasons why a host may be running both addresses (I know this isn't quite what you asked). 1. You had a LL address and have now got a global one but are still in the process of transitioning to using the global one exclusively. 2. You have a configured address (either static or a valid lease on a DHCP address) but it is not working so you assign a LL address too. Philip From owner-zeroconf@merit.edu Mon Feb 10 11:10:16 2003 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 LAA13777 for ; Mon, 10 Feb 2003 11:10:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2EC0D9124A; Mon, 10 Feb 2003 11:13:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E25689124B; Mon, 10 Feb 2003 11:13:48 -0500 (EST) 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 D64E99124A for ; Mon, 10 Feb 2003 11:13:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id B57345E08D; Mon, 10 Feb 2003 11:13:47 -0500 (EST) 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 344EA5E089 for ; Mon, 10 Feb 2003 11:13:47 -0500 (EST) 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 JAA06648; Mon, 10 Feb 2003 09:13:45 -0700 (MST) 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 h1AGDhl27116; Mon, 10 Feb 2003 17:13:43 +0100 (MET) Date: Mon, 10 Feb 2003 17:13:42 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Keith Moore Cc: zeroconf@merit.edu Subject: Re: too many issues with short fuses / suggestion for issue page In-Reply-To: <20030210110835.2febf964.moore@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, 10 Feb 2003, Keith Moore wrote: > okay, there are too many issues with short fuses. as far as I can tell, > there are one-week timeouts on 6, 7, 8, 11, 16, 17, 19. that's about 2 > times too many, and some of these issues are complex or ill-formed > enough that one week simply isn't enough. I made an error announcing 7. 7 is really 10. This is an indication that you are probably right - there are too many issues in '1 week last call.' These should've been easy and gone fast. There'll be fewer next week! > also, it would help if the issue status page had some indication of > which issues were in short-fuse mode. ASAP. Erik From owner-zeroconf@merit.edu Mon Feb 10 11:13:24 2003 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 LAA13902 for ; Mon, 10 Feb 2003 11:13:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4EBFD9124B; Mon, 10 Feb 2003 11:16:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A2459124C; Mon, 10 Feb 2003 11:16:33 -0500 (EST) 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 80BBB9124B for ; Mon, 10 Feb 2003 11:16:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7DDAD5DE4C; Mon, 10 Feb 2003 11:16:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by segue.merit.edu (Postfix) with ESMTP id 3480E5DDB9 for ; Mon, 10 Feb 2003 11:16:13 -0500 (EST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Mon, 10 Feb 2003 08:16:11 -0800 Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Feb 2003 08:16:08 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 10 Feb 2003 08:16:13 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 10 Feb 2003 08:16:08 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3760.0); Mon, 10 Feb 2003 08:16:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [Issue 19] Use v4LL source address for non-V4LL destination Date: Mon, 10 Feb 2003 08:16:06 -0800 Message-ID: Thread-Topic: [Issue 19] Use v4LL source address for non-V4LL destination thread-index: AcLRErZhecUzixGeQhWT7Mk4DhM6vgAC+AcA From: "Christian Huitema" To: "Keith Moore" , "Bernard Aboba" Cc: , X-OriginalArrivalTime: 10 Feb 2003 16:16:08.0312 (UTC) FILETIME=[B8206F80:01C2D11F] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA13902 I propose that the issue 19 be rejected. The proposed text would eliminate the possibility of exchange between LL addressed hosts and on-link hosts with a non LL address; as such it forces the "configured" hosts to either configure an LL address, or refuse all communication with an LL addressed host. Neither of these two alternatives is desirable. We debated the configuration issue at length last month, and there was a rough consensus that hosts with a configured address (DHCP or administrative action) should not be obliged to also configure an LL address, because it might confuse non LL aware application (e.g. a SIP UA) -- see issue LL1. There is also a strong point that, at least in transient situation, preventing communication is undesirable. -- Christian Huitema From owner-zeroconf@merit.edu Mon Feb 10 11:15:57 2003 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 LAA14005 for ; Mon, 10 Feb 2003 11:15:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 14B499124C; Mon, 10 Feb 2003 11:19:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C64279124D; Mon, 10 Feb 2003 11:19:31 -0500 (EST) 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 99BFB9124C for ; Mon, 10 Feb 2003 11:19:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8068E5DDB9; Mon, 10 Feb 2003 11:19:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 65E015DDAC for ; Mon, 10 Feb 2003 11:19:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 321E913FF5; Mon, 10 Feb 2003 11:19:30 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 24099-08; Mon, 10 Feb 2003 11:19:29 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 8F77313FD6; Mon, 10 Feb 2003 11:19:29 -0500 (EST) Date: Mon, 10 Feb 2003 11:19:29 -0500 From: Keith Moore To: zeroconf@merit.edu Cc: moore@cs.utk.edu Subject: [LL19] objection Message-Id: <20030210111929.37ce2ca6.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Spam-Status: No, hits=0.8 tagged_above=0.0 required=7.0 tests=SPAM_PHRASE_00_01 X-Spam-Level: X X-Razor-id: cadcb6c2fa12ff411488afd7e3d21c75b9836a12 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I object to the LL 19 proposal. Frankly, if you're going to arrange things so that ordinary IPv4 hosts cannot talk to hosts using LL addresses, then you have no business overloading the IPv4 programming interface for LL. Applications expect IPv4 hosts to be able to talk to one another. If you want a completely separate protocol, fine, but don't call it IP. It's true that legacy hosts won't be able to talk to v4LL addresses absent some code modification or explicit configuration to ARP on a link. The immediate (and probably long-term) workaround is to not use v4LL on networks that use routable addresses. This can be accomplished by either statically configuring the nodes that would otherwise use v4LL (on networks that statically configure all hosts) or by having a DHCP server assign routable addresses to such nodes. Alternatively, non-LL hosts can be configured to ARP for LL addresses. Maybe there is a need for a new issue here - to address communication between LL-capable hosts and legacy hosts on the same link? From owner-zeroconf@merit.edu Mon Feb 10 11:23:43 2003 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 LAA14315 for ; Mon, 10 Feb 2003 11:23:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BE2019124D; Mon, 10 Feb 2003 11:27:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BC059124E; Mon, 10 Feb 2003 11:27:16 -0500 (EST) 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 592E49124D for ; Mon, 10 Feb 2003 11:27:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3CF4A5DE4C; Mon, 10 Feb 2003 11:27:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 23EC75DDB9 for ; Mon, 10 Feb 2003 11:27:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id E2B3014047; Mon, 10 Feb 2003 11:27:14 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 25474-08; Mon, 10 Feb 2003 11:27:14 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 5149B13FF5; Mon, 10 Feb 2003 11:27:14 -0500 (EST) Date: Mon, 10 Feb 2003 11:27:14 -0500 From: Keith Moore To: Alex Karahalios Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination Message-Id: <20030210112714.1ab9d2f7.moore@cs.utk.edu> In-Reply-To: <1A8A74B6-3CCD-11D7-833C-00039377AD70@Outersoft.com> References: <20030209215540.613f59c8.moore@cs.utk.edu> <1A8A74B6-3CCD-11D7-833C-00039377AD70@Outersoft.com> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 5886423b8e1bed237540146267fcb509fc67df7e Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I guess putting the word "period." at the end of your sentence makes > it more definitive ;) But I think the standard should permit such > simple devices. Not every device has the luxury of implementing a DHCP > client. I strongly disagree. IETF's job is to explain how hosts and apps can interoperate. Standardizing crippled behavior does not facilitate interoperation. If implementing enough of DHCP to allow a device to acquire a routable address, a netmask, and a default route is too onerous, then we need another mechanism - but other people have claimed that this burden is not unreasonable. But we do not need to standardize dysfunctional behavior. Here's how I would phrase it. Every device that expects to be able to automatically configure itself MUST support DHCP, and MAY support v4LL. A device that expects to be manually configured MAY support an option to be configured by DHCP, and MAY support an option to be configured by v4LL. Of course, nothing stops a device vendor from implementing only v4LL. But they shouldn't be able to claim that IETF said it was okay to do that. Keith From owner-zeroconf@merit.edu Mon Feb 10 11:29:37 2003 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 LAA14544 for ; Mon, 10 Feb 2003 11:29:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ADCE59124E; Mon, 10 Feb 2003 11:33:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 796EC9124F; Mon, 10 Feb 2003 11:33:03 -0500 (EST) 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 46D439124E for ; Mon, 10 Feb 2003 11:33:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 34A765DDF6; Mon, 10 Feb 2003 11:33:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 1B3A45DDF3 for ; Mon, 10 Feb 2003 11:33:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id DC4B913FF5; Mon, 10 Feb 2003 11:33:01 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 26203-08; Mon, 10 Feb 2003 11:33:01 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 3DB0A1401E; Mon, 10 Feb 2003 11:33:01 -0500 (EST) Date: Mon, 10 Feb 2003 11:33:01 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Proposed text for LL2 Message-Id: <20030210113301.57090498.moore@cs.utk.edu> In-Reply-To: <024e01c2d11e$e0ea9810$131010ac@aldebaran> References: <200302101245.h1ACjXr21706@cichlid.adsl.duke.edu> <024e01c2d11e$e0ea9810$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 7a46d9e371eb239dd0b46e1d782fcbc1b752a352 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 10 Feb 2003 16:10:06 -0000 "Philip Nye" wrote: > > From: "Thomas Narten" > > > > What does this mean exactly? If those devices have normal addresses > > assigned to them, they won't need to be using LL and the problem no > > longer exists. Right? > > > > Why on a managed network would there still be devices around that > > insist on assigning LL addresses to their interfaces? > > Even in the case where hosts only get a LL address if they don't have > a global one there are reasons why a host may be running both > addresses (I know this isn't quite what you asked). > > 1. You had a LL address and have now got a global one but are still in > the process of transitioning to using the global one exclusively. > > 2. You have a configured address (either static or a valid lease on a > DHCP address) but it is not working so you assign a LL address too. I agree that there are cases where a host can legitimately have both an LL and a routable address. I don't agree that your case #2 is a valid one, because "address obtained from DHCP not working" is not a justification for a host to configure an LL address. How can a host distinguish the case where an address is "not working" because the address given to it was bogus, from several other legitimate cases? From owner-zeroconf@merit.edu Mon Feb 10 11:36:38 2003 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 LAA14765 for ; Mon, 10 Feb 2003 11:36:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A83319124F; Mon, 10 Feb 2003 11:40:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7BF2891250; Mon, 10 Feb 2003 11:40:10 -0500 (EST) 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 558809124F for ; Mon, 10 Feb 2003 11:40:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 422715DF33; Mon, 10 Feb 2003 11:40:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 298A35DEC5 for ; Mon, 10 Feb 2003 11:40:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id E13CD1403F; Mon, 10 Feb 2003 11:40:08 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 27749-01; Mon, 10 Feb 2003 11:40:08 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 44D5213FF5; Mon, 10 Feb 2003 11:40:08 -0500 (EST) Date: Mon, 10 Feb 2003 11:40:08 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Detection of working configured address Message-Id: <20030210114008.0241335f.moore@cs.utk.edu> In-Reply-To: <021101c2d11d$1b976a80$131010ac@aldebaran> References: <021101c2d11d$1b976a80$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: c828a1d1dbdacb089c5b6540426415ab3428bcd2 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > This is particularly relevent when a host detects a reconnection or > wakes up after shutdown or sleep. It may have a static address or a > perfectly valid DHCP lease. How does it detect whether it is still on > the same network where these were valid? There are a whole set of issues related to host recovery from moving, sleep/wakeup, network failures, dhcp failures, etc., all of which present the host with similar conditions but may require different recovery techniques depending on exactly what has happened. It would be useful to work out recommendations for such recovery but I doubt we'll be able to do this for this draft -- or for that matter, in this working group. For instance, hosts ought to be able to assume that a DHCP lease is renewable in the event that the server cannot be contacted. But this isn't the way that DHCP was designed to work, and it can't be fixed without changes in DHCP. But the last thing I'd want is for a host that had a DHCP address, that happened to try to renew its lease at a brief time when the DHCP server was inaccessible, to deprecate its routable address in favor of a v4LL address. That would make the host nearly useless in many situations. Keith From owner-zeroconf@merit.edu Mon Feb 10 11:37:52 2003 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 LAA14799 for ; Mon, 10 Feb 2003 11:37:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 088B591250; Mon, 10 Feb 2003 11:41:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA5E991251; Mon, 10 Feb 2003 11:41:25 -0500 (EST) 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 CC83E91250 for ; Mon, 10 Feb 2003 11:41:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id BB06C5DF4D; Mon, 10 Feb 2003 11:41:24 -0500 (EST) 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 6DF035DDF3 for ; Mon, 10 Feb 2003 11:41:24 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 2F55E5994E for ; Mon, 10 Feb 2003 16:41:27 +0000 (GMT) Message-ID: <027f01c2d123$3f4ebae0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <200302101245.h1ACjXr21706@cichlid.adsl.duke.edu><024e01c2d11e$e0ea9810$131010ac@aldebaran> <20030210113301.57090498.moore@cs.utk.edu> Subject: Re: Proposed text for LL2 Date: Mon, 10 Feb 2003 16:41:23 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Keith Moore" > > > 2. You have a configured address (either static or a valid lease on a > > DHCP address) but it is not working so you assign a LL address too. > > I agree that there are cases where a host can legitimately have both an > LL and a routable address. I don't agree that your case #2 is a valid > one, because "address obtained from DHCP not working" is not a > justification for a host to configure an LL address. How can a host > distinguish the case where an address is "not working" because the > address given to it was bogus, from several other legitimate cases? I was rather vague on this - but consider the case where you unplug your laptop at work and plug it in at home. It still has a valid DHCP lease but that address and configuration are most unlikely to work. This is a common use case which IPv4LL ought to address and I am not sure how it does so. I made a suggestion in an earlier post "Detection of working configured address". Philip From owner-zeroconf@merit.edu Mon Feb 10 11:40:53 2003 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 LAA14976 for ; Mon, 10 Feb 2003 11:40:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F031091251; Mon, 10 Feb 2003 11:44:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9D0891252; Mon, 10 Feb 2003 11:44:26 -0500 (EST) 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 B7E9A91251 for ; Mon, 10 Feb 2003 11:44:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 946355DF4D; Mon, 10 Feb 2003 11:44:25 -0500 (EST) 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 665BB5DDF6 for ; Mon, 10 Feb 2003 11:44:25 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id A729A5991E for ; Mon, 10 Feb 2003 16:44:28 +0000 (GMT) Message-ID: <028601c2d123$ab78dac0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" Subject: LL19 Date: Mon, 10 Feb 2003 16:44:24 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I oppose LL 19 If we were to mandate that in order to talk to a LL host, you need a LL address yourself, then we get back to the case where hosts run both addresses side by side as a matter of course. Unless we see workable suggestions for how to resolve the consequent issues of knowing which address to select in this case, I cannot support this. See previous communications on referrals (among others) for descriptions of these issues. Philip From owner-zeroconf@merit.edu Mon Feb 10 11:43:26 2003 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 LAA15066 for ; Mon, 10 Feb 2003 11:43:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5CB4291252; Mon, 10 Feb 2003 11:46:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 265B991253; Mon, 10 Feb 2003 11:46:52 -0500 (EST) 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 DBA9291252 for ; Mon, 10 Feb 2003 11:46:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id C0E855DDF6; Mon, 10 Feb 2003 11:46:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 64E355DDC2 for ; Mon, 10 Feb 2003 11:46:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 292991403F; Mon, 10 Feb 2003 11:46:48 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 27740-09; Mon, 10 Feb 2003 11:46:47 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 87E9F13FF5; Mon, 10 Feb 2003 11:46:47 -0500 (EST) Date: Mon, 10 Feb 2003 11:46:47 -0500 From: Keith Moore To: zeroconf@merit.edu Cc: moore@cs.utk.edu Subject: [LL17] ARPing vs. forwarding to router Message-Id: <20030210114647.7086b7f4.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Spam-Status: No, hits=0.8 tagged_above=0.0 required=7.0 tests=SPAM_PHRASE_00_01 X-Spam-Level: X X-Razor-id: 7132d8e09e87d705d540710ebc8c438f1c8bfc5b Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree that the way that a LL-capable host sends to an LL destination address is to ARP for that address (if it's not in the host's ARP cache), and in general treat the destination as if it were on-link, rather than to forward the packet to a router. However the issue seems to be stated awkwardly. - It doesn't matter whether the packet to the LL destination is being sent is a reply. - Also, "MUST NOT" forward to a router is fine, but "MUST ARP" has the potential to be misread. In general, a host is not required to reply to an incoming packet. If it doesn't want to reply, it shouldn't have to ARP for that packet either. It's probably better if the correct behavior is not stated in terms of MUST. Keith From owner-zeroconf@merit.edu Mon Feb 10 11:57:22 2003 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 LAA15536 for ; Mon, 10 Feb 2003 11:57:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9574091267; Mon, 10 Feb 2003 11:59:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 667A391259; Mon, 10 Feb 2003 11:59:26 -0500 (EST) 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 A4A489125D for ; Mon, 10 Feb 2003 11:59:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 915E75DDC2; Mon, 10 Feb 2003 11:59:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 6CFF05DDF3 for ; Mon, 10 Feb 2003 11:59:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 331951403F; Mon, 10 Feb 2003 11:59:20 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 30307-03; Mon, 10 Feb 2003 11:59:19 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 863C213FF1; Mon, 10 Feb 2003 11:59:19 -0500 (EST) Date: Mon, 10 Feb 2003 11:59:19 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: [LL7] Add warnings to applicability statement Message-Id: <20030210115919.5b066601.moore@cs.utk.edu> In-Reply-To: <1044787864.11519.98.camel@devil> References: <3727.1044784720@munnari.OZ.AU> <1044787864.11519.98.camel@devil> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 404e2e24f0db5ed8cf6036284246b316d156bdd0 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Incidentally I think the text in 1.4: > > "Note that addresses in the 169.254/16 prefix SHOULD NOT be configured > manually or by a DHCP server." > > Should be clarified to: > > "Note that addresses in the 169.254/16 prefix SHOULD NOT be configured > manually, by a DHCP server, or by any mechanism other than the one > described in this document." > > The plugs a perceived loop hole regarding address configuration > methods other than v4LL, DHCP, or manual configuration. You want to clearly distinguish between requirements on protocol implementations and expectations of users or network operators. And SHOULD NOT has a specific meaning that is intended to specify implementation requirements. Thus it's fine to say Addresses in the range 169.254/16 are reserved for use as link-local addresses that are allocated and configured according to this specification or subsequent revisions. Under normal conditions, users should not assign manually configure interfaces with such addresses, nor should DHCP servers be configured to return such addresses. But you should not use the SHOULD NOT language unless you want to impose constraints on protocol implementations, e.g. - DHCP servers SHOULD NOT accept a configuration directing them to assign such addresses to hosts, or - Hosts SHOULD NOT accept manual configuration of interfaces using addresses in this range ...neither of which I would find desirable. Keith From owner-zeroconf@merit.edu Mon Feb 10 12:05:43 2003 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 MAA15895 for ; Mon, 10 Feb 2003 12:05:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 47925912B2; Mon, 10 Feb 2003 12:08:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A282912B6; Mon, 10 Feb 2003 12:08:22 -0500 (EST) 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 65195912B2 for ; Mon, 10 Feb 2003 12:08:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5474A5DDF3; Mon, 10 Feb 2003 12:08:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 3C20B5DDC3 for ; Mon, 10 Feb 2003 12:08:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 0836F13FF1; Mon, 10 Feb 2003 12:08:14 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 31441-04; Mon, 10 Feb 2003 12:08:13 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 61FB913FE7; Mon, 10 Feb 2003 12:08:13 -0500 (EST) Date: Mon, 10 Feb 2003 12:08:13 -0500 From: Keith Moore To: zeroconf@merit.edu Cc: moore@cs.utk.edu Subject: [LL6] security considerations for wireless LANs Message-Id: <20030210120813.142ec5b4.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Spam-Status: No, hits=0.8 tagged_above=0.0 required=7.0 tests=SPAM_PHRASE_00_01 X-Spam-Level: X X-Razor-id: daea34e13e2950168362b9e4318b4fc5b9e2b659 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think this needs to be much stronger than the text proposed. A host should NEVER automatically configure itself to a wireless LAN, regardless of whether it is using LL or DHCP or some other mechanism, unless the LAN can authenticate itself and the host has been configured to trust it. I just received my laptop back from repair. Before I shipped it off for repair they asked me to change the root password so they could run diagnostics on it. Not wanting to disclose my normal password, I changed it to a "throwaway" password which is deliberately chosen to be insecure, and enclosed a note indicating that password. (There was nothing sensitive on the laptop, and I decided that I would trust this vendor to not modify the laptop in such a way as to further compromise security. This may have been unwise on my part, but at least it was an explicit decision.) When I got the laptop back, I was very careful to not connect it to a network until I had changed the root password back to something reasonable. But in the process of doing so I found that the laptop had automatically connected to the local wireless LAN, exposing it to attack. (The laptop was _not_ configured to do so when I sent it off, because connectivity to the wireless LAN from my office is marginal, and 100Mb ethernet is much faster anyway.) Keith From owner-zeroconf@merit.edu Mon Feb 10 12:08:43 2003 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 MAA15980 for ; Mon, 10 Feb 2003 12:08:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C5A6912B6; Mon, 10 Feb 2003 12:09:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFDB191287; Mon, 10 Feb 2003 12:08:53 -0500 (EST) 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 D966E912BC for ; Mon, 10 Feb 2003 12:08:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id BDC105DDF3; Mon, 10 Feb 2003 12:08:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 6A0D35DDAC for ; Mon, 10 Feb 2003 12:08:46 -0500 (EST) Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1AH5EP23152; Mon, 10 Feb 2003 11:05:14 -0600 (CST) Date: Mon, 10 Feb 2003 09:54:12 -0600 Subject: Re: [Issue 2] Explicit Additional Mechanism to disable v4LL Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Robert Elz , zeroconf@merit.edu To: Bernard Aboba From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> That assumes that the DHCP server wants the node in question connected >> (at all) to the network it is attached to, doesn't it? What do you >> do >> when the DHCP server wants to say "you are on the wrong network" ? > > Normally, the DHCP server sends a NAK in that circumstance, no? No, it sends no response to the DHCP client. A DHCPNAK can't be sent in response to a DHCPDISCOVER. From owner-zeroconf@merit.edu Mon Feb 10 12:13:16 2003 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 MAA16116 for ; Mon, 10 Feb 2003 12:13:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 600879125A; Mon, 10 Feb 2003 12:16:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 213A69125F; Mon, 10 Feb 2003 12:16:46 -0500 (EST) 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 CC7229125A for ; Mon, 10 Feb 2003 12:16:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id AED565DE45; Mon, 10 Feb 2003 12:16:41 -0500 (EST) 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 3CC2D5DDF6 for ; Mon, 10 Feb 2003 12:16:41 -0500 (EST) 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 MAA25976 for ; Mon, 10 Feb 2003 12:16:40 -0500 (EST) 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 MAA18856 for ; Mon, 10 Feb 2003 12:16:40 -0500 (EST) Received: from [18.18.3.76] (WINDEL1.MIT.EDU [18.18.3.76]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA14103 for ; Mon, 10 Feb 2003 12:16:39 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 10 Feb 2003 12:16:38 -0500 Subject: Re: LL2 comment From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200302101234.h1ACYnX21683@cichlid.adsl.duke.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 02/10/2003 07:34, "Thomas Narten" wrote: > But if there is a clear way to indicate "LL does not need to be used > on this network", why is this not sufficient? Because if the DHCP server goes down, then v4LL would of course start up and commence to trying to get addresses. There are environments where network access *has** to be explicitly controlled. This already exists for DHCP...if you manually configure your box, and there is no DHCP server, then you don't have DHCP. However, this is not the case for v4LL. If you are in a DHCP environment, and DHCP goes down, then you now have unauthorized networks creating themselves. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Feb 10 12:13:27 2003 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 MAA16133 for ; Mon, 10 Feb 2003 12:13:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4ED1C9125D; Mon, 10 Feb 2003 12:16:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E3E591262; Mon, 10 Feb 2003 12:16:47 -0500 (EST) 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 0F1D79125D for ; Mon, 10 Feb 2003 12:16:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id E9D4D5DDF6; Mon, 10 Feb 2003 12:16:41 -0500 (EST) 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 89FEE5DE25 for ; Mon, 10 Feb 2003 12:16:41 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id h1AHGeA29812 for ; Mon, 10 Feb 2003 12:16:41 -0500 (EST) Message-Id: <200302101716.h1AHGeA29812@astro.cs.utk.edu> To: zeroconf@merit.edu Subject: [LL2] way to disable LL Date: Mon, 10 Feb 2003 12:16:40 -0500 From: Keith Moore Sender: owner-zeroconf@merit.edu Precedence: bulk This illustrates one of the problems with look at these issues in isolation - the various issues can interact. There needs to be *some* way for a network to disable LL. Using a DHCP response to mean "deprecate your LL address and use a routable address instead" is sufficient for most purposes, as long as it's required of all LL implementations. (SHOULD implement DHCP, along with some discussion about why, might be good enough.) For those hosts that provide manual configuration as an option, a means to disable LL via manual configuration, (or for that matter, to enable it even in the presence of DHCP) is also desirable. I'd be fine with saying that hosts SHOULD provide such an option, but also fine with a similar recommendation with fewer teeth. Keith From owner-zeroconf@merit.edu Mon Feb 10 12:14:58 2003 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 MAA16261 for ; Mon, 10 Feb 2003 12:14:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 66D889125F; Mon, 10 Feb 2003 12:18:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3496891259; Mon, 10 Feb 2003 12:18:25 -0500 (EST) 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 DD9379125F for ; Mon, 10 Feb 2003 12:18:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id B60B05DDC6; Mon, 10 Feb 2003 12:18:00 -0500 (EST) 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 4CCEA5DDB0 for ; Mon, 10 Feb 2003 12:18:00 -0500 (EST) 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 MAA26751 for ; Mon, 10 Feb 2003 12:17:59 -0500 (EST) 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 MAA23377 for ; Mon, 10 Feb 2003 12:17:59 -0500 (EST) Received: from [18.18.3.76] (WINDEL1.MIT.EDU [18.18.3.76]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA14812 for ; Mon, 10 Feb 2003 12:17:58 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 10 Feb 2003 12:17:57 -0500 Subject: Re: Proposed text for LL2 From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200302101245.h1ACjXr21706@cichlid.adsl.duke.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 02/10/2003 07:45, "Thomas Narten" wrote: >> Many nodes using this protocol, on large networks, can cause excessive >> traffic as explained in the previous section (1.2). For this reason, >> and others, it can be necessary to disable use of link-local addresses >> in some situations where they are not required. > > What does this mean exactly? If those devices have normal addresses > assigned to them, they won't need to be using LL and the problem no > longer exists. Right? > > Why on a managed network would there still be devices around that > insist on assigning LL addresses to their interfaces? Because a company will decide to do it to give their customers more features, or customers will demand it, and wave checkbooks. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Feb 10 12:22:38 2003 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 MAA16646 for ; Mon, 10 Feb 2003 12:22:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 29FAD91259; Mon, 10 Feb 2003 12:26:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EDD5791262; Mon, 10 Feb 2003 12:26:11 -0500 (EST) 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 B51C991259 for ; Mon, 10 Feb 2003 12:26:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9DE105DDB0; Mon, 10 Feb 2003 12:26:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 84B025DDAC for ; Mon, 10 Feb 2003 12:26:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 3B1F713FE7; Mon, 10 Feb 2003 12:26:10 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 00905-06; Mon, 10 Feb 2003 12:26:09 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 3DF3013FA4; Mon, 10 Feb 2003 12:26:09 -0500 (EST) Date: Mon, 10 Feb 2003 12:26:08 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, mika.liljeberg@welho.com, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: Proposed text for LL2 Message-Id: <20030210122608.50d3d478.moore@cs.utk.edu> In-Reply-To: References: <1044796483.21383.156.camel@devil> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 07b8dfa188224c82c3082c36604e71aa8c488bda Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > [WG chair hat off, WG participant hat on.] > > The WG has members who assert there is a use case for a v4LL only > device. This group will probably not accept any text which states > that configuration is required. There may be use cases for v4LL-only devices. However there is no use case for a v4LL-only device that merits IETF standardization. Vendors that want to produce v4LL-only devices that are only intended to work on specific or highly-constrained networks are free to do so, but defining behavior of devices on such networks is not in scope for IETF, and those vendors should not be able to claim that such devices meet IETF standards. > The IESG on the other hand will likely reject a document which is seen > to promote v4LL-only devices as a recommended configuration. I hope they reject any document that permits v4LL-only devices to claim conformance to the standard. If they do not do so, I trust the IAB will see fit to override the IESG on that. Balkanazing IP is not consistent with IETF's mission. Any host that attempts to automatically configure an address MUST (or at least SHOULD) initially, and at intervals thereafter, attempt to get a routable address/netmask and a default route from DHCP and if such are obtained, use these in preference to v4LL configuration. So I'm strongly opposed to the text as suggested. Keith From owner-zeroconf@merit.edu Mon Feb 10 12:42:59 2003 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 MAA17653 for ; Mon, 10 Feb 2003 12:42:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7443191262; Mon, 10 Feb 2003 12:46:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43F8D91268; Mon, 10 Feb 2003 12:46:31 -0500 (EST) 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 C9B1B91262 for ; Mon, 10 Feb 2003 12:46:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 17E535DE4C; Mon, 10 Feb 2003 12:46:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id F14855DDAC for ; Mon, 10 Feb 2003 12:46:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id AA5F113FF8; Mon, 10 Feb 2003 12:46:02 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 03154-09; Mon, 10 Feb 2003 12:46:02 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 17FAD13FF5; Mon, 10 Feb 2003 12:46:02 -0500 (EST) Date: Mon, 10 Feb 2003 12:46:01 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Proposed text for LL2 Message-Id: <20030210124601.5c22d134.moore@cs.utk.edu> In-Reply-To: <027f01c2d123$3f4ebae0$131010ac@aldebaran> References: <200302101245.h1ACjXr21706@cichlid.adsl.duke.edu> <024e01c2d11e$e0ea9810$131010ac@aldebaran> <20030210113301.57090498.moore@cs.utk.edu> <027f01c2d123$3f4ebae0$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: d90c0b3fb5e7565eada0176e9c22f9a1ae360ad6 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 10 Feb 2003 16:41:23 -0000 "Philip Nye" wrote: > > From: "Keith Moore" > > > > > 2. You have a configured address (either static or a valid lease > > > on a DHCP address) but it is not working so you assign a LL > > > address too. > > > > I agree that there are cases where a host can legitimately have both > > an LL and a routable address. I don't agree that your case #2 is a > > valid one, because "address obtained from DHCP not working" is not a > > justification for a host to configure an LL address. How can a host > > distinguish the case where an address is "not working" because the > > address given to it was bogus, from several other legitimate cases? > > I was rather vague on this - but consider the case where you unplug > your laptop at work and plug it in at home. It still has a valid DHCP > lease but that address and configuration are most unlikely to work. media sense helps. and a host really ought to be able to ask "is my lease still valid here" without having to risk losing the lease if it's on the same network as before. however, I doubt we can fix those problems in this WG. Keith From owner-zeroconf@merit.edu Mon Feb 10 12:47:39 2003 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 MAA17866 for ; Mon, 10 Feb 2003 12:47:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 460799126D; Mon, 10 Feb 2003 12:49:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0514891270; Mon, 10 Feb 2003 12:49:12 -0500 (EST) 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 8E0FF9126D for ; Mon, 10 Feb 2003 12:49:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 60FBC5DDF6; Mon, 10 Feb 2003 12:49:07 -0500 (EST) 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 322AF5DDB0 for ; Mon, 10 Feb 2003 12:49:07 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 8FD615995A for ; Mon, 10 Feb 2003 17:49:10 +0000 (GMT) Message-ID: <02e901c2d12c$b531c820$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <200302101245.h1ACjXr21706@cichlid.adsl.duke.edu><024e01c2d11e$e0ea9810$131010ac@aldebaran><20030210113301.57090498.moore@cs.utk.edu><027f01c2d123$3f4ebae0$131010ac@aldebaran> <20030210124601.5c22d134.moore@cs.utk.edu> Subject: Re: Proposed text for LL2 Date: Mon, 10 Feb 2003 17:49:06 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Keith Moore" > > > I was rather vague on this - but consider the case where you unplug > > your laptop at work and plug it in at home. It still has a valid DHCP > > lease but that address and configuration are most unlikely to work. > > media sense helps. > > and a host really ought to be able to ask "is my lease still valid here" > without having to risk losing the lease if it's on the same network as > before. however, I doubt we can fix those problems in this WG. This is part of transition from configured to unconfigured which is in the charter. However, I agree it is open ended. Philip From owner-zeroconf@merit.edu Mon Feb 10 14:25:55 2003 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 OAA21588 for ; Mon, 10 Feb 2003 14:25:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 63B04913A6; Mon, 10 Feb 2003 14:01:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D6A5913A2; Mon, 10 Feb 2003 13:55:41 -0500 (EST) 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 98D6A913D1 for ; Mon, 10 Feb 2003 13:53:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 87FB05DE4C; Mon, 10 Feb 2003 13:53:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 373B25DDC3 for ; Mon, 10 Feb 2003 13:53:10 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1AIrfQF030451; Mon, 10 Feb 2003 20:53:41 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1AIrdXo030450; Mon, 10 Feb 2003 20:53:39 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [LL7] Add warnings to applicability statement From: Mika Liljeberg To: Keith Moore Cc: kre@munnari.OZ.AU, zeroconf@merit.edu In-Reply-To: <20030210115919.5b066601.moore@cs.utk.edu> References: <3727.1044784720@munnari.OZ.AU> <1044787864.11519.98.camel@devil> <20030210115919.5b066601.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044903218.29383.19.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 10 Feb 2003 20:53:38 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-02-10 at 18:59, Keith Moore wrote: > You want to clearly distinguish between requirements on protocol > implementations and expectations of users or network operators. And > SHOULD NOT has a specific meaning that is intended to specify > implementation requirements. Thus it's fine to say > > Addresses in the range 169.254/16 are reserved for use as link-local > addresses that are allocated and configured according to this > specification or subsequent revisions. Under normal conditions, users > should not assign manually configure interfaces with such addresses, > nor should DHCP servers be configured to return such addresses. It would be good to make clear that this concerns *all* manual configuration of LL addresses: Addresses in the range 169.254/16 are reserved for use as link-local addresses that are allocated and configured according to this specification or subsequent revisions. Under normal conditions, users should not manually configure interfaces with such addresses, nor should DHCP servers or any other address allocation mechanisms be configured to return such addresses. > But you should not use the SHOULD NOT language unless you want to impose > constraints on protocol implementations, e.g. Good point. MikaL From owner-zeroconf@merit.edu Mon Feb 10 14:37:33 2003 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 OAA22043 for ; Mon, 10 Feb 2003 14:37:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3806C914A6; Mon, 10 Feb 2003 14:28:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE1759144B; Mon, 10 Feb 2003 14:16:29 -0500 (EST) 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 BA9E4913F2 for ; Mon, 10 Feb 2003 13:59:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id A5DB45DE4C; Mon, 10 Feb 2003 13:59:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id ACA085DDC3 for ; Mon, 10 Feb 2003 13:59:25 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1AJ01QF030478; Mon, 10 Feb 2003 21:00:02 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1AIxx9w030477; Mon, 10 Feb 2003 20:59:59 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL2 comment From: Mika Liljeberg To: "John C. Welch" Cc: Zeroconf In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044903598.29380.23.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 10 Feb 2003 20:59:58 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-02-10 at 19:16, John C. Welch wrote: > There are environments where network access *has** to be explicitly > controlled. This already exists for DHCP...if you manually configure your > box, and there is no DHCP server, then you don't have DHCP. However, this is > not the case for v4LL. If you are in a DHCP environment, and DHCP goes down, > then you now have unauthorized networks creating themselves. This is a bogus argument. User's can always manually configure themselves an address and create unauthorized networks. MikaL From owner-zeroconf@merit.edu Mon Feb 10 14:45:01 2003 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 OAA22412 for ; Mon, 10 Feb 2003 14:45:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2F75D91417; Mon, 10 Feb 2003 14:25:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4CD3B9146D; Mon, 10 Feb 2003 14:22:15 -0500 (EST) 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 EAF5991443 for ; Mon, 10 Feb 2003 14:15:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 147705DED1; Mon, 10 Feb 2003 14:15:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 312CB5DD9E for ; Mon, 10 Feb 2003 14:15:15 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1AJFZQF030549; Mon, 10 Feb 2003 21:15:35 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1AJFWvM030548; Mon, 10 Feb 2003 21:15:32 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination From: Mika Liljeberg To: Keith Moore Cc: Bernard Aboba , kre@munnari.OZ.AU, zeroconf@merit.edu In-Reply-To: <20030210093933.50d919b1.moore@cs.utk.edu> References: <12309.1044867795@munnari.OZ.AU> <20030210093933.50d919b1.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044904531.29383.30.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 10 Feb 2003 21:15:32 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-02-10 at 16:39, Keith Moore wrote: > as far as I can tell it would be a good idea to recommend that v4 hosts > arp for LL addresses even if they don't have code to configure LL addresses. > That would allow them to communicate with hosts that, for whatever reason, > don't have a routable address. however I want to think more about the > multiple interface case before I'm confident of that. and I wonder how many > platforms would "partially" implement LL rather than doing either all or > nothing. If you put this in the specification you're sending people a message that it is standard operating procedure to have v4LL-only nodes as part of routed networks and configure servers to listen at v4LL addresses. It would be much better to just restrict v4LL addresses for communication with other nodes that have v4LL addresses. Nodes on routed networks should use routable addresses, always. MikaL From owner-zeroconf@merit.edu Mon Feb 10 14:58:15 2003 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 OAA22941 for ; Mon, 10 Feb 2003 14:58:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B8F7B914D2; Mon, 10 Feb 2003 15:00:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51BED914E4; Mon, 10 Feb 2003 14:44:31 -0500 (EST) 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 1A57E91272 for ; Mon, 10 Feb 2003 14:26:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE12B5DDFA; Mon, 10 Feb 2003 14:26:14 -0500 (EST) 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 81E5A5DD9E for ; Mon, 10 Feb 2003 14:26:14 -0500 (EST) 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 OAA29334 for ; Mon, 10 Feb 2003 14:26:08 -0500 (EST) 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 OAA22109 for ; Mon, 10 Feb 2003 14:21:26 -0500 (EST) Received: from [18.18.3.76] (WINDEL1.MIT.EDU [18.18.3.76]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA18162 for ; Mon, 10 Feb 2003 14:21:26 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 10 Feb 2003 14:21:24 -0500 Subject: Re: LL2 comment From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <1044903598.29380.23.camel@devil> 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 02/10/2003 13:59, "Mika Liljeberg" wrote: >> There are environments where network access *has** to be explicitly >> controlled. This already exists for DHCP...if you manually configure your >> box, and there is no DHCP server, then you don't have DHCP. However, this is >> not the case for v4LL. If you are in a DHCP environment, and DHCP goes down, >> then you now have unauthorized networks creating themselves. > > This is a bogus argument. User's can always manually configure > themselves an address and create unauthorized networks. No, they can't reconfigure machine settings if the permissions are locked down correctly. For example, in Mac OS X, I can lock normal users out of the network config utilities GUI and otherwise. Most other operating systems allow this as well. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Feb 10 15:08:48 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23303 for ; Mon, 10 Feb 2003 15:08:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A1F569154E; Mon, 10 Feb 2003 15:04:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9FAC9150D; Mon, 10 Feb 2003 15:01:45 -0500 (EST) 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 14D6C914C4 for ; Mon, 10 Feb 2003 14:48:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0083C5DE4C; Mon, 10 Feb 2003 14:48:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id CB0215DE27 for ; Mon, 10 Feb 2003 14:48:26 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1AJmxQF030658; Mon, 10 Feb 2003 21:48:59 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1AJmtNY030657; Mon, 10 Feb 2003 21:48:55 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination From: Mika Liljeberg To: Thomas Narten Cc: Markku Savela , zeroconf@merit.edu In-Reply-To: <200302101313.h1ADD3n21793@cichlid.adsl.duke.edu> References: <200302101313.h1ADD3n21793@cichlid.adsl.duke.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044906533.29380.56.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 10 Feb 2003 21:48:54 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-02-10 at 15:13, Thomas Narten wrote: > > If I have an interface configured with three addresses (and nets) > > > 10.0.0.1 10/8 > > 169.254.2.3 169.254/16 > > global-addr global/net > > Question: to what degree is the above supported by existing IPv4 > clients? Granted, I don't doubt linux supports this, but there are no > IETF documents AFAIK that talk about IPv4 devices needing to support > multiple addresses per interface and all the details that implies. I > suspect that many plaforms don't, or do it in an ad hoc way. We (in > this WG) are not going to change that. There is nothing particularly hard about supporting multiple addresses per interface in an implementation. We could require that all v4LL compliant nodes must support this. I agree that you're not going to change this for non-v4LL compliant nodes. There will be a *lot* of such nodes around, no matter what this specification states. Such nodes will be able to communicate with v4LL-only nodes only if you're lucky, i.e., only if they support manual configuraton of a 169.256/16 route and only if someone has happened to do so. Therefore, a v4LL address should never be used as source address when connecting to a routable address. There is simply no reliable way to know whether the target node will be able to respond. > In IPv6 we've specified the desirable behavior for multiple addresses > on an interface, and it's fairly complicated. There is an entire > document on address selection rules > (draft-ietf-ipv6-default-addr-select-09.txt), for instance. Well, that particular draft is overly complex, no disagreement there. We don't need to replicate that. A simple equivalent of the longest prefix match algorithm will suffice. > I don't believe we want to have to do the equivalent of that document > for IPv4 as part of specifying LL addresses. Making the rules extremely simple and predictable is what LL19 is all about. Single rule: the scopes of source and destination addresses MUST match This makes the possible failure modes extremely simple to understand. Mixing LL addresses with routable addresses, on the other hand, creates a much more complex situation with a bunch of different failure modes that can cause intermittent connectivity problems. > What I think we're trying to do here is make LL addresses work > reasonably well with one other global address, since we expect that to > happen at times, even if we don't really want that to be the normal > (or recommended) behavior. I think that philosophy is flawed. We should make it crystal clear, in which situations it is safe and appropriate to use v4LL addressing and in which not. > Certainly, we want the intended behavior to > be clear, if a device has only a LL address and attempts to > communicate with a device having only a non-LL address. The behaviour will soon come clear to the user: it often won't work. > > Why should 169.254/16 be anything different and require exception > > handling in the source address selection? If destination is in > > 169.254/16, the source should be also 169.254.2.3 (if host has a > > matching address). > > Because we don't really have general address selection rules for IPv4, > and we probably don't want to go there. Source and destination scopes MUST match. MikaL From owner-zeroconf@merit.edu Mon Feb 10 15:21:34 2003 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 PAA24014 for ; Mon, 10 Feb 2003 15:21:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3CA0391591; Mon, 10 Feb 2003 15:24:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D337914D7; Mon, 10 Feb 2003 15:19:08 -0500 (EST) 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 98DDE9127A for ; Mon, 10 Feb 2003 15:16:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id C45F65DED1; Mon, 10 Feb 2003 15:16:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id C26325DEAA for ; Mon, 10 Feb 2003 15:16:09 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1AKFYQF030767; Mon, 10 Feb 2003 22:15:54 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1AKE7Hn030755; Mon, 10 Feb 2003 22:14:07 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL19 From: Mika Liljeberg To: Philip Nye Cc: Zeroconf Working Group In-Reply-To: <028601c2d123$ab78dac0$131010ac@aldebaran> References: <028601c2d123$ab78dac0$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044908026.29380.76.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 10 Feb 2003 22:13:46 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-02-10 at 18:44, Philip Nye wrote: > I oppose LL 19 > > If we were to mandate that in order to talk to a LL host, you need a LL > address yourself, then we get back to the case where hosts run both > addresses side by side as a matter of course. That's exactly what should be required: 1) Nodes participating in a routed network must have a routable address. > Unless we see workable suggestions for how to resolve the consequent issues > of knowing which address to select in this case, I cannot support this. 2) The scopes of source and destination addresses must match. > See previous communications on referrals (among others) for descriptions of > these issues. Referral is a second order problem. The current rules don't even satisfactorily solve the first order problem of connectivity between v4LL compliant nodes and non-v4LL compliant nodes, as shown by LL19. If rule 1) is required, the referral problem shouldn't even come up. Expecting v4LL-only nodes to function correctly in a routed network is plainly not realistic. Specifying rules that *sometimes* make it work just sends the wrong message. MikaL From owner-zeroconf@merit.edu Mon Feb 10 15:27:47 2003 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 PAA24221 for ; Mon, 10 Feb 2003 15:27:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D2A2A912D7; Mon, 10 Feb 2003 15:30:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E7BAF912EC; Mon, 10 Feb 2003 15:30:40 -0500 (EST) 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 1E05A912EE for ; Mon, 10 Feb 2003 15:29:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 063AA5DDFA; Mon, 10 Feb 2003 15:29:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id E0BFD5DD9E for ; Mon, 10 Feb 2003 15:29:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id ADDCC13FF1; Mon, 10 Feb 2003 15:29:27 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 26141-06; Mon, 10 Feb 2003 15:29:27 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 151B413FC0; Mon, 10 Feb 2003 15:29:27 -0500 (EST) Date: Mon, 10 Feb 2003 15:29:26 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, aboba@internaut.com, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: [Issue 19] Use v4LL source address for non-V4LL destination Message-Id: <20030210152926.6601a177.moore@cs.utk.edu> In-Reply-To: <1044904531.29383.30.camel@devil> References: <12309.1044867795@munnari.OZ.AU> <20030210093933.50d919b1.moore@cs.utk.edu> <1044904531.29383.30.camel@devil> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 8a5b16b3d1fbb1de3cf8fff4eb775c5bc5b916a6 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 10 Feb 2003 21:15:32 +0200 Mika Liljeberg wrote: > On Mon, 2003-02-10 at 16:39, Keith Moore wrote: > > as far as I can tell it would be a good idea to recommend that v4 > > hosts arp for LL addresses even if they don't have code to configure > > LL addresses. That would allow them to communicate with hosts that, > > for whatever reason, don't have a routable address. however I want > > to think more about the multiple interface case before I'm confident > > of that. and I wonder how many platforms would "partially" implement > > LL rather than doing either all or nothing. > > If you put this in the specification you're sending people a message > that it is standard operating procedure to have v4LL-only nodes as > part of routed networks and configure servers to listen at v4LL > addresses. I don't think so, because for a variety of reasons other than v4-only hosts v4LL and routable addresses will co-exist on the same network. but this probably does need explaining somewhere. > It would be much better to just restrict v4LL addresses for > communication with other nodes that have v4LL addresses. Nodes on > routed networks should use routable addresses, always. it won't happen unless you can figure out how to instantly reconfigure everything when the DHCP server comes back up. Keith From owner-zeroconf@merit.edu Mon Feb 10 15:37:57 2003 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 PAA24658 for ; Mon, 10 Feb 2003 15:37:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 642BA912E2; Mon, 10 Feb 2003 15:40:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C41F0912E0; Mon, 10 Feb 2003 15:40:33 -0500 (EST) 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 5D208912B7 for ; Mon, 10 Feb 2003 15:40:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 26A625DE7D; Mon, 10 Feb 2003 15:40:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id F1C705DE3D for ; Mon, 10 Feb 2003 15:40:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id BB6D513FC0; Mon, 10 Feb 2003 15:40:27 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 27776-06; Mon, 10 Feb 2003 15:40:26 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id AB9F713FF1; Mon, 10 Feb 2003 15:40:26 -0500 (EST) Date: Mon, 10 Feb 2003 15:40:26 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL19 Message-Id: <20030210154026.774021d4.moore@cs.utk.edu> In-Reply-To: <1044908026.29380.76.camel@devil> References: <028601c2d123$ab78dac0$131010ac@aldebaran> <1044908026.29380.76.camel@devil> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 2b326a8d3d2339a21ca9ed7330127923d2a2dcbb Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > 2) The scopes of source and destination addresses must match. No. There's no reason for it, and it just serves to hamper interoperability. From owner-zeroconf@merit.edu Mon Feb 10 15:43:56 2003 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 PAA24830 for ; Mon, 10 Feb 2003 15:43:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 97B62912B5; Mon, 10 Feb 2003 15:46:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71C0A91216; Mon, 10 Feb 2003 15:43:50 -0500 (EST) 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 4254E912A3 for ; Mon, 10 Feb 2003 15:43:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F9EA5DDFA; Mon, 10 Feb 2003 15:43:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 0A3CC5DE7D for ; Mon, 10 Feb 2003 15:43:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id B872213FF1; Mon, 10 Feb 2003 15:43:44 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 28097-04; Mon, 10 Feb 2003 15:43:44 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 213F413FC0; Mon, 10 Feb 2003 15:43:44 -0500 (EST) Date: Mon, 10 Feb 2003 15:43:44 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Proposed text for LL2 Message-Id: <20030210154344.68ff5a54.moore@cs.utk.edu> In-Reply-To: <02e901c2d12c$b531c820$131010ac@aldebaran> References: <200302101245.h1ACjXr21706@cichlid.adsl.duke.edu> <024e01c2d11e$e0ea9810$131010ac@aldebaran> <20030210113301.57090498.moore@cs.utk.edu> <027f01c2d123$3f4ebae0$131010ac@aldebaran> <20030210124601.5c22d134.moore@cs.utk.edu> <02e901c2d12c$b531c820$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: ab305dcf19ada799eb4832ef99f73ebaea5d32fa Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > media sense helps. > > > > and a host really ought to be able to ask "is my lease still valid > > here" without having to risk losing the lease if it's on the same > > network as before. however, I doubt we can fix those problems in > > this WG. > > This is part of transition from configured to unconfigured which is in > the charter. I don't think it's in our charter to change DHCP, which is what is needed. And I don't think it's a good idea to make fixing this problem critical path for the v4LL document. and actually the issue is independent of v4LL, it exists even when none of the hosts on a network use v4LL. Keith From owner-zeroconf@merit.edu Mon Feb 10 15:51:08 2003 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 PAA25210 for ; Mon, 10 Feb 2003 15:51:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7517391216; Mon, 10 Feb 2003 15:54:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48BAA91260; Mon, 10 Feb 2003 15:54:35 -0500 (EST) 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 E38C991216 for ; Mon, 10 Feb 2003 15:54:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id D1B485DE51; Mon, 10 Feb 2003 15:54:33 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 483565DDCC for ; Mon, 10 Feb 2003 15:54:32 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1AKrsaj031261; Mon, 10 Feb 2003 22:54:14 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1AKqREB031255; Mon, 10 Feb 2003 22:52:27 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [Issue 2] Explicit Additional Mechanism to disable v4LL From: Mika Liljeberg To: Bernard Aboba Cc: zeroconf@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044910326.31088.8.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 10 Feb 2003 22:52:06 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-02-10 at 03:40, Bernard Aboba wrote: > I agree that this issue should be rejected. > > If we go the route of preferring routable addresses to V4LL ones if both > are available, then the way to control use of v4LL is to make sure that > hosts get a routable address -- in other words, keep your DHCPv4 server > running. I agree with this statement and with the proposal that LL2 should be rejected. A manual configuration option to disable v4LL should suffice for high security environments. MikaL From owner-zeroconf@merit.edu Mon Feb 10 15:57:40 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25523 for ; Mon, 10 Feb 2003 15:57:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B2F9691272; Mon, 10 Feb 2003 15:58:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 740D191273; Mon, 10 Feb 2003 15:58:22 -0500 (EST) 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 57CC491272 for ; Mon, 10 Feb 2003 15:58:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4734E5DEAA; Mon, 10 Feb 2003 15:58:18 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 601FE5DE71 for ; Mon, 10 Feb 2003 15:58:17 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1AKvAaj031268; Mon, 10 Feb 2003 22:57:31 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1AKtYoP031267; Mon, 10 Feb 2003 22:55:34 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL19 From: Mika Liljeberg To: Keith Moore Cc: philip@engarts.com, zeroconf@merit.edu In-Reply-To: <20030210154026.774021d4.moore@cs.utk.edu> References: <028601c2d123$ab78dac0$131010ac@aldebaran> <1044908026.29380.76.camel@devil> <20030210154026.774021d4.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044910512.31088.11.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 10 Feb 2003 22:55:13 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-02-10 at 22:40, Keith Moore wrote: > > 2) The scopes of source and destination addresses must match. > > No. There's no reason for it, and it just serves to hamper > interoperability. I don't know about you but I prefer an immediate failure to a lengthy timeout. MikaL From owner-zeroconf@merit.edu Mon Feb 10 16:05:19 2003 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 QAA25824 for ; Mon, 10 Feb 2003 16:05:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 28A0291273; Mon, 10 Feb 2003 16:08:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E85C791274; Mon, 10 Feb 2003 16:08:45 -0500 (EST) 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 BFF0691273 for ; Mon, 10 Feb 2003 16:08:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id A78F45DE71; Mon, 10 Feb 2003 16:08:44 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 8A3DC5DED1 for ; Mon, 10 Feb 2003 16:08:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5194413FF6; Mon, 10 Feb 2003 16:08:44 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 31239-09; Mon, 10 Feb 2003 16:08:43 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id ABAFB13FF5; Mon, 10 Feb 2003 16:08:43 -0500 (EST) Date: Mon, 10 Feb 2003 16:08:43 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL19 Message-Id: <20030210160843.7866e3ac.moore@cs.utk.edu> In-Reply-To: <1044910512.31088.11.camel@devil> References: <028601c2d123$ab78dac0$131010ac@aldebaran> <1044908026.29380.76.camel@devil> <20030210154026.774021d4.moore@cs.utk.edu> <1044910512.31088.11.camel@devil> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: e2500975e029c7c8c0c05882dea7d7bac15ccfad Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > > 2) The scopes of source and destination addresses must match. > > > > No. There's no reason for it, and it just serves to hamper > > interoperability. > > I don't know about you but I prefer an immediate failure to a lengthy > timeout. You can't avoid the possibility of a timeout. If the host you're trying to reach isn't there you get a timeout no matter whether you use an LL source addr or a routable source addr. Keith From owner-zeroconf@merit.edu Mon Feb 10 16:23:32 2003 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 QAA26418 for ; Mon, 10 Feb 2003 16:23:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 90C8891274; Mon, 10 Feb 2003 16:27:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5649891278; Mon, 10 Feb 2003 16:27:07 -0500 (EST) 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 3E1A491274 for ; Mon, 10 Feb 2003 16:27:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2ED325DE71; Mon, 10 Feb 2003 16:27:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id E30A95DE51 for ; Mon, 10 Feb 2003 16:27:04 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1ALPvaj031403; Mon, 10 Feb 2003 23:26:17 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1ALOKbi031400; Mon, 10 Feb 2003 23:24:20 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL19 From: Mika Liljeberg To: Keith Moore Cc: philip@engarts.com, zeroconf@merit.edu In-Reply-To: <20030210160843.7866e3ac.moore@cs.utk.edu> References: <028601c2d123$ab78dac0$131010ac@aldebaran> <1044908026.29380.76.camel@devil> <20030210154026.774021d4.moore@cs.utk.edu> <1044910512.31088.11.camel@devil> <20030210160843.7866e3ac.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044912239.31088.34.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 10 Feb 2003 23:23:59 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-02-10 at 23:08, Keith Moore wrote: > > > > 2) The scopes of source and destination addresses must match. > > > > > > No. There's no reason for it, and it just serves to hamper > > > interoperability. > > > > I don't know about you but I prefer an immediate failure to a lengthy > > timeout. > > You can't avoid the possibility of a timeout. If the host you're trying > to reach isn't there you get a timeout no matter whether you use an LL > source addr or a routable source addr. Of course. However, I'm talking about the case where the destination *is* there. The normal case. MikaL From owner-zeroconf@merit.edu Mon Feb 10 16:30:07 2003 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 QAA26710 for ; Mon, 10 Feb 2003 16:30:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 641C09127C; Mon, 10 Feb 2003 16:33:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A2D591285; Mon, 10 Feb 2003 16:33:30 -0500 (EST) 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 7BD369127C for ; Mon, 10 Feb 2003 16:33:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 56D325DD9E; Mon, 10 Feb 2003 16:33:15 -0500 (EST) 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 2851E5DD90 for ; Mon, 10 Feb 2003 16:33:15 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 171E55990B; Mon, 10 Feb 2003 21:33:19 +0000 (GMT) Message-ID: <004801c2d14c$0445d400$131010ac@aldebaran> From: "Philip Nye" To: "Mika Liljeberg" Cc: "Zeroconf Working Group" References: <028601c2d123$ab78dac0$131010ac@aldebaran> <1044908026.29380.76.camel@devil> Subject: Re: LL19 Date: Mon, 10 Feb 2003 21:33:13 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mika, > > Unless we see workable suggestions for how to resolve the consequent issues > > of knowing which address to select in this case, I cannot support this. > > 2) The scopes of source and destination addresses must match. The current draft (v7) effectively mandates what you are proposing - that all compliant hosts maintain a LL address alongside any routable one they might have - but the WG seems to have moved away from that position. By itself your suggestion causes broken applications because choice of address is not just a low level choice of the IP stack. Applications use IP addresses to identify peers, they obtain those addresses by a wide variety of means and might or might not get hold of either the LL or the routable address, and worst of all they pass those identifiers to other peers whose scope may be different. Once at application level, most IPv4 applications are totally unaware of scoped addresses and there is no mechanism to establish scope even if they weren't. Solve these issues and your suggestions will carry more weight. See: http://www.merit.edu/mail.archives/zeroconf/2003-02/msg00051.html > Expecting v4LL-only nodes to function correctly in a routed network is > plainly not realistic. Specifying rules that *sometimes* make it work > just sends the wrong message. "function correctly" is rather vague. They will exist on the same networks and maximising interoperability is the best we can hope for. Making their use a transitional case seems to help. Philip From owner-zeroconf@merit.edu Mon Feb 10 16:32:08 2003 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 QAA26784 for ; Mon, 10 Feb 2003 16:32:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8441B91278; Mon, 10 Feb 2003 16:35:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5408D9127B; Mon, 10 Feb 2003 16:35:41 -0500 (EST) 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 2F8C191278 for ; Mon, 10 Feb 2003 16:35:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE40B5DEA5; Mon, 10 Feb 2003 16:35:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id D4BD45DDA2 for ; Mon, 10 Feb 2003 16:35:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id A21BD13FE8; Mon, 10 Feb 2003 16:35:39 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 02801-07; Mon, 10 Feb 2003 16:35:39 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 1180613FB3; Mon, 10 Feb 2003 16:35:39 -0500 (EST) Date: Mon, 10 Feb 2003 16:35:38 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL19 Message-Id: <20030210163538.0c501368.moore@cs.utk.edu> In-Reply-To: <1044912239.31088.34.camel@devil> References: <028601c2d123$ab78dac0$131010ac@aldebaran> <1044908026.29380.76.camel@devil> <20030210154026.774021d4.moore@cs.utk.edu> <1044910512.31088.11.camel@devil> <20030210160843.7866e3ac.moore@cs.utk.edu> <1044912239.31088.34.camel@devil> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 11ce707d1af5351a6f174510566e1ec100780eb4 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > You can't avoid the possibility of a timeout. If the host you're > > trying to reach isn't there you get a timeout no matter whether you > > use an LL source addr or a routable source addr. > > Of course. However, I'm talking about the case where the destination > *is* there. The normal case. why would this result in a timeout? From owner-zeroconf@merit.edu Mon Feb 10 16:43:04 2003 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 QAA27148 for ; Mon, 10 Feb 2003 16:43:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 289519127B; Mon, 10 Feb 2003 16:46:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A138491281; Mon, 10 Feb 2003 16:46:29 -0500 (EST) 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 863369127B for ; Mon, 10 Feb 2003 16:46:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id E681F5DDA2; Mon, 10 Feb 2003 16:45:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 5259E5DD9E for ; Mon, 10 Feb 2003 16:45:45 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1ALhgaj031498; Mon, 10 Feb 2003 23:44:03 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1ALg6I6031496; Mon, 10 Feb 2003 23:42:06 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL19 From: Mika Liljeberg To: Keith Moore Cc: philip@engarts.com, zeroconf@merit.edu In-Reply-To: <20030210163538.0c501368.moore@cs.utk.edu> References: <028601c2d123$ab78dac0$131010ac@aldebaran> <1044908026.29380.76.camel@devil> <20030210154026.774021d4.moore@cs.utk.edu> <1044910512.31088.11.camel@devil> <20030210160843.7866e3ac.moore@cs.utk.edu> <1044912239.31088.34.camel@devil> <20030210163538.0c501368.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044913305.31088.56.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 10 Feb 2003 23:41:46 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-02-10 at 23:35, Keith Moore wrote: > > > You can't avoid the possibility of a timeout. If the host you're > > > trying to reach isn't there you get a timeout no matter whether you > > > use an LL source addr or a routable source addr. > > > > Of course. However, I'm talking about the case where the destination > > *is* there. The normal case. > > why would this result in a timeout? Because a non-v4LL compliant node may not be able to respond. LL19 problem description. MikaL From owner-zeroconf@merit.edu Mon Feb 10 17:00:37 2003 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 RAA27660 for ; Mon, 10 Feb 2003 17:00:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DC87E91281; Mon, 10 Feb 2003 17:04:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0223F91282; Mon, 10 Feb 2003 17:04:01 -0500 (EST) 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 DA1ED91281 for ; Mon, 10 Feb 2003 17:04:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id BF4605DE71; Mon, 10 Feb 2003 17:04:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 040345DE51 for ; Mon, 10 Feb 2003 17:04:00 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1AM3Oaj031602; Tue, 11 Feb 2003 00:03:45 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1AM1v4c031592; Tue, 11 Feb 2003 00:01:57 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL19 From: Mika Liljeberg To: Philip Nye Cc: Zeroconf Working Group In-Reply-To: <004801c2d14c$0445d400$131010ac@aldebaran> References: <028601c2d123$ab78dac0$131010ac@aldebaran> <1044908026.29380.76.camel@devil> <004801c2d14c$0445d400$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044914496.31092.95.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 11 Feb 2003 00:01:37 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-02-10 at 23:33, Philip Nye wrote: > Mika, > > > > Unless we see workable suggestions for how to resolve the consequent > issues > > > of knowing which address to select in this case, I cannot support this. > > > > 2) The scopes of source and destination addresses must match. > > The current draft (v7) effectively mandates what you are proposing - that > all compliant hosts maintain a LL address alongside any routable one they > might have I like that. > - but the WG seems to have moved away from that position. That worries me. > By itself your suggestion causes broken applications because choice of > address is not just a low level choice of the IP stack. Applications use IP > addresses to identify peers, they obtain those addresses by a wide variety > of means and might or might not get hold of either the LL or the routable > address, and worst of all they pass those identifiers to other peers whose > scope may be different. No matter how many times an address is passed between peers via this variety of means, the origin of the address ultimately boils down to one of two cases: 1) directly from the user (shoot in the foot case) 2) from a name resolution process (solvable: return routables first) > Once at application level, most IPv4 applications are totally unaware of > scoped addresses and there is no mechanism to establish scope even if they > weren't. > > Solve these issues and your suggestions will carry more weight. See: > http://www.merit.edu/mail.archives/zeroconf/2003-02/msg00051.html > > > Expecting v4LL-only nodes to function correctly in a routed network is > > plainly not realistic. Specifying rules that *sometimes* make it work > > just sends the wrong message. > > "function correctly" is rather vague. To be less vague, I believe failures are inevitable. That being the case, I would like the failures to be immediate and obvious, rather than unpredictable and usually after a lengthy timeout. MikaL From owner-zeroconf@merit.edu Mon Feb 10 17:59:36 2003 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 RAA29397 for ; Mon, 10 Feb 2003 17:59:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6B1E091293; Mon, 10 Feb 2003 18:02:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8857E91291; Mon, 10 Feb 2003 18:02:02 -0500 (EST) 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 E29609128C for ; Mon, 10 Feb 2003 18:02:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id BF9155DF62; Mon, 10 Feb 2003 18:02:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id E9F3F5DD90 for ; Mon, 10 Feb 2003 18:01:58 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1AN1jaj031850; Tue, 11 Feb 2003 01:02:05 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1AN0Ouv031843; Tue, 11 Feb 2003 01:00:24 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Robert Elz Cc: zeroconf@merit.edu In-Reply-To: <12433.1044872260@munnari.OZ.AU> References: <1044810580.21186.302.camel@devil> <1044803577.21383.233.camel@devil> <1044793681.21186.107.camel@devil> <1044787452.11519.93.camel@devil> <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> <3689.1044783115@munnari.OZ.AU> <4300.1044789975@munnari.OZ.AU> <4798.1044798098@munnari.OZ.AU> <5583.1044805928@munnari.OZ.AU> <12433.1044872260@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044918002.31088.163.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 11 Feb 2003 01:00:03 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-02-10 at 12:17, Robert Elz wrote: > | Could you give me some examples of these v4LL nodes that participate in > | a routed network but are unable to get a routable address? > > Huh? If you take a node to my network (LL aware or not) and attempt > get get a routable address, you'll fail. DHCP (which works there) is > set to only assign addresses to known systems. The DHCP server there > won't send a 2563 reply (by default anyway - I'd typically only do that > to specific clients that I know about, not just to anything unknown) > and so you would get to assign yourself a LL address. > So, now your v4LL node would be on a routed network, and unable to get > a routable address. You would deny me a routable address but you would welcome me to your servers? Frankly, I would not expect to be able to access anything on your network having only my v4LL address. > The prohibition wouldn't fix the issue, as you still have to deal with > nodes that have both LL and routable addresses (which your proposal would > require to exist) which will then still expose both addresses to > applications. That could be mitigated by, e.g., having the host resolver return routable addresses first. > | The obvious solution (even for a user) is to get a routable > | address to all nodes on the link. > > If you have one node with only a LL address, then perhaps. But if > you have many nodes with LL addresses on some ad-hoc network, and > one legacy system that doesn't understand LL?? Well, there you have me. Admittedly, a nerdy user might be tempted to do the dirty deed and configure a random LL address on the legacy node. On the other hand, a nerdy user would not lug around a legacy node. :) A non-technical user would just be out-of-luck, of course. > | 1) The printer has no need to initiate connections to other nodes. > > How does it report when it needs its paper tray or toner refilled ? Ok, so it talks to other rendezvous nodes. > | 2) Nodes that support rendezvous can contact to the printer directly. > > Sure. > > | 3) Nodes that do not support rendezvous cannot print directly to the > | printer even if they have the manually configured 169.254/16 on-link > | route, because they have no way of finding the IP address of the > | printer. > > "Hey Mika, what's the IP address of that printer you're using?" This would not be a common use case. > | 4) the obvious solution to 3) is to put up a print server that serves > | the non-rendezvous nodes. > > On a managed network, perhaps. For three friends and one of those > portable network printers in an airport? Really? One of them with a legacy node and the knowledge to configure routes? Again, not a very common use case. > I meant, after (s/he/the/) that if a system has a routable address, it > needs nothing more, if it is LL aware, or configured, it can communicate > with LL addresses - it doesn't need to have its own LL address, and is > simpler not to. It's simple enough to have both types of addresses at the same time. > Oh, now I see what you were saying, but it really doesn't work that way. > To make that happen (even assuming that it was a desirable outcome) would > require even more complexity than is now required (the server would have > to look at each individual address, and determine whether or not that one > was one that might be used, or probably wouldn't ever be). Not really. The admin would just have to put the address into the config file for bind to bind to (pun intented). > Once the edtorial issue is cleared up (one way or the other) then > there might be some technical issue as to whether what it says is > correct, but it is pointless debating that when everyone believes > it is correct, because they read it their own way. > > Do you want to send in an issue for that one, or should I? Be my guest. > Yes, I know, that's fine. The question is more whether you actually > want to, given no particularly good reason to do so. It's a simple clean design with no awkward transitions between v4LL and routable modes or any interdependencies between address configuration mechanisms. It is also closer to IPv6 semantics, which is a good thing too. > | > LL doesn't need to to be much different than that. You (the user, or > | > the device manufacturer) pick which address assignment method to use (or > | > which sequence to try until one succeeds) and then just let them run. > | > | s/method/methods/ and I would agree. > > Oh, good, because I don't mind that change. > That is, I don't object to a node being able to be configured explicitly > to have multiple addresses (including where one, or more, of them are > link local addresses), if that's what someone wants to do with it. Good. > And, provided that I have a way to explicitly configure it to have only > one address, and that having only one won't prevent me from communicating > with anyone else (that the particular address, or address type, I choose > is able to reach). I guess we still disagree on a few minor details here. :) > All that's left is to decide what the default should be when there is no > explicit configuration, and for that, I prefer the simplicity of just one > address, of the broadest possible scope available. That's fine, although the default configuration is really up to the manufacturer. Depends on the type of the device. MikaL From owner-zeroconf@merit.edu Mon Feb 10 18:45:12 2003 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 SAA00834 for ; Mon, 10 Feb 2003 18:45:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 780D391288; Mon, 10 Feb 2003 18:48:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4BB8291295; Mon, 10 Feb 2003 18:48:39 -0500 (EST) 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 41CB491288 for ; Mon, 10 Feb 2003 18:48:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2ABC35DF17; Mon, 10 Feb 2003 18:48:38 -0500 (EST) 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 AB7315DE62 for ; Mon, 10 Feb 2003 18:48:37 -0500 (EST) 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 SAA26699 for ; Mon, 10 Feb 2003 18:48:30 -0500 (EST) 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 SAA05951 for ; Mon, 10 Feb 2003 18:48:29 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id SAA15496 for ; Mon, 10 Feb 2003 18:48:28 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 10 Feb 2003 18:48:27 -0500 Subject: Re: [Issue 2] Explicit Additional Mechanism to disable v4LL From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <1044910326.31088.8.camel@devil> 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 02/10/2003 15:52, "Mika Liljeberg" wrote: > I agree with this statement and with the proposal that LL2 should be > rejected. > > A manual configuration option to disable v4LL should suffice for high > security environments. That's what LL2 is asking for...a manual mechanism to disable v4LL john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Feb 10 19:30:32 2003 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 TAA02261 for ; Mon, 10 Feb 2003 19:30:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BE72A91296; Mon, 10 Feb 2003 19:34:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8FE5F91298; Mon, 10 Feb 2003 19:34:06 -0500 (EST) 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 87FC791296 for ; Mon, 10 Feb 2003 19:34:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7247A5DF82; Mon, 10 Feb 2003 19:34:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by segue.merit.edu (Postfix) with ESMTP id 515FE5DF79 for ; Mon, 10 Feb 2003 19:34:05 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18iOMp-0003sX-00; Mon, 10 Feb 2003 16:33:43 -0800 Date: Mon, 10 Feb 2003 19:31:25 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL19 Message-Id: <20030210193125.157027dc.moore@cs.utk.edu> In-Reply-To: <1044914496.31092.95.camel@devil> References: <028601c2d123$ab78dac0$131010ac@aldebaran> <1044908026.29380.76.camel@devil> <004801c2d14c$0445d400$131010ac@aldebaran> <1044914496.31092.95.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > No matter how many times an address is passed between peers via this > variety of means, the origin of the address ultimately boils down to one > of two cases: > 1) directly from the user (shoot in the foot case) > 2) from a name resolution process (solvable: return routables first) you're simply wrong about this. for instance, apps can use the source address from a previous transaction. or they can do referrals which don't involve name resolution at all. Keith From owner-zeroconf@merit.edu Mon Feb 10 22:04:19 2003 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 WAA06342 for ; Mon, 10 Feb 2003 22:04:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7091891299; Mon, 10 Feb 2003 22:07:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C2069129A; Mon, 10 Feb 2003 22:07:54 -0500 (EST) 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 284D191299 for ; Mon, 10 Feb 2003 22:07:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0AF3E5DF7A; Mon, 10 Feb 2003 22:07:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8BDD35DDB8 for ; Mon, 10 Feb 2003 22:07:52 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1B1tW705506; Mon, 10 Feb 2003 17:55:33 -0800 Date: Mon, 10 Feb 2003 17:55:32 -0800 (PST) From: Bernard Aboba To: Keith Moore Cc: zeroconf@merit.edu Subject: Re: [Issue 10] Warnings in Applicability Statement In-Reply-To: <20030210125113.0a661043.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > I suggest instead: > > "Existing applications fundamentally assume addresses of > communicating peers are routable, relatively unchanging and unique. > These assumptions no longer hold with IPv4 link-local addresses, > especially those with a substantial number of hosts. On networks that > do not provide stable DHCP configurations the introduction of IPv4 > link-local addresses may further decrease address stability due to > hosts switching between LL addresses and DHCP-assigned addresses. Sounds good to me. From owner-zeroconf@merit.edu Tue Feb 11 00:07:03 2003 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 AAA08824 for ; Tue, 11 Feb 2003 00:07:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8C2439129C; Tue, 11 Feb 2003 00:10:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48DDE9129D; Tue, 11 Feb 2003 00:10:29 -0500 (EST) 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 95EC69129C for ; Tue, 11 Feb 2003 00:10:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 79D205DEA2; Tue, 11 Feb 2003 00:10:26 -0500 (EST) 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 E56005DE29 for ; Tue, 11 Feb 2003 00:10:25 -0500 (EST) 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 h1B5API07216 for ; Mon, 10 Feb 2003 21:10:25 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Feb 2003 21:10:23 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h1B5AOs11898; Mon, 10 Feb 2003 21:10:24 -0800 (PST) Message-Id: <200302110510.h1B5AOs11898@scv1.apple.com> Subject: *** Please Note: Subject line convention for discussions *** Date: Mon, 10 Feb 2003 21:10:26 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Erik Guttman" Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Erik Guttman previously posted the following procedure for discussions: >When discussing an issue, please put the issue number and title in the >subject line, for instance > > Subject: Re: [LL1] Preferred use of configured to v4 LL address > Subject: Text needed for [LL1]: Preferred use of configured to v4 LL > address > etc. > >For last calls on particular issues the subject line will look like: > > Subject: WG action - 1 week to discuss [LL1] > >And later > > Subject: WG action - [LL1] Accepted > >(or Rejected, etc.) I request that people adhere to the convention, specifically: The subject line should contain "LL", with no space between the "LL" and the number. If an email legitimately pertains to more than one issue, then the subject line can contain more than one "LL" tag. With the volume of traffic on the list (66 new messages over the weekend and 71 new messages so far today), it is very hard for everyone to keep track of what is being said. The ability to filter mail for "subject containing 'LL2'" (for example) provides an easy way to quickly see all the opinions being expressed on this issue. If people start adopting other conventions, like, "Issue 2", or "Topic 2" or just "[2]", etc., then the ability to sort and filter usefully based on subject line is diminished. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Feb 11 02:20:07 2003 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 CAA21961 for ; Tue, 11 Feb 2003 02:20:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E0A039129D; Tue, 11 Feb 2003 02:23:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91B2C912A0; Tue, 11 Feb 2003 02:23:42 -0500 (EST) 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 79A6B9129D for ; Tue, 11 Feb 2003 02:23:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6807C5DF30; Tue, 11 Feb 2003 02:23:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 69CB55DF18 for ; Tue, 11 Feb 2003 02:23:40 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1B7OCaj001499; Tue, 11 Feb 2003 09:24:12 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1B7O9ma001498; Tue, 11 Feb 2003 09:24:09 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL19 From: Mika Liljeberg To: Keith Moore Cc: philip@engarts.com, zeroconf@merit.edu In-Reply-To: <20030210193125.157027dc.moore@cs.utk.edu> References: <028601c2d123$ab78dac0$131010ac@aldebaran> <1044908026.29380.76.camel@devil> <004801c2d14c$0445d400$131010ac@aldebaran> <1044914496.31092.95.camel@devil> <20030210193125.157027dc.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044948248.1377.15.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 11 Feb 2003 09:24:09 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2003-02-11 at 02:31, Keith Moore wrote: > > No matter how many times an address is passed between peers via this > > variety of means, the origin of the address ultimately boils down to one > > of two cases: > > 1) directly from the user (shoot in the foot case) > > 2) from a name resolution process (solvable: return routables first) > > you're simply wrong about this. I don't think so. > for instance, apps can use the source address from a previous transaction. You forget the rule I'm proposing: source and destination address scopes must match. Thus, any result from source address selection is LL only if the destination was LL as well. Now ask yourself where that destination address originally came from. > or they can do referrals which don't involve name resolution at all. Referrals just pass addresses around. The question is, where do these address originate? A v4LL address can only be introduced to the application session if a) v4LL-only nodes are allowed to participate. This is a concious risk and an occasion failure is to be expected. An immediate one (no route) is always preferrable to a timeout. b) Manually configured LL address. That's a human error. MikaL From owner-zeroconf@merit.edu Tue Feb 11 02:27:39 2003 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 CAA22098 for ; Tue, 11 Feb 2003 02:27:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6D582912A0; Tue, 11 Feb 2003 02:30:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 32B6B912A3; Tue, 11 Feb 2003 02:30:48 -0500 (EST) 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 1EBA7912A0 for ; Tue, 11 Feb 2003 02:30:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F5915DF30; Tue, 11 Feb 2003 02:30:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 170B25DEA2 for ; Tue, 11 Feb 2003 02:30:38 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1B7VFaj001532 for ; Tue, 11 Feb 2003 09:31:15 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1B7VECh001531 for zeroconf@merit.edu; Tue, 11 Feb 2003 09:31:14 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [Issue 2] Explicit Additional Mechanism to disable v4LL From: Mika Liljeberg To: Zeroconf In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044948673.1377.22.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 11 Feb 2003 09:31:14 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2003-02-11 at 01:48, John C. Welch wrote: > On 02/10/2003 15:52, "Mika Liljeberg" wrote: > > > I agree with this statement and with the proposal that LL2 should be > > rejected. > > > > A manual configuration option to disable v4LL should suffice for high > > security environments. > > That's what LL2 is asking for...a manual mechanism to disable v4LL It's asking for RFC2653 or some derivative. I'd be willing to agree to manual configuration locally on the node, but not with the current LL2 proposal. MikaL From owner-zeroconf@merit.edu Tue Feb 11 03:51:39 2003 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 DAA23853 for ; Tue, 11 Feb 2003 03:51:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 365F091212; Tue, 11 Feb 2003 03:55:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 042C991224; Tue, 11 Feb 2003 03:55:12 -0500 (EST) 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 0A40C91212 for ; Tue, 11 Feb 2003 03:55:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id E20595DE35; Tue, 11 Feb 2003 03:55:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 23E925DDAF for ; Tue, 11 Feb 2003 03:55:10 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1B8sUn22369; Tue, 11 Feb 2003 15:54:30 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1B8sCb19891; Tue, 11 Feb 2003 15:54:14 +0700 (ICT) From: Robert Elz To: Keith Moore Cc: Erik Guttman , mika.liljeberg@welho.com, zeroconf@merit.edu Subject: Re: Proposed text for LL2 In-Reply-To: <20030210122608.50d3d478.moore@cs.utk.edu> References: <20030210122608.50d3d478.moore@cs.utk.edu> <1044796483.21383.156.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Feb 2003 15:54:12 +0700 Message-ID: <19889.1044953652@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 10 Feb 2003 12:26:08 -0500 From: Keith Moore Message-ID: <20030210122608.50d3d478.moore@cs.utk.edu> | Any host that attempts to automatically configure an address MUST (or | at least SHOULD) initially, and at intervals thereafter, attempt to get | a routable address/netmask and a default route from DHCP and if such | are obtained, use these in preference to v4LL configuration. Hmm - I agree with this (except I wouldn't require DHCP, just "a mechanism" which we all know, for all practical purposes is going to be DHCP these days, but RARP was used once, etc...) | So I'm strongly opposed to the text as suggested. Since I wrote the text that is the subject of this message, and since I agree with you (mostly) what about the text do you strongly disagree with? kre (Of course, it would be easier if the web page were updated with the suggested text...) From owner-zeroconf@merit.edu Tue Feb 11 04:03:40 2003 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 EAA24150 for ; Tue, 11 Feb 2003 04:03:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B778E91228; Tue, 11 Feb 2003 04:04:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65EB791227; Tue, 11 Feb 2003 04:04:44 -0500 (EST) 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 6102091228 for ; Tue, 11 Feb 2003 04:04:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 48E2A5DDE9; Tue, 11 Feb 2003 04:04:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id B00655DDAF for ; Tue, 11 Feb 2003 04:04:35 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1B93en29526; Tue, 11 Feb 2003 16:03:40 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1B93Mb19912; Tue, 11 Feb 2003 16:03:22 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs [LL19] In-Reply-To: <1044918002.31088.163.camel@devil> References: <1044918002.31088.163.camel@devil> <1044810580.21186.302.camel@devil> <1044803577.21383.233.camel@devil> <1044793681.21186.107.camel@devil> <1044787452.11519.93.camel@devil> <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> <3689.1044783115@munnari.OZ.AU> <4300.1044789975@munnari.OZ.AU> <4798.1044798098@munnari.OZ.AU> <5583.1044805928@munnari.OZ.AU> <12433.1044872260@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Feb 2003 16:03:22 +0700 Message-ID: <19910.1044954202@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 11 Feb 2003 01:00:03 +0200 From: Mika Liljeberg Message-ID: <1044918002.31088.163.camel@devil> | You would deny me a routable address but you would welcome me to your | servers? Of course, or those of them that allow you to connect. At least that's an option that I want available (otherwise when I'd have to either give you a routable address, and simultaneously install filters to stop you getting off the net, or have a 1918 type net as secondary addresses on the net and give you addresses on that one, and then arrange to make sure communications work - which is just the same problem as making connections to the LL address work. | > "Hey Mika, what's the IP address of that printer you're using?" | This would not be a common use case. I disagree. The prime motivator for LL addresses is for ad-hoc networks (the doc even says so). Those are networks that form when a few people get together and make a net connecting whatever they happen to have with them. They're often (even usually) in close proximity to each other, and easily able to exchange verbal information. | One of them with a legacy node and the knowledge to configure routes? | Again, not a very common use case. Well, one of them might be me, I use NetBSD, which currently has no v4LL support, and to the best of my knowledge, no-one is in any kind of hurry to bother adding it... (maybe it will never appear there). How common it is isn't really relevant, it needs to be able to work for when it is required. kre From owner-zeroconf@merit.edu Tue Feb 11 04:03:56 2003 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 EAA24168 for ; Tue, 11 Feb 2003 04:03:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C9AC991227; Tue, 11 Feb 2003 04:06:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9527091246; Tue, 11 Feb 2003 04:06:30 -0500 (EST) 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 3EFE891227 for ; Tue, 11 Feb 2003 04:06:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D7645DDE9; Tue, 11 Feb 2003 04:06:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 995625DDAF for ; Tue, 11 Feb 2003 04:06:21 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1B95Tn01058; Tue, 11 Feb 2003 16:05:29 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1B95Ab19923; Tue, 11 Feb 2003 16:05:10 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: Zeroconf Subject: Re: [Issue 2 - LL2] Explicit Additional Mechanism to disable v4LL In-Reply-To: <1044948673.1377.22.camel@devil> References: <1044948673.1377.22.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Feb 2003 16:05:10 +0700 Message-ID: <19921.1044954310@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 11 Feb 2003 09:31:14 +0200 From: Mika Liljeberg Message-ID: <1044948673.1377.22.camel@devil> | I'd be willing to agree to manual configuration locally on the node, but | not with the current LL2 proposal. This only works if you're also willing to mandate some kind of stable storage in every node supporting v4LL addresses. I don't think that's reasonable. kre From owner-zeroconf@merit.edu Tue Feb 11 04:25:18 2003 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 EAA24616 for ; Tue, 11 Feb 2003 04:25:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F074191234; Tue, 11 Feb 2003 04:28:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE4A291235; Tue, 11 Feb 2003 04:28:51 -0500 (EST) 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 BC39D91234 for ; Tue, 11 Feb 2003 04:28:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id A40195DF3A; Tue, 11 Feb 2003 04:28:50 -0500 (EST) 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 754F25DF30 for ; Tue, 11 Feb 2003 04:28:50 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 6CC2E5992A for ; Tue, 11 Feb 2003 09:28:51 +0000 (GMT) Message-ID: <000701c2d1af$fbe228e0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <028601c2d123$ab78dac0$131010ac@aldebaran> <1044908026.29380.76.camel@devil> <004801c2d14c$0445d400$131010ac@aldebaran> <1044914496.31092.95.camel@devil> Subject: Re: LL19 Date: Tue, 11 Feb 2003 09:28:48 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > No matter how many times an address is passed between peers via this > variety of means, the origin of the address ultimately boils down to one > of two cases: > 1) directly from the user (shoot in the foot case) > 2) from a name resolution process (solvable: return routables first) Or from SLP, or from an HTML link, or from SSDP, or from NetBios, or from CUPS or from a hundred and one other discovery protocols. You might class all these as "name resolution processes" but how do you ensure that they all "return routables first"? Add that to the fact that routable and LL addresses are not acquired simultaneously but exist at different (overlapping) times, and that most of these discovery methods hang on to identifiers for some period and do not expect to reconfirm addresses before they use them. What we haven't seen here is a hard proposal for how "return routables first" really works to resolve these issues without requiring rewrites of large numbers of applications or intermediate protocols such as those above. I would love to see such a proposal since it would of great benefit to IPv4LL whether or not we accept LL19. Philip From owner-zeroconf@merit.edu Tue Feb 11 05:07:35 2003 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 FAA25569 for ; Tue, 11 Feb 2003 05:07:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 37BDD91207; Tue, 11 Feb 2003 05:11:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 018CA91235; Tue, 11 Feb 2003 05:11:09 -0500 (EST) 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 099A991207 for ; Tue, 11 Feb 2003 05:11:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id E6AA25DDBB; Tue, 11 Feb 2003 05:11:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by segue.merit.edu (Postfix) with ESMTP id 1E2CB5DDAF for ; Tue, 11 Feb 2003 05:11:08 -0500 (EST) Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) with ESMTP id h1BAB6iC019660 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 11 Feb 2003 12:11:06 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) id h1BAB6FJ019656; Tue, 11 Feb 2003 12:11:06 +0200 Date: Tue, 11 Feb 2003 12:11:06 +0200 Message-Id: <200302111011.h1BAB6FJ019656@burp.tkv.asdf.org> From: Markku Savela To: zeroconf@merit.edu In-reply-to: <200302101313.h1ADD3n21793@cichlid.adsl.duke.edu> (message from Thomas Narten on Mon, 10 Feb 2003 08:13:03 -0500) Subject: [LL19 & LL1] Source Address selection References: <200302101313.h1ADD3n21793@cichlid.adsl.duke.edu> Sender: owner-zeroconf@merit.edu Precedence: bulk [changed the topic on this reply] In short: if LL19 is rejected, then LL1 is not acceptable either. > From: Thomas Narten > > Because we don't really have general address selection rules for > IPv4, and we probably don't want to go there. I'm looking this issue from already implemented IPv6/IPv4 stack, which does have address selection code (e.g. select LL source for LL destination, even if it also has global IPv4 addresses). To avoid "code bloat", IPv4 is handled as true subset of IPv6, exceptional handling IPv4 case is minimized. It is unacceptable that ZEROCONF RFC would make this suddenly "illegal". The "SHOULD NOT" in requested change of [L1] is too strong. From owner-zeroconf@merit.edu Tue Feb 11 05:16:59 2003 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 FAA25747 for ; Tue, 11 Feb 2003 05:16:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 310B491235; Tue, 11 Feb 2003 05:20:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 050ED91239; Tue, 11 Feb 2003 05:20:33 -0500 (EST) 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 06FAB91235 for ; Tue, 11 Feb 2003 05:20:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id D68A95DF42; Tue, 11 Feb 2003 05:20:32 -0500 (EST) 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 A7B815DF30 for ; Tue, 11 Feb 2003 05:20:32 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 6B43559952 for ; Tue, 11 Feb 2003 10:20:30 +0000 (GMT) Message-ID: <00e001c2d1b7$32f088c0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <200302101245.h1ACjXr21706@cichlid.adsl.duke.edu><024e01c2d11e$e0ea9810$131010ac@aldebaran><20030210113301.57090498.moore@cs.utk.edu><027f01c2d123$3f4ebae0$131010ac@aldebaran> <20030210124601.5c22d134.moore@cs.utk.edu> Subject: Re: Proposed text for LL2 Date: Tue, 11 Feb 2003 10:20:28 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Keith Moore" > > and a host really ought to be able to ask "is my lease still valid here" > without having to risk losing the lease if it's on the same network as > before... Transition from configured to Zero-config is even harder than the other way. But to meet the aims we should at least spell out a path. If that means outlining reasonable changes which would be required of DHCP then this is no bad thing even if they cannot be progressed here. So what of my suggestion that you simply ARP your configured routes? on the principle that if you cant reach a router than either you need new configuration or LL is going to be as good as it gets. We could build is a mechanism based on this - if you have configured routers but can't reach them then you can establish LL - but it might require periodic retries and all sorts of complexity. Philip From owner-zeroconf@merit.edu Tue Feb 11 05:25:46 2003 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 FAA25910 for ; Tue, 11 Feb 2003 05:25:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4B16291239; Tue, 11 Feb 2003 05:29:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10CD89123B; Tue, 11 Feb 2003 05:29:20 -0500 (EST) 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 16DC391239 for ; Tue, 11 Feb 2003 05:29:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id F284D5DDB8; Tue, 11 Feb 2003 05:29:19 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 21FE25DDAF for ; Tue, 11 Feb 2003 05:29:18 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1BASgn07930; Tue, 11 Feb 2003 17:28:43 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1BASMb20378; Tue, 11 Feb 2003 17:28:23 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: "Erik Guttman" , zeroconf@merit.edu Subject: Re: *** Please Note: Subject line convention for discussions *** In-Reply-To: <200302110510.h1B5AOs11898@scv1.apple.com> References: <200302110510.h1B5AOs11898@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Feb 2003 17:28:22 +0700 Message-ID: <20376.1044959302@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 10 Feb 2003 21:10:26 -0800 From: Stuart Cheshire Message-ID: <200302110510.h1B5AOs11898@scv1.apple.com> | I request that people adhere to the convention, specifically: [With no hat of any kind to put on, so take this for what it is worth...] I'd also like to ask that people explicitly say what their position is when replying, and not leave it to readers to guess... I believe that there are three reasonable responses to each of these issues... 1. The proposal is OK as it stands. (or "accept") 2. There is no issue that needs resolving here. (or "reject") 3. There is an issue, but the proposed solution isn't acceptable. In the third case, an alternate proposal should be made, or someone else's earlier alternate proposal should be agreed with. Ideally an alternate proposal should give text that would be included, and indicate where it would go, but as a minimum it should be clear what is being suggested be changed. (Sometimes an alternate proposal may be, or may become, a new issue, but requiring that seems like too much overhead to me - in some cases the "alternate proposal" might just mean editorial changes). kre From owner-zeroconf@merit.edu Tue Feb 11 08:19:31 2003 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 IAA03768 for ; Tue, 11 Feb 2003 08:19:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BB50691236; Tue, 11 Feb 2003 08:23:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D2D291241; Tue, 11 Feb 2003 08:23:06 -0500 (EST) 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 5A71F91236 for ; Tue, 11 Feb 2003 08:23:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 33F4F5DDAF; Tue, 11 Feb 2003 08:23:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by segue.merit.edu (Postfix) with ESMTP id 13A815DD8F for ; Tue, 11 Feb 2003 08:23:05 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18iaNI-0004bO-00; Tue, 11 Feb 2003 05:23:00 -0800 Date: Tue, 11 Feb 2003 08:20:40 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL19 Message-Id: <20030211082040.747f9941.moore@cs.utk.edu> In-Reply-To: <1044948248.1377.15.camel@devil> References: <028601c2d123$ab78dac0$131010ac@aldebaran> <1044908026.29380.76.camel@devil> <004801c2d14c$0445d400$131010ac@aldebaran> <1044914496.31092.95.camel@devil> <20030210193125.157027dc.moore@cs.utk.edu> <1044948248.1377.15.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 11 Feb 2003 09:24:09 +0200 Mika Liljeberg wrote: > On Tue, 2003-02-11 at 02:31, Keith Moore wrote: > > > No matter how many times an address is passed between peers via this > > > variety of means, the origin of the address ultimately boils down to one > > > of two cases: > > > 1) directly from the user (shoot in the foot case) > > > 2) from a name resolution process (solvable: return routables first) > > > > you're simply wrong about this. > > I don't think so. > > > for instance, apps can use the source address from a previous transaction. > > You forget the rule I'm proposing: source and destination address scopes > must match. nope, the app can use that source address in a referral to another host. the other host has no idea whether its scope matches that address. > Referrals just pass addresses around. The question is, where do these > address originate? from various places. > A v4LL address can only be introduced to the application session if > > a) v4LL-only nodes are allowed to participate. This is a concious risk > and an occasion failure is to be expected. An immediate one (no route) > is always preferrable to a timeout. > > b) Manually configured LL address. That's a human error. v4LL-only nodes should not be permitted. however there will be nodes that for the time being only have v4LL addresses talking to nodes that have routable addresses - perhaps because the DHCP server was down for a time, perhaps because the nodes with routable addresses had them manually configured (correctly), perhaps because some hosts on the network have multiple interfaces. From owner-zeroconf@merit.edu Tue Feb 11 08:48:06 2003 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 IAA04717 for ; Tue, 11 Feb 2003 08:48:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D117291243; Tue, 11 Feb 2003 08:51:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9CAFA91244; Tue, 11 Feb 2003 08:51:43 -0500 (EST) 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 8C9F691243 for ; Tue, 11 Feb 2003 08:51:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 784A25DF6E; Tue, 11 Feb 2003 08:51:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by segue.merit.edu (Postfix) with ESMTP id 573535DDF8 for ; Tue, 11 Feb 2003 08:51:42 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18iaoD-0006Al-00; Tue, 11 Feb 2003 05:50:50 -0800 Date: Tue, 11 Feb 2003 08:48:29 -0500 From: Keith Moore To: Robert Elz Cc: moore@cs.utk.edu, mika.liljeberg@welho.com, zeroconf@merit.edu Subject: Re: [Issue 2 - LL2] Explicit Additional Mechanism to disable v4LL Message-Id: <20030211084829.4f3cf9d4.moore@cs.utk.edu> In-Reply-To: <19921.1044954310@munnari.OZ.AU> References: <1044948673.1377.22.camel@devil> <19921.1044954310@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > | I'd be willing to agree to manual configuration locally on the node, but > | not with the current LL2 proposal. > > This only works if you're also willing to mandate some kind of stable > storage in every node supporting v4LL addresses. I don't think that's > reasonable. nor do I. which is why I've tended to say that such a feature is highly desirable, maybe even a SHOULD, but not a MUST. From owner-zeroconf@merit.edu Tue Feb 11 08:50:27 2003 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 IAA04782 for ; Tue, 11 Feb 2003 08:50:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F3A8491244; Tue, 11 Feb 2003 08:54:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C348B91245; Tue, 11 Feb 2003 08:54:03 -0500 (EST) 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 AF30891244 for ; Tue, 11 Feb 2003 08:54:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 978475DF6E; Tue, 11 Feb 2003 08:54:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by segue.merit.edu (Postfix) with ESMTP id 76AEF5DDF8 for ; Tue, 11 Feb 2003 08:54:02 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18iarF-0001jE-00; Tue, 11 Feb 2003 05:53:57 -0800 Date: Tue, 11 Feb 2003 08:51:37 -0500 From: Keith Moore To: Robert Elz Cc: moore@cs.utk.edu, Erik.Guttman@Sun.COM, mika.liljeberg@welho.com, zeroconf@merit.edu Subject: Re: Proposed text for LL2 Message-Id: <20030211085137.2918d9c7.moore@cs.utk.edu> In-Reply-To: <19889.1044953652@munnari.OZ.AU> References: <20030210122608.50d3d478.moore@cs.utk.edu> <1044796483.21383.156.camel@devil> <19889.1044953652@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > | Any host that attempts to automatically configure an address MUST (or > | at least SHOULD) initially, and at intervals thereafter, attempt to get > | a routable address/netmask and a default route from DHCP and if such > | are obtained, use these in preference to v4LL configuration. > > Hmm - I agree with this (except I wouldn't require DHCP, just "a mechanism" > which we all know, for all practical purposes is going to be DHCP these > days, but RARP was used once, etc...) well, we need a uniform mechanism for all of these devices (else networks have to guess as to which mechanisms are necessary), and DHCP is the most likely candidate. OTOH, RARP would almost be good enough. From owner-zeroconf@merit.edu Tue Feb 11 09:00:47 2003 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 JAA05092 for ; Tue, 11 Feb 2003 09:00:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 29E9891246; Tue, 11 Feb 2003 09:04:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4BEB91248; Tue, 11 Feb 2003 09:03:40 -0500 (EST) 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 C72E691246 for ; Tue, 11 Feb 2003 09:02:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id A9E075DF8C; Tue, 11 Feb 2003 09:02:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 2F2FA5DEB5 for ; Tue, 11 Feb 2003 09:02:04 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04416 for ; Tue, 11 Feb 2003 06:02:02 -0800 (PST) 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 h1BE21l02163 for ; Tue, 11 Feb 2003 15:02:01 +0100 (MET) Date: Tue, 11 Feb 2003 15:02:00 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: important: updates to LL2, LL3, LL8, other info Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Folks, - I revised www.spybeam.org/issues.html so that the current last call items are clearly marked (bold) - Issue LL8 was suggested by Alex Zinin not Alex Conta - Spurious LL3 text from Thomas Narten (about something else) removed - Additional text for LL2 was added. This topic filled discussion in Oct-Dec 2002. I add some representative views to aid newcomers to the topic, without making any attempt to cover all sides. - In the future, all issue actions will also be posted to the list. Even though this is more verbose, it is important to get it into the archive as this is required by IETF policy. - I added procedures and conflict resolution text already discussed on the mailing list: Procedures We will attempt to resolve points in an order which makes sense. A broader issue may require attention before another issue, so that the result of a later decision does not require us to revisit decisions. A series of one week last calls will be raised to intensely visit issues we have been discussing in an ad hoc fashion for many months. The result of that discussion as it relates to previous working group consensus will be used to determine the fate of the issue. * When referring to an issue in the subject line of an email message, please include the issue number as 'LL#', like LL12. This will ease searching through the mail archive for relevant comments. * Please state clearly up front if you would like to o Accept the issue, o Reject it. o Agree with the problem statement but not with the text. In this case, please say: Accept with revised text . Please be aware that the document under discussion has gone through WG last call and IETF last call several times. The IESG has outstanding issues which it would like the WG to resolve. This is not an invitation to revisit areas which have received no comments in the past. If there is a serious technical flaw which has been overlooked in the past - please bring it up. We are not, however, accepting bright new ideas or anything which would broaden the scope of the protocol. Conflict Resolution If we have contention, we have five possible avenues - in descending order of preference. 1. There is a clear technical answer. Dissenters are dismissed. 2. There is no clear technical answer. One group overwhelms the other. We go with rough consensus. This is for yes/no questions. NOTE: We try to deal with each issue as a yes/no issue first since it is much easier to understand this and conclude discussion. 3. The dissenter posts a competing issue. We choose the group with overwhelming support. This is for multiple choice questions. 4. We have a split we cannot overcome and even make a rough consenus call. Can we drop the goal, accomodate or compromise? 5. We have a split, with no rough consensus possible. We fail. Throw up our hands and let a thousand mutant flowers blossom. As ever - please send comments if any of this is not appropriate. Erik From owner-zeroconf@merit.edu Tue Feb 11 09:02:19 2003 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 JAA05171 for ; Tue, 11 Feb 2003 09:02:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 377B291248; Tue, 11 Feb 2003 09:05:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 030BC91249; Tue, 11 Feb 2003 09:05:44 -0500 (EST) 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 B0E6691248 for ; Tue, 11 Feb 2003 09:05:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 99F8D5DDF8; Tue, 11 Feb 2003 09:05:42 -0500 (EST) 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 3E3065DE37 for ; Tue, 11 Feb 2003 09:05:42 -0500 (EST) 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 HAA26413 for ; Tue, 11 Feb 2003 07:05:40 -0700 (MST) 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 h1BE5dl02268 for ; Tue, 11 Feb 2003 15:05:39 +0100 (MET) Date: Tue, 11 Feb 2003 15:05:38 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: LL2 modified Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk LL2 now contains suggested text (from Robert Elz) Description of Issue Explicit Additional Mechanism to disable v4LL Submitter Name Erik Guttman Submitter Email Address erik.guttman@sun.com Date first submitted 6 Feb 2002 Reference http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00459.html Security considerations with the proposal: http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00473.html Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section Not in document presently. Rationale/Explanation of issue: The specification should be modified to define or require some additional mechanism to disable IPv4 LL autoconfiguration. This mechanism would be mandatory to implement and cause all hosts using IPv4 LL to stop doing so. Lengthy description of problem: ... the desire to have a way to disable LL addresses isn't so that the network manager can make sure that no-one can use the net without their permission, or similar, that's ludicrous, the node(s) could just configure themselves with network 10 addresses, or 192.168, or anything else (including addresses from the block that are designated for use on the net in question). The reason is because the net manager knows what will, and won't work properly on their net, and can provide advice to the nodes as to what they should do in order to work well in the local environment. What is requested is RFC 2563 or some derivative. Requested Change: 1.3 Alternate Configuration Mechanisms As explained in the previous section (1.2), the link-local addresses assigned by this protocol are intended for small ad-hoc networks. However, it is very rare for a system to be constructed that can only ever be connected to such networks. When connected to a properly managed network, nodes should operate correctly for that network. To allow for this, all nodes that implement this protocol MUST also provide some mechanism to allow for routable addresses to be configured. That mechanism MAY use the DHCP protocol [RFC2131] in appropriate cases, but other means, such as manual configuration, are also adequate. Many nodes using this protocol, on large networks, can cause excessive traffic as explained in the previous section (1.2). For this reason, and others, it can be necessary to disable use of link-local addresses in some situations where they are not required. The configuration mechanism provided MUST provide a mechanism to disable the assignment of link local addresses on an interface. Where that configuration mechanism uses DHCP, the node MUST implement the DHCP option to disable stateless auto-configuration in IPv4 clients [RFC2563]. From owner-zeroconf@merit.edu Tue Feb 11 09:08:43 2003 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 JAA05364 for ; Tue, 11 Feb 2003 09:08:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1222791249; Tue, 11 Feb 2003 09:12:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CFD769124A; Tue, 11 Feb 2003 09:12:16 -0500 (EST) 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 9527091249 for ; Tue, 11 Feb 2003 09:12:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 801885DE37; Tue, 11 Feb 2003 09:12:15 -0500 (EST) 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 23B895DDF8 for ; Tue, 11 Feb 2003 09:12:15 -0500 (EST) 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 HAA06586 for ; Tue, 11 Feb 2003 07:12:13 -0700 (MST) 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 h1BECCl02526 for ; Tue, 11 Feb 2003 15:12:12 +0100 (MET) Date: Tue, 11 Feb 2003 15:12:11 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: LL3 changed - additional lengthy description added Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The new text of LL3 follows. Also see http://www.spybeam.org/ll3.html ------------------------------------------------------------------------ Description of Issue TTL=255 on send, check on receive? Submitter Name Erik Guttman Submitter Email Address erik.guttman@sun.com Date first submitted 6 Feb 2003 Reference http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00041.html http://www.merit.edu/mail.archives/zeroconf/2002-10/msg00000.html Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section 2.7 Rationale/Explanation of issue: There are various problems with the current text relating to setting TTL=255 and checking it. Lengthy description of problem: The current text says: "Any host sending an IPv4 packet with a source and/or destination address in the 169.254/16 prefix MUST set the TTL in the IP header to 255. This includes multicast and broadcast packets with a source address in the 169.254/16 prefix." And: "A host receiving a packet with a source and/or destination address in the 169.254/16 prefix and a TTL less than 255, MAY choose to consider such packets as potentially having been generated by a malicious attacker outside the local link, and MAY choose to silently discard such packets." ---------------------------------------------------------------- WG chair attempt at an unbiased overview of the points raised so far: * Setting the TTL to 255 may cause packets to leave the LAN as routers do not know to filter them. (REBUTTAL: If a host knows enough to set to 255 it also knows enough not to forward such a message to a router in the first place.) (REBUTTAL TO REBUTTAL: A message to a multicast address will be forwarded. Some routers also perform proxy ARP, so these messages can escape from the local LAN). * Some existing implementations do not set to 255. Filtering will decrease interoperability. We must 'do no harm.' * The security benefits to be had here are dubious. The document is misleading in that it creates unreasonably high expectations of security benefits from this feature. * Setting the TTL to 1 will prevent routers which have not been specifically configured to specially treat v4LL source addressed messages from forwarding LL messages. REBUTTAL: This decreases the incentive to reconfigure routers to comply with these recommendations. REBUTTAL TO REBUTTAL: We cannot expect all routers in the world to be reconfigured overnight. ---------------------------------------------------------------- Thomas Narten wrote: The way I understand the issues: Enforcing the 255-on-receipt check is non-backwards compatable. Indeed, it occurred to me today that its non-backwards compatable with nodes that don't even implement LL addressing. Consider a node A, on the same link with B. A has a global address, B has a LL address. If A attempts to communicate with B, but B notices that the dest address is LL, and then checks for a TTL of 255 (following the recommendation in the current ID), communication will likely fail. So here we have a case where two nodes with valid addresses can't communicate for non-obvious reasons. Neither implementation is violating a Standard. Note the A has not implemented LL at all, so it can't be violating any LL standard. Is this not a potential interoperability problem that we shouldn't knowingly encourage? However, now that Apple does this check, setting the TTL to anything other than 255 is also problematic. That might argue for setting it to 255 (and explaining in the document why), but also saying SHOULD NOT or MUST NOT do the check on receipt since we know it also causes problems with existing implementations that don't set the TTL this way. (Note we could say that the test might be changed in a future standard once the deployed base is upgraded/junked, but it is too early to say that today if one wants to avoid interoperability problems today). But setting the TTL to 255 (rather than 1) also will lead to more LL packets going off link then if the TTL is set to 1. Sure, hosts aren't *supposed* to forward them to routers, but some leakage will inevitably happen as a result of misconfigurations, and other things that are "not supposed to happen". This may cause operational problems. How much? Hard to say. Depends on how many (and which) routers do filtering. I don't believe we need 100% compliance here in order to get enough filtering in practice to keep LL traffic from leaking in horrible ways. For a home site, for example, does it care if its LL traffic goes off link? Probably not. What it cares about is that it doesn't go across the DSL link to its ISP (or that packets from the ISP come in with LL addresses). But that is something the ISP probably cares about enough to ensure that filters are fairly likely to get put at that boundary. Etc. ---------------------------------------------------------------- Stuart Cheshire wrote: There are four practical alternatives for the Working Group to choose between: 1. Always check TTL=255 2. Always check TTL=1 3. Don't check TTL at all 4. Have an optional (user configured) check for TTL=255 The three metrics to examine are: (Mac) Always compatible with existing Macs (Win) Always compatible with existing Windows boxes (Orig) Always able to determine if packet originated on the local link The scores: (Mac) (Win) (Orig) 1. Always check TTL=255 + - + 2. Always check TTL=1 - - - 3. Don't check TTL at all + + - 4. User configured TTL=255 + - - Option 1 works with Macs. Option 1 tells you the origin of the packet. Option 1 works with Windows, but only after you've changed the registry key as described in Appendix A.3. (This registry change doesn't have to be done manually by the user -- we're recommending to printer vendors that their printer driver software should automatically make the registry change so that Windows will automatically work properly with their Zeroconf printers.) Option 2 works with nothing today. It tells you nothing about the origin of the packet. It may limit forwarding of the packet, but this is a moot point because compliant hosts don't send LL packets to routers for forwarding anyway. Option 3 works with today's Macs and Windows boxes, but doesn't tell you the origin on the packet. Option 4 lets the user configure whether they want their printer to guard gainst off-link packets, or whether they want their printer to be compatible with the old version of Windows they are using. If the user configures it to check, it might not work with old Windows boxes, generating expensive support calls, so it fails the "Always works with Windows" test. If the user configures it to not check, then it might accept off-link packets, so it fails the "Always able to determine if packet originated on the local link" test. I have only one further comment to make on this topic: Which part of "Zero" and "Configuration" did you not understand? If we have to configure something to make it all work properly, lets configure the Registry key on last-year's Windows boxes to make them work better, not force the customer who buys next year's Zeroconf devices to understand and change some configuration setting to make them work worse. Of the four, options 1 and 3 get two points each. Option 1 has the benefit that receivers know the origin of the packet. Option 3 has the benefit that it saves Microsoft the hassle of having to change its software. My vote goes for option 1, because it gives the bigger long-term benefit. Some people have suggested a policy where we require senders to set the TTL to 255, but not check the TTL on reception, and then in future, after Windows has been updated, we update the specification to require the check too. This simply doesn't work. The fact is that there is no incentive for vendors to set the TTL correctly if no one is checking. The longer time goes on, the more non-conformant devices there will be, and it will become impossible to enforce the check later. We have to decide now. ---------------------------------------------------------------- Bernard Aboba wrote: The way to think about this is what the default behavior should be. The single most important thing about TCP/IP is that it is interoperable -- that is, that you can take two hosts with dissimilar operating systems and do an FTP between them. Put together, Zeroconf now has the potential to break the basic interoperability of TCP/IP -- by taking two hosts that formerly could do an FTP using global addresses and now making them unable to communicate. The breakage occurs two ways -- by introducing non-interoperable IPV4 linklocal, and by introducing non-interoperable name resolution. I would argue that if Zeroconf does nothing else, it MUST "do no harm". That is, two hosts with global addresses MUST be guaranteed to be able to continue to communicate interoperably after Zeroconf is introduced. To accomplish this, we need several things: a. Zeroconf protocols MUST be a last resort -- that is, linklocal addresses MUST NOT be used if the two peers have global addresses available. b. A host MUST NOT by default silently discard packets with TTL < 255. ---------------------------------------------------------------- Ran Atkinson wrote: Probability of a packet both leaking and arriving with a TTL exactly equal 1 is quite low. Leaking and having a TTL between 1 and 254 is MUCH MUCH higher probability -- and is protected against. > Are you saying that the sending problem is more important than the > receiving one? Among other things, I do think the sending problem is more significant -- but also note that I think that TTL of 1 actually helps the overwhelming majority of receivers also. ---------------------------------------------------------------- Please see the archive from mid October 2002 to the end of December 2002 for more on this thread. ---------------------------------------------------------------- Requested Change: Replace "A host receiving..." with "At a future time, when legacy pre-standard implementations are in the minority a follow on standard may be issued which will state that hosts SHOULD discard packets with a source and/or destination address in the 169.254/16 prefix and a TTL less than 255. This will lessen the possibility that a host with a v4LL configured address will receive a datagram from a host off the local link, to which it cannot respond." From owner-zeroconf@merit.edu Tue Feb 11 09:12:41 2003 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 JAA05474 for ; Tue, 11 Feb 2003 09:12:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D10E89124A; Tue, 11 Feb 2003 09:15:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 948839124B; Tue, 11 Feb 2003 09:15:50 -0500 (EST) 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 9CD6B9124A for ; Tue, 11 Feb 2003 09:15:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 74E0E5DDF8; Tue, 11 Feb 2003 09:15:45 -0500 (EST) 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 7AB265DFB5 for ; Tue, 11 Feb 2003 09:15:44 -0500 (EST) 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 HAA01827 for ; Tue, 11 Feb 2003 07:15:43 -0700 (MST) 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 h1BEFfl02625; Tue, 11 Feb 2003 15:15:41 +0100 (MET) Date: Tue, 11 Feb 2003 15:15:40 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Cc: erik.nordmark@sun.com Subject: important: ERROR - LL10 not LL7 should be under WG last call! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I humbly apologize. Keith is right - we are probably taking on too many last calls at once. When I called a 1 week discussion on LL7 I referred to LL10. That is the document we should be discussing. For that reason, let's extend the last call on this document for an extra week (till Feb 22). Sorry for the confusion. Erik From owner-zeroconf@merit.edu Tue Feb 11 09:15:57 2003 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 JAA05657 for ; Tue, 11 Feb 2003 09:15:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 940589124B; Tue, 11 Feb 2003 09:19:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30FCC9124C; Tue, 11 Feb 2003 09:19:20 -0500 (EST) 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 CDC0C9124B for ; Tue, 11 Feb 2003 09:17:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id A2BD55DE10; Tue, 11 Feb 2003 09:17:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id F3EBA5DDF1 for ; Tue, 11 Feb 2003 09:17:53 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13387 for ; Tue, 11 Feb 2003 06:17:52 -0800 (PST) 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 h1BEHpl02745 for ; Tue, 11 Feb 2003 15:17:51 +0100 (MET) Date: Tue, 11 Feb 2003 15:17:50 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: new issue: [LL24] Don't configure needless LL addresses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Description of Issue Don't configure needless LL addresses Submitter Name Robert Elz Submitter Email Address kre@munnari.OZ.AU Date first submitted 9 Feb 2003 Reference http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00262.html http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00548.html http://www.merit.edu/mail.archives/zeroconf/2003-02/msg00000.html Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section 1.5 Rationale/Explanation of issue: See LL1 Lengthy description of problem: See LL1 Requested Change: Delete all of section 1.5, and replace it with: Having addresses of multiple different scopes assigned to an interface with no adequate way to determine in what circumstances each address should be used leads to complexity for applications and confusion for users. A node with any address assigned for a link can communicate with all other devices on that link, whether those other devices use link-local addresses, or routable addresses. For this reason, a host that obtains, or is configured with, a routable address on an interface, SHOULD NOT attempt to configure a link-local address on the same interface. Where a link-local address has been configured on an interface, and a routable address is later configured on the same interface, the host MUST always use the routable address when initiating new communications, and MUST cease advertising the availability of the link-local address through whatever mechanisms that address had been made known to others. A host SHOULD continue to use the link-local address for communications underway when the routable address was configured, and MAY continue to accept new communications addressed to the link-local address. From owner-zeroconf@merit.edu Tue Feb 11 09:18:37 2003 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 JAA05747 for ; Tue, 11 Feb 2003 09:18:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 35E899124C; Tue, 11 Feb 2003 09:22:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0580D9124D; Tue, 11 Feb 2003 09:22:10 -0500 (EST) 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 180289124C for ; Tue, 11 Feb 2003 09:22:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id E8B3F5DF8C; Tue, 11 Feb 2003 09:22:09 -0500 (EST) 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 65F535DF9E for ; Tue, 11 Feb 2003 09:22:09 -0500 (EST) 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 HAA03437 for ; Tue, 11 Feb 2003 07:22:08 -0700 (MST) 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 h1BEM6l02982 for ; Tue, 11 Feb 2003 15:22:07 +0100 (MET) Date: Tue, 11 Feb 2003 15:22:05 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: new issue [LL24] Weaken the PRN generated address requirement from MUST to MAY Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The new issue follows. It may also be found under http://www.spybeam.org/ll24.html I reluctantly post this issue since I do not yet understand its justification. ------------------------------------ Description of Issue Weaken the PRN generated address requirement from MUST to MAY Submitter Name Subrata Goswami Submitter Email Address sgoswami@umich.edu Date first submitted 11 Feb 03 Reference none Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] 2 Section 2.1 Rationale/Explanation of issue: The algorithm that a LL node uses to determine its LL address does not need to be always PRN based, as ARP can be used validate if it is unique in the Link. Lengthy description of problem: Section 2.1 says, "When a host wishes to configure a link-local address, it selects an address using a pseudo-random number generator with a uniform distribution in the range from 169.254.1.0 to 169.254.254.255." ".. The pseudo-random number generation algorithm MUST be chosen so that different hosts do not generate the same sequence of numbers." Here text should be changed to indicted that the node can use other means to select a LL address than PRN, but has to varify uniqueness by ARPing before it intends to use that adderess on a link the first time (or after absence). Requested Change: ".. The pseudo-random number generation algorithm MAY be chosen so that different hosts do not generate the same sequence of numbers." From owner-zeroconf@merit.edu Tue Feb 11 09:23:06 2003 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 JAA05938 for ; Tue, 11 Feb 2003 09:23:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2571591272; Tue, 11 Feb 2003 09:25:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD82491267; Tue, 11 Feb 2003 09:25:16 -0500 (EST) 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 7618191251 for ; Tue, 11 Feb 2003 09:25:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 544C85DFBB; Tue, 11 Feb 2003 09:25:13 -0500 (EST) 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 C97A65DF8C for ; Tue, 11 Feb 2003 09:25:12 -0500 (EST) 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 GAA04324 for ; Tue, 11 Feb 2003 06:25:10 -0800 (PST) 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 h1BEP9l03043 for ; Tue, 11 Feb 2003 15:25:09 +0100 (MET) Date: Tue, 11 Feb 2003 15:25:08 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: new issue [LL25] Delete inappropriate "send" requirement on LL nodes. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The text of this issue follows. It can also be found at http://www.spybeam.org/ll25.html I post this issue reluctantly as I believe it is based on a basic misunderstanding of the specification. -------------------------------------------------------------------- Description of Issue Delete inappropriate "send" requirement on LL nodes. Submitter Name Subrata Goswami Submitter Email Address sgoswami@umich.edu Date first submitted 11 Feb 03 Reference none Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section 2.6 Rationale/Explanation of issue: Delete the following statements ".. The host MUST NOT send the packet to any router for forwarding." Lengthy description of problem: Section 2.6 requires the following of an LL node at several places. ".. The host MUST NOT send the packet to any router for forwarding." The nodes on a link should not have the responsibility of determining whether the router can forward a packet or not. Requested Change: Delete the following statements (throughout the document) ".. The host MUST NOT send the packet to any router for forwarding." From owner-zeroconf@merit.edu Tue Feb 11 09:23:12 2003 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 JAA05952 for ; Tue, 11 Feb 2003 09:23:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ED71C91251; Tue, 11 Feb 2003 09:26:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7144F91252; Tue, 11 Feb 2003 09:26:28 -0500 (EST) 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 8FE5D91251 for ; Tue, 11 Feb 2003 09:26:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7938F5DF8C; Tue, 11 Feb 2003 09:26:24 -0500 (EST) 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 224B65DDF1 for ; Tue, 11 Feb 2003 09:26:24 -0500 (EST) 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 HAA05805 for ; Tue, 11 Feb 2003 07:26:23 -0700 (MST) 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 h1BEQHl03175; Tue, 11 Feb 2003 15:26:17 +0100 (MET) Date: Tue, 11 Feb 2003 15:26:16 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Erik Guttman Cc: zeroconf@merit.edu Subject: Corection: new issue: [LL23] Don't configure needless LL addresses In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Please also see http://www.spybeam.org/ll23.html On Tue, 11 Feb 2003, Erik Guttman wrote: > Description of Issue Don't configure needless LL addresses > Submitter Name Robert Elz > Submitter Email Address kre@munnari.OZ.AU > Date first submitted 9 Feb 2003 > Reference > http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00262.html > http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00548.html > http://www.merit.edu/mail.archives/zeroconf/2003-02/msg00000.html > Comment Type ['T'echnical | 'E'ditorial] T > Priority ['S' Must fix | '1' Should fix | '2' May fix ] S > Section 1.5 > > Rationale/Explanation > of issue: See LL1 Lengthy description of problem: See LL1 Requested > > Change: > > Delete all of section 1.5, and replace it with: > > Having addresses of multiple different scopes assigned to an interface > with no adequate way to determine in what circumstances each address > should be used leads to complexity for applications and confusion for > users. A node with any address assigned for a link can communicate with > all other devices on that link, whether those other devices use > link-local addresses, or routable addresses. > > For this reason, a host that obtains, or is configured with, a routable > address on an interface, SHOULD NOT attempt to configure a > link-local address on the same interface. > > Where a link-local address has been configured on an interface, and a > routable address is later configured on the same interface, the host > MUST always use the routable address when initiating new communications, > and MUST cease advertising the availability of the link-local address > through whatever mechanisms that address had been made known to others. > > A host SHOULD continue to use the link-local address for communications > underway when the routable address was configured, and MAY continue to > accept new communications addressed to the link-local address. > > ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n N1 Installation and Provisioning cell: +49 172 865 5497 Sun Microsystems pager: 01728655497@d2-message.de From owner-zeroconf@merit.edu Tue Feb 11 09:26:06 2003 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 JAA06029 for ; Tue, 11 Feb 2003 09:26:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 54F2991252; Tue, 11 Feb 2003 09:29:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2082F91259; Tue, 11 Feb 2003 09:29:39 -0500 (EST) 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 1284891252 for ; Tue, 11 Feb 2003 09:29:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF3005DFBB; Tue, 11 Feb 2003 09:29:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 74DC25DF9E for ; Tue, 11 Feb 2003 09:29:37 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20656 for ; Tue, 11 Feb 2003 06:29:36 -0800 (PST) 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 h1BETYl03258 for ; Tue, 11 Feb 2003 15:29:35 +0100 (MET) Date: Tue, 11 Feb 2003 15:29:33 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: new issue: [LL26] source address selection is different from destination access Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The text of the issue follows. Please also see http://www.spybeam.org/ll26.html ---------------------------------------------------------------- Description of Issue source address selection is different from destination access Submitter Name Philip Nye Submitter Email Address philipn@engarts.com Date first submitted 10 Feb 2003 Reference Comment Type ['T'echnical | 'E'ditorial] E Priority ['S' Must fix | '1' Should fix | '2' May fix ] 1 Section 2.6 Rationale/Explanation of issue: Section 2.6 depite its title "Source Address Selection" actually talks a lot about how to reach destination addresses. This makes change to wording difficult and confuses some issues under discussion. Lengthy description of problem: Selection of source address is an issue connected with multihoming and the degree to which v4LL addresses are deprecated in the presence of configured addresses. Access to destination addresses is a simple choice of when to ARP and when to send to a router and should be treated in a different section. Based on the existing text in draft 7 these sections would become as below. This text would be potentially modified by issues LL1, LL13, LL17, LL19 and maybe others. Requested Change: Delete section 2.6 and replace with: 2.6 Source Address Selection Since each interface on a host may have a link-local address in addition to zero or more other addresses configured by other means (e.g. manually or via a DHCP server), a host may have to make a choice about what source address to use when it sends a packet or initiates a TCP connection. 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 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. If the destination address is a unicast address outside the 169.254/16 prefix, then the host SHOULD use an appropriate routable source address, if it has one. If the host does not have a routable source address, then it MAY choose to send its packet, with a link-local source IP address and a routable destination IP address. 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 address, depending on which is expected to be more likely to remain stable for the expected lifetime of the connection. Note that link- local addresses may be forced to change over time, as described in Section 2.5. 2.6a Accessing destination addresses If the destination address of a packet to be sent is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), the host MAY choose to ARP for the destination address and then send its packet, with 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. If the destination address is a unicast address outside the 169.254/16 prefix and the source address is a Link-Local address, then the sender MAY choose to ARP for the destination address and then send its packet, with a link-local source IP address and a routable destination IP address, directly to its destination on the same physical link. The host MUST NOT send the packet to any router for forwarding. From owner-zeroconf@merit.edu Tue Feb 11 09:37:58 2003 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 JAA06426 for ; Tue, 11 Feb 2003 09:37:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 71F619126D; Tue, 11 Feb 2003 09:40:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26DCE91273; Tue, 11 Feb 2003 09:40:08 -0500 (EST) 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 091E79126D for ; Tue, 11 Feb 2003 09:40:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC5745DF8C; Tue, 11 Feb 2003 09:40:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by segue.merit.edu (Postfix) with ESMTP id CBB835DDBD for ; Tue, 11 Feb 2003 09:40:02 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ibZn-0006Nn-00; Tue, 11 Feb 2003 06:40:01 -0800 Date: Tue, 11 Feb 2003 09:37:39 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: new issue: [LL26] source address selection is different from destination access Message-Id: <20030211093739.58068f69.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 agree with the rationale, disagree with the requested change. A host SHOULD always use a routable address as a source address if it has one, even when sending to an LL destination. From owner-zeroconf@merit.edu Tue Feb 11 09:46:20 2003 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 JAA06771 for ; Tue, 11 Feb 2003 09:46:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 103AE9120F; Tue, 11 Feb 2003 09:49:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD3FC91240; Tue, 11 Feb 2003 09:49:45 -0500 (EST) 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 9323B9120F for ; Tue, 11 Feb 2003 09:49:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 81D625DD8F; Tue, 11 Feb 2003 09:49:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by segue.merit.edu (Postfix) with ESMTP id 524FA5DDA5 for ; Tue, 11 Feb 2003 09:49:42 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ibj6-0001Vf-00; Tue, 11 Feb 2003 06:49:36 -0800 Date: Tue, 11 Feb 2003 09:47:16 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, Erik.Guttman@sun.com, zeroconf@merit.edu Subject: Re: Corection: new issue: [LL23] Don't configure needless LL addresses Message-Id: <20030211094716.07becbb1.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 I support the intent, but with changes / caveats 1. this is not sufficient by itself. there must be a uniform way for networks to give hosts routable addresses, and LL hosts MUST (or at least SHOULD) implement that. 2. > > For this reason, a host that obtains, or is configured with, a routable > > address on an interface, SHOULD NOT attempt to configure a > > link-local address on the same interface. ... unless explicitly (manually?) configured to do so. > > Where a link-local address has been configured on an interface, and a > > routable address is later configured on the same interface, the host > > MUST always use the routable address ...as a source address... > > when initiating new communications, ...unless the application unambiguously specifies that another address be used. > > and MUST cease advertising the availability of the link-local address > > through whatever mechanisms that address had been made known to others. this is not, in general, a host function - imposing MUST on something the host does not control does not seem like a good idea. suggest: It is also desirable for hosts and applications to cease advertising availability of services at link-local addresses once those services are available through routable addresses, and it is necessary to cease advertising availability thorugh link-local addresses once those services are no longer available through link-local addresses. From owner-zeroconf@merit.edu Tue Feb 11 09:46:53 2003 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 JAA06803 for ; Tue, 11 Feb 2003 09:46:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ACD6591240; Tue, 11 Feb 2003 09:50:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 808D19125A; Tue, 11 Feb 2003 09:50:19 -0500 (EST) 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 AA6D791240 for ; Tue, 11 Feb 2003 09:50:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 973275DDA5; Tue, 11 Feb 2003 09:50:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by segue.merit.edu (Postfix) with ESMTP id 75B535DD8F for ; Tue, 11 Feb 2003 09:50:16 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ibji-0006SS-00; Tue, 11 Feb 2003 06:50:15 -0800 Date: Tue, 11 Feb 2003 09:47:54 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: new issue [LL25] Delete inappropriate "send" requirement on LL nodes. Message-Id: <20030211094754.1182272e.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 I oppose this change. From owner-zeroconf@merit.edu Tue Feb 11 09:48:03 2003 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 JAA06875 for ; Tue, 11 Feb 2003 09:48:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 320499125A; Tue, 11 Feb 2003 09:51:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFB989125D; Tue, 11 Feb 2003 09:51:30 -0500 (EST) 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 E9CF29125A for ; Tue, 11 Feb 2003 09:51:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id D742E5DDA5; Tue, 11 Feb 2003 09:51:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by segue.merit.edu (Postfix) with ESMTP id AAB925DD8F for ; Tue, 11 Feb 2003 09:51:29 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ibkt-0006bL-00; Tue, 11 Feb 2003 06:51:28 -0800 Date: Tue, 11 Feb 2003 09:49:07 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: new issue [LL24] Weaken the PRN generated address requirement from MUST to MAY Message-Id: <20030211094907.4ac3e0a8.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 I oppose this change. the overhead of ARP is only acceptable if collisions are rare; using a random number generator of some sort (perhaps not a PRN) is necessary to avoid collisions. From owner-zeroconf@merit.edu Tue Feb 11 09:52:59 2003 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 JAA06987 for ; Tue, 11 Feb 2003 09:52:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2A1069125D; Tue, 11 Feb 2003 09:56:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3B6191262; Tue, 11 Feb 2003 09:56:32 -0500 (EST) 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 BF59C9125D for ; Tue, 11 Feb 2003 09:56:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id A08555DDAF; Tue, 11 Feb 2003 09:56:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by segue.merit.edu (Postfix) with ESMTP id 7E69B5DD8F for ; Tue, 11 Feb 2003 09:56:31 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ibpl-00071X-00; Tue, 11 Feb 2003 06:56:29 -0800 Date: Tue, 11 Feb 2003 09:54:09 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL2 modified Message-Id: <20030211095409.1edfa3ec.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 oppose this as written. manual configuration capability is not sufficient to relieve a host of the need to try DHCP before configuring an LL address. nor is it sufficient to leave the mechanism by which a host obtains a routable address unspecified. here's how I'd modify it: a host that attempts to automatically configure an address MUST implement DHCP, and MAY implement LL. If the host implements LL it MUST give preference to DHCP. (but we need to work this out in more detail) a host MAY (SHOULD?) permit manual configuration of addresses to override any DHCP or LL address assignment. a host MAY be manually configurable to allocate an LL address even if it has obtained a routable address by other means. From owner-zeroconf@merit.edu Tue Feb 11 10:15:55 2003 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 KAA07798 for ; Tue, 11 Feb 2003 10:15:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BCA4591218; Tue, 11 Feb 2003 10:19:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 880B091262; Tue, 11 Feb 2003 10:19:26 -0500 (EST) 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 BC71791218 for ; Tue, 11 Feb 2003 10:18:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 949EB5DDE6; Tue, 11 Feb 2003 10:18:02 -0500 (EST) 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 660285DDD1 for ; Tue, 11 Feb 2003 10:18:02 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 66CB359958; Tue, 11 Feb 2003 15:18:04 +0000 (GMT) Message-ID: <001d01c2d1e0$c44d1260$131010ac@aldebaran> From: "Philip Nye" To: "Keith Moore" , "Erik Guttman" Cc: , References: <20030211093739.58068f69.moore@cs.utk.edu> Subject: Re: new issue: [LL26] source address selection is different from destination access Date: Tue, 11 Feb 2003 15:18:01 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Keith Moore" > > agree with the rationale, disagree with the requested change. > A host SHOULD always use a routable address as a source address if it has > one, even when sending to an LL destination. I happen to agree with this - the change should be in LL1 I think. But given the number of other issues proposing textual changes to section 2.6 I simply split it based on the text in the draft. I would suggest that my split be (conceptually) applied first then other changes be applied to the text as split. I certainly agree with some of the other proposals which would modify this text but didn't want to confuse the issue of what it should say with the problem stated in the issue and in fact the whole idea of splitting it is to allow discussion of source selection to be separated from the rules on how to send the packet which are less controversial. How is best to resolve this interdependence of issues Erik? Should I try and reword my proposal or add a note? Philip From owner-zeroconf@merit.edu Tue Feb 11 10:21:53 2003 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 KAA08135 for ; Tue, 11 Feb 2003 10:21:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DFA8291262; Tue, 11 Feb 2003 10:25:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A112791267; Tue, 11 Feb 2003 10:25:27 -0500 (EST) 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 B595F91262 for ; Tue, 11 Feb 2003 10:25:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 920115DDFB; Tue, 11 Feb 2003 10:25:26 -0500 (EST) 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 C77C85DDA5 for ; Tue, 11 Feb 2003 10:25:25 -0500 (EST) 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 HAA14913; Tue, 11 Feb 2003 07:25:19 -0800 (PST) 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 h1BFPCl05366; Tue, 11 Feb 2003 16:25:12 +0100 (MET) Date: Tue, 11 Feb 2003 16:25:11 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Philip Nye Cc: Keith Moore , Erik Guttman , zeroconf@merit.edu Subject: Re: new issue: [LL26] source address selection is different from destination access In-Reply-To: <001d01c2d1e0$c44d1260$131010ac@aldebaran> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Philip, On Tue, 11 Feb 2003, Philip Nye wrote: > I certainly agree with some of the other proposals which would modify this > text but didn't want to confuse the issue [snip] > How is best to resolve this interdependence of issues Erik? Should I try and > reword my proposal or add a note? Since the text will likely be in flux as we discuss other issues, how about you leave the suggested text blank at this point and just include an editorial instruction to 'divide the source address selection' and 'destination access policy' text. The question is - should we discuss/approve LL26 at the same time as LL1 and LL2 (which are The Hot Topics and need to be brought up ASAP), or should we consider the editorial splitting afterwards? Erik From owner-zeroconf@merit.edu Tue Feb 11 10:22:38 2003 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 KAA08168 for ; Tue, 11 Feb 2003 10:22:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B40F091267; Tue, 11 Feb 2003 10:26:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81BDF91273; Tue, 11 Feb 2003 10:26:13 -0500 (EST) 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 40E7791267 for ; Tue, 11 Feb 2003 10:26:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 31F745DDFB; Tue, 11 Feb 2003 10:26:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by segue.merit.edu (Postfix) with ESMTP id 1061E5DDA5 for ; Tue, 11 Feb 2003 10:26:12 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18icIS-0006EW-00; Tue, 11 Feb 2003 07:26:08 -0800 Date: Tue, 11 Feb 2003 10:23:48 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: (mostly off topic) surviving DHCP failures Message-Id: <20030211102348.464290ec.moore@cs.utk.edu> In-Reply-To: <00e001c2d1b7$32f088c0$131010ac@aldebaran> References: <200302101245.h1ACjXr21706@cichlid.adsl.duke.edu> <024e01c2d11e$e0ea9810$131010ac@aldebaran> <20030210113301.57090498.moore@cs.utk.edu> <027f01c2d123$3f4ebae0$131010ac@aldebaran> <20030210124601.5c22d134.moore@cs.utk.edu> <00e001c2d1b7$32f088c0$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Tue, 11 Feb 2003 10:20:28 -0000 "Philip Nye" wrote: > > and a host really ought to be able to ask "is my lease still valid here" > > without having to risk losing the lease if it's on the same network as > > before... > > Transition from configured to Zero-config is even harder than the other way. > But to meet the aims we should at least spell out a path. If that means > outlining reasonable changes which would be required of DHCP then this is no > bad thing even if they cannot be progressed here. I'm reluctant to even suggest things because I don't know much about DHCP and haven't really had the time to investigate it in detail. But the first thing you need is for lease times to be much greater than the time required to identify a failed DHCP server and fix it. And if you need short lease times due to a shortage of addresses, this translates to a requirement that you be able to restore DHCP service very quickly. This isn't a protocol issue by itself - it's a configuration issue. I take the time to identify and fix a DHCP server problem to be a few hours for most managed networks. It could be made smaller with appropriate monitoring/alarms, hot backups for DHCP servers, and redundancy in the network connecting DHCP servers to clients, which would allow for shorter lease times. (note that the lease time could vary according to the availability of maintenance personnel - e.g. leases could be longer on weekends.) The second condition you need to meet is that a DHCP server outage does not immediately cause problems for hosts that already have addresses, even if they try to renew during that time. If a DHCP server might be inaccessible for several hours, not only do lease times need to be greater than that, but hosts need to renew their leases often enough that they will always have a lease that lasts for longer than the server is likely to be down. To give a concrete example, if the time required to fix a broken DHCP server were 2 hours, leases might need to be say 6 hours, and hosts need to renew their leases every hour or so, getting a 6 hour extension each time. Even if no response were heard, the old lease would still be valid. That way every host would have a lease valid for at least 5 more hours at the time that the DHCP server went down. To make this work, a host needs to be able to renew a lease without fear that an existing lease will be invalidated. DHCP should always renew a lease with the same address if it is possible to do so. There are other requirements for robustness. If there are multiple DHCP servers on a network, they need to not conflict with one another. Either they need to provide consistent results, or hosts need to treat their leases as separate from one another (each one hands out its own addresses, and hosts can use multiple addresses at once). DHCP servers need to be able to survive power failures without losing lease assignments. etc. -- What does any of this have to do with LL? Not much. DHCP problems need to be solved within DHCP. The best way to avoid churn between LL and DHCP is to fix DHCP to be more robust. That way, a host will only use LL if it wakes up while a DHCP server happens to be down, and only until the DHCP server comes back up (plus the interval that the host waits before retrying DHCP). From owner-zeroconf@merit.edu Tue Feb 11 10:27:44 2003 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 KAA08336 for ; Tue, 11 Feb 2003 10:27:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5F2F391273; Tue, 11 Feb 2003 10:30:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24B0591274; Tue, 11 Feb 2003 10:30:41 -0500 (EST) 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 EA53991273 for ; Tue, 11 Feb 2003 10:30:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2BE1D5DDF1; Tue, 11 Feb 2003 10:30:33 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by segue.merit.edu (Postfix) with ESMTP id BE5C85DDA5 for ; Tue, 11 Feb 2003 10:30:32 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18icMb-0005cv-00; Tue, 11 Feb 2003 07:30:25 -0800 Date: Tue, 11 Feb 2003 10:28:05 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, Erik.Guttman@Sun.COM, zeroconf@merit.edu Subject: Re: new issue: [LL26] source address selection is different from destination access Message-Id: <20030211102805.3c6ae196.moore@cs.utk.edu> In-Reply-To: <001d01c2d1e0$c44d1260$131010ac@aldebaran> References: <20030211093739.58068f69.moore@cs.utk.edu> <001d01c2d1e0$c44d1260$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 my impression is that we're trying too hard to express these issues in terms of changes to the existing text, when the existing text suffers from several assumptions that are now being questioned. let's agree on the principles, and figure out how they affect the text later. On Tue, 11 Feb 2003 15:18:01 -0000 "Philip Nye" wrote: > > From: "Keith Moore" > > > > agree with the rationale, disagree with the requested change. > > A host SHOULD always use a routable address as a source address if it has > > one, even when sending to an LL destination. > > I happen to agree with this - the change should be in LL1 I think. > > But given the number of other issues proposing textual changes to section > 2.6 I simply split it based on the text in the draft. > > I would suggest that my split be (conceptually) applied first then other > changes be applied to the text as split. > > I certainly agree with some of the other proposals which would modify this > text but didn't want to confuse the issue of what it should say with the > problem stated in the issue and in fact the whole idea of splitting it is to > allow discussion of source selection to be separated from the rules on how > to send the packet which are less controversial. > > How is best to resolve this interdependence of issues Erik? Should I try and > reword my proposal or add a note? > > Philip > From owner-zeroconf@merit.edu Tue Feb 11 10:32:34 2003 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 KAA08433 for ; Tue, 11 Feb 2003 10:32:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6B53D9123F; Tue, 11 Feb 2003 10:36:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3823A91274; Tue, 11 Feb 2003 10:36:07 -0500 (EST) 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 1799F9123F for ; Tue, 11 Feb 2003 10:36:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id F38BB5DE01; Tue, 11 Feb 2003 10:36:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by segue.merit.edu (Postfix) with ESMTP id 8C2D65DDA5 for ; Tue, 11 Feb 2003 10:36:05 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1BFa3JR011952 for ; Tue, 11 Feb 2003 10:36:03 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-75.cisco.com [161.44.150.75]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA22849 for ; Tue, 11 Feb 2003 10:36:03 -0500 (EST) Message-Id: <4.3.2.7.2.20030211102921.03d89078@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Feb 2003 10:36:01 -0500 To: zeroconf@merit.edu From: Ralph Droms Subject: Re: (mostly off topic) surviving DHCP failures In-Reply-To: <20030211102348.464290ec.moore@cs.utk.edu> References: <00e001c2d1b7$32f088c0$131010ac@aldebaran> <200302101245.h1ACjXr21706@cichlid.adsl.duke.edu> <024e01c2d11e$e0ea9810$131010ac@aldebaran> <20030210113301.57090498.moore@cs.utk.edu> <027f01c2d123$3f4ebae0$131010ac@aldebaran> <20030210124601.5c22d134.moore@cs.utk.edu> <00e001c2d1b7$32f088c0$131010ac@aldebaran> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Keith, I would be happy to follow up on your discussion of how to make DHCP more robust. You've mostly got it right...there are some details I can fill in (I hope Ted and I have addressed most of them in "The DHCP Handbook"). But, I'm not sure this is the right venue and would suggest we should move a discussion about DHCP over to the dhcwg@ietf mailing list... - Ralph From owner-zeroconf@merit.edu Tue Feb 11 11:09:23 2003 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 LAA09425 for ; Tue, 11 Feb 2003 11:09:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3016691296; Tue, 11 Feb 2003 11:12:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D946E91293; Tue, 11 Feb 2003 11:12:31 -0500 (EST) 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 819E69128B for ; Tue, 11 Feb 2003 11:12:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 706E85DE49; Tue, 11 Feb 2003 11:12:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 140C95DDA5 for ; Tue, 11 Feb 2003 11:12:28 -0500 (EST) Received: from nominum.com (dsl093-187-100.chi2.dsl.speakeasy.net [66.93.187.100]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1BGBJP07231; Tue, 11 Feb 2003 10:11:19 -0600 (CST) Date: Tue, 11 Feb 2003 10:12:22 -0600 Subject: Re: [Issue 2 - LL2] Explicit Additional Mechanism to disable v4LL Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Mika Liljeberg , Zeroconf To: Robert Elz From: Ted Lemon In-Reply-To: <19921.1044954310@munnari.OZ.AU> Message-Id: <99FA06FE-3DDB-11D7-A697-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > This only works if you're also willing to mandate some kind of stable > storage in every node supporting v4LL addresses. I don't think that's > reasonable. Can you give us an example of a device that you can buy today that autoconfigures on the network but does not have any nvram? If not, your definition of "not reasonable" is pretty extreme. The only thing I can think of is a mote, and I'm not even sure *those* are devoid of nvram. From owner-zeroconf@merit.edu Tue Feb 11 11:53:25 2003 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 LAA11262 for ; Tue, 11 Feb 2003 11:53:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 462709127E; Tue, 11 Feb 2003 11:56:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15C6091281; Tue, 11 Feb 2003 11:56:55 -0500 (EST) 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 EBAE19127E for ; Tue, 11 Feb 2003 11:56:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id D83285DE77; Tue, 11 Feb 2003 11:56:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id C00425DE06 for ; Tue, 11 Feb 2003 11:56:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 737EB13FEC; Tue, 11 Feb 2003 11:56:53 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 12302-03; Tue, 11 Feb 2003 11:56:52 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 6F89213FC3; Tue, 11 Feb 2003 11:56:52 -0500 (EST) Date: Tue, 11 Feb 2003 11:56:52 -0500 From: Keith Moore To: zeroconf@merit.edu Cc: moore@cs.utk.edu Subject: [LL10] applicability statement Message-Id: <20030211115652.23ea4d0d.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Spam-Status: No, hits=0.5 tagged_above=0.0 required=7.0 tests=SPAM_PHRASE_01_02 X-Spam-Level: X X-Razor-id: e4e2082faaed4e611da0712ef8257167bea76ff5 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm not at all sure how the requested change helps or what it's supposed to accomplish. But if I understand what is being proposed, it doesn't read right to me. If nothing else, the condition that is suggested is incorrectly formed. it should not be (ALL apps can accomodate dynamic addresses) OR (ALL apps have been modified) but instead ALL apps EITHER can inherently accomodate dynamic addresses OR have been modified to do so or more succinctly ALL apps can use dynamic addresses whether or not this required that they be modified. Even then, I fear this is missing the point. It is rare that networks are built to support only specific applications, and in general I'd claim that standardizing protocols to support special-purpose networks is not within IETF's scope. zeroconf should not claim to impose a new burden on applications by expecting them to adapt to dynamic addresses. this is not even feasible in all cases, and the IP architecture simply doesn't support changing addresses at a whim (even if you consider LLMNR and/or dynamic DNS part of the solution, which I don't) what we need to be saying is that due to ambiguity and stability issues LL addresses only work well for a subset of applications; that LL cannot be fixed to work better given the constraint that it be usable in ad hoc networks and the shortage of IPv4 addresses; that while some apps will work fine, other apps may or may not be able to work around these limitations; and as such, that LL addresses should only be used when stable, routable addresses are not available - such as on ad hoc, isolated networks. Keith From owner-zeroconf@merit.edu Tue Feb 11 11:58:09 2003 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 LAA11439 for ; Tue, 11 Feb 2003 11:58:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 343D691281; Tue, 11 Feb 2003 12:01:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC21691288; Tue, 11 Feb 2003 12:01:36 -0500 (EST) 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 0BD3E91281 for ; Tue, 11 Feb 2003 12:01:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id CF1245DE06; Tue, 11 Feb 2003 12:01:33 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id B14EE5DDFB for ; Tue, 11 Feb 2003 12:01:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 8969313FEC; Tue, 11 Feb 2003 12:01:33 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 12261-10; Tue, 11 Feb 2003 12:01:33 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id E7E9813FC3; Tue, 11 Feb 2003 12:01:32 -0500 (EST) Date: Tue, 11 Feb 2003 12:01:32 -0500 From: Keith Moore To: Markku Savela Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: [LL19 & LL1] Source Address selection Message-Id: <20030211120132.58eb22c2.moore@cs.utk.edu> In-Reply-To: <200302111011.h1BAB6FJ019656@burp.tkv.asdf.org> References: <200302101313.h1ADD3n21793@cichlid.adsl.duke.edu> <200302111011.h1BAB6FJ019656@burp.tkv.asdf.org> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 06f9850086992d5f34bd910aeaeaca69389114bd Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I disagree. first because v6 source selection is broken and we should not propogate this error; second because the issues are different for v4 and v6 source address selection. v6 does not have the backward compatibility problem that v4 does. > > In short: if LL19 is rejected, then LL1 is not acceptable either. > > > From: Thomas Narten > > > > Because we don't really have general address selection rules for > > IPv4, and we probably don't want to go there. > > I'm looking this issue from already implemented IPv6/IPv4 stack, which > does have address selection code (e.g. select LL source for LL > destination, even if it also has global IPv4 addresses). > > To avoid "code bloat", IPv4 is handled as true subset of IPv6, > exceptional handling IPv4 case is minimized. > > It is unacceptable that ZEROCONF RFC would make this suddenly > "illegal". > > The "SHOULD NOT" in requested change of [L1] is too strong. > > > > From owner-zeroconf@merit.edu Tue Feb 11 13:24:34 2003 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 NAA13926 for ; Tue, 11 Feb 2003 13:24:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 443A99129C; Tue, 11 Feb 2003 13:27:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15D5A912A2; Tue, 11 Feb 2003 13:27:54 -0500 (EST) 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 A74FB9129C for ; Tue, 11 Feb 2003 13:27:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 956065DE9A; Tue, 11 Feb 2003 13:27:51 -0500 (EST) 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 659395DE56 for ; Tue, 11 Feb 2003 13:27:51 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 8C1485995A; Tue, 11 Feb 2003 18:27:54 +0000 (GMT) Message-ID: <008c01c2d1fb$4907ce40$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" Cc: "Keith Moore" , "Erik Guttman" , References: Subject: Re: new issue: [LL26] source address selection is different from destination access Date: Tue, 11 Feb 2003 18:27:50 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Erik Guttman" > > Since the text will likely be in flux as we discuss other issues, how > about you leave the suggested text blank at this point and just include > an editorial instruction to 'divide the source address selection' and > 'destination access policy' text. I've send you a modified proposal. Philip From owner-zeroconf@merit.edu Tue Feb 11 13:42:29 2003 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 NAA14754 for ; Tue, 11 Feb 2003 13:42:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B9310912A4; Tue, 11 Feb 2003 13:43:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88379912A7; Tue, 11 Feb 2003 13:43:22 -0500 (EST) 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 05E9F912A4 for ; Tue, 11 Feb 2003 13:43:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id E872A5DF9E; Tue, 11 Feb 2003 13:43:18 -0500 (EST) 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 B7A7F5DD9B for ; Tue, 11 Feb 2003 13:43:18 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id A136759888 for ; Tue, 11 Feb 2003 18:43:21 +0000 (GMT) Message-ID: <009201c2d1fd$7187ee20$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" Subject: LL17 (also LL1 and LL26) Date: Tue, 11 Feb 2003 18:43:17 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I accept the principle of LL17 but not the text. The existing text is confusing because its use of "MAY choose to ARP" suggests that the host has an alternative to send the packet elsewhere. In practice sending to a router is expressly forbidden in the same section and the only alternative is to drop the packet. I don't think we can forbid this so changing the MAY to a MUST is not appropriate. The text proposed in LL17 also says "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." I don't believe that it is the intent of LL17 to specify source selection policy and that this text should not be proposed here - it is relevant to LL1. I propose that the text concerning destination access which addresses the issue of LL17 be separated from Source selection issues as per LL26 and changed to: "If either the source or the destination address of a packet to be sent is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), the host MUST NOT send the packet to any router for forwarding. In order to send the packet the host MUST ARP for the destination address and then send the packet directly to its destination on the same link." Philip From owner-zeroconf@merit.edu Tue Feb 11 14:40:56 2003 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 OAA16524 for ; Tue, 11 Feb 2003 14:40:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0DC2A912B6; Tue, 11 Feb 2003 14:41:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C54E3912B8; Tue, 11 Feb 2003 14:41:04 -0500 (EST) 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 B86FE912B6 for ; Tue, 11 Feb 2003 14:41:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id A6BD55DF9E; Tue, 11 Feb 2003 14:41:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 7AC8E5DE26 for ; Tue, 11 Feb 2003 14:41:00 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1BJfHaj004362; Tue, 11 Feb 2003 21:41:17 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1BJfE7R004361; Tue, 11 Feb 2003 21:41:14 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL19 From: Mika Liljeberg To: Keith Moore Cc: philip@engarts.com, zeroconf@merit.edu In-Reply-To: <20030211082040.747f9941.moore@cs.utk.edu> References: <028601c2d123$ab78dac0$131010ac@aldebaran> <1044908026.29380.76.camel@devil> <004801c2d14c$0445d400$131010ac@aldebaran> <1044914496.31092.95.camel@devil> <20030210193125.157027dc.moore@cs.utk.edu> <1044948248.1377.15.camel@devil> <20030211082040.747f9941.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044992473.1377.61.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 11 Feb 2003 21:41:14 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Keith, Philip, > > Referrals just pass addresses around. The question is, where do these > > address originate? > > from various places. Neither of you is following the logic. Think recursively. What I'm trying to say is that you should, as a mental exercise, track the path of a v4LL address through its referral chain, whatever it may be, back to its place origin. The place of origin can only be the node that generated that address. This is important: the origin is a node that is governed by this specification. Why then, if it is participating in a routed network, did it give out its v4LL address? If it was forced to do that it must be a v4LL-only node, otherwise it would have given out its routable address. This observation is in conflict with my assertion that all nodes participating in a routed network should acquire a routable address. What I'm trying to say is that the rules I'm proposing are internally consistent, unless you choose to relax one them. Of course, you've already made up your minds to do that, so it doesn't seem likely that I will convince you otherwise. As for how to "return routables first", that is an implementation issue but we can give some guidance, since we've already established that the place of origin is a node governed by this specification. A system implementing v4LL addressing should have APIs that consisntently work this way. One example of this would be to put LLMNR and normal DNS resolution under a unified API and return routable addresses first. I'm well aware that the above cannot be done in the general case and that there are legacy issues that make it unfeasible in some cases. However, I feel that it can be done in the common case, which is pretty good. The rules proposed by LL19 ensure that even if a v4LL address is propagated beyond it's scope, the failure mode is usually such that an immediate "destination unreachable" error is generated. This is not the case if direct communication between v4LL addresses and routable is allowed. So, I'm not pretending to solve anything in the general case. Neither is anyone else. I'm simply proposing that these stricter rules would result in: - clarity and simplicity of implementation - more obvious failure modes MikaL P.S. I'm not going to be expounding this any more. It's obvious that I'm beating a dead horse and that the people who got to her first had far bigger sticks than I. From owner-zeroconf@merit.edu Tue Feb 11 14:41:05 2003 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 OAA16545 for ; Tue, 11 Feb 2003 14:41:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F392C912B8; Tue, 11 Feb 2003 14:43:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4867912C3; Tue, 11 Feb 2003 14:43:54 -0500 (EST) 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 BB6F7912B8 for ; Tue, 11 Feb 2003 14:43:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id A7B995DEE2; Tue, 11 Feb 2003 14:43:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 8F0F45DE77 for ; Tue, 11 Feb 2003 14:43:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 4DD6F1401F; Tue, 11 Feb 2003 14:43:49 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 04061-02; Tue, 11 Feb 2003 14:43:48 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id AD28F14019; Tue, 11 Feb 2003 14:43:48 -0500 (EST) Date: Tue, 11 Feb 2003 14:43:48 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL19 Message-Id: <20030211144348.1a981bc9.moore@cs.utk.edu> In-Reply-To: <1044992473.1377.61.camel@devil> References: <028601c2d123$ab78dac0$131010ac@aldebaran> <1044908026.29380.76.camel@devil> <004801c2d14c$0445d400$131010ac@aldebaran> <1044914496.31092.95.camel@devil> <20030210193125.157027dc.moore@cs.utk.edu> <1044948248.1377.15.camel@devil> <20030211082040.747f9941.moore@cs.utk.edu> <1044992473.1377.61.camel@devil> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 46ac4b598d0711b873485d66b7cfebe062e8f743 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > > Referrals just pass addresses around. The question is, where do > > > these address originate? > > > > from various places. > > Neither of you is following the logic. Think recursively. > > What I'm trying to say is that you should, as a mental exercise, track > the path of a v4LL address through its referral chain, whatever it may > be, back to its place origin. The place of origin can only be the node > that generated that address. This is important: the origin is a node > that is governed by this specification. no it is not. the origin is some application that might or might not be aware of this specification at all. we cannot retroactively impose requirements on existing applications, and I would strongly object to trying to impose such requirements on new applications for the sake of being able to use LL source addresses when they're not needed. since your major premise is false, the rest of your argument does not hold. isn't this horse dead yet? Keith From owner-zeroconf@merit.edu Tue Feb 11 14:43:03 2003 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 OAA16599 for ; Tue, 11 Feb 2003 14:43:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6BD31912BB; Tue, 11 Feb 2003 14:46:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A847A912BA; Tue, 11 Feb 2003 14:46:04 -0500 (EST) 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 552CB912BC for ; Tue, 11 Feb 2003 14:45:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5CB655DE8E; Tue, 11 Feb 2003 14:45:35 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id BD40D5DE9A for ; Tue, 11 Feb 2003 14:45:19 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1BJjtaj004381; Tue, 11 Feb 2003 21:45:56 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1BJjqSn004380; Tue, 11 Feb 2003 21:45:52 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs [LL19] From: Mika Liljeberg To: Robert Elz Cc: zeroconf@merit.edu In-Reply-To: <19910.1044954202@munnari.OZ.AU> References: <1044918002.31088.163.camel@devil> <1044810580.21186.302.camel@devil> <1044803577.21383.233.camel@devil> <1044793681.21186.107.camel@devil> <1044787452.11519.93.camel@devil> <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> <3689.1044783115@munnari.OZ.AU> <4300.1044789975@munnari.OZ.AU> <4798.1044798098@munnari.OZ.AU> <5583.1044805928@munnari.OZ.AU> <12433.1044872260@munnari.OZ.AU> <19910.1044954202@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044992751.1374.63.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 11 Feb 2003 21:45:51 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2003-02-11 at 11:03, Robert Elz wrote: > How common it is isn't really relevant, it needs to be able to work for > when it is required. Perfect is the works enemy of good. MikaL From owner-zeroconf@merit.edu Tue Feb 11 14:48:59 2003 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 OAA16718 for ; Tue, 11 Feb 2003 14:48:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 57676912BA; Tue, 11 Feb 2003 14:52:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 20E4A912BC; Tue, 11 Feb 2003 14:52:35 -0500 (EST) 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 10E8E912BA for ; Tue, 11 Feb 2003 14:52:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id E95925DE9A; Tue, 11 Feb 2003 14:52:33 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 77C1F5DE77 for ; Tue, 11 Feb 2003 14:52:32 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1BJr6aj004412; Tue, 11 Feb 2003 21:53:06 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1BJr4x8004411; Tue, 11 Feb 2003 21:53:04 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Proposed text for LL2 From: Mika Liljeberg To: Keith Moore Cc: Robert Elz , Erik.Guttman@Sun.COM, zeroconf@merit.edu In-Reply-To: <20030211085137.2918d9c7.moore@cs.utk.edu> References: <20030210122608.50d3d478.moore@cs.utk.edu> <1044796483.21383.156.camel@devil> <19889.1044953652@munnari.OZ.AU> <20030211085137.2918d9c7.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044993183.1374.69.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 11 Feb 2003 21:53:04 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2003-02-11 at 15:51, Keith Moore wrote: > > | Any host that attempts to automatically configure an address MUST (or > > | at least SHOULD) initially, and at intervals thereafter, attempt to get > > | a routable address/netmask and a default route from DHCP and if such > > | are obtained, use these in preference to v4LL configuration. > > > > Hmm - I agree with this (except I wouldn't require DHCP, just "a mechanism" > > which we all know, for all practical purposes is going to be DHCP these > > days, but RARP was used once, etc...) > > well, we need a uniform mechanism for all of these devices (else networks have > to guess as to which mechanisms are necessary), and DHCP is the most likely > candidate. OTOH, RARP would almost be good enough. The main objection I have against a DHCP based mechanism is that it creates a dependency between the DHCP client and the v4LL implementation. If a truly universal solution is required, it should be an integral part of the v4LL specification. Your "magic ARP reply" idea might be palatable, if it were specified in these terms. MikaL From owner-zeroconf@merit.edu Tue Feb 11 15:01:49 2003 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 PAA17097 for ; Tue, 11 Feb 2003 15:01:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6B555912C4; Tue, 11 Feb 2003 15:05:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43E4A912BD; Tue, 11 Feb 2003 15:04:56 -0500 (EST) 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 946BE912C0 for ; Tue, 11 Feb 2003 15:03:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 74FC65DE77; Tue, 11 Feb 2003 15:03:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 35A215DE8E for ; Tue, 11 Feb 2003 15:02:28 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1BK2saj004478; Tue, 11 Feb 2003 22:02:55 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1BK2pjk004477; Tue, 11 Feb 2003 22:02:51 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL19 From: Mika Liljeberg To: Keith Moore Cc: philip@engarts.com, zeroconf@merit.edu In-Reply-To: <20030211144348.1a981bc9.moore@cs.utk.edu> References: <028601c2d123$ab78dac0$131010ac@aldebaran> <1044908026.29380.76.camel@devil> <004801c2d14c$0445d400$131010ac@aldebaran> <1044914496.31092.95.camel@devil> <20030210193125.157027dc.moore@cs.utk.edu> <1044948248.1377.15.camel@devil> <20030211082040.747f9941.moore@cs.utk.edu> <1044992473.1377.61.camel@devil> <20030211144348.1a981bc9.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044993770.1374.73.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 11 Feb 2003 22:02:50 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2003-02-11 at 21:43, Keith Moore wrote: > > > > Referrals just pass addresses around. The question is, where do > > > > these address originate? > > > > > > from various places. > > > > Neither of you is following the logic. Think recursively. > > > > What I'm trying to say is that you should, as a mental exercise, track > > the path of a v4LL address through its referral chain, whatever it may > > be, back to its place origin. The place of origin can only be the node > > that generated that address. This is important: the origin is a node > > that is governed by this specification. > > no it is not. the origin is some application that might or might not be > aware of this specification at all. we cannot retroactively impose > requirements on existing applications, and I would strongly object to > trying to impose such requirements on new applications for the sake of > being able to use LL source addresses when they're not needed. I addressed this in the part you didn't read. > since your major premise is false, the rest of your argument does not > hold. > > isn't this horse dead yet? Last word. There, I said it. MikaL From owner-zeroconf@merit.edu Tue Feb 11 15:05:39 2003 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 PAA17164 for ; Tue, 11 Feb 2003 15:05:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 565C791302; Tue, 11 Feb 2003 15:05:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2234912BF; Tue, 11 Feb 2003 15:04:53 -0500 (EST) 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 32A30912BD for ; Tue, 11 Feb 2003 15:02:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 151E05DE77; Tue, 11 Feb 2003 15:02:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id EFAA15DDCA for ; Tue, 11 Feb 2003 15:02:47 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id C0CF31401F; Tue, 11 Feb 2003 15:02:47 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 05639-09; Tue, 11 Feb 2003 15:02:47 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 2C79C14019; Tue, 11 Feb 2003 15:02:47 -0500 (EST) Date: Tue, 11 Feb 2003 15:02:46 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, Erik.Guttman@Sun.COM, zeroconf@merit.edu Subject: Re: Proposed text for LL2 Message-Id: <20030211150246.0093dd54.moore@cs.utk.edu> In-Reply-To: <1044993183.1374.69.camel@devil> References: <20030210122608.50d3d478.moore@cs.utk.edu> <1044796483.21383.156.camel@devil> <19889.1044953652@munnari.OZ.AU> <20030211085137.2918d9c7.moore@cs.utk.edu> <1044993183.1374.69.camel@devil> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 6fb0b82654cdb9af019a53f125c9d8a5ae785879 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > well, we need a uniform mechanism for all of these devices (else > > networks have to guess as to which mechanisms are necessary), and > > DHCP is the most likely candidate. OTOH, RARP would almost be good > > enough. > > The main objection I have against a DHCP based mechanism is that it > creates a dependency between the DHCP client and the v4LL > implementation. I think we already have a dependency on DHCP, in practical terms. The LLv4 spec just needs to reflect that. It's not clear to me that the v4LL code needs to know about DHCP, though it does need to be able to tell if there's a routable address configured for an interface. It doesn't matter how it got there. > If a truly universal solution is required, it should be an integral > part of the v4LL specification. Your "magic ARP reply" idea might be > palatable, if it were specified in these terms. I need to work on that some more. Keith From owner-zeroconf@merit.edu Tue Feb 11 15:13:17 2003 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 PAA17318 for ; Tue, 11 Feb 2003 15:13:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC337912BD; Tue, 11 Feb 2003 15:16:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC08F912BC; Tue, 11 Feb 2003 15:16:35 -0500 (EST) 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 BCE9E912BD for ; Tue, 11 Feb 2003 15:16:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7787D5DEE2; Tue, 11 Feb 2003 15:16:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 011125DE9A for ; Tue, 11 Feb 2003 15:16:09 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1BKGeaj004536; Tue, 11 Feb 2003 22:16:40 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1BKGdnl004535; Tue, 11 Feb 2003 22:16:39 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Proposed text for LL2 From: Mika Liljeberg To: Keith Moore Cc: kre@munnari.OZ.AU, Erik.Guttman@Sun.COM, zeroconf@merit.edu In-Reply-To: <20030211150246.0093dd54.moore@cs.utk.edu> References: <20030210122608.50d3d478.moore@cs.utk.edu> <1044796483.21383.156.camel@devil> <19889.1044953652@munnari.OZ.AU> <20030211085137.2918d9c7.moore@cs.utk.edu> <1044993183.1374.69.camel@devil> <20030211150246.0093dd54.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1044994598.1374.85.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 11 Feb 2003 22:16:39 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2003-02-11 at 22:02, Keith Moore wrote: > > > well, we need a uniform mechanism for all of these devices (else > > > networks have to guess as to which mechanisms are necessary), and > > > DHCP is the most likely candidate. OTOH, RARP would almost be good > > > enough. > > > > The main objection I have against a DHCP based mechanism is that it > > creates a dependency between the DHCP client and the v4LL > > implementation. There doesn't need to be. There shouldn't be. That would be plain bad design. I think this can be solved without introducing a dependency. > I think we already have a dependency on DHCP, in practical terms. > The LLv4 spec just needs to reflect that. > > It's not clear to me that the v4LL code needs to know about DHCP, > though it does need to be able to tell if there's a routable address > configured for an interface. It doesn't matter how it got there. Using the presence of a routable address on the interface is not an acceptable signal to turn off v4LL. A node should be allowed to have both a v4LL and a routable address on the same interface, if that is how it is configured. In this, several people actually agree with me. > > If a truly universal solution is required, it should be an integral > > part of the v4LL specification. Your "magic ARP reply" idea might be > > palatable, if it were specified in these terms. > > I need to work on that some more. Great. MikaL From owner-zeroconf@merit.edu Tue Feb 11 17:16:05 2003 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 RAA20197 for ; Tue, 11 Feb 2003 17:16:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CC6A69126A; Tue, 11 Feb 2003 17:19:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E2829126B; Tue, 11 Feb 2003 17:19:39 -0500 (EST) 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 399689126A for ; Tue, 11 Feb 2003 17:19:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C9C25DE0C; Tue, 11 Feb 2003 17:19:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by segue.merit.edu (Postfix) with ESMTP id EA2B85DD9C for ; Tue, 11 Feb 2003 17:19:37 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18iijj-0001wV-00; Tue, 11 Feb 2003 14:18:43 -0800 Date: Tue, 11 Feb 2003 17:16:21 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, Erik.Guttman@Sun.COM, zeroconf@merit.edu Subject: Re: Proposed text for LL2 Message-Id: <20030211171621.36b92fca.moore@cs.utk.edu> In-Reply-To: <1044994598.1374.85.camel@devil> References: <20030210122608.50d3d478.moore@cs.utk.edu> <1044796483.21383.156.camel@devil> <19889.1044953652@munnari.OZ.AU> <20030211085137.2918d9c7.moore@cs.utk.edu> <1044993183.1374.69.camel@devil> <20030211150246.0093dd54.moore@cs.utk.edu> <1044994598.1374.85.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Using the presence of a routable address on the interface is not an > acceptable signal to turn off v4LL. A node should be allowed to have > both a v4LL and a routable address on the same interface, if that is how > it is configured. In this, several people actually agree with me. well, I probably do too, if it's explicitly configured. I guess the point is that the coupling between LL and DHCP need not be terribly complex. But DHCP was here first, and is widely deployed, and is much more generally applicable than LL. If LL needs to know about DHCP, so be it. That's better than forcing applications to know about network topology and scoped addresses, etc. From owner-zeroconf@merit.edu Tue Feb 11 17:41:41 2003 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 RAA20606 for ; Tue, 11 Feb 2003 17:41:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 106FB9126B; Tue, 11 Feb 2003 17:45:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97C149126E; Tue, 11 Feb 2003 17:45:05 -0500 (EST) 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 AB03D9126B for ; Tue, 11 Feb 2003 17:45:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id A8EBF5DFD7; Tue, 11 Feb 2003 17:45:02 -0500 (EST) 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 9B85A5DE77 for ; Tue, 11 Feb 2003 17:45:01 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 947485989B; Tue, 11 Feb 2003 22:45:05 +0000 (GMT) Message-ID: <00b501c2d21f$362e2c50$131010ac@aldebaran> From: "Philip Nye" To: "Mika Liljeberg" , "Keith Moore" Cc: References: <028601c2d123$ab78dac0$131010ac@aldebaran> <1044908026.29380.76.camel@devil> <004801c2d14c$0445d400$131010ac@aldebaran> <1044914496.31092.95.camel@devil> <20030210193125.157027dc.moore@cs.utk.edu> <1044948248.1377.15.camel@devil> <20030211082040.747f9941.moore@cs.utk.edu> <1044992473.1377.61.camel@devil> Subject: Re: LL19 Date: Tue, 11 Feb 2003 22:45:01 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > What I'm trying to say is that you should, as a mental exercise, track > the path of a v4LL address through its referral chain, whatever it may > be, back to its place origin. The place of origin can only be the node > that generated that address. This is important: the origin is a node > that is governed by this specification. You are right to this extent: it all starts with some process on the node which uses a LL address interrogating some other process or structure in the same node to say "what is my IP address" (I say *probably* because it is also possible that another local host has inferred the address from ARP information) - to that extent, the node is in control. But so what? Host A then communicates with host B which then knows A's address and vice versa. One of these hosts might implement some sort of service discovery or name cache, it could be running a collaborative application or putting links on web pages or something. Sooner or later (probably sooner) somebody who doesn't understand the special rules will get hold of the address, or it will get passed off the link or all sorts of other horrible things will happen. In general this is all highly desirable and what makes IP so attractive. The way to minimise the damage is simply to minimise the duration and number of hosts around which use LL addresses when the link is not isolated. If one host on a link has only a LL address then under your rule all the others will need one too. Without LL19 then there is only the one address around to foul things up. Coexistence of LL and routable addresses on a routed network is unavoidable, but the spec should do what it can to make it a transitional case. Philip From owner-zeroconf@merit.edu Tue Feb 11 21:47:59 2003 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 VAA26026 for ; Tue, 11 Feb 2003 21:47:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF6B691207; Tue, 11 Feb 2003 21:51:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C15E69120F; Tue, 11 Feb 2003 21:51:32 -0500 (EST) 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 CB6E391207 for ; Tue, 11 Feb 2003 21:51:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD0E65E013; Tue, 11 Feb 2003 21:51:31 -0500 (EST) 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 34BFA5E00D for ; Tue, 11 Feb 2003 21:51:31 -0500 (EST) 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 h1C2pUI28418 for ; Tue, 11 Feb 2003 18:51:30 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 11 Feb 2003 18:51:28 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h1C2pUs28236 for ; Tue, 11 Feb 2003 18:51:30 -0800 (PST) Message-Id: <200302120251.h1C2pUs28236@scv1.apple.com> Subject: *** Reminder: Open Issues are LL6 LL8 LL10 LL11 LL16 LL17 LL19 Date: Tue, 11 Feb 2003 18:51:30 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Reminder: Open Issues are: LL6 Add security considerations note regarding wireless LANs LL8 Is additional Routing Considerations text needed LL10 Add warnings to applicability statement LL11 Add security consideration for the threat where an attacker forces address reconfiguration LL16 Split references LL17 Hosts with configured addresses MUST ARP for v4 LL addresses LL19 Do not use v4LL source address to non-v4LL destinations In the interest of sanity for all involved, please limit current discussion to these open issues. In particular, LL2 is not currently open for discussion. As Keith Moore said, we already have plenty of issues open for discussion without trying to discuss LL2 at the same time as well. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Feb 11 21:49:02 2003 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 VAA26074 for ; Tue, 11 Feb 2003 21:49:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 25FC29120F; Tue, 11 Feb 2003 21:52:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9F5791212; Tue, 11 Feb 2003 21:52:35 -0500 (EST) 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 123F39120F for ; Tue, 11 Feb 2003 21:52:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id F20E65DE24; Tue, 11 Feb 2003 21:52:34 -0500 (EST) 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 7902E5DE17 for ; Tue, 11 Feb 2003 21:52:34 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id h1C2qYI16897 for ; Tue, 11 Feb 2003 18:52:34 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 11 Feb 2003 18:52:33 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h1C2qXQ19910 for ; Tue, 11 Feb 2003 18:52:33 -0800 (PST) Message-Id: <200302120252.h1C2qXQ19910@scv2.apple.com> Subject: LL6 Add security considerations note regarding wireless LANs Date: Tue, 11 Feb 2003 18:52:33 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk I support the proposed text: The existence of local links without physical security, such as LANs with attached wireless base stations, means that expecting all local links to be secure enough that normal precautions can be dispensed with is an extremely dangerous practice, which will expose users to considerable risks. Stuart From owner-zeroconf@merit.edu Tue Feb 11 21:50:56 2003 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 VAA26118 for ; Tue, 11 Feb 2003 21:50:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5CCBA91212; Tue, 11 Feb 2003 21:54:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26A0C91214; Tue, 11 Feb 2003 21:54:31 -0500 (EST) 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 3ADD791212 for ; Tue, 11 Feb 2003 21:54:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 19D1E5DEBC; Tue, 11 Feb 2003 21:54:30 -0500 (EST) 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 937FC5DE6E for ; Tue, 11 Feb 2003 21:54:29 -0500 (EST) 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 h1C2sSI28931 for ; Tue, 11 Feb 2003 18:54:28 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 11 Feb 2003 18:54:28 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h1C2sRf29309 for ; Tue, 11 Feb 2003 18:54:28 -0800 (PST) Message-Id: <200302120254.h1C2sRf29309@scv3.apple.com> Subject: LL8 Is additional Routing Considerations text needed Date: Tue, 11 Feb 2003 18:54:28 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Robert Elz proposed some good text which I support: > Routing Protocols > > The link local address block (169.254/16) MUST NOT be > included as a reachable prefix in any dynamic routing protocol. > Subnets of that address block (which should not exist - see sect N.M) > MUST NOT be included either. Stuart From owner-zeroconf@merit.edu Tue Feb 11 22:09:37 2003 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 WAA26428 for ; Tue, 11 Feb 2003 22:09:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC27391214; Tue, 11 Feb 2003 22:13:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C16791216; Tue, 11 Feb 2003 22:13:10 -0500 (EST) 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 882E691214 for ; Tue, 11 Feb 2003 22:13:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E27A5DE24; Tue, 11 Feb 2003 22:13:09 -0500 (EST) 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 E85E35DE03 for ; Tue, 11 Feb 2003 22:13:08 -0500 (EST) 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 h1C3D8I01934 for ; Tue, 11 Feb 2003 19:13:08 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 11 Feb 2003 19:13:08 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h1C3D7Q27321 for ; Tue, 11 Feb 2003 19:13:07 -0800 (PST) Message-Id: <200302120313.h1C3D7Q27321@scv2.apple.com> Subject: LL10 Add warnings to applicability statement Date: Tue, 11 Feb 2003 19:13:08 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk I cannot support the proposed change: >IPv4 link-local addresses are therefore applicable if it is either >known that all applications that are used can accomondate this >change in the properties of the IP addresses, or all applications >that are used have been modified to account for dynamic addresses, >their limited scope and their potential ambiguity. If you think carefully about what this says, it outlaws what Apple and Microsoft have been doing since 1998, and anything that we could conceivably do in the future. This statement says that IPv4 link-local addresses are only applicable in cases where you can make a definite statement about *all* applications running on that OS. In the case of a general purpose OS like Mac OS, Windows, Linux, or Solaris, this means that IPv4 link-local addresses are *never* applicable because the OS vendor does not even know about every third-party application running on that OS. The whole rationale behind IPv4LL is that effectively *ALL* application protocols can function usefully with link-local addresses on a single isolated link. A wealth of useful IP application software exists today. Connect two laptops with an Ethernet cable and give them no IP addresses, and that vast wealth of software is worthless. Connect two laptops with an Ethernet cable and give them unique IP addresses, and that wealth of software comes back to life and can do useful things for the user. Stuart From owner-zeroconf@merit.edu Tue Feb 11 22:10:05 2003 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 WAA26443 for ; Tue, 11 Feb 2003 22:10:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D92D191216; Tue, 11 Feb 2003 22:13:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A702C91218; Tue, 11 Feb 2003 22:13:39 -0500 (EST) 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 C365A91216 for ; Tue, 11 Feb 2003 22:13:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id A198F5DE03; Tue, 11 Feb 2003 22:13:38 -0500 (EST) 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 139165DE17 for ; Tue, 11 Feb 2003 22:13:38 -0500 (EST) 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 h1C3DbI19282 for ; Tue, 11 Feb 2003 19:13:37 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 11 Feb 2003 19:13:36 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h1C3Dbs06803 for ; Tue, 11 Feb 2003 19:13:37 -0800 (PST) Message-Id: <200302120313.h1C3Dbs06803@scv1.apple.com> Subject: LL10 Add warnings to applicability statement Date: Tue, 11 Feb 2003 19:13:37 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Keith Moore proposed some good text which I support: Addresses in the range 169.254/16 are reserved for use as link-local addresses that are allocated and configured according to this specification or subsequent revisions. Under normal conditions, users should not manually configure interfaces with such addresses, nor should DHCP servers be configured to return such addresses. Stuart From owner-zeroconf@merit.edu Tue Feb 11 22:28:16 2003 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 WAA26644 for ; Tue, 11 Feb 2003 22:28:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9C28F9121C; Tue, 11 Feb 2003 22:31:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65F1891221; Tue, 11 Feb 2003 22:31:42 -0500 (EST) 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 497CC9121C for ; Tue, 11 Feb 2003 22:31:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 327BC5E008; Tue, 11 Feb 2003 22:31:41 -0500 (EST) 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 AAF415DF84 for ; Tue, 11 Feb 2003 22:31:40 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id h1C3VeI22171 for ; Tue, 11 Feb 2003 19:31:40 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 11 Feb 2003 19:31:39 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h1C3VdQ02787 for ; Tue, 11 Feb 2003 19:31:39 -0800 (PST) Message-Id: <200302120331.h1C3VdQ02787@scv2.apple.com> Subject: LL11 Add security consideration for the threat where an attacker forces address reconfiguration Date: Tue, 11 Feb 2003 19:31:40 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Erik Nordmark proposed: >A host implementing IPv4 link-local configuration has the >additional vulnerability to selective reconfiguration and >disruption. It is possible for an on-link attacker to issue ARP >packets which would cause a host to break all its connections by >switching to a new address. The attacker could force the host >implementing IPv4 link-local configuration to select certain >addresses, or prevent it from ever completing address selection. >This is a distinct threat from that posed by fraudulent ARPs, >described in the preceding paragraph. I disagree that this is a materially different threat from the normal chaos that ensues when two hosts are accidentally given the same IP address. In an on-link attacker spoofs ARP packets, then in reality you will lose all your TCP connections to resets and timeouts, even if you do refuse to pick a new address. The difference is that if you refuse to pick a new address, you will be unable to establish any reliable new TCP connections either. If you doubt this, open a bunch of telnet or ssh connections, and then set another local machine to the same IP address and see what happens. (Note: don't try to do this with a Mac, because Macs implement IPv4ACD to guard against accidentally or deliberately setting two hosts to the same IP address. Using some other OS you should be able to set two machines to the same IP address and see what happens.) The reason I am reluctant to support the proposed change is that I do not feel it meets one of the important requirements for text in an RFC: namely that it help the reader come to a true and accurate understanding of the relevant issues. As written, the proposed text overstates the vulnerability of IPv4LL to this kind of attack, while at the same time implying that manually-configured and DHCP-configured hosts are less vulnerable to the effects of the very same attack (or accidental misconfiguration). To imply this would be, I feel, a disservice to the reader. Stuart From owner-zeroconf@merit.edu Tue Feb 11 22:31:01 2003 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 WAA26784 for ; Tue, 11 Feb 2003 22:31:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D7F8A91221; Tue, 11 Feb 2003 22:34:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B35291227; Tue, 11 Feb 2003 22:34:31 -0500 (EST) 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 D05BC91226 for ; Tue, 11 Feb 2003 22:33:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id B928F5E008; Tue, 11 Feb 2003 22:33:37 -0500 (EST) 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 3F87F5DE17 for ; Tue, 11 Feb 2003 22:33:37 -0500 (EST) 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 h1C3XaI04589 for ; Tue, 11 Feb 2003 19:33:36 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 11 Feb 2003 19:33:36 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h1C3Xaf11872 for ; Tue, 11 Feb 2003 19:33:36 -0800 (PST) Message-Id: <200302120333.h1C3Xaf11872@scv3.apple.com> Subject: LL16 Split references Date: Tue, 11 Feb 2003 19:33:36 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Keith Moore wrote: >If DHCP ends up being required (as I believe it should) then RFC 2131 >becomes a normative reference. I hinted last week about devices that use IPv4LL for communication between components inside a single computer chassis. This week Apple publicly announced the first of these devices. Xserve RAID includes hot-swappable modules. These modules have to communicate internally. How do they communicate? Via PCI? No. they communicate via Ethernet, using IPv4LL addresses. If you think that Apple did this as a publicity stunt for the sake of promoting IPv4LL, let me correct that misunderstanding. The hardware teams at Apple are driven my making the best hardware at the lowest price. If a technology doesn't make sense, they're certainly not going to put it in just to please me. The hardware team chose IPv4LL/Ethernet for the internal communication bus for a good reason. The part they were using included an Ethernet port on the same silicon. When they were considering what internal communication technology to put in the design, someone (not me) pointed out this spare Ethernet port that they were not planning to use. With a little bit of software, they got their internal communication bus for free, instead of having to add some other interconnect to the circuit board. Now, getting back to LL16, it makes no sense to mandate that these RAID controller modules MUST implement a DHCP client, when they are on a 19-inch Ethernet network, inside a single computer chassis, and we *know* it will never have a DHCP server on it. Stuart From owner-zeroconf@merit.edu Tue Feb 11 22:31:18 2003 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 WAA26839 for ; Tue, 11 Feb 2003 22:31:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3508291226; Tue, 11 Feb 2003 22:34:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F4DB91228; Tue, 11 Feb 2003 22:34:31 -0500 (EST) 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 30A0091221 for ; Tue, 11 Feb 2003 22:32:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 07DD05E008; Tue, 11 Feb 2003 22:32:19 -0500 (EST) 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 825A45DEC2 for ; Tue, 11 Feb 2003 22:32:18 -0500 (EST) 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 h1C3WII04333 for ; Tue, 11 Feb 2003 19:32:18 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 11 Feb 2003 19:32:17 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h1C3WHQ02980 for ; Tue, 11 Feb 2003 19:32:17 -0800 (PST) Message-Id: <200302120332.h1C3WHQ02980@scv2.apple.com> Subject: LL11 Add security consideration for the threat where an attacker forces address reconfiguration Date: Tue, 11 Feb 2003 19:32:18 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Robert Elz suggested that a host send TCP resets before giving up its address. This sounds like a good idea, and I would not oppose this new text. However, I do not agree with the entire analysis. Robert Elz wrote: >The issue of course, is that on many net technologies where a node >has the ability to issue ARP packets, nodes also have the ability >to snoop packets. > >Such a node can, if it desires, watch a TCP connection be >established, go through the authentication phase, and then start >sending (many) ARP packets claiming to own the address of the >system which just authenticated itself. That system (following >section 2.5) reconfigures to a new address, leaving the old one >available for the node that usurped it. That node has all the >information it needs (sequence numbers, port numbers, ...) to >successfully masquerade as the node that was previously >authenticated. > >This is a very serious (and new) security issue posed by using LL >addresses as demanded in section 2.5. (new in the sense that it >doesn't exist in earlier IP stacks - not new to this e-mail of >course). I disagee that it is a new threat. Unicast ARP poisoning can be used today to hijack a TCP connection without the victim even knowing it. (The intruder poisons the peer's ARP cache via a spoof unicast reply; the victim never even sees the spoof unicast reply so it never knows why it stopped receiving packets. The intruder can even forward modified packets to keep the connection apparently alive, so the victim in fact may not stop receiving packets.) Stuart From owner-zeroconf@merit.edu Tue Feb 11 22:31:49 2003 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 WAA26921 for ; Tue, 11 Feb 2003 22:31:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 79D0D91227; Tue, 11 Feb 2003 22:35:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43A5191228; Tue, 11 Feb 2003 22:35:17 -0500 (EST) 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 57D9791227 for ; Tue, 11 Feb 2003 22:35:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F2FE5DEC2; Tue, 11 Feb 2003 22:35:16 -0500 (EST) 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 BABC45DE17 for ; Tue, 11 Feb 2003 22:35:15 -0500 (EST) 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 h1C3ZFI23016 for ; Tue, 11 Feb 2003 19:35:15 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 11 Feb 2003 19:35:13 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h1C3ZEs13415 for ; Tue, 11 Feb 2003 19:35:14 -0800 (PST) Message-Id: <200302120335.h1C3ZEs13415@scv1.apple.com> Subject: LL17 Hosts with configured addresses MUST ARP for v4 LL addresses Date: Tue, 11 Feb 2003 19:35:15 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Thomas Narten pointed out the ambiguity in the following text: > 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 MUST 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 the destination > on the same physical link. In many network stacks, achieving this > functionality may be as simple as adding a routing table entry > indicating that 169.254/16 is directly reachable on the local link. > The host MUST NOT send a packet with a link-local destination address > to any router for forwarding. I propose the following text instead: 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 SHOULD use an appropriate routable source IP address, if it has one. In either case, the host MUST use ARP in the usual way to map the destination IP address to a destination hardware address address, and then send its packet directly to the destination on the same physical link. In many network stacks, achieving this functionality may be as simple as adding a routing table entry indicating that 169.254/16 is directly reachable on the local link. The host MUST NOT send a packet with a link-local destination address to any router for forwarding. Some have proposed splitting the text into two sections. I do not think this is necessary, but I would not oppose it. Stuart From owner-zeroconf@merit.edu Tue Feb 11 22:32:26 2003 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 WAA26999 for ; Tue, 11 Feb 2003 22:32:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1E8CD91228; Tue, 11 Feb 2003 22:35:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E69D091229; Tue, 11 Feb 2003 22:35:53 -0500 (EST) 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 02AF291228 for ; Tue, 11 Feb 2003 22:35:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id E354D5E008; Tue, 11 Feb 2003 22:35:52 -0500 (EST) 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 641AD5DEC2 for ; Tue, 11 Feb 2003 22:35:52 -0500 (EST) 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 h1C3ZpI04792 for ; Tue, 11 Feb 2003 19:35:51 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 11 Feb 2003 19:35:50 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h1C3Zps13597 for ; Tue, 11 Feb 2003 19:35:51 -0800 (PST) Message-Id: <200302120335.h1C3Zps13597@scv1.apple.com> Subject: LL19 Do not use v4LL source address to non-v4LL destinations Date: Tue, 11 Feb 2003 19:35:52 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Bernard Aboba made some good arguments here, in my opinion, about why the perceived danger is pretty much a red-herring. In reality, communication between routable and LL will only occur commonly between compatible hosts (and in that case, those compatible hosts derive worthwhile benefit from being able to communicate). In practice, Mac OS 9 and Mac OS X have both implemented communication between routable and LL for a long time, and no problems have been observed or reported. Robert Elz gave an example of a user manually typing IP addresses on the command line. I do not believe that anything in this document changes the fact that when a user manually types IP addresses on the command line, they may type an address that for whatever reason fails to achieve successful communication, and may result in wasted packets being sent. Ten years ago, if I walked into your office with my laptop manually configured to 36.186.224.17, and you typed "telnet 36.186.224.17" on your computer, then your computer would send wasted packets all the way to Stanford, and successful communication would not be established. I agree that sending wasted packets into the Internet is not a good thing, but I think that we should also be careful not to regard the mere potential for an occasional wasted packet as a monumental disaster. I oppose LL19. Stuart From owner-zeroconf@merit.edu Tue Feb 11 22:33:07 2003 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 WAA27079 for ; Tue, 11 Feb 2003 22:33:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E431091229; Tue, 11 Feb 2003 22:36:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9F699122B; Tue, 11 Feb 2003 22:36:41 -0500 (EST) 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 C032E91229 for ; Tue, 11 Feb 2003 22:36:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD98B5E011; Tue, 11 Feb 2003 22:36:40 -0500 (EST) 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 29C2E5E008 for ; Tue, 11 Feb 2003 22:36:40 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id h1C3adI23206 for ; Tue, 11 Feb 2003 19:36:39 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 11 Feb 2003 19:36:39 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h1C3adf12665 for ; Tue, 11 Feb 2003 19:36:39 -0800 (PST) Message-Id: <200302120336.h1C3adf12665@scv3.apple.com> Subject: Beating a dead horse: Who supports LL19? Date: Tue, 11 Feb 2003 19:36:39 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Issue LL19 has generated a lot of traffic, almost all of it arguing that we should oppose it. I submit that we may be beating a dead horse. If anyone disagrees and still wants to argue in support of LL19 please do so, but I think that all of us (myself included) who oppose LL19 can probably leave the issue alone now. We have plenty of other stuff to be discussing. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Feb 11 23:32:20 2003 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 XAA28083 for ; Tue, 11 Feb 2003 23:32:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ED74C9122B; Tue, 11 Feb 2003 23:35:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB4AE9122C; Tue, 11 Feb 2003 23:35:53 -0500 (EST) 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 A2E889122B for ; Tue, 11 Feb 2003 23:35:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8FE3D5DEBC; Tue, 11 Feb 2003 23:35:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by segue.merit.edu (Postfix) with ESMTP id 62E085DD8D for ; Tue, 11 Feb 2003 23:35:52 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ioce-0006Jz-00; Tue, 11 Feb 2003 20:35:49 -0800 Date: Tue, 11 Feb 2003 23:33:26 -0500 From: Keith Moore To: Stuart Cheshire Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL16 Split references Message-Id: <20030211233326.50316b2f.moore@cs.utk.edu> In-Reply-To: <200302120333.h1C3Xaf11872@scv3.apple.com> References: <200302120333.h1C3Xaf11872@scv3.apple.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 these devices don't have to claim conformance to an IETF standard. neither should IETF be expected to endorse Apple's products. I am strongly opposed to permitting LL-only devices to claim conformance to the standard. this is completely unacceptable. Keith > Keith Moore wrote: > > >If DHCP ends up being required (as I believe it should) then RFC 2131 > >becomes a normative reference. > > I hinted last week about devices that use IPv4LL for communication > between components inside a single computer chassis. > > This week Apple publicly announced the first of these devices. > > > > Xserve RAID includes hot-swappable modules. These modules have to > communicate internally. How do they communicate? Via PCI? No. they > communicate via Ethernet, using IPv4LL addresses. > > If you think that Apple did this as a publicity stunt for the sake of > promoting IPv4LL, let me correct that misunderstanding. The hardware > teams at Apple are driven my making the best hardware at the lowest > price. If a technology doesn't make sense, they're certainly not going to > put it in just to please me. > > The hardware team chose IPv4LL/Ethernet for the internal communication > bus for a good reason. The part they were using included an Ethernet port > on the same silicon. When they were considering what internal > communication technology to put in the design, someone (not me) pointed > out this spare Ethernet port that they were not planning to use. With a > little bit of software, they got their internal communication bus for > free, instead of having to add some other interconnect to the circuit > board. > > Now, getting back to LL16, it makes no sense to mandate that these RAID > controller modules MUST implement a DHCP client, when they are on a > 19-inch Ethernet network, inside a single computer chassis, and we *know* > it will never have a DHCP server on it. > > Stuart > From owner-zeroconf@merit.edu Tue Feb 11 23:40:19 2003 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 XAA28221 for ; Tue, 11 Feb 2003 23:40:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8685A9122C; Tue, 11 Feb 2003 23:43:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C7A191234; Tue, 11 Feb 2003 23:43:54 -0500 (EST) 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 689E19122C for ; Tue, 11 Feb 2003 23:43:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 494A65DEE5; Tue, 11 Feb 2003 23:43:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from home.karahalios.org (dsl093-162-009.tus1.dsl.speakeasy.net [66.93.162.9]) by segue.merit.edu (Postfix) with ESMTP id 8697D5DED0 for ; Tue, 11 Feb 2003 23:43:52 -0500 (EST) Received: from Outersoft.com (usr2.Karahalios.org [192.168.2.2]) by home.karahalios.org (8.11.1/8.10.1) with ESMTP id h1C4hp611487 for ; Tue, 11 Feb 2003 21:43:51 -0700 Date: Tue, 11 Feb 2003 21:43:50 -0700 Subject: Re: LL16 Split references Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Alex Karahalios To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030211233326.50316b2f.moore@cs.utk.edu> Message-Id: <948C1C46-3E44-11D7-B8CE-00039377AD70@Outersoft.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit In case anyone is keeping count, I am in favor of permitting LL-only devices. I think this is completely acceptable. Alex Karahalios On Tuesday, February 11, 2003, at 09:33 PM, Keith Moore wrote: > I am strongly opposed to permitting LL-only devices to claim > conformance > to the standard. this is completely unacceptable. From owner-zeroconf@merit.edu Tue Feb 11 23:47:55 2003 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 XAA28413 for ; Tue, 11 Feb 2003 23:47:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C08E691207; Tue, 11 Feb 2003 23:51:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 923289120F; Tue, 11 Feb 2003 23:51:28 -0500 (EST) 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 51BA191207 for ; Tue, 11 Feb 2003 23:51:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 363935DEBC; Tue, 11 Feb 2003 23:51:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by segue.merit.edu (Postfix) with ESMTP id 161B85DDE2 for ; Tue, 11 Feb 2003 23:51:26 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18iori-0003LW-00; Tue, 11 Feb 2003 20:51:22 -0800 Date: Tue, 11 Feb 2003 23:49:00 -0500 From: Keith Moore To: Stuart Cheshire Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL10 Add warnings to applicability statement Message-Id: <20030211234900.6d1fe315.moore@cs.utk.edu> In-Reply-To: <200302120313.h1C3D7Q27321@scv2.apple.com> References: <200302120313.h1C3D7Q27321@scv2.apple.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Tue, 11 Feb 2003 19:13:08 -0800 Stuart Cheshire wrote: > I cannot support the proposed change: > > >IPv4 link-local addresses are therefore applicable if it is either > >known that all applications that are used can accomondate this > >change in the properties of the IP addresses, or all applications > >that are used have been modified to account for dynamic addresses, > >their limited scope and their potential ambiguity. > > If you think carefully about what this says, it outlaws what Apple and > Microsoft have been doing since 1998, No, it just means that the behavior of vendors products prior to the standard does not conform to the standard. (Actually I think the text is just poorly written, as I pointed out in a separate message. But IETF is under no obligation to bless any vendors' practices, whether good or bad, or in the past, present or future.) > This statement says that IPv4 link-local addresses are only applicable > in cases where you can make a definite statement about *all* applications > running on that OS. Until you find a way to separate the apps that work with LL from those that don't, such that those that don't work with LL aren't affected, there is at least some justification for this position. > In the case of a general purpose OS like Mac OS, > Windows, Linux, or Solaris, this means that IPv4 link-local addresses > are *never* applicable because the OS vendor does not even know about > every third-party application running on that OS. > > The whole rationale behind IPv4LL is that effectively *ALL* application > protocols can function usefully with link-local addresses on a single > isolated link. This may be the rationale, but it's simply not the case. There are apps that, for a variety of reasons, need to have external connectivity even if all of the participants in the session are all on the local link. For instance, some kinds of distributed apps rely on having a server on the public Internet which can serve as a forwarder and/or rendezvous point, because (due to NATs and firewalls) they do not expect hosts to be able to communicate directly with one another. Some apps insist on consulting a license server. Others will want to look up DNS names. etc. Nor is the "isolated network" case very relevant, because most apps will occasionally need to deal with a mixture of LL and routable addresses. How the app deals with it will vary from one app to another, but some apps will certainly fail under such conditions, and other apps will not work as well as they would with routable addresses. We've accepted that we're going to have LL addresses. We've come to something resembling agreement that they should only be used by ad hoc networks or when explicitly configured, that they should stay out of the way as much as possible. Having a solution for ad hoc networks is a good thing. But let's not lie about the limitations of these things. From owner-zeroconf@merit.edu Wed Feb 12 05:50:55 2003 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 FAA28656 for ; Wed, 12 Feb 2003 05:50:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2F5B59120F; Wed, 12 Feb 2003 05:54:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 054F591212; Wed, 12 Feb 2003 05:54:29 -0500 (EST) 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 117899120F for ; Wed, 12 Feb 2003 05:54:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id E466A5DFBB; Wed, 12 Feb 2003 05:54:28 -0500 (EST) 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 B464E5DEDF for ; Wed, 12 Feb 2003 05:54:28 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 364AD59981 for ; Wed, 12 Feb 2003 10:54:30 +0000 (GMT) Message-ID: <016101c2d285$1db32c00$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" Subject: LL6 security and wireless LANs Date: Wed, 12 Feb 2003 10:54:28 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I accept the proposed change. Philip From owner-zeroconf@merit.edu Wed Feb 12 05:51:39 2003 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 FAA28694 for ; Wed, 12 Feb 2003 05:51:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A9A0591212; Wed, 12 Feb 2003 05:55:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 715FA91214; Wed, 12 Feb 2003 05:55:06 -0500 (EST) 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 776DC91212 for ; Wed, 12 Feb 2003 05:55:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 640A75DEDF; Wed, 12 Feb 2003 05:55:05 -0500 (EST) 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 36B445DDA4 for ; Wed, 12 Feb 2003 05:55:05 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id E0CD859981 for ; Wed, 12 Feb 2003 10:55:06 +0000 (GMT) Message-ID: <016201c2d285$33921450$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" Subject: LL8 routing considerations Date: Wed, 12 Feb 2003 10:55:05 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I accept the principle and support the text suggested by Robert Elz: >> Routing Protocols The link local address block (169.254/16) MUST NOT be included as a reachable prefix in any dynamic routing protocol. Subnets of that address block (which should not exist - see sect N.M) MUST NOT be included either. >> From owner-zeroconf@merit.edu Wed Feb 12 05:52:31 2003 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 FAA28720 for ; Wed, 12 Feb 2003 05:52:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 930B391214; Wed, 12 Feb 2003 05:55:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5AC2291216; Wed, 12 Feb 2003 05:55:58 -0500 (EST) 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 5F19991214 for ; Wed, 12 Feb 2003 05:55:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4D5955DFBB; Wed, 12 Feb 2003 05:55:57 -0500 (EST) 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 201D85DEDF for ; Wed, 12 Feb 2003 05:55:57 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id C777D59955 for ; Wed, 12 Feb 2003 10:55:58 +0000 (GMT) Message-ID: <016301c2d285$527ef310$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" Subject: LL10 applicability Date: Wed, 12 Feb 2003 10:55:57 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I accept that a change needs to be made but not as worded. In general I agree with Keith Moore's analysis: "what we need to be saying is that due to ambiguity and stability issues LL addresses only work well for a subset of applications; that LL cannot be fixed to work better given the constraint that it be usable in ad hoc networks and the shortage of IPv4 addresses; that while some apps will work fine, other apps may or may not be able to work around these limitations; and as such, that LL addresses should only be used when stable, routable addresses are not available - such as on ad hoc, isolated networks." I suggest the following text: --- IPv4 link-local addresses and their dynamic configuration have profound implications upon applications which use them. This is discussed in Section 7. Many applications fundamentally assume addresses of communicating peers are routable, relatively unchanging and unique. These assumptions no longer hold with IPv4 link-local addresses, therefore while many applications will work properly with LL addresses, others may do so only after modification, or will exhibit reduced or partial functionality, or will fail altogether. The design requirements for IPv4 link-local address assignment means that they are necessarily a compromise and they should only be used where stable, routable addresses are not available - such as on ad hoc or isolated networks or in controlled situations where these limitations and their impact on applications are understood and accepted. --- Philip From owner-zeroconf@merit.edu Wed Feb 12 05:52:50 2003 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 FAA28738 for ; Wed, 12 Feb 2003 05:52:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 412CC91216; Wed, 12 Feb 2003 05:56:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 110639121A; Wed, 12 Feb 2003 05:56:24 -0500 (EST) 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 254A691216 for ; Wed, 12 Feb 2003 05:56:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1455B5DFFB; Wed, 12 Feb 2003 05:56:24 -0500 (EST) 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 DB00E5DEDF for ; Wed, 12 Feb 2003 05:56:23 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 8DA355997B for ; Wed, 12 Feb 2003 10:56:25 +0000 (GMT) Message-ID: <016401c2d285$62739320$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" Subject: LL11 Date: Wed, 12 Feb 2003 10:56:24 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I accept the proposed change. I also favour the addition suggested by Robert Elz: "Implementations and users should also note that a node that gives up an address and reconfigures, as required by section 2.5, allows the possibility that another node can easily successfully hijack existing TCP connections. Before abandoning an address due to a conflict, hosts SHOULD actively attempt to reset any existing connections using that address." (though on an editorial note I would delete "easily successfully"). Philip From owner-zeroconf@merit.edu Wed Feb 12 05:53:10 2003 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 FAA28753 for ; Wed, 12 Feb 2003 05:53:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A3D359121A; Wed, 12 Feb 2003 05:56:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C7439121C; Wed, 12 Feb 2003 05:56:36 -0500 (EST) 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 45CE59121A for ; Wed, 12 Feb 2003 05:56:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 30B485DFBB; Wed, 12 Feb 2003 05:56:35 -0500 (EST) 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 050E45DEDF for ; Wed, 12 Feb 2003 05:56:35 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id B12ED59983 for ; Wed, 12 Feb 2003 10:56:36 +0000 (GMT) Message-ID: <016501c2d285$691851c0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" Subject: LL16 split references Date: Wed, 12 Feb 2003 10:56:35 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I accept the proposal The actual sorting between informative and normative obviously needs to be performed at a late stage as some references may change status with other issue resolutions. Philip From owner-zeroconf@merit.edu Wed Feb 12 06:22:55 2003 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 GAA29199 for ; Wed, 12 Feb 2003 06:22:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 59EA191226; Wed, 12 Feb 2003 06:26:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 23BDB91227; Wed, 12 Feb 2003 06:26:21 -0500 (EST) 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 D9F8191226 for ; Wed, 12 Feb 2003 06:26:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id CA9EF5DFFF; Wed, 12 Feb 2003 06:26:17 -0500 (EST) 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 9D9175DFB3 for ; Wed, 12 Feb 2003 06:26:17 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 33C585997B for ; Wed, 12 Feb 2003 11:26:19 +0000 (GMT) Message-ID: <017d01c2d289$8f7ef590$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" Subject: LL10 applicability Date: Wed, 12 Feb 2003 11:26:17 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Oohps - bad punctuation in my suggested text. It should read: --- IPv4 link-local addresses and their dynamic configuration have profound implications upon applications which use them. This is discussed in Section 7. Many applications fundamentally assume addresses of communicating peers are routable, relatively unchanging and unique. These assumptions no longer hold with IPv4 link-local addresses, therefore while many applications will work properly with LL addresses, others may do so only after modification, or will exhibit reduced or partial functionality, or will fail altogether. The design requirements for IPv4 link-local address assignment means that they are necessarily a compromise and they should only be used where stable, routable addresses are not available (such as on ad hoc or isolated networks) or in controlled situations where these limitations and their impact on applications are understood and accepted. --- Philip From owner-zeroconf@merit.edu Wed Feb 12 08:17:38 2003 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 IAA01902 for ; Wed, 12 Feb 2003 08:17:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A151791228; Wed, 12 Feb 2003 08:21:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D1FA91229; Wed, 12 Feb 2003 08:21:13 -0500 (EST) 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 6907991228 for ; Wed, 12 Feb 2003 08:21:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 581DF5E027; Wed, 12 Feb 2003 08:21:12 -0500 (EST) 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 DDA855DDA4 for ; Wed, 12 Feb 2003 08:21:11 -0500 (EST) 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 IAA10144 for ; Wed, 12 Feb 2003 08:21:11 -0500 (EST) 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 IAA22440 for ; Wed, 12 Feb 2003 08:18:58 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id IAA27550 for ; Wed, 12 Feb 2003 08:04:48 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 12 Feb 2003 08:04:45 -0500 Subject: Re: LL16 Split references From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <948C1C46-3E44-11D7-B8CE-00039377AD70@Outersoft.com> 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 02/11/2003 23:43, "Alex Karahalios" wrote: > In case anyone is keeping count, I am in favor of permitting LL-only > devices. I think this is completely acceptable. > Especially with Stuart's example. Anytime you have a need for easy setup within a limited scope, (intra cluster communication on a dedicated channel comes to mind), LL4 is perfect. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Feb 12 09:47:23 2003 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 JAA04529 for ; Wed, 12 Feb 2003 09:47:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8928D91234; Wed, 12 Feb 2003 09:50:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50F6E91235; Wed, 12 Feb 2003 09:50:59 -0500 (EST) 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 30B0791234 for ; Wed, 12 Feb 2003 09:50:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 12F915E027; Wed, 12 Feb 2003 09:50:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by segue.merit.edu (Postfix) with ESMTP id D5B895E028 for ; Wed, 12 Feb 2003 09:50:57 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18iyDv-0007kU-00; Wed, 12 Feb 2003 06:50:55 -0800 Date: Wed, 12 Feb 2003 09:48:31 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL16 Split references Message-Id: <20030212094831.2cf13a0a.moore@cs.utk.edu> In-Reply-To: References: <948C1C46-3E44-11D7-B8CE-00039377AD70@Outersoft.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > In case anyone is keeping count, I am in favor of permitting LL-only > > devices. I think this is completely acceptable. > > > > Especially with Stuart's example. Anytime you have a need for easy setup > within a limited scope, (intra cluster communication on a dedicated channel > comes to mind), LL4 is perfect. this is out of scope for IETF, and out of scope for this working group. From owner-zeroconf@merit.edu Wed Feb 12 11:48:12 2003 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 LAA08238 for ; Wed, 12 Feb 2003 11:48:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8D9A191236; Wed, 12 Feb 2003 11:51:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5773591239; Wed, 12 Feb 2003 11:51:48 -0500 (EST) 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 30CC491236 for ; Wed, 12 Feb 2003 11:51:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 193BC5E02D; Wed, 12 Feb 2003 11:51:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id F17D25E02C for ; Wed, 12 Feb 2003 11:51:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id B434014067; Wed, 12 Feb 2003 11:51:46 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 25909-06; Wed, 12 Feb 2003 11:51:46 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 1900214066; Wed, 12 Feb 2003 11:51:46 -0500 (EST) Date: Wed, 12 Feb 2003 11:51:45 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL10 applicability Message-Id: <20030212115145.0f9cda73.moore@cs.utk.edu> In-Reply-To: <017d01c2d289$8f7ef590$131010ac@aldebaran> References: <017d01c2d289$8f7ef590$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 714e45285c7a5bcb0dec226596cbfaa6105681d9 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit mostly I like the proposed text. I few suggestions: > IPv4 link-local addresses and their dynamic configuration have > profound implications upon applications which use them. This is > discussed in Section 7. Many applications fundamentally assume that > addresses of communicating peers are routable, relatively > unchanging and unique. These assumptions no longer hold with IPv4 > link-local addresses, or a mixture of link-local and routable addresses. > [T]herefore while many applications will work > properly with LL addresses , or a mixture of LL and routable addresses > , others may do so only after > modification, or will exhibit reduced or partial functionality In some cases it may be infeasible for the application to be modified to operate under such conditions. > The design requirements for IPv4 link-local address assignment (instead of the previous line) were necessarily a compromise to favor usability in the absence of address assignment infrastructure over stability of addressing and ability to communicate with off-link hosts. Such a compromise makes sense for ad hoc or isolated networks, but not for links that are connected to external networks. IPv4 link-local addresses should therefore only > be used where stable, routable addresses are not available (such > as on ad hoc or isolated networks) or in controlled situations > where these limitations and their impact on applications are > understood and accepted. (it might be better to restate this as "use of v4LL should be avoided when stable, routable addresses are available, except in controlled situations where the set of applications is fixed and the impact of v4LL on those applications is well-understood and accepted") From owner-zeroconf@merit.edu Wed Feb 12 11:50:42 2003 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 LAA08275 for ; Wed, 12 Feb 2003 11:50:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 86B2C91239; Wed, 12 Feb 2003 11:54:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 508C39123F; Wed, 12 Feb 2003 11:54:17 -0500 (EST) 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 3406C91239 for ; Wed, 12 Feb 2003 11:54:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 21C975DFB5; Wed, 12 Feb 2003 11:54:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 099C95DF6C for ; Wed, 12 Feb 2003 11:54:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id D5C6114066; Wed, 12 Feb 2003 11:54:15 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 26494-04; Wed, 12 Feb 2003 11:54:15 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 2CF4814062; Wed, 12 Feb 2003 11:54:15 -0500 (EST) Date: Wed, 12 Feb 2003 11:54:15 -0500 From: Keith Moore To: Stuart Cheshire Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL17 Hosts with configured addresses MUST ARP for v4 LL addresses Message-Id: <20030212115415.2126fb40.moore@cs.utk.edu> In-Reply-To: <200302120335.h1C3ZEs13415@scv1.apple.com> References: <200302120335.h1C3ZEs13415@scv1.apple.com> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 021572d67a2da8acc02691211529a3a5f27464ce Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I propose the following text instead: > > 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. strongly disagree. SHOULD always use a routable source address in preference to a LL source address. From owner-zeroconf@merit.edu Wed Feb 12 11:55:52 2003 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 LAA08508 for ; Wed, 12 Feb 2003 11:55:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4376C9123F; Wed, 12 Feb 2003 11:59:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2BE791240; Wed, 12 Feb 2003 11:59:26 -0500 (EST) 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 B1F739123F for ; Wed, 12 Feb 2003 11:59:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 93CBF5E02E; Wed, 12 Feb 2003 11:59:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 74E7F5E02D for ; Wed, 12 Feb 2003 11:59:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 41C9F14067; Wed, 12 Feb 2003 11:59:25 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 26830-07; Wed, 12 Feb 2003 11:59:24 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 9930914062; Wed, 12 Feb 2003 11:59:24 -0500 (EST) Date: Wed, 12 Feb 2003 11:59:24 -0500 From: Keith Moore To: Stuart Cheshire Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL11 Add security consideration for the threat where an attacker forces address reconfiguration Message-Id: <20030212115924.64ffae8d.moore@cs.utk.edu> In-Reply-To: <200302120332.h1C3WHQ02980@scv2.apple.com> References: <200302120332.h1C3WHQ02980@scv2.apple.com> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: c0e0768329edd67da4fd812b953d66dfe85845b0 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree with kre that sending RSTs is a good idea, and I agree with Stuart that spoofed ARPs are not an LL-specific threat. The difference with LL is that, *as a matter of protocol conformance*, ARPs can be used to DoS a TCP connection at any time. However I suspect this may also be the case with most existing (non-LL) TCP implementations - especially those that use ARP to perform DAD. In which case there would be little practical difference to this threat between LL and non-LL. Keith On Tue, 11 Feb 2003 19:32:18 -0800 Stuart Cheshire wrote: > Robert Elz suggested that a host send TCP resets before giving up its > address. This sounds like a good idea, and I would not oppose this new > > text. > > However, I do not agree with the entire analysis. > > Robert Elz wrote: > > >The issue of course, is that on many net technologies where a node > >has the ability to issue ARP packets, nodes also have the ability > >to snoop packets. > > > >Such a node can, if it desires, watch a TCP connection be > >established, go through the authentication phase, and then start > >sending (many) ARP packets claiming to own the address of the > >system which just authenticated itself. That system (following > >section 2.5) reconfigures to a new address, leaving the old one > >available for the node that usurped it. That node has all the > >information it needs (sequence numbers, port numbers, ...) to > >successfully masquerade as the node that was previously > >authenticated. > > > >This is a very serious (and new) security issue posed by using LL > >addresses as demanded in section 2.5. (new in the sense that it > >doesn't exist in earlier IP stacks - not new to this e-mail of > >course). > > I disagee that it is a new threat. > > Unicast ARP poisoning can be used today to hijack a TCP connection > without the victim even knowing it. (The intruder poisons the peer's > ARP cache via a spoof unicast reply; the victim never even sees the > spoof unicast reply so it never knows why it stopped receiving > packets. The intruder can even forward modified packets to keep the > connection apparently alive, so the victim in fact may not stop > receiving packets.) > > Stuart > From owner-zeroconf@merit.edu Wed Feb 12 12:49:19 2003 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 MAA09986 for ; Wed, 12 Feb 2003 12:49:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CA74291242; Wed, 12 Feb 2003 12:52:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9414891243; Wed, 12 Feb 2003 12:52:54 -0500 (EST) 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 85FBB91242 for ; Wed, 12 Feb 2003 12:52:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6FE3C5DEEC; Wed, 12 Feb 2003 12:52:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by segue.merit.edu (Postfix) with ESMTP id 0E5E95DEDA for ; Wed, 12 Feb 2003 12:52:53 -0500 (EST) Received: from asteroids.gpcc.itd.umich.edu (asteroids.gpcc.itd.umich.edu [141.211.2.218]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id MAA25139 for ; Wed, 12 Feb 2003 12:52:52 -0500 (EST) Received: from localhost (sgoswami@localhost) by asteroids.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id MAA15484 for ; Wed, 12 Feb 2003 12:52:52 -0500 (EST) Date: Wed, 12 Feb 2003 12:52:52 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@asteroids.gpcc.itd.umich.edu To: zeroconf@merit.edu Subject: LL17, LL8 In-Reply-To: <20030212115415.2126fb40.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk In the above two issues it is mentioned "The host MUST NOT send the packet to any router for forward" at several places. These issues are not really resolved unless the following are addressed. i. How does the v4LL interface know which is a router ? ii. How does the v4LL interface implement the "NOT send the packet to any router" scheme ? In LL17 Erik has provided a hint on how to manipulate routing table to make sure routable IP addresses are indeed on the link. A similar clarification for "NOT send the packet to any router" is required. Subrata From owner-zeroconf@merit.edu Wed Feb 12 13:33:27 2003 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 NAA11243 for ; Wed, 12 Feb 2003 13:33:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 10A4891243; Wed, 12 Feb 2003 13:37:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC62191244; Wed, 12 Feb 2003 13:37:01 -0500 (EST) 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 7741291243 for ; Wed, 12 Feb 2003 13:37:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 594005DEEC; Wed, 12 Feb 2003 13:37:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 39F0E5DEA8 for ; Wed, 12 Feb 2003 13:37:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id E84321404E; Wed, 12 Feb 2003 13:36:59 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 08771-04; Wed, 12 Feb 2003 13:36:59 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 2FEEB13FAD; Wed, 12 Feb 2003 13:36:59 -0500 (EST) Date: Wed, 12 Feb 2003 13:36:58 -0500 From: Keith Moore To: zeroconf@merit.edu Cc: moore@cs.utk.edu Subject: new issue: LL-only hosts are out of scope Message-Id: <20030212133658.2cc20d8e.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Spam-Status: No, hits=0.8 tagged_above=0.0 required=7.0 tests=SPAM_PHRASE_00_01 X-Spam-Level: X X-Razor-id: 2ecbc7ceb57c1cbc3b871e3ba2769822284b20f4 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit might as well get this one on the table... Description of issue: LL-only hosts are out of scope for this specification Submitter name: Keith Moore Submitter email address: moore@cs.utk.edu Date first submitted: 11 February 2003 Reference: Comment type: T Priority: S Rationale: The Internet Engineering Task Force develops specifications which, when followed, should permit interoperation of conforming implementations on the Internet. With very few exceptions, IETF has considered the behavior of private networks (i.e. networks that are entirely controlled by a single party) as outside of its scope. (Use of the Internet Protocol on purely isolated, ad hoc networks would also be out-of-scope and of little interest to IETF -- except that some interchange between hosts using link-local addresses and hosts using routable addresses is unavoidable, and that absent careful consideration of the effects of such interchange, introduction of link-local addressing to IPv4 would be expected to adversely affect the ability of hosts and applications to interoperate over the Internet.) Inherent in the entire concept of "INTERnet", and the "Internet Protocol" is the ability to communicate _between_ networks. Devices which don't support that ability should not claim conformance to IP or compatibility with the Internet, and IETF should not be blessing specifications that encourage the creation of a class of devices (and applications) that inherently cannot interoperate with the Internet. Requested change: Insert this section at an appropriate place in the document: ---- ##. Hosts which implement only link-local addressing Inherent in the entire concept of "Internet" is the ability to communicate between (not just within) networks, and the Internet Protocol was designed specifically to facilitate communication between hosts on potentially dissimilar, and perhaps distant, networks. Hosts which are inherently incapable of communicating with hosts on other IP networks cannot meaningfully be said to implement the Internet Protocol, or to support Internet connectivity, even if they use similar packet formats. Hosts which are incapable of being configured to use routable addresses, or are incapable of being configured to route packets with nonlocal destinations to a router, or which are incapable of exchanging traffic with hosts on other IP networks, are therefore outside of the scope of this specification. While hosts with such limitations may still be useful in specific contexts, it is not appropriate for such hosts to claim conformance with this specification, or with the Internet Protocol, or compatibility with the Internet. In order to clearly distinguish hosts that implement link-local addressing but are incapable of communicating with the Internet, from hosts that are capable of communicating with the Internet, vendors of the former kind of hosts are strongly urged to choose another name for the former capability. ---- Keith p.s. The name "Local Interhost Protocol" with the acronym "LIP" is offered as a strawman. Then you could define LIP-specific services, or "LIP services" for short. This is easily distinguishable from IP while still hinting at a similarity with IP, which seems like the right idea. However my guess is that marketroids will shy away from claiming to make devices with LIPs, or which can only give LIP services. From owner-zeroconf@merit.edu Wed Feb 12 16:40:44 2003 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 QAA16607 for ; Wed, 12 Feb 2003 16:40:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B71D091222; Wed, 12 Feb 2003 16:44:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86FB191225; Wed, 12 Feb 2003 16:44:18 -0500 (EST) 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 31B2291222 for ; Wed, 12 Feb 2003 16:44:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 125205E037; Wed, 12 Feb 2003 16:44:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id E3D0D5E036 for ; Wed, 12 Feb 2003 16:44:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id B11B113FC6; Wed, 12 Feb 2003 16:44:16 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 03154-04; Wed, 12 Feb 2003 16:44:16 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id F37A714067; Wed, 12 Feb 2003 16:44:15 -0500 (EST) Date: Wed, 12 Feb 2003 16:44:15 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs Message-Id: <20030212164415.5772a277.moore@cs.utk.edu> In-Reply-To: <1044793681.21186.107.camel@devil> References: <1044787452.11519.93.camel@devil> <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> <3689.1044783115@munnari.OZ.AU> <4300.1044789975@munnari.OZ.AU> <1044793681.21186.107.camel@devil> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: b4ea54d47215ac5da9a5ab5f12a21f1f06762f3a Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > No, a routable address can communicate perfectly well with a LL > > address. > > Only if both nodes are v4LL compliant. It is not safe to talk to a > non-v4LL node using a v4LL address. > > I'm expecting networks to have a lot of non-v4LL compliant nodes. fair enough, but the case of a host with only a v4LL address talking to a host with a routable address should be rare - it should only occur when the v4LL host has somehow failed to acquire an address from DHCP. and even in that case, there is a workaround by configuring the other host to arp for v4ll addresses. (of course, there should be no v4LL-only hosts as these could not interoperate anyway) and it is impossible to define v4LL behavior in such a way that it will always interoperate with hosts that don't support it. > The draft already says that v4LL addresses should not be configured > manually. this should be interpreted as "v4LL addresses should not be assigned manuallly". there is no objection to a host permitting a user to manually tell it to pick a v4LL address at random, and follow the claim/defend protocol in this specification. > > What's more, applications that care about addresses also get to > > see more than one, and also need to choose which they use. > > Where do these addresses come from? They always come from: > > a) manual configuration > b) a name resolution process. > c) a communicating peer as part of the application layer protocol > > Ask yourself where the peer got the address. Repeat until you get > either a) or b) as the answer. nope. you're completely wrong about that. and even to the extent that addresses do come from manual configuration or name resolution, (a) to cope with a mixture of routable and LL addresses often requires a change to existing applications and (b) there is no fix that allows applications to work with a mixture of LL and routable addresses in all cases. in general the application doing the referral has no idea whether the address will be usable to the party who eventually wants to use it. > To address your earlier argument: I am not saying that "every > v4LL-compliant node MUST have a v4LL address". I am saying: > - A node MUST be allowed to have a v4LL together with a routable > address on the same interface I don't think anyone's objecting to this, but it should not happen absent manual configuration to enable it, or except as a transition from LL to routable addresses. > - A node MUST NOT use the v4LL address when communicating with a > non-v4LL compliant node there's no way for the source to know whether the destination is v4LL compliant. the safest thing is to always use a routable source address, if you have one. > - PLEASE don't create unnecessary implementation dependencies between > v4LL and other address configuration mechanisms the dependencies are unfortunate, but necessary. trying to get rid of those dependencies causes worse problems. From owner-zeroconf@merit.edu Wed Feb 12 16:49:18 2003 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 QAA16968 for ; Wed, 12 Feb 2003 16:49:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5BE4791225; Wed, 12 Feb 2003 16:52:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 278859124F; Wed, 12 Feb 2003 16:52:53 -0500 (EST) 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 2DCA991225 for ; Wed, 12 Feb 2003 16:52:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id F061C5E038; Wed, 12 Feb 2003 16:52:51 -0500 (EST) 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 BA8605DF38 for ; Wed, 12 Feb 2003 16:52:51 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 986B259982; Wed, 12 Feb 2003 21:52:54 +0000 (GMT) Message-ID: <01f201c2d2e1$17114ec0$131010ac@aldebaran> From: "Philip Nye" To: "s. goswami" , References: Subject: Re: LL17, LL8 Date: Wed, 12 Feb 2003 21:52:50 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "s. goswami" > > "The host MUST NOT send the packet to any router for forward" > > at several places. > > > These issues are not really resolved unless the following > are addressed. > > i. How does the v4LL interface know which is a router ? > ii. How does the v4LL interface implement the "NOT send the packet to any > router" scheme ? There is a difference between sending a packet to a host which happens to be a router (i.e. communicating with the host) and sending it to that router *for forwarding*. In the first case the packet's destination address is the router's own IP address. In the second case the packet's destination address is different and the hope is that the router will forward it to eventually reach it's true destination. It is quite OK to communicate with the router itself. So whether or not you know which hosts are routers doesn't really matter. Just don't send packets with LL destination (or source) addresses anywhere other than their true destination which must be on the local link. If the destination is not on the local link you have to discard the packet and the communication fails. The rules for proper routable IP addresses are different. Philip From owner-zeroconf@merit.edu Wed Feb 12 17:36:45 2003 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 RAA17992 for ; Wed, 12 Feb 2003 17:36:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7693191208; Wed, 12 Feb 2003 17:40:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A88491252; Wed, 12 Feb 2003 17:40:13 -0500 (EST) 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 68EA491208 for ; Wed, 12 Feb 2003 17:40:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 57A7E5DE39; Wed, 12 Feb 2003 17:40:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by segue.merit.edu (Postfix) with ESMTP id 81BAA5E02F for ; Wed, 12 Feb 2003 17:40:11 -0500 (EST) Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) with ESMTP id h1CMe9iC003693 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Thu, 13 Feb 2003 00:40:10 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) id h1CMe9gg003689; Thu, 13 Feb 2003 00:40:09 +0200 Date: Thu, 13 Feb 2003 00:40:09 +0200 Message-Id: <200302122240.h1CMe9gg003689@burp.tkv.asdf.org> From: Markku Savela To: zeroconf@merit.edu Subject: LL usage example: LL-only homenetwork with single global address + NAT Sender: owner-zeroconf@merit.edu Precedence: bulk This not related specifically to any issue, but I just thought to remind of this potential usage of Ipv4 link local (probably this has be mentioned here): - a home network with multiple machines (printers and maybe others) - nodes at home network are LL only (automatic configuration, just plug in the devices). Easy to use. - then they get link to internet, but the nasty ISP gives only one global IP-address. Thus, the user gets - a gateway router perfoming the ugly NAT service for outbound connections Above configuration would "break" a few points that have been discussed here: - nodes DO NEED to packets with LL-source and global destination to the NAT/Router/Gateway for FORWARDING. - LL-only nodes need to install default route for the gateway (does rendezvous have a feature for this: find the default router?). From owner-zeroconf@merit.edu Wed Feb 12 17:46:05 2003 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 RAA18160 for ; Wed, 12 Feb 2003 17:46:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4DE079121E; Wed, 12 Feb 2003 17:49:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 13ADC91252; Wed, 12 Feb 2003 17:49:39 -0500 (EST) 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 6A7C29121E for ; Wed, 12 Feb 2003 17:48:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4B65B5DFE8; Wed, 12 Feb 2003 17:48:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by segue.merit.edu (Postfix) with ESMTP id D6D165DFE3 for ; Wed, 12 Feb 2003 17:48:06 -0500 (EST) Received: from robotron.gpcc.itd.umich.edu (robotron.gpcc.itd.umich.edu [141.211.2.207]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id RAA25825; Wed, 12 Feb 2003 17:48:05 -0500 (EST) Received: from localhost (sgoswami@localhost) by robotron.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id RAA19342; Wed, 12 Feb 2003 17:48:05 -0500 (EST) Date: Wed, 12 Feb 2003 17:48:05 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@robotron.gpcc.itd.umich.edu To: Philip Nye Cc: zeroconf@merit.edu Subject: Re: LL17, LL8 In-Reply-To: <01f201c2d2e1$17114ec0$131010ac@aldebaran> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk See my comments inline. On Wed, 12 Feb 2003, Philip Nye wrote: > > From: "s. goswami" > > > > "The host MUST NOT send the packet to any router for forward" > > > > at several places. > > > > > > These issues are not really resolved unless the following > > are addressed. > > > > i. How does the v4LL interface know which is a router ? > > ii. How does the v4LL interface implement the "NOT send the packet to any > > router" scheme ? > > There is a difference between sending a packet to a host which happens to be > a router (i.e. communicating with the host) and sending it to that router > *for forwarding*. > In the first case the packet's destination address is the router's own IP > address. In the second case the packet's destination address is different > and the hope is that the router will forward it to eventually reach it's > true destination. It is quite OK to communicate with the router itself. > So this also precludes a router between two 169.254/16 networks, right ? > So whether or not you know which hosts are routers doesn't really matter. > Just don't send packets with LL destination (or source) addresses anywhere > other than their true destination which must be on the local link. If the > destination is not on the local link you have to discard the packet and the > communication fails. > This is basically covered in ARP requirement (LL17)- why do we need to say the same thing multiple times in different words ? We can also say that the route table should have an entry as the following (assuming 169.254.0.11 is the IP address on the LL interface) Network Destination Netmask Gateway Interface 169.254.0.0 255.255.0.0 169.254.0.11 169.254.0.11 This also would impact existing IP nodes, as in them it would be possible to set a 169.254.x.x address and forward that to the existing router (which by the way would happily forward it). > The rules for proper routable IP addresses are different. > > Philip > From owner-zeroconf@merit.edu Wed Feb 12 17:51:09 2003 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 RAA18241 for ; Wed, 12 Feb 2003 17:51:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8CE3491252; Wed, 12 Feb 2003 17:54:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFD8E91257; Wed, 12 Feb 2003 17:54:41 -0500 (EST) 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 CF7CE91252 for ; Wed, 12 Feb 2003 17:54:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id B81235DE23; Wed, 12 Feb 2003 17:54:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id DCAE55DDEB for ; Wed, 12 Feb 2003 17:54:39 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1CMtDaj011267; Thu, 13 Feb 2003 00:55:13 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1CMtCOf011266; Thu, 13 Feb 2003 00:55:12 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Keith Moore Cc: kre@munnari.OZ.AU, zeroconf@merit.edu In-Reply-To: <20030212164415.5772a277.moore@cs.utk.edu> References: <1044787452.11519.93.camel@devil> <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> <3689.1044783115@munnari.OZ.AU> <4300.1044789975@munnari.OZ.AU> <1044793681.21186.107.camel@devil> <20030212164415.5772a277.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045090511.4847.93.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 13 Feb 2003 00:55:12 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-12 at 23:44, Keith Moore wrote: > > > What's more, applications that care about addresses also get to > > > see more than one, and also need to choose which they use. > > > > Where do these addresses come from? They always come from: > > > > a) manual configuration > > b) a name resolution process. > > c) a communicating peer as part of the application layer protocol > > > > Ask yourself where the peer got the address. Repeat until you get > > either a) or b) as the answer. > > nope. you're completely wrong about that. The above is simple logic. It's not right or wrong, it just is. However, you're right that the interesting place is at the node of origin, where the application interacts with the APIs on that node. That's what I was trying to get people to focus on. > and even to the extent that > addresses do come from manual configuration or name resolution, (a) to > cope with a mixture of routable and LL addresses often requires a change > to existing applications and (b) there is no fix that allows > applications to work with a mixture of LL and routable addresses in all > cases. in general the application doing the referral has no idea > whether the address will be usable to the party who eventually wants to > use it. I think we agree on most of that. Our disagreements relate to how to best cope with that. Applications are stupid. They don't go to great lengths to find out all the addresses a node has. Typically, they just use an API to get one address and then they use it. Most commonly, this API is the host resolver API, although there are other possibilities as well. Proper design of the APIs can minimize the chance that applications will get hold of a LL address, even if the node has both LL and routable addresses. It's not a perfect approach, but it very often works. Naturally, this WG can't require OS vendors to redesign their APIs or force application vendors to rewrite their applications. However, this WG could give advice on those issues. Unfortunately, this WG apparently has decided to focus on something it *can* affect direcly, choosing to kludge the TCPIP stack in order to work around the problems. That is understandable, however, let's be honest about it and not confuse it with good overall design. MikaL From owner-zeroconf@merit.edu Wed Feb 12 18:01:52 2003 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 SAA18474 for ; Wed, 12 Feb 2003 18:01:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0974D9125A; Wed, 12 Feb 2003 18:05:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF2969125C; Wed, 12 Feb 2003 18:05:24 -0500 (EST) 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 497379125A for ; Wed, 12 Feb 2003 18:04:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id A72ED5DEB1; Wed, 12 Feb 2003 18:04:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 8E82A5DDEB for ; Wed, 12 Feb 2003 18:04:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5C2201406C; Wed, 12 Feb 2003 18:04:02 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 13637-08; Wed, 12 Feb 2003 18:04:01 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id B68CD14068; Wed, 12 Feb 2003 18:04:01 -0500 (EST) Date: Wed, 12 Feb 2003 18:03:58 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: WG consensus action: when to configure LL addrs Message-Id: <20030212180358.305dc539.moore@cs.utk.edu> In-Reply-To: <1045090511.4847.93.camel@devil> References: <1044787452.11519.93.camel@devil> <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> <3689.1044783115@munnari.OZ.AU> <4300.1044789975@munnari.OZ.AU> <1044793681.21186.107.camel@devil> <20030212164415.5772a277.moore@cs.utk.edu> <1045090511.4847.93.camel@devil> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 17fc2f64272515289dfe48b817306e708237e447 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > > Where do these addresses come from? They always come from: > > > > > > a) manual configuration > > > b) a name resolution process. > > > c) a communicating peer as part of the application layer protocol > > > > > > Ask yourself where the peer got the address. Repeat until you get > > > either a) or b) as the answer. > > > > nope. you're completely wrong about that. > > The above is simple logic. It's not right or wrong, it just is. no, it's a false assumption. applying logic to false assumptions does not say anything about the validity of the conclusion. > However, you're right that the interesting place is at the node of > origin, where the application interacts with the APIs on that node. it's not even always the same application as the one in question. and messing with those APIs in order to mislead applications breaks another set of apps. nor can you hope to solve the problem by changing the APIs because the API implementation has no idea about what the needs of the application are. Keith From owner-zeroconf@merit.edu Wed Feb 12 18:08:24 2003 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 SAA18568 for ; Wed, 12 Feb 2003 18:08:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A31239125D; Wed, 12 Feb 2003 18:10:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64E1791263; Wed, 12 Feb 2003 18:10:52 -0500 (EST) 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 1FD129125D for ; Wed, 12 Feb 2003 18:10:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0DFBB5E03C; Wed, 12 Feb 2003 18:10:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id E6A395E039 for ; Wed, 12 Feb 2003 18:10:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id B6F031406C; Wed, 12 Feb 2003 18:10:46 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 15251-02; Wed, 12 Feb 2003 18:10:46 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 18D9714068; Wed, 12 Feb 2003 18:10:46 -0500 (EST) Date: Wed, 12 Feb 2003 18:10:45 -0500 From: Keith Moore To: Markku Savela Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL usage example: LL-only homenetwork with single global address + NAT Message-Id: <20030212181045.5c4341cb.moore@cs.utk.edu> In-Reply-To: <200302122240.h1CMe9gg003689@burp.tkv.asdf.org> References: <200302122240.h1CMe9gg003689@burp.tkv.asdf.org> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: f0f7b06f75e6cb50ce8779653e589684fdf271e1 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 13 Feb 2003 00:40:09 +0200 Markku Savela wrote: > This not related specifically to any issue, but I just thought to > remind of this potential usage of Ipv4 link local (probably this has > be mentioned here): > > - a home network with multiple machines (printers and maybe others) > > - nodes at home network are LL only (automatic configuration, just > plug in the devices). Easy to use. easy to use, and dysfunctional. when vendors make broken devices you cannot expect them to work well. > - then they get link to internet, but the nasty ISP gives only one > global IP-address. not something that this group can fix. IPv6 helps a lot, and it already has a good solution for configuration. local router can support IPv6 and IPv4+NAT on local net, native IPv6 or IPv4+6to4 or Teredo on external connection. IPv6 device configuration already works better than v4LL. > Thus, the user gets > > - a gateway router perfoming the ugly NAT service for outbound > connections > > Above configuration would "break" a few points that have been > discussed here: > > - nodes DO NEED to packets with LL-source and global destination to > the NAT/Router/Gateway for FORWARDING. no they don't. if anything, nodes on such a network should get routable (RFC 1918) addresses from the evil NAT's DHCP server. as bad as it is, it's better than trying to figure out how to make nodes originate traffic with an external destination and an LL source. this just illustrates that LL-only nodes are a bad idea. From owner-zeroconf@merit.edu Wed Feb 12 18:16:12 2003 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 SAA18619 for ; Wed, 12 Feb 2003 18:16:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F028F9125F; Wed, 12 Feb 2003 18:19:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0B0A91261; Wed, 12 Feb 2003 18:19:45 -0500 (EST) 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 0CD999125F for ; Wed, 12 Feb 2003 18:17:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id DD8B25DFE8; Wed, 12 Feb 2003 18:17:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 1276B5DE60 for ; Wed, 12 Feb 2003 18:17:54 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1CNITaj011365; Thu, 13 Feb 2003 01:18:29 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1CNIS1P011364; Thu, 13 Feb 2003 01:18:28 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG consensus action: when to configure LL addrs From: Mika Liljeberg To: Keith Moore Cc: kre@munnari.OZ.AU, zeroconf@merit.edu In-Reply-To: <20030212180358.305dc539.moore@cs.utk.edu> References: <1044787452.11519.93.camel@devil> <8BF39131-3BA5-11D7-A2AE-00039367340A@nominum.com> <3689.1044783115@munnari.OZ.AU> <4300.1044789975@munnari.OZ.AU> <1044793681.21186.107.camel@devil> <20030212164415.5772a277.moore@cs.utk.edu> <1045090511.4847.93.camel@devil> <20030212180358.305dc539.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045091907.4848.103.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 13 Feb 2003 01:18:28 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-02-13 at 01:03, Keith Moore wrote: > > > > Where do these addresses come from? They always come from: > > > > > > > > a) manual configuration > > > > b) a name resolution process. > > > > c) a communicating peer as part of the application layer protocol > > > > > > > > Ask yourself where the peer got the address. Repeat until you get > > > > either a) or b) as the answer. > > > > > > nope. you're completely wrong about that. > > > > The above is simple logic. It's not right or wrong, it just is. > > no, it's a false assumption. applying logic to false assumptions does > not say anything about the validity of the conclusion. You forgot to explain what the false assumption is. > > However, you're right that the interesting place is at the node of > > origin, where the application interacts with the APIs on that node. > > it's not even always the same application as the one in question. Say what? I'm afraid my school english gave up on that sentence. > and messing with those APIs in order to mislead applications breaks > another set of apps. I was talking about overall design, not "messing with APIs". Although you confusing the two just goes to prove my point. > nor can you hope to solve the problem by changing > the APIs because the API implementation has no idea about what the needs > of the application are. The problem cannot be solved. You said so yourself. It can be mitigated. Good API design is one way to do that. MikaL From owner-zeroconf@merit.edu Wed Feb 12 18:31:59 2003 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 SAA18774 for ; Wed, 12 Feb 2003 18:31:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 24B2491261; Wed, 12 Feb 2003 18:35:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E07DE91262; Wed, 12 Feb 2003 18:35:33 -0500 (EST) 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 DF0FB91261 for ; Wed, 12 Feb 2003 18:35:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id BF14B5DE23; Wed, 12 Feb 2003 18:35:31 -0500 (EST) 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 8A8345DDEB for ; Wed, 12 Feb 2003 18:35:31 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 945BE598A5; Wed, 12 Feb 2003 23:35:15 +0000 (GMT) Message-ID: <020a01c2d2ef$63438020$131010ac@aldebaran> From: "Philip Nye" To: "Keith Moore" , "Markku Savela" Cc: , References: <200302122240.h1CMe9gg003689@burp.tkv.asdf.org> <20030212181045.5c4341cb.moore@cs.utk.edu> Subject: Re: LL usage example: LL-only homenetwork with single global address + NAT Date: Wed, 12 Feb 2003 23:35:01 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > - nodes DO NEED to packets with LL-source and global destination to > > the NAT/Router/Gateway for FORWARDING. > > no they don't. if anything, nodes on such a network should get routable > (RFC 1918) addresses from the evil NAT's DHCP server. as bad as it is, > it's better than trying to figure out how to make nodes originate > traffic with an external destination and an LL source. > > this just illustrates that LL-only nodes are a bad idea. And that LL addresses are not just an autoconfigured equivalent of 1918 addresses and do not have the same functionality. Philip From owner-zeroconf@merit.edu Thu Feb 13 03:52:51 2003 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 DAA07337 for ; Thu, 13 Feb 2003 03:52:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 83CC291212; Thu, 13 Feb 2003 03:56:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 59C0191214; Thu, 13 Feb 2003 03:56:27 -0500 (EST) 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 55A8391212 for ; Thu, 13 Feb 2003 03:56:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F5015DE18; Thu, 13 Feb 2003 03:56:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id A610D5DE2E for ; Thu, 13 Feb 2003 03:55:21 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1D8rlq07950; Thu, 13 Feb 2003 15:53:50 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1D8rXb04192; Thu, 13 Feb 2003 15:53:34 +0700 (ICT) From: Robert Elz To: Keith Moore Cc: Erik.Guttman@Sun.COM, mika.liljeberg@welho.com, zeroconf@merit.edu Subject: Re: Proposed text for LL2 In-Reply-To: <20030211085137.2918d9c7.moore@cs.utk.edu> References: <20030211085137.2918d9c7.moore@cs.utk.edu> <20030210122608.50d3d478.moore@cs.utk.edu> <1044796483.21383.156.camel@devil> <19889.1044953652@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Feb 2003 15:53:33 +0700 Message-ID: <4190.1045126413@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 11 Feb 2003 08:51:37 -0500 From: Keith Moore Message-ID: <20030211085137.2918d9c7.moore@cs.utk.edu> | well, we need a uniform mechanism for all of these devices | (else networks have to guess as to which mechanisms are necessary), No, I disagree with that. It would certainly help to have a uniform mechanism, as as much as vendors want to keep customers happy, I'd expect that a uniform mechanism (likely to be DHCP) will be what happens. But for the requirements here, there is no need for that - if I need to have a DHCP server (also able to do BOOTP) a RARP server, a MOP server, a ... server on my net, that is possible. What is necessary is that there be some way to configure the devices, and if that means that devices come with a CD and instructions "boot this on your windows machine before connecting the device" then that suffices, even if what then happens is some totally non-standard proprietary protocol. I personally wouldn't buy any such thing, but that's not what counts. kre From owner-zeroconf@merit.edu Thu Feb 13 04:04:03 2003 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 EAA07507 for ; Thu, 13 Feb 2003 04:04:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7D1AA91216; Thu, 13 Feb 2003 04:07:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 488C19121A; Thu, 13 Feb 2003 04:07:16 -0500 (EST) 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 69A5891216 for ; Thu, 13 Feb 2003 04:07:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 835375DF36; Thu, 13 Feb 2003 04:07:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 44DE95DE18 for ; Thu, 13 Feb 2003 04:06:58 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1D963q15058; Thu, 13 Feb 2003 16:06:03 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1D95lb04214; Thu, 13 Feb 2003 16:05:47 +0700 (ICT) From: Robert Elz To: Keith Moore Cc: Erik Guttman , zeroconf@merit.edu Subject: Re: Corection: new issue: [LL23] Don't configure needless LL addresses In-Reply-To: <20030211094716.07becbb1.moore@cs.utk.edu> References: <20030211094716.07becbb1.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Feb 2003 16:05:47 +0700 Message-ID: <4212.1045127147@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 11 Feb 2003 09:47:16 -0500 From: Keith Moore Message-ID: <20030211094716.07becbb1.moore@cs.utk.edu> | 1. this is not sufficient by itself. there must be a uniform way for | networks to give hosts routable addresses, See my previous message, (just a few minutes ago), I don't think that is required. | ... unless explicitly (manually?) configured to do so. Fine. | ...as a source address... Fine. | ...unless the application unambiguously specifies that another address be | used. Fine. | > > and MUST cease advertising the availability of the link-local address | > > through whatever mechanisms that address had been made known to others. | | this is not, in general, a host function - imposing MUST on something | the host does not control does not seem like a good idea. No, with LL addresses, it must be a host function - the host invents its own address, the only way that the host can ever be found, is when the host makes that address known to others (somehow). That's what I call "advertising" it. Any number of methods might exist by which this is done, but they all necessarily originate at the host. Once a routable address is available (under this proposal) the host must no longer tell anyone else about its LL address via whatever this advertising mechanism happens to be (which says nothing at all about what may have happened prior to this, nor does it require the host to use the same mechanisms for its routable address, which may be inappropriate). So, I don't think we need your suggested change there. kre From owner-zeroconf@merit.edu Thu Feb 13 04:08:16 2003 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 EAA07572 for ; Thu, 13 Feb 2003 04:08:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 499D89121A; Thu, 13 Feb 2003 04:11:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1331E9121E; Thu, 13 Feb 2003 04:11:53 -0500 (EST) 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 2B6FC9121A for ; Thu, 13 Feb 2003 04:11:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 685065DF43; Thu, 13 Feb 2003 04:11:52 -0500 (EST) 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 0F5F85DF66 for ; Thu, 13 Feb 2003 04:11:52 -0500 (EST) 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 CAA20110 for ; Thu, 13 Feb 2003 02:11:50 -0700 (MST) 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 h1D9Bnl19234 for ; Thu, 13 Feb 2003 10:11:49 +0100 (MET) Date: Thu, 13 Feb 2003 10:11:47 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: discussion on zeroconf issues In-Reply-To: <4190.1045126413@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Folks, Please try to focus on the items which are up for WG last call. The criteria for influencing the decision at the end of the last call is not number, length or vehemence of postings from a single contributor. Rather, we will consider the technical merit of the postings and the breadth of support. The goal is not to convince each other individually. For example, there is no requirement to get the submitter of an issue to agree they have made a mistake. Rather, we need to get our different views on the table expressed clearly so we can make a determination. We must of course debate assertions which we do not agree with. Debate means: bringing up specific technical arguments, backed up with examples and practical concerns that have not been brought up yet. Thanks, Erik ZEROCONF WG cochair From owner-zeroconf@merit.edu Thu Feb 13 05:03:54 2003 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 FAA08395 for ; Thu, 13 Feb 2003 05:03:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A1AA09121E; Thu, 13 Feb 2003 05:07:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F78391222; Thu, 13 Feb 2003 05:07:29 -0500 (EST) 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 48E4A9121E for ; Thu, 13 Feb 2003 05:07:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F2825DD9F; Thu, 13 Feb 2003 05:07:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 9AAAB5DDD2 for ; Thu, 13 Feb 2003 05:07:18 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1DA66q20914; Thu, 13 Feb 2003 17:06:07 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1DA5tb04323; Thu, 13 Feb 2003 17:05:57 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: LL16 Split references In-Reply-To: <200302120333.h1C3Xaf11872@scv3.apple.com> References: <200302120333.h1C3Xaf11872@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Feb 2003 17:05:55 +0700 Message-ID: <4321.1045130755@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 11 Feb 2003 19:33:36 -0800 From: Stuart Cheshire Message-ID: <200302120333.h1C3Xaf11872@scv3.apple.com> I can't imagine what this has to do with LL16, but ... | I hinted last week about devices that use IPv4LL for communication | between components inside a single computer chassis. | | This week Apple publicly announced the first of these devices. | | I think you're not understanding the reason for MUSTs etc in RFCs. | Xserve RAID includes hot-swappable modules. These modules have to | communicate internally. How do they communicate? Via PCI? No. they | communicate via Ethernet, using IPv4LL addresses. I've had a quick(ish) look at that web page, and PDF files of specs available from it, and I can't find a thing about IP, or Link Local addresses. I'm not trying to say you're making this up - of course not. What I am saying is that there's no reason for Apple to mention any of the internal details of how their device operates. For the same reason, there's no reason for them to claim they conform, or even actually conform, with any of the IETF's (or anyone else's) standards. You justify the use of ethernet for communications in your message, and that's fine (not that I care anyway, what would matter to me would be whether the device performs adequately, not what kind of wiring is installed). But for all anyone can tell, not that anyone would care, even if we know you're using ethernet, you could just as well be using Ethertalk, rather than IP, and the device would appear identical. I have no doubt there are reasons for the choice of IP, but none of them are going to be relevant to us - that's all internal Apple engineering decisions. Even given that Apple have decided to use IP, there's no particular reason they should be using 169.254 - even if the desire is to do random addresses (ie: no configuration) the device would work just the same if it used network 10, or 172.16 or 192.168.1 or something, wouldn't it? There's no way anyone from outside can ever see, no reason for anyone outside to ever care, and no reason (aside from your attempts to argue here) for Apple to even ever tell anyone what they're doing in this area. The purpose of open standards (like the IETFs) is so that people can say "we do it the way the standard specifies", so that others can know that if they select the device in question, it will (or should) interoperate correctly with other devices that they want it to interoperate with. If that is irrelevant to some particular purpose, anyone is free to take any IETF standard, and bend, mutilate, and spindle it to meet their own needs - that is, to take some of the ideas, and make use of them in other ways that are anything from close to, to completely different from the intent of the IETF standard. They can ignore MUST and MUST NOT however much suits them, as they're never going to be claiming that they're actually supporting the standard - they're just taking the ideas. Ignoring the lineage of the LL address stuff, that's what Apple are apparently doing here. No-one is going to stop them, no-one is going to care which parts of the spec they are using, and which parts they're ignoring. That is, nothing about what the IETF says need have any effect whatever on how this particular device (or others that might be similar, from the same or other sources) works - in some cases the IETF spec might contain some ideas and rules from the experience of the people writing it, which might be worth noting, or being aware of, but nothing in an IETF spec is ever mandatory for anyone. You just don't get to claim to conform to the spec if you don't (that would be fraud, or misleading advertising, and could cause trouble). Here no-one is claiming anything about LL address usage - so even if the spec does end up requiring DHCP clients in all LL nodes, there's no reason for Apple to take any notice of that, all they need to do is convince themselves that it will never be useful. kre From owner-zeroconf@merit.edu Thu Feb 13 05:08:04 2003 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 FAA08498 for ; Thu, 13 Feb 2003 05:08:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 033E691222; Thu, 13 Feb 2003 05:11:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C330291225; Thu, 13 Feb 2003 05:11:39 -0500 (EST) 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 D367C91222 for ; Thu, 13 Feb 2003 05:11:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id B06315DDD2; Thu, 13 Feb 2003 05:11:38 -0500 (EST) 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 2123D5DD9F for ; Thu, 13 Feb 2003 05:11:38 -0500 (EST) 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 DAA21650 for ; Thu, 13 Feb 2003 03:11:36 -0700 (MST) 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 h1DABZl21326 for ; Thu, 13 Feb 2003 11:11:35 +0100 (MET) Date: Thu, 13 Feb 2003 11:11:34 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: [LL6] Add security considerations note regarding wireless LANs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk [WG chair hat off] I accept the issue, and the recommended text. Erik From owner-zeroconf@merit.edu Thu Feb 13 05:09:57 2003 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 FAA08543 for ; Thu, 13 Feb 2003 05:09:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3A41A91225; Thu, 13 Feb 2003 05:13:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E3D791226; Thu, 13 Feb 2003 05:13:29 -0500 (EST) 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 206BB91225 for ; Thu, 13 Feb 2003 05:13:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id E2F405DF43; Thu, 13 Feb 2003 05:13:28 -0500 (EST) 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 6B1FB5DD9F for ; Thu, 13 Feb 2003 05:13:28 -0500 (EST) 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 CAA02377 for ; Thu, 13 Feb 2003 02:13:26 -0800 (PST) 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 h1DADPl21347 for ; Thu, 13 Feb 2003 11:13:25 +0100 (MET) Date: Thu, 13 Feb 2003 11:13:23 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: [LL8] Is additional Routing Considerations text needed? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk [WG chair hat off] I accept the issue (that none of the questions raised are left unanswered). I support the additional text supplied by Robert Elz in Message-ID: <3825.1044786071@munnari.OZ.AU> Routing Protocols The link local address block (169.254/16) MUST NOT be included as a reachable prefix in any dynamic routing protocol. Subnets of that address block (which should not exist - see sect N.M) MUST NOT be included either. Responding to "s. goswami" Message-ID: > So this also precludes a router between two 169.254/16 networks, > right ? Yes, this is definitely precluded. Addresses in this prefix are *link-local.* Erik From owner-zeroconf@merit.edu Thu Feb 13 05:16:20 2003 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 FAA08609 for ; Thu, 13 Feb 2003 05:16:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 089BF91243; Thu, 13 Feb 2003 05:19:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30B9B91228; Thu, 13 Feb 2003 05:19:33 -0500 (EST) 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 88AC491239 for ; Thu, 13 Feb 2003 05:17:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 61A845DF45; Thu, 13 Feb 2003 05:17:25 -0500 (EST) 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 CCB9C5DF36 for ; Thu, 13 Feb 2003 05:17:24 -0500 (EST) 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 DAA24531 for ; Thu, 13 Feb 2003 03:17:23 -0700 (MST) 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 h1DAHMl21672 for ; Thu, 13 Feb 2003 11:17:22 +0100 (MET) Date: Thu, 13 Feb 2003 11:17:21 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: [LL11] Add security consideration for the threat where an attacker forces address reconfiguration Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk [WG chair hat off] I accept the issue. I accept Robert Elz's proposed text: "Implementations and users should also note that a node that gives up an address and reconfigures, as required by section 2.5, allows the possibility that another node can easily successfully hijack existing TCP connections. Before abandoning an address due to a conflict, hosts SHOULD actively attempt to reset any existing connections using that address." I agree with Philip Nye: > (though on an editorial note I would delete "easily successfully"). Erik From owner-zeroconf@merit.edu Thu Feb 13 05:16:22 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08623 for ; Thu, 13 Feb 2003 05:16:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F2FBA91226; Thu, 13 Feb 2003 05:16:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3A4E91234; Thu, 13 Feb 2003 05:16:45 -0500 (EST) 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 091A991228 for ; Thu, 13 Feb 2003 05:16:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 78C4A5DF45; Thu, 13 Feb 2003 05:16:16 -0500 (EST) 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 ECED65DD9F for ; Thu, 13 Feb 2003 05:16:15 -0500 (EST) 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 DAA00075 for ; Thu, 13 Feb 2003 03:16:14 -0700 (MST) 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 h1DAGDl21583 for ; Thu, 13 Feb 2003 11:16:13 +0100 (MET) Date: Thu, 13 Feb 2003 11:16:12 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: [LL10] Add warnings to applicability statement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk [WG chair hat off] I reject the rewording as stated, as it is too restrictive. The applicability of v4LL should not be predicated on the least functional of *all* applications run on a host. It may be the case that some applications do break. Users will potentially have to get new versions one day to support both local and global use, and their transitions. I understand that this view is not shared, but it is my view. It is OK to break some applications when introducing new functionality. Microsoft has shown that it is possible to introduce new versions of network applications which can be resilient to address renumbering events. I accept the revised text from Philip Nye as modified by Keith Moore. (I gathered it up without changing it, I hope. The postings on this issue got a little confusing. Anyway, I agree with the text below.) IPv4 link-local addresses and their dynamic configuration have profound implications upon applications which use them. This is discussed in Section 7. Many applications fundamentally assume that addresses of communicating peers are routable, relatively unchanging and unique. These assumptions no longer hold with IPv4 link-local addresses, or a mixture of link-local and routable addresses. Therefore while many applications will work properly with LL addresses, or a mixture of LL and routable addresses, others may do so only after modification, or will exhibit reduced or partial functionality. In some cases it may be infeasible for the application to be modified to operate under such conditions. IPv4 link-local addresses should therefore only be used where stable, routable addresses are not available (such as on ad hoc or isolated networks) or in controlled situations where these limitations and their impact on applications are understood and accepted. Erik From owner-zeroconf@merit.edu Thu Feb 13 05:16:49 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08639 for ; Thu, 13 Feb 2003 05:16:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 04D7E91252; Thu, 13 Feb 2003 05:19:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B555291239; Thu, 13 Feb 2003 05:19:34 -0500 (EST) 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 8678A91243 for ; Thu, 13 Feb 2003 05:19:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A64B5DF45; Thu, 13 Feb 2003 05:19:20 -0500 (EST) 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 E07B65DF43 for ; Thu, 13 Feb 2003 05:19:19 -0500 (EST) 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 DAA22929 for ; Thu, 13 Feb 2003 03:19:18 -0700 (MST) 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 h1DAJHl21747 for ; Thu, 13 Feb 2003 11:19:17 +0100 (MET) Date: Thu, 13 Feb 2003 11:19:16 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: [LL16] Split references Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk [WG chair hat off] I accept the issue and Stuart's split. I agree that we have to wait for the resolution of LL2, etc before we can decide whether DHCP is normative or informative. Erik From owner-zeroconf@merit.edu Thu Feb 13 05:16:57 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08652 for ; Thu, 13 Feb 2003 05:16:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 37FFC91234; Thu, 13 Feb 2003 05:19:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DBD759125D; Thu, 13 Feb 2003 05:19:40 -0500 (EST) 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 B6D9391242 for ; Thu, 13 Feb 2003 05:19:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9A09E5DF45; Thu, 13 Feb 2003 05:19:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 196D05DF43 for ; Thu, 13 Feb 2003 05:19:02 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1DAIhq28892; Thu, 13 Feb 2003 17:18:43 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1DAIMb04346; Thu, 13 Feb 2003 17:18:22 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: LL11 Add security consideration for the threat where an attacker forces address reconfiguration In-Reply-To: <200302120332.h1C3WHQ02980@scv2.apple.com> References: <200302120332.h1C3WHQ02980@scv2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Feb 2003 17:18:22 +0700 Message-ID: <4344.1045131502@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 11 Feb 2003 19:32:18 -0800 From: Stuart Cheshire Message-ID: <200302120332.h1C3WHQ02980@scv2.apple.com> | Robert Elz suggested that a host send TCP resets before giving up its | address. This sounds like a good idea, and I would not oppose this new | text. Thinking about this afterwards, there's actually another mechanism that could be used (I suspect reset is likely best, but ...) That is, a node on having its address "stolen" by another node, can do what the draft currently says, and just go allocate itself a new address (the new address allocation has never been the issue here) but not release the old one - that is, continue to defend it to the death, forever (or at least until there is no longer any reasonable possibility that any old connections using the old address survive). That would, essentially, remove the one real difference between the LL spec, and what has always happened in the past when there are address conflicts. That is, the new problem that the LL spec introduces, is that it requires nodes to abandon their address in the event of a conflict. That's new, and that's what leads to the problem. | However, I do not agree with the entire analysis. | I disagee that it is a new threat. I agree, it is possible today to hijack connections. Where the LL spec makes a difference is that it (currently) requires the node being hijacked to meekly go along with the hijack attempt - that is, it is required to give up its address (and though the text doesn't say so, one presumes also to cease sending packets claiming to originate from that address). All of this makes hijack attempts much simpler than currently - that is, not new (there's nothing new ...) but easier to perform with less effort. All that is actually being asked for here is more text in the security considerations. I don't think it is too much, nor do I think it is misleading anyone into believing that LL addresses are lots worse when compared with others - it isn't even the addresses (or their allocation here) that this note is about - but the practice of simply stopping using them in the event of a conflict. In the attack your described, nothing causes the victim to stop sending packets to its peer - receiving those packets can often cause the peer to reset the connection (depends upon what happens with sequence numbers etc), with the current LL scheme, the peer will never see anything odd at all. kre From owner-zeroconf@merit.edu Thu Feb 13 05:17:34 2003 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 FAA08670 for ; Thu, 13 Feb 2003 05:17:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5EDC991228; Thu, 13 Feb 2003 05:21:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2241491239; Thu, 13 Feb 2003 05:21:11 -0500 (EST) 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 2A48C91228 for ; Thu, 13 Feb 2003 05:21:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0E86F5DF45; Thu, 13 Feb 2003 05:21:10 -0500 (EST) 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 B39595DD9F for ; Thu, 13 Feb 2003 05:21:09 -0500 (EST) 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 DAA02520 for ; Thu, 13 Feb 2003 03:21:08 -0700 (MST) 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 h1DAL7l21821 for ; Thu, 13 Feb 2003 11:21:07 +0100 (MET) Date: Thu, 13 Feb 2003 11:21:05 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk [WG chair hat off] I accept the issue but not the requested text. 1) I agree however that the text is unclear in that the text should be restructured to support 2 distinct sections one for source address selection, the other for destination address resolution, see [LL26] 2) The text implies that a host should use a LL address if it has a LL address and a configured address. I believe this is a mistake and should not be implied. This really depends on the outcome of [LL1] which has not yet been decided. Presently the requested text says: 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 MUST 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 the destination on the same physical link. I recommend the following revised text: If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), then it MUST 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 the destination on the same physical link. Erik From owner-zeroconf@merit.edu Thu Feb 13 05:18:39 2003 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 FAA08684 for ; Thu, 13 Feb 2003 05:18:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1E54B91239; Thu, 13 Feb 2003 05:22:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE4709123F; Thu, 13 Feb 2003 05:22:15 -0500 (EST) 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 E24D691239 for ; Thu, 13 Feb 2003 05:22:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id CE7925DF43; Thu, 13 Feb 2003 05:22:14 -0500 (EST) 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 53D275DD9F for ; Thu, 13 Feb 2003 05:22:14 -0500 (EST) 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 CAA07704 for ; Thu, 13 Feb 2003 02:22:08 -0800 (PST) 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 h1DAM7l21893 for ; Thu, 13 Feb 2003 11:22:07 +0100 (MET) Date: Thu, 13 Feb 2003 11:22:05 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: [LL19] Do not use v4LL source address to non-v4LL destinations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk [WG chair hat off] I reject this issue. It is important in my mind to be able to support hosts functioning during transition from use of LL to configured addresses. This will occur at different times. It is unacceptable if hosts become unreachable. Erik From owner-zeroconf@merit.edu Thu Feb 13 05:18:59 2003 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 FAA08699 for ; Thu, 13 Feb 2003 05:18:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B52B29123F; Thu, 13 Feb 2003 05:22:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8710D91242; Thu, 13 Feb 2003 05:22:37 -0500 (EST) 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 958279123F for ; Thu, 13 Feb 2003 05:22:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 80AAC5DF43; Thu, 13 Feb 2003 05:22:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id BE0475DD9F for ; Thu, 13 Feb 2003 05:22:34 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1DALoq00882; Thu, 13 Feb 2003 17:21:50 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1DALkb04361; Thu, 13 Feb 2003 17:21:47 +0700 (ICT) From: Robert Elz To: "s. goswami" Cc: zeroconf@merit.edu Subject: Re: LL17, LL8 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Feb 2003 17:21:46 +0700 Message-ID: <4359.1045131706@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 12 Feb 2003 12:52:52 -0500 (EST) From: "s. goswami" Message-ID: | "The host MUST NOT send the packet to any router for forward" What this is really trying to say is that the node must not deliberately send packets to something it knows is not the final intended destination, with the expectation that that other node will send the packets to the destination (LL nodes should send directly to the destination in all cases). That's all it is trying to say - perhaps different wording to achieve the same effect could be found (to me it is clear enough and obvious enough as it is). kre From owner-zeroconf@merit.edu Thu Feb 13 05:21:33 2003 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 FAA08727 for ; Thu, 13 Feb 2003 05:21:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 08E1791242; Thu, 13 Feb 2003 05:25:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C08F89125D; Thu, 13 Feb 2003 05:25:07 -0500 (EST) 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 CAD4791242 for ; Thu, 13 Feb 2003 05:25:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id AE63A5DF45; Thu, 13 Feb 2003 05:25:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id DFC165DD9F for ; Thu, 13 Feb 2003 05:25:04 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1DAOdq02654; Thu, 13 Feb 2003 17:24:39 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1DAOWb04372; Thu, 13 Feb 2003 17:24:33 +0700 (ICT) From: Robert Elz To: Markku Savela Cc: zeroconf@merit.edu Subject: Re: LL usage example: LL-only homenetwork with single global address + NAT In-Reply-To: <200302122240.h1CMe9gg003689@burp.tkv.asdf.org> References: <200302122240.h1CMe9gg003689@burp.tkv.asdf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Feb 2003 17:24:32 +0700 Message-ID: <4370.1045131872@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 13 Feb 2003 00:40:09 +0200 From: Markku Savela Message-ID: <200302122240.h1CMe9gg003689@burp.tkv.asdf.org> | - nodes DO NEED to packets with LL-source and global destination to | the NAT/Router/Gateway for FORWARDING. If this was ever to actually happen (I suspect that switching to use 1918 addresses on the internal link is what would normally be expected, the NAT/Router/Gateway normally does DHCP as well...) then the solution for this would be for the NAT/Router/Gateway to also proxy ARP. Then the end node believes that it is communicating directly with the destination, and not forwarding through a router, and no rules are broken. Also ... | - LL-only nodes need to install default route for the gateway would no longer be true. kre From owner-zeroconf@merit.edu Thu Feb 13 05:46:10 2003 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 FAA08980 for ; Thu, 13 Feb 2003 05:46:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC6A39125F; Thu, 13 Feb 2003 05:49:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA1A591261; Thu, 13 Feb 2003 05:49:46 -0500 (EST) 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 B42139125F for ; Thu, 13 Feb 2003 05:49:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 875475DDA1; Thu, 13 Feb 2003 05:49:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id F38DC5DD9F for ; Thu, 13 Feb 2003 05:49:43 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1DAnUq16534 for ; Thu, 13 Feb 2003 17:49:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1DAnNb04415 for ; Thu, 13 Feb 2003 17:49:23 +0700 (ICT) From: Robert Elz To: zeroconf@merit.edu Subject: New Issue: Applicability of Document Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Feb 2003 17:49:23 +0700 Message-ID: <4413.1045133363@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Description of Issue: Applicability of Document Submitter Name: Robert Elz Submitter Email Address: kre@munnari.OZ.AU Date first submitted: 2003-02-13 Reference: Comment Type ['T'echnical | 'E'ditorial]: E Priority ['S' Must fix | '1' Should fix | '2' May fix ]: 1 Section: 1.2 Rationale/Explanation of issue: It isn't clear just which types of networks which parts of the spec apply to, and/or whether some parts of the spec apply to all link levels Lengthy description of problem: Section 1.2 starts off saying "The specifications in this document apply to any IEEE 802 media" and then later says ... "Link-layer network technologies that do not support ARP may be able to use other techniques ..." This leads to confusion as to whether or not anything in this document is applicable to the use of LL addresses on anything other than IEEE 802 media. Requested Change: Change the first paragraph of section 1.2 to read Link-local addresses as defined in this document, and the methods by which they are used, and not to be used, once acquired, apply in general to any network technology. The specification of how link local addresses are initially acquired, and then later defended, and in particular, the timers to be used, vary from network technology to network technology, and will in general be described in other documents as required in the future. Because IEEE 802 media, including Ethernet (IEEE 802.3), are very commonly used, particularly in environments where link-local addresses are likely to be most desired, this document includes the specification of how link-local addresses are to be acquired and defended using such media. Whenever this document uses the term "Ethernet", that should be read to include any other network technology that uses ARP [RFC826] for IP address resolution, operates at a data rate of at least one megabit per second, and has a round trip latency of no more than one second. Then continue with what is currently the second paragraph (etc). kre From owner-zeroconf@merit.edu Thu Feb 13 06:33:42 2003 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 GAA09753 for ; Thu, 13 Feb 2003 06:33:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A816291261; Thu, 13 Feb 2003 06:37:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79CE99126D; Thu, 13 Feb 2003 06:37:18 -0500 (EST) 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 5B84791261 for ; Thu, 13 Feb 2003 06:37:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3B5E25DE74; Thu, 13 Feb 2003 06:37:17 -0500 (EST) 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 AECAC5DF48 for ; Thu, 13 Feb 2003 06:37:16 -0500 (EST) 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 EAA06582 for ; Thu, 13 Feb 2003 04:37:15 -0700 (MST) 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 h1DBbEl24315 for ; Thu, 13 Feb 2003 12:37:14 +0100 (MET) Date: Thu, 13 Feb 2003 12:37:12 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: new issue: [LL27] LL-only hosts are out of scope for this specification Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Please also see http://www.spybeam.org/ll27.html The text of the issue follows: Description of issue: LL-only hosts are out of scope for this specification Submitter name: Keith Moore Submitter email address: moore@cs.utk.edu Date first submitted: 11 February 2003 Reference: Comment type: T Priority: S Rationale: The Internet Engineering Task Force develops specifications which, when followed, should permit interoperation of conforming implementations on the Internet. With very few exceptions, IETF has considered the behavior of private networks (i.e. networks that are entirely controlled by a single party) as outside of its scope. (Use of the Internet Protocol on purely isolated, ad hoc networks would also be out-of-scope and of little interest to IETF -- except that some interchange between hosts using link-local addresses and hosts using routable addresses is unavoidable, and that absent careful consideration of the effects of such interchange, introduction of link-local addressing to IPv4 would be expected to adversely affect the ability of hosts and applications to interoperate over the Internet.) Inherent in the entire concept of "INTERnet", and the "Internet Protocol" is the ability to communicate _between_ networks. Devices which don't support that ability should not claim conformance to IP or compatibility with the Internet, and IETF should not be blessing specifications that encourage the creation of a class of devices (and applications) that inherently cannot interoperate with the Internet. Requested change: Insert this section at an appropriate place in the document: ---- ##. Hosts which implement only link-local addressing Inherent in the entire concept of "Internet" is the ability to communicate between (not just within) networks, and the Internet Protocol was designed specifically to facilitate communication between hosts on potentially dissimilar, and perhaps distant, networks. Hosts which are inherently incapable of communicating with hosts on other IP networks cannot meaningfully be said to implement the Internet Protocol, or to support Internet connectivity, even if they use similar packet formats. Hosts which are incapable of being configured to use routable addresses, or are incapable of being configured to route packets with nonlocal destinations to a router, or which are incapable of exchanging traffic with hosts on other IP networks, are therefore outside of the scope of this specification. While hosts with such limitations may still be useful in specific contexts, it is not appropriate for such hosts to claim conformance with this specification, or with the Internet Protocol, or compatibility with the Internet. In order to clearly distinguish hosts that implement link-local addressing but are incapable of communicating with the Internet, from hosts that are capable of communicating with the Internet, vendors of the former kind of hosts are strongly urged to choose another name for the former capability. ---- From owner-zeroconf@merit.edu Thu Feb 13 08:34:29 2003 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 IAA11870 for ; Thu, 13 Feb 2003 08:34:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2F29C9120D; Thu, 13 Feb 2003 08:38:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F333C9126F; Thu, 13 Feb 2003 08:38:05 -0500 (EST) 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 E8FC49120D for ; Thu, 13 Feb 2003 08:38:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id D5FF85DF47; Thu, 13 Feb 2003 08:38:04 -0500 (EST) 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 5D58E5DDE3 for ; Thu, 13 Feb 2003 08:38:04 -0500 (EST) 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 IAA14283 for ; Thu, 13 Feb 2003 08:38:03 -0500 (EST) 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 IAA12944 for ; Thu, 13 Feb 2003 08:38:03 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id IAA11566 for ; Thu, 13 Feb 2003 08:38:02 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 13 Feb 2003 08:37:59 -0500 Subject: Re: new issue: [LL27] LL-only hosts are out of scope for this specification From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: 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 02/13/2003 06:37, "Erik Guttman" wrote: > Inherent in the entire concept of "Internet" is the ability to > communicate between (not just within) networks, and the Internet > Protocol was designed specifically to facilitate communication between > hosts on potentially dissimilar, and perhaps distant, networks. Hosts > which are inherently incapable of communicating with hosts on other IP > networks cannot meaningfully be said to implement the Internet Protocol, > or to support Internet connectivity, even if they use similar packet > formats. I completely and utterly reject this. This standard is not "Public Internet Link - Local addressing", Nor is it "Inter-Network Link - Local addressing". It is TCP/IPv4 Link Local addressing. It is ridiculous for the IETF to dictate how a standard is used. TCP/IP is used in devices that will.never.be.on.the.public.internet. It is used in devices that cannot talk to other networks. The IETF has no business telling anyone how to USE a standard, only how to comply with the standard from a technical level. To make usage requirements a part of the standard is beyond the pale. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Feb 13 08:47:23 2003 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 IAA12120 for ; Thu, 13 Feb 2003 08:47:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8EA4C9126F; Thu, 13 Feb 2003 08:51:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E5AD91272; Thu, 13 Feb 2003 08:51:00 -0500 (EST) 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 4A2CD9126F for ; Thu, 13 Feb 2003 08:50:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C9E65DE96; Thu, 13 Feb 2003 08:50:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by segue.merit.edu (Postfix) with ESMTP id 0BA0D5DDE3 for ; Thu, 13 Feb 2003 08:50:59 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18jJkd-0004JE-00; Thu, 13 Feb 2003 05:50:07 -0800 Date: Thu, 13 Feb 2003 08:47:26 -0500 From: Keith Moore To: Robert Elz Cc: moore@cs.utk.edu, Erik.Guttman@Sun.COM, mika.liljeberg@welho.com, zeroconf@merit.edu Subject: Re: Proposed text for LL2 Message-Id: <20030213084726.2e1b68a2.moore@cs.utk.edu> In-Reply-To: <4190.1045126413@munnari.OZ.AU> References: <20030211085137.2918d9c7.moore@cs.utk.edu> <20030210122608.50d3d478.moore@cs.utk.edu> <1044796483.21383.156.camel@devil> <19889.1044953652@munnari.OZ.AU> <4190.1045126413@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > No, I disagree with that. It would certainly help to have a uniform > mechanism, as as much as vendors want to keep customers happy, I'd > expect that a uniform mechanism (likely to be DHCP) will be what happens. > But for the requirements here, there is no need for that - if I need to > have a DHCP server (also able to do BOOTP) a RARP server, a MOP server, > a ... server on my net, that is possible. yes, it's possible for you to do that. But I don't think it's acceptable to require that in order to get random plug-and-ping devices to play well on his network, an admin has to potentially implement a separate mechanism for each device. Requiring that the admin support 1 or 2 mechanisms (say DHCP or RARP) is fine, more than that is too much. > What is necessary is that there be some way to configure the devices, and > if that means that devices come with a CD and instructions "boot this on > your windows machine before connecting the device" then that suffices, > even if what then happens is some totally non-standard proprietary protocol. > I personally wouldn't buy any such thing, but that's not what counts. Manual configuration is acceptable as long as the device is required to be configured manually before it will try to operate at all. But if the device tries to configure LL automatically, it needs to also check for DHCP automatically. From owner-zeroconf@merit.edu Thu Feb 13 08:47:47 2003 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 IAA12140 for ; Thu, 13 Feb 2003 08:47:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 448DE91272; Thu, 13 Feb 2003 08:51:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 102E39127C; Thu, 13 Feb 2003 08:51:23 -0500 (EST) 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 0425291272 for ; Thu, 13 Feb 2003 08:51:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id E16455DE96; Thu, 13 Feb 2003 08:51:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by segue.merit.edu (Postfix) with ESMTP id C06A85DDE3 for ; Thu, 13 Feb 2003 08:51:22 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18jJlm-0005Y9-00; Thu, 13 Feb 2003 05:51:18 -0800 Date: Thu, 13 Feb 2003 08:48:50 -0500 From: Keith Moore To: Robert Elz Cc: moore@cs.utk.edu, Erik.Guttman@Sun.COM, mika.liljeberg@welho.com, zeroconf@merit.edu Subject: Re: Proposed text for LL2 Message-Id: <20030213084850.721f169a.moore@cs.utk.edu> In-Reply-To: <4190.1045126413@munnari.OZ.AU> References: <20030211085137.2918d9c7.moore@cs.utk.edu> <20030210122608.50d3d478.moore@cs.utk.edu> <1044796483.21383.156.camel@devil> <19889.1044953652@munnari.OZ.AU> <4190.1045126413@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 oops sorry. I had told one of the chairs I'd hold off on discussing LL2 until it's back on the table, since we already have so many discussions going on. I replied to the last message before I realized it was about LL2. Keith From owner-zeroconf@merit.edu Thu Feb 13 09:27:00 2003 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 JAA12817 for ; Thu, 13 Feb 2003 09:26:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B0A309127E; Thu, 13 Feb 2003 09:30:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D69991281; Thu, 13 Feb 2003 09:30:16 -0500 (EST) 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 6AF7B9127E for ; Thu, 13 Feb 2003 09:30:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id BC4995DE98; Thu, 13 Feb 2003 09:30:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by segue.merit.edu (Postfix) with ESMTP id 26B4B5DF75 for ; Thu, 13 Feb 2003 09:30:09 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18jKNL-0003LV-00; Thu, 13 Feb 2003 06:30:07 -0800 Date: Thu, 13 Feb 2003 09:27:39 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: new issue: [LL27] LL-only hosts are out of scope for this specification Message-Id: <20030213092739.1f53ebb7.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 "John C. Welch" wrote: > I completely and utterly reject this. Per the chair's request, I'd like to defer discussion of this until we clear some of the other issues out of the way. Keith From owner-zeroconf@merit.edu Thu Feb 13 11:43:12 2003 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 LAA18029 for ; Thu, 13 Feb 2003 11:43:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 643CC9129C; Thu, 13 Feb 2003 11:46:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B2D9912A4; Thu, 13 Feb 2003 11:46:37 -0500 (EST) 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 0F59F9129C for ; Thu, 13 Feb 2003 11:46:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 53A8D5E043; Thu, 13 Feb 2003 11:45:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by segue.merit.edu (Postfix) with ESMTP id 100D35E041 for ; Thu, 13 Feb 2003 11:45:53 -0500 (EST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 13 Feb 2003 08:45:55 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 13 Feb 2003 08:45:52 -0800 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Feb 2003 08:45:43 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 13 Feb 2003 08:45:48 -0800 Received: from WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 13 Feb 2003 08:45:50 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Thu, 13 Feb 2003 08:45:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses Date: Thu, 13 Feb 2003 08:44:35 -0800 Message-ID: Thread-Topic: [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses thread-index: AcLTSaR7xvlRJc/GRA6f5rSh2oFW2wANVIzw From: "Christian Huitema" To: "Erik Guttman" , X-OriginalArrivalTime: 13 Feb 2003 16:45:27.0220 (UTC) FILETIME=[4FC1BF40:01C2D37F] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA18029 Erik, Your proposed text still has a reference to the source address: > If the destination address is in the 169.254/16 prefix (including the > 169.254.255.255 broadcast address), then it MUST 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 the > destination on the same physical link. I think it would be simpler to only deal with the destination address in this paragraph: If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), then it MUST ARP for the destination address and then send its packet directly to the destination on the same physical link. -- Christian Huitema From owner-zeroconf@merit.edu Thu Feb 13 11:46:27 2003 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 LAA18178 for ; Thu, 13 Feb 2003 11:46:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC5B2912A4; Thu, 13 Feb 2003 11:50:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A2A8912A5; Thu, 13 Feb 2003 11:50:02 -0500 (EST) 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 C2340912A4 for ; Thu, 13 Feb 2003 11:48:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 90F0A5E040; Thu, 13 Feb 2003 11:48:30 -0500 (EST) 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 370CE5DDA8 for ; Thu, 13 Feb 2003 11:48:30 -0500 (EST) 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 JAA10714; Thu, 13 Feb 2003 09:48:28 -0700 (MST) 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 h1DGmQl06803; Thu, 13 Feb 2003 17:48:26 +0100 (MET) Date: Thu, 13 Feb 2003 17:48:25 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Christian Huitema Cc: Erik Guttman , zeroconf@merit.edu Subject: RE: [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Christian, On Thu, 13 Feb 2003, Christian Huitema wrote: > Your proposed text still has a reference to the source address: > > > If the destination address is in the 169.254/16 prefix (including > the > > 169.254.255.255 broadcast address), then it MUST 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 the > > destination on the same physical link. > > I think it would be simpler to only deal with the destination address in > this paragraph: > > If the destination address is in the 169.254/16 prefix (including > the > 169.254.255.255 broadcast address), then it MUST ARP for the > destination address and then send its packet directly to the > destination on the same physical link. Thank you. I support your reformulated version. Erik From owner-zeroconf@merit.edu Thu Feb 13 18:15:47 2003 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 SAA19047 for ; Thu, 13 Feb 2003 18:15:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6EF68912A1; Thu, 13 Feb 2003 18:19:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E5B0912A6; Thu, 13 Feb 2003 18:19:23 -0500 (EST) 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 B2574912A1 for ; Thu, 13 Feb 2003 18:18:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 99DE75DF88; Thu, 13 Feb 2003 18:18:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 9D2A55DF71 for ; Thu, 13 Feb 2003 18:18:56 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1DNJRaj016825; Fri, 14 Feb 2003 01:19:27 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1DNJPXZ016824; Fri, 14 Feb 2003 01:19:25 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL11 Add security consideration for the threat where an attacker forces address reconfiguration From: Mika Liljeberg To: Robert Elz Cc: Stuart Cheshire , zeroconf@merit.edu In-Reply-To: <4344.1045131502@munnari.OZ.AU> References: <200302120332.h1C3WHQ02980@scv2.apple.com> <4344.1045131502@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045178364.4848.1250.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.1 Date: 14 Feb 2003 01:19:25 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-02-13 at 12:18, Robert Elz wrote: > That is, a node on having its address "stolen" by another node, can > do what the draft currently says, and just go allocate itself a > new address (the new address allocation has never been the issue here) > but not release the old one - that is, continue to defend it to the > death, forever (or at least until there is no longer any reasonable > possibility that any old connections using the old address survive). > > That would, essentially, remove the one real difference between the LL > spec, and what has always happened in the past when there are address > conflicts. This is a bit OT, but a node can guard against ARP poisoning by doing some additional checking on hardware addresses and cache state: - discard all unsolicited ARP announcements - never overwrite a cached hardware address - keep reference counts for cache entries and keep entries with non-zero reference counts alive by probing the peer before the entry has a chance to expire In the event of an address collision, given the above defensive mechanisms, a node could configure a new address, but try to finish the existing connections with the old one. This would work with a peer employing similar counter-measures. MikaL From owner-zeroconf@merit.edu Fri Feb 14 01:16:07 2003 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 BAA01445 for ; Fri, 14 Feb 2003 01:16:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 422E091226; Fri, 14 Feb 2003 01:19:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 550F49122E; Fri, 14 Feb 2003 01:19:41 -0500 (EST) 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 E13E891226 for ; Fri, 14 Feb 2003 01:18:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id BDB6D5DE0F; Fri, 14 Feb 2003 01:18:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 0FD765DF5C for ; Fri, 14 Feb 2003 01:17:52 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1E6GPq27133; Fri, 14 Feb 2003 13:16:27 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1E6GGb09620; Fri, 14 Feb 2003 13:16:16 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: Stuart Cheshire , zeroconf@merit.edu Subject: Re: LL11 Add security consideration for the threat where an attacker forces address reconfiguration In-Reply-To: <1045178364.4848.1250.camel@devil> References: <1045178364.4848.1250.camel@devil> <200302120332.h1C3WHQ02980@scv2.apple.com> <4344.1045131502@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Feb 2003 13:16:16 +0700 Message-ID: <9618.1045203376@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 14 Feb 2003 01:19:25 +0200 From: Mika Liljeberg Message-ID: <1045178364.4848.1250.camel@devil> | This is a bit OT, but a node can ... Yes, I agree with all of that. But for present purposes, all that is really required is that the security considerations make it clear that there really is a potential problem here (that is, it isn't all just as it used to be), and advise implementors to take care. What is the best way to do that might vary depending upon the requirements of the node in question - or it may eventually turn out that there's one best way that works well (enough) for everyone. Blindly just ceasing (abruptly) to use an address because some other node says that you should is sometimes going to be dangerous though (not always, there's no real problem if the node is just sitting there waiting for someone to find it & communicate). kre From owner-zeroconf@merit.edu Fri Feb 14 11:34:57 2003 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 LAA26402 for ; Fri, 14 Feb 2003 11:34:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 607D391242; Fri, 14 Feb 2003 11:38:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A24391243; Fri, 14 Feb 2003 11:38:07 -0500 (EST) 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 17F6891242 for ; Fri, 14 Feb 2003 11:38:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC8F75DFE6; Fri, 14 Feb 2003 11:38:05 -0500 (EST) 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 7EEE45DED1 for ; Fri, 14 Feb 2003 11:38:05 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.3/8.12.3) with ESMTP id h1EGc4g7006393 for ; Fri, 14 Feb 2003 08:38:04 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 14 Feb 2003 08:38:04 -0800 Received: from [17.219.193.36] (vpn-scv-x1-36.apple.com [17.219.193.36]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h1EGc4f18457 for ; Fri, 14 Feb 2003 08:38:04 -0800 (PST) Message-Id: <200302141638.h1EGc4f18457@scv3.apple.com> Subject: Organizational Changes Date: Fri, 14 Feb 2003 08:38:05 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Recently I have been facing an ever-increasing workload, working with other groups internally within Apple, working with partners outside Apple, speaking engagements at conferences, etc. At the same time, the Zeroconf Working Group has moved into high gear, with over 800 messages in January alone, and another 300 so far this month. I have come to realize that I cannot do everything that I want to do. Thankfully, help has been forthcoming. Erik Guttman has offered to take on the full workload of Chairman of the Zero Configuration Working Group, so that I can step down from my co-chair position. Daniel Senie has offered to take over the task of doing the remaining editing for draft-ietf-zeroconf-ipv4-linklocal. By passing on those responsibilities, I am freeing up more of my time to concentrate more on two of the things I consider most important: contributing to the technical content of the IPv4LL document, and working with Apple and other companies to make excellent products that use that technology. My time as co-chair of Zeroconf has been rewarding. I have enjoyed working with the many smart people in this group, and have learnt a lot in the process. The process will continue and I am optimistic that we will succeed and publish a great specification. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Feb 14 16:25:19 2003 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 QAA05381 for ; Fri, 14 Feb 2003 16:25:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B23BA9126F; Fri, 14 Feb 2003 16:28:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8401391272; Fri, 14 Feb 2003 16:28:54 -0500 (EST) 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 79F5B9126F for ; Fri, 14 Feb 2003 16:28:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 573665E010; Fri, 14 Feb 2003 16:28:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by segue.merit.edu (Postfix) with ESMTP id D9C985DFE5 for ; Fri, 14 Feb 2003 16:28:52 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e34.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1ELSm6C036158; Fri, 14 Feb 2003 16:28:49 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1ELSlYg079566; Fri, 14 Feb 2003 14:28:47 -0700 Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by rotala.raleigh.ibm.com (8.12.5/8.12.5) with ESMTP id h1ELQI97001195; Fri, 14 Feb 2003 16:26:18 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.12.5/8.12.5/Submit) with ESMTP id h1ELQHKM001190; Fri, 14 Feb 2003 16:26:17 -0500 Message-Id: <200302142126.h1ELQHKM001190@rotala.raleigh.ibm.com> To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Organizational Changes In-Reply-To: Message from cheshire@apple.com of "Fri, 14 Feb 2003 08:38:05 PST." <200302141638.h1EGc4f18457@scv3.apple.com> Date: Fri, 14 Feb 2003 16:26:17 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Stuart, I'd like thank you for all the hard work you've put into zeroconf over the last few years. You've put in a lot of time and hard work and I think the WG has benefitted a lot from your efforts. I do hope you will find time to continue contributing and encourage you to do so. The IETF benefits greatly when we get good technical input, especially when its coupled with experience from real deployments, which is something you have provided. As you've indicated, Erik has agreed to continue chairing the WG. In addition, I'm pleased to be able to say that Daniel Senie has agreed to take over the editing of the ipv4-linklocal document. Also, as can be seen from the recent mailing list traffic, there is a renewed effort at trying to bring the remaining work to closure. I believe I speak for many when I say that I would really like to see the LL document published as a Proposed Standard -- and soon! The technology is already in use, and it appears to be useful. I continue to believe that the document is 95% finished. We just need to find a way to close on the remaining issues and complete the job we set out to do. Let's all try and help Erik go through the open issues one-by-one and come to a clear and satisfactory resolution on all of them. Thomas From owner-zeroconf@merit.edu Fri Feb 14 19:32:30 2003 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 TAA10545 for ; Fri, 14 Feb 2003 19:32:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 445869129C; Fri, 14 Feb 2003 19:36:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FCDD912B6; Fri, 14 Feb 2003 19:36:05 -0500 (EST) 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 E3C729129C for ; Fri, 14 Feb 2003 19:36:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id D08185DE33; Fri, 14 Feb 2003 19:36:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by segue.merit.edu (Postfix) with ESMTP id 628965DE04 for ; Fri, 14 Feb 2003 19:36:04 -0500 (EST) Received: from zidane.cc.vt.edu (IDENT:mirapoint@zidane-lb.cc.vt.edu [10.1.1.13]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id h1F0a3W159028 for ; Fri, 14 Feb 2003 19:36:03 -0500 (EST) Received: from zathras (zathras.cc.vt.edu [198.82.162.117]) by zidane.cc.vt.edu (Mirapoint Messaging Server MOS 3.3.2-CR) with ESMTP id BBG95228; Fri, 14 Feb 2003 19:35:49 -0500 (EST) X-WebMail-UserID: bsvijay Date: Fri, 14 Feb 2003 19:35:48 -0500 From: Vijayanand Ballapuram To: zeroconf@merit.edu X-EXP32-SerialNo: 00002964 Subject: Service Discovery Protocols Message-ID: <3E500159@zathras> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: WebMail (Hydra) SMTP v3.61.08 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Everyone, I need information required service discovery protocols in ZERO Confuguration Networking which can applied for LAN, WAN, Wirless Networks(Base station) and MANETs. I would greatly appreciate if anyone let's me know reserach that has been done so far in SERVICE DISCOVERY PROTOCOLS, papers, Drafts and/or any other technical documents which would give me RELATED INFORMATION. Thanks in Advance, Vijay From owner-zeroconf@merit.edu Sat Feb 15 02:19:16 2003 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 CAA27243 for ; Sat, 15 Feb 2003 02:19:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0F0A691205; Sat, 15 Feb 2003 02:22:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCF469120E; Sat, 15 Feb 2003 02:22:53 -0500 (EST) 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 CCEA291205 for ; Sat, 15 Feb 2003 02:22:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id B3D4F5DE30; Sat, 15 Feb 2003 02:22:52 -0500 (EST) 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 46FCE5DDA7 for ; Sat, 15 Feb 2003 02:22:52 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.3/8.12.3) with ESMTP id h1F7Mpg7027925 for ; Fri, 14 Feb 2003 23:22:51 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 14 Feb 2003 23:22:51 -0800 Received: from [17.219.194.40] (vpn-scv-x3-40.apple.com [17.219.194.40]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h1F7Mps12569 for ; Fri, 14 Feb 2003 23:22:51 -0800 (PST) Message-Id: <200302150722.h1F7Mps12569@scv1.apple.com> Subject: LL16 Split references Date: Fri, 14 Feb 2003 23:22:54 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Keith Moore wrote (with respect to the hot-swappable modules in Apple's Xserve RAID that communicate internally using IPv4LL): >these devices don't have to claim conformance to an IETF standard. >neither should IETF be expected to endorse Apple's products. >this is out of scope for IETF, and out of scope for this working group. Keith, we may disagree frequently, but I know you are smart, so here's a genuine question for you: Suppose Apple were to allow and encourage third-parties to develop hot-swappable modules that are compatible with Xserve RAID? Suppose further that this family of hot-swappable modules becomes very popular, and other RAID vendors want to build RAID chassis that accept said modules. To properly serve the industry doing this, there needs to be a standard (just like PCI is a standard). Who is responsible for defining this inter-company standard for communication using IP over Ethernet inside a computer chassis, if not the IETF? Should the IEEE take on defining the standard for IP over Ethernet inside a computer chassis? Would you support an IEEE standard defining this use of IP over Ethernet and all its application implications, or would you say that the IEEE would be stepping on the toes of the IETF if it started defining such standards? I will defer further comment until LL27 is officially open for discussion. Regarding "LL16 Split references", think we all agree that splitting the references is right, but we can't agree which references are normative, so I propose we will have to make LL16 the *last* issue, and defer its discussion until after every other issue has been resolved. I hope that by then LL16 will be easy to agree on. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sat Feb 15 02:20:47 2003 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 CAA27280 for ; Sat, 15 Feb 2003 02:20:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8A2339120E; Sat, 15 Feb 2003 02:24:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C17591211; Sat, 15 Feb 2003 02:24:24 -0500 (EST) 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 57F1F9120E for ; Sat, 15 Feb 2003 02:24:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 43FC15DE67; Sat, 15 Feb 2003 02:24:23 -0500 (EST) 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 CAEB85DDA7 for ; Sat, 15 Feb 2003 02:24:22 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.3/8.12.3) with ESMTP id h1F7OMg7028152 for ; Fri, 14 Feb 2003 23:24:22 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 14 Feb 2003 23:24:21 -0800 Received: from [17.219.194.40] (vpn-scv-x3-40.apple.com [17.219.194.40]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h1F7OLQ04350 for ; Fri, 14 Feb 2003 23:24:21 -0800 (PST) Message-Id: <200302150724.h1F7OLQ04350@scv2.apple.com> Subject: LL10 Add warnings to applicability statement Date: Fri, 14 Feb 2003 23:24:24 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Keith Moore wrote: >> The whole rationale behind IPv4LL is that effectively *ALL* >> application protocols can function usefully with link-local >> addresses on a single isolated link. > >This may be the rationale, but it's simply not the case. There >are apps that, for a variety of reasons, need to have external >connectivity even if all of the participants in the session are >all on the local link. This looks like an oxymoron -- if the application needs external connectivity, then at least *one* of the participants must be external (i.e. not on the local link). However, regardless of this, the point remains that I still believe that with a small group of hosts connected to an Ethernet hub, IPv4LL enables any application to work at least as well as it could work with with *any* kind of addressing. Some applications may still fail by virtue of lack of necessary connectivity, but that lack of necessary connectivity would exist no matter how addresses were assigned. I feel that this IPv4LL document is being subjected to demands that it contain an absolutely unprecedented amount of self-critical pejorative language suggesting that it is a worthless technology that is little use for anything. The fact is that if you have an isolated LAN, then you don't have external connectivity. You can assign manual addresses, but you won't have external connectivity. You can set up a DHCP server, but you still won't have external connectivity. If you don't take any such action to configure an address somehow, then you won't have any IP connectivity at all, not even to hosts that are physically reachable. Having self-configuring self-assigned addresses means that hosts can at least communicate with the other hosts which which it is *possible* to communicate. If anyone can come up with a real application (or list of applications) that DO NOT work with a small group of hosts connected to an Ethernet hub using IPv4LL addresses, but DO work with a small group of hosts connected to an Ethernet hub using manually-assigned (or DHCP) addresses, then I would support mentioning these specific applications in the document. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sat Feb 15 02:22:00 2003 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 CAA27304 for ; Sat, 15 Feb 2003 02:22:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C1BD591211; Sat, 15 Feb 2003 02:25:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97B11912C8; Sat, 15 Feb 2003 02:25:29 -0500 (EST) 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 772E091211 for ; Sat, 15 Feb 2003 02:25:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 673A35DE30; Sat, 15 Feb 2003 02:25:28 -0500 (EST) 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 2ADCE5DDA7 for ; Sat, 15 Feb 2003 02:25:28 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.3/8.12.3) with ESMTP id h1F7PRTb011767 for ; Fri, 14 Feb 2003 23:25:27 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 14 Feb 2003 23:25:27 -0800 Received: from [17.219.194.40] (vpn-scv-x3-40.apple.com [17.219.194.40]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h1F7PRf11431 for ; Fri, 14 Feb 2003 23:25:27 -0800 (PST) Message-Id: <200302150725.h1F7PRf11431@scv3.apple.com> Subject: LL10 applications assume addresses are routable? Date: Fri, 14 Feb 2003 23:25:30 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Several people have said: >Many applications fundamentally assume >addresses of communicating peers are routable I submit that this is utter nonsense. Applications (aside from a few specialized network debugging tools like traceroute) care only that a given destination address will deliver a packet to the right destination. The fact that the packet may get there via routing is an implementation issue, of which the application has no care. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sat Feb 15 02:23:27 2003 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 CAA27328 for ; Sat, 15 Feb 2003 02:23:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 23A4D912C8; Sat, 15 Feb 2003 02:26:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D6F66912C9; Sat, 15 Feb 2003 02:26:57 -0500 (EST) 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 DB710912C8 for ; Sat, 15 Feb 2003 02:26:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id C62125DE99; Sat, 15 Feb 2003 02:26:56 -0500 (EST) 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 58A725DE67 for ; Sat, 15 Feb 2003 02:26:56 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.3/8.12.3) with ESMTP id h1F7QtTb011892 for ; Fri, 14 Feb 2003 23:26:55 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 14 Feb 2003 23:26:55 -0800 Received: from [17.219.194.40] (vpn-scv-x3-40.apple.com [17.219.194.40]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h1F7QtQ04672 for ; Fri, 14 Feb 2003 23:26:55 -0800 (PST) Message-Id: <200302150726.h1F7QtQ04672@scv2.apple.com> Subject: LL11: Is there an elephant in the room? Date: Fri, 14 Feb 2003 23:26:58 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Robert Elz suggested: > Before abandoning an address ... hosts SHOULD actively > attempt to reset any existing connections using that address. While I do think this is a good suggestion in isolation, I also want to point out that it is another example of how IPv4LL is being subjected to unprecedented nit-picking. When changing a manually-assigned IP address, does any RFC say that hosts should actively attempt to reset any existing connections? Changing a manually-assigned IP address also leaves TCP connections dangling which could be subject to later hijacking. When a DHCP server declines to renew a lease (as more and more ISPs are doing these days), does the DHCP RFC say that hosts should actively attempt to reset any existing connections before giving up the address? The fact is that anyone wanting to hijack a TCP connection on the local link will do it in the usual way, by bi-lateral unicast ARP cache poisoning, and then continuing to pass data between the two poisoned hosts so that they don't notice. Tools Ettercap will even do this bi-lateral poisoning and pass-through for you. Compared to that, an attack that makes one of the hosts reconfigure is crude and clumsy and more likely to be detected. Insisting that the document discuss the hazards of forced reconfiguration, when we know that tools like Ettercap already exist, is like insisting that airport security should X-ray everyone's shoelaces at an airport where we know that they're not checking anyone's carry-on bags. Sure, the risk of forced reconfiguration exists, but by spending a lot of time talking about it, everyone is busy discussing the link-local ant while ignoring the IPv4 elephant in the room. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sat Feb 15 02:23:44 2003 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 CAA27345 for ; Sat, 15 Feb 2003 02:23:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4DC93912C9; Sat, 15 Feb 2003 02:27:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 192C3912CB; Sat, 15 Feb 2003 02:27:21 -0500 (EST) 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 2BD32912C9 for ; Sat, 15 Feb 2003 02:27:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 18AC15DE67; Sat, 15 Feb 2003 02:27:20 -0500 (EST) 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 CFD705DDA7 for ; Sat, 15 Feb 2003 02:27:19 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.3/8.12.3) with ESMTP id h1F7RJTb011955 for ; Fri, 14 Feb 2003 23:27:19 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 14 Feb 2003 23:27:18 -0800 Received: from [17.219.194.40] (vpn-scv-x3-40.apple.com [17.219.194.40]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h1F7RIs13330 for ; Fri, 14 Feb 2003 23:27:18 -0800 (PST) Message-Id: <200302150727.h1F7RIs13330@scv1.apple.com> Subject: Re: LL11 Add security consideration for the threat where an attacker forces address reconfiguration Date: Fri, 14 Feb 2003 23:27:22 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Mika Liljeberg wrote: >a node can guard against ARP poisoning by doing >some additional checking on hardware addresses and cache state: >- discard all unsolicited ARP announcements >- never overwrite a cached hardware address This change would violate the ARP specification in RFC 826, and any such change to RFC 826 would require a *lot* of discussion and debate. The list of problems in such a change would probably require a working group of their own. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sat Feb 15 02:24:13 2003 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 CAA27359 for ; Sat, 15 Feb 2003 02:24:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9AFCB912CB; Sat, 15 Feb 2003 02:27:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 686F6912CD; Sat, 15 Feb 2003 02:27:43 -0500 (EST) 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 77404912CB for ; Sat, 15 Feb 2003 02:27:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D5D15DE30; Sat, 15 Feb 2003 02:27:42 -0500 (EST) 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 106B35DDA7 for ; Sat, 15 Feb 2003 02:27:42 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.3/8.12.3) with ESMTP id h1F7RfTb012012 for ; Fri, 14 Feb 2003 23:27:41 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 14 Feb 2003 23:27:41 -0800 Received: from [17.219.194.40] (vpn-scv-x3-40.apple.com [17.219.194.40]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h1F7Res13404 for ; Fri, 14 Feb 2003 23:27:41 -0800 (PST) Message-Id: <200302150727.h1F7Res13404@scv1.apple.com> Subject: Re: LL usage example: LL-only homenetwork with single global address + NAT Date: Fri, 14 Feb 2003 23:27:44 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk > - a gateway router perfoming the ugly NAT service for outbound > connections This is off-topic, so the answer will be brief. The current draft explicitly prohibits this, for a reason. There's nothing wrong with DHCP. If you want to do this, put a DHCP server in the NAT box (as virtually all do today). IPv4LL is not proposed as a replacement for DHCP. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sat Feb 15 04:46:34 2003 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 EAA29409 for ; Sat, 15 Feb 2003 04:46:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AF7F6912CF; Sat, 15 Feb 2003 04:50:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5235E912D0; Sat, 15 Feb 2003 04:50:05 -0500 (EST) 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 8043E912CF for ; Sat, 15 Feb 2003 04:49:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 610EE5DE58; Sat, 15 Feb 2003 04:49:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id CDBAB5DE08 for ; Sat, 15 Feb 2003 04:49:43 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1F9nUq21988; Sat, 15 Feb 2003 16:49:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1F9nKb14659; Sat, 15 Feb 2003 16:49:21 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: LL11 Add security consideration for the threat where an attacker forces address reconfiguration In-Reply-To: <200302150727.h1F7RIs13330@scv1.apple.com> References: <200302150727.h1F7RIs13330@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 15 Feb 2003 16:49:20 +0700 Message-ID: <14657.1045302560@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 14 Feb 2003 23:27:22 -0800 From: Stuart Cheshire Message-ID: <200302150727.h1F7RIs13330@scv1.apple.com> | This change would violate the ARP specification in RFC 826, and any such | change to RFC 826 would require a *lot* of discussion and debate. The | list of problems in such a change would probably require a working group | of their own. The change that was suggested would. I know however that the last implementation of ARP I did treated an unsolicited reply (and would a broadcast request) as a suggestion that the IP<->MAC address mapping might have changed. That is, I invalidated the ARP cache entry. (I doubt that I invented this technique, which suggests that others do the same thing, and I learned it from someone else - this was all a *long* time ago now). When there was a need to send another packet to the destination, an ARP request would result - that the true owner of the address would respond to. A hacker might also respond, in which case odd things happen (the effect is that the cache is invalidated again, as when the 2nd reply, whichever it is, arrives, no reply is expected). When the cache gets invalidated this way, the event is also logged, if it is a genuine MAC address change, that's fine, one (comparatively rare) log entry - if it is someone attempting to hijack addresses, it becomes very obvious, very quickly. There are still DoS possibilities here, but nothing like as bad as just silently updating an ARP cache upon request, nor as bad as just giving up an address upon request and handing it to someone else. Stuart - all that anyone is asking here is that there be an adequate security considerations section. Giving up an address upon request from any random node is new for the Internet architecture, and doing so does have security implications - those need to be noted. I agree with you (I think) that none of this is severe enough, compared with what currently is possible, to warrant requiring any changes to the protocol itself. But there is enough here that noting the issue in the security considerations is important. wrt your reply to me ... There is no RFC about manually changing assigned IP addresses. If we were to write one, this issue should be addressed in it as well. The same is true for DHCP - this is one of the reasons why DHCP servers should not refuse to renew a lease - but if we were writing about that now (what a client should do if a lease expires) then closing all active connections should be on the list to at least attempt. kre From owner-zeroconf@merit.edu Sat Feb 15 07:50:34 2003 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 HAA01950 for ; Sat, 15 Feb 2003 07:50:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0A845912D2; Sat, 15 Feb 2003 07:54:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BFDFE912D3; Sat, 15 Feb 2003 07:54:10 -0500 (EST) 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 A3E2B912D2 for ; Sat, 15 Feb 2003 07:54:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8C50F5DF59; Sat, 15 Feb 2003 07:54:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id A14525DD98 for ; Sat, 15 Feb 2003 07:54:08 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1FCsdaj029008; Sat, 15 Feb 2003 14:54:40 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1FCsaw4029007; Sat, 15 Feb 2003 14:54:36 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL11 Add security consideration for the threat where an attacker forces address reconfiguration From: Mika Liljeberg To: Stuart Cheshire Cc: zeroconf@merit.edu In-Reply-To: <200302150727.h1F7RIs13330@scv1.apple.com> References: <200302150727.h1F7RIs13330@scv1.apple.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045313674.27671.60.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Feb 2003 14:54:35 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I support LL11. On Sat, 2003-02-15 at 09:27, Stuart Cheshire wrote: > >a node can guard against ARP poisoning by doing > >some additional checking on hardware addresses and cache state: > >- discard all unsolicited ARP announcements > >- never overwrite a cached hardware address > > This change would violate the ARP specification in RFC 826, and any such > change to RFC 826 would require a *lot* of discussion and debate. Undoubtedly true, although RFC826 is none too clear on the mandatory requirements. There's quite a bit of leeway in there. I was not suggesting this as a solution (the description is too vague anyway) and even indicated that it is slightly off-topic. I was only pointing out that there are counter-measures that nodes can take and, as Robert also pointed out, there are implementations which do. Our implementation, for instance, follows the IPv6 Neighbor Discovery state machine and takes an unsolicited ARP reply with a different hardware address only as an indication that the address may have changed. The cached entry is set to STALE state. From there it progresses to PROBE state, in which the node to sends unicast probes to the old hardware address to ascertain its reachability. The entry gets deleted only if the old hardware address no longer responds, in which case the next packet will cause the node to ARP for the address normally. The above may not be exactly as described in RFC826 but it works reasonably well and it does address the issues that RFC826 cites as reason for updating a cached hardware address. The implementation is also a good deal more resistant to cache poisoning. > The > list of problems in such a change would probably require a working group > of their own. That thought is not without merit, RFC826 is way past its time. Certainly this is not a problem to address in this group, though. I agree with Robert, however, that there should be a warning in the security section about the new attack variants enabled by the address collision resolution. In the case of our stack, for instance, it clearly reopens attack avenues that we had already dealt with. MikaL From owner-zeroconf@merit.edu Sat Feb 15 10:39:16 2003 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 KAA04143 for ; Sat, 15 Feb 2003 10:39:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CEBC391237; Sat, 15 Feb 2003 10:42:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 948BC912D5; Sat, 15 Feb 2003 10:42:54 -0500 (EST) 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 7804691237 for ; Sat, 15 Feb 2003 10:42:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5BBB85DDFC; Sat, 15 Feb 2003 10:42:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id F17445DD92 for ; Sat, 15 Feb 2003 10:42:51 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1FFhNaj029593; Sat, 15 Feb 2003 17:43:24 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1FFhKqk029592; Sat, 15 Feb 2003 17:43:20 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL11: Is there an elephant in the room? From: Mika Liljeberg To: Stuart Cheshire Cc: zeroconf@merit.edu In-Reply-To: <200302150726.h1F7QtQ04672@scv2.apple.com> References: <200302150726.h1F7QtQ04672@scv2.apple.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045323799.27665.74.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 15 Feb 2003 17:43:20 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-15 at 09:26, Stuart Cheshire wrote: > Robert Elz suggested: > > > Before abandoning an address ... hosts SHOULD actively > > attempt to reset any existing connections using that address. > > While I do think this is a good suggestion in isolation, I also want to > point out that it is another example of how IPv4LL is being subjected to > unprecedented nit-picking. I'm trying to imagine a nit-picking elephant. :-) In my view, when an address collision is detected the elephant is already in the store. This discussion is merely about how to lay out the store in such a way that the flying shards present the least hazard to bystanders. Resetting TCP connections might be an appropiate response to losing the local IP address without warning. Forced TCB delection could easily send an RST as a matter of course. However, I think section 2.5 is already saying too much when it states "the host MUST immediately cease using this address and configure a new link-local IP address". In our stack it would make more sense to mark the old address as "deprecated" (see definition in RFC2462) and pick a new one. MikaL From owner-zeroconf@merit.edu Sat Feb 15 17:15:42 2003 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 RAA08116 for ; Sat, 15 Feb 2003 17:15:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A449691260; Sat, 15 Feb 2003 17:19:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C42791256; Sat, 15 Feb 2003 17:19:16 -0500 (EST) 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 821E191258 for ; Sat, 15 Feb 2003 17:19:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 60CB85DEAA; Sat, 15 Feb 2003 17:19:09 -0500 (EST) 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 E50EC5DE37 for ; Sat, 15 Feb 2003 17:19:08 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.3/8.12.3) with ESMTP id h1FMJ8Tb016160 for ; Sat, 15 Feb 2003 14:19:08 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Sat, 15 Feb 2003 14:19:08 -0800 Received: from [17.219.193.9] (vpn-scv-x1-9.apple.com [17.219.193.9]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h1FMJ8f27127 for ; Sat, 15 Feb 2003 14:19:08 -0800 (PST) Message-Id: <200302152219.h1FMJ8f27127@scv3.apple.com> Subject: Re: LL11: Is there an elephant in the room? Date: Sat, 15 Feb 2003 14:19:13 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >However, I think section 2.5 is already saying too much when it >states "the host MUST immediately cease using this address and >configure a new link-local IP address". In our stack it would make >more sense to mark the old address as "deprecated" (see definition >in RFC2462) and pick a new one. I have said this before, so I'll try to avoid having to say it too many times again. Keeping an address (even in "deprecated" state) while some other host is using the same address may sound like a good idea until you try it, but it simply doesn't work. ARP caches flap, correspondent hosts send TCP packets to the wrong peer, causing resets, and in no time at all, both hosts have lost all their active TCP connections. The current text is a result of something that I think Erik Nordmark originally requested -- that when two authority-less networks merge (rare, but lets consider it anyway) and two hosts have previously picked the same address (also rare, but lets consider it anyway), that at least one of them should be able to continue working without disruption, instead of both being disrupted. For that to work, one of the hosts has to gracefully defer to the other. The alternative is that if they both try to keep the address, they both end up losing all their connections anyway. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sat Feb 15 17:15:59 2003 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 RAA08136 for ; Sat, 15 Feb 2003 17:15:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7BF1A91258; Sat, 15 Feb 2003 17:19:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30B339125B; Sat, 15 Feb 2003 17:19:15 -0500 (EST) 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 5461791256 for ; Sat, 15 Feb 2003 17:18:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 383395DEAA; Sat, 15 Feb 2003 17:18:59 -0500 (EST) 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 EE01B5DE37 for ; Sat, 15 Feb 2003 17:18:58 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.3/8.12.3) with ESMTP id h1FMIwTb016146 for ; Sat, 15 Feb 2003 14:18:58 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Sat, 15 Feb 2003 14:18:58 -0800 Received: from [17.219.193.9] (vpn-scv-x1-9.apple.com [17.219.193.9]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h1FMIvQ12732 for ; Sat, 15 Feb 2003 14:18:57 -0800 (PST) Message-Id: <200302152218.h1FMIvQ12732@scv2.apple.com> Subject: Re: LL11 Add security consideration for the threat where an attacker forces address reconfiguration Date: Sat, 15 Feb 2003 14:19:03 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Robert Elz wrote: >I agree with you (I think) that none of this is severe enough, compared >with what currently is possible, to warrant requiring any changes to >the protocol itself. But there is enough here that noting the issue >in the security considerations is important. It is important that we describe the relevant issues clearly, but my concern is that the document is not serving its intended purpose if we fail to find the right balance between honest clarity and alarmist language. Some of the problems are simply inherent properties of (a) any network which does not have full connectivity to every other host in the world, and/or (b) any network where no single authority has been designated, so that in the absence of authority, the hosts have to agree to work cooperatively (or not work at all). If the document does not distinguish between (i) the inherent problems of an isolated authority-less network, and (ii) the specific problems due to *this* particular solution, then we are not informing the reader. This is not an irrelevant academic concern. One of the problems I face frequently is talking to vendors who have decided that their device does need link-local autoconfiguration, but they are not going to do it "the IETF way" because "the IETF way is known to be full of massive security holes". Instead they have invented some bizarre mechanism of their own, which works much less well, and has all the same security problems (and more). If we write a document that ends up convincing a large minority of its readers that they should go off and invent their own solution instead, then the standard will have failed its primary purpose, which is to increase interoperability, not decrease it. I'm not saying we shouldn't clearly describe the problems, but excessive harping on those problems to the point where vendors (continue to) invent their own solutions instead of implementing the standard is self-defeating rather than helpful. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sat Feb 15 17:54:21 2003 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 RAA08383 for ; Sat, 15 Feb 2003 17:54:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 175479125B; Sat, 15 Feb 2003 17:58:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D51F191270; Sat, 15 Feb 2003 17:57:59 -0500 (EST) 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 B2B4D9125B for ; Sat, 15 Feb 2003 17:57:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9525D5DDC3; Sat, 15 Feb 2003 17:57:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 7AAE85DDBF for ; Sat, 15 Feb 2003 17:57:57 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1FMwVaj031425; Sun, 16 Feb 2003 00:58:31 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1FMwT1Y031424; Sun, 16 Feb 2003 00:58:29 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL11: Is there an elephant in the room? From: Mika Liljeberg To: Stuart Cheshire Cc: zeroconf@merit.edu In-Reply-To: <200302152219.h1FMJ8f27127@scv3.apple.com> References: <200302152219.h1FMJ8f27127@scv3.apple.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045349908.27665.86.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 16 Feb 2003 00:58:28 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-02-16 at 00:19, Stuart Cheshire wrote: > >However, I think section 2.5 is already saying too much when it > >states "the host MUST immediately cease using this address and > >configure a new link-local IP address". In our stack it would make > >more sense to mark the old address as "deprecated" (see definition > >in RFC2462) and pick a new one. > > Keeping an address (even in "deprecated" state) while some other host is > using the same address may sound like a good idea until you try it, but > it simply doesn't work. ARP caches flap, correspondent hosts send TCP > packets to the wrong peer, causing resets, and in no time at all, both > hosts have lost all their active TCP connections. Our implementation doesn't flap ARP entries quite that easily. All implementations not being similarly resistant, there is a fair chance that what you say would happen. I just think that SHOULD would have been strong enough for what is a corner case in the first place. MikaL From owner-zeroconf@merit.edu Sat Feb 15 22:24:13 2003 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 WAA10848 for ; Sat, 15 Feb 2003 22:24:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8A5ED91279; Sat, 15 Feb 2003 22:27:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C1A09127A; Sat, 15 Feb 2003 22:27:50 -0500 (EST) 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 3195A91279 for ; Sat, 15 Feb 2003 22:27:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 230245DF62; Sat, 15 Feb 2003 22:27:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id B66135DF2C for ; Sat, 15 Feb 2003 22:27:48 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1G3Pwb13540 for ; Sat, 15 Feb 2003 21:25:59 -0600 (CST) Date: Sat, 15 Feb 2003 21:27:47 -0600 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: My positions on pending items 6, 8, 11, 17, 19, 23 From: Ted Lemon To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit Message-Id: <9E9876FE-415E-11D7-BBEB-00039367340A@nominum.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Before I state my positions, I should say that I've heard and understood the various opinions that have been presented on these issues, so in particular there is no need for Kevin or kre to send me additional messages explaining their respective points of view. I have sympathy with both their positions and respect them, but I think some of my positions disagree with theirs. Reasonable people may differ on these points. LL6: We shouldn't add the suggested text. The theory is that IPv4ll creates a new vulnerability because a node that has a wireless interface could be attacked in cases where this was not previously possible. This theory is not correct because there is no case where an attack via IPv4ll would have been possible in which an attack via DHCP would not also have been possible. If a warning like the one suggested needs to go anywhere, it needs to go in the 802.11 and bluetooth standards, not in this draft. Adding the proposed text implies that there is a problem with wireless networking that is specific to IPv4ll, when there is no such problem. LL8: The text imposes some implementation requirements that don't make sense, because the implementor has no way of knowing whether or not a particular node is a router. This text should be removed: > section 2.6 > If the destination address is in the 169.254/16 prefix ... > The host MUST NOT send the packet to any router for forwarding. > > [...] > The host MUST NOT send the packet to any router for forwarding. > This text should be replaced: > section 2.7 > An IPv4 packet whose source and/or destination address is in the > 169.254/16 prefix MUST NOT be sent to any router for forwarding, and > any network device receiving such a packet MUST NOT forward it, > regardless of the TTL in the IP header. With this: > section 2.7 > Any network device receiving an IPv4 packet whose source and/or > destination address is in the 169.254/16 prefix MUST NOT forward it, > regardless of the TTL in the IP header. I should say that I am not going to withhold my participation in consensus based on whether this advice is followed - if the text is left as is, I don't think it does a lot of harm, but it's technically incorrect, and could conceivably lead someone to waste a lot of time trying to figure out how to implement it. LL11: I agree that the proposed new text is better than the old text. However, I believe that it would be sufficient to simply delete the old text - the old text isn't correct, and the new text is sufficiently vague that reminds me of a legal disclaimer. I don't think it offers any meaningful guidance to an implementor. I would participate in a consensus on this point either with the new text, or with the old text removed. LL17: I agree with the proposed change. LL19: I agree to this if and only if LL23 is rejected. I think these two issued need to be tied together. The protocol is less susceptible to denial of service if LL19 is accepted and LL23 is rejected. However, I am not sure there is consensus to reject LL23. Without rejecting LL23, LL19 completely breaks link-local, and so obviously it can't be accepted. Having said that, I would prefer that LL19 be accepted and LL23 rejected, rather than that LL23 be accepted and LL19 rejected. If LL19 is accepted and LL23 rejected, some other proposed changes will need to be reconsidered. From owner-zeroconf@merit.edu Sun Feb 16 16:09:45 2003 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 QAA29712 for ; Sun, 16 Feb 2003 16:09:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 03EFB9121F; Sun, 16 Feb 2003 16:11:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B71E491223; Sun, 16 Feb 2003 16:11:22 -0500 (EST) 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 7CF6F9121F for ; Sun, 16 Feb 2003 16:11:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 640445DDCF; Sun, 16 Feb 2003 16:11:18 -0500 (EST) 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 1A6A85DDCA for ; Sun, 16 Feb 2003 16:11:18 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 402DA5991D; Sun, 16 Feb 2003 21:11:21 +0000 (GMT) Message-ID: <000901c2d5ff$f2acc1a0$131010ac@aldebaran> From: "Philip Nye" To: "Ted Lemon" , References: <9E9876FE-415E-11D7-BBEB-00039367340A@nominum.com> Subject: Re: My positions on pending items 6, 8, 11, 17, 19, 23 Date: Sun, 16 Feb 2003 21:11:17 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Ted Lemon" ... > LL8: The text imposes some implementation requirements that don't make > sense, because the implementor has no way of knowing whether or not a > particular node is a router. This text should be removed: > > > section 2.6 > > If the destination address is in the 169.254/16 prefix ... > > The host MUST NOT send the packet to any router for forwarding. > > > > [...] > > The host MUST NOT send the packet to any router for forwarding. > > > > This text should be replaced: > > > section 2.7 > > An IPv4 packet whose source and/or destination address is in the > > 169.254/16 prefix MUST NOT be sent to any router for forwarding, and > > any network device receiving such a packet MUST NOT forward it, > > regardless of the TTL in the IP header. > > With this: > > > section 2.7 > > Any network device receiving an IPv4 packet whose source and/or > > destination address is in the 169.254/16 prefix MUST NOT forward it, > > regardless of the TTL in the IP header. While I agree that in general "the implementor has no way of knowing whether or not a particular node is a router". I do not think the requirement on the sender should be removed as there is no guarantee that routers on the local link will be LL compliant and there is also no guarantee that the stack will _not_ know where a router is. A packet for routing is distinguished by the fact that it's destination address is different from that of the host it is sent to, so the requirement for IPv4LL is really that packets are only ever sent directly to their destination address. How about this: > Any IPv4 packet sent whose source and/or destination address is in the > 169.254/16 prefix MUST be sent directly to its final destination, as > identified by ARP, on the same link. It MUST not be sent to any other > destination as it might then be forwarded off the link. Then add the ban on forwarding as well. Philip From owner-zeroconf@merit.edu Sun Feb 16 18:28:16 2003 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 SAA01107 for ; Sun, 16 Feb 2003 18:28:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CD7A89123B; Sun, 16 Feb 2003 18:31:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B678A9123C; Sun, 16 Feb 2003 18:31:52 -0500 (EST) 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 D49149123B for ; Sun, 16 Feb 2003 18:31:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id B71E75DE13; Sun, 16 Feb 2003 18:31:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id B745B5DDF3 for ; Sun, 16 Feb 2003 18:31:48 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1GNWOaj018579; Mon, 17 Feb 2003 01:32:25 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1GNWL8s018578; Mon, 17 Feb 2003 01:32:21 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: LL17 [Re: My positions on pending items 6, 8, 11, 17, 19, 23] From: Mika Liljeberg To: Philip Nye Cc: Ted Lemon , zeroconf@merit.edu In-Reply-To: <000901c2d5ff$f2acc1a0$131010ac@aldebaran> References: <9E9876FE-415E-11D7-BBEB-00039367340A@nominum.com> <000901c2d5ff$f2acc1a0$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045438340.17019.32.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Feb 2003 01:32:21 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-02-16 at 23:11, Philip Nye wrote: > How about this: Let's try something a bit more precise: A compliant node MUST use the 169.254/16 prefix, in addition to any other on-link prefixes it may have, when determining whether a particular destination is on-link. A compliant node MUST NOT send a packet having a source address in the 169.254/16 range to an off-link destination. A received packet with a source address in the 169.254/16 range and a destination address that is not one of the receiving node's own IP addresses MUST be discarded. MikaL From owner-zeroconf@merit.edu Sun Feb 16 18:31:43 2003 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 SAA01159 for ; Sun, 16 Feb 2003 18:31:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ACE769123C; Sun, 16 Feb 2003 18:35:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CC4B9123E; Sun, 16 Feb 2003 18:35:21 -0500 (EST) 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 749DA9123C for ; Sun, 16 Feb 2003 18:35:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4CEB75DE3F; Sun, 16 Feb 2003 18:35:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id BF3DC5DDF3 for ; Sun, 16 Feb 2003 18:35:19 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1GNXKb22790; Sun, 16 Feb 2003 17:33:21 -0600 (CST) Date: Sun, 16 Feb 2003 17:35:18 -0600 Subject: Re: My positions on pending items 6, 8, 11, 17, 19, 23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Philip Nye" From: Ted Lemon In-Reply-To: <000901c2d5ff$f2acc1a0$131010ac@aldebaran> Message-Id: <4EB3F83E-4207-11D7-9D01-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> Any IPv4 packet sent whose source and/or destination address is in the >> 169.254/16 prefix MUST be sent directly to its final destination, as >> identified by ARP, on the same link. The text already says this, although with somewhat different wording. >> It MUST not be sent to any other >> destination as it might then be forwarded off the link. There's no reason to say this. The existing text already excludes this. Then only time that the packet could get forwarded off-net would be if the IPv4ll implementation were broken, in that it did not follow the explicit recommendation of the standard, or if there were a router doing proxy arp, in which case the IPv4ll implementation would have no way of knowing that it was a router. As I said, I am not going to object strongly to the text as written, but I do think that putting in this requirement, whether worded the way you have done, or worded as the document currently is, has the potential to create confusion, and that is why I raised the issue. From owner-zeroconf@merit.edu Sun Feb 16 18:47:19 2003 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 SAA01262 for ; Sun, 16 Feb 2003 18:47:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5163F91241; Sun, 16 Feb 2003 18:48:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B568991245; Sun, 16 Feb 2003 18:48:39 -0500 (EST) 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 024D791241 for ; Sun, 16 Feb 2003 18:48:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA7E55DDAF; Sun, 16 Feb 2003 18:48:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id EC0605DDA0 for ; Sun, 16 Feb 2003 18:48:10 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1GNmnaj018639; Mon, 17 Feb 2003 01:48:50 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1GNmnks018638; Mon, 17 Feb 2003 01:48:49 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: My positions on pending items 6, 8, 11, 17, 19, 23 From: Mika Liljeberg To: Ted Lemon Cc: Philip Nye , zeroconf@merit.edu In-Reply-To: <4EB3F83E-4207-11D7-9D01-00039317663C@nominum.com> References: <4EB3F83E-4207-11D7-9D01-00039317663C@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045439328.17019.40.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Feb 2003 01:48:49 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-02-17 at 01:35, Ted Lemon wrote: > As I said, I am not going to object strongly to the text as written, > but I do think that putting in this requirement, whether worded the way > you have done, or worded as the document currently is, has the > potential to create confusion, and that is why I raised the issue. One thing I don't much like in any of the proposed wordings is the role of ARP. Normally, on-link determination is done as part of route selection *prior* to running ARP. First you determine whether the packet needs to be sent to a gateway or to an on-link destination. Then if you don't have the link-layer address you run ARP to get it. Using ARP for on-link determination is a perversion that totally scrambles the logic of existing stacks. That's why I proposed a different wording in the previous mail. MikaL From owner-zeroconf@merit.edu Sun Feb 16 23:51:19 2003 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 XAA04741 for ; Sun, 16 Feb 2003 23:51:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5569091218; Sun, 16 Feb 2003 23:54:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D27B91247; Sun, 16 Feb 2003 23:54:58 -0500 (EST) 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 0EEC691218 for ; Sun, 16 Feb 2003 23:54:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id DC7AF5DEB9; Sun, 16 Feb 2003 23:54:56 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by segue.merit.edu (Postfix) with ESMTP id AEFC65DD8D for ; Sun, 16 Feb 2003 23:54:56 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18kdIr-0005yp-00; Sun, 16 Feb 2003 20:54:53 -0800 Date: Sun, 16 Feb 2003 23:52:11 -0500 From: Keith Moore To: Stuart Cheshire Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL16 Split references Message-Id: <20030216235211.2eb83599.moore@cs.utk.edu> In-Reply-To: <200302150722.h1F7Mps12569@scv1.apple.com> References: <200302150722.h1F7Mps12569@scv1.apple.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Keith, we may disagree frequently, but I know you are smart, so here's a > genuine question for you: > > Suppose Apple were to allow and encourage third-parties to develop > hot-swappable modules that are compatible with Xserve RAID? Suppose > further that this family of hot-swappable modules becomes very popular, > and other RAID vendors want to build RAID chassis that accept said > modules. To properly serve the industry doing this, there needs to be a > standard (just like PCI is a standard). > > Who is responsible for defining this inter-company standard for > communication using IP over Ethernet inside a computer chassis, if not > the IETF? I don't know if there is one. Just because a technology might be useful if standardized doesn't mean that there's an organization already in place that is well-suited to standardize it. It certainly doesn't make much sense for IETF to standardize behavior that encourages balkanazation of the Internet. From owner-zeroconf@merit.edu Mon Feb 17 00:23:54 2003 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 AAA05160 for ; Mon, 17 Feb 2003 00:23:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7632C91247; Mon, 17 Feb 2003 00:27:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DACF9124D; Mon, 17 Feb 2003 00:27:33 -0500 (EST) 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 1D6F191247 for ; Mon, 17 Feb 2003 00:27:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0410E5DE9F; Mon, 17 Feb 2003 00:27:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by segue.merit.edu (Postfix) with ESMTP id D584C5DDFB for ; Mon, 17 Feb 2003 00:27:31 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18kdoO-0007IH-00; Sun, 16 Feb 2003 21:27:28 -0800 Date: Mon, 17 Feb 2003 00:24:46 -0500 From: Keith Moore To: Stuart Cheshire Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL10 applications assume addresses are routable? Message-Id: <20030217002446.4b754c07.moore@cs.utk.edu> In-Reply-To: <200302150725.h1F7PRf11431@scv3.apple.com> References: <200302150725.h1F7PRf11431@scv3.apple.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Several people have said: > > >Many applications fundamentally assume > >addresses of communicating peers are routable > > I submit that this is utter nonsense. It depends on how you interpret 'routable'. I agree with you that very few apps care how their packets get from one point to another, as long as they get there. But if you interpret 'routable' in the sense of 'having the properties of a normal IP address, as opposed to those of a LL address', then it's a very reasonable statement. A slight change of wording might help. e.g. 'many applications fundamentally assume that addresses are uniquely bound to hosts within the temporal and topological scope of the application, and/or that addresses used by pairs of communicating hosts are also usable by other hosts participating in the same application.' Keith From owner-zeroconf@merit.edu Mon Feb 17 00:36:01 2003 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 AAA05296 for ; Mon, 17 Feb 2003 00:36:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1959B9124D; Mon, 17 Feb 2003 00:39:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB2C691259; Mon, 17 Feb 2003 00:39:40 -0500 (EST) 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 CB12F9124D for ; Mon, 17 Feb 2003 00:39:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id AA0355DDFB; Mon, 17 Feb 2003 00:39:39 -0500 (EST) 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 5E9B25DD8D for ; Mon, 17 Feb 2003 00:39:39 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h1H5ddET009779 for ; Sun, 16 Feb 2003 22:39:39 -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 WAA20631 for ; Sun, 16 Feb 2003 22:39:37 -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 h1H5dZo3016062 for ; Mon, 17 Feb 2003 16:39:35 +1100 (EST) Message-ID: <3E507597.2050507@motorola.com> Date: Mon, 17 Feb 2003 16:39:35 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: LL6, LL8, LL10, LL11, LL16, LL17, LL19 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit LL6 Add security considerations note regarding wireless LANs === Reject suggested text. Section 2.8 is about IP forwarding, but the proposed text talks about link-layer and physical security (which are good things to talk about, just not here). Alternative suggestion: remove everything in Section 2.8 except for the first paragraph. The "Security Considerations" section already says: implementers of devices supporting the Internet Protocol must not assume that a customer's local network is free from security risks. LL8 Is additional Routing Considerations text needed? === Accept. (ie No Change) I would support Ted Lemon's suggestion for this as well: http://www.merit.edu/mail.archives/zeroconf/msg01861.html LL10 Add warnings to applicability statement ==== Accept, with changes. I support Philip Nye's text, as munged and quoted by Erik: http://www.merit.edu/mail.archives/zeroconf/msg01828.html FWIW, I'm not particularly keen on the "profound" wording of the first suggested paragraph. On an isolated network, with one subnet, many of those applications are fundamentally going to work just fine, in the face of all the assumptions that apparently no longer hold. LL11 Add security consideration for the threat where an attacker ==== forces address reconfiguration Accept. As suggested on the issues page. I do not support the text about sending RSTs, e.g. the text: http://www.merit.edu/mail.archives/zeroconf/msg01830.html Local TCP connection hijacking is possible with or without IPv4LL, and the suggested countermeasure adds little. LL16 Separate normative and informative references. ==== Accept. Surely the new editor can figure it out. LL17 Hosts with configured addresses MUST ARP for v4 LL addresses ==== Accept with changes. Modification suggested by Christian Huitema seems good: http://www.merit.edu/mail.archives/zeroconf/msg01842.html LL19 Do not use v4LL source address to non-v4LL destinations ==== Reject. We had what appeared to be consensus that hosts with non-v4LL addresses should be allowed to communicate with hosts that had only IPv4-LL addresses. I don't see any new information which would change my mind on that score. From owner-zeroconf@merit.edu Mon Feb 17 04:21:45 2003 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 EAA18277 for ; Mon, 17 Feb 2003 04:21:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 345FE91207; Mon, 17 Feb 2003 04:25:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E823C91264; Mon, 17 Feb 2003 04:25:23 -0500 (EST) 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 E613891207 for ; Mon, 17 Feb 2003 04:25:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id D562A5DE01; Mon, 17 Feb 2003 04:25:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta08bw.bigpond.com (mta08bw.bigpond.com [144.135.24.137]) by segue.merit.edu (Postfix) with ESMTP id 6DABF5DDB5 for ; Mon, 17 Feb 2003 04:25:21 -0500 (EST) Received: from pc-00206 ([144.135.24.72]) by mta08bw.bigpond.com (Netscape Messaging Server 4.15 mta08bw Jul 16 2002 22:47:55) with SMTP id HAG4U600.8RZ; Mon, 17 Feb 2003 19:25:18 +1000 Received: from CPE-203-51-28-240.nsw.bigpond.net.au ([203.51.28.240]) by bwmam02.mailsvc.email.bigpond.com(MailRouter V3.0n 17/7372518); 17 Feb 2003 19:25:18 From: Brad Hards To: , zeroconf-workers@lists.sourceforge.net Subject: zeroconf paper from linux.conf.au Date: Mon, 17 Feb 2003 20:11:48 +1100 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: <200302172011.48364.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 For anyone interested, I spoke at linux.conf.au 2003, on zeroconf. The conference was triple-track, and I probably got about a third of the attendees, and I got some good questions, so I was pretty happy. The paper is available (in HTML) at: http://zeroconf.sourceforge.net/zeroconf-lca2003/t1.html The slides are available at: http://zeroconf.sourceforge.net/zeroconf-lca2003/slideshow/index.html The paper is also available in other formats: http://zeroconf.sourceforge.net/zeroconf-lca2003/zeroconf.sgml http://zeroconf.sourceforge.net/zeroconf-lca2003/zeroconf.ps http://zeroconf.sourceforge.net/zeroconf-lca2003/zeroconf.pdf I'd welcome any feedback. Brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+UKdUW6pHgIdAuOMRAp90AJ9ynbDh9Ax8yGhomQDYrVREkdJMQQCfWIbf JNh6snO7/HIojQIc99//7bo= =vIYG -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Mon Feb 17 11:54:18 2003 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 LAA25747 for ; Mon, 17 Feb 2003 11:54:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 106B591218; Mon, 17 Feb 2003 11:57:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D472D9121F; Mon, 17 Feb 2003 11:57:56 -0500 (EST) 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 E6ABA91218 for ; Mon, 17 Feb 2003 11:57:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id CAA585E028; Mon, 17 Feb 2003 11:57:55 -0500 (EST) 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 4B2455DE6C for ; Mon, 17 Feb 2003 11:57:55 -0500 (EST) 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 JAA22529 for ; Mon, 17 Feb 2003 09:57:54 -0700 (MST) Received: from sun.com (vpn-129-159-0-17.EMEA.Sun.COM [129.159.0.17]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1HGvpl12313 for ; Mon, 17 Feb 2003 17:57:52 +0100 (MET) Message-ID: <3E51144C.5050803@sun.com> Date: Mon, 17 Feb 2003 17:56:44 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: [LL10] Add warnings to applicability statement Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please note that the discussion period for this expires on 22 Feb 03. I believe there is reason to 'defer' the decision on this until, as Stuart suggests, we have a list of applications for which there are applicability limitations. We must undertake this anyway, for issues LL4 No examples of applications LL5 Higher layer protocol considerations is not sufficiently draconian I believe the consensus call at this point should be Accept *for applications identified* in discussion of LL5. I would like to see an analysis for IPP, HTTP, NFS, SIP, SMTP and perhaps LDAP for cases where (a) a client has a v4LL address and a server has a v4LL address and a global address (b) a server has a v4LL address and a client has a v4LL address and a global address (c) a server has a v4LL address and another server has a v4LL and a global address (this is important for several protocols in which servers talk to each other, there are proxies, etc.) I am not calling for this analysis for LL10, but I anticipate that the week after next we will discuss LL4, LL5 and other application related issues (ending Mar 3). Please let me know if you can volunteer for analysis of any of these protocols as a subject matter expert. Thanks. Erik ZEROCONF WG chair From owner-zeroconf@merit.edu Mon Feb 17 11:55:00 2003 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 LAA25789 for ; Mon, 17 Feb 2003 11:55:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6E8259121F; Mon, 17 Feb 2003 11:58:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E51191221; Mon, 17 Feb 2003 11:58:40 -0500 (EST) 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 5CC9E9121F for ; Mon, 17 Feb 2003 11:58:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 45FDA5E029; Mon, 17 Feb 2003 11:58:39 -0500 (EST) 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 EA89A5E028 for ; Mon, 17 Feb 2003 11:58:38 -0500 (EST) 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 JAA22911 for ; Mon, 17 Feb 2003 09:58:37 -0700 (MST) Received: from sun.com (vpn-129-159-0-17.EMEA.Sun.COM [129.159.0.17]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1HGwal12334 for ; Mon, 17 Feb 2003 17:58:36 +0100 (MET) Message-ID: <3E51147E.9040008@sun.com> Date: Mon, 17 Feb 2003 17:57:34 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Consensus action: ACCEPT [LL6] Add security considerations note regarding wireless LANs Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit RESULT: Accept ACTION: Add to Security Considerations section: The existence of local links without physical security, such as LANs with attached wireless base stations, means that expecting all local links to be secure enough that normal precautions can be dispensed with is an extremely dangerous practice, which will expose users to considerable risks. Dissent: Keith Moore Keith argued for a stronger requirement which discouraged or disallowed automatic configuration on any wireless link. Erik ZEROCONF WG chair From owner-zeroconf@merit.edu Mon Feb 17 11:55:25 2003 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 LAA25813 for ; Mon, 17 Feb 2003 11:55:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 25DF791221; Mon, 17 Feb 2003 11:59:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E19B891226; Mon, 17 Feb 2003 11:59:04 -0500 (EST) 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 C759491221 for ; Mon, 17 Feb 2003 11:59:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id B78BA5E084; Mon, 17 Feb 2003 11:59:03 -0500 (EST) 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 38E9E5E029 for ; Mon, 17 Feb 2003 11:59:03 -0500 (EST) 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 JAA23041 for ; Mon, 17 Feb 2003 09:59:02 -0700 (MST) Received: from sun.com (vpn-129-159-0-17.EMEA.Sun.COM [129.159.0.17]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1HGx0l12346 for ; Mon, 17 Feb 2003 17:59:00 +0100 (MET) Message-ID: <3E511498.60306@sun.com> Date: Mon, 17 Feb 2003 17:58:00 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Consensus action: ACCEPT [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ACTION: Accept RESULT: Make the following change in section 2.6 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 MUST 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 the destination on the same physical link. In many network stacks, achieving this functionality may be as simple as adding a routing table entry indicating that 169.254/16 is directly reachable on the local link. becomes: If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), then it MUST be routed directly to the destination address and then send its packet directly to the destination on the same physical link. In many network stacks, achieving this functionality may be as simple as adding a routing table entry indicating that 169.254/16 is directly reachable on the local link. Add to the terminology section: directly routed A datagram is directly routed to a destination if it is sent to the destination address. A datagram that is directly routed MUST NOT be sent to another address so that it will be forwarded to the destination address. From owner-zeroconf@merit.edu Mon Feb 17 11:55:41 2003 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 LAA25849 for ; Mon, 17 Feb 2003 11:55:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 567AA91226; Mon, 17 Feb 2003 11:59:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2657791229; Mon, 17 Feb 2003 11:59:20 -0500 (EST) 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 9479291226 for ; Mon, 17 Feb 2003 11:59:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7EBC95E094; Mon, 17 Feb 2003 11:59:18 -0500 (EST) 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 F12745E084 for ; Mon, 17 Feb 2003 11:59:17 -0500 (EST) 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 JAA12263 for ; Mon, 17 Feb 2003 09:59:16 -0700 (MST) Received: from sun.com (vpn-129-159-0-17.EMEA.Sun.COM [129.159.0.17]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1HGxEl12352 for ; Mon, 17 Feb 2003 17:59:15 +0100 (MET) Message-ID: <3E5114A7.7040900@sun.com> Date: Mon, 17 Feb 2003 17:58:15 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Consensus action: REJECT [LL19] Do not use v4LL source address to non-v4LL destinations Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit RESULT: Reject Erik ZEROCONF WG chair From owner-zeroconf@merit.edu Mon Feb 17 11:55:58 2003 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 LAA25869 for ; Mon, 17 Feb 2003 11:55:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6785C91229; Mon, 17 Feb 2003 11:59:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B6179122B; Mon, 17 Feb 2003 11:59:37 -0500 (EST) 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 B1B9791229 for ; Mon, 17 Feb 2003 11:59:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9AC985DE6C; Mon, 17 Feb 2003 11:59:35 -0500 (EST) 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 1BB775E029 for ; Mon, 17 Feb 2003 11:59:35 -0500 (EST) 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 JAA12373 for ; Mon, 17 Feb 2003 09:59:34 -0700 (MST) Received: from sun.com (vpn-129-159-0-17.EMEA.Sun.COM [129.159.0.17]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1HGxVl12364 for ; Mon, 17 Feb 2003 17:59:32 +0100 (MET) Message-ID: <3E5114B8.5000406@sun.com> Date: Mon, 17 Feb 2003 17:58:32 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Consensus action: ACCEPT [LL8] Is additional Routing Considerations text needed? Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit RESULT: Accept ACTION: Add a new routing considerations section with text: The link local address block (169.254/16) MUST NOT be included as a reachable prefix in any dynamic routing protocol. Subnets of that address block (which should not exist - see sect N.M) MUST NOT be included either. NOTE: Alex Zinin has not gotten back to us regarding his comment. If he has additional concerns or does not approve of the text above, we will open a new issue. NOTE2: Ted Lemon noted that autoconfigured hosts may not know what address a router has, so all the statements regarding not forwarding to a router do not make sense. --------------------------- If anyone agrees with the below, please submit a new issue requesting the change: Thomas Narten suggested that in order to address this concern it might make sense to improve this text with the following additional terminology: Thomas Narten wrote: > This document might find it useful to define "non-local" or > some term to indicate addresses that are connected to the same link as > the sender. Maybe on-link and off-link are the best terms, given that > IPv6 uses them. Then, one could say. > > Definitions (stolen from 2460): > router - a node that forwards packets not explicitly addressed to itself. on-link destination - a destination that is attached to the same link as the sender. Packets for on-link destinations are sent directly to that destination (e.g., by first ARPing for the destination to determine its link-layer address) off-link destination - Destination addresses that are not on the same link as the sender. Packets to off-link destinations must be forwarded through a router. > note: "routable" might also be useful to define more formally (there > is a definition in the document): > > This document uses the term "routable address" to refer to all > unicast addresses outside the 169.254/16 prefix, including global > addresses and private addresses such as Net 10/8 [RFC 1918], all of > which may be forwarded via routers. > Routable is a bad term (it's been cited as confusing on the > list). Might be better to talk about scopes, which is the real issue. > > then change: >> The link local address block (169.254/16) MUST NOT be >> included as a reachable prefix in any dynamic routing protocol. >> Subnets of that address block (which should not exist - see sect >> N.M) MUST NOT be included either. > to The link local address block (169.254/16) is reserved for addresses that are on-link. Thus, it makes no sense to advertise the prefix in routing protocols. The link-local address block (and any addresses within the block) MUST NOT be included as a reachable prefix in any dynamic routing protocol. It SHOULD be ignored when received in messages from routing protocols. Erik ZEROCONF WG chair From owner-zeroconf@merit.edu Mon Feb 17 11:56:20 2003 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 LAA25886 for ; Mon, 17 Feb 2003 11:56:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DBD919122B; Mon, 17 Feb 2003 11:59:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADADE9122C; Mon, 17 Feb 2003 11:59:58 -0500 (EST) 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 B7DB29122B for ; Mon, 17 Feb 2003 11:59:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id A6B255E029; Mon, 17 Feb 2003 11:59:57 -0500 (EST) 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 26E1B5DE6C for ; Mon, 17 Feb 2003 11:59:57 -0500 (EST) 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 JAA18401 for ; Mon, 17 Feb 2003 09:59:55 -0700 (MST) Received: from sun.com (vpn-129-159-0-17.EMEA.Sun.COM [129.159.0.17]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1HGxrl12392 for ; Mon, 17 Feb 2003 17:59:54 +0100 (MET) Message-ID: <3E5114CE.5060107@sun.com> Date: Mon, 17 Feb 2003 17:58:54 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Consensus action: ACCEPT [LL11] Add security consideration for the threat where an attacker forces address reconfiguration Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ACTION: Accept RESULT: Add the following sections to the Security Considerations section. ================ Add paragraph 1 ================ A host implementing IPv4 link-local configuration has the additional vulnerability to selective reconfiguration and disruption. It is possible for an on-link attacker to issue ARP packets that would cause a host to believe the address it is using is also being used by someone else and must be given up. Giving up the address and configuring another address will cause a host to break all its connections by switching to a new address. The attacker could force the host implementing IPv4 link-local configuration to select certain addresses, or prevent it from ever completing address selection. This is a distinct threat from that posed by fraudulent ARPs, described in the preceding paragraph. ================ Add paragraph 2 ================ Implementations and users should also note that a node that gives up an address and reconfigures, as required by section 2.5, allows the possibility that another node can easily successfully hijack existing TCP connections. Before abandoning an address due to a conflict, hosts SHOULD actively attempt to reset any existing connections using that address. NOTE: Stuart Cheshire and Aidan Williams argue that the paragraph 2 above is not a threat introduced by IPv4LL. There was no disagreement that this is a real threat, though. Suggestion: Raise a new issue which proposes additional text to indicate that paragraph 2 is not an issue specific to IPv4LL but it is worth considering for implementors of IPv4LL. Erik ZEROCONF WG chair From owner-zeroconf@merit.edu Mon Feb 17 11:57:37 2003 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 LAA25932 for ; Mon, 17 Feb 2003 11:57:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E7C1B9122C; Mon, 17 Feb 2003 12:00:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AAD6191232; Mon, 17 Feb 2003 12:00:17 -0500 (EST) 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 707149122C for ; Mon, 17 Feb 2003 12:00:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id B96795E028; Mon, 17 Feb 2003 12:00:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id C16495DE6C for ; Mon, 17 Feb 2003 12:00:12 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20192 for ; Mon, 17 Feb 2003 09:00:11 -0800 (PST) Received: from sun.com (vpn-129-159-0-17.EMEA.Sun.COM [129.159.0.17]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1HH08l12440 for ; Mon, 17 Feb 2003 18:00:09 +0100 (MET) Message-ID: <3E5114DD.1080906@sun.com> Date: Mon, 17 Feb 2003 17:59:09 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Consensus action: ACCEPT [LL16] Split references Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ACTION: Accept RESULT: Break up the informative / normative references according as 11. Normative References [RFC 826] D. Plummer, "An Ethernet Address Resolution Protocol -or- [RFC 1122] R. Braden, "Requirements for Internet Hosts -- [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 12. Informative References [802] IEEE Standards for Local and Metropolitan Area Networks: [802.1d] ISO/IEC 10038, ANSI/IEEE Std 802.1D-1993 "MAC Bridges". [802.3] Local Area Networks Standard, 802.3 Carrier Sense [802.5] Local Area Networks Standard, 802.5 Token Ring Access [1394] Standard for a High Performance Serial Bus. [RFC 1918] Y. Rekhter et.al., "Address Allocation for Private [RFC 2131] R. Droms, "Dynamic Host Configuration Protocol", [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address [USB] Universal Serial Bus Implementers Forum [X10] X10 Ltd. NOTE: The final distinction of the informative and normative references will depend upon the outcome of the issues still to be decided. We leave it to the I-D editor to track this. We will call out changes to the informative/normative split as required, as we continue work. Erik ZEROCONF WG chair From owner-zeroconf@merit.edu Mon Feb 17 11:57:54 2003 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 LAA25954 for ; Mon, 17 Feb 2003 11:57:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 322BD91232; Mon, 17 Feb 2003 12:00:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC15491235; Mon, 17 Feb 2003 12:00:25 -0500 (EST) 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 E267091232 for ; Mon, 17 Feb 2003 12:00:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 844475E022; Mon, 17 Feb 2003 12:00:23 -0500 (EST) 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 EE01A5DE6C for ; Mon, 17 Feb 2003 12:00:22 -0500 (EST) 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 KAA12918 for ; Mon, 17 Feb 2003 10:00:21 -0700 (MST) Received: from sun.com (vpn-129-159-0-17.EMEA.Sun.COM [129.159.0.17]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1HH0Jl12444 for ; Mon, 17 Feb 2003 18:00:20 +0100 (MET) Message-ID: <3E5114E8.2000200@sun.com> Date: Mon, 17 Feb 2003 17:59:20 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: WG consensus action - 1 week to discuss [LL1] Preferred use of configured to v4 LL address Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please discuss this issue in the next week. Our goal is to achieve WG consensus. Please try to stay on-topic during the discussion. See also http://www.spybeam.org/ll1.html We should strive to conclude this discussion by Feb 24. =================================================================== Description of Issue Preferred use of configured to v4 LL address Submitter Name Erik Guttman Submitter Email Address erik.guttman@sun.com Date first submitted 6 Feb 2003 Reference http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00262.html http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00548.html http://www.merit.edu/mail.archives/zeroconf/2003-02/msg00000.html Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section 1.5 Rationale/Explanation of issue: Supporting multiple address per interface, where one address is v4 LL and other addresses are configured leads to a scoped address problem. Hosts must select which source address to send datagrams with from that interface. In addition, application considerations are much more complex when there are multiple scopes in which the application must operate in. Lengthy description of problem: A lot of the programming issues arise from having multiple addresses of different scope for the same hosts -- there was an extensive debate on that point in the IPv6 WG. If a global address is available, using just that address has a number of good properties -- as in, it does not break existing applications. So, there is a strong incentive to not configure a LL address when a global address is available, either through static configuration or through DHCP. [Christian Huitema] Requested Change: A host should use an IPv4LL address as a source address when the only addresses available to the host are IPv4LL addresses. Otherwise, a host SHOULD NOT use an LL source address unless the application has unambiguously requested this. From owner-zeroconf@merit.edu Mon Feb 17 11:58:18 2003 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 LAA25973 for ; Mon, 17 Feb 2003 11:58:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CB01091235; Mon, 17 Feb 2003 12:00:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98D6C91237; Mon, 17 Feb 2003 12:00:36 -0500 (EST) 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 8688391235 for ; Mon, 17 Feb 2003 12:00:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id E0B475E022; Mon, 17 Feb 2003 12:00:32 -0500 (EST) 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 D31825DE6C for ; Mon, 17 Feb 2003 12:00:29 -0500 (EST) 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 KAA23882 for ; Mon, 17 Feb 2003 10:00:28 -0700 (MST) Received: from sun.com (vpn-129-159-0-17.EMEA.Sun.COM [129.159.0.17]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1HH0Ql12456 for ; Mon, 17 Feb 2003 18:00:26 +0100 (MET) Message-ID: <3E5114EE.2060803@sun.com> Date: Mon, 17 Feb 2003 17:59:26 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: WG consensus action - 1 week to discuss [LL27] LL-only hosts are out of scope for this specification Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please discuss this issue in the next week. Our goal is to achieve WG consensus. Please try to stay on-topic during the discussion. See also http://www.spybeam.org/ll27.html Discussion of this item will conclude on Feb 24. Erik ZEROCONF WG chair ==================================================================== Description of Issue LL-only hosts are out of scope for this specification Submitter Name Keith Moore Submitter Email Address moore@cs.utk.edu Date first submitted 12 Feb 03 Reference Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section Rationale/Explanation of issue: Lengthy description of problem: The Internet Engineering Task Force develops specifications which, when followed, should permit interoperation of conforming implementations on the Internet. With very few exceptions, IETF has considered the behavior of private networks (i.e. networks that are entirely controlled by a single party) as outside of its scope. (Use of the Internet Protocol on purely isolated, ad hoc networks would also be out-of-scope and of little interest to IETF -- except that some interchange between hosts using link-local addresses and hosts using routable addresses is unavoidable, and that absent careful consideration of the effects of such interchange, introduction of link-local addressing to IPv4 would be expected to adversely affect the ability of hosts and applications to interoperate over the Internet.) Inherent in the entire concept of "INTERnet", and the "Internet Protocol" is the ability to communicate _between_ networks. Devices which don't support that ability should not claim conformance to IP or compatibility with the Internet, and IETF should not be blessing specifications that encourage the creation of a class of devices (and applications) that inherently cannot interoperate with the Internet. Requested Change: ##. Hosts which implement only link-local addressing Inherent in the entire concept of "Internet" is the ability to communicate between (not just within) networks, and the Internet Protocol was designed specifically to facilitate communication between hosts on potentially dissimilar, and perhaps distant, networks. Hosts which are inherently incapable of communicating with hosts on other IP networks cannot meaningfully be said to implement the Internet Protocol, or to support Internet connectivity, even if they use similar packet formats. Hosts which are incapable of being configured to use routable addresses, or are incapable of being configured to route packets with nonlocal destinations to a router, or which are incapable of exchanging traffic with hosts on other IP networks, are therefore outside of the scope of this specification. While hosts with such limitations may still be useful in specific contexts, it is not appropriate for such hosts to claim conformance with this specification, or with the Internet Protocol, or compatibility with the Internet. In order to clearly distinguish hosts that implement link-local addressing but are incapable of communicating with the Internet, from hosts that are capable of communicating with the Internet, vendors of the former kind of hosts are strongly urged to choose another name for the former capability. From owner-zeroconf@merit.edu Mon Feb 17 11:58:41 2003 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 LAA26008 for ; Mon, 17 Feb 2003 11:58:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2BC7891237; Mon, 17 Feb 2003 12:00:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EBB869123B; Mon, 17 Feb 2003 12:00:44 -0500 (EST) 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 C802D91237 for ; Mon, 17 Feb 2003 12:00:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 751EC5E022; Mon, 17 Feb 2003 12:00:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id C58405DE6C for ; Mon, 17 Feb 2003 12:00:35 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20324 for ; Mon, 17 Feb 2003 09:00:34 -0800 (PST) Received: from sun.com (vpn-129-159-0-17.EMEA.Sun.COM [129.159.0.17]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1HH0Vl12460 for ; Mon, 17 Feb 2003 18:00:32 +0100 (MET) Message-ID: <3E5114F4.5060407@sun.com> Date: Mon, 17 Feb 2003 17:59:32 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: WG consensus action - 1 week to discuss [LL23] Don't configure needless LL addresses Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please discuss this issue in the next week. Our goal is to achieve WG consensus. Please try to stay on-topic during the discussion. See also http://www.spybeam.org/ll23.html We should strive to conclude this discussion by Feb 24. =================================================================== Description of Issue Don't configure needless LL addresses Submitter Name Robert Elz Submitter Email Address kre@munnari.OZ.AU Date first submitted 9 Feb 2003 Reference http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00262.html http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00548.html http://www.merit.edu/mail.archives/zeroconf/2003-02/msg00000.html Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section 1.5 Rationale/Explanation of issue: See LL1 Lengthy description of problem: See LL1 Requested Change: Delete all of section 1.5, and replace it with: Having addresses of multiple different scopes assigned to an interface with no adequate way to determine in what circumstances each address should be used leads to complexity for applications and confusion for users. A node with any address assigned for a link can communicate with all other devices on that link, whether those other devices use link-local addresses, or routable addresses. For this reason, a host that obtains, or is configured with, a routable address on an interface, SHOULD NOT attempt to configure a link-local address on the same interface. Where a link-local address has been configured on an interface, and a routable address is later configured on the same interface, the host MUST always use the routable address when initiating new communications, and MUST cease advertising the availability of the link-local address through whatever mechanisms that address had been made known to others. A host SHOULD continue to use the link-local address for communications underway when the routable address was configured, and MAY continue to accept new communications addressed to the link-local address. From owner-zeroconf@merit.edu Mon Feb 17 11:58:59 2003 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 LAA26032 for ; Mon, 17 Feb 2003 11:58:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2AFC39123B; Mon, 17 Feb 2003 12:01:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2CEA9123C; Mon, 17 Feb 2003 12:01:26 -0500 (EST) 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 C60109123B for ; Mon, 17 Feb 2003 12:01:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id B68455DE46; Mon, 17 Feb 2003 12:00:44 -0500 (EST) 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 BC0895E094 for ; Mon, 17 Feb 2003 12:00:43 -0500 (EST) 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 JAA25192 for ; Mon, 17 Feb 2003 09:00:42 -0800 (PST) Received: from sun.com (vpn-129-159-0-17.EMEA.Sun.COM [129.159.0.17]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1HH0dl12472 for ; Mon, 17 Feb 2003 18:00:40 +0100 (MET) Message-ID: <3E5114FC.1040703@sun.com> Date: Mon, 17 Feb 2003 17:59:40 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: WG consensus action - 1 week to discuss [LL2] Explicit Additional Mechanism to disable v4 LL Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please discuss this issue in the next week. Our goal is to achieve WG consensus. Please try to stay on-topic during the discussion. See also http://www.spybeam.org/ll2.html We should strive to conclude this discussion by Feb 24. =================================================================== Description of Issue Explicit Additional Mechanism to disable v4LL Submitter Name Erik Guttman Submitter Email Address erik.guttman@sun.com Date first submitted 6 Feb 2002 Reference http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00459.html Security considerations with the proposal: http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00473.html Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section Not in document presently. Rationale/Explanation of issue: The specification should be modified to define or require some additional mechanism to disable IPv4 LL autoconfiguration. This mechanism would be mandatory to implement and cause all hosts using IPv4 LL to stop doing so. Lengthy description of problem: ... the desire to have a way to disable LL addresses isn't so that the network manager can make sure that no-one can use the net without their permission, or similar, that's ludicrous, the node(s) could just configure themselves with network 10 addresses, or 192.168, or anything else (including addresses from the block that are designated for use on the net in question). The reason is because the net manager knows what will, and won't work properly on their net, and can provide advice to the nodes as to what they should do in order to work well in the local environment. What is requested is RFC 2563 or some derivative. Requested Change: 1.3 Alternate Configuration Mechanisms As explained in the previous section (1.2), the link-local addresses assigned by this protocol are intended for small ad-hoc networks. However, it is very rare for a system to be constructed that can only ever be connected to such networks. When connected to a properly managed network, nodes should operate correctly for that network. To allow for this, all nodes that implement this protocol MUST also provide some mechanism to allow for routable addresses to be configured. That mechanism MAY use the DHCP protocol [RFC2131] in appropriate cases, but other means, such as manual configuration, are also adequate. Many nodes using this protocol, on large networks, can cause excessive traffic as explained in the previous section (1.2). For this reason, and others, it can be necessary to disable use of link-local addresses in some situations where they are not required. The configuration mechanism provided MUST provide a mechanism to disable the assignment of link local addresses on an interface. Where that configuration mechanism uses DHCP, the node MUST implement the DHCP option to disable stateless auto-configuration in IPv4 clients [RFC2563]. From owner-zeroconf@merit.edu Mon Feb 17 12:22:19 2003 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 MAA26473 for ; Mon, 17 Feb 2003 12:22:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 02E359123C; Mon, 17 Feb 2003 12:25:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE76391240; Mon, 17 Feb 2003 12:25:58 -0500 (EST) 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 BC7139123C for ; Mon, 17 Feb 2003 12:25:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 994135DED4; Mon, 17 Feb 2003 12:25:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 318F05DDC5 for ; Mon, 17 Feb 2003 12:25:57 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1HGD3P14110 for ; Mon, 17 Feb 2003 08:13:03 -0800 Date: Mon, 17 Feb 2003 08:13:03 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: [Issue 1]: Preferred use of configured to v4LL Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I support the proposed resolution, subject to the constraint that a host would not initiate new connections from the v4LL once a configured address is acquired, but would not have to immediately drop old ones. From owner-zeroconf@merit.edu Mon Feb 17 12:25:59 2003 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 MAA26588 for ; Mon, 17 Feb 2003 12:25:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DEAD491240; Mon, 17 Feb 2003 12:29:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E18A91241; Mon, 17 Feb 2003 12:29:39 -0500 (EST) 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 982F191240 for ; Mon, 17 Feb 2003 12:29:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 82FA85E084; Mon, 17 Feb 2003 12:29:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 0C2A95DED4 for ; Mon, 17 Feb 2003 12:29:38 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1HGGix14383 for ; Mon, 17 Feb 2003 08:16:44 -0800 Date: Mon, 17 Feb 2003 08:16:44 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: [Issue 2]: Explicit Additional Mechanism to disable v4LL Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Most of the text here seems ok, with the exception of the last sentence: "Where that configuration mechanism uses DHCP, the node MUST implement the DHCP option to disable stateless auto-configuration in IPv4 clients [RFC2563]." If we accept the resolution of Issue 1, then we already have a way to disable stateless auto-configuration -- provide a DHCPv4 address. As a result, this last sentence is unnecessary. Presumably if there were a real need for this functionality, we would have implementations of RFC2563, but we don't. As a result, the right thing to do with RFC 2563 is to deprecate it, not make it mandatory. From owner-zeroconf@merit.edu Mon Feb 17 12:37:20 2003 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 MAA26955 for ; Mon, 17 Feb 2003 12:37:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD99D91241; Mon, 17 Feb 2003 12:41:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A732C91242; Mon, 17 Feb 2003 12:41:00 -0500 (EST) 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 9D30F91241 for ; Mon, 17 Feb 2003 12:40:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E07F5DEF1; Mon, 17 Feb 2003 12:40:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 085625DDC5 for ; Mon, 17 Feb 2003 12:40:59 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1HGS5X14935 for ; Mon, 17 Feb 2003 08:28:05 -0800 Date: Mon, 17 Feb 2003 08:28:05 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: [Issue 23]: Don't configure needless LLv4 addresses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I am in favor of this change, although I think that if it is accepted, we don't also need the change proposed in Issue #1. Issue 1 deals with when LLv4 addresses are used. This issue attempts to restrict when they are configured. To some extent the text of the two issues overlap. Overall, I think I like the text of 23 better than Issue 1, because it deals with the issue of initiating new connections vs. continuing to use old ones, and is more specific. Comments on the text: "Having addresses of multiple different scopes assigned to an interface with no adequate way to determine in what circumstances each address should be used leads to complexity for applications and confusion for users. A node with any address assigned for a link can communicate with all other devices on that link, whether those other devices use link-local addresses, or routable addresses." Yes, this is true now that we have accepted Issue #17. "For this reason, a host that obtains, or is configured with, a routable address on an interface, SHOULD NOT attempt to configure a link-local address on the same interface." I am not entirely sure what configure means here. Does it mean the same thing as SHOULD NOT use? How is it different? What specific things does this imply aren't done? Are they all covered in the next paragraph? "Where a link-local address has been configured on an interface, and a routable address is later configured on the same interface, the host MUST always use the routable address when initiating new communications, and MUST cease advertising the availability of the link-local address through whatever mechanisms that address had been made known to others." This makes sense, I think. I assume that "advertising" doesn't include ARP replies. "A host SHOULD continue to use the link-local address for communications underway when the routable address was configured, and MAY continue to accept new communications addressed to the link-local address." This is good. Assuming we accept these changes, why do we also need the resolution to Issue #1? From owner-zeroconf@merit.edu Mon Feb 17 12:57:36 2003 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 MAA27291 for ; Mon, 17 Feb 2003 12:57:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 60D3791242; Mon, 17 Feb 2003 13:00:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C72E91247; Mon, 17 Feb 2003 13:00:50 -0500 (EST) 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 1C5FD91242 for ; Mon, 17 Feb 2003 13:00:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id DE3085DDED; Mon, 17 Feb 2003 13:00:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 095895DDC5 for ; Mon, 17 Feb 2003 13:00:29 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1HGlak16063 for ; Mon, 17 Feb 2003 08:47:36 -0800 Date: Mon, 17 Feb 2003 08:47:36 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: [Issue 27]: LL-only hosts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I propose that this issue be rejected. It does seem reasonable to require that a host be able to configure a routable address, but I can also see devices being shipped that do not configure such an address by default. My recommendation would be to replace the currently proposed text with something along these lines: "Host supporting configuration of LLv4 address MUST also support configuration of a routable address, whether manually or automatically." From owner-zeroconf@merit.edu Mon Feb 17 13:18:58 2003 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 NAA27709 for ; Mon, 17 Feb 2003 13:18:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B307D9124D; Mon, 17 Feb 2003 13:22:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84B7391258; Mon, 17 Feb 2003 13:22:30 -0500 (EST) 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 605A19124D for ; Mon, 17 Feb 2003 13:22:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 481755E0A1; Mon, 17 Feb 2003 13:22:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 2B9355E0A0 for ; Mon, 17 Feb 2003 13:22:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id B0A4D14050; Mon, 17 Feb 2003 13:22:28 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 05332-01; Mon, 17 Feb 2003 13:22:28 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 0D93F14045; Mon, 17 Feb 2003 13:22:28 -0500 (EST) Date: Mon, 17 Feb 2003 13:22:27 -0500 From: Keith Moore To: Bernard Aboba Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: [Issue 27]: LL-only hosts Message-Id: <20030217132227.5d8e9cd4.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: e03fcd58648caa0ff6cfe2c2cbfa28b2ae28953c Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I propose that this issue be rejected. it appears that you're supporting the issue in principle, but have issues with the proposed wording. > It does seem reasonable to require that a host be able to configure a > routable address, but I can also see devices being shipped that do not > configure such an address by default. > > My recommendation would be to replace the currently proposed text with > something along these lines: > > "Host supporting configuration of LLv4 address MUST also support > configuration of a routable address, whether manually or > automatically." manual configuration as an alternative would be fine with me as long as a) the manual configuration includes netmask and default route (address alone is insufficient), and b) a host that does not support the standard method of determining local network configuration for connected networks (presumably DHCP) SHOULD require manual configuration to enable LL. but I don't want to see devices advertised as "complies with IETF LL standard for zero configuration" if they do require configuration to work correctly on connected networks. Keith From owner-zeroconf@merit.edu Mon Feb 17 13:45:39 2003 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 NAA28094 for ; Mon, 17 Feb 2003 13:45:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EA29A91244; Mon, 17 Feb 2003 13:49:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5CA291246; Mon, 17 Feb 2003 13:49:18 -0500 (EST) 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 B1E2F91244 for ; Mon, 17 Feb 2003 13:49:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 92D2D5DFB5; Mon, 17 Feb 2003 13:49:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 7B5455DE1F for ; Mon, 17 Feb 2003 13:49:16 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1HInZaj026247; Mon, 17 Feb 2003 20:49:36 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1HInXo3026246; Mon, 17 Feb 2003 20:49:34 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [Issue 23]: Don't configure needless LLv4 addresses From: Mika Liljeberg To: Bernard Aboba Cc: zeroconf@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045507773.17019.62.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Feb 2003 20:49:33 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm reserving judgement on LL1 and LL23 for now. On Mon, 2003-02-17 at 18:28, Bernard Aboba wrote: > "For this reason, a host that obtains, or is configured with, a routable > address on an interface, SHOULD NOT attempt to configure a > link-local address on the same interface." > > I am not entirely sure what configure means here. Does it mean the same > thing as SHOULD NOT use? How is it different? What specific things does > this imply aren't done? Are they all covered in the next paragraph? The text also fails to deal with the issue what to do if the routable address is unconfigured (e.g. by a frustrated DHCP client). > "Where a link-local address has been configured on an interface, and a > routable address is later configured on the same interface, the host > MUST always use the routable address when initiating new communications, > and MUST cease advertising the availability of the link-local address > through whatever mechanisms that address had been made known to others." > > This makes sense, I think. I assume that "advertising" doesn't include > ARP replies. What exactly does advertising include? What is the implication to an implementor? Unless these questions can be answered, the sentence should be deleted. > "A host SHOULD continue to use the link-local address for communications > underway when the routable address was configured, and MAY continue to > accept new communications addressed to the link-local address." I like this bit. > This is good. Assuming we accept these changes, why do we also need the > resolution to Issue #1? We don't. I believe LL1 and LL23 are alternative proposed solutions to the same issue. We can accept either one or we can reject the issue. MikaL From owner-zeroconf@merit.edu Mon Feb 17 14:01:19 2003 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 OAA28425 for ; Mon, 17 Feb 2003 14:01:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 698129126C; Mon, 17 Feb 2003 14:04:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7AE491248; Mon, 17 Feb 2003 14:04:51 -0500 (EST) 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 2025F9126C for ; Mon, 17 Feb 2003 14:04:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id F06665E0A1; Mon, 17 Feb 2003 14:04:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 657775E090 for ; Mon, 17 Feb 2003 14:04:37 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1HHpeN19593; Mon, 17 Feb 2003 09:51:40 -0800 Date: Mon, 17 Feb 2003 09:51:40 -0800 (PST) From: Bernard Aboba To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: Re: [Issue 23]: Don't configure needless LLv4 addresses In-Reply-To: <1045507773.17019.62.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > "For this reason, a host that obtains, or is configured with, a routable > > address on an interface, SHOULD NOT attempt to configure a > > link-local address on the same interface." > > > > I am not entirely sure what configure means here. Does it mean the same > > thing as SHOULD NOT use? How is it different? What specific things does > > this imply aren't done? Are they all covered in the next paragraph? > > The text also fails to deal with the issue what to do if the routable > address is unconfigured (e.g. by a frustrated DHCP client). If the DHCP client doesn't obtain an address, then the routable address would not be configured, no? So I think that part is covered. > > > "Where a link-local address has been configured on an interface, and a > > routable address is later configured on the same interface, the host > > MUST always use the routable address when initiating new communications, > > and MUST cease advertising the availability of the link-local address > > through whatever mechanisms that address had been made known to others." > > > > This makes sense, I think. I assume that "advertising" doesn't include > > ARP replies. > > What exactly does advertising include? What is the implication to an > implementor? Unless these questions can be answered, the sentence should > be deleted. Since there are presumably going to be a bunch of prohibitions on "advertisement" of link local addresses (e.g. don't register them in DNS, don't hand them out in applications, etc.) my guess is that this applies to the remaining mechanisms that are allowable (such as answering LLMNR queries). But you are right that we need to be specific here. > > This is good. Assuming we accept these changes, why do we also need the > > resolution to Issue #1? > > We don't. I believe LL1 and LL23 are alternative proposed solutions to > the same issue. We can accept either one or we can reject the issue. Right. I guess I'm for rejecting LL1 and accepting LL23 with modifications. From owner-zeroconf@merit.edu Mon Feb 17 14:02:16 2003 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 OAA28454 for ; Mon, 17 Feb 2003 14:02:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A528491248; Mon, 17 Feb 2003 14:05:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70D0191249; Mon, 17 Feb 2003 14:05:49 -0500 (EST) 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 6CDFF91248 for ; Mon, 17 Feb 2003 14:05:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5A0735DE1F; Mon, 17 Feb 2003 14:05:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id DF1735DDED for ; Mon, 17 Feb 2003 14:05:47 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1HHqr819668 for ; Mon, 17 Feb 2003 09:52:54 -0800 Date: Mon, 17 Feb 2003 09:52:53 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: [Issue 1]: Preferred use of configured to v4LL In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Now that I've realized that Issue 1 and Issue 23 are mutually exclusive, I'd like to advocate that Issue 1 be rejected, and that the problems described there be solved via the approach of Issue 23 instead. On Mon, 17 Feb 2003, Bernard Aboba wrote: > I support the proposed resolution, subject to the constraint that a host > would not initiate new connections from the v4LL once a configured address > is acquired, but would not have to immediately drop old ones. > > From owner-zeroconf@merit.edu Mon Feb 17 14:11:10 2003 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 OAA28845 for ; Mon, 17 Feb 2003 14:11:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BCE8C91249; Mon, 17 Feb 2003 14:14:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C9159124A; Mon, 17 Feb 2003 14:14:50 -0500 (EST) 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 8AB5891249 for ; Mon, 17 Feb 2003 14:14:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6FE535E0A5; Mon, 17 Feb 2003 14:14:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 83E175DDED for ; Mon, 17 Feb 2003 14:14:48 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1HJFOaj026401; Mon, 17 Feb 2003 21:15:25 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1HJFNgp026400; Mon, 17 Feb 2003 21:15:23 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [Issue 23]: Don't configure needless LLv4 addresses From: Mika Liljeberg To: Bernard Aboba Cc: zeroconf@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045509322.17019.67.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Feb 2003 21:15:23 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-02-17 at 19:51, Bernard Aboba wrote: > If the DHCP client doesn't obtain an address, then the routable address > would not be configured, no? So I think that part is covered. I was thinking lease expiry or manual unconfigure. What will happen if the routable address disappears? Will the node be left without an address or will it acquire a v4LL? MikaL From owner-zeroconf@merit.edu Mon Feb 17 14:21:36 2003 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 OAA29086 for ; Mon, 17 Feb 2003 14:21:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A54D091218; Mon, 17 Feb 2003 14:25:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 751B29121F; Mon, 17 Feb 2003 14:25:17 -0500 (EST) 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 4C88691218 for ; Mon, 17 Feb 2003 14:25:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C3095E0AE; Mon, 17 Feb 2003 14:25:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 13CE85E0AD for ; Mon, 17 Feb 2003 14:25:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id CF63214075; Mon, 17 Feb 2003 14:25:15 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 13142-07; Mon, 17 Feb 2003 14:25:15 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 2DD6114050; Mon, 17 Feb 2003 14:25:15 -0500 (EST) Date: Mon, 17 Feb 2003 14:25:15 -0500 From: Keith Moore To: Bernard Aboba Cc: moore@cs.utk.edu, mika.liljeberg@welho.com, zeroconf@merit.edu Subject: Re: LL23: Don't configure needless LLv4 addresses Message-Id: <20030217142515.30445248.moore@cs.utk.edu> In-Reply-To: References: <1045507773.17019.62.camel@devil> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 525cadc6026ba559c4bd3876ecc8c9396fd84186 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit [subject line changed to make tracking easier] > > What exactly does advertising include? What is the implication to an > > implementor? Unless these questions can be answered, the sentence > > should be deleted. > > Since there are presumably going to be a bunch of prohibitions on > "advertisement" of link local addresses (e.g. don't register them in > DNS, don't hand them out in applications, etc.) my guess is that this > applies to the remaining mechanisms that are allowable (such as > answering LLMNR queries). But you are right that we need to be > specific here. actually you don't want to be too specific, because the problem occurs anytime the address is advertised as being associated with a service, via any means - be it DNS, DHCP, SLP, LLMNR, or something that is application-specific. From owner-zeroconf@merit.edu Mon Feb 17 14:24:03 2003 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 OAA29192 for ; Mon, 17 Feb 2003 14:24:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DB0CC9121F; Mon, 17 Feb 2003 14:27:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD01591221; Mon, 17 Feb 2003 14:27:43 -0500 (EST) 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 A6DAA9121F for ; Mon, 17 Feb 2003 14:27:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8A72D5E0B0; Mon, 17 Feb 2003 14:27:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 0BD195DDED for ; Mon, 17 Feb 2003 14:27:42 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1HIElM20838 for ; Mon, 17 Feb 2003 10:14:48 -0800 Date: Mon, 17 Feb 2003 10:14:47 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: [Issue 27]: LL-only hosts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk >> I propose that this issue be rejected. >it appears that you're supporting the issue in principle, but have >issues with the proposed wording. Yes. > "Host supporting configuration of LLv4 address MUST also support > configuration of a routable address, whether manually or > automatically." >manual configuration as an alternative would be fine with me as long >as > >a) the manual configuration includes netmask and default route > (address alone is insufficient), and Fine. >b) a host that does not support the standard method of determining > local network configuration for connected networks (presumably DHCP) > SHOULD require manual configuration to enable LL. > >but I don't want to see devices advertised as "complies with IETF LL >standard for zero configuration" if they do require configuration >to work correctly on connected networks. You're probably right about this. How about this new text: "Hosts supporting configuration of LLv4 addresses MUST also support configuration of a routable address, netmask and default route, whether manually or automatically. Hosts not supporting automated configuration (such as via DHCPv4) SHOULD require manual configuration to enable LLv4." From owner-zeroconf@merit.edu Mon Feb 17 14:27:33 2003 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 OAA29264 for ; Mon, 17 Feb 2003 14:27:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2FF5E91226; Mon, 17 Feb 2003 14:28:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E72F991229; Mon, 17 Feb 2003 14:28:57 -0500 (EST) 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 7366A91226 for ; Mon, 17 Feb 2003 14:28:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 55E485E0B1; Mon, 17 Feb 2003 14:28:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id DE0785DDED for ; Mon, 17 Feb 2003 14:28:53 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1HIFu121015; Mon, 17 Feb 2003 10:15:56 -0800 Date: Mon, 17 Feb 2003 10:15:56 -0800 (PST) From: Bernard Aboba To: Keith Moore Cc: mika.liljeberg@welho.com, Subject: Re: LL23: Don't configure needless LLv4 addresses In-Reply-To: <20030217142515.30445248.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > actually you don't want to be too specific, because the problem occurs > anytime the address is advertised as being associated with a service, > via any means - be it DNS, DHCP, SLP, LLMNR, or something that is > application-specific. Well, that's still more specific than the text we have now :) From owner-zeroconf@merit.edu Mon Feb 17 14:27:58 2003 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 OAA29278 for ; Mon, 17 Feb 2003 14:27:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A30F091232; Mon, 17 Feb 2003 14:29:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 761D69122C; Mon, 17 Feb 2003 14:29:55 -0500 (EST) 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 6E28991229 for ; Mon, 17 Feb 2003 14:29:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 525925E0B0; Mon, 17 Feb 2003 14:29:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 37B9C5E0AF for ; Mon, 17 Feb 2003 14:29:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 0EF4C14050; Mon, 17 Feb 2003 14:29:51 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 13887-05; Mon, 17 Feb 2003 14:29:50 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 7086814045; Mon, 17 Feb 2003 14:29:50 -0500 (EST) Date: Mon, 17 Feb 2003 14:29:50 -0500 From: Keith Moore To: Bernard Aboba Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: [Issue 27]: LL-only hosts Message-Id: <20030217142950.703aaebd.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 53561005c7a28d165d17f1a78170b54ca962e948 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > You're probably right about this. How about this new text: > > "Hosts supporting configuration of LLv4 addresses MUST also support > configuration of a routable address, netmask and default route, > whether manually or automatically. Hosts not supporting automated > configuration(such as via DHCPv4) SHOULD require manual configuration > to enable LLv4." I like it. Keith From owner-zeroconf@merit.edu Mon Feb 17 14:29:01 2003 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 OAA29301 for ; Mon, 17 Feb 2003 14:29:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 38FC491229; Mon, 17 Feb 2003 14:32:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E69F69122B; Mon, 17 Feb 2003 14:32:11 -0500 (EST) 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 0EE4191229 for ; Mon, 17 Feb 2003 14:32:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id EFE485DEF4; Mon, 17 Feb 2003 14:32:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by segue.merit.edu (Postfix) with ESMTP id 2908F5DDED for ; Mon, 17 Feb 2003 14:32:10 -0500 (EST) Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) with ESMTP id h1HJW4iC022444 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 17 Feb 2003 21:32:04 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) id h1HJW4Ve022440; Mon, 17 Feb 2003 21:32:04 +0200 Date: Mon, 17 Feb 2003 21:32:04 +0200 Message-Id: <200302171932.h1HJW4Ve022440@burp.tkv.asdf.org> From: Markku Savela To: aboba@internaut.com Cc: zeroconf@merit.edu In-reply-to: (message from Bernard Aboba on Mon, 17 Feb 2003 10:14:47 -0800 (PST)) Subject: Re: [Issue 27]: LL-only hosts References: Sender: owner-zeroconf@merit.edu Precedence: bulk > You're probably right about this. How about this new text: > > "Hosts supporting configuration of LLv4 addresses MUST also support > configuration of a routable address, netmask and default route, whether > manually or automatically. Hosts not supporting automated configuration > (such as via DHCPv4) SHOULD require manual configuration to enable LLv4." Isn't this against the zeroconf goal: "without any configuration, plug in the node and it should work"? From owner-zeroconf@merit.edu Mon Feb 17 14:50:19 2003 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 OAA29679 for ; Mon, 17 Feb 2003 14:50:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 935A791218; Mon, 17 Feb 2003 14:54:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B1169121F; Mon, 17 Feb 2003 14:54:00 -0500 (EST) 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 52F5A91218 for ; Mon, 17 Feb 2003 14:53:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3672D5E0AB; Mon, 17 Feb 2003 14:53:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id AD89B5DDED for ; Mon, 17 Feb 2003 14:53:58 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1HIf1g22305; Mon, 17 Feb 2003 10:41:01 -0800 Date: Mon, 17 Feb 2003 10:41:01 -0800 (PST) From: Bernard Aboba To: Markku Savela Cc: zeroconf@merit.edu Subject: Re: [Issue 27]: LL-only hosts In-Reply-To: <200302171932.h1HJW4Ve022440@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > You're probably right about this. How about this new text: > > > > "Hosts supporting configuration of LLv4 addresses MUST also support > > configuration of a routable address, netmask and default route, whether > > manually or automatically. Hosts not supporting automated configuration > > (such as via DHCPv4) SHOULD require manual configuration to enable LLv4." > > Isn't this against the zeroconf goal: "without any configuration, plug > in the node and it should work"? The problem is that if a host doesn't support automatic configuration, then it also can't take direction as to when LLv4 should be enabled (such as preferring a routable address when available). So it could be argued that such a host is already "not working". I can conceive of a device that boots with only LLv4 support, and then can be configured to support routable addressing, but I'd suggest that it is probably more viable for that device to support routable addressing (e.g. DHCPv4) by default. If it does that, then it can also support LLv4 by default, and everything will indeed "just work". From owner-zeroconf@merit.edu Mon Feb 17 15:08:13 2003 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 PAA00075 for ; Mon, 17 Feb 2003 15:08:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1F7479122B; Mon, 17 Feb 2003 15:10:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0CAA91278; Mon, 17 Feb 2003 15:10:31 -0500 (EST) 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 99F669122B for ; Mon, 17 Feb 2003 15:10:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 888575E0B0; Mon, 17 Feb 2003 15:10:27 -0500 (EST) 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 295BC5E0AD for ; Mon, 17 Feb 2003 15:10:27 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h1HKAAA12296; Mon, 17 Feb 2003 15:10:11 -0500 (EST) Date: Mon, 17 Feb 2003 15:09:10 -0500 From: Keith Moore To: Markku Savela Cc: moore@cs.utk.edu, aboba@internaut.com, zeroconf@merit.edu Subject: Re: [LL27]: LL-only hosts Message-Id: <20030217150910.56541bdb.moore@cs.utk.edu> In-Reply-To: <200302171932.h1HJW4Ve022440@burp.tkv.asdf.org> References: <200302171932.h1HJW4Ve022440@burp.tkv.asdf.org> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) 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 > > "Hosts supporting configuration of LLv4 addresses MUST also support > > configuration of a routable address, netmask and default route, > > whether manually or automatically. Hosts not supporting automated > > configuration(such as via DHCPv4) SHOULD require manual > > configuration to enable LLv4." > > Isn't this against the zeroconf goal: "without any configuration, plug > in the node and it should work"? if you want to realize that goal, you need to implement DHCP. LL does not "work" (for any reasonable meaning of "work") on a connected network. what LL allows a host to do is "work" on a disconnected network without manual configuration, about as well as the host could "work" with manual configuration. From owner-zeroconf@merit.edu Mon Feb 17 15:13:13 2003 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 PAA00160 for ; Mon, 17 Feb 2003 15:13:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 394359122C; Mon, 17 Feb 2003 15:16:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F114C91235; Mon, 17 Feb 2003 15:16:53 -0500 (EST) 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 C46009122C for ; Mon, 17 Feb 2003 15:16:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8EDB65E0A3; Mon, 17 Feb 2003 15:16:52 -0500 (EST) 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 173D95E098 for ; Mon, 17 Feb 2003 15:16:52 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h1HKGnA12302; Mon, 17 Feb 2003 15:16:50 -0500 (EST) Date: Mon, 17 Feb 2003 15:16:49 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: [LL1] Preferred use of configured to v4 LL address Message-Id: <20030217151649.3351926f.moore@cs.utk.edu> In-Reply-To: <3E5114E8.2000200@sun.com> References: <3E5114E8.2000200@sun.com> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) 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 I support LL1. From owner-zeroconf@merit.edu Mon Feb 17 15:42:54 2003 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 PAA01002 for ; Mon, 17 Feb 2003 15:42:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3D6B39121D; Mon, 17 Feb 2003 15:46:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0F2891237; Mon, 17 Feb 2003 15:46:32 -0500 (EST) 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 5063A9121D for ; Mon, 17 Feb 2003 15:46:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 955175E0AC; Mon, 17 Feb 2003 15:46:10 -0500 (EST) 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 361585E0A1 for ; Mon, 17 Feb 2003 15:46:10 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h1HKk8A12342; Mon, 17 Feb 2003 15:46:08 -0500 (EST) Date: Mon, 17 Feb 2003 15:46:08 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: [LL10] Add warnings to applicability statement Message-Id: <20030217154608.777b171b.moore@cs.utk.edu> In-Reply-To: <3E51144C.5050803@sun.com> References: <3E51144C.5050803@sun.com> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) 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 > I would like to see an analysis for IPP, HTTP, NFS, SIP, SMTP > and perhaps LDAP for cases where why these specific apps? From owner-zeroconf@merit.edu Mon Feb 17 23:31:15 2003 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 XAA08760 for ; Mon, 17 Feb 2003 23:31:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 03EFD91226; Mon, 17 Feb 2003 23:34:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3D9E9123B; Mon, 17 Feb 2003 23:34:53 -0500 (EST) 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 B9B5F91226 for ; Mon, 17 Feb 2003 23:34:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9C1FC5DD91; Mon, 17 Feb 2003 23:34:52 -0500 (EST) 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 2F1D65DE23 for ; Mon, 17 Feb 2003 23:34:52 -0500 (EST) 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 XAA27136 for ; Mon, 17 Feb 2003 23:34:51 -0500 (EST) 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 XAA17603 for ; Mon, 17 Feb 2003 23:34:51 -0500 (EST) Received: from [10.0.1.3] (adsl-34-240-45.bct.bellsouth.net [67.34.240.45]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id XAA12557 for ; Mon, 17 Feb 2003 23:34:50 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 17 Feb 2003 23:34:48 -0500 Subject: Re: WG consensus action - 1 week to discuss [LL27] LL-only hosts are out of scope for this specification From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <3E5114EE.2060803@sun.com> 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 02/17/2003 11:59, "Erik Guttman" wrote: > (Use of the Internet Protocol on purely isolated, ad hoc networks would > also be out-of-scope and of little interest to IETF -- except that > some interchange between hosts using link-local addresses and hosts > using routable addresses is unavoidable, and that absent careful > consideration of the effects of such interchange, introduction of > link-local addressing to IPv4 would be expected to adversely affect the > ability of hosts and applications to interoperate over the Internet.) Reject. TCP/IP is a networking protocol. It is not the IETF's place to tell anyone that they have to be able to connect to some arbitrary network level to be able to call it TCP/IP. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Feb 17 23:34:54 2003 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 XAA08786 for ; Mon, 17 Feb 2003 23:34:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 69FBA9123B; Mon, 17 Feb 2003 23:38:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31C0691240; Mon, 17 Feb 2003 23:38:34 -0500 (EST) 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 2B9B19123B for ; Mon, 17 Feb 2003 23:38:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 08B395DE23; Mon, 17 Feb 2003 23:38:33 -0500 (EST) 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 9368B5DD91 for ; Mon, 17 Feb 2003 23:38:32 -0500 (EST) 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 XAA24699 for ; Mon, 17 Feb 2003 23:38:32 -0500 (EST) 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 XAA17985 for ; Mon, 17 Feb 2003 23:38:31 -0500 (EST) Received: from [10.0.1.3] (adsl-34-240-45.bct.bellsouth.net [67.34.240.45]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id XAA13319 for ; Mon, 17 Feb 2003 23:38:31 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 17 Feb 2003 23:38:29 -0500 Subject: Re: [Issue 27]: LL-only hosts From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: 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 02/17/2003 11:47, "Bernard Aboba" wrote: > My recommendation would be to replace the currently proposed text with > something along these lines: > > "Host supporting configuration of LLv4 address MUST also support > configuration of a routable address, whether manually or automatically." No. Again, it is not the IETF's place to decide how a standard is to be *used*. If someone creates a device that is v4LL only, but follows the standard, then it's a compliant device. We have no business telling you that "You must support routable addressing, even though your device will never need, nor use one." john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Feb 18 00:08:14 2003 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 AAA09289 for ; Tue, 18 Feb 2003 00:08:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CA17E91226; Tue, 18 Feb 2003 00:11:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95DD291240; Tue, 18 Feb 2003 00:11:54 -0500 (EST) 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 7B7B891226 for ; Tue, 18 Feb 2003 00:11:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5F1C75E03C; Tue, 18 Feb 2003 00:11:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by segue.merit.edu (Postfix) with ESMTP id 3E9D05DD91 for ; Tue, 18 Feb 2003 00:11:53 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18l02o-0000oz-00; Mon, 17 Feb 2003 21:11:50 -0800 Date: Tue, 18 Feb 2003 00:09:05 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: [Issue 27]: LL-only hosts Message-Id: <20030218000905.7d753c40.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > My recommendation would be to replace the currently proposed text with > > something along these lines: > > > > "Host supporting configuration of LLv4 address MUST also support > > configuration of a routable address, whether manually or automatically." > > No. Again, it is not the IETF's place to decide how a standard is to be > *used*. that's a completely ridiculous and unsupportable statement. worse yet, it's irrelevant. if you take the care to read the proposed text, it says nothing about how LL is used - it says that use of LL for LL-only hosts is not within the scope of the standard. what you seem to want is for IETF to endorse use of LL for purposes that harm interoperability. why in the world IETF should do that is completely incomprehensible. Keith From owner-zeroconf@merit.edu Tue Feb 18 11:46:41 2003 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 LAA01710 for ; Tue, 18 Feb 2003 11:46:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4145691240; Tue, 18 Feb 2003 11:50:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 12EC891242; Tue, 18 Feb 2003 11:50:20 -0500 (EST) 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 0B02A91240 for ; Tue, 18 Feb 2003 11:50:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id E0C995DEC6; Tue, 18 Feb 2003 11:50:19 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by segue.merit.edu (Postfix) with ESMTP id BEB9F5DDBF for ; Tue, 18 Feb 2003 11:50:19 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lAwj-0000es-00; Tue, 18 Feb 2003 08:50:17 -0800 Date: Tue, 18 Feb 2003 11:47:29 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Consensus action: ACCEPT [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses Message-Id: <20030218114729.663c7d8f.moore@cs.utk.edu> In-Reply-To: <3E511498.60306@sun.com> References: <3E511498.60306@sun.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 1. the definition proposed for "directly routed" could stand lots of improvement. the first sentence is meaningless (or at least, the meaning is opaque) and the second sentence tries to define "directly routed" in terms of how not to do it. MUST NOT probably doesn't belong in a definition anyway. suggest: A datagram is directly routed to a destination if the sending host treats the destination address as if the destination host were attached to a local link. For Ethernet-like link-layers this means that an ARP request is sent over an appropriate network interface, a link-layer destination address is obtained from the ARP reply, and the datagram is sent to that link-layer destination. A datagram is not directly routed if it is sent to another address (e.g. that of a router) so that it will be forwarded to the destination host. 2. if you're going to define a term "directly routed" then I suggest that the text that uses the term spell it the same way, rather than "routed directly". Keith On Mon, 17 Feb 2003 17:58:00 +0100 Erik Guttman wrote: > ACTION: Accept > > RESULT: Make the following change in section 2.6 > > 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 MUST 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 the destination > on the same physical link. In many network stacks, achieving this > functionality may be as simple as adding a routing table entry > indicating that 169.254/16 is directly reachable on the local link. > > becomes: > > If the destination address is in the 169.254/16 prefix (including > the 169.254.255.255 broadcast address), then it MUST be routed > directly to the destination address and then send its packet > directly to the destination on the same physical link. In many > network stacks, achieving this functionality may be as simple as > adding a routing table entry indicating that 169.254/16 is > directly reachable on the local link. > > Add to the terminology section: > > directly routed > > A datagram is directly routed to a destination if it is sent > to the destination address. A datagram that is directly > routed MUST NOT be sent to another address so that it will > be forwarded to the destination address. > From owner-zeroconf@merit.edu Tue Feb 18 14:32:45 2003 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 OAA06174 for ; Tue, 18 Feb 2003 14:32:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ABA8991245; Tue, 18 Feb 2003 14:36:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 817CC91248; Tue, 18 Feb 2003 14:36:26 -0500 (EST) 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 8106F91245 for ; Tue, 18 Feb 2003 14:35:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5F4DD5DE81; Tue, 18 Feb 2003 14:35:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from Telstra_Bigpond (mta07bw.bigpond.com [144.135.24.134]) by segue.merit.edu (Postfix) with ESMTP id 063D05DDDF for ; Tue, 18 Feb 2003 14:35:42 -0500 (EST) Received: from pc-00206 ([144.135.24.78]) by mta07bw.email.bigpond.com (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with SMTP id <0HAI00BUVRRFGU@mta07bw.email.bigpond.com> for zeroconf@merit.edu; Wed, 19 Feb 2003 05:35:40 +1000 (EST) Received: from CPE-203-51-28-240.nsw.bigpond.net.au ([203.51.28.240]) by bwmam04.mailsvc.email.bigpond.com(MailRouter V3.0n 35/9866881); Wed, 19 Feb 2003 05:35:39 +0000 Date: Wed, 19 Feb 2003 06:22:03 +1100 From: Brad Hards Subject: Re: [Issue 27]: LL-only hosts In-reply-to: To: Bernard Aboba , zeroconf@merit.edu Message-id: <200302190622.03405.bhards@bigpond.net.au> MIME-version: 1.0 Content-type: Text/Plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline Content-description: clearsigned data User-Agent: KMail/1.4.5 References: Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 18 Feb 2003 03:47, Bernard Aboba wrote: > I propose that this issue be rejected. > > It does seem reasonable to require that a host be able to configure a > routable address, but I can also see devices being shipped that do not > configure such an address by default. > > My recommendation would be to replace the currently proposed text with > something along these lines: > > "Host supporting configuration of LLv4 address MUST also support > configuration of a routable address, whether manually or automatically." I reject this, and anything else that requires a routable address to be implemented. There are a range of applications where a routable address is of absolutely no value. I came to zeroconf looking for a solution for USB host-to-host cables. In Linux, those devices are presented by the OS as equivalent to ethernet devices. Several PDAs also use this. I don't want a proprietary solution. I want to establish compatible IP addresses on each end, and run ftp/rsync/distcc/whatever over that connection, point-to-point. DHCP isn't going to be running, so there is no point in testing for it, and implementing DHCP clients in a PDA for spec compliant is stupidity. I could agree if the requirement was changed to SHOULD. Brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+UofbW6pHgIdAuOMRAvUsAKC8IYoHQ1Jn7k6K87EBBg5R6HNIlACfdpE6 SbYbxIRTurCq6C4yNIsk/qA= =aHHb -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Tue Feb 18 14:39:57 2003 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 OAA06326 for ; Tue, 18 Feb 2003 14:39:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1987791248; Tue, 18 Feb 2003 14:43:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D535091249; Tue, 18 Feb 2003 14:43:38 -0500 (EST) 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 C932F91248 for ; Tue, 18 Feb 2003 14:43:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC8C85E067; Tue, 18 Feb 2003 14:43:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by segue.merit.edu (Postfix) with ESMTP id 8B5965E04E for ; Tue, 18 Feb 2003 14:43:37 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lDeD-0004dq-00; Tue, 18 Feb 2003 11:43:22 -0800 Date: Tue, 18 Feb 2003 14:40:34 -0500 From: Keith Moore To: Brad Hards Cc: moore@cs.utk.edu, aboba@internaut.com, zeroconf@merit.edu Subject: Re: [Issue 27]: LL-only hosts Message-Id: <20030218144034.71c2e078.moore@cs.utk.edu> In-Reply-To: <200302190622.03405.bhards@bigpond.net.au> References: <200302190622.03405.bhards@bigpond.net.au> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > There are a range of applications where a routable address is of absolutely no > value. I came to zeroconf looking for a solution for USB host-to-host cables. please explain what that has to do with the Internet, why it's relevant to the purpose of IETF or this WG, and why IETF should standardize a practice that will harm Internet interoperability. From owner-zeroconf@merit.edu Tue Feb 18 15:01:03 2003 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 PAA06831 for ; Tue, 18 Feb 2003 15:00:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2414091249; Tue, 18 Feb 2003 15:04:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E7E809124A; Tue, 18 Feb 2003 15:04:39 -0500 (EST) 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 EC1B991249 for ; Tue, 18 Feb 2003 15:04:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id C56BD5DDDF; Tue, 18 Feb 2003 15:04:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta05bw.bigpond.com (mta05bw.bigpond.com [139.134.6.95]) by segue.merit.edu (Postfix) with ESMTP id 5DE145DD91 for ; Tue, 18 Feb 2003 15:04:37 -0500 (EST) Received: from pc-00206 ([144.135.24.69]) by mta05bw.bigpond.com (Netscape Messaging Server 4.15 mta05bw Jul 16 2002 22:47:55) with SMTP id HAIT3M00.AL5; Wed, 19 Feb 2003 06:04:34 +1000 Received: from CPE-203-51-28-240.nsw.bigpond.net.au ([203.51.28.240]) by bwmam01.mailsvc.email.bigpond.com(MailRouter V3.0n 8/8841386); 19 Feb 2003 06:04:33 From: Brad Hards To: Keith Moore Subject: Re: [Issue 27]: LL-only hosts Date: Wed, 19 Feb 2003 06:50:47 +1100 User-Agent: KMail/1.4.5 Cc: moore@cs.utk.edu, aboba@internaut.com, zeroconf@merit.edu References: <200302190622.03405.bhards@bigpond.net.au> <20030218144034.71c2e078.moore@cs.utk.edu> In-Reply-To: <20030218144034.71c2e078.moore@cs.utk.edu> 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: <200302190650.47575.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 19 Feb 2003 06:40, Keith Moore wrote: > > There are a range of applications where a routable address is of > > absolutely no value. I came to zeroconf looking for a solution for USB > > host-to-host cables. > > please explain what that has to do with the Internet, why it's relevant to > the purpose of IETF or this WG, and why IETF should standardize a practice > that will harm Internet interoperability. Keith - please keep calm, and don't make emotive and unjustified statements in the form of questions. Either this WG has scope to discuss a protocol enhancement that only works on the local link (that is, using protocols already developed by the IETF), or it doesn't. If it doesn't, could all those who are only here for IETF reasons please move on, and let the rest of us get on with making it work. If it does, then what difference does it make whether the underlying transport is USB or ethernet? Brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+Uo6XW6pHgIdAuOMRAjRlAJ46f+EIBgSJ7pVv5Fwi1EjRrKYzJACeOmN9 oUPkGsiG5QjuoZATDbZggU4= =cLof -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Tue Feb 18 15:12:39 2003 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 PAA07101 for ; Tue, 18 Feb 2003 15:12:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B734C9124A; Tue, 18 Feb 2003 15:15:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7AC5D9124B; Tue, 18 Feb 2003 15:15:22 -0500 (EST) 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 524239124A for ; Tue, 18 Feb 2003 15:15:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 776F85DF8B; Tue, 18 Feb 2003 15:15:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by segue.merit.edu (Postfix) with ESMTP id E820A5DF81 for ; Tue, 18 Feb 2003 15:15:19 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lE8x-00068g-00; Tue, 18 Feb 2003 12:15:07 -0800 Date: Tue, 18 Feb 2003 15:12:19 -0500 From: Keith Moore To: Brad Hards Cc: moore@cs.utk.edu, aboba@internaut.com, zeroconf@merit.edu Subject: Re: [Issue 27]: LL-only hosts Message-Id: <20030218151219.6bb3b1e0.moore@cs.utk.edu> In-Reply-To: <200302190650.47575.bhards@bigpond.net.au> References: <200302190622.03405.bhards@bigpond.net.au> <20030218144034.71c2e078.moore@cs.utk.edu> <200302190650.47575.bhards@bigpond.net.au> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Wed, 19 Feb 2003 06:40, Keith Moore wrote: > > > There are a range of applications where a routable address is of > > > absolutely no value. I came to zeroconf looking for a solution for USB > > > host-to-host cables. > > > > please explain what that has to do with the Internet, why it's relevant to > > the purpose of IETF or this WG, and why IETF should standardize a practice > > that will harm Internet interoperability. > > Keith - please keep calm, and don't make emotive and unjustified statements > in the form of questions. FWIW, I'm very calm. These are genuine questions. To standardize LL-only devices we need a convincing argument that these are in scope for this WG, and by extension, IETF. For this WG to exceed its scope would be a process error. For this WG to produce devices which cannot interoperate with the Internet would be a technical error. > Either this WG has scope to discuss a protocol enhancement that only works > on the local link (that is, using protocols already developed by the IETF), > or it doesn't. If it doesn't, could all those who are only here for IETF > reasons please move on, and let the rest of us get on with making it work. if LL-only devices aren't in scope (and I'd claim that they're not), then the people who want LL-only devices are the ones who need to move on. Keith From owner-zeroconf@merit.edu Tue Feb 18 15:47:08 2003 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 PAA08084 for ; Tue, 18 Feb 2003 15:47:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6CAC29122A; Tue, 18 Feb 2003 15:50:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 346AB9124C; Tue, 18 Feb 2003 15:50:50 -0500 (EST) 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 2E9789122A for ; Tue, 18 Feb 2003 15:50:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 11FB15E067; Tue, 18 Feb 2003 15:50:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 15A535DD91 for ; Tue, 18 Feb 2003 15:50:48 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1IKpRaj000668 for ; Tue, 18 Feb 2003 22:51:27 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1IKpPfb000667 for zeroconf@merit.edu; Tue, 18 Feb 2003 22:51:25 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: LL27 - reject From: Mika Liljeberg To: zeroconf@merit.edu Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045601484.17022.93.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 18 Feb 2003 22:51:25 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit LL-only nodes plainly are within the charter and there are plenty of use cases. MikaL From owner-zeroconf@merit.edu Tue Feb 18 19:27:40 2003 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 TAA12587 for ; Tue, 18 Feb 2003 19:27:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B6A5A91249; Tue, 18 Feb 2003 19:30:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A1FC9124A; Tue, 18 Feb 2003 19:30:44 -0500 (EST) 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 8D3FA91249 for ; Tue, 18 Feb 2003 19:30:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9702A5DF81; Tue, 18 Feb 2003 19:30:37 -0500 (EST) 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 009305DE41 for ; Tue, 18 Feb 2003 19:30:36 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.3/8.12.3) with ESMTP id h1J0UaTb012203 for ; Tue, 18 Feb 2003 16:30:36 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 18 Feb 2003 16:30:36 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h1J0Uaf06713 for ; Tue, 18 Feb 2003 16:30:36 -0800 (PST) Message-Id: <200302190030.h1J0Uaf06713@scv3.apple.com> Subject: Re: ACCEPT [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses Date: Tue, 18 Feb 2003 16:30:37 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Erik Guttman announced the following text: If the destination address is in the 169.254/16 prefix (...), then it MUST be routed directly to the destination address and then send its packet directly to the destination on the same physical link. I don't think that sentence makes any sense. I previously proposed the following text: If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), then the host MUST use ARP [RFC 826] in the usual way to map the destination IP address to a destination hardware address, and then send its packet directly to the destination on the same physical link. In many network stacks, achieving this functionality may be as simple as adding a routing table entry indicating that 169.254/16 is directly reachable on the local link. The host MUST NOT send a packet with a link-local destination address to any router for forwarding. Were there any objections to this wording? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Feb 18 19:28:08 2003 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 TAA12603 for ; Tue, 18 Feb 2003 19:28:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E614E9122D; Tue, 18 Feb 2003 19:31:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB6EE9124A; Tue, 18 Feb 2003 19:31:46 -0500 (EST) 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 97B859122D for ; Tue, 18 Feb 2003 19:31:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 33D025DF9D; Tue, 18 Feb 2003 19:30:59 -0500 (EST) 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 DE4F35DF81 for ; Tue, 18 Feb 2003 19:30:58 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.3/8.12.3) with ESMTP id h1J0UwTb012347 for ; Tue, 18 Feb 2003 16:30:58 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 18 Feb 2003 16:30:57 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h1J0UpQ15777 for ; Tue, 18 Feb 2003 16:30:56 -0800 (PST) Message-Id: <200302190030.h1J0UpQ15777@scv2.apple.com> Subject: Re: ACCEPT [LL17] "directly routed"? Date: Tue, 18 Feb 2003 16:30:53 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Erik Guttman proposed the following terminology definition: directly routed A datagram is directly routed to a destination if it is sent to the destination address. A datagram that is directly routed MUST NOT be sent to another address so that it will be forwarded to the destination address. I think the first sentence says nothing. I also think that the term "directly routed" is self-contradictory. The concept of "routing" means "going through routers". The concept of sending a packet "directly" to its destination means "NOT going through routers". Perhaps the term should be "directly delivered" or "delivered directly". We should reserve the term "routed" for its commonly understood meaning, namely, "pertaining to routers". Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Feb 18 20:00:03 2003 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 UAA13346 for ; Tue, 18 Feb 2003 20:00:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 44FED9122A; Tue, 18 Feb 2003 20:03:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16EBC9124D; Tue, 18 Feb 2003 20:03:35 -0500 (EST) 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 DEDFD9122A for ; Tue, 18 Feb 2003 20:02:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id BCBB55DF96; Tue, 18 Feb 2003 20:02:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 3C5C35DF88 for ; Tue, 18 Feb 2003 20:02:50 -0500 (EST) Received: from nominum.com (a7.tc43.theriver.com [206.26.123.199]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1J10Tb21381; Tue, 18 Feb 2003 19:00:30 -0600 (CST) Date: Tue, 18 Feb 2003 18:02:49 -0700 Subject: Re: ACCEPT [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: Stuart Cheshire From: Ted Lemon In-Reply-To: <200302190030.h1J0Uaf06713@scv3.apple.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > If the destination address is in the 169.254/16 prefix (including > the 169.254.255.255 broadcast address), > then the host MUST use ARP [RFC 826] in the usual way to map the > destination IP address to a destination hardware address, > and then send its packet directly to the destination on the same > physical link. In many network stacks, achieving this > functionality may be as simple as adding a routing table entry > indicating that 169.254/16 is directly reachable on the local > link. The host MUST NOT send a packet with a link-local > destination address to any router for forwarding. This text is fine with me. From owner-zeroconf@merit.edu Wed Feb 19 01:44:57 2003 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 BAA20309 for ; Wed, 19 Feb 2003 01:44:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E40059120D; Wed, 19 Feb 2003 01:48:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 857AD91212; Wed, 19 Feb 2003 01:48:29 -0500 (EST) 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 4F2DC9120D for ; Wed, 19 Feb 2003 01:47:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3261F5E0FA; Wed, 19 Feb 2003 01:47:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta04bw.bigpond.com (mta04bw.bigpond.com [139.134.6.87]) by segue.merit.edu (Postfix) with ESMTP id BAB795DE0F for ; Wed, 19 Feb 2003 01:47:52 -0500 (EST) Received: from pc-00206 ([144.135.24.75]) by mta04bw.bigpond.com (Netscape Messaging Server 4.15 mta04bw Jul 16 2002 22:47:55) with SMTP id HAJMVM00.GNR; Wed, 19 Feb 2003 16:47:46 +1000 Received: from CPE-203-51-28-240.nsw.bigpond.net.au ([203.51.28.240]) by bwmam03.mailsvc.email.bigpond.com(MailRouter V3.0n 26/10670665); 19 Feb 2003 16:47:46 From: Brad Hards To: Keith Moore Subject: Re: [Issue 27]: LL-only hosts Date: Wed, 19 Feb 2003 17:33:40 +1100 User-Agent: KMail/1.4.5 Cc: aboba@internaut.com, zeroconf@merit.edu References: <200302190650.47575.bhards@bigpond.net.au> <20030218151219.6bb3b1e0.moore@cs.utk.edu> In-Reply-To: <20030218151219.6bb3b1e0.moore@cs.utk.edu> 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: <200302191733.40896.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 19 Feb 2003 07:12, Keith Moore wrote: > FWIW, I'm very calm. These are genuine questions. To standardize LL-only > devices we need a convincing argument that these are in scope for this WG, > and by extension, IETF. For this WG to exceed its scope would be a process > error. For this WG to produce devices which cannot interoperate with the > Internet would be a technical error. If there is a mandatory requirement for zeroconf allocation of Internet routable addresses, then clearly we cannot achieve that with IPv4, and we should probably just give up and wait 10-20 years for IPv6. However I don't see that as a requirement. If the requirement is really to achieve networking on a single network segment (ie where all hosts are reachable by link-layer broadcast/multicast), then there is no apparent requirement for anything except Link Local address assignment - DHCP is not needed. BTW: In the absence of unambiguous statements on IETF scope as it relates to link local networking (which there may be, but I am not aware of), then precedence is a use guide. I'll cite ARP as an example of previous work that is clearly link-local. Brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+UyVEW6pHgIdAuOMRAj/YAJ9eLnmeAOf1rA48tKBj1A5ZO7NWiwCffxvW wY7UV7Dpi18SY1zd5mx7M50= =3ou8 -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Wed Feb 19 01:55:07 2003 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 BAA20418 for ; Wed, 19 Feb 2003 01:55:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4272791228; Wed, 19 Feb 2003 01:57:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DF7991222; Wed, 19 Feb 2003 01:57:03 -0500 (EST) 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 69D8F91212 for ; Wed, 19 Feb 2003 01:56:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 595E25E0F4; Wed, 19 Feb 2003 01:56:59 -0500 (EST) 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 3F18C5DE0F for ; Wed, 19 Feb 2003 01:56:59 -0500 (EST) Received: from repligate ([67.36.179.41]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20030219065659.DGXD3860.mailhost.chi1.ameritech.net@repligate> for ; Wed, 19 Feb 2003 00:56:59 -0600 Message-ID: <0c3301c2d7e4$21081b90$8500a8c0@repligate> From: "Jim Fleming" To: References: <200302190650.47575.bhards@bigpond.net.au> <20030218151219.6bb3b1e0.moore@cs.utk.edu> <200302191733.40896.bhards@bigpond.net.au> Subject: Re: [Issue 27]: LL-only hosts Date: Wed, 19 Feb 2003 00:57:11 -0600 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: "Brad Hards" > On Wed, 19 Feb 2003 07:12, Keith Moore wrote: > > FWIW, I'm very calm. These are genuine questions. To standardize LL-only > > devices we need a convincing argument that these are in scope for this WG, > > and by extension, IETF. For this WG to exceed its scope would be a process > > error. For this WG to produce devices which cannot interoperate with the > > Internet would be a technical error. > If there is a mandatory requirement for zeroconf allocation of Internet > routable addresses, then clearly we cannot achieve that with IPv4, and we > should probably just give up and wait 10-20 years for IPv6. ========================================================= It appears that the "LL" that you are interested in standardizing, could be classified as part of the FM InterNAT, as opposed to the aging legacy AM (low quality) Internet. You might want to consider setting the FM bit in the 160 bit header as part of your "LL" standard. Are you on the AM Internet or the FM Internet ? 128-bit DNS AAAA Record Flag Day Formats 2003:[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 ("AM/FM") 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 http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt IPv8 0QQQQGGGSSSSSSSS[32-bits][Port] IPv16 0QQQQGGGSSSSSSSS[32-bits][Port] 1AAAAAAAAAAAAAAA[32-bits][Port] A...A=ASN=32769...65535 Jim Fleming http://IPv8.isfun.net From owner-zeroconf@merit.edu Wed Feb 19 02:08:44 2003 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 CAA00848 for ; Wed, 19 Feb 2003 02:08:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2649F91212; Wed, 19 Feb 2003 02:12:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC4B291216; Wed, 19 Feb 2003 02:12:24 -0500 (EST) 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 CFE0291212 for ; Wed, 19 Feb 2003 02:12:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id AF8D55E049; Wed, 19 Feb 2003 02:12:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id F1FE25DE0F for ; Wed, 19 Feb 2003 02:12:22 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1J7Ctaj004987; Wed, 19 Feb 2003 09:12:56 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1J7Cr2C004986; Wed, 19 Feb 2003 09:12:53 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: ACCEPT [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses From: Mika Liljeberg To: Stuart Cheshire Cc: zeroconf@merit.edu In-Reply-To: <200302190030.h1J0Uaf06713@scv3.apple.com> References: <200302190030.h1J0Uaf06713@scv3.apple.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045638772.17022.108.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Feb 2003 09:12:53 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-19 at 02:30, Stuart Cheshire wrote: > Erik Guttman announced the following text: > > If the destination address is in the 169.254/16 prefix (...), > then it MUST be routed > directly to the destination address and then send its packet > directly to the destination on the same physical link. > > I don't think that sentence makes any sense. I agree. I would prefer that the text be written in terms of the on-link/off-link terminology defined in RFC2460. Defining new vague terminology just confuses people. > I previously proposed the following text: > > If the destination address is in the 169.254/16 prefix (including > the 169.254.255.255 broadcast address), > then the host MUST use ARP [RFC 826] in the usual way to map the > destination IP address to a destination hardware address, > and then send its packet directly to the destination on the same > physical link. In many network stacks, achieving this > functionality may be as simple as adding a routing table entry > indicating that 169.254/16 is directly reachable on the local > link. The host MUST NOT send a packet with a link-local > destination address to any router for forwarding. > > Were there any objections to this wording? Yes, two separate objections from different people: a) the sender cannot know whether another node is a router or not b) ARP should not be mentioned here, since this text deals purely with route selection. These rules should be applicable to all uses of v4LL addresses, not just Ethernet type networks. I proposed the following text, which uses the off-link/on-link terminology: "A compliant node MUST use the 169.254/16 prefix, in addition to any other on-link prefixes it may have, when determining whether a particular destination is on-link. A compliant node MUST NOT send a packet having a source address in the 169.254/16 range to an off-link destination. A received packet with a source address in the 169.254/16 range and a destination address that is not one of the receiving node's own IP addresses MUST be discarded." The first two sentences deal with route selection. The last sentence deals with received packet validation, and automatically also bans any possibility of forwarding the packet. MikaL From owner-zeroconf@merit.edu Wed Feb 19 06:14:58 2003 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 GAA18703 for ; Wed, 19 Feb 2003 06:14:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C4DA291209; Wed, 19 Feb 2003 06:18:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 888809121A; Wed, 19 Feb 2003 06:18:37 -0500 (EST) 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 4FA8D91209 for ; Wed, 19 Feb 2003 06:18:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 253215E109; Wed, 19 Feb 2003 06:18:36 -0500 (EST) 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 C40E75E106 for ; Wed, 19 Feb 2003 06:18:35 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id E342F599A7 for ; Wed, 19 Feb 2003 11:18:31 +0000 (GMT) Message-ID: <028001c2d808$a78897c0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <200302190622.03405.bhards@bigpond.net.au><20030218144034.71c2e078.moore@cs.utk.edu><200302190650.47575.bhards@bigpond.net.au> <20030218151219.6bb3b1e0.moore@cs.utk.edu> Subject: Re: [Issue 27]: LL-only hosts Date: Wed, 19 Feb 2003 11:18:39 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Saying that a standard which extends TCP/IP is immediately out of scope for IETF wherever it does not connect to *The Internet* seems a very narrow reading of the IETF's scope and begs a lot of questions about what would happen should another standards body emerge specifically to develop IP extensions. Suppose someone were to take IPv4LL to another standards body because they perceive a need to to get a standard for LL only devices, there then gets to be a problem of tracking and synchronisation of standards and all sorts of thorny issues. On the other hand Keith is right when he has continually beaten us around the heads with the fact that as soon as a LL-only device gets connected to a larger routed network, it (and more significantly other devices) starts to misfunction and reminds us that this is an *interoperability* standard as opposed to some other kind. I would say that what is really needed is to split this into one specification which simply defines how LL claim-defend works and a second which dictates the conditions, warnings, prerequisits etc for using it in generic devices which might be connected into routed networks. While, I don't really see that there is the appetite or even possibility to make this major change, the emphasis in the current doc could be along those lines. I would like to see a phrasing which only allows LL-only devices where it is known that the device, by virtue of its design, cannot or is highly unlikely to be connected to a routed network. It should be possible to specify a phrase such devices must use if claiming compliance such as "Isolated link only". Philip ----- Original Message ----- From: "Keith Moore" To: "Brad Hards" Cc: ; ; Sent: Tuesday, February 18, 2003 8:12 PM Subject: Re: [Issue 27]: LL-only hosts > > On Wed, 19 Feb 2003 06:40, Keith Moore wrote: > > > > There are a range of applications where a routable address is of > > > > absolutely no value. I came to zeroconf looking for a solution for USB > > > > host-to-host cables. > > > > > > please explain what that has to do with the Internet, why it's relevant to > > > the purpose of IETF or this WG, and why IETF should standardize a practice > > > that will harm Internet interoperability. > > > > Keith - please keep calm, and don't make emotive and unjustified statements > > in the form of questions. > > FWIW, I'm very calm. These are genuine questions. To standardize LL-only > devices we need a convincing argument that these are in scope for this WG, and > by extension, IETF. For this WG to exceed its scope would be a process error. > For this WG to produce devices which cannot interoperate with the Internet > would be a technical error. > > > Either this WG has scope to discuss a protocol enhancement that only works > > on the local link (that is, using protocols already developed by the IETF), > > or it doesn't. If it doesn't, could all those who are only here for IETF > > reasons please move on, and let the rest of us get on with making it work. > > if LL-only devices aren't in scope (and I'd claim that they're not), then the > people who want LL-only devices are the ones who need to move on. > > Keith > From owner-zeroconf@merit.edu Wed Feb 19 06:39:59 2003 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 GAA19284 for ; Wed, 19 Feb 2003 06:39:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2BB7F9121A; Wed, 19 Feb 2003 06:43:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED9E69121E; Wed, 19 Feb 2003 06:43:39 -0500 (EST) 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 E791C9121A for ; Wed, 19 Feb 2003 06:43:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id CF6615E103; Wed, 19 Feb 2003 06:43:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by segue.merit.edu (Postfix) with ESMTP id 03CC15DFAE for ; Wed, 19 Feb 2003 06:43:38 -0500 (EST) Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) with ESMTP id h1JBhRiC007340 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 19 Feb 2003 13:43:28 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) id h1JBhRX3007336; Wed, 19 Feb 2003 13:43:27 +0200 Date: Wed, 19 Feb 2003 13:43:27 +0200 Message-Id: <200302191143.h1JBhRX3007336@burp.tkv.asdf.org> From: Markku Savela To: philip@engarts.com Cc: zeroconf@merit.edu In-reply-to: <028001c2d808$a78897c0$131010ac@aldebaran> (philip@engarts.com) Subject: Re: [Issue 27]: LL-only hosts References: <200302190622.03405.bhards@bigpond.net.au><20030218144034.71c2e078.moore@cs.utk.edu><200302190650.47575.bhards@bigpond.net.au> <20030218151219.6bb3b1e0.moore@cs.utk.edu> <028001c2d808$a78897c0$131010ac@aldebaran> Sender: owner-zeroconf@merit.edu Precedence: bulk > From: "Philip Nye" > I would like to see a phrasing which only allows LL-only devices where it is > known that the device, by virtue of its design, cannot or is highly unlikely > to be connected to a routed network. It should be possible to specify a > phrase such devices must use if claiming compliance such as "Isolated link > only". I strongly disagree on this. I want to be able to run LL-only node in parallel to the connected node. And that, these "nodes" could be located virtually at same machine sharing the network interface. That is, for other hosts it looks like there are two hosts on the link: one LL4 only host and another host, with global address. It is no concern of IETF how I manage this situation internally within the node. From owner-zeroconf@merit.edu Wed Feb 19 06:49:37 2003 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 GAA19584 for ; Wed, 19 Feb 2003 06:49:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4B57C9121E; Wed, 19 Feb 2003 06:53:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F3C791222; Wed, 19 Feb 2003 06:53:17 -0500 (EST) 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 2B6BE9121E for ; Wed, 19 Feb 2003 06:53:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 12D7D5E103; Wed, 19 Feb 2003 06:53:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by segue.merit.edu (Postfix) with ESMTP id 3F16F5DFAE for ; Wed, 19 Feb 2003 06:53:15 -0500 (EST) Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) with ESMTP id h1JBrAiC007403 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 19 Feb 2003 13:53:10 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) id h1JBrASa007399; Wed, 19 Feb 2003 13:53:10 +0200 Date: Wed, 19 Feb 2003 13:53:10 +0200 Message-Id: <200302191153.h1JBrASa007399@burp.tkv.asdf.org> From: Markku Savela To: zeroconf@merit.edu In-reply-to: <200302191143.h1JBhRX3007336@burp.tkv.asdf.org> (message from Markku Savela on Wed, 19 Feb 2003 13:43:27 +0200) Subject: Re: [Issue 27]: LL-only hosts References: <200302190622.03405.bhards@bigpond.net.au><20030218144034.71c2e078.moore@cs.utk.edu><200302190650.47575.bhards@bigpond.net.au> <20030218151219.6bb3b1e0.moore@cs.utk.edu> <028001c2d808$a78897c0$131010ac@aldebaran> <200302191143.h1JBhRX3007336@burp.tkv.asdf.org> Sender: owner-zeroconf@merit.edu Precedence: bulk And replying to myself... > That is, for other hosts it looks like there are two hosts on the > link: one LL4 only host and another host, with global address. It is > no concern of IETF how I manage this situation internally within the > node. The logical conclusion of above is, that if LL4 only nodes are out of scope for this WG, the result of this WG is also irrelevant for me, as I ONLY have LL-only node and globally connected node. From owner-zeroconf@merit.edu Wed Feb 19 07:05:01 2003 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 HAA20185 for ; Wed, 19 Feb 2003 07:05:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6DC4A91222; Wed, 19 Feb 2003 07:08:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 357A791225; Wed, 19 Feb 2003 07:08:41 -0500 (EST) 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 45B6D91222 for ; Wed, 19 Feb 2003 07:08:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2438C5E10A; Wed, 19 Feb 2003 07:08:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 822475DFB8 for ; Wed, 19 Feb 2003 07:08:38 -0500 (EST) Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1JC8Hd17505; Wed, 19 Feb 2003 19:08:18 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1JC3DK06088; Wed, 19 Feb 2003 19:03:14 +0700 (ICT) From: Robert Elz To: Bernard Aboba Cc: zeroconf@merit.edu Subject: Re: [Issue 23]: Don't configure needless LLv4 addresses In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Feb 2003 19:03:13 +0700 Message-ID: <6086.1045656193@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 17 Feb 2003 08:28:05 -0800 (PST) From: Bernard Aboba Message-ID: | I am in favor of this change, although I think that if it is accepted, we | don't also need the change proposed in Issue #1. LL23 was intended as an alternative to LL1. This was submitted during the period (which may still exist, though mostly seems to be being ignored) when the requested way to suggest an alternative resolution for an issue was to submit a new issue. | "For this reason, a host that obtains, or is configured with, a routable | address on an interface, SHOULD NOT attempt to configure a | link-local address on the same interface." | | I am not entirely sure what configure means here. Run the LL assignment algorithm (actually assign an LL address to an interface). By all means suggest wording improvements. | Does it mean the same thing as SHOULD NOT use? No, except that if an address isn't configured, it would be rather difficult to use it... | How is it different? "use" is ambiguous, it could refer to assigning an address to an interface, or sending (or receiving) packets with an address in it. "Configure" is intended to refer to only the first. | What specific things does this imply aren't done? | Are they all covered in the next paragraph? Largely, I hope so. | This makes sense, I think. I assume that "advertising" doesn't include | ARP replies. no, that's a reply - an advertisment is something unsolicited (some way of causing others to issue an ARP request, that is of allowing them to discover what IP address to use in the first place). Or that is what was intended. The idea is that the system attempt to cause people to use the routable address, instead of the LL, wherever possible - but I don't think we need to much specific language as to how that can or should be done, it depends upon too many other issues that aren't otherwise relevant here (this draft doesn't, itself, give anyone a clue as to how they'd discover someone else's LL address - nor does it need to). kre From owner-zeroconf@merit.edu Wed Feb 19 07:11:02 2003 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 HAA20477 for ; Wed, 19 Feb 2003 07:11:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BFA2F91225; Wed, 19 Feb 2003 07:14:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D7C19122A; Wed, 19 Feb 2003 07:14:43 -0500 (EST) 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 9592291225 for ; Wed, 19 Feb 2003 07:14:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 759FA5E10E; Wed, 19 Feb 2003 07:14:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id E781C5E10D for ; Wed, 19 Feb 2003 07:14:40 -0500 (EST) Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1JCERd21103; Wed, 19 Feb 2003 19:14:29 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1JC9HK06102; Wed, 19 Feb 2003 19:09:18 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: Bernard Aboba , zeroconf@merit.edu Subject: Re: [Issue 23]: Don't configure needless LLv4 addresses In-Reply-To: <1045507773.17019.62.camel@devil> References: <1045507773.17019.62.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Feb 2003 19:09:17 +0700 Message-ID: <6100.1045656557@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 17 Feb 2003 20:49:33 +0200 From: Mika Liljeberg Message-ID: <1045507773.17019.62.camel@devil> | The text also fails to deal with the issue what to do if the routable | address is unconfigured (e.g. by a frustrated DHCP client). By all means, suggest wording to fix that. That's a reasonable point. I'd expect that if the host has a LL address from earlier, it would go back to using it as it would if the routable address had never existed, and if it doesn't, it would go and acquire one. That is, assuming that LL2 hasn't told it not to configure a LL address of course. | What exactly does advertising include? What is the implication to an | implementor? Unless these questions can be answered, the sentence should | be deleted. I'd prefer to keep the sentence, and not answer the questions. Answering the questions means embedding more knowledge in this draft that isn't needed, about the methods by which link local addresses of other nodes are determined. It would be reasonable to add (in the definitions of terms section) something along the lines of advertising any process by which a node makes known to others its randomly selected link local address. (note that this does not include information made known by third parties, but does include the node notifying the third party in the first place). kre From owner-zeroconf@merit.edu Wed Feb 19 07:26:10 2003 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 HAA21583 for ; Wed, 19 Feb 2003 07:26:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 262C291228; Wed, 19 Feb 2003 07:29:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E81E59122A; Wed, 19 Feb 2003 07:29:49 -0500 (EST) 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 EA6F391228 for ; Wed, 19 Feb 2003 07:29:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id D369E5E10D; Wed, 19 Feb 2003 07:29:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 5A5A35DFB8 for ; Wed, 19 Feb 2003 07:29:47 -0500 (EST) Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1JCTbd26120; Wed, 19 Feb 2003 19:29:38 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1JCOFK06126; Wed, 19 Feb 2003 19:24:20 +0700 (ICT) From: Robert Elz To: Brad Hards Cc: Bernard Aboba , zeroconf@merit.edu Subject: Re: [Issue 27]: LL-only hosts In-Reply-To: <200302190622.03405.bhards@bigpond.net.au> References: <200302190622.03405.bhards@bigpond.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Feb 2003 19:24:15 +0700 Message-ID: <6124.1045657455@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 19 Feb 2003 06:22:03 +1100 From: Brad Hards Message-ID: <200302190622.03405.bhards@bigpond.net.au> I support LL27 - the newer wording for it that has been proposed is better than the original... (there's less of it...) | There are a range of applications where a routable address is of | absolutely no value. There are way too many people who believe that makes a difference. This is irrelevant - if some manufacturer can guarantee that some device can never possibly need a routable address, then the device is clearly not going to be connected to the internet, and so claiming conformance with an Internet standard would be irrelevant and useless. This doesn't mean that the manufacturer can't implement, and use, LL addresses, exactly as defined in the spec, without implementing any more. Such a manufacturer might also choose to do lots of other things that the internet standards don't allow, like not bothering to check TCP checksums (because they know the link level checksum, which is most likely a much better algorithm, will have found any errors), and ignoring anything in IP options (because none will ever be relevant) and not implementing ICMP at all (because nothing in their system ever needs it). None of that is ever permitted in an IETF standard however. But ... | I came to zeroconf looking for a solution for USB host-to-host cables. | In Linux, those devices are presented by the OS as equivalent to ethernet | devices. Several PDAs also use this. These kinds of devices are ones where routable addresses most certainly are needed. What's more it is almost inconceivable to imagine the manufacturer of such a device that would limit their potential market by not allowing any way where routable addresses could be assigned. | I don't want a proprietary solution. I want to establish compatible IP | addresses on each end, and run ftp/rsync/distcc/whatever over that | connection, point-to-point. DHCP isn't going to be running, How can you possibly know? It might not be running in your particular case, and there's nothing stopping you disabling DHCP if the extra couple of seconds delay is really going to bother you. Other users will want to use the device to its full potential, and that includes accessing random web pages over that USB host to host "pretend to be an ethernet" device via the router at the other end of the cable, etc. kre From owner-zeroconf@merit.edu Wed Feb 19 07:28:11 2003 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 HAA21687 for ; Wed, 19 Feb 2003 07:28:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4CDA19122A; Wed, 19 Feb 2003 07:31:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E35DE9122D; Wed, 19 Feb 2003 07:31:44 -0500 (EST) 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 3192F9122A for ; Wed, 19 Feb 2003 07:31:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id C97215E116; Wed, 19 Feb 2003 07:31:06 -0500 (EST) 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 9399B5E115 for ; Wed, 19 Feb 2003 07:31:06 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 7BB42599AF for ; Wed, 19 Feb 2003 12:31:08 +0000 (GMT) Message-ID: <02c901c2d812$cfd9e5d0$131010ac@aldebaran> From: "Philip Nye" To: References: Subject: Re: LL1, LL23 Date: Wed, 19 Feb 2003 12:31:22 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I support the principle of both these - that a node should not try and obtain or use a LL address when a routable address is available. However, I note that both these only reference section 1.5 while there are other places that this principle needs to be mentioned - including section 2.6 "Source Address Selection" (see LL26). Comparing the two: LL23 better describes the issue of transition from zero-config to configured networks but the same behaviour is not precluded by LL1; LL23 says "don't configure" a LL address while LL1 just says "don't use" it. Neither option directly tackles the more difficult issue of transition from configured to zero-config but LL23 might conflict with sensible attempts to solve this issue (what if you have a routable address but it no longer seems to work) so I currently favour LL1. Philip From owner-zeroconf@merit.edu Wed Feb 19 07:32:31 2003 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 HAA21962 for ; Wed, 19 Feb 2003 07:32:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B4AB69122D; Wed, 19 Feb 2003 07:36:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 807A391249; Wed, 19 Feb 2003 07:36:11 -0500 (EST) 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 888EE9122D for ; Wed, 19 Feb 2003 07:36:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 69A1D5E105; Wed, 19 Feb 2003 07:36:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id E117E5E103 for ; Wed, 19 Feb 2003 07:36:08 -0500 (EST) Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1JCZgd27100; Wed, 19 Feb 2003 19:35:44 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1JCUHK06145; Wed, 19 Feb 2003 19:30:18 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: ACCEPT [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses In-Reply-To: <200302190030.h1J0Uaf06713@scv3.apple.com> References: <200302190030.h1J0Uaf06713@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Feb 2003 19:30:17 +0700 Message-ID: <6143.1045657817@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 18 Feb 2003 16:30:37 -0800 From: Stuart Cheshire Message-ID: <200302190030.h1J0Uaf06713@scv3.apple.com> | Erik Guttman announced the following text: | | If the destination address is in the 169.254/16 prefix (...), | then it MUST be routed | directly to the destination address and then send its packet | directly to the destination on the same physical link. | | I don't think that sentence makes any sense. yes, there's some odd wording there. | I previously proposed the following text: | Were there any objections to this wording? Yes, you cannot require ARP, because not all link levels use it. The wording needs to be in such a way that specific link level technologies are not implied. And the "send to any router" keeps on making people ask "how do I know if it is a router?" or "does this mean I can send it to a host, which is not a router, for forwarding". Clearly the relevant part is intended to be "for forwarding" and if you define (reaosnably) a router as any node which forwards packets, then this part makes sense, but to many people, a "router" is something that you buy from cisco/bay/nortel/3com/... and a PC running *BSD or linux isn't one. Just clean up Erik's working (I think there's already been another suggestion which looked OK). kre From owner-zeroconf@merit.edu Wed Feb 19 07:39:15 2003 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 HAA22352 for ; Wed, 19 Feb 2003 07:39:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C951491249; Wed, 19 Feb 2003 07:42:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8CCB49124D; Wed, 19 Feb 2003 07:42:55 -0500 (EST) 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 9B2FB91249 for ; Wed, 19 Feb 2003 07:42:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C6AE5E105; Wed, 19 Feb 2003 07:42:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id B0C935E110 for ; Wed, 19 Feb 2003 07:42:48 -0500 (EST) Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1JCgfd28212; Wed, 19 Feb 2003 19:42:41 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1JCbBK06157; Wed, 19 Feb 2003 19:37:11 +0700 (ICT) From: Robert Elz To: Brad Hards Cc: Keith Moore , aboba@internaut.com, zeroconf@merit.edu Subject: Re: [Issue 27]: LL-only hosts In-Reply-To: <200302191733.40896.bhards@bigpond.net.au> References: <200302191733.40896.bhards@bigpond.net.au> <200302190650.47575.bhards@bigpond.net.au> <20030218151219.6bb3b1e0.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Feb 2003 19:37:11 +0700 Message-ID: <6155.1045658231@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 19 Feb 2003 17:33:40 +1100 From: Brad Hards Message-ID: <200302191733.40896.bhards@bigpond.net.au> | If there is a mandatory requirement for zeroconf allocation of Internet | routable addresses, You're misreading the request, which is not that. What is being asked is that nodes should be able to be configured to use routable addresses. The mechanism doesn't belong to this WG. The same nodes should also be able to autoconfigure themselves (LL addresses) when there is no other configuration, so they can work on isolated nets. | If the requirement is really to achieve networking on a single network segment | (ie where all hosts are reachable by link-layer broadcast/multicast), then | there is no apparent requirement for anything except Link Local address | assignment - DHCP is not needed. It wouldn't be, if you can find a way for the node to know whether it is on an isolated LAN, or whether it is connected to a LAN to which lots of other LANs (and perhaps the whole internet) is also connected. Or more relevantly here, if you can simultaneously describe a node which cannot ever be connected to a LAN where having a routable address would be an advantage, and which also has some need to conform with Internet standards. kre From owner-zeroconf@merit.edu Wed Feb 19 07:40:39 2003 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 HAA22477 for ; Wed, 19 Feb 2003 07:40:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6C9879124D; Wed, 19 Feb 2003 07:44:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E50B91250; Wed, 19 Feb 2003 07:44:19 -0500 (EST) 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 3C6F29124D for ; Wed, 19 Feb 2003 07:44:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1F8E45E111; Wed, 19 Feb 2003 07:44:18 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta04ps.bigpond.com (mta04ps.bigpond.com [144.135.25.136]) by segue.merit.edu (Postfix) with ESMTP id CA5D25E105 for ; Wed, 19 Feb 2003 07:44:16 -0500 (EST) Received: from pc-00206 ([144.135.25.81]) by mta04ps.bigpond.com (Netscape Messaging Server 4.15 mta04ps Jul 16 2002 22:47:55) with SMTP id HAK3DP00.15Q; Wed, 19 Feb 2003 22:44:13 +1000 Received: from CPE-203-51-28-240.nsw.bigpond.net.au ([203.51.28.240]) by psmam05.mailsvc.email.bigpond.com(MailRouter V3.2e 107/3436672); 19 Feb 2003 22:44:12 From: Brad Hards To: Erik Guttman , zeroconf@merit.edu Subject: Re: new issue [LL24] Weaken the PRN generated address requirement from MUST to MAY Date: Wed, 19 Feb 2003 23:30:33 +1100 User-Agent: KMail/1.4.5 References: In-Reply-To: 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: <200302192330.33455.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 12 Feb 2003 01:22, Erik Guttman wrote: > The new issue follows. It may also be found under > http://www.spybeam.org/ll24.html > > I reluctantly post this issue since I do not yet understand its > justification. > > ------------------------------------ > Description of Issue Weaken the PRN generated address requirement from > MUST to MAY > Submitter Name Subrata Goswami > Submitter Email Address sgoswami@umich.edu > Date first submitted 11 Feb 03 > Reference none > Comment Type ['T'echnical | 'E'ditorial] T > Priority ['S' Must fix | '1' Should fix | '2' May fix ] 2 > Section 2.1 > > Rationale/Explanation of issue: > > The algorithm that a LL node uses to determine its LL address does not > need to be always PRN based, as ARP can be used validate if it is unique > in the Link. Lengthy description of problem: Section 2.1 says, > > "When a host wishes to configure a link-local address, it selects > an address using a pseudo-random number generator with a uniform > distribution in the range from 169.254.1.0 to 169.254.254.255." > > ".. The pseudo-random number generation algorithm MUST be chosen so that > different hosts do not generate the same sequence of numbers." > > Here text should be changed to indicted that the node can use other > means to select a LL address than PRN, but has to varify uniqueness by > ARPing before it intends to use that adderess on a link the first time > (or after absence). > > Requested Change: > > ".. The pseudo-random number generation algorithm MAY be chosen so that > different hosts do not generate the same sequence of numbers." Reject. The basis is not well supported, and the wording change is broken, since it (appears to) say that the implementation may elect to choose an algorithm that does generate the same sequence of numbers. This can lead to a pathological case where two or more machines get into lock-step, each trying to claim an address, only to collide and move onto the next number in an identical sequence, only to collide, and so on. One of the I-Ds describes this. Brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+U3jpW6pHgIdAuOMRApB+AJ9L8tNV1UNlQQhdZYC/ZNh8fLwDxACfXV6A IMgKZ4zO4Kf49zW1Ew8xvFA= =Tax1 -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Wed Feb 19 07:52:28 2003 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 HAA23318 for ; Wed, 19 Feb 2003 07:52:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 791E191257; Wed, 19 Feb 2003 07:56:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 42B6C9125A; Wed, 19 Feb 2003 07:56:07 -0500 (EST) 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 36AC891257 for ; Wed, 19 Feb 2003 07:56:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 255455DFC1; Wed, 19 Feb 2003 07:56:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 2317A5DE12 for ; Wed, 19 Feb 2003 07:56:04 -0500 (EST) Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1JCtsd29830; Wed, 19 Feb 2003 19:55:55 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1JCoDK06179; Wed, 19 Feb 2003 19:50:13 +0700 (ICT) From: Robert Elz To: Bernard Aboba Cc: zeroconf@merit.edu Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Feb 2003 19:50:13 +0700 Message-ID: <6177.1045659013@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 17 Feb 2003 08:16:44 -0800 (PST) From: Bernard Aboba Message-ID: | Most of the text here seems ok, with the exception of the last sentence: | | "Where that configuration | mechanism uses DHCP, the node MUST implement the DHCP option to disable | stateless auto-configuration in IPv4 clients [RFC2563]." | | If we accept the resolution of Issue 1, then we already have a way to | disable stateless auto-configuration -- provide a DHCPv4 address. As a | result, this last sentence is unnecessary. No, that omits the possibility that what is desired is to disable LL addressing *without* allocating a routable address. That is, to tell the node that there's no point configuring IP on the LAN to which it is connected (most likely, it is plugged into the wrong place). Note, this is not about preventing intruders from accessing the net (which as people keep pointing out, irrelevantly, cannot be done this way), the intent is to allow the node to discover what is appropriate to use on the LAN to which it has been connected, which is, sometimes, nothing. We're lacking functionality if we don't provide any mechanism to handle that case. The alternative is to tell people that having their DHCP server assign a bogus address to the end node achieves the same result (which it almost does). That's worse as far as DoS issues go (the node doesn't know the address is bogus, hence has no reason to prefer some alternative offer) and leaves the node believing that the net should be functional (sending ARP requests, ...) when it really would be better knowing that it has no (IP) connectivity. Or, we could show people how to run ARP response daemons (I suspect, but haven't verified, that "arpd" can do this with suitable config) to prevent LL addresses being assigned (or with more sophistication, assigned to particular nodes). As a mechanism to disable LL addressing this one works fine, but requires a connection on each LAN where it is to be applied. DHCP gives net admins no more power (less actually as it doesn't prevent the node ignoring the 2563 advice) but more convenience. | Presumably if there were a real need for this functionality, we | would have implementations of RFC2563, but we don't. As a result, the | right thing to do with RFC 2563 is to deprecate it, not make it mandatory. We don't, what we have is a chicken and egg problem. No servers support it as no clients make use of it. No clients bother because no servers respond (and in general, client implementors prefer not to have to consider what happens if they have no addresses - though it is something that really needs to be properly handled). If this WG were to mandate 2563 support in clients, then clients will start doing it, and with that incentive, server support will appear as well. If there was truly no demand for 2563, why would the RFC have ever been written, and survived IETF last call, in the first place? It is wanted, there just hasn't been an adequate place to require its implementation before. It only applies to LL addressing, and the docs from this WG are the first from the IETF that have specified anything about that. kre From owner-zeroconf@merit.edu Wed Feb 19 08:43:12 2003 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 IAA24710 for ; Wed, 19 Feb 2003 08:43:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B6CB79125C; Wed, 19 Feb 2003 08:46:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 827219125D; Wed, 19 Feb 2003 08:46:44 -0500 (EST) 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 3B88B9125C for ; Wed, 19 Feb 2003 08:46:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4D5BB5DFC1; Wed, 19 Feb 2003 08:46:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by segue.merit.edu (Postfix) with ESMTP id CF3FD5E103 for ; Wed, 19 Feb 2003 08:46:00 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lUXs-0003wc-00; Wed, 19 Feb 2003 05:45:56 -0800 Date: Wed, 19 Feb 2003 08:43:05 -0500 From: Keith Moore To: Brad Hards Cc: moore@cs.utk.edu, aboba@internaut.com, zeroconf@merit.edu Subject: Re: LL27: LL-only hosts Message-Id: <20030219084305.7d4892b5.moore@cs.utk.edu> In-Reply-To: <200302191733.40896.bhards@bigpond.net.au> References: <200302190650.47575.bhards@bigpond.net.au> <20030218151219.6bb3b1e0.moore@cs.utk.edu> <200302191733.40896.bhards@bigpond.net.au> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > If there is a mandatory requirement for zeroconf allocation of Internet > routable addresses, then clearly we cannot achieve that with IPv4, and we > should probably just give up and wait 10-20 years for IPv6. However I don't > see that as a requirement. you're misunderstanding both the meaning of routable addresses and the meaning of the requirement. the requirement is that devices be able to be assigned a routable address. a routable address is essentially an address other than an LL address. (RFC 1918 addresses are routable, though not globally routable) one effect of the requirement is that the device can be connected to the Internet if its user desires to do so. > I'll cite ARP as an example of previous work that > is clearly link-local. but ARP permits devices to have routable addresses, and thus, to work with the Internet. LL by itself does not. Keith From owner-zeroconf@merit.edu Wed Feb 19 08:58:20 2003 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 IAA25086 for ; Wed, 19 Feb 2003 08:58:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 635DA91231; Wed, 19 Feb 2003 09:01:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22FC39125D; Wed, 19 Feb 2003 09:01:54 -0500 (EST) 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 027A291231 for ; Wed, 19 Feb 2003 09:01:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id E103D5E111; Wed, 19 Feb 2003 09:01:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by segue.merit.edu (Postfix) with ESMTP id 8C4025DDC0 for ; Wed, 19 Feb 2003 09:01:48 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lUn8-0002wc-00; Wed, 19 Feb 2003 06:01:42 -0800 Date: Wed, 19 Feb 2003 08:58:51 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL27: LL-only hosts Message-Id: <20030219085851.6851e618.moore@cs.utk.edu> In-Reply-To: <028001c2d808$a78897c0$131010ac@aldebaran> References: <200302190622.03405.bhards@bigpond.net.au> <20030218144034.71c2e078.moore@cs.utk.edu> <200302190650.47575.bhards@bigpond.net.au> <20030218151219.6bb3b1e0.moore@cs.utk.edu> <028001c2d808$a78897c0$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Saying that a standard which extends TCP/IP is immediately out of scope for > IETF wherever it does not connect to *The Internet* seems a very narrow > reading of the IETF's scope and begs a lot of questions about what would > happen should another standards body emerge specifically to develop IP > extensions. True. And we've understood for years that while our standards are designed for the Internet, they're often used in private and/or isolated networks. However what we're talking about here is a standard that allows a conforming device to not _be able_ to connect to the Internet, which does seem over the line. > Suppose someone were to take IPv4LL to another standards body > because they perceive a need to to get a standard for LL only devices, there > then gets to be a problem of tracking and synchronisation of standards and > all sorts of thorny issues. It doesn't have to be that way. For instance, the other standards document could reference the relevant portions of the IETF standard. From owner-zeroconf@merit.edu Wed Feb 19 09:30:06 2003 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 JAA25885 for ; Wed, 19 Feb 2003 09:30:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 23D369125E; Wed, 19 Feb 2003 09:33:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D159291262; Wed, 19 Feb 2003 09:33:46 -0500 (EST) 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 CF7129125E for ; Wed, 19 Feb 2003 09:33:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id B0F175DE6F; Wed, 19 Feb 2003 09:33:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 428F35DDC0 for ; Wed, 19 Feb 2003 09:33:44 -0500 (EST) Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1JEXYd26150; Wed, 19 Feb 2003 21:33:34 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1JEQKK06850; Wed, 19 Feb 2003 21:26:21 +0700 (ICT) From: Robert Elz To: Markku Savela Cc: philip@engarts.com, zeroconf@merit.edu Subject: Re: [LL27]: LL-only hosts In-Reply-To: <200302191143.h1JBhRX3007336@burp.tkv.asdf.org> References: <200302191143.h1JBhRX3007336@burp.tkv.asdf.org> <200302190622.03405.bhards@bigpond.net.au><20030218144034.71c2e078.moore@cs.utk.edu><200302190650.47575.bhards@bigpond.net.au> <20030218151219.6bb3b1e0.moore@cs.utk.edu> <028001c2d808$a78897c0$131010ac@aldebaran> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Feb 2003 21:26:20 +0700 Message-ID: <6848.1045664780@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 19 Feb 2003 13:43:27 +0200 From: Markku Savela Message-ID: <200302191143.h1JBhRX3007336@burp.tkv.asdf.org> | I strongly disagree on this. I want to be able to run LL-only node in | parallel to the connected node. | | And that, these "nodes" could be located virtually at same machine | sharing the network interface. It isn't clear from this what you mean, I see two (at least) quite different things that you might be doing. You might mean that you're running a system, with two OS's on it (in the sense of one OS hosting another, or virtual machines, each running an OS), each of which is essentially independent of each other (processes on one use network protocols to communicate with the other in most cases). Or, you might be meaning an implementation technique. If its the latter, then for all practical purposes, you are doing both routed and LL, and LL27 would not be of any concern to you - your system will be able to be connected to the Internet, using routable addresses. Your implementation method to allow this to work is of concern only to you (and perhaps your users, depending upon how much of it is exposed). Since I think you're concerned with Linux, and it is pretty hard to imagine a linux system which (by design) cannot be connected to the Internet, I suspect that fro your point of view anyway, you can ignore Ll27. (There are other issues which would be relevant, but not this one). On the other hand, if what you're describing are virtual machines, each essentially independent of the other, then I can't see how you can possibly know in advance whether either or both of them need global connectivity or not, and I'd expect that both should (independently) be able to acquire both LL and routable addresses. I doubt this is the interpretation you mean though. kre ps: Any time a node has 2 (or more) addresses, it looks to other hosts (or hosts which don't examine the MAC addresses anyway, which would not be reliable in any case) as if there are two distinct nodes. There's no defined (IPv4) way to take one address and discover other addresses that may apply to the same node that I'm aware of. From owner-zeroconf@merit.edu Wed Feb 19 09:34:53 2003 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 JAA26005 for ; Wed, 19 Feb 2003 09:34:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3586191262; Wed, 19 Feb 2003 09:38:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 053D591263; Wed, 19 Feb 2003 09:38:33 -0500 (EST) 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 0767091262 for ; Wed, 19 Feb 2003 09:38:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id D6A425DDC0; Wed, 19 Feb 2003 09:38:32 -0500 (EST) 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 A47385DDB6 for ; Wed, 19 Feb 2003 09:38:32 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id D473D599DB for ; Wed, 19 Feb 2003 14:38:34 +0000 (GMT) Message-ID: <02f501c2d824$a3d06100$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <6177.1045659013@munnari.OZ.AU> Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL Date: Wed, 19 Feb 2003 14:38:59 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Robert Elz" > The alternative is to tell people that having their DHCP server assign > a bogus address to the end node achieves the same result (which it almost > does). That's worse as far as DoS issues go (the node doesn't know the > address is bogus, hence has no reason to prefer some alternative offer) > and leaves the node believing that the net should be functional (sending > ARP requests, ...) when it really would be better knowing that it has > no (IP) connectivity. RFC2563 actually "hands out" the address 0.0.0.0 as a way of saying "no address for you". This alone could be sufficient to prevent LL if we noted so in our draft. RFC2563 also specifies a separate "turn LL on/off" option. I guess that in the case that the network admin didn't want to give an address but was happy for you use LL, using this option would be quicker than simply not responding. (It would also allow the dubious case of saying "use both"). Philip From owner-zeroconf@merit.edu Wed Feb 19 09:58:03 2003 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 JAA26615 for ; Wed, 19 Feb 2003 09:58:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EFEF291263; Wed, 19 Feb 2003 10:01:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B995F91265; Wed, 19 Feb 2003 10:01:36 -0500 (EST) 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 8F97991263 for ; Wed, 19 Feb 2003 10:01:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 73B975E057; Wed, 19 Feb 2003 10:01:34 -0500 (EST) 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 4793F5DFCD for ; Wed, 19 Feb 2003 10:01:34 -0500 (EST) Received: from repligate ([67.36.179.41]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20030219150133.HISP3860.mailhost.chi1.ameritech.net@repligate> for ; Wed, 19 Feb 2003 09:01:33 -0600 Message-ID: <0c8901c2d827$d4976150$8500a8c0@repligate> From: "Jim Fleming" To: References: <200302190650.47575.bhards@bigpond.net.au><20030218151219.6bb3b1e0.moore@cs.utk.edu><200302191733.40896.bhards@bigpond.net.au> <20030219084305.7d4892b5.moore@cs.utk.edu> Subject: "RFC 1918 addresses are routable, though not globally routable" ? Date: Wed, 19 Feb 2003 09:01:49 -0600 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 "RFC 1918 addresses are routable, though not globally routable" ? By convention, that may be true with TOS=0x00,0x0*,0x*0 and when the AM/FM bit is 0. The InterNAT is capable of routing around the aging, toy, legacy, 32-bit core network and can use the 10.*.*.* address space and the other address spaces which are black-holes on the Internet. Jim Fleming http://IPv8.isfun.net ----- Original Message ----- From: "Keith Moore" To: "Brad Hards" Cc: ; ; Sent: Wednesday, February 19, 2003 7:43 AM Subject: Re: LL27: LL-only hosts > > > If there is a mandatory requirement for zeroconf allocation of Internet > > routable addresses, then clearly we cannot achieve that with IPv4, and we > > should probably just give up and wait 10-20 years for IPv6. However I don't > > see that as a requirement. > > you're misunderstanding both the meaning of routable addresses and > the meaning of the requirement. the requirement is that devices be able > to be assigned a routable address. a routable address is essentially > an address other than an LL address. (RFC 1918 addresses are routable, > though not globally routable) > > one effect of the requirement is that the device can be connected to the > Internet if its user desires to do so. > > > I'll cite ARP as an example of previous work that > > is clearly link-local. > > but ARP permits devices to have routable addresses, and thus, to work with > the Internet. LL by itself does not. > > Keith From owner-zeroconf@merit.edu Wed Feb 19 10:02:07 2003 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 KAA26859 for ; Wed, 19 Feb 2003 10:02:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7C21B91265; Wed, 19 Feb 2003 10:05:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49CA891266; Wed, 19 Feb 2003 10:05:49 -0500 (EST) 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 47E7C91265 for ; Wed, 19 Feb 2003 10:05:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3034F5DFCD; Wed, 19 Feb 2003 10:05:48 -0500 (EST) 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 12A6D5DEF5 for ; Wed, 19 Feb 2003 10:05:48 -0500 (EST) Received: from repligate ([67.36.179.41]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20030219150547.HKSB3860.mailhost.chi1.ameritech.net@repligate> for ; Wed, 19 Feb 2003 09:05:47 -0600 Message-ID: <0c8f01c2d828$6bf2c940$8500a8c0@repligate> From: "Jim Fleming" To: References: <200302190622.03405.bhards@bigpond.net.au><20030218144034.71c2e078.moore@cs.utk.edu><200302190650.47575.bhards@bigpond.net.au><20030218151219.6bb3b1e0.moore@cs.utk.edu><028001c2d808$a78897c0$131010ac@aldebaran> <20030219085851.6851e618.moore@cs.utk.edu> Subject: "standards are designed for the Internet, they're often used in private and/or isolated networks..." ? Date: Wed, 19 Feb 2003 09:06:03 -0600 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 "standards are designed for the Internet, they're often used in private and/or isolated networks..." === It is estimated that over 80% of all IPv4 equipment, is never physically connected to what some claim is the global public transport. Did the Space Shuttle use the "Internet" for guidance information ? Jim Fleming http://IPv8.dyn.ee .PS...Did the Space Shuttle use the "Internet" for guidance information ? ----- Original Message ----- From: "Keith Moore" To: "Philip Nye" Cc: ; Sent: Wednesday, February 19, 2003 7:58 AM Subject: Re: LL27: LL-only hosts > > Saying that a standard which extends TCP/IP is immediately out of scope for > > IETF wherever it does not connect to *The Internet* seems a very narrow > > reading of the IETF's scope and begs a lot of questions about what would > > happen should another standards body emerge specifically to develop IP > > extensions. > > True. And we've understood for years that while our standards are designed > for the Internet, they're often used in private and/or isolated networks. > However what we're talking about here is a standard that allows a conforming > device to not _be able_ to connect to the Internet, which does seem over the > line. > > > Suppose someone were to take IPv4LL to another standards body > > because they perceive a need to to get a standard for LL only devices, there > > then gets to be a problem of tracking and synchronisation of standards and > > all sorts of thorny issues. > > It doesn't have to be that way. For instance, the other standards document > could reference the relevant portions of the IETF standard. > From owner-zeroconf@merit.edu Wed Feb 19 10:17:00 2003 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 KAA28011 for ; Wed, 19 Feb 2003 10:17:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7E0B791266; Wed, 19 Feb 2003 10:20:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4DBB191267; Wed, 19 Feb 2003 10:20:41 -0500 (EST) 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 5C15091266 for ; Wed, 19 Feb 2003 10:20:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F6C95DE39; Wed, 19 Feb 2003 10:20:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id C118B5DDBA for ; Wed, 19 Feb 2003 10:20:38 -0500 (EST) Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1JFKTd22686; Wed, 19 Feb 2003 22:20:30 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1JFCaK07468; Wed, 19 Feb 2003 22:12:37 +0700 (ICT) From: Robert Elz To: "Philip Nye" Cc: "Zeroconf Working Group" Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL In-Reply-To: <02f501c2d824$a3d06100$131010ac@aldebaran> References: <02f501c2d824$a3d06100$131010ac@aldebaran> <6177.1045659013@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Feb 2003 22:12:36 +0700 Message-ID: <7466.1045667556@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 19 Feb 2003 14:38:59 -0000 From: "Philip Nye" Message-ID: <02f501c2d824$a3d06100$131010ac@aldebaran> | RFC2563 actually "hands out" the address 0.0.0.0 as a way of saying "no | address for you". This alone could be sufficient to prevent LL if we noted | so in our draft. Yes, it would, but if we're going to go that far, the rest of what is in 2563 is pretty trivial, and potentially useful (occasionally). Note I'm not wedded to 2563 - I didn't even know it existed until someone brought it up here part way along. Its only advantage over other similar possible techniques is that it is already out there, documented, etc. kre From owner-zeroconf@merit.edu Wed Feb 19 10:36:28 2003 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 KAA29050 for ; Wed, 19 Feb 2003 10:36:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D8FDD91267; Wed, 19 Feb 2003 10:40:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A296491269; Wed, 19 Feb 2003 10:40:08 -0500 (EST) 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 5E44591267 for ; Wed, 19 Feb 2003 10:40:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 37C875DEF5; Wed, 19 Feb 2003 10:40:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 8FB165DE39 for ; Wed, 19 Feb 2003 10:40:04 -0500 (EST) Received: from delta.cs.mu.OZ.AU ([172.30.0.189]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1JFdod03146; Wed, 19 Feb 2003 22:39:51 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1JFVeK07515; Wed, 19 Feb 2003 22:31:41 +0700 (ICT) From: Robert Elz To: Ted Lemon Cc: Zeroconf Subject: Re: [Issue 2 - LL2] Explicit Additional Mechanism to disable v4LL In-Reply-To: <99FA06FE-3DDB-11D7-A697-00039367340A@nominum.com> References: <99FA06FE-3DDB-11D7-A697-00039367340A@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Feb 2003 22:31:40 +0700 Message-ID: <7513.1045668700@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 11 Feb 2003 10:12:22 -0600 From: Ted Lemon Message-ID: <99FA06FE-3DDB-11D7-A697-00039367340A@nominum.com> Now this issue is open for discussion, I will reply to this old(ish) message... | > This only works if you're also willing to mandate some kind of stable | > storage in every node supporting v4LL addresses. I don't think that's | > reasonable. | | Can you give us an example of a device that you can buy today that | autoconfigures on the network but does not have any nvram? not off hand. Though NetBSD-live (i386live) (the NetBSD that boots and runs entirely from a CD) is probably close (a PC with no writable discs has no stable storage that is useful for its OS - the BIOS config space isn't really available or useful). | If not, | your definition of "not reasonable" is pretty extreme. The only thing | I can think of is a mote, and I'm not even sure *those* are devoid of | nvram. What really matters for this though is whether you are willing to have the standard say: Link local addresses MUST NOT be implemented on devices without stable storage for configuration information. And whether you think you can get the rest of the WG to agree with you. I don't think that's needed, I certainly don't think it is possible. But without it, I do think we need a dynamic way to disable use of LL. I actually think we need a dynamic enable/disable mechanism anyway, as stable storage doesn't tend to be updated easily when a node moves from one LAN to another, but what addresses (or address types) should be used there certainly does. kre From owner-zeroconf@merit.edu Wed Feb 19 11:03:48 2003 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 LAA29810 for ; Wed, 19 Feb 2003 11:03:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5859C91234; Wed, 19 Feb 2003 11:07:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 13EA091269; Wed, 19 Feb 2003 11:07:28 -0500 (EST) 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 EB9D591234 for ; Wed, 19 Feb 2003 11:07:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id CAED55DEE1; Wed, 19 Feb 2003 11:07:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by segue.merit.edu (Postfix) with ESMTP id 882735DE39 for ; Wed, 19 Feb 2003 11:07:27 -0500 (EST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 19 Feb 2003 08:07:22 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Feb 2003 08:07:26 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 19 Feb 2003 08:07:24 -0800 Received: from WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 19 Feb 2003 08:07:25 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 19 Feb 2003 08:07:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [LL2]: Explicit Additional Mechanism to disable v4LL Date: Wed, 19 Feb 2003 08:06:57 -0800 Message-ID: Thread-Topic: [LL2]: Explicit Additional Mechanism to disable v4LL Thread-Index: AcLYFk5w2XVZey17Qji4/sSGdpJqdQAGgJhQ From: "Christian Huitema" To: "Robert Elz" , "Bernard Aboba" Cc: X-OriginalArrivalTime: 19 Feb 2003 16:07:14.0159 (UTC) FILETIME=[F776E7F0:01C2D830] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA29810 > | Most of the text here seems ok, with the exception of the last > sentence: > | > | "Where that configuration > | mechanism uses DHCP, the node MUST implement the DHCP option to > disable > | stateless auto-configuration in IPv4 clients [RFC2563]." > | > | If we accept the resolution of Issue 1, then we already have a way to > | disable stateless auto-configuration -- provide a DHCPv4 address. As a > | result, this last sentence is unnecessary. > > No, that omits the possibility that what is desired is to disable LL > addressing *without* allocating a routable address. That is, to tell > the node that there's no point configuring IP on the LAN to which it > is connected (most likely, it is plugged into the wrong place). I agree with KRE's assessment. This is not a security issue, but a usability issue. Suppose a network in which, for whatever reason, the resident hosts have been configured not to interact with LL addresses. In such a network, the visiting host which configures an LL address will find out eventually that it cannot communicate with any other host. Wouldn't it be better to have a way to learn that immediately? -- Christian Huitema From owner-zeroconf@merit.edu Wed Feb 19 11:25:10 2003 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 LAA00484 for ; Wed, 19 Feb 2003 11:25:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 147739121B; Wed, 19 Feb 2003 11:28:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE5289122F; Wed, 19 Feb 2003 11:28:51 -0500 (EST) 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 B7F499121B for ; Wed, 19 Feb 2003 11:28:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id A70A85DFEC; Wed, 19 Feb 2003 11:28:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 12ADB5DFE7 for ; Wed, 19 Feb 2003 11:28:50 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1JF1kW07087; Wed, 19 Feb 2003 07:01:46 -0800 Date: Wed, 19 Feb 2003 07:01:46 -0800 (PST) From: Bernard Aboba To: Robert Elz Cc: zeroconf@merit.edu Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL In-Reply-To: <6177.1045659013@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > No, that omits the possibility that what is desired is to disable LL > addressing *without* allocating a routable address. That is, to tell > the node that there's no point configuring IP on the LAN to which it > is connected (most likely, it is plugged into the wrong place). So the idea is to use this option in a scenario where DHCPv4 is being used (otherwise the option would not be helpful) but where the DHCPv4 server is not assigning addresses? (if it were, by LL23, use of LLv4 would not occur). This doesn't seem like a very mainstream scenario. > Note, this is not about preventing intruders from accessing the net > (which as people keep pointing out, irrelevantly, cannot be done this > way), the intent is to allow the node to discover what is appropriate > to use on the LAN to which it has been connected, which is, sometimes, > nothing. Maybe it's just me, but I don't know many instances where DHCPv4 is supported where the intent is *not* to assign IP addresses. If such an option is used, it would definitely seem to require authenticated DHCP, or else it would create a security vulnerability. > The alternative is to tell people that having their DHCP server assign > a bogus address to the end node achieves the same result (which it almost > does). "Achieve the same result" means trying to make sure that the hosts in an organization have no IP addresses? Why use DHCP to achieve that result (except by accident)? > We don't, what we have is a chicken and egg problem. No servers support > it as no clients make use of it. No clients bother because no servers > respond (and in general, client implementors prefer not to have to consider > what happens if they have no addresses - though it is something that really > needs to be properly handled). Actually, the causation diagram is a bit different. No customers ask for it, because existing implementations don't use LLv4 on an interface if a routable address is available on that interface, and they don't care about "configured" interfaces with no usage. Vendors don't build it because customers don't ask for it. > If this WG were to mandate 2563 support in clients, then clients will start > doing it, and with that incentive, server support will appear as well. Actually it's more likely that vendors will ignore the requirement, because customers don't care. > If there was truly no demand for 2563, why would the RFC have ever been > written, and survived IETF last call, in the first place? It is wanted, > there just hasn't been an adequate place to require its implementation before. 2563 was written prior to shipment of LLv4 enabled clients on a large scale, when it was thought there might be demand for the option. This turned out to not be the case. In addition, concern arose that the option represented a security vulnerability. So there are no current RFC 2563 implementations on any operating system, and I doubt we will see any. From owner-zeroconf@merit.edu Wed Feb 19 12:32:28 2003 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 MAA02395 for ; Wed, 19 Feb 2003 12:32:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3F0BA91252; Wed, 19 Feb 2003 12:36:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 068D591269; Wed, 19 Feb 2003 12:36:06 -0500 (EST) 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 EAA6291252 for ; Wed, 19 Feb 2003 12:36:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id CF97A5E0DE; Wed, 19 Feb 2003 12:36:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by segue.merit.edu (Postfix) with ESMTP id AEDA85DFEC for ; Wed, 19 Feb 2003 12:36:05 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lY8Y-0002eO-00; Wed, 19 Feb 2003 09:36:03 -0800 Date: Wed, 19 Feb 2003 12:33:09 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030219123309.32482dde.moore@cs.utk.edu> In-Reply-To: <02c901c2d812$cfd9e5d0$131010ac@aldebaran> References: <02c901c2d812$cfd9e5d0$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Neither option directly tackles the more difficult issue of transition from > configured to zero-config this is an interesting case. IMHO it should only happen when a network is losing its external address prefix, or by explicit decision of the network admin. if the routable addresses remain valid (i.e. they're not being reassigned) it's better for the network to use routable addresses (even if the network is isolated) than to use LL addresses. I suppose it would be useful to define ways for DHCP to say "stop using your DHCP assigned address and start using LL" in addition to the other things we'd like it to be able to say (e.g. "don't use LL" or "it's okay to use LL in addition to whatever routable addresses you've been assigned"). I'd strongly argue for using DHCP as the mechanism to do this, because DHCP is already used for network config purposes, and DHCP authentication is already defined (thus saving us the trouble of defining a new kind of authentication). From owner-zeroconf@merit.edu Wed Feb 19 12:35:10 2003 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 MAA02543 for ; Wed, 19 Feb 2003 12:35:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 88E4C9126B; Wed, 19 Feb 2003 12:38:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C93B91269; Wed, 19 Feb 2003 12:38:49 -0500 (EST) 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 2C6ED9126C for ; Wed, 19 Feb 2003 12:38:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id E2EBE5E118; Wed, 19 Feb 2003 12:38:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by segue.merit.edu (Postfix) with ESMTP id 292E15DE73 for ; Wed, 19 Feb 2003 12:38:46 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lYBA-0004rT-00; Wed, 19 Feb 2003 09:38:45 -0800 Date: Wed, 19 Feb 2003 12:35:53 -0500 From: Keith Moore Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: [LL24] Weaken the PRN generated address requirement from MUST to MAY Message-Id: <20030219123553.0d43164e.moore@cs.utk.edu> In-Reply-To: <200302192330.33455.bhards@bigpond.net.au> References: <200302192330.33455.bhards@bigpond.net.au> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 I disagree that MAY is sufficient. SHOULD would be okay with me. the consequence of more address collisions from the PRNG is more network traffic. the current draft tries to minimize network load, which is highly desirable. From owner-zeroconf@merit.edu Wed Feb 19 13:21:37 2003 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 NAA03923 for ; Wed, 19 Feb 2003 13:21:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0236B9126C; Wed, 19 Feb 2003 13:25:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C202F9126E; Wed, 19 Feb 2003 13:25:14 -0500 (EST) 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 C630A9126C for ; Wed, 19 Feb 2003 13:25:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id A76965DE16; Wed, 19 Feb 2003 13:25:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 2426D5DE0D for ; Wed, 19 Feb 2003 13:25:13 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1JIMgb28582; Wed, 19 Feb 2003 12:22:42 -0600 (CST) Date: Wed, 19 Feb 2003 11:25:11 -0700 Subject: Re: ACCEPT [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Stuart Cheshire , zeroconf@merit.edu To: Mika Liljeberg From: Ted Lemon In-Reply-To: <1045638772.17022.108.camel@devil> Message-Id: <7B5E5AFF-4437-11D7-9530-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > "A compliant node MUST use the 169.254/16 prefix, in addition to any > other on-link prefixes it may have, when determining whether a > particular destination is on-link. A compliant node MUST NOT send a > packet having a source address in the 169.254/16 range to an off-link > destination. A received packet with a source address in the 169.254/16 > range and a destination address that is not one of the receiving node's > own IP addresses MUST be discarded." This is good. I like this better than the text you proposed, Stuart (sorry!). From owner-zeroconf@merit.edu Wed Feb 19 13:23:52 2003 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 NAA04001 for ; Wed, 19 Feb 2003 13:23:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D48389126E; Wed, 19 Feb 2003 13:27:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A22409126F; Wed, 19 Feb 2003 13:27:30 -0500 (EST) 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 982999126E for ; Wed, 19 Feb 2003 13:27:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 85A335E039; Wed, 19 Feb 2003 13:27:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 4249D5DF2A for ; Wed, 19 Feb 2003 13:27:28 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1JIS3aj007460; Wed, 19 Feb 2003 20:28:03 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1JIS0wS007459; Wed, 19 Feb 2003 20:28:00 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: [LL2]: Explicit Additional Mechanism to disable v4LL From: Mika Liljeberg To: Christian Huitema Cc: Robert Elz , Bernard Aboba , zeroconf@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045679278.17022.112.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Feb 2003 20:27:59 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-19 at 18:06, Christian Huitema wrote: > I agree with KRE's assessment. This is not a security issue, but a > usability issue. Suppose a network in which, for whatever reason, the > resident hosts have been configured not to interact with LL addresses. > In such a network, the visiting host which configures an LL address will > find out eventually that it cannot communicate with any other host. > Wouldn't it be better to have a way to learn that immediately? You mean like put up a popup for the user rather than wait for him to try to connect to something? That sounds like a lot of fun waiting to happen... Besides, if two such nodes are plugged in, wouldn't it be better to have the communicate with each other even if the resident nodes refuse to communicate with them? MikaL From owner-zeroconf@merit.edu Wed Feb 19 13:47:29 2003 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 NAA04604 for ; Wed, 19 Feb 2003 13:47:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6D5CA91288; Wed, 19 Feb 2003 13:50:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F91291286; Wed, 19 Feb 2003 13:50:17 -0500 (EST) 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 8F47991283 for ; Wed, 19 Feb 2003 13:50:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 707D85DD93; Wed, 19 Feb 2003 13:50:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 0EB675DFE2 for ; Wed, 19 Feb 2003 13:50:12 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1JIlfb28766; Wed, 19 Feb 2003 12:47:42 -0600 (CST) Date: Wed, 19 Feb 2003 11:50:10 -0700 Subject: Re: [Issue 2 - LL2] Explicit Additional Mechanism to disable v4LL Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Zeroconf To: Robert Elz From: Ted Lemon In-Reply-To: <7513.1045668700@munnari.OZ.AU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > not off hand. Though NetBSD-live (i386live) (the NetBSD that boots > and > runs entirely from a CD) is probably close (a PC with no writable discs > has no stable storage that is useful for its OS - the BIOS config space > isn't really available or useful). The NetBSD live CD is itself stable storage - it has to have some kind of configuration burned onto it in order to be useful. If you don't want your NetBSD live system to do IPv4ll, all you have to do is burn a CD that is configured not to do IPv4ll. So this is a bad example. > What really matters for this though is whether you are willing to have > the standard say: > > Link local addresses MUST NOT be implemented on devices without > stable storage for configuration information. > > And whether you think you can get the rest of the WG to agree with you. No, I'm not willing to have the standard say that. I am willing to have the standard say something like "Devices that implement link-local addressing SHOULD have a mechanism whereby they can be configured not to attempt IPv4ll addressing." I've seen long diatribes by various people with amazingly strong opinions as to why IPv4ll absolutely MUST be disableable, but I've never heard anything that convinces me that we need any stronger language than what I've stated above. My point in asking you to come up with an example of a device without stable storage was to illustrate why I do not think stronger language than this is needed, not to assert that it is completely inconceivable that such a device could ever exist. MUST makes sense in situations where if you don't follow the spec, you don't have interoperability. If you say MUST, and the implementor doesn't follow the MUST, his or her application should fail to interoperate in the circumstances addressed by the MUST. So it is simply not appropriate to say MUST here - there is no interoperability issue. For operational issues, we say "SHOULD" if we strongly feel that every implementation should follow the recommendation, or "MAY" if the recommendation is optional. From owner-zeroconf@merit.edu Wed Feb 19 13:52:46 2003 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 NAA04830 for ; Wed, 19 Feb 2003 13:52:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4120991274; Wed, 19 Feb 2003 13:56:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0CC0691278; Wed, 19 Feb 2003 13:56:24 -0500 (EST) 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 0CE4D91274 for ; Wed, 19 Feb 2003 13:56:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id E95835DEEC; Wed, 19 Feb 2003 13:56:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 9726B5DD93 for ; Wed, 19 Feb 2003 13:56:23 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1JIpJb28806; Wed, 19 Feb 2003 12:51:19 -0600 (CST) Date: Wed, 19 Feb 2003 11:53:48 -0700 Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Robert Elz" , "Bernard Aboba" , To: "Christian Huitema" From: Ted Lemon In-Reply-To: Message-Id: <7AFA1DF9-443B-11D7-9530-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Suppose a network in which, for whatever reason, the > resident hosts have been configured not to interact with LL addresses. > In such a network, the visiting host which configures an LL address > will > find out eventually that it cannot communicate with any other host. > Wouldn't it be better to have a way to learn that immediately? Sure. There are lots of things that would be nice. Some of them create opportunities for denial of service. This is one. Are you willing to have this immediate notification in one rare situation, in exchange for opening yourself up to a really easy denial of service attack? From owner-zeroconf@merit.edu Wed Feb 19 13:54:28 2003 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 NAA04863 for ; Wed, 19 Feb 2003 13:54:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A1D6D91278; Wed, 19 Feb 2003 13:57:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F76991279; Wed, 19 Feb 2003 13:57:59 -0500 (EST) 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 6D9B991278 for ; Wed, 19 Feb 2003 13:57:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 503955DE16; Wed, 19 Feb 2003 13:57:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id F249E5DD93 for ; Wed, 19 Feb 2003 13:57:57 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1JItRb28863; Wed, 19 Feb 2003 12:55:27 -0600 (CST) Date: Wed, 19 Feb 2003 11:57:55 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Philip Nye" , zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030219123309.32482dde.moore@cs.utk.edu> Message-Id: <0E19B872-443C-11D7-9530-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > this is an interesting case. IMHO it should only happen when a > network is > losing its external address prefix, or by explicit decision of the > network > admin. if the routable addresses remain valid (i.e. they're not being > reassigned) it's better for the network to use routable addresses > (even if > the network is isolated) than to use LL addresses. How about when the DHCP server fails? From owner-zeroconf@merit.edu Wed Feb 19 13:55:01 2003 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 NAA04883 for ; Wed, 19 Feb 2003 13:55:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A9D4791279; Wed, 19 Feb 2003 13:58:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 715D49127A; Wed, 19 Feb 2003 13:58:40 -0500 (EST) 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 01E3991279 for ; Wed, 19 Feb 2003 13:58:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id E50165DF2A; Wed, 19 Feb 2003 13:58:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by segue.merit.edu (Postfix) with ESMTP id A169B5DE16 for ; Wed, 19 Feb 2003 13:58:38 -0500 (EST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Wed, 19 Feb 2003 10:58:37 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 19 Feb 2003 10:58:33 -0800 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Feb 2003 10:58:36 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 19 Feb 2003 10:58:20 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 19 Feb 2003 10:58:35 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 19 Feb 2003 10:58:36 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [LL2]: Explicit Additional Mechanism to disable v4LL Date: Wed, 19 Feb 2003 10:57:53 -0800 Message-ID: Thread-Topic: [LL2]: Explicit Additional Mechanism to disable v4LL Thread-Index: AcLYRIjYUx6D7WedSSGi3ASRM6F8lAAAzXdw From: "Christian Huitema" To: "Mika Liljeberg" Cc: X-OriginalArrivalTime: 19 Feb 2003 18:58:36.0277 (UTC) FILETIME=[E8159A50:01C2D848] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA04883 > From: Mika Liljeberg [mailto:mika.liljeberg@welho.com] > On Wed, 2003-02-19 at 18:06, Christian Huitema wrote: > > I agree with KRE's assessment. This is not a security issue, but a > > usability issue. Suppose a network in which, for whatever reason, the > > resident hosts have been configured not to interact with LL addresses. > > In such a network, the visiting host which configures an LL address will > > find out eventually that it cannot communicate with any other host. > > Wouldn't it be better to have a way to learn that immediately? > > You mean like put up a popup for the user rather than wait for him to > try to connect to something? That sounds like a lot of fun waiting to > happen... The specific way in which information is conveyed to the user is certainly out of scope for the IETF -- flashing red LED, red crossed tray icon, pop up windows, whatever. The general idea is, if it won't work, find it now. Maybe you can correct that through some action, e.g. register the visiting host with some management service. > Besides, if two such nodes are plugged in, wouldn't it be better to have > the communicate with each other even if the resident nodes refuse to > communicate with them? I guess you can argue that either way. It is certainly the case that if they have link access today, no DHCP message will prevent two hosts from communicating using, for example, IPX. So it is a bit hard to argue that if a host has link access it should not be sending packets. Maybe the whole LL2 issue is a tempest in a tea cup. After all, we already have a way to determine that something is wrong: the host knows that there is a DHCP server, but the DHCP server will not give an address. This is probably enough to learn that "something is broken" and display whatever red light is appropriate. -- Christian Huitema From owner-zeroconf@merit.edu Wed Feb 19 13:58:45 2003 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 NAA05054 for ; Wed, 19 Feb 2003 13:58:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B04759128C; Wed, 19 Feb 2003 14:01:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83B219128B; Wed, 19 Feb 2003 14:01:56 -0500 (EST) 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 6BF7D9128A for ; Wed, 19 Feb 2003 14:01:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id A917A5E126; Wed, 19 Feb 2003 14:01:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by segue.merit.edu (Postfix) with ESMTP id 64E5B5E125 for ; Wed, 19 Feb 2003 14:01:37 -0500 (EST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 19 Feb 2003 11:01:34 -0800 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Feb 2003 11:01:36 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 19 Feb 2003 11:01:35 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 19 Feb 2003 11:01:35 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Wed, 19 Feb 2003 11:01:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [LL2]: Explicit Additional Mechanism to disable v4LL Date: Wed, 19 Feb 2003 11:00:52 -0800 Message-ID: Thread-Topic: [LL2]: Explicit Additional Mechanism to disable v4LL Thread-Index: AcLYSIwNQ1JHkgJ+SOCl8ACeMsdEZAAAIapg From: "Christian Huitema" To: "Ted Lemon" Cc: X-OriginalArrivalTime: 19 Feb 2003 19:01:35.0636 (UTC) FILETIME=[52FD9D40:01C2D849] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA05054 > > Suppose a network in which, for whatever reason, the > > resident hosts have been configured not to interact with LL addresses. > > In such a network, the visiting host which configures an LL address > > will > > find out eventually that it cannot communicate with any other host. > > Wouldn't it be better to have a way to learn that immediately? > > Sure. There are lots of things that would be nice. Some of them > create opportunities for denial of service. This is one. Are you > willing to have this immediate notification in one rare situation, in > exchange for opening yourself up to a really easy denial of service > attack? Ted, this denial of service argument is really bogus. Let's face it: LL, as specified, depends on ARP, and ARP is not secure. If someone is out to conduct a DOS attack on LL, they don't need bother with DHCP. -- Christian Huitema From owner-zeroconf@merit.edu Wed Feb 19 14:07:31 2003 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 OAA05299 for ; Wed, 19 Feb 2003 14:07:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 500909127B; Wed, 19 Feb 2003 14:11:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1FB0B9127C; Wed, 19 Feb 2003 14:11:10 -0500 (EST) 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 15BA09127B for ; Wed, 19 Feb 2003 14:11:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id ECDAF5DEEC; Wed, 19 Feb 2003 14:11:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 654CF5DD93 for ; Wed, 19 Feb 2003 14:11:07 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1JJBkaj007666; Wed, 19 Feb 2003 21:11:47 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1JJBh8J007663; Wed, 19 Feb 2003 21:11:43 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: [LL2]: Explicit Additional Mechanism to disable v4LL From: Mika Liljeberg To: Christian Huitema Cc: zeroconf@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045681902.17022.119.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Feb 2003 21:11:42 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-19 at 20:57, Christian Huitema wrote: > Maybe the whole LL2 issue is a tempest in a tea cup. After all, we > already have a way to determine that something is wrong: the host knows > that there is a DHCP server, but the DHCP server will not give an > address. This is probably enough to learn that "something is broken" and > display whatever red light is appropriate. This is my thinking as well. If this is a usability issue, it should enough to tell the user that DHCP is not giving out an address. It surely cannot be a security issue, since any automated measure to disable LL addressing would require the co-operation of the would-be attacker. My conclusion: reject LL2. MikaL From owner-zeroconf@merit.edu Wed Feb 19 14:17:33 2003 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 OAA05601 for ; Wed, 19 Feb 2003 14:17:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B9CB891280; Wed, 19 Feb 2003 14:21:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74FC19127D; Wed, 19 Feb 2003 14:21:11 -0500 (EST) 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 58BCE9127C for ; Wed, 19 Feb 2003 14:21:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3650B5E000; Wed, 19 Feb 2003 14:21:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by segue.merit.edu (Postfix) with ESMTP id 1306D5DEEC for ; Wed, 19 Feb 2003 14:21:10 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lZmE-0003bM-00; Wed, 19 Feb 2003 11:21:06 -0800 Date: Wed, 19 Feb 2003 14:18:15 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030219141815.3d3a8122.moore@cs.utk.edu> In-Reply-To: <0E19B872-443C-11D7-9530-00039317663C@nominum.com> References: <20030219123309.32482dde.moore@cs.utk.edu> <0E19B872-443C-11D7-9530-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > this is an interesting case. IMHO it should only happen when a > > network is losing its external address prefix, or by explicit decision of > > the network admin. if the routable addresses remain valid (i.e. they're > > not being reassigned) it's better for the network to use routable > > addresses (even if the network is isolated) than to use LL addresses. > > How about when the DHCP server fails? when the DHCP server fails, you want your hosts to keep using the same addresses they were using before. switching to LL will not in general allow the apps to contiune to work, because most hosts support at least one app that needs resources that are not on the local link. proper configuration of the DHCP service, including selection of lease times, helps a lot. Keith From owner-zeroconf@merit.edu Wed Feb 19 14:19:16 2003 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 OAA05648 for ; Wed, 19 Feb 2003 14:19:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 41DAB9127C; Wed, 19 Feb 2003 14:22:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D6AF9127D; Wed, 19 Feb 2003 14:22:54 -0500 (EST) 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 0DA049127C for ; Wed, 19 Feb 2003 14:22:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id E96645DEEC; Wed, 19 Feb 2003 14:22:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 67B155DD93 for ; Wed, 19 Feb 2003 14:22:53 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1JJKPb29055; Wed, 19 Feb 2003 13:20:25 -0600 (CST) Date: Wed, 19 Feb 2003 12:22:54 -0700 Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Christian Huitema" From: Ted Lemon In-Reply-To: Message-Id: <8BCDE3B0-443F-11D7-9530-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Ted, this denial of service argument is really bogus. Let's face it: > LL, > as specified, depends on ARP, and ARP is not secure. If someone is out > to conduct a DOS attack on LL, they don't need bother with DHCP. No, they don't need to do it with DHCP, but it's *much* easier with DHCP. And it's much harder to track down the offender. I've explained this before, not sure why it needs repeating. From owner-zeroconf@merit.edu Wed Feb 19 14:40:28 2003 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 OAA06382 for ; Wed, 19 Feb 2003 14:40:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F02459127D; Wed, 19 Feb 2003 14:44:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7A5C91281; Wed, 19 Feb 2003 14:44:06 -0500 (EST) 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 A39019127D for ; Wed, 19 Feb 2003 14:44:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E9495DEBC; Wed, 19 Feb 2003 14:44:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by segue.merit.edu (Postfix) with ESMTP id 6CB535DE1C for ; Wed, 19 Feb 2003 14:44:05 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18la7T-0001Rl-00; Wed, 19 Feb 2003 11:43:03 -0800 Date: Wed, 19 Feb 2003 14:40:11 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, huitema@windows.microsoft.com, kre@munnari.OZ.AU, aboba@internaut.com, zeroconf@merit.edu Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL Message-Id: <20030219144011.37b1919c.moore@cs.utk.edu> In-Reply-To: <7AFA1DF9-443B-11D7-9530-00039317663C@nominum.com> References: <7AFA1DF9-443B-11D7-9530-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Wed, 19 Feb 2003 11:53:48 -0700 Ted Lemon wrote: > > Suppose a network in which, for whatever reason, the > > resident hosts have been configured not to interact with LL addresses. > > In such a network, the visiting host which configures an LL address > > will > > find out eventually that it cannot communicate with any other host. > > Wouldn't it be better to have a way to learn that immediately? > > Sure. There are lots of things that would be nice. Some of them > create opportunities for denial of service. This is one. Given that DHCP is used at all, I don't see how the risk of DoS is increased by allowing DHCP to specify that LL not be used. And a host that is fooled into configuring LL when it should have acquired a routable address has still been successfully attacked. LL is simply not an adequate fallback for most hosts on most networks. From owner-zeroconf@merit.edu Wed Feb 19 14:43:13 2003 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 OAA06463 for ; Wed, 19 Feb 2003 14:43:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9765F91282; Wed, 19 Feb 2003 14:46:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2344391284; Wed, 19 Feb 2003 14:46:48 -0500 (EST) 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 833F891282 for ; Wed, 19 Feb 2003 14:46:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id A96215DEEC; Wed, 19 Feb 2003 14:46:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by segue.merit.edu (Postfix) with ESMTP id 1AA7D5DF48 for ; Wed, 19 Feb 2003 14:46:20 -0500 (EST) Received: from timepilot.gpcc.itd.umich.edu (timepilot.gpcc.itd.umich.edu [141.211.2.206]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id OAA01721 for ; Wed, 19 Feb 2003 14:46:19 -0500 (EST) Received: from localhost (sgoswami@localhost) by timepilot.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id OAA22683 for ; Wed, 19 Feb 2003 14:46:18 -0500 (EST) Date: Wed, 19 Feb 2003 14:46:18 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@timepilot.gpcc.itd.umich.edu To: zeroconf@merit.edu Subject: Re: LL1, LL23 In-Reply-To: <20030219141815.3d3a8122.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk let me join the frey, what happens if there are multiple DHCP servers, one saying use LL and another saying do not use LL ? so the final decision to LL or not LL depends on the node itself. On Wed, 19 Feb 2003, Keith Moore wrote: > > > this is an interesting case. IMHO it should only happen when a > > > network is losing its external address prefix, or by explicit decision of > > > the network admin. if the routable addresses remain valid (i.e. they're > > > not being reassigned) it's better for the network to use routable > > > addresses (even if the network is isolated) than to use LL addresses. > > > > How about when the DHCP server fails? > > when the DHCP server fails, you want your hosts to keep using the same > addresses they were using before. switching to LL will not in general > allow the apps to contiune to work, because most hosts support at least > one app that needs resources that are not on the local link. proper > configuration of the DHCP service, including selection of lease times, > helps a lot. > > Keith > > > From owner-zeroconf@merit.edu Wed Feb 19 14:57:06 2003 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 OAA06992 for ; Wed, 19 Feb 2003 14:57:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4E57B91284; Wed, 19 Feb 2003 15:00:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EAF1591292; Wed, 19 Feb 2003 15:00:15 -0500 (EST) 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 013AA91284 for ; Wed, 19 Feb 2003 15:00:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 051F15DF76; Wed, 19 Feb 2003 15:00:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 5898E5DDB3 for ; Wed, 19 Feb 2003 15:00:08 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1JJvcb29301; Wed, 19 Feb 2003 13:57:39 -0600 (CST) Date: Wed, 19 Feb 2003 13:00:08 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu, philip@engarts.com To: Keith Moore From: Ted Lemon In-Reply-To: <20030219141815.3d3a8122.moore@cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > when the DHCP server fails, you want your hosts to keep using the same > addresses they were using before. switching to LL will not in general > allow the apps to contiune to work, because most hosts support at least > one app that needs resources that are not on the local link. proper > configuration of the DHCP service, including selection of lease times, > helps a lot. "DHCP server fails" means "DHCP server fails to renew a client's lease before it expires," and also "DHCP server fails to provide a lease for a new client, and the client doesn't have a valid lease it can attempt to use". When either of these events occurs, the DHCP client MUST stop using its IP address, to avoid interoperability problems (e.g., when there is a shortage of IP addresses, the DHCP server is permitted to round-robin the addresses to the clients). Since we have allowed the camel's nose under the tent by saying that a DHCP-allocated IP address trumps an IPv4ll address, then we have to account for what happens in both of the above cases. So far we have accounted for what happens in only one of these cases. From owner-zeroconf@merit.edu Wed Feb 19 15:01:02 2003 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 PAA07110 for ; Wed, 19 Feb 2003 15:01:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 38F8F91285; Wed, 19 Feb 2003 15:04:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A8D791286; Wed, 19 Feb 2003 15:04:17 -0500 (EST) 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 CD12F91285 for ; Wed, 19 Feb 2003 15:03:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id AB1DF5DF76; Wed, 19 Feb 2003 15:03:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by segue.merit.edu (Postfix) with ESMTP id 899F95DF66 for ; Wed, 19 Feb 2003 15:03:20 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18laR4-0002R9-00; Wed, 19 Feb 2003 12:03:18 -0800 Date: Wed, 19 Feb 2003 15:00:26 -0500 From: Keith Moore To: "s. goswami" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030219150026.40b191a3.moore@cs.utk.edu> In-Reply-To: References: <20030219141815.3d3a8122.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > let me join the frey, what happens if there are multiple DHCP > servers, one saying use LL and another saying do not use LL ? garbage in, garbage out. but this group isn't chartered to solve problems with DHCP configuration. Keith From owner-zeroconf@merit.edu Wed Feb 19 15:02:24 2003 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 PAA07152 for ; Wed, 19 Feb 2003 15:02:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4339A91286; Wed, 19 Feb 2003 15:05:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14C5D91287; Wed, 19 Feb 2003 15:05:58 -0500 (EST) 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 2141F91286 for ; Wed, 19 Feb 2003 15:05:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0E4E25E000; Wed, 19 Feb 2003 15:05:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id ABE835DDB3 for ; Wed, 19 Feb 2003 15:05:56 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1JK0mb29330; Wed, 19 Feb 2003 14:00:49 -0600 (CST) Date: Wed, 19 Feb 2003 13:03:19 -0700 Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: huitema@windows.microsoft.com, kre@munnari.OZ.AU, aboba@internaut.com, zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030219144011.37b1919c.moore@cs.utk.edu> Message-Id: <30A51C3A-4445-11D7-9530-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > And a host that is fooled > into configuring LL when it should have acquired a routable address > has still > been successfully attacked. Keith, you're not making sense. How do you fool a host *into* configuring LL? From owner-zeroconf@merit.edu Wed Feb 19 15:10:28 2003 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 PAA07339 for ; Wed, 19 Feb 2003 15:10:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BFE0191289; Wed, 19 Feb 2003 15:14:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F2449128A; Wed, 19 Feb 2003 15:14:10 -0500 (EST) 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 8754791289 for ; Wed, 19 Feb 2003 15:14:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E3A85DF2A; Wed, 19 Feb 2003 15:14:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by segue.merit.edu (Postfix) with ESMTP id 6BDBD5DDB3 for ; Wed, 19 Feb 2003 15:13:44 -0500 (EST) Received: from timepilot.gpcc.itd.umich.edu (timepilot.gpcc.itd.umich.edu [141.211.2.206]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id PAA04987 for ; Wed, 19 Feb 2003 15:13:39 -0500 (EST) Received: from localhost (sgoswami@localhost) by timepilot.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id PAA29010 for ; Wed, 19 Feb 2003 15:13:39 -0500 (EST) Date: Wed, 19 Feb 2003 15:13:39 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@timepilot.gpcc.itd.umich.edu To: zeroconf@merit.edu Subject: Re: LL1, LL23 In-Reply-To: <20030219150026.40b191a3.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk if you are saying DHCP is garbage, then make use of DHCP optional. ideally DHCP should have no bearing on LL. by tying DHCP with LL usage we are trying to solve DHCP configuration problems among other things. On Wed, 19 Feb 2003, Keith Moore wrote: > > let me join the frey, what happens if there are multiple DHCP > > servers, one saying use LL and another saying do not use LL ? > > garbage in, garbage out. > > but this group isn't chartered to solve problems with DHCP configuration. > > Keith > From owner-zeroconf@merit.edu Wed Feb 19 15:12:34 2003 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 PAA07392 for ; Wed, 19 Feb 2003 15:12:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E15429128B; Wed, 19 Feb 2003 15:15:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0DFB9128D; Wed, 19 Feb 2003 15:15:29 -0500 (EST) 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 92B629128B for ; Wed, 19 Feb 2003 15:15:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C9F05DF2A; Wed, 19 Feb 2003 15:15:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by segue.merit.edu (Postfix) with ESMTP id C3C3A5DDB3 for ; Wed, 19 Feb 2003 15:15:26 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lack-00039F-00; Wed, 19 Feb 2003 12:15:22 -0800 Date: Wed, 19 Feb 2003 15:12:30 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030219151230.376bb62a.moore@cs.utk.edu> In-Reply-To: References: <20030219141815.3d3a8122.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > "DHCP server fails" means "DHCP server fails to renew a client's lease > before it expires," and also "DHCP server fails to provide a lease for > a new client, and the client doesn't have a valid lease it can attempt > to use". When either of these events occurs, the DHCP client MUST stop > using its IP address, to avoid interoperability problems (e.g., when > there is a shortage of IP addresses, the DHCP server is permitted to > round-robin the addresses to the clients). > > Since we have allowed the camel's nose under the tent by saying that a > DHCP-allocated IP address trumps an IPv4ll address, then we have to > account for what happens in both of the above cases. So far we have > accounted for what happens in only one of these cases. Okay, the reason that we want hosts to use LL only when DHCP doesn't answer is that we want these hosts to play well on configured networks. Having hosts configure LL when DHCP fails is not the same thing. In the latter case the host already knows its on a configured network, and that it is seeing a failure. Though it may work in limited instances, configuring LL is not in general a good means of recovering from such failures. If hosts want to configure an LL address when DHCP doesn't renew their leases, that's their own business. The LL standard doesn't have to define what happens in that case, and probably shouldn't. The right behavior will differ from one host/app to another. So I'd say that a host MAY configure LL if it cannot renew its DHCP lease, but if it does so it MUST continue attempting to acquire an address using DHCP, and cease using the LL address once such an address acquired. The point is that LL is not a suitable backup for DHCP server failure, nor for failure of network admins to properly configure their DHCP servers. This is such a frequent point of confusion that it needs to be explicitly said in the RFC. Keith From owner-zeroconf@merit.edu Wed Feb 19 15:13:21 2003 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 PAA07419 for ; Wed, 19 Feb 2003 15:13:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E9F9C9128A; Wed, 19 Feb 2003 15:16:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2AF39128D; Wed, 19 Feb 2003 15:16:50 -0500 (EST) 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 A86019128A for ; Wed, 19 Feb 2003 15:16:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A89F5E11E; Wed, 19 Feb 2003 15:16:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id A8CFB5DF2A for ; Wed, 19 Feb 2003 15:16:45 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1JKHPaj008040 for ; Wed, 19 Feb 2003 22:17:26 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1JKHOAI008037 for zeroconf@merit.edu; Wed, 19 Feb 2003 22:17:24 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: LL1 and LL23 From: Mika Liljeberg To: zeroconf@merit.edu Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045685843.7734.31.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Feb 2003 22:17:24 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm leaning towards rejecting the issue: "Supporting multiple address per interface, where one address is v4 LL and other addresses are configured leads to a scoped address problem. Hosts must select which source address to send datagrams with from that interface. In addition, application considerations are much more complex when there are multiple scopes in which the application must operate in." While there is some justification to this, I believe that the potential problem has been blown beyond its true proportions. With LL-only nodes, such problems are indeed inevitable and cannot be fixed by the measures proposed in either LL1 or LL23. With nodes having both LL and routable addresses, I'm not convinced. The text argues that multiple address per interface are a problem. What, then, of multihomed hosts? Is this somehow more of a problem than having a single address on each interface of a multihomed host? Applications need to deal with that as well. >From an implementation point of view, both LL1 and LL23 generate additional code and alternative code paths in a stack implementation. Of the two LL23 is clearly more demanding. LL1 is less so, but in a hybrid IPv4/IP6 implementation necessitates alternate code paths for IPv4 and IPv6 source address selection, where the current wording enables a shared code path. In the recent discussion I have seen zero concrete examples where having both LL and routable addresses in an interface would result in serious application problems. Given a sufficiently compelling example, I might reconsider. However, currently I see few advantages and some definite disadvantages. In my mind, the current wording in section 1.5 and 2.5 regarding source address selection is sufficient and appropriate. MikaL From owner-zeroconf@merit.edu Wed Feb 19 15:16:03 2003 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 PAA07476 for ; Wed, 19 Feb 2003 15:16:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 60F489128E; Wed, 19 Feb 2003 15:19:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 194AC9128F; Wed, 19 Feb 2003 15:19:30 -0500 (EST) 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 49AE09128D for ; Wed, 19 Feb 2003 15:19:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D7CD5DF08; Wed, 19 Feb 2003 15:19:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 1EE2F5DDB3 for ; Wed, 19 Feb 2003 15:19:28 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1JKK3aj008071; Wed, 19 Feb 2003 22:20:04 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1JKK1I1008052; Wed, 19 Feb 2003 22:20:01 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: "s. goswami" , zeroconf@merit.edu In-Reply-To: <20030219150026.40b191a3.moore@cs.utk.edu> References: <20030219141815.3d3a8122.moore@cs.utk.edu> <20030219150026.40b191a3.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045686000.7738.33.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Feb 2003 22:20:01 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-19 at 22:00, Keith Moore wrote: > garbage in, garbage out. > > but this group isn't chartered to solve problems with DHCP configuration. Come to think of it, this group isn't chartered to solve problems with LL nodes connecting to managed networks. MikaL From owner-zeroconf@merit.edu Wed Feb 19 15:16:10 2003 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 PAA07489 for ; Wed, 19 Feb 2003 15:16:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 93B3D91290; Wed, 19 Feb 2003 15:19:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 509C69128D; Wed, 19 Feb 2003 15:19:31 -0500 (EST) 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 9AE459128E for ; Wed, 19 Feb 2003 15:19:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 86AD75DF08; Wed, 19 Feb 2003 15:19:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by segue.merit.edu (Postfix) with ESMTP id 6486B5DDB3 for ; Wed, 19 Feb 2003 15:19:29 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lafm-000650-00; Wed, 19 Feb 2003 12:18:30 -0800 Date: Wed, 19 Feb 2003 15:15:38 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, huitema@windows.microsoft.com, kre@munnari.OZ.AU, aboba@internaut.com, zeroconf@merit.edu Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL Message-Id: <20030219151538.465d2439.moore@cs.utk.edu> In-Reply-To: <30A51C3A-4445-11D7-9530-00039317663C@nominum.com> References: <20030219144011.37b1919c.moore@cs.utk.edu> <30A51C3A-4445-11D7-9530-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > And a host that is fooled into configuring LL when it should have acquired > > a routable address has still been successfully attacked. > > Keith, you're not making sense. How do you fool a host *into* > configuring LL? by somehow blocking the DHCP server's response. Keith From owner-zeroconf@merit.edu Wed Feb 19 15:20:58 2003 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 PAA07594 for ; Wed, 19 Feb 2003 15:20:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D129A9128F; Wed, 19 Feb 2003 15:24:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2B5D91291; Wed, 19 Feb 2003 15:24:27 -0500 (EST) 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 98DEF9128F for ; Wed, 19 Feb 2003 15:24:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 857955DF2A; Wed, 19 Feb 2003 15:24:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 90BF25DF08 for ; Wed, 19 Feb 2003 15:24:25 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1JJ5fc20496; Wed, 19 Feb 2003 11:05:42 -0800 Date: Wed, 19 Feb 2003 11:05:41 -0800 (PST) From: Bernard Aboba To: Ted Lemon Cc: Keith Moore , , , Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL In-Reply-To: <30A51C3A-4445-11D7-9530-00039317663C@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > Keith, you're not making sense. How do you fool a host *into* > configuring LL? And what difference does it make if you do, assuming that the LLv4 address isn't used? From owner-zeroconf@merit.edu Wed Feb 19 15:28:28 2003 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 PAA07846 for ; Wed, 19 Feb 2003 15:28:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8BC1791293; Wed, 19 Feb 2003 15:32:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 45FB591294; Wed, 19 Feb 2003 15:32:02 -0500 (EST) 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 ABA4591293 for ; Wed, 19 Feb 2003 15:31:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 936115DE4C; Wed, 19 Feb 2003 15:31:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A5E6B5DDB3 for ; Wed, 19 Feb 2003 15:31:57 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1JJ53x20469; Wed, 19 Feb 2003 11:05:03 -0800 Date: Wed, 19 Feb 2003 11:05:03 -0800 (PST) From: Bernard Aboba To: Keith Moore Cc: Ted Lemon , , , Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL In-Reply-To: <20030219144011.37b1919c.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > Given that DHCP is used at all, I don't see how the risk of DoS is increased > by allowing DHCP to specify that LL not be used. Issue #23 already takes care of making sure that LLv4 will not be used if DHCPv4 is present. So that is already taken care of, no? > And a host that is fooled > into configuring LL when it should have acquired a routable address has still > been successfully attacked. How can it be attacked if the LLv4 address is configured, but not used? Is the issue that the host will be willing to receive on the LLv4 address? How would that occur if it is not advertised? > LL is simply not an adequate fallback for most hosts on most networks. I'd agree. From owner-zeroconf@merit.edu Wed Feb 19 15:32:58 2003 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 PAA08009 for ; Wed, 19 Feb 2003 15:32:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0740191294; Wed, 19 Feb 2003 15:34:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B82F91292; Wed, 19 Feb 2003 15:33:59 -0500 (EST) 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 DC37391294 for ; Wed, 19 Feb 2003 15:32:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id C23305DE4C; Wed, 19 Feb 2003 15:32:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by segue.merit.edu (Postfix) with ESMTP id 9FCF85DDB3 for ; Wed, 19 Feb 2003 15:32:52 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18latb-00020Q-00; Wed, 19 Feb 2003 12:32:47 -0800 Date: Wed, 19 Feb 2003 15:29:55 -0500 From: Keith Moore To: Brad Hards Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL27: LL-only hosts Message-Id: <20030219152955.7eb5e2aa.moore@cs.utk.edu> In-Reply-To: <200302200648.20986.bhards@bigpond.net.au> References: <028001c2d808$a78897c0$131010ac@aldebaran> <20030219085851.6851e618.moore@cs.utk.edu> <200302200648.20986.bhards@bigpond.net.au> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > True. And we've understood for years that while our standards are > > designed for the Internet, they're often used in private and/or isolated > > networks. However what we're talking about here is a standard that allows > > a conforming device to not _be able_ to connect to the Internet, which > > does seem over the line. > > Devices with Net10 addresses cannot connect to the Internet either, except > by NAT or application level proxy. 169.254/16 addresses are the same. NAT is not standardized, and use of RFC 1918 by NATs is a violation of RFC 1918. Of course RFC 1918 does allocate a block of addresses for use in isolated networks. But IETF's purpose in approving RFC 1918 as a BCP was to enhance interoperability on the public Internet by giving private networks an alternative to picking address blocks at random. That way when those addresses leak, as they inevitably do, they can be filtered, and the condition can be unambiguously recognized as an error. Now if this group were trying to publish a BCP that merely allocated a block of IPv4 addresses to be used as LL addresses, without specifying the LL protocol, I'd argue that RFC 1918 is an appropriate precedent. (though many would argue that RFC 1918 was a mistake and that based on experience we should not make another similar mistake). So please tell me - how does declaring LL-only devices to be in scope for the standard enhance interoperability on the Internet? Keith From owner-zeroconf@merit.edu Wed Feb 19 15:35:39 2003 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 PAA08079 for ; Wed, 19 Feb 2003 15:35:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 93DE79129E; Wed, 19 Feb 2003 15:36:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 409569129F; Wed, 19 Feb 2003 15:36:50 -0500 (EST) 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 6E3719129E for ; Wed, 19 Feb 2003 15:35:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5A1875DF01; Wed, 19 Feb 2003 15:35:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 064F65DE4C for ; Wed, 19 Feb 2003 15:35:27 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1JKWub29609; Wed, 19 Feb 2003 14:32:56 -0600 (CST) Date: Wed, 19 Feb 2003 13:35:26 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "s. goswami" , zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030219150026.40b191a3.moore@cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > but this group isn't chartered to solve problems with DHCP > configuration. No, but neither is it chartered to *create* problems with DHCP configuration! From owner-zeroconf@merit.edu Wed Feb 19 15:40:49 2003 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 PAA08281 for ; Wed, 19 Feb 2003 15:40:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B25E391292; Wed, 19 Feb 2003 15:44:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81E3591296; Wed, 19 Feb 2003 15:44:30 -0500 (EST) 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 6BDE391292 for ; Wed, 19 Feb 2003 15:44:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F7015E05C; Wed, 19 Feb 2003 15:44:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by segue.merit.edu (Postfix) with ESMTP id 2A0DE5DE4C for ; Wed, 19 Feb 2003 15:44:29 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lb43-000512-00; Wed, 19 Feb 2003 12:43:35 -0800 Date: Wed, 19 Feb 2003 15:40:43 -0500 From: Keith Moore To: Bernard Aboba Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, huitema@windows.microsoft.com, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL Message-Id: <20030219154043.3144cf46.moore@cs.utk.edu> In-Reply-To: References: <20030219144011.37b1919c.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > And a host that is fooled > > into configuring LL when it should have acquired a routable address has still > > been successfully attacked. > > How can it be attacked if the LLv4 address is configured, but not used? Is > the issue that the host will be willing to receive on the LLv4 address? > How would that occur if it is not advertised? use is the real issue. I don't care much if hosts configure LL addresses as long as they don't use them at inappropriate times. From owner-zeroconf@merit.edu Wed Feb 19 15:42:37 2003 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 PAA08323 for ; Wed, 19 Feb 2003 15:42:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8C98691297; Wed, 19 Feb 2003 15:45:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A15291298; Wed, 19 Feb 2003 15:45:39 -0500 (EST) 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 4F2C091297 for ; Wed, 19 Feb 2003 15:45:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 376BE5DE4C; Wed, 19 Feb 2003 15:45:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by segue.merit.edu (Postfix) with ESMTP id 26D8D5E10E for ; Wed, 19 Feb 2003 15:45:34 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lb54-0000iL-00; Wed, 19 Feb 2003 12:44:38 -0800 Date: Wed, 19 Feb 2003 15:41:46 -0500 From: Keith Moore To: Bernard Aboba Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, huitema@windows.microsoft.com, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL Message-Id: <20030219154146.5e5ede2f.moore@cs.utk.edu> In-Reply-To: References: <30A51C3A-4445-11D7-9530-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > >How do you fool a host *into* configuring LL? > > And what difference does it make if you do, assuming that the LLv4 address > isn't used? the point is that fallback to LL is not an effective defense against DoS attack. Keith From owner-zeroconf@merit.edu Wed Feb 19 15:43:27 2003 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 PAA08341 for ; Wed, 19 Feb 2003 15:43:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E69C491296; Wed, 19 Feb 2003 15:47:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DCDC91298; Wed, 19 Feb 2003 15:47:03 -0500 (EST) 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 2CD1091296 for ; Wed, 19 Feb 2003 15:47:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BBC95DE71; Wed, 19 Feb 2003 15:47:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by segue.merit.edu (Postfix) with ESMTP id D8B5F5DE4C for ; Wed, 19 Feb 2003 15:47:00 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lb7J-0005Wf-00; Wed, 19 Feb 2003 12:46:58 -0800 Date: Wed, 19 Feb 2003 15:44:06 -0500 From: Keith Moore To: "s. goswami" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030219154406.6feda977.moore@cs.utk.edu> In-Reply-To: References: <20030219150026.40b191a3.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > if you are saying DHCP is garbage, then make use of DHCP optional. nope, I'm saying that if you feed hosts broken DHCP configuations then it's silly to expect them to behave in a useful fashion. > ideally DHCP should have no bearing on LL. by tying DHCP with LL > usage we are trying to solve DHCP configuration problems > among other things. ideally LL should have no bearing on connected networks. by tying LL to DHCP we avoid many cases where LL would interfere with operation of those networks, or of hosts or apps on those networks. From owner-zeroconf@merit.edu Wed Feb 19 15:46:27 2003 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 PAA08391 for ; Wed, 19 Feb 2003 15:46:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2B64691201; Wed, 19 Feb 2003 15:50:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB56B91298; Wed, 19 Feb 2003 15:50:08 -0500 (EST) 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 F3ACA91201 for ; Wed, 19 Feb 2003 15:50:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id E073F5DE4C; Wed, 19 Feb 2003 15:50:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by segue.merit.edu (Postfix) with ESMTP id 183805DED1 for ; Wed, 19 Feb 2003 15:50:07 -0500 (EST) Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) with ESMTP id h1JKo1iC011718 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 19 Feb 2003 22:50:01 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) id h1JKo1mN011714; Wed, 19 Feb 2003 22:50:01 +0200 Date: Wed, 19 Feb 2003 22:50:01 +0200 Message-Id: <200302192050.h1JKo1mN011714@burp.tkv.asdf.org> From: Markku Savela To: moore@cs.utk.edu Cc: zeroconf@merit.edu In-reply-to: <20030219152955.7eb5e2aa.moore@cs.utk.edu> (message from Keith Moore on Wed, 19 Feb 2003 15:29:55 -0500) Subject: Re: LL27: LL-only hosts References: <028001c2d808$a78897c0$131010ac@aldebaran> <20030219085851.6851e618.moore@cs.utk.edu> <200302200648.20986.bhards@bigpond.net.au> <20030219152955.7eb5e2aa.moore@cs.utk.edu> Sender: owner-zeroconf@merit.edu Precedence: bulk > From: Keith Moore > > Now if this group were trying to publish a BCP that merely allocated a block > of IPv4 addresses to be used as LL addresses, without specifying the LL > protocol, The ONLY difference between use of RFC 1918 addresses and LL addresses is that this group specifies a protocol by wich LL addresses are automaticly assigned. From owner-zeroconf@merit.edu Wed Feb 19 15:46:49 2003 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 PAA08405 for ; Wed, 19 Feb 2003 15:46:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF4C291298; Wed, 19 Feb 2003 15:50:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2AAE91299; Wed, 19 Feb 2003 15:50:30 -0500 (EST) 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 A0ADA91298 for ; Wed, 19 Feb 2003 15:50:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 847415DED1; Wed, 19 Feb 2003 15:50:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by segue.merit.edu (Postfix) with ESMTP id 634C85DE4C for ; Wed, 19 Feb 2003 15:50:29 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lbAe-000533-00; Wed, 19 Feb 2003 12:50:25 -0800 Date: Wed, 19 Feb 2003 15:47:33 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, sgoswami@umich.edu, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030219154733.76a5f9a7.moore@cs.utk.edu> In-Reply-To: <1045686000.7738.33.camel@devil> References: <20030219141815.3d3a8122.moore@cs.utk.edu> <20030219150026.40b191a3.moore@cs.utk.edu> <1045686000.7738.33.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > but this group isn't chartered to solve problems with DHCP configuration. > > Come to think of it, this group isn't chartered to solve problems with > LL nodes connecting to managed networks. if LL nodes aren't going to be connected to the Internet, this group has no business at all existing in IETF, except perhaps to avoid address assignment conflicts as in RFC 1918. but the LL protocol would not be in scope for IETF. on the other hand if LL nodes are going to be connected to the Internet, as is already happening, then IETF clearly has an interest in making sure that those nodes don't interfere with IP networks more than necessary. it's called "damage control". why do you think this group was chartered? Keith From owner-zeroconf@merit.edu Wed Feb 19 15:50:27 2003 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 PAA08455 for ; Wed, 19 Feb 2003 15:50:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 46F0591299; Wed, 19 Feb 2003 15:54:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0846F9129A; Wed, 19 Feb 2003 15:54:08 -0500 (EST) 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 E867191299 for ; Wed, 19 Feb 2003 15:54:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id C60E75E10E; Wed, 19 Feb 2003 15:54:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by segue.merit.edu (Postfix) with ESMTP id C80CF5DED1 for ; Wed, 19 Feb 2003 15:54:02 -0500 (EST) Received: from timepilot.gpcc.itd.umich.edu (timepilot.gpcc.itd.umich.edu [141.211.2.206]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id PAA11407; Wed, 19 Feb 2003 15:54:01 -0500 (EST) Received: from localhost (sgoswami@localhost) by timepilot.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id PAA07679; Wed, 19 Feb 2003 15:54:01 -0500 (EST) Date: Wed, 19 Feb 2003 15:54:01 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@timepilot.gpcc.itd.umich.edu To: Keith Moore Cc: Brad Hards , , Subject: Re: LL27: LL-only hosts In-Reply-To: <20030219152955.7eb5e2aa.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > Now if this group were trying to publish a BCP that merely allocated a block > of IPv4 addresses to be used as LL addresses, without specifying the LL > protocol, I'd argue that RFC 1918 is an appropriate precedent. (though many > would argue that RFC 1918 was a mistake and that based on experience we should > not make another similar mistake). > What is the mistake here you are talking about ? NAT ? > So please tell me - how does declaring LL-only devices to be in scope for > the standard enhance interoperability on the Internet? > What is the Internet for you ? The globaly routable address space, the backbone routers (which by the way are usually manmaged through a 10.0.0.0 address) , or the 192.168/16 space in my home network ? > Keith > > From owner-zeroconf@merit.edu Wed Feb 19 15:51:02 2003 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 PAA08472 for ; Wed, 19 Feb 2003 15:51:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4409E9129A; Wed, 19 Feb 2003 15:54:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 118E39129B; Wed, 19 Feb 2003 15:54:44 -0500 (EST) 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 F3B439129A for ; Wed, 19 Feb 2003 15:54:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id E21D45DED1; Wed, 19 Feb 2003 15:54:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by segue.merit.edu (Postfix) with ESMTP id C18965DE4C for ; Wed, 19 Feb 2003 15:54:42 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lbEh-00070K-00; Wed, 19 Feb 2003 12:54:36 -0800 Date: Wed, 19 Feb 2003 15:51:44 -0500 From: Keith Moore To: Markku Savela Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL27: LL-only hosts Message-Id: <20030219155144.0440b306.moore@cs.utk.edu> In-Reply-To: <200302192050.h1JKo1mN011714@burp.tkv.asdf.org> References: <028001c2d808$a78897c0$131010ac@aldebaran> <20030219085851.6851e618.moore@cs.utk.edu> <200302200648.20986.bhards@bigpond.net.au> <20030219152955.7eb5e2aa.moore@cs.utk.edu> <200302192050.h1JKo1mN011714@burp.tkv.asdf.org> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > The ONLY difference between use of RFC 1918 addresses and LL addresses > is that this group specifies a protocol by wich LL addresses are > automaticly assigned. no, that's not the only difference. another important difference is that RFC 1918 addresses are not supposed to be used except on isolated networks, while LL addresses are permitted on links that are connected to the Internet. even so, if we knew then what we know now, we would not have approved RFC 1918. it was barely approved as it was. those who said it would be harmful were exactly right. (I was one of those who was wrong.) Keith From owner-zeroconf@merit.edu Wed Feb 19 15:56:46 2003 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 PAA08598 for ; Wed, 19 Feb 2003 15:56:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 496259129B; Wed, 19 Feb 2003 16:00:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B80BE9129D; Wed, 19 Feb 2003 16:00:11 -0500 (EST) 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 1BD329129B for ; Wed, 19 Feb 2003 16:00:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 70D4C5E118; Wed, 19 Feb 2003 16:00:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by segue.merit.edu (Postfix) with ESMTP id B22B95E10E for ; Wed, 19 Feb 2003 16:00:04 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lbJq-0001uq-00; Wed, 19 Feb 2003 12:59:55 -0800 Date: Wed, 19 Feb 2003 15:57:02 -0500 From: Keith Moore To: "s. goswami" Cc: moore@cs.utk.edu, bhards@bigpond.net.au, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL27: LL-only hosts Message-Id: <20030219155702.3705d118.moore@cs.utk.edu> In-Reply-To: References: <20030219152955.7eb5e2aa.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > Now if this group were trying to publish a BCP that merely allocated a block > > of IPv4 addresses to be used as LL addresses, without specifying the LL > > protocol, I'd argue that RFC 1918 is an appropriate precedent. (though many > > would argue that RFC 1918 was a mistake and that based on experience we should > > not make another similar mistake). > > What is the mistake here you are talking about ? NAT ? yes. there is a widespread belief that RFC 1918 encouraged NAT. > What is the Internet for you ? the set of networks that are connected together using IP. From owner-zeroconf@merit.edu Wed Feb 19 16:04:35 2003 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 QAA08822 for ; Wed, 19 Feb 2003 16:04:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 741019123A; Wed, 19 Feb 2003 16:08:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 45ED59129C; Wed, 19 Feb 2003 16:08:17 -0500 (EST) 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 43E429123A for ; Wed, 19 Feb 2003 16:08:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D7BA5E10E; Wed, 19 Feb 2003 16:08:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id D05405DE4C for ; Wed, 19 Feb 2003 16:08:15 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1JL5kb29863; Wed, 19 Feb 2003 15:05:46 -0600 (CST) Date: Wed, 19 Feb 2003 14:08:17 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu, philip@engarts.com To: Keith Moore From: Ted Lemon In-Reply-To: <20030219151230.376bb62a.moore@cs.utk.edu> Message-Id: <44262E02-444E-11D7-9530-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > The point is that LL is not a suitable backup for DHCP server failure, > nor for failure of network admins to properly configure their DHCP > servers. > This is such a frequent point of confusion that it needs to be > explicitly > said in the RFC. I don't think anybody is disputing whether or not LL is a suitable backup for DHCP server failure, and I have not heard one person on this mailing list express anything that suggested that they were confused about this. My personal opinion is that it is a mistake for there to be any interrelationship between IPv4ll and DHCP - the two should be orthogonal, because they do different things. Perhaps a better way to frame this issue is: what happens if the network stack is configured with a routable IP address, and then later that address is unconfigured? Does the IPv4ll agent at that point immediately go out and get an IPv4 address and start using it? I think it does. I agree with you that this is no substitute for having a routable IP address, but that's not the point. The routable IP address is being *used* as by IPv4ll while it exists. When it goes away, in order to avoid losing *IPv4ll* functionality, the IPv4ll agent needs to go get an IPv4ll address again. Or if there is still an IPv4ll address lying around, the stack needs to start using it, and it needs to be published in LLMNS. From owner-zeroconf@merit.edu Wed Feb 19 16:08:13 2003 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 QAA08863 for ; Wed, 19 Feb 2003 16:08:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0F4C89129C; Wed, 19 Feb 2003 16:11:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA79E9129D; Wed, 19 Feb 2003 16:11:54 -0500 (EST) 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 AAAB39129C for ; Wed, 19 Feb 2003 16:11:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 945425E113; Wed, 19 Feb 2003 16:11:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by segue.merit.edu (Postfix) with ESMTP id 42D9F5E10E for ; Wed, 19 Feb 2003 16:11:53 -0500 (EST) Received: from timepilot.gpcc.itd.umich.edu (timepilot.gpcc.itd.umich.edu [141.211.2.206]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id QAA13793; Wed, 19 Feb 2003 16:11:52 -0500 (EST) Received: from localhost (sgoswami@localhost) by timepilot.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id QAA11581; Wed, 19 Feb 2003 16:11:52 -0500 (EST) Date: Wed, 19 Feb 2003 16:11:52 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@timepilot.gpcc.itd.umich.edu To: Keith Moore Cc: bhards@bigpond.net.au, , Subject: Re: LL27: LL-only hosts In-Reply-To: <20030219155702.3705d118.moore@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, 19 Feb 2003, Keith Moore wrote: > > > Now if this group were trying to publish a BCP that merely allocated a block > > > of IPv4 addresses to be used as LL addresses, without specifying the LL > > > protocol, I'd argue that RFC 1918 is an appropriate precedent. (though many > > > would argue that RFC 1918 was a mistake and that based on experience we should > > > not make another similar mistake). > > > > What is the mistake here you are talking about ? NAT ? > > yes. there is a widespread belief that RFC 1918 encouraged NAT. > Why is the mistake in NAT ? What else was there ? Finally without the private address space IP would have been choked to unuse. > > What is the Internet for you ? > > the set of networks that are connected together using IP. > > What exactly do you mean by using IP ? What addresses, what protocols ? What exactly do you mean by connected together ? My home network is connected togther by IPv4/Ethernet - is it the Internet ? I am begining to think that what you call Internet is not the same as what others think. I do not really know what the term Internet means, if there is any meaning at all. Subrata From owner-zeroconf@merit.edu Wed Feb 19 16:08:32 2003 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 QAA08881 for ; Wed, 19 Feb 2003 16:08:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E42F89129D; Wed, 19 Feb 2003 16:12:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3B4E9129F; Wed, 19 Feb 2003 16:12:14 -0500 (EST) 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 A1C0A9129D for ; Wed, 19 Feb 2003 16:12:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E7ED5E113; Wed, 19 Feb 2003 16:12:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by segue.merit.edu (Postfix) with ESMTP id 6CD1F5DE4C for ; Wed, 19 Feb 2003 16:12:13 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lbVi-0000qt-00; Wed, 19 Feb 2003 13:12:10 -0800 Date: Wed, 19 Feb 2003 16:09:18 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030219160918.10a1a3ab.moore@cs.utk.edu> In-Reply-To: <44262E02-444E-11D7-9530-00039317663C@nominum.com> References: <20030219151230.376bb62a.moore@cs.utk.edu> <44262E02-444E-11D7-9530-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Perhaps a better way to frame this issue is: what happens if the > network stack is configured with a routable IP address, and then later > that address is unconfigured? Does the IPv4ll agent at that point > immediately go out and get an IPv4 address and start using it? the device does whatever it wants to do. LL might or might not be suitable for its purposes. we shouldn't insist that a device configure or use LL when it's attached to a connected network. From owner-zeroconf@merit.edu Wed Feb 19 16:09:09 2003 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 QAA08914 for ; Wed, 19 Feb 2003 16:09:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA9D39129F; Wed, 19 Feb 2003 16:12:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A60B5912A0; Wed, 19 Feb 2003 16:12:50 -0500 (EST) 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 941CF9129F for ; Wed, 19 Feb 2003 16:12:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 736FC5E113; Wed, 19 Feb 2003 16:12:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id B539B5E10E for ; Wed, 19 Feb 2003 16:12:48 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1JLDQaj008340; Wed, 19 Feb 2003 23:13:26 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1JLDPIn008337; Wed, 19 Feb 2003 23:13:25 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: sgoswami@umich.edu, zeroconf@merit.edu In-Reply-To: <20030219154733.76a5f9a7.moore@cs.utk.edu> References: <20030219141815.3d3a8122.moore@cs.utk.edu> <20030219150026.40b191a3.moore@cs.utk.edu> <1045686000.7738.33.camel@devil> <20030219154733.76a5f9a7.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045689204.7734.49.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Feb 2003 23:13:24 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-19 at 22:47, Keith Moore wrote: > if LL nodes aren't going to be connected to the Internet, this group > has no business at all existing in IETF, except perhaps to avoid address > assignment conflicts as in RFC 1918. but the LL protocol would not be in > scope for IETF. > > on the other hand if LL nodes are going to be connected to the Internet, > as is already happening, then IETF clearly has an interest in making sure > that those nodes don't interfere with IP networks more than necessary. > > it's called "damage control". why do you think this group was chartered? Well, if I had to venture a guess I would say this group was chartered to do what the charter states: "The goal of the Zero Configuration Networking (ZEROCONF) Working Group is to enable networking in the absence of configuration and administration. Zero configuration networking is required for environments where administration is impractical or impossible, such as in the home or small office, embedded systems 'plugged together' as in an automobile, or to allow impromptu networks as between the devices of strangers on a train. " Note some of the highlights: "in the absence of configuration and administration" "where administration is impractical or impossible" "embedded systems 'plugged together'" "impromptu networks" You may not agree with the charter but don't try to rewrite it to your liking. Zeroconf exists, therefore it is within IETF scope. Now, I have nothing against considering the issues with connecting to managed networks and I agree that they are relevant, even if not part of the charter. However, let's not step into the realm of the absurd and claim that zeroconf itself is outside the scope of IETF. IP has two key properties: interoperability and link-layer agnosticity. InterNETworking is a byproduct, even if it was a nice buzzword some 20 years ago. MikaL From owner-zeroconf@merit.edu Wed Feb 19 16:15:14 2003 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 QAA08992 for ; Wed, 19 Feb 2003 16:15:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2E5B1912A0; Wed, 19 Feb 2003 16:18:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EBF4A912A1; Wed, 19 Feb 2003 16:18:48 -0500 (EST) 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 0A456912A0 for ; Wed, 19 Feb 2003 16:18:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id C97185DE6F; Wed, 19 Feb 2003 16:18:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by segue.merit.edu (Postfix) with ESMTP id A71645DE4C for ; Wed, 19 Feb 2003 16:18:10 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lbbU-0000up-00; Wed, 19 Feb 2003 13:18:08 -0800 Date: Wed, 19 Feb 2003 16:15:17 -0500 From: Keith Moore To: "s. goswami" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL27: LL-only hosts Message-Id: <20030219161517.70f9b7df.moore@cs.utk.edu> In-Reply-To: References: <20030219155702.3705d118.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Why is the mistake in NAT ? What else was there ? Finally without > the private address space IP would have been choked to unuse. I'll reply in private as this is no longer relevant to this group. From owner-zeroconf@merit.edu Wed Feb 19 16:18:55 2003 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 QAA09020 for ; Wed, 19 Feb 2003 16:18:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2B781912A1; Wed, 19 Feb 2003 16:22:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E90A0912A2; Wed, 19 Feb 2003 16:22:36 -0500 (EST) 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 F3838912A1 for ; Wed, 19 Feb 2003 16:22:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id D9A815E01A; Wed, 19 Feb 2003 16:22:35 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 873535DF6B for ; Wed, 19 Feb 2003 16:22:35 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1JLK4b29953; Wed, 19 Feb 2003 15:20:05 -0600 (CST) Date: Wed, 19 Feb 2003 14:22:35 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "s. goswami" , zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030219154406.6feda977.moore@cs.utk.edu> Message-Id: <438FEA80-4450-11D7-9530-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > ideally LL should have no bearing on connected networks. by tying LL > to DHCP > we avoid many cases where LL would interfere with operation of those > networks, > or of hosts or apps on those networks. You have yet to offer an example of these many cases where LL would interfere with operation of connected networks, so this is not a valid reason to say that we need to tie LL to DHCP. From owner-zeroconf@merit.edu Wed Feb 19 16:19:51 2003 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 QAA09037 for ; Wed, 19 Feb 2003 16:19:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 80814912A2; Wed, 19 Feb 2003 16:23:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 541E5912A3; Wed, 19 Feb 2003 16:23:33 -0500 (EST) 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 5E8AF912A2 for ; Wed, 19 Feb 2003 16:23:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 47FBB5DE6F; Wed, 19 Feb 2003 16:23:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id E90BF5DE4C for ; Wed, 19 Feb 2003 16:23:31 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1JLKtb29962; Wed, 19 Feb 2003 15:20:55 -0600 (CST) Date: Wed, 19 Feb 2003 14:23:24 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Mika Liljeberg , sgoswami@umich.edu, zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030219154733.76a5f9a7.moore@cs.utk.edu> Message-Id: <610219B4-4450-11D7-9530-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > it's called "damage control". why do you think this group was > chartered? In order to create value. Anyway, that's why I'm here. From owner-zeroconf@merit.edu Wed Feb 19 16:22:42 2003 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 QAA09101 for ; Wed, 19 Feb 2003 16:22:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 79994912A3; Wed, 19 Feb 2003 16:26:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D360912A5; Wed, 19 Feb 2003 16:26:25 -0500 (EST) 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 57A39912A3 for ; Wed, 19 Feb 2003 16:26:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3A7EF5DEB2; Wed, 19 Feb 2003 16:26:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id DC8EC5DE6F for ; Wed, 19 Feb 2003 16:26:23 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1JLNtb29971; Wed, 19 Feb 2003 15:23:55 -0600 (CST) Date: Wed, 19 Feb 2003 14:26:26 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu, philip@engarts.com To: Keith Moore From: Ted Lemon In-Reply-To: <20030219160918.10a1a3ab.moore@cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > we shouldn't insist that a device > configure or use LL when it's attached to a connected network. Maybe it's not a connected network anymore. Maybe the reason the configured address went away is that the network connection went away. From owner-zeroconf@merit.edu Wed Feb 19 16:24:36 2003 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 QAA09131 for ; Wed, 19 Feb 2003 16:24:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D9FE5912A5; Wed, 19 Feb 2003 16:28:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A37B4912A6; Wed, 19 Feb 2003 16:28:18 -0500 (EST) 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 895AE912A5 for ; Wed, 19 Feb 2003 16:28:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 659305E006; Wed, 19 Feb 2003 16:28:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by segue.merit.edu (Postfix) with ESMTP id 441295DE4C for ; Wed, 19 Feb 2003 16:28:17 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lblE-0001w1-00; Wed, 19 Feb 2003 13:28:13 -0800 Date: Wed, 19 Feb 2003 16:25:20 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, sgoswami@umich.edu, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030219162520.47ebb34c.moore@cs.utk.edu> In-Reply-To: <1045689204.7734.49.camel@devil> References: <20030219141815.3d3a8122.moore@cs.utk.edu> <20030219150026.40b191a3.moore@cs.utk.edu> <1045686000.7738.33.camel@devil> <20030219154733.76a5f9a7.moore@cs.utk.edu> <1045689204.7734.49.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > it's called "damage control". why do you think this group was chartered? > > Well, if I had to venture a guess there's the stated reason and then there's the real reason. different things. Keith From owner-zeroconf@merit.edu Wed Feb 19 16:27:34 2003 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 QAA09213 for ; Wed, 19 Feb 2003 16:27:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B2EAA912A6; Wed, 19 Feb 2003 16:30:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8484D912A7; Wed, 19 Feb 2003 16:30:32 -0500 (EST) 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 6E719912A6 for ; Wed, 19 Feb 2003 16:30:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id BFD155E006; Wed, 19 Feb 2003 16:30:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by segue.merit.edu (Postfix) with ESMTP id 909065E01A for ; Wed, 19 Feb 2003 16:30:28 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lbnI-0000FB-00; Wed, 19 Feb 2003 13:30:20 -0800 Date: Wed, 19 Feb 2003 16:27:28 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, sgoswami@umich.edu, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030219162728.5f0b75db.moore@cs.utk.edu> In-Reply-To: <438FEA80-4450-11D7-9530-00039317663C@nominum.com> References: <20030219154406.6feda977.moore@cs.utk.edu> <438FEA80-4450-11D7-9530-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > You have yet to offer an example of these many cases where LL would > interfere with operation of connected networks, no, you have yet to listen to them. From owner-zeroconf@merit.edu Wed Feb 19 16:31:37 2003 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 QAA09338 for ; Wed, 19 Feb 2003 16:31:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2F78591261; Wed, 19 Feb 2003 16:35:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF3CE912A7; Wed, 19 Feb 2003 16:35:19 -0500 (EST) 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 E53B091261 for ; Wed, 19 Feb 2003 16:35:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id D23EC5DED1; Wed, 19 Feb 2003 16:35:18 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 7B2F25DDAD for ; Wed, 19 Feb 2003 16:35:17 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1JLZnaj008473; Wed, 19 Feb 2003 23:35:50 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1JLZjWT008472; Wed, 19 Feb 2003 23:35:45 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL27: LL-only hosts From: Mika Liljeberg To: Keith Moore Cc: Markku Savela , zeroconf@merit.edu In-Reply-To: <20030219155144.0440b306.moore@cs.utk.edu> References: <028001c2d808$a78897c0$131010ac@aldebaran> <20030219085851.6851e618.moore@cs.utk.edu> <200302200648.20986.bhards@bigpond.net.au> <20030219152955.7eb5e2aa.moore@cs.utk.edu> <200302192050.h1JKo1mN011714@burp.tkv.asdf.org> <20030219155144.0440b306.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045690544.7738.53.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Feb 2003 23:35:45 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-19 at 22:51, Keith Moore wrote: > another important difference is that > RFC 1918 addresses are not supposed to be used except on isolated networks, That claim is false. RFC1918 divides hosts into different classes based on what type of addresses they need. There is no restriction to use RFC1918 in networks connected to the global internet. MikaL From owner-zeroconf@merit.edu Wed Feb 19 16:32:06 2003 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 QAA09353 for ; Wed, 19 Feb 2003 16:32:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5DC17912A7; Wed, 19 Feb 2003 16:35:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25367912A8; Wed, 19 Feb 2003 16:35:47 -0500 (EST) 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 1D58E912A7 for ; Wed, 19 Feb 2003 16:35:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0ACD85DE6F; Wed, 19 Feb 2003 16:35:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by segue.merit.edu (Postfix) with ESMTP id A1A755DDAD for ; Wed, 19 Feb 2003 16:35:45 -0500 (EST) Received: from timepilot.gpcc.itd.umich.edu (timepilot.gpcc.itd.umich.edu [141.211.2.206]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id QAA16912 for ; Wed, 19 Feb 2003 16:35:45 -0500 (EST) Received: from localhost (sgoswami@localhost) by timepilot.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id QAA16423 for ; Wed, 19 Feb 2003 16:35:44 -0500 (EST) Date: Wed, 19 Feb 2003 16:35:43 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@timepilot.gpcc.itd.umich.edu Cc: zeroconf@merit.edu Subject: Re: LL27: LL-only hosts In-Reply-To: <20030219161517.70f9b7df.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk No, I think it is relevant to undertand what you are trying to convey. Not only the NAT part, but also the Internet part. Till a precise meaning is associated with the term Internet, I do not think we should write a draft based on that. Subrata On Wed, 19 Feb 2003, Keith Moore wrote: > > > Why is the mistake in NAT ? What else was there ? Finally without > > the private address space IP would have been choked to unuse. > > I'll reply in private as this is no longer relevant to this group. > From owner-zeroconf@merit.edu Wed Feb 19 16:34:26 2003 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 QAA09449 for ; Wed, 19 Feb 2003 16:34:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B289D912A8; Wed, 19 Feb 2003 16:38:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8015C912A9; Wed, 19 Feb 2003 16:38:09 -0500 (EST) 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 8056D912A8 for ; Wed, 19 Feb 2003 16:38:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 63A8D5DE6F; Wed, 19 Feb 2003 16:38:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 261C35DE4C for ; Wed, 19 Feb 2003 16:38:07 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1JLcgaj008486; Wed, 19 Feb 2003 23:38:43 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1JLcc4k008485; Wed, 19 Feb 2003 23:38:38 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: sgoswami@umich.edu, zeroconf@merit.edu In-Reply-To: <20030219162520.47ebb34c.moore@cs.utk.edu> References: <20030219141815.3d3a8122.moore@cs.utk.edu> <20030219150026.40b191a3.moore@cs.utk.edu> <1045686000.7738.33.camel@devil> <20030219154733.76a5f9a7.moore@cs.utk.edu> <1045689204.7734.49.camel@devil> <20030219162520.47ebb34c.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045690717.7738.55.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Feb 2003 23:38:37 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-19 at 23:25, Keith Moore wrote: > there's the stated reason and then there's the real reason. different things. They say that reality is a subjective thing. MikaL From owner-zeroconf@merit.edu Wed Feb 19 16:39:02 2003 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 QAA09619 for ; Wed, 19 Feb 2003 16:39:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D951F912A9; Wed, 19 Feb 2003 16:42:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AADEB912AA; Wed, 19 Feb 2003 16:42:43 -0500 (EST) 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 86A6A912A9 for ; Wed, 19 Feb 2003 16:42:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6C5845DED1; Wed, 19 Feb 2003 16:42:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by segue.merit.edu (Postfix) with ESMTP id 4ADBB5DE6F for ; Wed, 19 Feb 2003 16:42:42 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lbz8-0004Dv-00; Wed, 19 Feb 2003 13:42:34 -0800 Date: Wed, 19 Feb 2003 16:39:42 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, msa@burp.tkv.asdf.org, zeroconf@merit.edu Subject: Re: LL27: LL-only hosts Message-Id: <20030219163942.61312a28.moore@cs.utk.edu> In-Reply-To: <1045690544.7738.53.camel@devil> References: <028001c2d808$a78897c0$131010ac@aldebaran> <20030219085851.6851e618.moore@cs.utk.edu> <200302200648.20986.bhards@bigpond.net.au> <20030219152955.7eb5e2aa.moore@cs.utk.edu> <200302192050.h1JKo1mN011714@burp.tkv.asdf.org> <20030219155144.0440b306.moore@cs.utk.edu> <1045690544.7738.53.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > another important difference is that > > RFC 1918 addresses are not supposed to be used except on isolated networks, > > That claim is false. > > RFC1918 divides hosts into different classes based on what type of > addresses they need. There is no restriction to use RFC1918 in networks > connected to the global internet. from RFC 1918, section 3: Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any host outside of the enterprise. From owner-zeroconf@merit.edu Wed Feb 19 16:40:22 2003 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 QAA09658 for ; Wed, 19 Feb 2003 16:40:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1AC36912AA; Wed, 19 Feb 2003 16:44:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D6460912AB; Wed, 19 Feb 2003 16:44:03 -0500 (EST) 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 C4593912AA for ; Wed, 19 Feb 2003 16:44:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id ADB005DE6F; Wed, 19 Feb 2003 16:44:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by segue.merit.edu (Postfix) with ESMTP id 8CCBE5DDC1 for ; Wed, 19 Feb 2003 16:44:02 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lc0W-0001sz-00; Wed, 19 Feb 2003 13:44:00 -0800 Date: Wed, 19 Feb 2003 16:41:08 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030219164108.78d83334.moore@cs.utk.edu> In-Reply-To: References: <20030219160918.10a1a3ab.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > we shouldn't insist that a device > > configure or use LL when it's attached to a connected network. > > Maybe it's not a connected network anymore. Maybe the reason the > configured address went away is that the network connection went away. those are two separate cases. but the argument remains the same. Keith From owner-zeroconf@merit.edu Wed Feb 19 16:42:33 2003 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 QAA09756 for ; Wed, 19 Feb 2003 16:42:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 36527912AE; Wed, 19 Feb 2003 16:45:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3761912AF; Wed, 19 Feb 2003 16:45:56 -0500 (EST) 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 C95DD912AE for ; Wed, 19 Feb 2003 16:45:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF60F5DDB3; Wed, 19 Feb 2003 16:45:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 514395DEC3 for ; Wed, 19 Feb 2003 16:45:48 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1JLkLaj008553; Wed, 19 Feb 2003 23:46:22 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1JLkJ3D008551; Wed, 19 Feb 2003 23:46:19 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL27: LL-only hosts From: Mika Liljeberg To: Keith Moore Cc: msa@burp.tkv.asdf.org, zeroconf@merit.edu In-Reply-To: <20030219163942.61312a28.moore@cs.utk.edu> References: <028001c2d808$a78897c0$131010ac@aldebaran> <20030219085851.6851e618.moore@cs.utk.edu> <200302200648.20986.bhards@bigpond.net.au> <20030219152955.7eb5e2aa.moore@cs.utk.edu> <200302192050.h1JKo1mN011714@burp.tkv.asdf.org> <20030219155144.0440b306.moore@cs.utk.edu> <1045690544.7738.53.camel@devil> <20030219163942.61312a28.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045691179.7738.59.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Feb 2003 23:46:19 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-19 at 23:39, Keith Moore wrote: > > > another important difference is that > > > RFC 1918 addresses are not supposed to be used except on isolated networks, > > > > That claim is false. > > > > RFC1918 divides hosts into different classes based on what type of > > addresses they need. There is no restriction to use RFC1918 in networks > > connected to the global internet. > > from RFC 1918, section 3: > > Private hosts can communicate with all other hosts > inside the enterprise, both public and private. However, they cannot > have IP connectivity to any host outside of the enterprise. A network having a few private hosts in addition to public ones does not equal an isolated network. MikaL From owner-zeroconf@merit.edu Wed Feb 19 16:47:10 2003 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 QAA09831 for ; Wed, 19 Feb 2003 16:47:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9CB5B912AB; Wed, 19 Feb 2003 16:50:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65E26912AC; Wed, 19 Feb 2003 16:50:52 -0500 (EST) 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 47BFD912AB for ; Wed, 19 Feb 2003 16:50:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2519D5DE70; Wed, 19 Feb 2003 16:50:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by segue.merit.edu (Postfix) with ESMTP id 039D85DE6F for ; Wed, 19 Feb 2003 16:50:51 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lc76-0005fl-00; Wed, 19 Feb 2003 13:50:48 -0800 Date: Wed, 19 Feb 2003 16:47:52 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030219164752.7c771d12.moore@cs.utk.edu> In-Reply-To: <1045690717.7738.55.camel@devil> References: <20030219141815.3d3a8122.moore@cs.utk.edu> <20030219150026.40b191a3.moore@cs.utk.edu> <1045686000.7738.33.camel@devil> <20030219154733.76a5f9a7.moore@cs.utk.edu> <1045689204.7734.49.camel@devil> <20030219162520.47ebb34c.moore@cs.utk.edu> <1045690717.7738.55.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > there's the stated reason and then there's the real reason. different > > things. > > They say that reality is a subjective thing. True. But I was on the IESG at the time the group was chatered. You weren't. Of course it's likely that different ADs had different reasons for not objecting to the creation of the WG. But from the NITS BOFs it was obvious that this group was going to be a real headache, and we usually try to avoid headaches except when we think that doing so will create bigger headaches. Sadly, "damage control" is a motivation for a lot of WG approvals. From owner-zeroconf@merit.edu Wed Feb 19 16:53:03 2003 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 QAA09978 for ; Wed, 19 Feb 2003 16:53:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D6DD4912AC; Wed, 19 Feb 2003 16:56:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA724912AD; Wed, 19 Feb 2003 16:56:45 -0500 (EST) 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 A09B8912AC for ; Wed, 19 Feb 2003 16:56:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F3385DEB2; Wed, 19 Feb 2003 16:56:44 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 76A485DE6F for ; Wed, 19 Feb 2003 16:56:43 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1JLvLaj008623; Wed, 19 Feb 2003 23:57:21 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1JLvJBo008621; Wed, 19 Feb 2003 23:57:19 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: zeroconf@merit.edu In-Reply-To: <20030219164752.7c771d12.moore@cs.utk.edu> References: <20030219141815.3d3a8122.moore@cs.utk.edu> <20030219150026.40b191a3.moore@cs.utk.edu> <1045686000.7738.33.camel@devil> <20030219154733.76a5f9a7.moore@cs.utk.edu> <1045689204.7734.49.camel@devil> <20030219162520.47ebb34c.moore@cs.utk.edu> <1045690717.7738.55.camel@devil> <20030219164752.7c771d12.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045691838.7738.65.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 19 Feb 2003 23:57:19 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-02-19 at 23:47, Keith Moore wrote: > > > there's the stated reason and then there's the real reason. different > > > things. > > > > They say that reality is a subjective thing. > > True. But I was on the IESG at the time the group was chatered. You weren't. > > Of course it's likely that different ADs had different reasons for not > objecting to the creation of the WG. But from the NITS BOFs it was obvious > that this group was going to be a real headache, and we usually try to avoid > headaches except when we think that doing so will create bigger headaches. > Sadly, "damage control" is a motivation for a lot of WG approvals. Fair enough. However, having not been there, I'm sure you'll forgive me if I proceed on what is stated. MikaL From owner-zeroconf@merit.edu Wed Feb 19 16:53:20 2003 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 QAA10031 for ; Wed, 19 Feb 2003 16:53:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 27A52912AD; Wed, 19 Feb 2003 16:57:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E32F6912AF; Wed, 19 Feb 2003 16:57:00 -0500 (EST) 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 72D70912AD for ; Wed, 19 Feb 2003 16:56:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6B1FC5DE6F; Wed, 19 Feb 2003 16:56:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by segue.merit.edu (Postfix) with ESMTP id 49AFE5DDAD for ; Wed, 19 Feb 2003 16:56:57 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lcCs-0005MF-00; Wed, 19 Feb 2003 13:56:47 -0800 Date: Wed, 19 Feb 2003 16:53:54 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, msa@burp.tkv.asdf.org, zeroconf@merit.edu Subject: Re: LL27: LL-only hosts Message-Id: <20030219165354.155462cb.moore@cs.utk.edu> In-Reply-To: <1045691179.7738.59.camel@devil> References: <028001c2d808$a78897c0$131010ac@aldebaran> <20030219085851.6851e618.moore@cs.utk.edu> <200302200648.20986.bhards@bigpond.net.au> <20030219152955.7eb5e2aa.moore@cs.utk.edu> <200302192050.h1JKo1mN011714@burp.tkv.asdf.org> <20030219155144.0440b306.moore@cs.utk.edu> <1045690544.7738.53.camel@devil> <20030219163942.61312a28.moore@cs.utk.edu> <1045691179.7738.59.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > from RFC 1918, section 3: > > > > Private hosts can communicate with all other hosts > > inside the enterprise, both public and private. However, they cannot > > have IP connectivity to any host outside of the enterprise. > > A network having a few private hosts in addition to public ones does not > equal an isolated network. true enough. 1918 mostly talks about hosts being isolated, not networks. From owner-zeroconf@merit.edu Wed Feb 19 16:55:28 2003 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 QAA10166 for ; Wed, 19 Feb 2003 16:55:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 304C0912AF; Wed, 19 Feb 2003 16:59:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 059FB912B0; Wed, 19 Feb 2003 16:59:09 -0500 (EST) 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 0E561912AF for ; Wed, 19 Feb 2003 16:59:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id E82A15DE6F; Wed, 19 Feb 2003 16:59:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 9656F5DDB3 for ; Wed, 19 Feb 2003 16:59:08 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1JLuXb00689; Wed, 19 Feb 2003 15:56:34 -0600 (CST) Date: Wed, 19 Feb 2003 14:59:04 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: sgoswami@umich.edu, zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030219162728.5f0b75db.moore@cs.utk.edu> Message-Id: <5CBB9F46-4455-11D7-9530-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> You have yet to offer an example of these many cases where LL would >> interfere with operation of connected networks, > > no, you have yet to listen to them. I heard you say a bunch of stuff, Keith. I spent a substantial effort trying to see if what you were saying was correct. I determined that what you were claiming was not true. I explained why. Not agreeing with you is not the same thing as not listening to you. From owner-zeroconf@merit.edu Wed Feb 19 16:58:41 2003 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 QAA10216 for ; Wed, 19 Feb 2003 16:58:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7485F912B0; Wed, 19 Feb 2003 17:02:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DF45912B1; Wed, 19 Feb 2003 17:02:16 -0500 (EST) 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 29F71912B0 for ; Wed, 19 Feb 2003 17:02:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id F23175DDC1; Wed, 19 Feb 2003 17:02:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by segue.merit.edu (Postfix) with ESMTP id C92355DDB3 for ; Wed, 19 Feb 2003 17:02:14 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lcI8-0007da-00; Wed, 19 Feb 2003 14:02:12 -0800 Date: Wed, 19 Feb 2003 16:59:20 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030219165920.3d6f0e35.moore@cs.utk.edu> In-Reply-To: <5CBB9F46-4455-11D7-9530-00039317663C@nominum.com> References: <20030219162728.5f0b75db.moore@cs.utk.edu> <5CBB9F46-4455-11D7-9530-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > I heard you say a bunch of stuff, Keith. I spent a substantial effort > trying to see if what you were saying was correct. I determined that > what you were claiming was not true. you did no such thing. From owner-zeroconf@merit.edu Wed Feb 19 17:11:02 2003 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 RAA10831 for ; Wed, 19 Feb 2003 17:11:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 139D4912B1; Wed, 19 Feb 2003 17:14:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF273912B2; Wed, 19 Feb 2003 17:14:43 -0500 (EST) 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 C34B6912B1 for ; Wed, 19 Feb 2003 17:14:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id A86955DF01; Wed, 19 Feb 2003 17:14:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 562945DE6F for ; Wed, 19 Feb 2003 17:14:42 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1JMCCb00825; Wed, 19 Feb 2003 16:12:13 -0600 (CST) Date: Wed, 19 Feb 2003 15:14:44 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu, philip@engarts.com To: Keith Moore From: Ted Lemon In-Reply-To: <20030219164108.78d83334.moore@cs.utk.edu> Message-Id: <8CADF780-4457-11D7-9530-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>> we shouldn't insist that a device >>> configure or use LL when it's attached to a connected network. >> >> Maybe it's not a connected network anymore. Maybe the reason the >> configured address went away is that the network connection went away. > > those are two separate cases. but the argument remains the same. If the reasons given to support an argument have been shown to be incomplete, and no additional reasons have been given that complete what is missing, then the argument is invalid. This working group is in the business of producing an IPv4ll draft that works consistently, predictably and reliably. You are saying that we should not specify how an IPv4ll-aware node should operate in a certain situation that we can reasonably expect to occur. You are recommending that we leave it up to the implementor to choose what happens in this case. If we follow your recommendation, the behavior of IPv4ll will be neither consistent nor reliable. From owner-zeroconf@merit.edu Wed Feb 19 17:30:27 2003 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 RAA11234 for ; Wed, 19 Feb 2003 17:30:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 45824912B2; Wed, 19 Feb 2003 17:34:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 150E7912B3; Wed, 19 Feb 2003 17:34:01 -0500 (EST) 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 11474912B2 for ; Wed, 19 Feb 2003 17:34:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC4CF5DDC1; Wed, 19 Feb 2003 17:34:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 9B8685DDC0 for ; Wed, 19 Feb 2003 17:34:00 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1JMVVb01009; Wed, 19 Feb 2003 16:31:31 -0600 (CST) Date: Wed, 19 Feb 2003 15:34:03 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030219165920.3d6f0e35.moore@cs.utk.edu> Message-Id: <3F8D5A51-445A-11D7-9530-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> I heard you say a bunch of stuff, Keith. I spent a substantial >> effort >> trying to see if what you were saying was correct. I determined that >> what you were claiming was not true. > > you did no such thing. Sure I did. You just didn't accept my reasons for disagreeing with you. That's not the same thing. From owner-zeroconf@merit.edu Wed Feb 19 17:33:13 2003 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 RAA11298 for ; Wed, 19 Feb 2003 17:33:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 705B9912B3; Wed, 19 Feb 2003 17:36:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 379F0912B4; Wed, 19 Feb 2003 17:36:56 -0500 (EST) 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 199D2912B3 for ; Wed, 19 Feb 2003 17:36:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 009C05DDC0; Wed, 19 Feb 2003 17:36:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by segue.merit.edu (Postfix) with ESMTP id D3AA85DDB3 for ; Wed, 19 Feb 2003 17:36:54 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lcpe-0003zQ-00; Wed, 19 Feb 2003 14:36:50 -0800 Date: Wed, 19 Feb 2003 17:33:56 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030219173356.1b978a60.moore@cs.utk.edu> In-Reply-To: <8CADF780-4457-11D7-9530-00039317663C@nominum.com> References: <20030219164108.78d83334.moore@cs.utk.edu> <8CADF780-4457-11D7-9530-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > >>> we shouldn't insist that a device > >>> configure or use LL when it's attached to a connected network. > >> > >> Maybe it's not a connected network anymore. Maybe the reason the > >> configured address went away is that the network connection went away. > > > > those are two separate cases. but the argument remains the same. > > If the reasons given to support an argument have been shown to be > incomplete, and no additional reasons have been given that complete > what is missing, then the argument is invalid. you haven't shown the reasons to be incomplete. > This working group is in the business of producing an IPv4ll draft that > works consistently, predictably and reliably. it's not even close, though I'd be happy if it took that task on. > You are saying that we > should not specify how an IPv4ll-aware node should operate in a certain > situation that we can reasonably expect to occur. no, what I'm saying is that the node should not presume that failure to renew a DHCP lease is an indication that a network partitioning has occured, and the WG should not presume that using LL is a useful failure mode for a device even if such a partitioning really did occur. folks should stop trying to impose LL in places where it gets in the way. > You are > recommending that we leave it up to the implementor to choose what > happens in this case. If we follow your recommendation, the behavior > of IPv4ll will be neither consistent nor reliable. the behavior of hsots is not consistent. different hosts serve different purposes. the behavior of hosts in response to network failures will also need to vary depending on the needs of that host and the apps that it supports. Keith From owner-zeroconf@merit.edu Wed Feb 19 17:37:12 2003 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 RAA11350 for ; Wed, 19 Feb 2003 17:37:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5700B912B4; Wed, 19 Feb 2003 17:40:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2476A912B5; Wed, 19 Feb 2003 17:40:55 -0500 (EST) 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 14943912B4 for ; Wed, 19 Feb 2003 17:40:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id F3C375DF2C; Wed, 19 Feb 2003 17:40:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by segue.merit.edu (Postfix) with ESMTP id D31A75DEF0 for ; Wed, 19 Feb 2003 17:40:53 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lctV-0004rK-00; Wed, 19 Feb 2003 14:40:49 -0800 Date: Wed, 19 Feb 2003 17:37:57 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030219173757.76cae93b.moore@cs.utk.edu> In-Reply-To: <3F8D5A51-445A-11D7-9530-00039317663C@nominum.com> References: <20030219165920.3d6f0e35.moore@cs.utk.edu> <3F8D5A51-445A-11D7-9530-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > >> I heard you say a bunch of stuff, Keith. I spent a substantial > >> effort > >> trying to see if what you were saying was correct. I determined that > >> what you were claiming was not true. > > > > you did no such thing. > > Sure I did. bullshit. I know the code I work with, I know the problems it has with scoped addresses. you don't know what the hell you're talking about. Keith From owner-zeroconf@merit.edu Wed Feb 19 17:39:14 2003 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 RAA11390 for ; Wed, 19 Feb 2003 17:39:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3AA89912B5; Wed, 19 Feb 2003 17:42:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04186912B7; Wed, 19 Feb 2003 17:42:56 -0500 (EST) 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 00565912B5 for ; Wed, 19 Feb 2003 17:42:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id DD6B25DF6B; Wed, 19 Feb 2003 17:42:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by segue.merit.edu (Postfix) with ESMTP id 793B15DE0B for ; Wed, 19 Feb 2003 17:42:55 -0500 (EST) Received: from timepilot.gpcc.itd.umich.edu (timepilot.gpcc.itd.umich.edu [141.211.2.206]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id RAA23754; Wed, 19 Feb 2003 17:42:28 -0500 (EST) Received: from localhost (sgoswami@localhost) by timepilot.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id RAA00046; Wed, 19 Feb 2003 17:42:28 -0500 (EST) Date: Wed, 19 Feb 2003 17:42:28 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@timepilot.gpcc.itd.umich.edu To: Keith Moore Cc: Mika Liljeberg , , Subject: Re: LL27: LL-only hosts In-Reply-To: <20030219165354.155462cb.moore@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, 19 Feb 2003, Keith Moore wrote: > > > > from RFC 1918, section 3: > > > > > > Private hosts can communicate with all other hosts > > > inside the enterprise, both public and private. However, they cannot > > > have IP connectivity to any host outside of the enterprise. > > > > A network having a few private hosts in addition to public ones does not > > equal an isolated network. > > true enough. 1918 mostly talks about hosts being isolated, not networks. > > RFC 1918 is a BCP, not Internet Standard, hence non-binding. Similarly RFC3022 for NAT is an Informatioanl RFC. So it is left to the user community to determine what to use what not to use. Whereas RFC1918 does not categorically preclude NAT, it allows one to have ALG's. In a generic way NAT's are ALG's, where payloads are left intact and IP headers are slightly modified. It looks to me that RFC1918 does a good deal of hand waving with ALG's. Also RFC1918 came in February 1996, whereas NAT became an RFC in May 1994. Looks like a classic example of "Ex Post Facto Law". Take the following staemet in RFC1918 Section 3. "Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any external host." What this statement seem to convey is that if I need to access the Web from my desk I will either have to have 2 networks or physically move my computer to a second, public network. Absurd requirements ! Subrata From owner-zeroconf@merit.edu Wed Feb 19 18:06:17 2003 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 SAA12117 for ; Wed, 19 Feb 2003 18:06:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C47B91272; Wed, 19 Feb 2003 18:10:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F01479127E; Wed, 19 Feb 2003 18:09:59 -0500 (EST) 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 0644191272 for ; Wed, 19 Feb 2003 18:09:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id DDAFD5DE3E; Wed, 19 Feb 2003 18:09:58 -0500 (EST) 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 ABC645DDC0 for ; Wed, 19 Feb 2003 18:09:58 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id A8DCC598EB for ; Wed, 19 Feb 2003 23:10:02 +0000 (GMT) Message-ID: <00bf01c2d86c$30ca3120$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <20030219164108.78d83334.moore@cs.utk.edu><8CADF780-4457-11D7-9530-00039317663C@nominum.com> <20030219173356.1b978a60.moore@cs.utk.edu> Subject: Re: LL1, LL23 Date: Wed, 19 Feb 2003 23:11:10 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Keith Moore" > > no, what I'm saying is that the node should not presume that failure > to renew a DHCP lease is an indication that a network partitioning has > occured, and the WG should not presume that using LL is a useful failure > mode for a device even if such a partitioning really did occur. > > folks should stop trying to impose LL in places where it gets in the way. There is no chance of imposing LL. Compliance with v4LL is not going to be obligatory and configuration and use of a LL address is certainly optional even if you are LL aware. However, for those who would prefer a LL address to no functional address at all, there is nothing in the document - not even vague guidance - as to when you might start to consider starting to use v4LL. Philip From owner-zeroconf@merit.edu Wed Feb 19 18:09:31 2003 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 SAA12183 for ; Wed, 19 Feb 2003 18:09:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7A9C09127E; Wed, 19 Feb 2003 18:13:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A43F912B7; Wed, 19 Feb 2003 18:13:14 -0500 (EST) 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 4E8209127E for ; Wed, 19 Feb 2003 18:13:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1A7985DF2C; Wed, 19 Feb 2003 18:13:13 -0500 (EST) 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 D79D65DF0F for ; Wed, 19 Feb 2003 18:13:12 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 0E33259A0D for ; Wed, 19 Feb 2003 23:13:17 +0000 (GMT) Message-ID: <00df01c2d86c$a4addb00$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <02c901c2d812$cfd9e5d0$131010ac@aldebaran> <20030219123309.32482dde.moore@cs.utk.edu> Subject: Re: LL1, LL23 Date: Wed, 19 Feb 2003 23:14:24 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Keith Moore" > > > Neither option directly tackles the more difficult issue of transition from > > configured to zero-config > > this is an interesting case. IMHO it should only happen when a network is > losing its external address prefix, or by explicit decision of the network > admin. if the routable addresses remain valid (i.e. they're not being > reassigned) it's better for the network to use routable addresses (even if > the network is isolated) than to use LL addresses. It could easily happen when your NAT router with DHCP server goes down or is unplugged. Those DHCP leases will run out eventually. The case where you unplug from one network and plug into another is closely related to this. It is a transition from one state to another which might be zero-config. If you have been running in zero-config mode, the requirement to periodically try DHCP will ensure a transition. If you have been running configured, there is nothing to trigger a reconfiguration and no guideline in the document so say when it is OK to start trying for LL again. Waiting till your lease runs out and you fail to renew it could be a long time. That is OK if your address continues to work for that time but this won't necessarily be the case. These are both cases of detecting the absence of valid configuration which is harder than detecting its presence - what makes you start? how long do you try for? Philip From owner-zeroconf@merit.edu Wed Feb 19 18:21:21 2003 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 SAA12509 for ; Wed, 19 Feb 2003 18:21:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F1782912A4; Wed, 19 Feb 2003 18:25:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6DE6912B7; Wed, 19 Feb 2003 18:25:03 -0500 (EST) 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 527F8912A4 for ; Wed, 19 Feb 2003 18:25:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F8565DFE5; Wed, 19 Feb 2003 18:25:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by segue.merit.edu (Postfix) with ESMTP id 1E06E5DDC0 for ; Wed, 19 Feb 2003 18:25:01 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ldaA-0001tD-00; Wed, 19 Feb 2003 15:24:55 -0800 Date: Wed, 19 Feb 2003 18:22:02 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030219182202.15f8da1c.moore@cs.utk.edu> In-Reply-To: <00bf01c2d86c$30ca3120$131010ac@aldebaran> References: <20030219164108.78d83334.moore@cs.utk.edu> <8CADF780-4457-11D7-9530-00039317663C@nominum.com> <20030219173356.1b978a60.moore@cs.utk.edu> <00bf01c2d86c$30ca3120$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > no, what I'm saying is that the node should not presume that failure > > to renew a DHCP lease is an indication that a network partitioning has > > occured, and the WG should not presume that using LL is a useful failure > > mode for a device even if such a partitioning really did occur. > > > > folks should stop trying to impose LL in places where it gets in the way. > > There is no chance of imposing LL. Compliance with v4LL is not going to be > obligatory LL is already being imposed on people who buy windows or mac boxes (which is to say, the vast majority of computer users) and the networks that these boxes connect to. the least we can do is try to standardize LL in such a way as to minimize problems. (apparently vendors have already tried to do that, by favoring DHCP over LL, and I'm glad they did that) > and configuration and use of a LL address is certainly optional > even if you are LL aware. not in the current document it isn't. > However, for those who would prefer a LL address to no functional address at > all, there is nothing in the document - not even vague guidance - as to when > you might start to consider starting to use v4LL. this is not a decision that can be made at this level of granularity. since scoped addresses break some apps and isolation breaks others, whether or not to use LL should be an application-specific choice. similarly, whether or not to attempt to recover from DHCP failure by using LL is an application-specific choice. currently neither the host nor the app has any way of knowing whether the DHCP failure is a server failure, a network partitioning, or a network reconfiguration - but a given app may want to deal with each of these in different ways. at least the app implementor knows the consequences of making the wrong choice for his app. the OS implementor has no idea what those consequences are for the apps on that host. Keith From owner-zeroconf@merit.edu Wed Feb 19 18:51:24 2003 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 SAA13075 for ; Wed, 19 Feb 2003 18:51:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 356E1912B7; Wed, 19 Feb 2003 18:55:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2BEE912B8; Wed, 19 Feb 2003 18:55:04 -0500 (EST) 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 E8E90912B7 for ; Wed, 19 Feb 2003 18:55:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id CACDA5E01A; Wed, 19 Feb 2003 18:55:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 4A8AE5DFFA for ; Wed, 19 Feb 2003 18:55:03 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1JNqVb01748; Wed, 19 Feb 2003 17:52:33 -0600 (CST) Date: Wed, 19 Feb 2003 16:55:03 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Zeroconf Working Group" To: "Philip Nye" From: Ted Lemon In-Reply-To: <00df01c2d86c$a4addb00$131010ac@aldebaran> Message-Id: <907EC2A6-4465-11D7-9530-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Waiting till your lease runs out and you fail to renew it could be a > long > time. That is OK if your address continues to work for that time but > this > won't necessarily be the case. Actually, as long as you have a valid routable IP address, you can continue to use that address for IPv4ll, so that's not a problem. If you are connected to a network and get an IP address from a DHCP server, and then are plugged into another network with no DHCP server, you will be able to interoperate with IPv4ll-aware nodes on that network, as long as those nodes have not been configured with non-IPv4ll IP addresses. There _is_ the problem of doing IPv4ll with your routable IPv4 address when you move to another network on which there is a DHCP server that just won't talk to you. There's also the problem of doing IPv4ll once your lease on your routable address expires, in the case that you are connected to a network where only IPv4ll is supported. Adoption of LL1 breaks the first case. Adoption of LL23 breaks the second case. From owner-zeroconf@merit.edu Wed Feb 19 19:02:13 2003 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 TAA13255 for ; Wed, 19 Feb 2003 19:02:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1F50B912B8; Wed, 19 Feb 2003 19:05:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5021912B9; Wed, 19 Feb 2003 19:05:54 -0500 (EST) 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 DF779912B8 for ; Wed, 19 Feb 2003 19:05:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id CCEE85DFE5; Wed, 19 Feb 2003 19:05:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 4B02D5DF83 for ; Wed, 19 Feb 2003 19:05:53 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1K03Lb01839; Wed, 19 Feb 2003 18:03:21 -0600 (CST) Date: Wed, 19 Feb 2003 17:05:54 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Philip Nye" , zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030219182202.15f8da1c.moore@cs.utk.edu> Message-Id: <1421FC2E-4467-11D7-9530-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > this is not a decision that can be made at this level of granularity. > since > scoped addresses break some apps and isolation breaks others, whether > or not > to use LL should be an application-specific choice. similarly, > whether or > not to attempt to recover from DHCP failure by using LL is an > application-specific choice. currently neither the host nor the app > has > any way of knowing whether the DHCP failure is a server failure, a > network > partitioning, or a network reconfiguration - but a given app may want > to > deal with each of these in different ways. at least the app > implementor > knows the consequences of making the wrong choice for his app. the OS > implementor has no idea what those consequences are for the apps on > that host. Earlier you were saying that you think the application shouldn't have to be aware of whether it is using an IPv4ll address or a non-scoped address. Here it seems like what you are saying is that an app that needs to care which kind of address gets used (e.g., one that is doing a referral) is going to _have_ to make the decision itself - there is no way the O.S. can make the decision for it. Am I understanding you correctly? From owner-zeroconf@merit.edu Wed Feb 19 19:06:40 2003 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 TAA13482 for ; Wed, 19 Feb 2003 19:06:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9D032912B9; Wed, 19 Feb 2003 19:10:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6261D912BC; Wed, 19 Feb 2003 19:10:22 -0500 (EST) 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 52B47912B9 for ; Wed, 19 Feb 2003 19:10:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 407035DFE5; Wed, 19 Feb 2003 19:10:21 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by segue.merit.edu (Postfix) with ESMTP id 1DD955DF83 for ; Wed, 19 Feb 2003 19:10:21 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18leI4-0002BZ-00; Wed, 19 Feb 2003 16:10:17 -0800 Date: Wed, 19 Feb 2003 19:07:23 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030219190723.31c9a550.moore@cs.utk.edu> In-Reply-To: <907EC2A6-4465-11D7-9530-00039317663C@nominum.com> References: <00df01c2d86c$a4addb00$131010ac@aldebaran> <907EC2A6-4465-11D7-9530-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > Waiting till your lease runs out and you fail to renew it could be a > > long time. That is OK if your address continues to work for that time but > > this won't necessarily be the case. > > Actually, as long as you have a valid routable IP address, you can > continue to use that address for IPv4ll, so that's not a problem. > If you are connected to a network and get an IP address from a DHCP > server, and then are plugged into another network with no DHCP server, > you will be able to interoperate with IPv4ll-aware nodes on that > network, as long as those nodes have not been configured with > non-IPv4ll IP addresses. ...and as long as apps on those nodes don't try to use your IP address in referrals to other nodes. i.e. it might work in a pinch but you shouldn't depend on it. somehow I don't think this WG is going to solve all of the problems that can crop up when DHCP servers fail, networks renumber abruptly, or hosts move from one network to another - whether or not LL is involved. Keith From owner-zeroconf@merit.edu Wed Feb 19 19:14:55 2003 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 TAA13687 for ; Wed, 19 Feb 2003 19:14:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1BAF1912BA; Wed, 19 Feb 2003 19:18:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D748D912BC; Wed, 19 Feb 2003 19:18:28 -0500 (EST) 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 73813912BA for ; Wed, 19 Feb 2003 19:17:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F48C5DF01; Wed, 19 Feb 2003 19:17:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by segue.merit.edu (Postfix) with ESMTP id 2453F5DDD0 for ; Wed, 19 Feb 2003 19:17:40 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lePA-0006hg-00; Wed, 19 Feb 2003 16:17:37 -0800 Date: Wed, 19 Feb 2003 19:14:44 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030219191444.629e94a6.moore@cs.utk.edu> In-Reply-To: <1421FC2E-4467-11D7-9530-00039317663C@nominum.com> References: <20030219182202.15f8da1c.moore@cs.utk.edu> <1421FC2E-4467-11D7-9530-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Earlier you were saying that you think the application shouldn't have > to be aware of whether it is using an IPv4ll address or a non-scoped > address. not sure what context you are referring to. no, I don't think apps should have to special-case handling of addresses. and yet scoped addresses work differently than globals. so if scoped addresses exist, it's unavoidable that some apps are going to need to deal with them. some apps will deal with LL by trying to avoid using LL addresses, some will go to elaborate means to try to make things work in a mixture of LL and routable addresses, and some apps can be blissfully ignorant of LL and work about as well as they ever did. > Here it seems like what you are saying is that an app that > needs to care which kind of address gets used (e.g., one that is doing > a referral) is going to _have_ to make the decision itself - there is > no way the O.S. can make the decision for it. Am I understanding you > correctly? yes, I think you're understanding at least part of what I'm saying. note that there are multiple decisions here - whether to listen to an LL address, whether to send to an LL address, whether to use an LL address as a source address (by explicitly binding either an LL or another address to the local end of the socket), whether to send a referral containing an LL address, and whether to try to use LL addresses for some of these purposes when routable addresses cease to work. and there's no way (at least with current APIs) that the OS can reasonably make these decisions on an app's behalf. Keith From owner-zeroconf@merit.edu Wed Feb 19 22:51:11 2003 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 WAA18297 for ; Wed, 19 Feb 2003 22:51:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0F34A912BF; Wed, 19 Feb 2003 22:54:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB071912BE; Wed, 19 Feb 2003 22:54:52 -0500 (EST) 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 C80DB912BD for ; Wed, 19 Feb 2003 22:54:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id AEC3A5DE16; Wed, 19 Feb 2003 22:54:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by segue.merit.edu (Postfix) with ESMTP id 8CD9F5DDC7 for ; Wed, 19 Feb 2003 22:54:51 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lhnI-00078o-00; Wed, 19 Feb 2003 19:54:44 -0800 Date: Wed, 19 Feb 2003 22:51:51 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030219225151.5c3d3e2f.moore@cs.utk.edu> In-Reply-To: <22DA342F-446F-11D7-9530-00039317663C@nominum.com> References: <20030219190723.31c9a550.moore@cs.utk.edu> <22DA342F-446F-11D7-9530-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > somehow I don't think this WG is going to solve all of the problems > > that can crop up when DHCP servers fail, networks renumber abruptly, or > > hosts move from one network to another - whether or not LL is involved. > > No, we definitely can't. But that's not what we're trying to do, so > it's okay. But is _is_ possible to write the document so that IPv4ll > connectivity isn't prevented in cases where it doesn't need to be. I'm not sure that it is possible to do so in all cases without making some fairly bogus assumptions about the nature of failures. Keith From owner-zeroconf@merit.edu Wed Feb 19 22:52:27 2003 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 WAA18316 for ; Wed, 19 Feb 2003 22:52:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 273A8912BD; Wed, 19 Feb 2003 22:56:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E4C53912BE; Wed, 19 Feb 2003 22:56:01 -0500 (EST) 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 C0D30912BD for ; Wed, 19 Feb 2003 22:56:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id A8DA75E099; Wed, 19 Feb 2003 22:56:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 568495DEC8 for ; Wed, 19 Feb 2003 22:56:00 -0500 (EST) Received: from nominum.com (a33.pm3-67.theriver.com [206.25.48.225]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1K3mFN03438; Wed, 19 Feb 2003 21:48:15 -0600 (CST) Date: Wed, 19 Feb 2003 18:03:34 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: philip@engarts.com, zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030219190723.31c9a550.moore@cs.utk.edu> Message-Id: <22DA342F-446F-11D7-9530-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > ...and as long as apps on those nodes don't try to use your IP address > in referrals to other nodes. i.e. it might work in a pinch but > you shouldn't depend on it. Yup. If you only have link-local connectivity, you can't communicate off the link. And the case where you have an invalid IP address for network to which you're connected, if you have a mix of devices with link-local and non-link-local addresses, you won't be able to communicate with the devices that have non-link-local addresses either directly or by referral. > somehow I don't think this WG is going to solve all of the problems > that > can crop up when DHCP servers fail, networks renumber abruptly, or > hosts > move from one network to another - whether or not LL is involved. No, we definitely can't. But that's not what we're trying to do, so it's okay. But is _is_ possible to write the document so that IPv4ll connectivity isn't prevented in cases where it doesn't need to be. From owner-zeroconf@merit.edu Thu Feb 20 04:33:59 2003 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 EAA05391 for ; Thu, 20 Feb 2003 04:33:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C44E09121B; Thu, 20 Feb 2003 04:37:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E0C69121E; Thu, 20 Feb 2003 04:37:41 -0500 (EST) 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 9C40E9121B for ; Thu, 20 Feb 2003 04:37:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C54B5DFB2; Thu, 20 Feb 2003 04:37:40 -0500 (EST) 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 482155DDA7 for ; Thu, 20 Feb 2003 04:37:40 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 258CF599EC for ; Thu, 20 Feb 2003 09:37:41 +0000 (GMT) Message-ID: <004801c2d8c3$e0f80c50$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <00df01c2d86c$a4addb00$131010ac@aldebaran><907EC2A6-4465-11D7-9530-00039317663C@nominum.com> <20030219190723.31c9a550.moore@cs.utk.edu> Subject: Re: LL1, LL23 Date: Thu, 20 Feb 2003 09:38:52 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Keith Moore" > somehow I don't think this WG is going to solve all of the problems that > can crop up when DHCP servers fail, networks renumber abruptly, or hosts > move from one network to another - whether or not LL is involved. This group is chartered to provide a LL configuration scheme which provides functionality in ad-hoc networks. If the requirements of an irrelevant administered network to which a host is no longer connected can obstruct this, it is clearly something which the spec should fix if it can. Philip From owner-zeroconf@merit.edu Thu Feb 20 04:47:06 2003 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 EAA05649 for ; Thu, 20 Feb 2003 04:47:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D5DCE9121E; Thu, 20 Feb 2003 04:50:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9985491222; Thu, 20 Feb 2003 04:50:48 -0500 (EST) 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 916799121E for ; Thu, 20 Feb 2003 04:50:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6EC9B5DDA7; Thu, 20 Feb 2003 04:50:47 -0500 (EST) 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 1A4FA5DD9D for ; Thu, 20 Feb 2003 04:50:47 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id E5010599E9 for ; Thu, 20 Feb 2003 09:50:47 +0000 (GMT) Message-ID: <005501c2d8c5$b5e5ac00$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <907EC2A6-4465-11D7-9530-00039317663C@nominum.com> Subject: Re: LL1, LL23 Date: Thu, 20 Feb 2003 09:51:58 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Ted Lemon" > > There _is_ the problem of doing IPv4ll with your routable IPv4 address > when you move to another network on which there is a DHCP server that > just won't talk to you. There's also the problem of doing IPv4ll once > your lease on your routable address expires, in the case that you are > connected to a network where only IPv4ll is supported. > > Adoption of LL1 breaks the first case. Adoption of LL23 breaks the > second case. There is also the problem of a handful of people who bring their laptops from their various company networks and try and set up an ad hoc network in a conference room. Each might have a different "valid" configuration and each _could_ talk using LL rules if only they knew those other addresses were on the same link. But since none of them are 169.254 addresses they can't. The presumption in allowing configured addresses to talk directly with LL addresses has always been that those configured addresses are sensible and that they can talk with each other without any help from LL. But this breaks down when previously condigured devices are thrown together in a new ad-hoc network. This doesn't necessarily mean that a device has been physically moved or power cycled. I can see that some of these issues are out of scope for LL but it seems to be a hole in the spec that it somehow assumes that you are always starting the configuration process from a clean slate - when in fact this is frequently not the case. Would adding something like this be pertinent? "If a host loses its configured address (e.g. by lease expiry) or has reason to believe that its configured address is no longer working (e.g. from media sense), it MAY test the network configuration (e.g. using ARP) to see if its default route or any other applicable route is still reachable. If it is unable to reach any configured routers the host MAY recommence the LL configuration scheme from the start." Philip From owner-zeroconf@merit.edu Thu Feb 20 05:01:39 2003 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 FAA05938 for ; Thu, 20 Feb 2003 05:01:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AD89091212; Thu, 20 Feb 2003 05:05:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D5E691222; Thu, 20 Feb 2003 05:05:21 -0500 (EST) 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 91AB191212 for ; Thu, 20 Feb 2003 05:05:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7BDEA5DE9B; Thu, 20 Feb 2003 05:05:20 -0500 (EST) 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 EF2805DD9D for ; Thu, 20 Feb 2003 05:05:19 -0500 (EST) 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 DAA13981; Thu, 20 Feb 2003 03:05:18 -0700 (MST) 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 h1KA5Gl06651; Thu, 20 Feb 2003 11:05:17 +0100 (MET) Date: Thu, 20 Feb 2003 11:05:15 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Keith Moore Cc: Erik Guttman , zeroconf@merit.edu Subject: Re: [LL10] Add warnings to applicability statement In-Reply-To: <20030217154608.777b171b.moore@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, 17 Feb 2003, Keith Moore wrote: > > I would like to see an analysis for IPP, HTTP, NFS, SIP, SMTP > > and perhaps LDAP for cases where I want to consider the applications which folks in environments without lots of administrators are likely to use. IMO: File sharing and print sharing are the 'classic' desktop networking applications. Email and web browsing are the 'big applications' of the Internet. Internet telephony and directory access are likely to be the next big applications. Do you have any additional suggestions or issues with that list? Erik From owner-zeroconf@merit.edu Thu Feb 20 08:03:45 2003 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 IAA11397 for ; Thu, 20 Feb 2003 08:03:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0490891234; Thu, 20 Feb 2003 08:07:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE5C59123A; Thu, 20 Feb 2003 08:07:25 -0500 (EST) 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 C47AB91234 for ; Thu, 20 Feb 2003 08:07:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id B4A105E123; Thu, 20 Feb 2003 08:07:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 8A31D5DF4A for ; Thu, 20 Feb 2003 08:07:10 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1KD74d20669; Thu, 20 Feb 2003 20:07:04 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1KD6k114641; Thu, 20 Feb 2003 20:06:46 +0700 (ICT) From: Robert Elz To: Ted Lemon Cc: "Philip Nye" , "Zeroconf Working Group" Subject: Re: LL1, LL23 In-Reply-To: <907EC2A6-4465-11D7-9530-00039317663C@nominum.com> <005501c2d8c5$b5e5ac00$131010ac@aldebaran> References: <907EC2A6-4465-11D7-9530-00039317663C@nominum.com> <005501c2d8c5$b5e5ac00$131010ac@aldebaran> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Feb 2003 20:06:46 +0700 Message-ID: <14639.1045746406@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 19 Feb 2003 16:55:03 -0700 From: Ted Lemon Message-ID: <907EC2A6-4465-11D7-9530-00039317663C@nominum.com> | There _is_ the problem of doing IPv4ll with your routable IPv4 address | when you move to another network on which there is a DHCP server that | just won't talk to you. There's also the problem of doing IPv4ll once | your lease on your routable address expires, in the case that you are | connected to a network where only IPv4ll is supported. | | Adoption of LL1 breaks the first case. Adoption of LL23 breaks the | second case. LL23 is not intended to break the second case. If it needs more words to make that clear, suggest what they should be. If a node which has had a routable address ceases to have one, then it can start the whole allocation process again (just as it did before LL addresses were invented). If that fails, there's no reason it cannot acquire an LL address for itself (or resume using one it had previously acquired). [Aside: note that LL23 does not say that a host should stop defending its LL address, so once having acquire it, it will retain it in most cases. It also doesn't say, but in this case probably should, that if some other node usurps a LL address that is "dormant" the node should just forget it ever existed, and not go allocate another - or not until working routable addresses fail]. Philip Nye said: | Would adding something like this be pertinent? | | "If a host loses its configured address (e.g. by lease expiry) or has reason | to believe that its configured address is no longer working (e.g. from media | sense), it MAY test the network configuration (e.g. using ARP) to see if its | default route or any other applicable route is still reachable. If it is | unable to reach any configured routers the host MAY recommence the LL | configuration scheme from the start." No problem with that, but I'm not sure it is needed. That is, I wold have thought that to be obvious - nothing from outside can ever tell what is going on inside a host, it can decide that it wants to attempt to re-validate its lease whenever it feels inclined (for all the outside world knows, it may have just crashed and rebooted). Doing so because it has tested its net configuration and not liked the results seems like an intelligent idea. If the host believes that it may have moved networks (because the link has gone done and reappeared) ought probably just go re-validate its lease without bothering with the extra ARP (not that that is costly, as in most cases it can be a unicast request, or can at least start that way). kre From owner-zeroconf@merit.edu Thu Feb 20 08:03:59 2003 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 IAA11417 for ; Thu, 20 Feb 2003 08:03:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C3F559123A; Thu, 20 Feb 2003 08:07:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91C1791249; Thu, 20 Feb 2003 08:07:36 -0500 (EST) 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 6F5BA9123A for ; Thu, 20 Feb 2003 08:07:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1634D5E123; Thu, 20 Feb 2003 08:07:33 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 81B3D5DF4A for ; Thu, 20 Feb 2003 08:07:31 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1KD76d20697; Thu, 20 Feb 2003 20:07:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1JIHd108495; Thu, 20 Feb 2003 01:17:39 +0700 (ICT) From: Robert Elz To: Bernard Aboba Cc: zeroconf@merit.edu Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Feb 2003 01:17:39 +0700 Message-ID: <8493.1045678659@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 19 Feb 2003 07:01:46 -0800 (PST) From: Bernard Aboba Message-ID: | So the idea is to use this option in a scenario where DHCPv4 is being used | (otherwise the option would not be helpful) but where the DHCPv4 server is | not assigning addresses? Not assigning addresses to particular clients on particular LANs. | This doesn't seem like a very mainstream scenario. More than you might think. | Maybe it's just me, but I don't know many instances where DHCPv4 is | supported where the intent is *not* to assign IP addresses. I do that all the time. I see lots of queries on lists from others who want to do just the same, and are attempting to work out how. That is, host A is allocated an address on LAN X, but not on LAN Y. Without LL addresses, one simply uses the (ISC) dhcp server "ignore booting" (or "deny") (or some equivalent from some other server), the server ignores the client, which then gets no address. At this point it can do whatever is appropriate for a node of its type with no addresses. With LL addresses, the node still gets no routable address, but lacking any extra mechanism, now assigns itself a LL address, and acts as if it is on a disconnected LAN (ie: some stuff works, perhaps, other stuff doesn't). Having a node tell its user (one way or another) "No network address available" is something I can cope with, they tell me that, and I can either fix the problem, or tell them what they did wrong. On the other hand, when they tell me "the network works OK, but I can't reach ebay" (or google or whatever) - most likely the only external address they have tried, I start looking at other potential problems. | If such an | option is used, it would definitely seem to require authenticated DHCP, or | else it would create a security vulnerability. No. We have been through all of this before. This option, itself, is no more of a security problem than DHCP itself. Authenticated DHCP is useful (or not) on its own merits for general DHCP usage. (Authenticated DHCP in a zeroconf environment seems a little unlikely to me though.) If anything, the 2563 option is "better" than raw DHCP in this area, as a client can easily ignore a bogus server sending such an option, and accept an address from the real server clients always get to choose which offer of several to accept), whereas it cannot easily ignore a bogus server giving out what looks like a normal routable address (which just doesn't work) because it has no idea which response is bogus and which is not. | "Achieve the same result" means trying to make sure that the hosts in an | organization have no IP addresses? Some hosts, on some LANs. Plug your system into LAN A where it belongs, and you get an address, plug into LAN B where it doesn't, and you don't. | Why use DHCP to achieve that result (except by accident)? Because that's how DHCP has always been (able to be) used. kre From owner-zeroconf@merit.edu Thu Feb 20 09:17:57 2003 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 JAA15280 for ; Thu, 20 Feb 2003 09:17:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9142C91257; Thu, 20 Feb 2003 09:21:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60EAE9125C; Thu, 20 Feb 2003 09:21:38 -0500 (EST) 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 4CCEC91257 for ; Thu, 20 Feb 2003 09:21:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3317C5DD9D; Thu, 20 Feb 2003 09:21:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9CD8C5DE2D for ; Thu, 20 Feb 2003 09:21:36 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1KCt5w14680; Thu, 20 Feb 2003 04:55:05 -0800 Date: Thu, 20 Feb 2003 04:55:05 -0800 (PST) From: Bernard Aboba To: Robert Elz Cc: zeroconf@merit.edu Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL In-Reply-To: <8493.1045678659@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > Having a node tell its user (one way or another) "No network address > available" is something I can cope with, they tell me that, and I can > either fix the problem, or tell them what they did wrong. On the > other hand, when they tell me "the network works OK, but I can't reach > ebay" (or google or whatever) - most likely the only external address > they have tried, I start looking at other potential problems. You are effectively using DHCP as a form of LAN access control. I don't believe that this is one of the intended uses of this protocol, so that adding RFC 2563 as a requirement to better enable an unsupported use of DHCP seems like a bad decision. If you want LAN access control, including error messages sent when hosts fail to authenticate (or even when they don't authenticate at all, but are unauthorized on LAN X but not LAN Y), you can use IEEE 802.1X instead. > No. We have been through all of this before. This option, itself, > is no more of a security problem than DHCP itself. I would claim that any option that can disable a host in a substantial way should require DHCP authentication. Preventing host IP address assignment on a given network is one of those things. > Authenticated DHCP in a zeroconf environment seems a little unlikely to > me though.) The scenario you described is not a zeroconf scenario. It is a scenario in which an admin attempts to use DHCP for access control. > anything, the 2563 option is "better" than raw DHCP in this area, as a client > can easily ignore a bogus server sending such an option, and accept an address > from the real server Show me an example of a host that actually operates this way. I don't know of any. > Some hosts, on some LANs. Plug your system into LAN A where it belongs, > and you get an address, plug into LAN B where it doesn't, and you don't. Great, so you don't get an IP address -- but you still have connectivity to AppleTalk, IPX, and NetBEUI. If the operation that the user is doing happens to activate one of those protocols, things will still work. So does this accomplish the goal of controlling access to the network? From owner-zeroconf@merit.edu Thu Feb 20 10:06:50 2003 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 KAA16761 for ; Thu, 20 Feb 2003 10:06:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 51CA891263; Thu, 20 Feb 2003 10:08:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0535F91267; Thu, 20 Feb 2003 10:08:04 -0500 (EST) 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 E4AAC91263 for ; Thu, 20 Feb 2003 10:08:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id C0A375E063; Thu, 20 Feb 2003 10:08:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by segue.merit.edu (Postfix) with ESMTP id 9F9B85E060 for ; Thu, 20 Feb 2003 10:08:00 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lsIo-0002Un-00; Thu, 20 Feb 2003 07:07:58 -0800 Date: Thu, 20 Feb 2003 10:05:03 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030220100503.049cc4f5.moore@cs.utk.edu> In-Reply-To: <005501c2d8c5$b5e5ac00$131010ac@aldebaran> References: <907EC2A6-4465-11D7-9530-00039317663C@nominum.com> <005501c2d8c5$b5e5ac00$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > There is also the problem of a handful of people who bring their laptops > from their various company networks and try and set up an ad hoc network in > a conference room. that's why laptops need a button to say "connect to ad hoc network". From owner-zeroconf@merit.edu Thu Feb 20 10:07:08 2003 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 KAA16778 for ; Thu, 20 Feb 2003 10:07:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 64C899127C; Thu, 20 Feb 2003 10:09:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E67C91267; Thu, 20 Feb 2003 10:09:58 -0500 (EST) 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 554439127C for ; Thu, 20 Feb 2003 10:09:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 408295E065; Thu, 20 Feb 2003 10:09:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by segue.merit.edu (Postfix) with ESMTP id 0268D5E063 for ; Thu, 20 Feb 2003 10:09:53 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18lsJm-0006kL-00; Thu, 20 Feb 2003 07:08:58 -0800 Date: Thu, 20 Feb 2003 10:06:04 -0500 From: Keith Moore To: Bernard Aboba Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL Message-Id: <20030220100604.4dc66154.moore@cs.utk.edu> In-Reply-To: References: <8493.1045678659@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > I would claim that any option that can disable a host in a substantial way > should require DHCP authentication. LL can disable a host in a substantial way. From owner-zeroconf@merit.edu Thu Feb 20 10:16:15 2003 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 KAA17094 for ; Thu, 20 Feb 2003 10:16:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8F16291266; Thu, 20 Feb 2003 10:19:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5AB7891267; Thu, 20 Feb 2003 10:19:56 -0500 (EST) 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 2E32891266 for ; Thu, 20 Feb 2003 10:19:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 14C8D5E06E; Thu, 20 Feb 2003 10:19:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by segue.merit.edu (Postfix) with ESMTP id 966EB5E06D for ; Thu, 20 Feb 2003 10:19:54 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h1KFJqNh018758 for ; Thu, 20 Feb 2003 10:19:52 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA25115 for ; Thu, 20 Feb 2003 10:19:52 -0500 (EST) Message-Id: <4.3.2.7.2.20030220101604.03d43d18@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Feb 2003 10:19:51 -0500 To: zeroconf@merit.edu From: Ralph Droms Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL In-Reply-To: <8493.1045678659@munnari.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I think the analysis of selective assignment of addresses by a DHCP server goes something like: it's a local policy decision as to whether a DHCP server responds to a request from a particular client. Network admins recognize that denying an address to a client does not prevent that client from otherwise configuring an IP address or using other protocols. However, there should be no requirement that a DHCP server MUST assign an address in response to a request from a client. Someone can break into my house but there's no requirement that I hand that person a key to my front door. - Ralph At 01:17 AM 2/20/2003 +0700, Robert Elz wrote: > Date: Wed, 19 Feb 2003 07:01:46 -0800 (PST) > From: Bernard Aboba > Message-ID: > > | So the idea is to use this option in a scenario where DHCPv4 is being > used > | (otherwise the option would not be helpful) but where the DHCPv4 > server is > | not assigning addresses? > >Not assigning addresses to particular clients on particular LANs. > > | This doesn't seem like a very mainstream scenario. > >More than you might think. > > | Maybe it's just me, but I don't know many instances where DHCPv4 is > | supported where the intent is *not* to assign IP addresses. > >I do that all the time. I see lots of queries on lists from others who >want to do just the same, and are attempting to work out how. > >That is, host A is allocated an address on LAN X, but not on LAN Y. > >Without LL addresses, one simply uses the (ISC) dhcp server "ignore >booting" (or "deny") (or some equivalent from some other server), the >server ignores the client, which then gets no address. At this point >it can do whatever is appropriate for a node of its type with no addresses. > >With LL addresses, the node still gets no routable address, but lacking >any extra mechanism, now assigns itself a LL address, and acts as if >it is on a disconnected LAN (ie: some stuff works, perhaps, other stuff >doesn't). > >Having a node tell its user (one way or another) "No network address >available" is something I can cope with, they tell me that, and I can >either fix the problem, or tell them what they did wrong. On the >other hand, when they tell me "the network works OK, but I can't reach >ebay" (or google or whatever) - most likely the only external address >they have tried, I start looking at other potential problems. > > | If such an > | option is used, it would definitely seem to require authenticated > DHCP, or > | else it would create a security vulnerability. > >No. We have been through all of this before. This option, itself, >is no more of a security problem than DHCP itself. Authenticated DHCP >is useful (or not) on its own merits for general DHCP usage. (Authenticated >DHCP in a zeroconf environment seems a little unlikely to me though.) If >anything, the 2563 option is "better" than raw DHCP in this area, as a client >can easily ignore a bogus server sending such an option, and accept an address >from the real server clients always get to choose which offer of several to >accept), whereas it cannot easily ignore a bogus server giving out what looks >like a normal routable address (which just doesn't work) because it has no >idea which response is bogus and which is not. > > | "Achieve the same result" means trying to make sure that the hosts in an > | organization have no IP addresses? > >Some hosts, on some LANs. Plug your system into LAN A where it belongs, >and you get an address, plug into LAN B where it doesn't, and you don't. > > | Why use DHCP to achieve that result (except by accident)? > >Because that's how DHCP has always been (able to be) used. > >kre From owner-zeroconf@merit.edu Thu Feb 20 10:36:41 2003 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 KAA18190 for ; Thu, 20 Feb 2003 10:36:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 57BCF9126B; Thu, 20 Feb 2003 10:40:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D3699126C; Thu, 20 Feb 2003 10:40:24 -0500 (EST) 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 C4F8D9126B for ; Thu, 20 Feb 2003 10:40:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id A000C5DFD8; Thu, 20 Feb 2003 10:40:21 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 204245DF55 for ; Thu, 20 Feb 2003 10:40:21 -0500 (EST) Received: from nominum.com (az-ben-pm3-2-15.ppp.theriver.com [206.25.50.15]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1KFbiN10479; Thu, 20 Feb 2003 09:37:44 -0600 (CST) Date: Thu, 20 Feb 2003 08:40:17 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Zeroconf Working Group" To: "Philip Nye" From: Ted Lemon In-Reply-To: <005501c2d8c5$b5e5ac00$131010ac@aldebaran> Message-Id: <9C758E90-44E9-11D7-B7DF-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > "If a host loses its configured address (e.g. by lease expiry) or has > reason > to believe that its configured address is no longer working (e.g. from > media > sense), it MAY test the network configuration (e.g. using ARP) to see > if its > default route or any other applicable route is still reachable. If it > is > unable to reach any configured routers the host MAY recommence the LL > configuration scheme from the start." The problem I have with language like this is that it requires the IPv4ll agent to have its hands too deeply in the guts of the routing table code. What MacOS X does is to immediately reconfirm with the DHCP server and drop its configured address if the carrier sense drops. I'm not sure what it does when the wireless network changes. This is a rather draconian response to carrier sense changes. It means that if you want to move from one connected location to another where both are connected to the same physical network, you can reasonably expect all your connections to be lost while you are walking from one location to the other. It has a similar result if, for example, you are plugged directly into your gateway and you need to reboot the gateway for some reason (I had this happen to me a couple of days ago). I would rather choose a less extreme solution than that - e.g., keep your IPv4ll address when you have a routable address and use the IPv4ll address when communicating with other IPv4ll hosts, and use your routable address at all other times, if you have one. Unfortunately, LL19 has already been dropped, so we don't have that as an option anymore. From owner-zeroconf@merit.edu Thu Feb 20 10:53:27 2003 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 KAA18758 for ; Thu, 20 Feb 2003 10:53:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1AF489126C; Thu, 20 Feb 2003 10:57:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DECFB9126E; Thu, 20 Feb 2003 10:57:08 -0500 (EST) 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 C07A59126C for ; Thu, 20 Feb 2003 10:57:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id A2C8A5E06C; Thu, 20 Feb 2003 10:57:07 -0500 (EST) 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 488E75E063 for ; Thu, 20 Feb 2003 10:57:07 -0500 (EST) 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 IAA02130; Thu, 20 Feb 2003 08:57:06 -0700 (MST) 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 h1KFv4l23216; Thu, 20 Feb 2003 16:57:04 +0100 (MET) Date: Thu, 20 Feb 2003 16:57:03 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: ACCEPT [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses In-Reply-To: <200302190030.h1J0Uaf06713@scv3.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Tue, 18 Feb 2003, Stuart Cheshire wrote: > Erik Guttman announced the following text: > > If the destination address is in the 169.254/16 prefix (...), > then it MUST be routed > directly to the destination address and then send its packet > directly to the destination on the same physical link. > > I don't think that sentence makes any sense. Sorry - I take the blame for that sentence. I was trying to capture several pieces of advice I got on the final wording of the closure call. A grammatical improvement to the text could be If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), then it MUST be routed directly to the destination address and then send its packet directly to the destination on the same physical link. In many network stacks, achieving this functionality may be as simple as adding a routing table entry indicating that 169.254/16 is directly reachable on the local link. -> If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), then it MUST be routed directly to the destination address. The datagram will be sent directly to the destination on the same physical link. In many network stacks, achieving this functionality may be as simple as adding a routing table entry indicating that 169.254/16 is directly reachable on the local link. This still removes mention of ARP (which is the point of the issue, I guess). So perhaps your original text is superior. > I previously proposed the following text: > > If the destination address is in the 169.254/16 prefix (including > the 169.254.255.255 broadcast address), > then the host MUST use ARP [RFC 826] in the usual way to map the > destination IP address to a destination hardware address, > and then send its packet directly to the destination on the same > physical link. In many network stacks, achieving this > functionality may be as simple as adding a routing table entry > indicating that 169.254/16 is directly reachable on the local > link. The host MUST NOT send a packet with a link-local > destination address to any router for forwarding. > > Were there any objections to this wording? Yes there was - from Thomas Narten. I am sure he won't mind if I post it. >> If the destination address is in the 169.254/16 prefix (including >> the 169.254.255.255 broadcast address), then it MUST ARP for the >> destination address and then send its packet directly to the >> destination on the same physical link. In many network stacks, > > Please change the ARP wording to use something like "routed directly" > (maybe defining the term in the definitions if necessary). Comments on > the list about not using ARP to define what is logically on-link are > 100% correct. > >> achieving this functionality may be as simple as adding a routing >> table entry indicating that 169.254/16 is directly reachable on the >> local link. The host MUST NOT send a packet with a link-local >> destination address to any router for forwarding. > > Why this last sentence _in this section_, which is about source > address selection? This sentence need only appear once in the document > in the section that talks about where to send packets to LL > destinations. I agree we should resolve this. Could you take this up with Thomas and see if you and he can agree on some text - then bring it back to the list with a suggestion? I regret the last minute change - but remember the goal of this entire exercise is to resolve all IESG issues. Thanks for your patience, Erik From owner-zeroconf@merit.edu Thu Feb 20 11:02:24 2003 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 LAA19091 for ; Thu, 20 Feb 2003 11:02:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 703999126E; Thu, 20 Feb 2003 11:06:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 41E1791274; Thu, 20 Feb 2003 11:06:05 -0500 (EST) 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 5A7659126E for ; Thu, 20 Feb 2003 11:06:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 473895DECD; Thu, 20 Feb 2003 11:06:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id B58F15DDBC for ; Thu, 20 Feb 2003 11:06:03 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26967; Thu, 20 Feb 2003 08:06:02 -0800 (PST) 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 h1KG60l23666; Thu, 20 Feb 2003 17:06:00 +0100 (MET) Date: Thu, 20 Feb 2003 17:05:59 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: ACCEPT [LL17] "directly routed"? In-Reply-To: <200302190030.h1J0UpQ15777@scv2.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Tue, 18 Feb 2003, Stuart Cheshire wrote: > directly routed > > A datagram is directly routed to a destination if it is sent > to the destination address. A datagram that is directly > routed MUST NOT be sent to another address so that it will > be forwarded to the destination address. > > I think the first sentence says nothing. > > I also think that the term "directly routed" is self-contradictory. The > concept of "routing" means "going through routers". The concept of > sending a packet "directly" to its destination means "NOT going through > routers". > > Perhaps the term should be "directly delivered" or "delivered directly". Actually, I think what we are trying to get at is if you want to send to destination D you should send directly to D, not to some other address not-D so as to get the packet delivered to D. There are many reasons you might send to not-D to get to D - such as "going through routers," tunneling, knowing somehow that the host with an interface configured with address D also has another (or the same) interface configured with address not-D. In each case, we do not want to allow these routing behaviors (forwarding, encapsulating, accessing of an 'adjacent' interface). I fully agree the wording of the definition needs work. Erik From owner-zeroconf@merit.edu Thu Feb 20 11:04:16 2003 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 LAA19173 for ; Thu, 20 Feb 2003 11:04:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0EA0B91274; Thu, 20 Feb 2003 11:08:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE5D891278; Thu, 20 Feb 2003 11:07:59 -0500 (EST) 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 D298591274 for ; Thu, 20 Feb 2003 11:07:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id B3DA65DDBC; Thu, 20 Feb 2003 11:07:58 -0500 (EST) 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 5F4CD5DD9D for ; Thu, 20 Feb 2003 11:07:58 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id A4632598EE; Thu, 20 Feb 2003 16:08:00 +0000 (GMT) Message-ID: <003601c2d8fa$66fceab0$131010ac@aldebaran> From: "Philip Nye" To: "Ted Lemon" Cc: "Zeroconf Working Group" References: <9C758E90-44E9-11D7-B7DF-00039317663C@nominum.com> Subject: Re: LL1, LL23 Date: Thu, 20 Feb 2003 16:09:03 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Ted Lemon" > > > "If a host loses its configured address (e.g. by lease expiry) or has > > reason > > to believe that its configured address is no longer working (e.g. from > > media > > sense), it MAY test the network configuration (e.g. using ARP) to see > > if its > > default route or any other applicable route is still reachable. If it > > is > > unable to reach any configured routers the host MAY recommence the LL > > configuration scheme from the start." > > The problem I have with language like this is that it requires the > IPv4ll agent to have its hands too deeply in the guts of the routing > table code. > > What MacOS X does is to immediately reconfirm with the DHCP server and > drop its configured address if the carrier sense drops. I'm not sure > what it does when the wireless network changes. This is a rather > draconian response to carrier sense changes. It means that if you > want to move from one connected location to another where both are > connected to the same physical network, you can reasonably expect all > your connections to be lost while you are walking from one location to > the other. It has a similar result if, for example, you are plugged > directly into your gateway and you need to reboot the gateway for some > reason (I had this happen to me a couple of days ago). The fact that the principle proponents of LL: Apple and Microsoft both use very simplistic algorithms (at opposite extremes it seems) which cause trouble in one situation or another indicates that some guidance would be useful. How much general guidance can go into a standard is questionable - this standard seems to have quite a bit. I suggested trying to ARP your router because this seems a much lower level indication that you are still on the same network than a DHCP request does. If the DHCP server is down or busy, you can still usefully use your configuration provided it has not expired. However, if your default router is not reachable, then you either need to find a new one or you might as well use LL (or nothing) since you can't get off the link anyway. Since you probably start reconfiguration by looking for a DHCP server anyway, this seems to make sense. Philip From owner-zeroconf@merit.edu Thu Feb 20 11:36:16 2003 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 LAA20435 for ; Thu, 20 Feb 2003 11:36:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2D85191279; Thu, 20 Feb 2003 11:39:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E93189127B; Thu, 20 Feb 2003 11:39:58 -0500 (EST) 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 CCF7991279 for ; Thu, 20 Feb 2003 11:39:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9FE0F5E06D; Thu, 20 Feb 2003 11:39:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by segue.merit.edu (Postfix) with ESMTP id 77A305DECD for ; Thu, 20 Feb 2003 11:39:57 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ltjm-0000Dn-00; Thu, 20 Feb 2003 08:39:54 -0800 Date: Thu, 20 Feb 2003 11:36:59 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030220113659.335e47fb.moore@cs.utk.edu> In-Reply-To: <003601c2d8fa$66fceab0$131010ac@aldebaran> References: <9C758E90-44E9-11D7-B7DF-00039317663C@nominum.com> <003601c2d8fa$66fceab0$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > I suggested trying to ARP your router because this seems a much lower level > indication that you are still on the same network than a DHCP request does. except in one case - where you are on a private network using RFC 1918 addresses. it's very common for the NAT/router to have the .1 address on such networks, and even if not, it's common for the .1 address to be assigned to some host. hence, an ARP reply from that address doesn't mean you are on the same network. From owner-zeroconf@merit.edu Thu Feb 20 13:28:12 2003 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 NAA24375 for ; Thu, 20 Feb 2003 13:28:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B1A4F91288; Thu, 20 Feb 2003 13:31:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61BEB91286; Thu, 20 Feb 2003 13:31:38 -0500 (EST) 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 E346691285 for ; Thu, 20 Feb 2003 13:31:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1A1BE5DE30; Thu, 20 Feb 2003 13:31:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id C804D5DDA6 for ; Thu, 20 Feb 2003 13:31:00 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1KIVdaj014936; Thu, 20 Feb 2003 20:31:39 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1KIVbVJ014934; Thu, 20 Feb 2003 20:31:37 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Ted Lemon Cc: Philip Nye , Zeroconf Working Group In-Reply-To: <9C758E90-44E9-11D7-B7DF-00039317663C@nominum.com> References: <9C758E90-44E9-11D7-B7DF-00039317663C@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045765896.14741.17.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Feb 2003 20:31:37 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-02-20 at 17:40, Ted Lemon wrote: > > "If a host loses its configured address (e.g. by lease expiry) or has > > reason > > to believe that its configured address is no longer working (e.g. from > > media > > sense), it MAY test the network configuration (e.g. using ARP) to see > > if its > > default route or any other applicable route is still reachable. If it > > is > > unable to reach any configured routers the host MAY recommence the LL > > configuration scheme from the start." > > The problem I have with language like this is that it requires the > IPv4ll agent to have its hands too deeply in the guts of the routing > table code. Exactly. Not to mention that language like that is far too vague to implement anything sensible. > I would rather choose a less extreme solution than that - e.g., keep > your IPv4ll address when you have a routable address and use the IPv4ll > address when communicating with other IPv4ll hosts, and use your > routable address at all other times, if you have one. Unfortunately, > LL19 has already been dropped, so we don't have that as an option > anymore. We do have this option. I tried to get matching scopes for source and destination addresses mandated via LL19, but the current text in the draft is acceptable too: the requirement is SHOULD rather than MUST. This allows communication between LL-only and routable-only, which seems to be the big thing now, while maintaining reasonable clarity of implementation. ==> reject both LL1 and LL23. MikaL From owner-zeroconf@merit.edu Thu Feb 20 14:22:52 2003 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 OAA26324 for ; Thu, 20 Feb 2003 14:22:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3740B91286; Thu, 20 Feb 2003 14:26:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02B6D9128A; Thu, 20 Feb 2003 14:26:33 -0500 (EST) 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 050C591286 for ; Thu, 20 Feb 2003 14:26:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id DBAEF5DF2C; Thu, 20 Feb 2003 14:26:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id BA8A35DDAE for ; Thu, 20 Feb 2003 14:26:31 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1KJRBaj015166; Thu, 20 Feb 2003 21:27:11 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1KJRA60015165; Thu, 20 Feb 2003 21:27:10 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Robert Elz Cc: Ted Lemon , Philip Nye , Zeroconf Working Group In-Reply-To: <14639.1045746406@munnari.OZ.AU> References: <907EC2A6-4465-11D7-9530-00039317663C@nominum.com> <005501c2d8c5$b5e5ac00$131010ac@aldebaran> <14639.1045746406@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045769229.14935.29.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Feb 2003 21:27:09 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-02-20 at 15:06, Robert Elz wrote: > [Aside: note that > LL23 does not say that a host should stop defending its LL address, so > once having acquire it, it will retain it in most cases. It also doesn't > say, but in this case probably should, that if some other node usurps a LL > address that is "dormant" the node should just forget it ever existed, and > not go allocate another - or not until working routable addresses fail]. So, LL23 allows the node to keep and defend its LL address (dormant) after acquiring a routable one. This being the case, it seems rather pointless to put in additional complicated rules about when to configure and when to unconfigure a LL address. MikaL From owner-zeroconf@merit.edu Thu Feb 20 14:31:12 2003 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 OAA26633 for ; Thu, 20 Feb 2003 14:31:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 86CF99128A; Thu, 20 Feb 2003 14:34:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 544C59128B; Thu, 20 Feb 2003 14:34:54 -0500 (EST) 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 362C89128A for ; Thu, 20 Feb 2003 14:34:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C3875DED6; Thu, 20 Feb 2003 14:34:53 -0500 (EST) 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 B1FE05DDFE for ; Thu, 20 Feb 2003 14:34:52 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h1KJUsA11250; Thu, 20 Feb 2003 14:30:56 -0500 (EST) Date: Thu, 20 Feb 2003 14:30:54 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, Ted.Lemon@nominum.com, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030220143054.31469a4b.moore@cs.utk.edu> In-Reply-To: <1045769229.14935.29.camel@devil> References: <907EC2A6-4465-11D7-9530-00039317663C@nominum.com> <005501c2d8c5$b5e5ac00$131010ac@aldebaran> <14639.1045746406@munnari.OZ.AU> <1045769229.14935.29.camel@devil> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) 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 > So, LL23 allows the node to keep and defend its LL address (dormant) > after acquiring a routable one. This being the case, it seems rather > pointless to put in additional complicated rules about when to > configure and when to unconfigure a LL address. I would rather nodes not continue to defend addresses on connected networks, if only because this consumes potentially scarce network resources. (think of an ethernet bridged over ISDN BRI, for instance) Using DHCP to give the node an address is an acceptable workaround for this problem only if the node then stops maintaining its LL address. From owner-zeroconf@merit.edu Thu Feb 20 14:38:50 2003 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 OAA26911 for ; Thu, 20 Feb 2003 14:38:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7BCCB9128B; Thu, 20 Feb 2003 14:42:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D5849128C; Thu, 20 Feb 2003 14:42:32 -0500 (EST) 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 3F76C9128B for ; Thu, 20 Feb 2003 14:42:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C4FD5E071; Thu, 20 Feb 2003 14:42:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 0D90C5DED6 for ; Thu, 20 Feb 2003 14:42:30 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1KJh4aj015278; Thu, 20 Feb 2003 21:43:04 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1KJh1i7015276; Thu, 20 Feb 2003 21:43:01 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: kre@munnari.OZ.AU, Ted.Lemon@nominum.com, philip@engarts.com, zeroconf@merit.edu In-Reply-To: <20030220143054.31469a4b.moore@cs.utk.edu> References: <907EC2A6-4465-11D7-9530-00039317663C@nominum.com> <005501c2d8c5$b5e5ac00$131010ac@aldebaran> <14639.1045746406@munnari.OZ.AU> <1045769229.14935.29.camel@devil> <20030220143054.31469a4b.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045770180.14935.34.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Feb 2003 21:43:00 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-02-20 at 21:30, Keith Moore wrote: > > So, LL23 allows the node to keep and defend its LL address (dormant) > > after acquiring a routable one. This being the case, it seems rather > > pointless to put in additional complicated rules about when to > > configure and when to unconfigure a LL address. > > I would rather nodes not continue to defend addresses on connected > networks, if only because this consumes potentially scarce network > resources. (think of an ethernet bridged over ISDN BRI, for instance) > Using DHCP to give the node an address is an acceptable workaround for > this problem only if the node then stops maintaining its LL address. I see the point, but I doubt a few extra ARPs are going to make that much difference. If the alternative is that each node has to constantly probe its gateway routes to check whether it still has connectivity, the DADs actually seem like the lesser evil. MikaL From owner-zeroconf@merit.edu Thu Feb 20 15:05:58 2003 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 PAA27791 for ; Thu, 20 Feb 2003 15:05:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F0C749128C; Thu, 20 Feb 2003 15:09:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B625A9128E; Thu, 20 Feb 2003 15:09:39 -0500 (EST) 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 A02309128C for ; Thu, 20 Feb 2003 15:09:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 84B995E077; Thu, 20 Feb 2003 15:09:38 -0500 (EST) 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 2571B5E076 for ; Thu, 20 Feb 2003 15:09:38 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h1KK5jA11309; Thu, 20 Feb 2003 15:05:45 -0500 (EST) Date: Thu, 20 Feb 2003 15:05:44 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, Ted.Lemon@nominum.com, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030220150544.1ce16cf5.moore@cs.utk.edu> In-Reply-To: <1045770180.14935.34.camel@devil> References: <907EC2A6-4465-11D7-9530-00039317663C@nominum.com> <005501c2d8c5$b5e5ac00$131010ac@aldebaran> <14639.1045746406@munnari.OZ.AU> <1045769229.14935.29.camel@devil> <20030220143054.31469a4b.moore@cs.utk.edu> <1045770180.14935.34.camel@devil> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) 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 > > I would rather nodes not continue to defend addresses on connected > > networks, if only because this consumes potentially scarce network > > resources. (think of an ethernet bridged over ISDN BRI, for > > instance) Using DHCP to give the node an address is an acceptable > > workaround for this problem only if the node then stops maintaining > > its LL address. > > I see the point, but I doubt a few extra ARPs are going to make that > much difference. If the alternative is that each node has to > constantly probe its gateway routes to check whether it still has > connectivity, the DADs actually seem like the lesser evil. those are separate concerns. defending an LL address doesn't relieve a host of whatever necessity (if it has any, which I doubt) to probe nearby routers. and I don't think probing nearby routers is a good way to determine whether to start using an LL address. address validity and external connectivity are separate things. From owner-zeroconf@merit.edu Thu Feb 20 15:14:20 2003 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 PAA27990 for ; Thu, 20 Feb 2003 15:14:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A7FB791292; Thu, 20 Feb 2003 15:15:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66AE091297; Thu, 20 Feb 2003 15:15:52 -0500 (EST) 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 B06E591292 for ; Thu, 20 Feb 2003 15:15:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 657335E09E; Thu, 20 Feb 2003 15:15:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id C7E235E0DE for ; Thu, 20 Feb 2003 15:15:40 -0500 (EST) Received: from nominum.com (az-ben-pm3-2-15.ppp.theriver.com [206.25.50.15]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1KKAIN12754; Thu, 20 Feb 2003 14:10:18 -0600 (CST) Date: Thu, 20 Feb 2003 13:12:54 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Mika Liljeberg , kre@munnari.OZ.AU, philip@engarts.com, zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030220143054.31469a4b.moore@cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I would rather nodes not continue to defend addresses on connected > networks, if only because this consumes potentially scarce network > resources. (think of an ethernet bridged over ISDN BRI, for instance) You know, there are a lot of things that I think the IETF should be working on. Making sure that this particular configuration works well simply isn't one of them. The solution that I think the IETF, if it were a sentient being capable of recommending solutions, would make for this configuration is that the bridge should be replaced with a router, and the network should be subnetted. There are a lot of parts of the IP protocol suite that don't react well to mixed-media broadcast domains where one medium is wildly different than the other. This can be *made* to work, but we shouldn't be surprised when it doesn't work well, any more than we should be surprised that NAT, for example, doesn't work well in some situations. From owner-zeroconf@merit.edu Thu Feb 20 15:25:11 2003 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 PAA28405 for ; Thu, 20 Feb 2003 15:25:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 08B2E91294; Thu, 20 Feb 2003 15:26:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D43AF91293; Thu, 20 Feb 2003 15:26:43 -0500 (EST) 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 07A2E91290 for ; Thu, 20 Feb 2003 15:26:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id E09375E06D; Thu, 20 Feb 2003 15:26:38 -0500 (EST) 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 8145C5DDFE for ; Thu, 20 Feb 2003 15:26:38 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h1KKMkA11346; Thu, 20 Feb 2003 15:22:46 -0500 (EST) Date: Thu, 20 Feb 2003 15:22:46 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, mika.liljeberg@welho.com, kre@munnari.OZ.AU, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030220152246.5655c484.moore@cs.utk.edu> In-Reply-To: References: <20030220143054.31469a4b.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) 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 > > I would rather nodes not continue to defend addresses on connected > > networks, if only because this consumes potentially scarce network > > resources. (think of an ethernet bridged over ISDN BRI, for > > instance) > > You know, there are a lot of things that I think the IETF should be > working on. Making sure that this particular configuration works > well simply isn't one of them. perhaps not. then again, LL-only devices are probably even more deserving of being excluded. I do think it's reasonable for IETF to be somewhat concerned about the impact of its standards on existing networks, even if those networks aren't laid out exactly as we think best. e.g. we try to make software NAT-tolerant where feasible even though NAT violates IP. Keith From owner-zeroconf@merit.edu Thu Feb 20 16:12:32 2003 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 QAA29690 for ; Thu, 20 Feb 2003 16:12:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1771D91299; Thu, 20 Feb 2003 16:15:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF3149129A; Thu, 20 Feb 2003 16:15:43 -0500 (EST) 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 5161D91299 for ; Thu, 20 Feb 2003 16:15:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5E6865E07A; Thu, 20 Feb 2003 16:15:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id BB1D15DE5D for ; Thu, 20 Feb 2003 16:15:40 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08897; Thu, 20 Feb 2003 13:15:39 -0800 (PST) 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 h1KLFbl08431; Thu, 20 Feb 2003 22:15:37 +0100 (MET) Date: Thu, 20 Feb 2003 22:15:36 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Philip Nye Cc: Zeroconf Working Group Subject: Re: LL1, LL23 In-Reply-To: <00df01c2d86c$a4addb00$131010ac@aldebaran> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Wed, 19 Feb 2003, Philip Nye wrote: > > > Neither option directly tackles the more difficult issue of transition > from > > > configured to zero-config > > > > this is an interesting case. IMHO it should only happen when a network is > > losing its external address prefix, or by explicit decision of the network > > admin. if the routable addresses remain valid (i.e. they're not being > > reassigned) it's better for the network to use routable addresses (even > if > > the network is isolated) than to use LL addresses. > > It could easily happen when your NAT router with DHCP server goes down or is > unplugged. Those DHCP leases will run out eventually. > > The case where you unplug from one network and plug into another is closely > related to this. It is a transition from one state to another which might be > zero-config. If you have been running in zero-config mode, the requirement > to periodically try DHCP will ensure a transition. If you have been running > configured, there is nothing to trigger a reconfiguration and no guideline > in the document so say when it is OK to start trying for LL again. > > Waiting till your lease runs out and you fail to renew it could be a long > time. That is OK if your address continues to work for that time but this > won't necessarily be the case. > > These are both cases of detecting the absence of valid configuration which > is harder than detecting its presence - what makes you start? how long do > you try for? We need to think about this, but not necessarily in the context of LL1 or LL23. Both say if you have a configured address you should stop using the autoconfigured address (with SHOULD and MAY under certain conditions, for certain functions). Neither say what you should do whne you do not have an address or how to determine that. I think we should have a new issue for this. Erik From owner-zeroconf@merit.edu Thu Feb 20 16:25:10 2003 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 QAA00014 for ; Thu, 20 Feb 2003 16:25:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B5CF49129C; Thu, 20 Feb 2003 16:28:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F47D912A7; Thu, 20 Feb 2003 16:28:25 -0500 (EST) 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 B77289129C for ; Thu, 20 Feb 2003 16:28:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D94B5E09E; Thu, 20 Feb 2003 16:28:22 -0500 (EST) 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 0D6645E07F for ; Thu, 20 Feb 2003 16:28:22 -0500 (EST) 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 OAA17659 for ; Thu, 20 Feb 2003 14:28:21 -0700 (MST) 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 h1KLSJl08915 for ; Thu, 20 Feb 2003 22:28:19 +0100 (MET) Date: Thu, 20 Feb 2003 22:28:18 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: keep on topic please Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Discussion of NAT, RFC 1918, and the hidden agenda of those participating in chartering the zeroconf WG is not moving the discussion of LL1, LL2, LL23 and LL27 forward. Stay on topic or take your discussions off the list. Erik ZEROCONF WG chair From owner-zeroconf@merit.edu Thu Feb 20 16:25:35 2003 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 QAA00037 for ; Thu, 20 Feb 2003 16:25:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 71AEE91298; Thu, 20 Feb 2003 16:29:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 413CB9129A; Thu, 20 Feb 2003 16:29:19 -0500 (EST) 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 2F3D491298 for ; Thu, 20 Feb 2003 16:29:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 142315E0F7; Thu, 20 Feb 2003 16:29:18 -0500 (EST) 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 B4F645E0DE for ; Thu, 20 Feb 2003 16:29:17 -0500 (EST) 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 OAA29924; Thu, 20 Feb 2003 14:29:15 -0700 (MST) 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 h1KLTEl08948; Thu, 20 Feb 2003 22:29:14 +0100 (MET) Date: Thu, 20 Feb 2003 22:29:12 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: Keith Moore Cc: Brad Hards , aboba@internaut.com, zeroconf@merit.edu Subject: Re: [Issue 27]: LL-only hosts In-Reply-To: <20030218151219.6bb3b1e0.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk [WG chair hat off] On Tue, 18 Feb 2003, Keith Moore wrote: >>>> There are a range of applications where a routable address is of >>>> absolutely no value. I came to zeroconf looking for a solution for USB >>>> host-to-host cables. >>> >>> please explain what that has to do with the Internet, A LL-only device will support IETF standards for L4 and up. >>> why it's relevant to the purpose of IETF There is no requirement that a host support all elective standards. There is no standard which states that a host must support configuration. The closest we come is in RFC1123 where we say Finally, we note that a vendor needs to provide adequate documentation on all configuration parameters, their limits and effects. and section 6.2.1(1) Diskless machines often have no permanent storage in which to store network configuration information, so that sufficient configuration information must be obtained dynamically to support the loading phase that follows. ! This information must include at least the IP addresses of ! the host and of the boot server. To support booting ! across a gateway, the address mask and a list of default ! gateways are also required. ... A host with a disk may perform the first step, dynamic configuration. This is important for microcomputers, whose floppy disks allow network configuration information to be mistakenly duplicated on more than one host. Also, ! installation of new hosts is much simpler if they automatically ! obtain their configuration information from a central server, ! saving administrator time and decreasing the probability of ! mistakes. Automatic (serverless) configuration of IP addresses is not envisioned here. Support of configuration of a gateway address and network mask is required only to boot over a gateway. The suggested approach to dynamic configuration is to use the BOOTP protocol with the extensions defined in "BOOTP Vendor Information Extensions" RFC-1084 [BOOT:3]. RFC-1084 defines some important general (not vendor-specific) extensions. In particular, these extensions allow the ! address mask to be supplied in BOOTP; we RECOMMEND that the address mask be supplied in this manner. Again, other ways of providing parameters are not excluded. Nowhere is there a requirement that a host have an address of some specific scope. Nowhere is there a statement that a host without such an address is outside fo the scope of IETF standardization. [WG chair hat] >>> or this WG, This has been a stated objective of the WG since the first BOF. This was part of both Stuart's and my materials at nearly all of our WG meetings. [/WG chair hat] >>> and why IETF should standardize a practice that will harm >>> Internet interoperability. It is true that there may be issues for higher layer protocols which work with LL addresses if there are any such devices which have addresses in different scopes. I have not seen any arguments that that show that there are problems for a set of devices *solely* in link-local scope. We all agree this may not be completely straightforward to support hosts using higher layer addresses with link-local address in an environment with both link-local and non-link-local scoped addresses. We are committed to identifying the issues, finding a way to minimize their effects and ensuring that *if* a host is configurable it will interoperate well. I do not see how one can then conclude that the devices *must* be configurable. Erik From owner-zeroconf@merit.edu Thu Feb 20 16:25:59 2003 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 QAA00064 for ; Thu, 20 Feb 2003 16:25:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8A93E9129A; Thu, 20 Feb 2003 16:29:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A1539129B; Thu, 20 Feb 2003 16:29:44 -0500 (EST) 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 6CAF49129A for ; Thu, 20 Feb 2003 16:29:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4E8525E0DE; Thu, 20 Feb 2003 16:29:43 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id C5C485DE5D for ; Thu, 20 Feb 2003 16:29:42 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18084; Thu, 20 Feb 2003 13:29:41 -0800 (PST) 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 h1KLTdl08969; Thu, 20 Feb 2003 22:29:39 +0100 (MET) Date: Thu, 20 Feb 2003 22:29:38 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: Philip Nye Cc: Zeroconf Working Group Subject: Re: [Issue 27]: LL-only hosts In-Reply-To: <028001c2d808$a78897c0$131010ac@aldebaran> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Wed, 19 Feb 2003, Philip Nye wrote: > I would say that what is really needed is to split this into one > specification which simply defines how LL claim-defend works and a second > which dictates the conditions, warnings, prerequisits etc for using it in > generic devices which might be connected into routed networks. This is not an option at this late a date. This would add months to the process of completing work on the specification. Erik From owner-zeroconf@merit.edu Thu Feb 20 16:27:55 2003 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 QAA00153 for ; Thu, 20 Feb 2003 16:27:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C18079129F; Thu, 20 Feb 2003 16:31:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8906C912A1; Thu, 20 Feb 2003 16:31:07 -0500 (EST) 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 578479129F for ; Thu, 20 Feb 2003 16:31:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 59C905E07F; Thu, 20 Feb 2003 16:31:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (unknown [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id C9E675E098 for ; Thu, 20 Feb 2003 16:30:58 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1KLVbaj015765; Thu, 20 Feb 2003 23:31:38 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1KLVZ5Q015763; Thu, 20 Feb 2003 23:31:35 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Erik Guttman Cc: Philip Nye , Zeroconf Working Group In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045776694.14935.56.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 20 Feb 2003 23:31:34 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-02-20 at 23:15, Erik Guttman wrote: > We need to think about this, but not necessarily in the context of LL1 > or LL23. Both say if you have a configured address you should stop > using the autoconfigured address (with SHOULD and MAY under certain > conditions, for certain functions). Neither say what you should do whne > you do not have an address or how to determine that. I think we should > have a new issue for this. I disagree. These problems go to show that LL23 is probably not a good idea. MikaL From owner-zeroconf@merit.edu Thu Feb 20 17:00:01 2003 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 RAA01276 for ; Thu, 20 Feb 2003 17:00:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 924DB9129E; Thu, 20 Feb 2003 17:02:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 421EB912A1; Thu, 20 Feb 2003 17:02:04 -0500 (EST) 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 47B919129E for ; Thu, 20 Feb 2003 17:02:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF5EA5E081; Thu, 20 Feb 2003 17:01:59 -0500 (EST) 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 857135DDFA for ; Thu, 20 Feb 2003 17:01:59 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h1KM1cA11644; Thu, 20 Feb 2003 17:01:39 -0500 (EST) Date: Thu, 20 Feb 2003 17:01:38 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, bhards@bigpond.net.au, aboba@internaut.com, zeroconf@merit.edu Subject: Re: [LL27]: LL-only hosts Message-Id: <20030220170138.391218ee.moore@cs.utk.edu> In-Reply-To: References: <20030218151219.6bb3b1e0.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf) 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 > A LL-only device will support IETF standards for L4 and up. but it won't interoperate with anything on the Internet. I assert that it is a serious process violation, as well as a technical error, if this WG tries to endorse LL-only devices in an IETF standard. > There is no requirement that a host support all elective standards. there is no requirement that IETF endorse things that won't interoperate with the internet, and which if encouraged will degrade internet interoperability. > Nowhere is there a requirement that a host have an address of some > specific scope. at the time 1123 was written, all IP addresses were globally scoped, so any such requirement would have been superfluous. > This has been a stated objective of the WG since the first BOF. and IIRC, there was significant pushback about this at the NITS BOFs. did you think the problem would go away if it were ignored? > It is true that there may be issues for higher layer protocols which > work with LL addresses if there are any such devices which have > addresses in different scopes. forget higher layer protocols for the moment. LL-only devices can't even exchange IP packets with devices that aren't on the link. thus they cannot function with the INTERnet, which is fundamentally a network consisting of concatenated networks. furthermore I'll claim that encouragement of devices which cannot communicate with the Internet but can claim to conform to IETF standards does harm to the Internet and dilutes the value of IETF standards. Keith From owner-zeroconf@merit.edu Thu Feb 20 17:38:34 2003 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 RAA02358 for ; Thu, 20 Feb 2003 17:38:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 47CDD912A2; Thu, 20 Feb 2003 17:42:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F2CC912A3; Thu, 20 Feb 2003 17:42:15 -0500 (EST) 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 118D2912A2 for ; Thu, 20 Feb 2003 17:42:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id E8B185DE45; Thu, 20 Feb 2003 17:42:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 972DB5DE37 for ; Thu, 20 Feb 2003 17:42:14 -0500 (EST) Received: from nominum.com (az-ben-pm3-2-15.ppp.theriver.com [206.25.50.15]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1KMdVN13949; Thu, 20 Feb 2003 16:39:31 -0600 (CST) Date: Thu, 20 Feb 2003 15:42:08 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Erik Guttman , Philip Nye , Zeroconf Working Group To: Mika Liljeberg From: Ted Lemon In-Reply-To: <1045776694.14935.56.camel@devil> Message-Id: <8B083511-4524-11D7-A12D-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I disagree. These problems go to show that LL23 is probably not a good > idea. > > MikaL I agree with Mika on this one. I think we should just drop LL1 and LL23. From owner-zeroconf@merit.edu Fri Feb 21 01:55:15 2003 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 BAA11140 for ; Fri, 21 Feb 2003 01:55:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 33B5491263; Fri, 21 Feb 2003 01:58:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E743691265; Fri, 21 Feb 2003 01:58:56 -0500 (EST) 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 D11C591263 for ; Fri, 21 Feb 2003 01:58:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id B3A9C5E00A; Fri, 21 Feb 2003 01:58:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id F30635DE2A for ; Fri, 21 Feb 2003 01:58:54 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1L6xTaj019709; Fri, 21 Feb 2003 08:59:29 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1L6xQew019708; Fri, 21 Feb 2003 08:59:26 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: Ted Lemon , Erik.Guttman@Sun.COM, philip@engarts.com, zeroconf@merit.edu In-Reply-To: <20030220174934.10b52b2e.moore@cs.utk.edu> References: <1045776694.14935.56.camel@devil> <8B083511-4524-11D7-A12D-00039317663C@nominum.com> <20030220174934.10b52b2e.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045810765.14935.486.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2003 08:59:26 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-02-21 at 00:49, Keith Moore wrote: > > > I disagree. These problems go to show that LL23 is probably not a > > > good idea. > > > > I agree with Mika on this one. I think we should just drop LL1 and > > LL23. > > nobody has proposed a better solution to the problems that LL causes > for applications. There's just two points I'd like to make to that: 1) The attitude here is that "the problem" should be taken for granted. Despite repeated requests, no compelling cases of common situations where users would be seriously inconvenienced have been presented. This fact merely strengthens my belief that "the problem" is in fact a fairly minor one. 2) "The problem" is such a convenient one that we could debate it endlessly and still not come up with a satisfactory solution. As such, it simply delays the work of the WG and serves no useful purpose. > to reject LL23 is to make LL unsuitable for standardization. Hardly that. LL23 describes what is fundamentally an implementation approach. Rejecting issue LL23 does not prevent OS vendors from applying it in their implementation if they want to. There is no need to foist it on OS vendors who don't. OS vendors are perfectly capable of taking in user feedback and deciding for themselves. LL23 has also been shown to introduce a number of new difficulties, which would need to be solved to make the specification suitable for standardisation. The implementation complexity implied by LL23 just makes me wince. Well, this patient is not feeling particularly ill and doesn't much like the medicine. LL1 OTH is a fairly indifferent proposition. Taking what is currently in the draft, LL1 only makes a difference with connections where the peer is LL-only. For LL-only nodes "the problem" is insoluble anyway. Since the ineffectiveness is coupled with some implementation issues, I feel no compunction in putting LL1 aside as well. MikaL From owner-zeroconf@merit.edu Fri Feb 21 05:15:10 2003 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 FAA25036 for ; Fri, 21 Feb 2003 05:15:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1CCB79126C; Fri, 21 Feb 2003 05:18:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE9759126E; Fri, 21 Feb 2003 05:18:44 -0500 (EST) 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 D6C219126C for ; Fri, 21 Feb 2003 05:18:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id B14805DF1E; Fri, 21 Feb 2003 05:18:31 -0500 (EST) 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 36AAF5DE76 for ; Fri, 21 Feb 2003 05:18:31 -0500 (EST) 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 CAA24337; Fri, 21 Feb 2003 02:18:28 -0800 (PST) Received: from sun.com (vpn-129-159-0-192.EMEA.Sun.COM [129.159.0.192]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1LAIPl00947; Fri, 21 Feb 2003 11:18:25 +0100 (MET) Message-ID: <3E55FCA9.7080000@sun.com> Date: Fri, 21 Feb 2003 11:17:13 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Keith Moore Cc: bhards@bigpond.net.au, aboba@internaut.com, zeroconf@merit.edu Subject: Re: [LL27]: LL-only hosts References: <20030218151219.6bb3b1e0.moore@cs.utk.edu> <20030220170138.391218ee.moore@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: >>A LL-only device will support IETF standards for L4 and up. > > > but it won't interoperate with anything on the Internet. > > I assert that it is a serious process violation, as well as a technical > error, if this WG tries to endorse LL-only devices in an IETF standard. Folks, It is fine for Keith to assert this. He has however no special authority which allows him to interpret IETF process or determine what is suitable for IETF standardization. The IESG is the body at the IETF who has this authority. We will consider specific technical arguments as part of the call for WG consensus on issues. Please be concrete - abstract evocation of architectural disasters have less weight than a single example of useful technology. The number, vehemence, or length of postings will have no bearing on the WG consensus call. Given that please post sparingly, remain respectful, give concrete examples and keep your statements to the point. Erik ZEROCONF WG chair ps. This message should not be taken to defend the position that I took in the mail Keith is responding to. That position was taken by me as a WG contributor and so it also will be given no special authority or weight in the consensus call. From owner-zeroconf@merit.edu Fri Feb 21 05:16:39 2003 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 FAA25069 for ; Fri, 21 Feb 2003 05:16:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9C29D9126E; Fri, 21 Feb 2003 05:20:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63BA891274; Fri, 21 Feb 2003 05:20:15 -0500 (EST) 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 741BB9126E for ; Fri, 21 Feb 2003 05:20:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 62F895DF56; Fri, 21 Feb 2003 05:20:14 -0500 (EST) 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 34E425DEA5 for ; Fri, 21 Feb 2003 05:20:14 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 6EB0059AAF for ; Fri, 21 Feb 2003 10:20:15 +0000 (GMT) Message-ID: <006c01c2d992$fdb008a0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <1045776694.14935.56.camel@devil> <8B083511-4524-11D7-A12D-00039317663C@nominum.com> <20030220174934.10b52b2e.moore@cs.utk.edu> <1045810765.14935.486.camel@devil> Subject: Re: LL1, LL23 Date: Fri, 21 Feb 2003 10:21:25 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Ted Lemon" > > I agree with Mika on this one. I think we should just drop LL1 and > LL23. We are in severe danger of starting round the same futile loop once again. It is only a month ago or so that this list seemed to have finally accepted the principle that running both LL and routable addresses together in a host on a routed network is A BAD IDEA, largely because of apparently unresolvable issues for applications. We also recognised that it is not possible to stop this case altogether because of transitions but that the best compromise is for hosts to cease using LL addresses if they have a routable one and to stick to the principle of just one address per interface (multihoming for other reasons excepted). This has given rise to LL1 and LL23 which are both variations on precisely how to do this. LL1 is more brutal. LL23 attempts to spell things out more and to soften the disruption when an operating LL host gains a configured address. Personally I see little to choose between them and if someone wants to suggest a better way to make this happen then fine. But if we are to go back round the loop on the idea of running LL and routable addresses concurrently then someone had better bring something new to the table! Philip From owner-zeroconf@merit.edu Fri Feb 21 05:58:32 2003 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 FAA25639 for ; Fri, 21 Feb 2003 05:58:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B612791276; Fri, 21 Feb 2003 05:59:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E89B91277; Fri, 21 Feb 2003 05:59:26 -0500 (EST) 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 AED1B91276 for ; Fri, 21 Feb 2003 05:59:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9A3755E038; Fri, 21 Feb 2003 05:59:22 -0500 (EST) 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 6CD0F5DF8A for ; Fri, 21 Feb 2003 05:59:22 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id CBD5959AAE for ; Fri, 21 Feb 2003 10:59:23 +0000 (GMT) Message-ID: <011701c2d998$75619120$131010ac@aldebaran> From: "Philip Nye" To: References: <3E5114FC.1040703@sun.com> Subject: LL2 Date: Fri, 21 Feb 2003 11:00:34 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I reject LL2 I note that once again we have a text that combines two separate issues: > ...all nodes that implement this protocol MUST also > provide some mechanism to allow for routable addresses to be configured... and > ...Where that configuration > mechanism uses DHCP, the node MUST implement the DHCP option to disable > stateless auto-configuration in IPv4 clients [RFC2563]. I disagree with the second of these because it adds complexity for dubious gain, and therefore I cannot support LL2. I am currently undecided on the first issue which is roughly the same as LL27 Philip From owner-zeroconf@merit.edu Fri Feb 21 06:02:34 2003 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 GAA25709 for ; Fri, 21 Feb 2003 06:02:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6014E91299; Fri, 21 Feb 2003 06:05:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2982A912AE; Fri, 21 Feb 2003 06:05:37 -0500 (EST) 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 F355A91299 for ; Fri, 21 Feb 2003 06:05:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id D9ACD5DE35; Fri, 21 Feb 2003 06:05:35 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by segue.merit.edu (Postfix) with ESMTP id B84995DDBB for ; Fri, 21 Feb 2003 06:05:35 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mAzd-0004MF-00; Fri, 21 Feb 2003 03:05:25 -0800 Date: Fri, 21 Feb 2003 06:02:27 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, Erik.Guttman@Sun.COM, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030221060227.7bc6339e.moore@cs.utk.edu> In-Reply-To: <1045810765.14935.486.camel@devil> References: <1045776694.14935.56.camel@devil> <8B083511-4524-11D7-A12D-00039317663C@nominum.com> <20030220174934.10b52b2e.moore@cs.utk.edu> <1045810765.14935.486.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > 1) The attitude here is that "the problem" should be taken for granted. > Despite repeated requests, no compelling cases of common situations > where users would be seriously inconvenienced have been presented. This > fact merely strengthens my belief that "the problem" is in fact a fairly > minor one. I disagree with your assessment of what is "compelling" or "common". Users are seriously inconvenienced if the Internet is made less capable of supporting applications that don't exist yet, and there are compelling applications like conferencing and internet telephony that are made less deployable by use of scoped addresses. To claim otherwise is disingeneous. > 2) "The problem" is such a convenient one that we could debate it > endlessly and still not come up with a satisfactory solution. As such, > it simply delays the work of the WG and serves no useful purpose. The work of this WG is not to cripple the Internet. > > to reject LL23 is to make LL unsuitable for standardization. > > Hardly that. LL23 describes what is fundamentally an implementation > approach. Rejecting issue LL23 does not prevent OS vendors from applying > it in their implementation if they want to. There is no need to foist it > on OS vendors who don't. I refer you to RFC 2026's requirements for proposed standard, the part about "no known technical omissions". From owner-zeroconf@merit.edu Fri Feb 21 06:09:14 2003 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 GAA25807 for ; Fri, 21 Feb 2003 06:09:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C75C29127C; Fri, 21 Feb 2003 06:12:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9703F91286; Fri, 21 Feb 2003 06:12:58 -0500 (EST) 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 84EEF9127C for ; Fri, 21 Feb 2003 06:12:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6DBF05E038; Fri, 21 Feb 2003 06:12:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by segue.merit.edu (Postfix) with ESMTP id 4CEA25DDBB for ; Fri, 21 Feb 2003 06:12:57 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mB6r-0004eC-00; Fri, 21 Feb 2003 03:12:53 -0800 Date: Fri, 21 Feb 2003 06:09:55 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, zeroconf@merit.edu, zeroconf@merit.edu Subject: Re: [LL27]: LL-only hosts Message-Id: <20030221060955.1f141504.moore@cs.utk.edu> In-Reply-To: <3E55FCA9.7080000@sun.com> References: <20030218151219.6bb3b1e0.moore@cs.utk.edu> <20030220170138.391218ee.moore@cs.utk.edu> <3E55FCA9.7080000@sun.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > We will consider specific technical arguments as part of the call > for WG consensus on issues. Please be concrete - abstract evocation > of architectural disasters have less weight than a single example > of useful technology. Erik, I consider it inappropriate for you, as chair, to make such an assertion. There is no basis for such an assertion in IETF process. Giving direction to WG participants as to which criteria they may use in making judgements as to the suitability of this proposal for standardization is a process error. Arguments about specific problems are more easily dismissed than general architectural arguments. Almost any specific example can be dismissed as irrelevant, but a general problem that applies to multiple applications should not be so easily dismissed. Keith From owner-zeroconf@merit.edu Fri Feb 21 07:43:13 2003 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 HAA27891 for ; Fri, 21 Feb 2003 07:43:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7013991288; Fri, 21 Feb 2003 07:46:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D1059128A; Fri, 21 Feb 2003 07:46:55 -0500 (EST) 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 A682F91288 for ; Fri, 21 Feb 2003 07:46:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9DDFC5DDAB; Fri, 21 Feb 2003 07:46:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 172165E146 for ; Fri, 21 Feb 2003 07:46:22 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1LCkId21234; Fri, 21 Feb 2003 19:46:18 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1LCk2o23110; Fri, 21 Feb 2003 19:46:02 +0700 (ICT) From: Robert Elz To: Bernard Aboba Cc: zeroconf@merit.edu Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Feb 2003 19:46:02 +0700 Message-ID: <23108.1045831562@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 20 Feb 2003 04:55:05 -0800 (PST) From: Bernard Aboba Message-ID: | You are effectively using DHCP as a form of LAN access control. Not really, but something like that. | I don't believe that this is one of the intended uses of this protocol, Not answering requests for addresses has always been an option for a DHCP server. Do your DHCP servers allocate addresses upon request for anything and everything that asks? Even those absurd RAS servers that keep on asking for addresses when (accidentally) enabled? Most people don't... This isn't really access control though, as it controls nothing, it doesn't prevent a node from accessing the net, or inventing its own address to do do. It is no more than advising the node what the DHCP server (ie: the network administrator) believes should be done. | I would claim that any option that can disable a host in a substantial way | should require DHCP authentication. That's DHCP. It is DHCP that can disable the host in a substantial way, using any of its abilities (supplying a bogus address for the default router will do quite a bit of damage, supplying a bogus address for the node to use will do more). 2563 itself does nothing new. If you want to argue that using DHCP should require DHCP authentication, please do so, but do it in the DHC WG. | The scenario you described is not a zeroconf scenario. It is a scenario in | which an admin attempts to use DHCP for access control. There are two aspects to zeroconf. One where there is no configuration anywhere, and the other where there is no configuration on the node, but there is config on the net. The same nodes need to be able to operate in both environments - since the node has no configuration it cannot act differently on a net that has no config from one which does. Hence, it is important that the way it acts be compatible with both environments. | Show me an example of a host that actually operates this way. I don't know | of any. Because we have no hosts using 2563 currently (that I know of anyway). Were there any, that didn't operate that way, then they should be fixed. | Great, so you don't get an IP address -- but you still have connectivity | to AppleTalk, IPX, and NetBEUI. If the operation that the user is doing | happens to activate one of those protocols, things will still work. So | does this accomplish the goal of controlling access to the network? It doesn't. It's you who believe that this has something to do with controlling access to the net (you concluded that above). I keep saying that it does not - controlling access isn't what I want to do. But you look at the mechanisms, see that it looks a bit like access control, show that it doesn't work as access control, and hence conclude that it is useless... that's a very poor argument. The aim is to advise the node what is appropriate for it to use on the LAN it happens to have been connected to. If that is "nothing" (in some cases) there really should be a way to say that, shouldn't there? kre From owner-zeroconf@merit.edu Fri Feb 21 07:45:21 2003 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 HAA27996 for ; Fri, 21 Feb 2003 07:45:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3CE3F9128A; Fri, 21 Feb 2003 07:49:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F25709128B; Fri, 21 Feb 2003 07:49:05 -0500 (EST) 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 CE1CF9128A for ; Fri, 21 Feb 2003 07:49:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id B145D5E087; Fri, 21 Feb 2003 07:49:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 390725DF61 for ; Fri, 21 Feb 2003 07:49:04 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08386; Fri, 21 Feb 2003 04:49:02 -0800 (PST) Received: from sun.com (vpn-129-159-0-192.EMEA.Sun.COM [129.159.0.192]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1LCmil08034; Fri, 21 Feb 2003 13:49:00 +0100 (MET) Message-ID: <3E561FE4.7070701@sun.com> Date: Fri, 21 Feb 2003 13:47:32 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Philip Nye Cc: Zeroconf Working Group Subject: Re: LL1, LL23 References: <1045776694.14935.56.camel@devil> <8B083511-4524-11D7-A12D-00039317663C@nominum.com> <20030220174934.10b52b2e.moore@cs.utk.edu> <1045810765.14935.486.camel@devil> <006c01c2d992$fdb008a0$131010ac@aldebaran> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Philip, [WG hat off] I agree with your assessment. The problems caused by apps being run by hosts who are in different scopes is real. Since LL19 was rejected, we must consider how to contain them. I completely agree with Stuart: there has been nothing specific said about what the risks are. We will have to take this up soon in other issues (specific applications which are at risk or not at risk). To support your statement, we need to bring up concrete examples of apps which would break in mixed-scope environments - so we can get away from admonishments and dismissals of abstract risks. A B C D +----+-R-[network]-R-+---+ A is a host running a HTTP service - with a link local scope address B is a http proxy - on the same link as A with a global scope address C is a http client on a different link with a global scope address D is a host with a link-local scope address (same as A's) C contacts B requesting an HTML document. B contacts A and retrieves the document, sending it to C. There are many modes in which C cannot now get the rest of the document. B goes away, for example, or C follows a link in the document it received to obtain data directly from A. C could also attempt to reach A and get a completely different host D on the link where C is located, which also cannot return the document requested. This is not a HTTP specific issue. It is possible to create examples of many other services in which referrals, pointers, links, redirects and locators will fail. These examples are harder for me to construct (SMTP, LDAP, SIP, FTP, IPP... are likely brittle in this regard). Please either give concrete examples or continue discussing the example above. Erik ----------------------------------------------------------- Philip Nye wrote: >>From: "Ted Lemon" >> >>I agree with Mika on this one. I think we should just drop LL1 and >>LL23. > > > We are in severe danger of starting round the same futile loop once again. > > It is only a month ago or so that this list seemed to have finally accepted > the principle that running both LL and routable addresses together in a host > on a routed network is A BAD IDEA, largely because of apparently > unresolvable issues for applications. > > We also recognised that it is not possible to stop this case altogether > because of transitions but that the best compromise is for hosts to cease > using LL addresses if they have a routable one and to stick to the principle > of just one address per interface (multihoming for other reasons excepted). > This has given rise to LL1 and LL23 which are both variations on precisely > how to do this. > > LL1 is more brutal. LL23 attempts to spell things out more and to soften the > disruption when an operating LL host gains a configured address. > > Personally I see little to choose between them and if someone wants to > suggest a better way to make this happen then fine. But if we are to go back > round the loop on the idea of running LL and routable addresses concurrently > then someone had better bring something new to the table! > > Philip > From owner-zeroconf@merit.edu Fri Feb 21 07:50:05 2003 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 HAA28084 for ; Fri, 21 Feb 2003 07:50:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 275E99128B; Fri, 21 Feb 2003 07:53:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E4F139128C; Fri, 21 Feb 2003 07:53:48 -0500 (EST) 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 EB57C9128B for ; Fri, 21 Feb 2003 07:53:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id D93B65E087; Fri, 21 Feb 2003 07:53:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 3BB205DF61 for ; Fri, 21 Feb 2003 07:53:46 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1LCrVd26505; Fri, 21 Feb 2003 19:53:34 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1LCr8o23125; Fri, 21 Feb 2003 19:53:09 +0700 (ICT) From: Robert Elz To: Ted Lemon Cc: "Philip Nye" , "Zeroconf Working Group" Subject: Re: LL1, LL23 In-Reply-To: <9C758E90-44E9-11D7-B7DF-00039317663C@nominum.com> References: <9C758E90-44E9-11D7-B7DF-00039317663C@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Feb 2003 19:53:08 +0700 Message-ID: <23123.1045831988@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 20 Feb 2003 08:40:17 -0700 From: Ted Lemon Message-ID: <9C758E90-44E9-11D7-B7DF-00039317663C@nominum.com> | The problem I have with language like this is that it requires the | IPv4ll agent to have its hands too deeply in the guts of the routing | table code. I don't think so. But all of this is in the IP layer anyway, if needed, routing table code, and/or ARP access, needs to be available (v4LL can't function if the LL code can't interface to ARP). Discovering what is the IP address of the default router isn't what most people would regard as "deep in the guts of the routing code", and (aside from the ability to ARP) that's all that was requested here. It also isn't really the LL module that needs to do this, but the address management module. That is, something needs to be done when a node moves from one LAN to another in any case - just continuing to use your old address (whether DHCP assigned, or LL) without verifying it isn't going to work. There needs to be code to take care of these issues. When appropriate that code will invoke the LL module to assign an LL address. | What MacOS X does is to [...] That sounds broken to me. Demonstrating that it is possible to do something badly doesn't mean that the idea is poor, just the particular implementation. Nothing requires a node to cease using an address, or break any connections, just because a DHCP server doesn't respond. kre From owner-zeroconf@merit.edu Fri Feb 21 08:40:27 2003 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 IAA29126 for ; Fri, 21 Feb 2003 08:40:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 02B059128C; Fri, 21 Feb 2003 08:44:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C24A291292; Fri, 21 Feb 2003 08:44:08 -0500 (EST) 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 BE8A19128C for ; Fri, 21 Feb 2003 08:44:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9CCB75E167; Fri, 21 Feb 2003 08:44:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 290995E163 for ; Fri, 21 Feb 2003 08:44:07 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1LCO5O26722; Fri, 21 Feb 2003 04:24:05 -0800 Date: Fri, 21 Feb 2003 04:24:05 -0800 (PST) From: Bernard Aboba To: Robert Elz Cc: zeroconf@merit.edu Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL In-Reply-To: <23108.1045831562@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > This isn't really access control though, as it controls nothing, it > doesn't prevent a node from accessing the net, or inventing its own > address to do so. Right. > The aim is to advise the node what is appropriate for it to use on the > LAN it happens to have been connected to. If that is "nothing" (in > some cases) there really should be a way to say that, shouldn't there? It seems like what you actually want is a DHCP option to display a message to the user saying "You shouldn't be on Network X". Then you wouldn't get the support call that is the issue here. Assuming that this capability was available, why would RFC 2563 also be needed in the scenario you describe? From owner-zeroconf@merit.edu Fri Feb 21 09:28:13 2003 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 JAA01329 for ; Fri, 21 Feb 2003 09:28:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A5A8991294; Fri, 21 Feb 2003 09:31:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B07091298; Fri, 21 Feb 2003 09:31:46 -0500 (EST) 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 6DEAE91294 for ; Fri, 21 Feb 2003 09:31:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id A7C695E175; Fri, 21 Feb 2003 09:31:18 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 0B0E55E171 for ; Fri, 21 Feb 2003 09:31:17 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1LEV6d29620; Fri, 21 Feb 2003 21:31:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1LEUvo24420; Fri, 21 Feb 2003 21:31:00 +0700 (ICT) From: Robert Elz To: Bernard Aboba Cc: zeroconf@merit.edu Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Feb 2003 21:30:57 +0700 Message-ID: <24418.1045837857@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 21 Feb 2003 04:24:05 -0800 (PST) From: Bernard Aboba Message-ID: | It seems like what you actually want is a DHCP option to display a message | to the user saying "You shouldn't be on Network X". Then you wouldn't get | the support call that is the issue here. Assuming that this capability was | available, why would RFC 2563 also be needed in the scenario you describe? Yes, that would be useful. Of course, it would need to be a code, we don't want to embed English in messages to be displayed to the user. And if it is going to be encoded, what's wrong with the encoding in 2563? That is essentially telling the client that "you shouldn't be on this LAN". Having the client (assuming it is this kind of client - there are clients without displays remember) respond to that as you suggest would be an entirely sensible thing for it to do. kre From owner-zeroconf@merit.edu Fri Feb 21 09:45:05 2003 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 JAA01671 for ; Fri, 21 Feb 2003 09:45:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 17B5391298; Fri, 21 Feb 2003 09:48:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D146A9129A; Fri, 21 Feb 2003 09:48:39 -0500 (EST) 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 12C8591298 for ; Fri, 21 Feb 2003 09:47:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id D77B55DE3B; Fri, 21 Feb 2003 09:47:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by segue.merit.edu (Postfix) with ESMTP id 662455DDF8 for ; Fri, 21 Feb 2003 09:47:26 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h1LElOJR022659 for ; Fri, 21 Feb 2003 09:47:24 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-251.cisco.com [161.44.149.251]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA19525 for ; Fri, 21 Feb 2003 09:47:23 -0500 (EST) Message-Id: <4.3.2.7.2.20030221093548.03ebaac8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Feb 2003 09:47:22 -0500 To: zeroconf@merit.edu From: Ralph Droms Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL In-Reply-To: <24418.1045837857@munnari.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk We almost already have the right pieces in DHCP...the "Message" option (option code 56) "is used by a DHCP server to provide an error message to a DHCP client" [RFC2132, sec. 9.99]. Unfortunately, the "Message" option is only allowed to appear in a DHCPNAK message, and we don't have a way to send an explicit NAK, meaning "You shouldn't be on this link", to a newly booting client (that sent a DHCPDISCOVER message). A DHCP server can send a DHCPNAK message in response to a DHCPREQUEST message, so the following sequence would be OK (although ugly; the bogus address is just a placeholder because the client is expecting something in 'yiaddr' in the DHCPOFFER message): Client Server ------ ------ DHCPDISCOVER ---------------> DHCPOFFER, yiaddr = bogus <--------------- DHCPREQUEST requested IP address = bogus ---------------> DHCPNAK, Message = "Go away" <--------------- And, a server can send a DHCPNAK in response to a rebooting client that begins by sending a DHCPREQUEST message. If it would be useful to allow a server to respond with a DHCPNAK to a DHCPDISCOVER, we can certainly explore the idea in the dhc WG. - Ralph At 09:30 PM 2/21/2003 +0700, Robert Elz wrote: > Date: Fri, 21 Feb 2003 04:24:05 -0800 (PST) > From: Bernard Aboba > Message-ID: > > | It seems like what you actually want is a DHCP option to display a > message > | to the user saying "You shouldn't be on Network X". Then you wouldn't get > | the support call that is the issue here. Assuming that this > capability was > | available, why would RFC 2563 also be needed in the scenario you > describe? > >Yes, that would be useful. Of course, it would need to be a code, >we don't want to embed English in messages to be displayed to the user. > >And if it is going to be encoded, what's wrong with the encoding in 2563? > >That is essentially telling the client that "you shouldn't be on this LAN". >Having the client (assuming it is this kind of client - there are clients >without displays remember) respond to that as you suggest would be an >entirely sensible thing for it to do. > >kre From owner-zeroconf@merit.edu Fri Feb 21 11:27:11 2003 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 LAA05590 for ; Fri, 21 Feb 2003 11:27:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DDA829129F; Fri, 21 Feb 2003 11:30:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B889912A2; Fri, 21 Feb 2003 11:30:16 -0500 (EST) 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 E30E19129F for ; Fri, 21 Feb 2003 11:30:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8AA9C5DDCD; Fri, 21 Feb 2003 11:30:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id DE1185DDB8 for ; Fri, 21 Feb 2003 11:30:11 -0500 (EST) Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1LGRON24880; Fri, 21 Feb 2003 10:27:24 -0600 (CST) Date: Fri, 21 Feb 2003 09:30:04 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Zeroconf Working Group" To: "Philip Nye" From: Ted Lemon In-Reply-To: <006c01c2d992$fdb008a0$131010ac@aldebaran> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > It is only a month ago or so that this list seemed to have finally > accepted > the principle that running both LL and routable addresses together in > a host > on a routed network is A BAD IDEA, largely because of apparently > unresolvable issues for applications. The list doesn't accept anything. Individual members of the list accept arguments. For me, what happened a month ago is that I decided to stop arguing about it because I couldn't think of any reason other than personal prejudice why this position was incorrect. I didn't feel that it was right for me to try to sway the group toward my own personal preferences when I couldn't justify them. Further debate with kre and various others has helped to clarify my thinking on this point. I now understand precisely why it is a bad idea for an IPv4ll host to relinquish its IPv4ll address when it gets a routable address. So I no longer feel that I have to censor myself, since I have a logical basis for asserting that this is so. So in my mind, rejecting LL1 and LL23 represents forward progress. From owner-zeroconf@merit.edu Fri Feb 21 11:31:54 2003 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 LAA05738 for ; Fri, 21 Feb 2003 11:31:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BEF22912A2; Fri, 21 Feb 2003 11:35:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 903E1912A4; Fri, 21 Feb 2003 11:35:36 -0500 (EST) 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 92987912A2 for ; Fri, 21 Feb 2003 11:35:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 66CF35E0CF; Fri, 21 Feb 2003 11:35:35 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 0DF3F5DE9D for ; Fri, 21 Feb 2003 11:35:35 -0500 (EST) Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1LGWlN24940; Fri, 21 Feb 2003 10:32:48 -0600 (CST) Date: Fri, 21 Feb 2003 09:35:28 -0700 Subject: Re: LL2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Philip Nye" From: Ted Lemon In-Reply-To: <011701c2d998$75619120$131010ac@aldebaran> Message-Id: <7C7E6AC5-45BA-11D7-A12D-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I disagree with the second of these because it adds complexity for > dubious > gain, and therefore I cannot support LL2. I also reject LL2, for the same reasons you've stated. I think perhaps we should add a new issue that proposes a change similar to the first part of LL2, though. The text proposed in LL2 is: >> ...all nodes that implement this protocol MUST also >> provide some mechanism to allow for routable addresses to be >> configured... I'm suggesting that it should be this instead: >> ...nodes that implement this protocol SHOULD also >> provide some mechanism to allow for routable addresses to be >> configured... From owner-zeroconf@merit.edu Fri Feb 21 11:48:08 2003 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 LAA06474 for ; Fri, 21 Feb 2003 11:48:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7BBD6912A4; Fri, 21 Feb 2003 11:51:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D271912A5; Fri, 21 Feb 2003 11:51:51 -0500 (EST) 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 59C8C912A4 for ; Fri, 21 Feb 2003 11:51:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F7C55DF74; Fri, 21 Feb 2003 11:51:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id E15C25DE9D for ; Fri, 21 Feb 2003 11:51:49 -0500 (EST) Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1LGn2N25050 for ; Fri, 21 Feb 2003 10:49:03 -0600 (CST) Date: Fri, 21 Feb 2003 09:51:43 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030221060227.7bc6339e.moore@cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I refer you to RFC 2026's requirements for proposed standard, the part > about > "no known technical omissions". This does not compel us to accept LL23. You could argue on the basis of the text you're quoting that if we do not accept LL1 or LL23, we need to have a note explaining the issues you've raised, and how vendors and applications should deal with them. From owner-zeroconf@merit.edu Fri Feb 21 12:08:33 2003 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 MAA07205 for ; Fri, 21 Feb 2003 12:08:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DC5FA912A5; Fri, 21 Feb 2003 12:12:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1BE2912A6; Fri, 21 Feb 2003 12:12:14 -0500 (EST) 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 8FC9A912A5 for ; Fri, 21 Feb 2003 12:12:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6AC005E13D; Fri, 21 Feb 2003 12:12:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id CD6645E137 for ; Fri, 21 Feb 2003 12:12:12 -0500 (EST) Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1LH9ON26073; Fri, 21 Feb 2003 11:09:24 -0600 (CST) Date: Fri, 21 Feb 2003 10:12:04 -0700 Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu, Bernard Aboba To: Robert Elz From: Ted Lemon In-Reply-To: <23108.1045831562@munnari.OZ.AU> Message-Id: <99984944-45BF-11D7-A12D-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > That's DHCP. It is DHCP that can disable the host in a substantial > way, using any of its abilities (supplying a bogus address for the > default router will do quite a bit of damage, supplying a bogus address > for the node to use will do more). 2563 itself does nothing new. This is one of the reasons why I reject LL1 and LL23 - without these two changes, the IPv4ll failure mode you're talking about isn't possible, whether through happenstance or a deliberate attempt to deny service. RFC2563 is in fact the innovation, because it predates these two proposals. > The aim is to advise the node what is appropriate for it to use on the > LAN it happens to have been connected to. If that is "nothing" (in > some cases) there really should be a way to say that, shouldn't there? As with any proposal, we have to weigh the pros and cons. The pro here is what you are stating - that the administrator can advise the client as to the administrator's preferences. The con here is that if the client always follows this kind of advice, it will be easy to gull the client into not using the network in situations where the client in fact has every right to use the network. So on the one hand, we give the network administrator the opportunity to state a preference, which the client may or may not follow. On the other, we have an easy DoS attack. To me, the drawbacks of this approach strongly outweigh the benefits. There is no significant demand for RFC2563 - if there were, it would have been implemented. During my tenure as the ISC DHCP server author and maintainer, I was never asked to provide this capability. No existing client supports it - not even the open source clients, which easily could. Again, I've never even been asked about it for the ISC DHCP client, even though the ISC DHCP client works on MacOS X and could be used to disable IPv4ll there. Bernard Aboba, who has a much larger user base than I do, says he hasn't seen any demand either. I realize that there are several people on this mailing list who want this feature, so in that sense there is some demand. However, despite the fact that Windows and Mac are very popular, you seem to have survived so far without it. What is the compelling need for this feature that makes it worth our while to open the protocol to an easy DoS attack that is difficult to counter and difficult to trace? From owner-zeroconf@merit.edu Fri Feb 21 12:20:31 2003 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 MAA07577 for ; Fri, 21 Feb 2003 12:20:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0342F912B1; Fri, 21 Feb 2003 12:22:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC39D912A8; Fri, 21 Feb 2003 12:22:51 -0500 (EST) 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 28837912B1 for ; Fri, 21 Feb 2003 12:22:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1513A5E140; Fri, 21 Feb 2003 12:22:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id C82C25E13D for ; Fri, 21 Feb 2003 12:22:44 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1LHNKaj022162; Fri, 21 Feb 2003 19:23:20 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1LHNHJk022158; Fri, 21 Feb 2003 19:23:17 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: Ted.Lemon@nominum.com, Erik.Guttman@Sun.COM, philip@engarts.com, zeroconf@merit.edu In-Reply-To: <20030221060227.7bc6339e.moore@cs.utk.edu> References: <1045776694.14935.56.camel@devil> <8B083511-4524-11D7-A12D-00039317663C@nominum.com> <20030220174934.10b52b2e.moore@cs.utk.edu> <1045810765.14935.486.camel@devil> <20030221060227.7bc6339e.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045848196.22035.8.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2003 19:23:17 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-02-21 at 13:02, Keith Moore wrote: > > 1) The attitude here is that "the problem" should be taken for granted. > > Despite repeated requests, no compelling cases of common situations > > where users would be seriously inconvenienced have been presented. This > > fact merely strengthens my belief that "the problem" is in fact a fairly > > minor one. > > I disagree with your assessment of what is "compelling" or "common". > Users are seriously inconvenienced if the Internet is made less capable > of supporting applications that don't exist yet, That is a fine abstract argument against scoped addressing in general but it is of no help whatsoever when trying to decide whether proposals like LL1 and LL23 are technically sound. I call again for you and others to present some concrete cases, so that we can assess them on factual basis. MikaL From owner-zeroconf@merit.edu Fri Feb 21 12:24:08 2003 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 MAA07746 for ; Fri, 21 Feb 2003 12:24:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BFFFC912A8; Fri, 21 Feb 2003 12:27:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B76E912A9; Fri, 21 Feb 2003 12:27:51 -0500 (EST) 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 91DBA912A8 for ; Fri, 21 Feb 2003 12:27:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 837155E140; Fri, 21 Feb 2003 12:27:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 0103F5E13D for ; Fri, 21 Feb 2003 12:27:49 -0500 (EST) Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1LHP0N26262; Fri, 21 Feb 2003 11:25:01 -0600 (CST) Date: Fri, 21 Feb 2003 10:27:41 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Philip Nye" , "Zeroconf Working Group" To: Robert Elz From: Ted Lemon In-Reply-To: <23123.1045831988@munnari.OZ.AU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > That sounds broken to me. Demonstrating that it is possible to > do something badly doesn't mean that the idea is poor, just the > particular implementation. > > Nothing requires a node to cease using an address, or break any > connections, just because a DHCP server doesn't respond. I don't know what the implementors at Apple had in mind, but it looks like Apple is forced to do this because they have chosen not to keep their IPv4ll address around all the time. A network carrier transition, up to down and then down to up, implies that the client has been connected to a new network. In the case that the device has simply been moved to a new physical location and plugged into the same network, assuming that the client is on a new network is a mistake. However, this is the less likely case - usually when you move a device around, it's connected to a different network. If Apple assumes the device is connected to the same network, IPv4ll won't work until the DHCP lease expires. If they assume that the device is connected to a different network, IPv4ll will work immediately. So they make the assumption that is most likely to be correct, and get good performance in that case, at the expense of somewhat pathological performance in the case where their guess is wrong. If we accept LL1 and LL23, everybody who implements IPv4ll has to make this choice. If we reject them, then no such choice has to be made - the IPv4ll and DHCP state machines can be completely separate, and so IPv4ll can work immediately after a link state transition, whilst DHCP follows the usual rules and also continues to work after the link state transition. From owner-zeroconf@merit.edu Fri Feb 21 12:32:31 2003 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 MAA07971 for ; Fri, 21 Feb 2003 12:32:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 15C93912AA; Fri, 21 Feb 2003 12:36:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5736912AC; Fri, 21 Feb 2003 12:36:13 -0500 (EST) 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 29889912AA for ; Fri, 21 Feb 2003 12:34:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id DD68D5DE42; Fri, 21 Feb 2003 12:34:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 9DD765DE1E for ; Fri, 21 Feb 2003 12:34:24 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1LHZ5aj022214; Fri, 21 Feb 2003 19:35:05 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1LHZ48e022211; Fri, 21 Feb 2003 19:35:04 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Erik Guttman Cc: Philip Nye , Zeroconf Working Group In-Reply-To: <3E561FE4.7070701@sun.com> References: <1045776694.14935.56.camel@devil> <8B083511-4524-11D7-A12D-00039317663C@nominum.com> <20030220174934.10b52b2e.moore@cs.utk.edu> <1045810765.14935.486.camel@devil> <006c01c2d992$fdb008a0$131010ac@aldebaran> <3E561FE4.7070701@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045848903.22159.25.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2003 19:35:04 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-02-21 at 14:47, Erik Guttman wrote: > To support your statement, we need to bring up concrete examples > of apps which would break in mixed-scope environments - so we can > get away from admonishments and dismissals of abstract risks. I support this wholeheartedly. Let's discuss concrete issues instead of ideology. > > A B C D > +----+-R-[network]-R-+---+ > > A is a host running a HTTP service - with a link local scope address > B is a http proxy - on the same link as A with a global scope address > C is a http client on a different link with a global scope address > D is a host with a link-local scope address (same as A's) > > C contacts B requesting an HTML document. B contacts A and > retrieves the document, sending it to C. > > There are many modes in which C cannot now get the rest of > the document. B goes away, for example, or C follows a link > in the document it received to obtain data directly from A. > C could also attempt to reach A and get a completely different > host D on the link where C is located, which also cannot return > the document requested. This example has two v4LL-only nodes and therefore has problems. This clearly argues against LL23. If nodes A and D had LL and routable addresses both, would the problem still exist? MikaL From owner-zeroconf@merit.edu Fri Feb 21 13:16:22 2003 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 NAA09714 for ; Fri, 21 Feb 2003 13:16:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 346C2912B0; Fri, 21 Feb 2003 13:19:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1B51912B2; Fri, 21 Feb 2003 13:19:56 -0500 (EST) 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 15B3F912B0 for ; Fri, 21 Feb 2003 13:18:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id EA1075E13D; Fri, 21 Feb 2003 13:18:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 5CE0B5DF61 for ; Fri, 21 Feb 2003 13:18:08 -0500 (EST) Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1LIFKN26774 for ; Fri, 21 Feb 2003 12:15:20 -0600 (CST) Date: Fri, 21 Feb 2003 11:18:01 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: Zeroconf Working Group Content-Transfer-Encoding: 7bit In-Reply-To: <1045848903.22159.25.camel@devil> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > This example has two v4LL-only nodes and therefore has problems. This > clearly argues against LL23. If nodes A and D had LL and routable > addresses both, would the problem still exist? Another way to put this is that the example shows a case where communications between an off-link node and a node that has only an IPv4ll address fails. But why is B proxying A in the first place? Is it accidental? I don't see how this would happen. If the idea is that A has both an IPv4ll address and an IPv4 global address, and that A put its IPv4ll address instead of its domain name or global IP address into a web page, I can see where this would be a problem, but it's a violation of accepted practice in setting up web pages anyway - generally it's poor form to hard-code IP addresses or even domain names into an HTML referral. This causes no end of problems even in situations where the HTTP server has an unscoped IP address. Furthermore, it's unlikely that anybody would hand-code an IPv4ll address into a web page. So the only way for this to happen is for a CGI script that generates the web page to generate a bogus HREF. I don't think this is a likely scenario. In this case, in order to accept that this describes a real problem, I'd want to see an actual example of a real-world application making this mistake, and then we could analyze why it made the mistake, how likely such a mistake is, and how the mistake could be prevented. From owner-zeroconf@merit.edu Fri Feb 21 14:03:39 2003 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 OAA11301 for ; Fri, 21 Feb 2003 14:03:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ACDD1912B7; Fri, 21 Feb 2003 14:07:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84812912B8; Fri, 21 Feb 2003 14:07:15 -0500 (EST) 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 A7511912B7 for ; Fri, 21 Feb 2003 14:07:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 97DD65E180; Fri, 21 Feb 2003 14:07:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 1526E5E08B for ; Fri, 21 Feb 2003 14:07:14 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27673; Fri, 21 Feb 2003 11:07:12 -0800 (PST) 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 h1LJ7Al28176; Fri, 21 Feb 2003 20:07:10 +0100 (MET) Date: Fri, 21 Feb 2003 20:07:08 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Robert Elz Cc: Bernard Aboba , zeroconf@merit.edu Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL In-Reply-To: <23108.1045831562@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Fri, 21 Feb 2003, Robert Elz wrote: > The aim is to advise the node what is appropriate for it to use on the > LAN it happens to have been connected to. We understand this is your aim. What is the justification for adding 'LAN policy awareness management' (if there is such a thing) to the charter of this working group? How specifically does a node being 'advised' or not affect the ability for nodes implementing this spec to communicate with each other? Remember 'good ideas' are out of scope unless they answer IESG issues (posted to the list last October) or they have such a clear and strong rationale they can engender WG consensus. Erik From owner-zeroconf@merit.edu Fri Feb 21 14:17:18 2003 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 OAA11790 for ; Fri, 21 Feb 2003 14:17:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3AD89912B9; Fri, 21 Feb 2003 14:21:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A7AE912BA; Fri, 21 Feb 2003 14:20:59 -0500 (EST) 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 28B30912B9 for ; Fri, 21 Feb 2003 14:20:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0E0595E08B; Fri, 21 Feb 2003 14:20:35 -0500 (EST) 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 D3E015DE52 for ; Fri, 21 Feb 2003 14:20:34 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 9780159AEC for ; Fri, 21 Feb 2003 19:20:37 +0000 (GMT) Message-ID: <021701c2d9de$79e1bf40$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: Subject: Re: LL1, LL23 Date: Fri, 21 Feb 2003 19:21:46 -0000 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 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Ted Lemon" > ... But why is B proxying A in the first place? > Is it accidental? I don't see how this would happen. In general because the proxy app in B and the HTTP server in A don't know anything about scoped addresses. > generally it's poor form to hard-code IP addresses or > even domain names into an HTML referral. This sort of thing happens when a dynamic web page is created in response to conditions discovered locally. For example - I have a NAT router which displays ARP tables on a web page. It doesn't actually make links to them, but some other configuration page might well do so. Philip From owner-zeroconf@merit.edu Fri Feb 21 14:41:45 2003 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 OAA12512 for ; Fri, 21 Feb 2003 14:41:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E99DC912BA; Fri, 21 Feb 2003 14:42:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B311E912BF; Fri, 21 Feb 2003 14:42:38 -0500 (EST) 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 4A547912BA for ; Fri, 21 Feb 2003 14:42:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3A52E5E08B; Fri, 21 Feb 2003 14:42:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id AD64D5DFE6 for ; Fri, 21 Feb 2003 14:42:35 -0500 (EST) Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1LJdkN27665; Fri, 21 Feb 2003 13:39:47 -0600 (CST) Date: Fri, 21 Feb 2003 12:42:28 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Zeroconf Working Group" To: "Philip Nye" From: Ted Lemon In-Reply-To: <021701c2d9de$79e1bf40$131010ac@aldebaran> Message-Id: <9C1B4A52-45D4-11D7-A12D-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> From: "Ted Lemon" >> ... But why is B proxying A in the first place? >> Is it accidental? I don't see how this would happen. > > In general because the proxy app in B and the HTTP server in A don't > know > anything about scoped addresses. I don't mean in general. I mean specifically. How does B know that A is an http server? Was B configured to proxy A? Did it discover it automatically? How? > For example - I have a NAT router which displays ARP tables on a web > page. > It doesn't actually make links to them, but some other configuration > page > might well do so. That's true, but a web page on a web server can refer to another web page on the same server without specifying an IP address, and this is generally the best way to do it. You say to refer to /foo.html, rather than saying ''. You would never say ''. So I'm looking for a specific example where an HTTP server would generate a reference to a page by providing an IPv4ll address. The reason it's important to have specific examples is that we've been told that this is a significant problem, and that we should act on it as if it is a significant problem. So if nobody can come up with a specific example of where the problem would happen, then the assertion that the problem is significant is clearly called into question. Such an assertion can't logically be used as a reason for justifying reducing the functionality of the protocol. From owner-zeroconf@merit.edu Fri Feb 21 15:10:58 2003 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 PAA13207 for ; Fri, 21 Feb 2003 15:10:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9F1D4912C1; Fri, 21 Feb 2003 15:14:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62428912C2; Fri, 21 Feb 2003 15:14:40 -0500 (EST) 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 6AE26912C1 for ; Fri, 21 Feb 2003 15:14:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A9725E08B; Fri, 21 Feb 2003 15:14:39 -0500 (EST) 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 1C95F5DE1A for ; Fri, 21 Feb 2003 15:14:39 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 6690559AEF for ; Fri, 21 Feb 2003 20:14:42 +0000 (GMT) Message-ID: <021f01c2d9e6$07d76fa0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <9C1B4A52-45D4-11D7-A12D-00039317663C@nominum.com> Subject: Re: LL1, LL23 Date: Fri, 21 Feb 2003 20:15:51 -0000 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 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Ted Lemon" > > I don't mean in general. I mean specifically. How does B know that > A is an http server? Was B configured to proxy A? Did it discover > it automatically? How? Some examples: 1. A is advertising a service via SLP 2. A is a printer and is discovered via a printer discovery protocol (e.g. CUPS) 3. A is found via a netbios There are lots of ways to discover hosts other than by DNS and many of them only give you an IP address. > > For example - I have a NAT router which displays ARP tables on a web > > page. > > It doesn't actually make links to them, but some other configuration > > page > > might well do so. > > That's true, but a web page on a web server can refer to another web > page on the same server without specifying an IP address, and this is > generally the best way to do it. You say to > refer to /foo.html, rather than saying ' HREF="http://myserver.example.com/foo.html">'. You would never say > ''. My point was that the router lists _other_ hosts on the local net by their IP address on an HTML page. It doesn't have any other information in that context except their MAC address. Philip From owner-zeroconf@merit.edu Fri Feb 21 15:46:12 2003 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 PAA14184 for ; Fri, 21 Feb 2003 15:46:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5233B912C5; Fri, 21 Feb 2003 15:49:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F779912C6; Fri, 21 Feb 2003 15:49:54 -0500 (EST) 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 2207C912C5 for ; Fri, 21 Feb 2003 15:49:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BF815DF58; Fri, 21 Feb 2003 15:49:53 -0500 (EST) 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 D049D5DE9A for ; Fri, 21 Feb 2003 15:49:52 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 6744F59AF5 for ; Fri, 21 Feb 2003 20:49:56 +0000 (GMT) Message-ID: <022d01c2d9ea$f3d2d350$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <9C1B4A52-45D4-11D7-A12D-00039317663C@nominum.com> Subject: LL1, LL23 and retrospectively LL19 Date: Fri, 21 Feb 2003 20:51:05 -0000 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 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Another example: A B(LL) C D +----+------+---+routing+---+ A, C and D have routable addresses B is LL only. A, B, C and D are running a collaborative service. 1. A and B communicate 2. B passes A's address on to C 3. C and A communicate 4. C passes A's address on to D 5. D communicates with A Under LL1/LL23 this all works even though B doesn't have global connectivity (no one would expect D to communicate successfully with B anyway). Under LL19 this would not work. Although A has a routable address it is A's LL address which gets propagated through the system because that is the address it used to communicate with B. It is already starting to break down at 3. because C only knows A by the LL address even though by LL19 rules it should be using a routable one. Philip From owner-zeroconf@merit.edu Fri Feb 21 15:52:59 2003 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 PAA14476 for ; Fri, 21 Feb 2003 15:52:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F2272912C6; Fri, 21 Feb 2003 15:56:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7547912C7; Fri, 21 Feb 2003 15:56:40 -0500 (EST) 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 7EFE8912C6 for ; Fri, 21 Feb 2003 15:56:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5B4FB5DF58; Fri, 21 Feb 2003 15:56:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 9CD305DE26 for ; Fri, 21 Feb 2003 15:56:38 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1LKvJaj023075; Fri, 21 Feb 2003 22:57:19 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1LKvISC023072; Fri, 21 Feb 2003 22:57:18 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Philip Nye Cc: Zeroconf Working Group In-Reply-To: <021f01c2d9e6$07d76fa0$131010ac@aldebaran> References: <9C1B4A52-45D4-11D7-A12D-00039317663C@nominum.com> <021f01c2d9e6$07d76fa0$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045861037.22626.48.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2003 22:57:17 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Discussing this particular example leads nowhere. The connectivity problem is caused by the fact that some of the nodes are LL-only. Neither LL1 nor LL23 can do anything to change that. Because of the above, I won't even *try* to figure out why anyone would consider this a compelling use case. First we need to see a plausible scenario with some of the following types of nodes: - a node having both LL and routable addresses - a LL compliant node having only a routable address - a non-LL compliant node having a routable address LL-only nodes should not be included. It is clear that referral apps will not work with them and there is nothing we can do about it. Therefore, they are out of scope for this exercise. Then we need to consider whether the scenario presents an actual use case. In order to qualify it should satisfy the following: - It is something that a number of people will clearly want to do - There is no other reasonable way to accomplish the same thing without running into referral problems Given the above we would have a plausible use case. Then we would need to consider, whether either LL1 or LL23 or actually solves the referral problem. Finally, we would need to evaluate whether the use case is compelling enough to warrant the medicine. LL1 and LL23 supporters are hereby called to build the use case. LL1 and LL23 opponents are hereby called to try and shoot it down. Let's try be specific with the arguments. MikaL On Fri, 2003-02-21 at 22:15, Philip Nye wrote: > > From: "Ted Lemon" > > > > I don't mean in general. I mean specifically. How does B know that > > A is an http server? Was B configured to proxy A? Did it discover > > it automatically? How? > > Some examples: > 1. A is advertising a service via SLP > 2. A is a printer and is discovered via a printer discovery protocol (e.g. > CUPS) > 3. A is found via a netbios > > There are lots of ways to discover hosts other than by DNS and many of them > only give you an IP address. > > > > For example - I have a NAT router which displays ARP tables on a web > > > page. > > > It doesn't actually make links to them, but some other configuration > > > page > > > might well do so. > > > > That's true, but a web page on a web server can refer to another web > > page on the same server without specifying an IP address, and this is > > generally the best way to do it. You say to > > refer to /foo.html, rather than saying ' > HREF="http://myserver.example.com/foo.html">'. You would never say > > ''. > > My point was that the router lists _other_ hosts on the local net by their > IP address on an HTML page. It doesn't have any other information in that > context except their MAC address. > > Philip > From owner-zeroconf@merit.edu Fri Feb 21 16:05:51 2003 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 QAA14897 for ; Fri, 21 Feb 2003 16:05:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 498D3912C8; Fri, 21 Feb 2003 16:09:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14D1A912C9; Fri, 21 Feb 2003 16:09:33 -0500 (EST) 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 15511912C8 for ; Fri, 21 Feb 2003 16:09:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id EACC25DE94; Fri, 21 Feb 2003 16:09:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 0BE595DE26 for ; Fri, 21 Feb 2003 16:09:31 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1LLAAaj023154; Fri, 21 Feb 2003 23:10:11 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1LLA6IR023153; Fri, 21 Feb 2003 23:10:06 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 and retrospectively LL19 From: Mika Liljeberg To: Philip Nye Cc: Zeroconf Working Group In-Reply-To: <022d01c2d9ea$f3d2d350$131010ac@aldebaran> References: <9C1B4A52-45D4-11D7-A12D-00039317663C@nominum.com> <022d01c2d9ea$f3d2d350$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045861805.22626.75.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2003 23:10:06 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-02-21 at 22:51, Philip Nye wrote: > Another example: > > A B(LL) C D > +----+------+---+routing+---+ > > A, C and D have routable addresses > B is LL only. > > A, B, C and D are running a collaborative service. > > 1. A and B communicate > 2. B passes A's address on to C > 3. C and A communicate > 4. C passes A's address on to D > 5. D communicates with A Ok. You've shown that it is possible to construe a theoretical scenario where there is a referral issue (although caused by a v4LL node). Now answer the following: Does this map into a specific real world application? Why does B only have a LL address? Why does B, having only a LL address, participate in a referral application? Is the use case common and compelling enough that complicating the specification with LL1 or LL23 is clearly justified, when we know there are unsolved issues with (at least) the LL23 solution (we haven't really considered LL1 in as much depth)? MikaL From owner-zeroconf@merit.edu Fri Feb 21 16:07:56 2003 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 QAA15029 for ; Fri, 21 Feb 2003 16:07:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 49BEB91206; Fri, 21 Feb 2003 16:11:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1793E912C9; Fri, 21 Feb 2003 16:11:38 -0500 (EST) 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 21B1691206 for ; Fri, 21 Feb 2003 16:11:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0A8B95DE94; Fri, 21 Feb 2003 16:11:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 764A75DE26 for ; Fri, 21 Feb 2003 16:11:36 -0500 (EST) Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1LL8lN28887 for ; Fri, 21 Feb 2003 15:08:48 -0600 (CST) Date: Fri, 21 Feb 2003 14:11:29 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: Zeroconf Working Group Content-Transfer-Encoding: 7bit In-Reply-To: <1045861037.22626.48.camel@devil> Message-Id: <0BD2EB73-45E1-11D7-A12D-00039317663C@nominum.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Then we need to consider whether the scenario presents an actual use > case. In order to qualify it should satisfy the following: > - It is something that a number of people will clearly want to do > - There is no other reasonable way to accomplish the same thing without > running into referral problems I think it's worth also considering cases where existing applications would break and it would not be easy to modify those applications so that they do not break. I don't think these are as compelling as cases where there is simply no other reasonable way to accomplish the same thing, but they're still interesting. From owner-zeroconf@merit.edu Fri Feb 21 16:19:43 2003 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 QAA15243 for ; Fri, 21 Feb 2003 16:19:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4317391213; Fri, 21 Feb 2003 16:23:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0CDD8912C9; Fri, 21 Feb 2003 16:23:24 -0500 (EST) 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 00A8891213 for ; Fri, 21 Feb 2003 16:23:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id D4D945DE87; Fri, 21 Feb 2003 16:23:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id D0EA05DE26 for ; Fri, 21 Feb 2003 16:23:22 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1LLO3aj023206; Fri, 21 Feb 2003 23:24:04 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1LLO2qJ023204; Fri, 21 Feb 2003 23:24:02 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Ted Lemon Cc: Zeroconf Working Group In-Reply-To: <0BD2EB73-45E1-11D7-A12D-00039317663C@nominum.com> References: <0BD2EB73-45E1-11D7-A12D-00039317663C@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045862641.22625.96.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 21 Feb 2003 23:24:01 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-02-21 at 23:11, Ted Lemon wrote: > I think it's worth also considering cases where existing applications > would break and it would not be easy to modify those applications so > that they do not break. I don't think these are as compelling as > cases where there is simply no other reasonable way to accomplish the > same thing, but they're still interesting. You're right, we should consider those as well. Existing applications make good use cases, and they become more compelling if there is no straightforward administrative recourse around the problem. MikaL From owner-zeroconf@merit.edu Fri Feb 21 17:00:25 2003 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 RAA16380 for ; Fri, 21 Feb 2003 17:00:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7CCBE91223; Fri, 21 Feb 2003 17:03:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31DE191224; Fri, 21 Feb 2003 17:03:59 -0500 (EST) 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 2F31991223 for ; Fri, 21 Feb 2003 17:03:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1032A5DFE6; Fri, 21 Feb 2003 17:03:57 -0500 (EST) 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 B4B615DFC2 for ; Fri, 21 Feb 2003 17:03:56 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 7A2C559904 for ; Fri, 21 Feb 2003 22:04:00 +0000 (GMT) Message-ID: <002901c2d9f5$4c939330$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <9C1B4A52-45D4-11D7-A12D-00039317663C@nominum.com> <022d01c2d9ea$f3d2d350$131010ac@aldebaran> <1045861805.22626.75.camel@devil> Subject: Re: LL1, LL23 and retrospectively LL19 Date: Fri, 21 Feb 2003 22:05:09 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Mika Liljeberg" > > On Fri, 2003-02-21 at 22:51, Philip Nye wrote: > > Another example: > > > > A B(LL) C D > > +----+------+---+routing+---+ > > > > A, C and D have routable addresses > > B is LL only. > > > > A, B, C and D are running a collaborative service. > > > > 1. A and B communicate > > 2. B passes A's address on to C > > 3. C and A communicate > > 4. C passes A's address on to D > > 5. D communicates with A > > Ok. You've shown that it is possible to construe a theoretical scenario > where there is a referral issue (although caused by a v4LL node). Now > answer the following: > > Does this map into a specific real world application? Keith has mentioned Netsolve and Gnutella (I think). I am not familiar with either. I have developed embedded applications which pass IP addresses around - they don't live in a world with DNS. However, these hosts don't all have to be running the same application. For example: A is a printer advertising itself via SLP B is running an SLP Directory Agent. C is running a web page with links to printers which it discovers through SLP > Why does B only have a LL address? Because the DHCP server didn't hand it an address. Or because it is an LL only device. Or because it has a manually configured address which worked doesn't work on this network. Or because it was in a transitional state at the time. > Why does B, having only a LL address, participate in a referral > application? Because the poor schmuck who is trying to use it is not a geek. And because the app doesn't know about scoped addresses - nor should it. > Is the use case common and compelling enough that complicating the > specification with LL1 or LL23 is clearly justified, when we know there > are unsolved issues with (at least) the LL23 solution (we haven't really > considered LL1 in as much depth)? The point is that addresses are acquired in lots of ways, not just through DNS or neat two way apps and since virtually nothing in IPv4 except routers considers the scope of an address before using it. You are right that this has to be balanced against other issues but I am not clear what simply maintaining a LL address alongside your routable one solves. If the stack and API successfully suppress the LL address in the presence of a routable one AND all hosts have routable addresses then it really doesn't matter whether those hosts are technically retaining their LL addresses or not - they just don't get used. However, the purpose of retaining them must be to use them and deciding where and when is a whole can of worms. Ted seems to be suggesting that if your routable configuration is not working, at least you still have LL. But if you can determine that your routable configuration is not working, then you can also choose to try reconfiguring and maybe end up with just LL. OTOH if you use your LL address even though your routable configuration is valid you run straight into the mixed scopes problems again. Philip From owner-zeroconf@merit.edu Fri Feb 21 17:40:00 2003 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 RAA17404 for ; Fri, 21 Feb 2003 17:39:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7F6BB912CA; Fri, 21 Feb 2003 17:43:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46A10912CC; Fri, 21 Feb 2003 17:43:43 -0500 (EST) 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 43128912CA for ; Fri, 21 Feb 2003 17:43:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A9B35E00B; Fri, 21 Feb 2003 17:43:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by segue.merit.edu (Postfix) with ESMTP id 487125DF7A for ; Fri, 21 Feb 2003 17:43:41 -0500 (EST) Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) with ESMTP id h1LMhUiC001752 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 22 Feb 2003 00:43:30 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) id h1LMhUsP001748; Sat, 22 Feb 2003 00:43:30 +0200 Date: Sat, 22 Feb 2003 00:43:30 +0200 Message-Id: <200302212243.h1LMhUsP001748@burp.tkv.asdf.org> From: Markku Savela To: philip@engarts.com Cc: zeroconf@merit.edu In-reply-to: <002901c2d9f5$4c939330$131010ac@aldebaran> (philip@engarts.com) Subject: Re: LL1, LL23 and retrospectively LL19 References: <9C1B4A52-45D4-11D7-A12D-00039317663C@nominum.com> <022d01c2d9ea$f3d2d350$131010ac@aldebaran> <1045861805.22626.75.camel@devil> <002901c2d9f5$4c939330$131010ac@aldebaran> Sender: owner-zeroconf@merit.edu Precedence: bulk > From: "Philip Nye" > > If the stack and API successfully suppress the LL address ... I thought the issue of this practise was to show us a real application where the stack retaining and fully using both LL and global address at same time would break something. So far this example only shows that bringing in LL-only node has problems. But this is nothing new. The only example I can find, that comes close is: A ----- B ---- router ---- C -- D On local net: A is host running IRC client B is host running IRC server On global internet C is host running IRC server D is host running IRC client B needs to have a global address to talk to C. But, if it also has LL address and accepts client connections to this LL address, then A can connect with LL address. The resulting problem is: if A initiates client-to-client DCC connection with D, it will probably take it's own address from the A-B connection and passes this within IRC message over to D. D will try to use this address to connect A. If A had only global address it would only connect with global address. The insteresting case is when A has both LL and global addresses, and the question: why did A pick LL instead of global? In my system this would depend in DNS resolver, and if B:s name resolves to global address, then it would have used global address anyway. If there is no global DNS, then it would try LLMNR and perhaps get LL address, things would work at least for normal IRC (only DCC requests out of site would fail -- as they fail with net-10 and kind addresses). Thus the text should not have any strong "SHOULD or MUST" that prevent simulataneous use of LL and gloabl address. There can be MAY for those operating systems that have problems handling multiple levels of DNS servers and scoped addressing. From owner-zeroconf@merit.edu Fri Feb 21 17:45:30 2003 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 RAA17576 for ; Fri, 21 Feb 2003 17:45:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B0CD0912D9; Fri, 21 Feb 2003 17:48:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A34C912D4; Fri, 21 Feb 2003 17:48:50 -0500 (EST) 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 CBD89912CE for ; Fri, 21 Feb 2003 17:48:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id B59765DE93; Fri, 21 Feb 2003 17:48:45 -0500 (EST) 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 87C975DDCF for ; Fri, 21 Feb 2003 17:48:45 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 9BE1859ACC for ; Fri, 21 Feb 2003 22:48:49 +0000 (GMT) Message-ID: <003f01c2d9fb$8f597b20$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <6B197570-45E4-11D7-A12D-00039317663C@nominum.com> Subject: Re: LL1, LL23 Date: Fri, 21 Feb 2003 22:49:58 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > ... If it has both an IPv4ll address and a global address, and > is contacting an SLP server that has a global address, why is it giving > the SLP server its IPv4ll address? In the beginning the app says to its OS "what is my IP address". This happens with lots of apps. The OS cannot answer "who do you want to send it to?" or "what do you want to do with it?". It cannot answer "local or global?". What does it answer? Philip From owner-zeroconf@merit.edu Fri Feb 21 17:48:20 2003 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 RAA17627 for ; Fri, 21 Feb 2003 17:48:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E68F1912CD; Fri, 21 Feb 2003 17:51:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5E1991210; Fri, 21 Feb 2003 17:51:54 -0500 (EST) 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 D5C70912CD for ; Fri, 21 Feb 2003 17:51:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id A245B5DFE6; Fri, 21 Feb 2003 17:51:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 7A9A85DE9C for ; Fri, 21 Feb 2003 17:51:38 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1LMqIaj023582; Sat, 22 Feb 2003 00:52:18 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1LMqGtS023581; Sat, 22 Feb 2003 00:52:16 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 and retrospectively LL19 From: Mika Liljeberg To: Philip Nye Cc: zeroconf@merit.edu In-Reply-To: <001d01c2d9f5$3bcc39d0$131010ac@aldebaran> References: <9C1B4A52-45D4-11D7-A12D-00039317663C@nominum.com> <022d01c2d9ea$f3d2d350$131010ac@aldebaran> <1045861805.22626.75.camel@devil> <001d01c2d9f5$3bcc39d0$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045867935.22625.232.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 00:52:16 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 00:04, Philip Nye wrote: > > Ok. You've shown that it is possible to construe a theoretical scenario > > where there is a referral issue (although caused by a v4LL node). Now > > answer the following: > > > > Does this map into a specific real world application? > > Keith has mentioned Netsolve and Gnutella (I think). I am not familiar with > either. I figured peer-to-peer applications and distributed directories would be a likely case. I'm not familiar with netsolve, but gnutella is a p2p file sharing application. Gnutella would be a compelling application, since a lot of people are inrested in file sharing. However, I would bet that a p2p node would advertise their own address via the p2p protocol, rather than relying on a neighbour to advertise it. Thus, a p2p client having both LL and a routable address would be advertising its routable address. A LL-only node would be out of luck (I'm sure no-one expects otherwise). The other thing with p2p applications is that they are under intense research and development, which means that new constraints like understading LL addresses can be easily handled as part of the development process. For this reason any new and non-traditional applications make somewhat less convincing use cases, since their implementors should be aware of LL addresses. > I have developed embedded applications which pass IP addresses around - they > don't live in a world with DNS. Would you be willing to give a concrete example using one of those applications? > However, these hosts don't all have to be running the same application. > > For example: > > A is a printer advertising itself via SLP > B is running an SLP Directory Agent. This doesn't make sense. A directory agent would most certainly have a routable address as well. > C is running a web page with links to printers which it discovers through > SLP > > > Why does B only have a LL address? > > Because the DHCP server didn't hand it an address. > Or because it is an LL only device. > Or because it has a manually configured address which worked doesn't work on > this network. > Or because it was in a transitional state at the time. Forgive me for sticking to the specific, but you gave an SLP directory agent as example. None of these alternatives make sense in that context. > > Why does B, having only a LL address, participate in a referral > > application? > > Because the poor schmuck who is trying to use it is not a geek. The poor schmuck running the SLP directory agent? :-) > And because the app doesn't know about scoped addresses - nor should it. That's fine. The OS should know. I'm trying establish if this is truly a problem. > > Is the use case common and compelling enough that complicating the > > specification with LL1 or LL23 is clearly justified, when we know there > > are unsolved issues with (at least) the LL23 solution (we haven't really > > considered LL1 in as much depth)? > > The point is that addresses are acquired in lots of ways, not just through > DNS or neat two way apps and since virtually nothing in IPv4 except routers > considers the scope of an address before using it. We're meandering into the realm of the abstract again. These arguments sound consistent on their own, but they have to be connected to the real world. Let's try to do that with concrete examples. It should be easy enough to come up with one, if this is really major problem. > You are right that this has to be balanced against other issues but I am not > clear what simply maintaining a LL address alongside your routable one > solves. Well, my claim all along has been that LL23 introduces a lot of additional implementation complexity. There are thorny issues related to switching between configured/unconfigured states and monitoring the reachability situation. Also, LL23 does not address multihomed hosts at all. An LL address could be configured on interface A, while a routable one could be configured on interface B. How does LL23 relate to this? I'm fairly convinced that having both LL and routable addresses does not cause any real problems as opposed to only having a single address per interface. If I'm wrong, supporters of LL1 or LL23 should easily be able to prove it by presenting a quick concrete example. > If the stack and API successfully suppress the LL address in the presence of > a routable one AND all hosts have routable addresses then it really doesn't > matter whether those hosts are technically retaining their LL addresses or > not - they just don't get used. This is what I argued with LL19. In the majority of cases, these APIs are used to find a destination address for a connection. If source address selection works in such a way that the scope of the selected source address matches the destination address, there should be no major problem with bi-directional communication. People who believe there would be a problem with referral apps should prove it with a few concrete examples. > However, the purpose of retaining them must > be to use them and deciding where and when is a whole can of worms. The purpose of retaining them would be to have them indepenently of the routable address. If the routable address happens to go away, the LL address is there and immediately usable. No complex implementation interdependencies, unless *really* needed. > Ted seems to be suggesting that if your routable configuration is not > working, at least you still have LL. But if you can determine that your > routable configuration is not working, then you can also choose to try > reconfiguring and maybe end up with just LL. You could but why would you want to go to all that trouble if you can just keep the LL address all the time? The principle is "keep it simple". "Make it more complex" must always have compelling reasons. Besides, you even win the 10 seconds it takes to configure a LL address. That's a (admittedly small) advantage in usability. > OTOH if you use your LL address > even though your routable configuration is valid you run straight into the > mixed scopes problems again. Back to abstract arguments? If you have both addresses, you use the routable one to communicate with destinations of equal scope. MikaL From owner-zeroconf@merit.edu Fri Feb 21 17:54:08 2003 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 RAA17697 for ; Fri, 21 Feb 2003 17:54:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3900B91210; Fri, 21 Feb 2003 17:57:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08DDC912CE; Fri, 21 Feb 2003 17:57:50 -0500 (EST) 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 CE48F91210 for ; Fri, 21 Feb 2003 17:57:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id B6DC75E08F; Fri, 21 Feb 2003 17:57:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 5609A5DE93 for ; Fri, 21 Feb 2003 17:57:49 -0500 (EST) Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1LMsxN03497 for ; Fri, 21 Feb 2003 16:54:59 -0600 (CST) Date: Fri, 21 Feb 2003 15:57:45 -0700 Subject: Re: LL1, LL23 and retrospectively LL19 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: "Zeroconf Working Group" Content-Transfer-Encoding: 7bit In-Reply-To: <002901c2d9f5$4c939330$131010ac@aldebaran> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > A is a printer advertising itself via SLP > B is running an SLP Directory Agent. > C is running a web page with links to printers which it discovers > through > SLP Why is B, a host with only an IPv4ll address, apparently not a legitimate user of the network, since other devices on the network have routable addresses, acting as an SLP DA? Why do we care if this configuration doesn't work? > Because the DHCP server didn't hand it an address. I.e., it's not a legitimate user of the network, but it's acting as a server on the network. We can't generally protect against this problem other than by using authentication in our server-discovery protocols. This is true whether IPv4ll is present or not. > Or because it is an LL only device. Why would an LL-only device act as an SLP DA? Why does the manufacturer have room in the ROM for an SLP DA implementation, but not a DHCP implementation? > Or because it has a manually configured address which worked doesn't > work on > this network. Why does a server on this network have a bogus manually-configured address? Why is it our problem that it does? Would removing IPv4ll from this device have the result that it would then begin to function properly? If not, why is this an interesting example when we are talking about the IPv4ll draft? > Or because it was in a transitional state at the time. LL1 and LL23 do not eliminate the problem of transitional states. Why is this example a reason to support LL1 and/or LL23? > You are right that this has to be balanced against other issues but I > am not > clear what simply maintaining a LL address alongside your routable one > solves. It means that IPv4ll is always available, even when external events have created a situation where IP routing isn't functional and nodes can't interoperate using their invalid, yet configured, global addresses. > But if you can determine that your > routable configuration is not working, then you can also choose to try > reconfiguring and maybe end up with just LL. Who is "you"? How does "you" determine that "you" don't have a working routable configuration? For example, is "you" the DHCP client or the IPv4ll agent or some other entity? Or do we require that the IPv4ll agent and the DHCP client be the same thing? Unless you can write this down in the draft in a way that a reasonable person can understand (and LL1 and LL23 do not do this), you can't use this as an argument either. > OTOH if you use your LL address > even though your routable configuration is valid you run straight into > the > mixed scopes problems again. Right. This mixed scope problem for which we have yet to see a specific example. :'/ This shouldn't be that hard. It should be possible to come up with a real world configuration, with specific software and specific protocols, where it doesn't work because a node has an IPv4ll address and also a global address, where the problem isn't simply a configuration error. There shouldn't be a need to resort to hypothetical examples. From owner-zeroconf@merit.edu Fri Feb 21 18:01:48 2003 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 SAA17865 for ; Fri, 21 Feb 2003 18:01:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A3E46912CE; Fri, 21 Feb 2003 18:05:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F28F912CF; Fri, 21 Feb 2003 18:05:33 -0500 (EST) 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 71B04912CE for ; Fri, 21 Feb 2003 18:05:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 600A25DF7A; Fri, 21 Feb 2003 18:05:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 665895DF42 for ; Fri, 21 Feb 2003 18:05:31 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1LN6Baj023960; Sat, 22 Feb 2003 01:06:12 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1LN6Br6023959; Sat, 22 Feb 2003 01:06:11 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Philip Nye Cc: Zeroconf Working Group In-Reply-To: <003f01c2d9fb$8f597b20$131010ac@aldebaran> References: <6B197570-45E4-11D7-A12D-00039317663C@nominum.com> <003f01c2d9fb$8f597b20$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045868769.23864.5.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 01:06:10 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 00:49, Philip Nye wrote: > > ... If it has both an IPv4ll address and a global address, and > > is contacting an SLP server that has a global address, why is it giving > > the SLP server its IPv4ll address? > > In the beginning the app says to its OS "what is my IP address". This > happens with lots of apps. So why doesn't the OS give the global one? > The OS cannot answer "who do you want to send it to?" or "what do you want > to do with it?". It cannot answer "local or global?". What does it answer? It should give the highest scope address first. MikaL From owner-zeroconf@merit.edu Fri Feb 21 18:39:21 2003 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 SAA18423 for ; Fri, 21 Feb 2003 18:39:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 09E8891230; Fri, 21 Feb 2003 18:43:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7CB19123D; Fri, 21 Feb 2003 18:43:04 -0500 (EST) 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 C5C5A91230 for ; Fri, 21 Feb 2003 18:43:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id ADAF55E183; Fri, 21 Feb 2003 18:43:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by segue.merit.edu (Postfix) with ESMTP id D4B815E021 for ; Fri, 21 Feb 2003 18:43:02 -0500 (EST) Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) with ESMTP id h1LNh0iC002223 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 22 Feb 2003 01:43:00 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) id h1LNgvjC002217; Sat, 22 Feb 2003 01:42:57 +0200 Date: Sat, 22 Feb 2003 01:42:57 +0200 Message-Id: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> From: Markku Savela To: philip@engarts.com Cc: zeroconf@merit.edu In-reply-to: <003f01c2d9fb$8f597b20$131010ac@aldebaran> (philip@engarts.com) Subject: Re: LL1, LL23 References: <6B197570-45E4-11D7-A12D-00039317663C@nominum.com> <003f01c2d9fb$8f597b20$131010ac@aldebaran> Sender: owner-zeroconf@merit.edu Precedence: bulk > From: "Philip Nye" > In the beginning the app says to its OS "what is my IP address". This > happens with lots of apps. Above is a serious API problem with multihomed hosts in any case. Which address from the multiple interfaces OS will return? And, even funnier, will it return IPv4 or IPv6 global? Perhaps, a more correct way to ask the question is "what is my IP address if I would connect to X?" And, in fact, to support simple applications, the original question should be internally translated into "what is my IP address for global estination". Relating to topic: the ZEROCONF RFC must not include any wording that would make OS "unconformant", if allows and works fine with both LL and global addresses at same time. I accept wording "MAY stop using LL when global address is present" for those unfortunate ones, that can't handle the situation :-) From owner-zeroconf@merit.edu Fri Feb 21 18:46:55 2003 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 SAA18686 for ; Fri, 21 Feb 2003 18:46:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7EF629123D; Fri, 21 Feb 2003 18:50:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48B549123E; Fri, 21 Feb 2003 18:50:39 -0500 (EST) 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 4ABEB9123D for ; Fri, 21 Feb 2003 18:50:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 34E495DDC3; Fri, 21 Feb 2003 18:50:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 8CC535DDAA for ; Fri, 21 Feb 2003 18:50:37 -0500 (EST) Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1LNllN03964 for ; Fri, 21 Feb 2003 17:47:47 -0600 (CST) Date: Fri, 21 Feb 2003 16:50:33 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: "Zeroconf Working Group" Content-Transfer-Encoding: 7bit In-Reply-To: <003f01c2d9fb$8f597b20$131010ac@aldebaran> Message-Id: <444ABB7C-45F7-11D7-A12D-00039317663C@nominum.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > In the beginning the app says to its OS "what is my IP address". This > happens with lots of apps. Really? Given how differently most operating systems support answering this question, I suspect that you are wrong. Most apps bind to 0.0.0.0, not to a specific IP address. There are some few apps that do use system-specific APIs to discover IP addresses. It is only this second group of apps that is going to have a problem with application-discovered addresses. Can you give us an example of an app that both has the quality that it checks to see what addresses the system has, _and_ sends these addresses to other services that might publish them? I can give you one example - the ISC DHCP server does this. We had a problem with this about four or five years ago, and I had to hack the server to allow the user to specify which address to advertise. This was very easy. It would also be very easy to hack the ISC DHCP server to simply discard the IPv4ll address, since it is never correct for the DHCP server to advertise this address. The server already has a code path that eliminates addresses that shouldn't be advertised, so this would involve something like four lines of code. ISC BIND also uses SIOCGIFCONF to get a list of IP addresses, but it doesn't ever publish them. Likewise with sendmail. Can you give us an example that isn't easy to fix, like ISC DHCP, and that is actually a problem, unlike BIND and sendmail? > The OS cannot answer "who do you want to send it to?" or "what do you > want > to do with it?". It cannot answer "local or global?". What does it > answer? Actually, as I say, usually the app doesn't ever tell the O.S. which address to use - it trusts the O.S. to choose. The application programmer has to be fairly knowledgeable just to know how to ask the O.S. what addresses are configured on its various interfaces. We've already described an excellent rule for how the O.S. should choose which source address to use - if the destination is scoped, use our scoped address. If it is not scoped, use our non-scoped address. In the case where the client uses something like SIOCGIFCONF to get a list of IP addresses on an interface, you have a harder problem. As I say, the ISC DHCP server already solves this problem. I suspect that most applications that use SIOCGIFCONF, which are few, would be easy to modify so that they did the right thing. It would also be possible for the O.S. vendor to modify the SIOCGIFCONF ioctl so that it didn't return link-local addresses in a way that made them look identical to global addresses. I suspect that this would be a good choice - it's likely that in most cases the app that is getting the address doesn't want to see the link-local address, and the app that wants the link-local address will know to ask for it. Can you think of an application that we would *want* to advertise the link-local address, but that would not know to ask specifically for it? From owner-zeroconf@merit.edu Fri Feb 21 19:10:03 2003 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 TAA19157 for ; Fri, 21 Feb 2003 19:10:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 43BB19123E; Fri, 21 Feb 2003 19:13:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1597A912CF; Fri, 21 Feb 2003 19:13:47 -0500 (EST) 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 1FBD49123E for ; Fri, 21 Feb 2003 19:13:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 05D645E183; Fri, 21 Feb 2003 19:13:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id A88655DF18 for ; Fri, 21 Feb 2003 19:13:45 -0500 (EST) Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1M0AsN04247; Fri, 21 Feb 2003 18:10:54 -0600 (CST) Date: Fri, 21 Feb 2003 17:13:41 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu, philip@engarts.com To: Markku Savela From: Ted Lemon In-Reply-To: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> Message-Id: <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Above is a serious API problem with multihomed hosts in any > case. Which address from the multiple interfaces OS will return? And, > even funnier, will it return IPv4 or IPv6 global? > > Perhaps, a more correct way to ask the question is "what is my IP > address if I would connect to X?" > > And, in fact, to support simple applications, the original question > should be internally translated into "what is my IP address for global > estination". There _is_ no API of which I am aware through which you can ask the question "what is my IP address?" The only one that I know of answers the question, "what are my interfaces and the IP addresses configured on them?" Server programs that enumerate IP addresses have to be prepared to understand a lot about the connectivity of the host. This is not a new problem that's caused by IPv4ll. I speak from personal experience, having had to write code to handle this on a wide variety of operating systems. From owner-zeroconf@merit.edu Sat Feb 22 00:34:15 2003 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 AAA25394 for ; Sat, 22 Feb 2003 00:34:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 42991912D7; Sat, 22 Feb 2003 00:37:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DEAC912D8; Sat, 22 Feb 2003 00:37:58 -0500 (EST) 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 E2079912D7 for ; Sat, 22 Feb 2003 00:37:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id C4A5B5DE17; Sat, 22 Feb 2003 00:37:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by segue.merit.edu (Postfix) with ESMTP id A294A5DE03 for ; Sat, 22 Feb 2003 00:37:57 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mSM9-0005bD-00; Fri, 21 Feb 2003 21:37:49 -0800 Date: Sat, 22 Feb 2003 00:34:48 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030222003448.701b2253.moore@cs.utk.edu> In-Reply-To: <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > There _is_ no API of which I am aware through which you can ask the > question "what is my IP address?" The only one that I know of answers > the question, "what are my interfaces and the IP addresses configured > on them?" the other thing that is commonly done is to feed the output of gethostname (or uname, whatever) to gethostbyname (). note that this does not necessarily result in a DNS query. > Server programs that enumerate IP addresses have to be > prepared to understand a lot about the connectivity of the host. not necessarily. obviously it depends on how they use those addresses. it is also the case that fairly simple approaches (e.g. take an address of the interface to which the default route is attached) often work well. > This is not a new problem that's caused by IPv4ll. no, but the introduction of v4LL will break software that currently works. the vast majority of IPv4 hosts do not have multiple network interfaces, or if they do, do not use more than one of those interfaces at a time. and the vast majority of IPv4 hosts do not have multiple IPv4 addresses assigned to them. a lot of software will break in the presence of multiple addresses on a host. (I just saw a patch go by for netsolve which allows a server to have its local address specified on the command-line when it is started, to handle the case where the server has multiple addresses assigned to it and they don't all work well. The fix is still a kludge in that it can only advertise a single address even though this address might not be sufficient for all clients. basically netsolve does not have the ability to deal with scoped addresses, and it's impractical to fix netsolve so that it does deal with them robustly.) From owner-zeroconf@merit.edu Sat Feb 22 00:40:55 2003 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 AAA25490 for ; Sat, 22 Feb 2003 00:40:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AF158912D8; Sat, 22 Feb 2003 00:44:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84880912DA; Sat, 22 Feb 2003 00:44:39 -0500 (EST) 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 6EAE1912D8 for ; Sat, 22 Feb 2003 00:44:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 53A085DE17; Sat, 22 Feb 2003 00:44:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by segue.merit.edu (Postfix) with ESMTP id 32B9F5DE03 for ; Sat, 22 Feb 2003 00:44:38 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mSSf-0005q0-00; Fri, 21 Feb 2003 21:44:34 -0800 Date: Sat, 22 Feb 2003 00:41:33 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030222004133.52b5a0c1.moore@cs.utk.edu> In-Reply-To: <444ABB7C-45F7-11D7-A12D-00039317663C@nominum.com> References: <003f01c2d9fb$8f597b20$131010ac@aldebaran> <444ABB7C-45F7-11D7-A12D-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > In the beginning the app says to its OS "what is my IP address". This > > happens with lots of apps. > > Really? Given how differently most operating systems support > answering this question, I suspect that you are wrong. Most apps bind > to 0.0.0.0, not to a specific IP address. true, in my experience. but the app may still depend on being reachable via a single address by any peer. > There are some few apps > that do use system-specific APIs to discover IP addresses. the socket APIs are actually fairly portable across UNIXen, and there are lots of ways to determine IP addressees to be used in referrals: - ioctl SIOCGIFCONF - to get your own interfaces/addresses - getlocalname on an open socket - to get a local IP address - getpeername on a connection with a peer -to get the peer's address to use in referrals - gethostbyname (gethostname ()) - get an address associated with the host's idea of its name note that it's really unreasonable to expect everyone to have to fix their software in order to keep working in the presence of LL, especially when there's no standard way to disable LL on a network. Keith From owner-zeroconf@merit.edu Sat Feb 22 00:45:31 2003 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 AAA25544 for ; Sat, 22 Feb 2003 00:45:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 74062912DA; Sat, 22 Feb 2003 00:49:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40C71912DB; Sat, 22 Feb 2003 00:49:07 -0500 (EST) 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 B8A4A912DA for ; Sat, 22 Feb 2003 00:47:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 936115DDAB; Sat, 22 Feb 2003 00:47:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by segue.merit.edu (Postfix) with ESMTP id 719BA5DDA0 for ; Sat, 22 Feb 2003 00:47:52 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mSVk-0001nR-00; Fri, 21 Feb 2003 21:47:45 -0800 Date: Sat, 22 Feb 2003 00:44:44 -0500 From: Keith Moore To: Markku Savela Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030222004444.60a11c47.moore@cs.utk.edu> In-Reply-To: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> References: <6B197570-45E4-11D7-A12D-00039317663C@nominum.com> <003f01c2d9fb$8f597b20$131010ac@aldebaran> <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > And, in fact, to support simple applications, the original question > should be internally translated into "what is my IP address for global > estination". actually gethostbyname (gethostname ()) often works quite well for this - because, if necessary, the host can be configured with a host name and a hostname->address mapping (say in /etc/hosts) that selects one address that works "everywhere". > I accept wording "MAY stop using LL when global address is present" > for those unfortunate ones, that can't handle the situation :-) it's not acceptable for this WG to standardize behavior that breaks things. From owner-zeroconf@merit.edu Sat Feb 22 00:48:37 2003 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 AAA25592 for ; Sat, 22 Feb 2003 00:48:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 13DB9912DB; Sat, 22 Feb 2003 00:52:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D55BD912DC; Sat, 22 Feb 2003 00:52:21 -0500 (EST) 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 C38A4912DB for ; Sat, 22 Feb 2003 00:52:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id A7E2A5DE03; Sat, 22 Feb 2003 00:52:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by segue.merit.edu (Postfix) with ESMTP id 877C65DDAB for ; Sat, 22 Feb 2003 00:52:20 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mSa6-0001rT-00; Fri, 21 Feb 2003 21:52:14 -0800 Date: Sat, 22 Feb 2003 00:49:14 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, Erik.Guttman@Sun.COM, philip@engarts.com, zeroconf@merit.edu Subject: Re: LL1, LL23 Message-Id: <20030222004914.43555809.moore@cs.utk.edu> In-Reply-To: <1045848196.22035.8.camel@devil> References: <1045776694.14935.56.camel@devil> <8B083511-4524-11D7-A12D-00039317663C@nominum.com> <20030220174934.10b52b2e.moore@cs.utk.edu> <1045810765.14935.486.camel@devil> <20030221060227.7bc6339e.moore@cs.utk.edu> <1045848196.22035.8.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > I disagree with your assessment of what is "compelling" or "common". > > Users are seriously inconvenienced if the Internet is made less capable > > of supporting applications that don't exist yet, > > That is a fine abstract argument against scoped addressing in general > but it is of no help whatsoever when trying to decide whether proposals > like LL1 and LL23 are technically sound. no, you have it backwards. you can't decide whether something is technically sound based on concrete examples. concerete examples might demonstrate that it is unsound, but they cannot demonstrate soundness. what you seem to want to do is feel free to dismiss any example that you personally find insignificant. I disagree that you or anyone in this WG has the right to determine that certain applications are insignificant enough to be broken by linklocal. Keith From owner-zeroconf@merit.edu Sat Feb 22 01:27:56 2003 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 BAA25936 for ; Sat, 22 Feb 2003 01:27:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6DC10912DE; Sat, 22 Feb 2003 01:31:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA2EE912DF; Sat, 22 Feb 2003 01:31:03 -0500 (EST) 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 D8D4B912DE for ; Sat, 22 Feb 2003 01:30:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 629565DFC6; Sat, 22 Feb 2003 01:30:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 6D6215DE95 for ; Sat, 22 Feb 2003 01:30:21 -0500 (EST) Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1M6RQN07478 for ; Sat, 22 Feb 2003 00:27:26 -0600 (CST) Date: Fri, 21 Feb 2003 23:30:15 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030222003448.701b2253.moore@cs.utk.edu> Message-Id: <1ADF6C77-462F-11D7-A12D-00039317663C@nominum.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > no, but the introduction of v4LL will break software that currently > works. When DEC put a DNS resolver into Ultrix, it broke a lot of stuff too. I remember all the stuff I had to do to make things work. Subtle changes to the way the resolver worked in later releases had significant effects on how various applications behaved. In particular, it badly broke NFS and rsh. If you installed a hostname that wasn't an FQDN, things broke all over the place. Yet I think you would be hard pressed to argue either that NFS and rsh should have been doing the thing that broke them, or that we shouldn't have deployed DNS for fear of breaking NFS and rsh. The hostname bugs were all actual bugs, not just broken behavior. Now, the net win for DNS is *much* bigger than the win for IPv4ll, but the principle is the same. You compare the costs to the benefits. You do not just say "this breaks something, so it shall not pass." So what we are trying to do here is identify specific cases where IPv4ll would break things, and consider how we might fix the problem. Then we can really compare the costs to the benefits. > basically netsolve does not have the ability to deal with scoped > addresses, and it's impractical to fix netsolve so that it does deal > with them robustly. So, with the above in mind, would you care to characterize this further? Is it impossible to add code that eliminates IPv4ll addresses from the interface list? Would it not help to make SIOCGIFCONF not return IPv4ll addresses, and require that instead require that server software that needs to advertise IPv4ll addresses use a separate system call to get a list of IPv4ll addresses? Wouldn't this latter solution actually require zero change to netsolve? From owner-zeroconf@merit.edu Sat Feb 22 01:38:03 2003 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 BAA26037 for ; Sat, 22 Feb 2003 01:38:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 010E8912DF; Sat, 22 Feb 2003 01:41:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE6E7912E0; Sat, 22 Feb 2003 01:41:46 -0500 (EST) 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 B2C1A912DF for ; Sat, 22 Feb 2003 01:41:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B9455DFA2; Sat, 22 Feb 2003 01:41:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 3B3D05DDFB for ; Sat, 22 Feb 2003 01:41:45 -0500 (EST) Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1M6cpN07629 for ; Sat, 22 Feb 2003 00:38:52 -0600 (CST) Date: Fri, 21 Feb 2003 23:41:40 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030222004133.52b5a0c1.moore@cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > true, in my experience. but the app may still depend on being > reachable > via a single address by any peer. Applications that depend on being reachable by a single address are already broken in the context of existing protocols, because many hosts have more than one interface, and therefore more than one address. In many cases, particularly when a host has both IPv4 and IPv6 addresses, the addresses are not interchangeable. I don't think you can argue that an application with this problem is bug-free in the absence of IPv4ll. > the socket APIs are actually fairly portable across UNIXen, and there > are lots of ways to determine IP addressees to be used in referrals: > > - ioctl SIOCGIFCONF - to get your own interfaces/addresses Doesn't work on Linux. Or at least it didn't in 2.2 - maybe they fixed that in 2.4. The API for doing this in 2.2 is completely different. Various different Unices have slightly different versions of SIOCGIFCONF, and there is no standard behavior, although the behaviors of most non-Linux stacks are fairly similar. The point is, if you are using SIOCGIFCONF, you're not a neophyte. > - getlocalname on an open socket - to get a local IP address This is going to give you the IP address that you are using to communicate. Can you give an example of when this would be the wrong address to use? > - getpeername on a connection with a peer -to get the peer's > address to use in referrals Again, this is going to give you the IP address you're using to communicate with the peer. If the peer has a global address, and you have a global address, you're going to get a global address here. If the peer doesn't have a global address, or you don't have a global address, you're going to get an IPv4ll address. In none of these cases are you going to get an address that is not appropriate to use in referrals. > - gethostbyname (gethostname ()) - get an address associated with > the host's idea of its name This doesn't even promise to get you the host's IP address. There is no guarantee at all that your domain search list and the hostname are going to be such that the IP address you get back from this will not be some other computer's IP address. So I would say that any application that does this is simply broken, and this brokenness has nothing to do with IPv4ll. From owner-zeroconf@merit.edu Sat Feb 22 01:40:55 2003 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 BAA26092 for ; Sat, 22 Feb 2003 01:40:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0BEB0912E0; Sat, 22 Feb 2003 01:44:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7528912E1; Sat, 22 Feb 2003 01:44:39 -0500 (EST) 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 DA092912E0 for ; Sat, 22 Feb 2003 01:44:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id C80865DFE0; Sat, 22 Feb 2003 01:44:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 497DB5DFDC for ; Sat, 22 Feb 2003 01:44:38 -0500 (EST) Received: from nominum.com (a21.pm3-67.theriver.com [206.25.48.213]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1M6fjN07674 for ; Sat, 22 Feb 2003 00:41:45 -0600 (CST) Date: Fri, 21 Feb 2003 23:44:34 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030222004914.43555809.moore@cs.utk.edu> Message-Id: <1ADFAD6A-4631-11D7-A12D-00039317663C@nominum.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > no, you have it backwards. you can't decide whether something is > technically > sound based on concrete examples. concerete examples might > demonstrate that > it is unsound, but they cannot demonstrate soundness. Nothing other than deployment can demonstrate soundness. That is why we are challenging you to come up with some concrete example that demonstrates unsoundness. If you can do that, then we can stop arguing. Otherwise, the only way we can proceed is to, well, proceed, and see what happens. From owner-zeroconf@merit.edu Sat Feb 22 04:38:32 2003 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 EAA07949 for ; Sat, 22 Feb 2003 04:38:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F0F9391203; Sat, 22 Feb 2003 04:42:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4BF691259; Sat, 22 Feb 2003 04:42:14 -0500 (EST) 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 6F9B291203 for ; Sat, 22 Feb 2003 04:42:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4B1865DDB1; Sat, 22 Feb 2003 04:42:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 9F9505DD90 for ; Sat, 22 Feb 2003 04:42:10 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1M9ggaj026803; Sat, 22 Feb 2003 11:42:42 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1M9gdFm026802; Sat, 22 Feb 2003 11:42:39 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: Ted Lemon , msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com In-Reply-To: <20030222003448.701b2253.moore@cs.utk.edu> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045906958.26682.15.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 11:42:39 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 07:34, Keith Moore wrote: > > There _is_ no API of which I am aware through which you can ask the > > question "what is my IP address?" The only one that I know of answers > > the question, "what are my interfaces and the IP addresses configured > > on them?" > > the other thing that is commonly done is to feed the output of > gethostname (or uname, whatever) to gethostbyname (). > note that this does not necessarily result in a DNS query. That's good. You're not supposed to put LLs into DNS, so this will keep on working. > > Server programs that enumerate IP addresses have to be > > prepared to understand a lot about the connectivity of the host. > > not necessarily. obviously it depends on how they use those addresses. it is > also the case that fairly simple approaches (e.g. take an address of the > interface to which the default route is attached) often work well. This too will keep on working, with a little help from the OS. If the implementation is such that each IPv4 address is configured on a separate virtual interface, your default route will still point to the interface in which you have the routable address. > > This is not a new problem that's caused by IPv4ll. > > no, but the introduction of v4LL will break software that currently works. We're trying to establish what that software might be, but so far I have not seen even a single good example. By "good" I mean detailed enough to undestand the failure mode and discuss it. > the vast majority of IPv4 hosts do not have multiple network interfaces, or if > they do, do not use more than one of those interfaces at a time. and the vast > majority of IPv4 hosts do not have multiple IPv4 addresses assigned to them. > a lot of software will break in the presence of multiple addresses on a host. Show an example of software that will break. > (I just saw a patch go by for netsolve which allows a server to have its local > address specified on the command-line when it is started, to handle the case > where the server has multiple addresses assigned to it and they don't all work > well. The fix is still a kludge in that it can only advertise a single address > even though this address might not be sufficient for all clients. If that address is a global one, why would it not be sufficient for all clients? > basically > netsolve does not have the ability to deal with scoped addresses, and it's > impractical to fix netsolve so that it does deal with them robustly.) Excellent, a concrete example! How does netsolve normally determine the address it advertises? MikaL From owner-zeroconf@merit.edu Sat Feb 22 04:52:28 2003 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 EAA08076 for ; Sat, 22 Feb 2003 04:52:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7FE22912E3; Sat, 22 Feb 2003 04:54:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CFF1912F2; Sat, 22 Feb 2003 04:54:03 -0500 (EST) 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 26F8A912E3 for ; Sat, 22 Feb 2003 04:53:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 09CBE5DDE5; Sat, 22 Feb 2003 04:53:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id A9D465DD90 for ; Sat, 22 Feb 2003 04:53:57 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1M9sVaj026847; Sat, 22 Feb 2003 11:54:32 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1M9sTsU026844; Sat, 22 Feb 2003 11:54:29 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: Ted.Lemon@nominum.com, Erik.Guttman@Sun.COM, philip@engarts.com, zeroconf@merit.edu In-Reply-To: <20030222004914.43555809.moore@cs.utk.edu> References: <1045776694.14935.56.camel@devil> <8B083511-4524-11D7-A12D-00039317663C@nominum.com> <20030220174934.10b52b2e.moore@cs.utk.edu> <1045810765.14935.486.camel@devil> <20030221060227.7bc6339e.moore@cs.utk.edu> <1045848196.22035.8.camel@devil> <20030222004914.43555809.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045907669.26677.26.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 11:54:29 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 07:49, Keith Moore wrote: > no, you have it backwards. you can't decide whether something is technically > sound based on concrete examples. concerete examples might demonstrate that > it is unsound, but they cannot demonstrate soundness. It has already been demonstrated that, in addition to increasing implementation complexity, LL1/LL23 also create new potential problems e.g. with swithing between configured and unconfigured states. What has not been demonstrated at all, beyond insistent assertions, is that either LL1 or LL23 is needed in the first place. > what you seem to want to do is feel free to dismiss any example that you > personally find insignificant. I disagree that you or anyone in this WG has > the right to determine that certain applications are insignificant enough to be > broken by linklocal. That is uncalled for. We're all professionals here, I hope. MikaL From owner-zeroconf@merit.edu Sat Feb 22 08:32:51 2003 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 IAA10634 for ; Sat, 22 Feb 2003 08:32:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8B9FA9120A; Sat, 22 Feb 2003 08:36:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D9399121C; Sat, 22 Feb 2003 08:36:35 -0500 (EST) 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 618BA9120A for ; Sat, 22 Feb 2003 08:36:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 401925DEEA; Sat, 22 Feb 2003 08:36:34 -0500 (EST) 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 128C05DD8F for ; Sat, 22 Feb 2003 08:36:34 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id C7F1059936 for ; Sat, 22 Feb 2003 13:36:35 +0000 (GMT) Message-ID: <004201c2da77$9536dfc0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <1045776694.14935.56.camel@devil> <8B083511-4524-11D7-A12D-00039317663C@nominum.com> <20030220174934.10b52b2e.moore@cs.utk.edu> <1045810765.14935.486.camel@devil> <20030221060227.7bc6339e.moore@cs.utk.edu> <1045848196.22035.8.camel@devil> <20030222004914.43555809.moore@cs.utk.edu> <1045907669.26677.26.camel@devil> Subject: Re: LL1, LL23 Date: Sat, 22 Feb 2003 13:37:45 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Mika Liljeberg" > > It has already been demonstrated that, in addition to increasing > implementation complexity, LL1/LL23 also create new potential problems > e.g. with swithing between configured and unconfigured states. How? Give me a concretre example where keeping a LL address solves the switching issue which can't be solved under LL1/LL23? You can't have it both ways. If you can stop hosts with both addresses "advertising" the LL one, then that basically means it can't be used. As soon as it is used it gets picked up by aopplications and into the system. Philip From owner-zeroconf@merit.edu Sat Feb 22 08:45:18 2003 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 IAA10775 for ; Sat, 22 Feb 2003 08:45:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C31691227; Sat, 22 Feb 2003 08:49:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD9D291264; Sat, 22 Feb 2003 08:49:01 -0500 (EST) 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 EE39791227 for ; Sat, 22 Feb 2003 08:46:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 935F95DE00; Sat, 22 Feb 2003 08:46:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 913995DD8D for ; Sat, 22 Feb 2003 08:46:54 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MDlaaj027873 for ; Sat, 22 Feb 2003 15:47:36 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MDlZNu027872 for zeroconf@merit.edu; Sat, 22 Feb 2003 15:47:35 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: zeroconf@merit.edu In-Reply-To: <003601c2da6e$f5fad770$131010ac@aldebaran> References: <1045776694.14935.56.camel@devil> <8B083511-4524-11D7-A12D-00039317663C@nominum.com> <20030220174934.10b52b2e.moore@cs.utk.edu> <1045810765.14935.486.camel@devil> <20030221060227.7bc6339e.moore@cs.utk.edu> <1045848196.22035.8.camel@devil> <20030222004914.43555809.moore@cs.utk.edu> <1045907669.26677.26.camel@devil> <003601c2da6e$f5fad770$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045921654.27180.48.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 15:47:35 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 14:36, Philip Nye wrote: > > From: "Mika Liljeberg" > > > > It has already been demonstrated that, in addition to increasing > > implementation complexity, LL1/LL23 also create new potential problems > > e.g. with swithing between configured and unconfigured states. > > How? Give me a concretre example where keeping a LL address solves the > switching issue which can't be solved under LL1/LL23? There is no switching between configured and unconfigured states if LL23 is rejected. If you mean the source address selection algorithm, I believe that a source address with a scope matching the destination address is always the most appropriate one, as it ensures bi-directional communication between the hosts. > You can't have it both ways. If you can stop hosts with both addresses > "advertising" the LL one, then that basically means it can't be used. No it doesn't. It can still be used as source address with LL-only destinations (which *cannot* directly pass the peer address off-link). That's all I want. No unconfiguring/reconfiguring addresses on the fly. No funny exceptions to source address selection rules. MikaL From owner-zeroconf@merit.edu Sat Feb 22 09:56:01 2003 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 JAA11460 for ; Sat, 22 Feb 2003 09:56:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DBFB69126E; Sat, 22 Feb 2003 09:59:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A18CC91276; Sat, 22 Feb 2003 09:59:43 -0500 (EST) 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 8950F9126E for ; Sat, 22 Feb 2003 09:59:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6DA1A5DE8F; Sat, 22 Feb 2003 09:59:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtp.covadmail.net (mx03.covadmail.net [63.65.120.63]) by segue.merit.edu (Postfix) with SMTP id 073DB5DD8F for ; Sat, 22 Feb 2003 09:59:42 -0500 (EST) Received: (covad.net 17025 invoked from network); 22 Feb 2003 14:59:41 -0000 Received: from unknown (HELO STUDY) (66.167.13.3) by sun-qmail16 with SMTP; 22 Feb 2003 14:59:41 -0000 To: zeroconf@merit.edu Subject: [LL27] LL-only hosts are out of scope for this specification References: <3E5114EE.2060803@sun.com> Organization: Seeking Work... From: Scott Lawrence Date: 22 Feb 2003 09:59:40 -0500 In-Reply-To: <3E5114EE.2060803@sun.com> Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-zeroconf@merit.edu Precedence: bulk Erik Guttman writes: > Description of Issue: LL-only hosts are out of scope for this specification > Inherent in the entire concept of "Internet" is the ability to > communicate between (not just within) networks, and the Internet > Protocol was designed specifically to facilitate communication between > hosts on potentially dissimilar, and perhaps distant, networks. Hosts > which are inherently incapable of communicating with hosts on other IP > networks cannot meaningfully be said to implement the Internet Protocol, > or to support Internet connectivity, even if they use similar packet > formats. Categorically reject any such language. Products that use technologies specified in this and other Standards Track documents, but which have no need to communicate beyond the local link, have been and will continue to be built. To ignore them, or worse to declare them somehow beyond the pale, is to do a disservice to the user community and would do nothing other than foster chaos. Local usage on networks not connected to the global Internet is explicitly cited in the Zeroconf charter; this item is not so much an objection to the proposed address autoconfiguration protocol as to the concept of local networks, which is a broader question already dealt with when the working group was chartered. I respectfully suggest that as such this issue is out of order. -- Scott Lawrence From owner-zeroconf@merit.edu Sat Feb 22 10:09:53 2003 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 KAA11851 for ; Sat, 22 Feb 2003 10:09:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 43DC491207; Sat, 22 Feb 2003 10:13:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0BB1291276; Sat, 22 Feb 2003 10:13:35 -0500 (EST) 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 A86FA91207 for ; Sat, 22 Feb 2003 10:13:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8C2295DE8F; Sat, 22 Feb 2003 10:13:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by segue.merit.edu (Postfix) with ESMTP id 6A5545DE3B for ; Sat, 22 Feb 2003 10:13:34 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mbL9-0002Pd-00; Sat, 22 Feb 2003 07:13:23 -0800 Date: Sat, 22 Feb 2003 10:10:21 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030222101021.449ef2ff.moore@cs.utk.edu> In-Reply-To: <1045906958.26682.15.camel@devil> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > the other thing that is commonly done is to feed the output of > > gethostname (or uname, whatever) to gethostbyname (). > > note that this does not necessarily result in a DNS query. > > That's good. You're not supposed to put LLs into DNS, so this will keep > on working. well, you wouldn't want gethostbyname (gethostname ()) to return an LL address under any circumstances where a routable address were associated with the host, because this would cause apps to advertise the LL address as a way to reach that host. > > > Server programs that enumerate IP addresses have to be > > > prepared to understand a lot about the connectivity of the host. > > > > not necessarily. obviously it depends on how they use those addresses. > > it is also the case that fairly simple approaches (e.g. take an address of > > the interface to which the default route is attached) often work well. > > This too will keep on working, with a little help from the OS. If the > implementation is such that each IPv4 address is configured on a > separate virtual interface, your default route will still point to the > interface in which you have the routable address. agreed that it can help if the OS is clever about how it represents LL address-to-interface bindings. > > > This is not a new problem that's caused by IPv4ll. > > > > no, but the introduction of v4LL will break software that currently works. > > We're trying to establish what that software might be, but so far I have > not seen even a single good example. By "good" I mean detailed enough to > undestand the failure mode and discuss it. when have had such discussions. people seem to want to disregard them, and then later claim that they haven't happened. > > the vast majority of IPv4 hosts do not have multiple network interfaces, > > or if they do, do not use more than one of those interfaces at a time. > > and the vast majority of IPv4 hosts do not have multiple IPv4 addresses > > assigned to them. a lot of software will break in the presence of multiple > > addresses on a host. > > Show an example of software that will break. I just did. > > (I just saw a patch go by for netsolve which allows a server to have its > > local address specified on the command-line when it is started, to handle > > the case where the server has multiple addresses assigned to it and they > > don't all work well. The fix is still a kludge in that it can only > > advertise a single address even though this address might not be > > sufficient for all clients. > > If that address is a global one, why would it not be sufficient for all > clients? globally scoped does not mean globally reachable. > > basically > > netsolve does not have the ability to deal with scoped addresses, and it's > > impractical to fix netsolve so that it does deal with them robustly.) > > Excellent, a concrete example! How does netsolve normally determine the > address it advertises? I'll have to look at the code again to be sure, but from memory, it does different things in different parts of the code a. getpeername() b. gethostbyname (gethostname ()) From owner-zeroconf@merit.edu Sat Feb 22 10:57:38 2003 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 KAA12402 for ; Sat, 22 Feb 2003 10:57:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 265519120E; Sat, 22 Feb 2003 11:01:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E64DB91276; Sat, 22 Feb 2003 11:01:01 -0500 (EST) 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 708109120E for ; Sat, 22 Feb 2003 11:01:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 255CB5DEBE; Sat, 22 Feb 2003 11:00:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 15C725DEC1 for ; Sat, 22 Feb 2003 11:00:54 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MG1Vaj028360; Sat, 22 Feb 2003 18:01:31 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MG1T1Q028358; Sat, 22 Feb 2003 18:01:29 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com In-Reply-To: <20030222101021.449ef2ff.moore@cs.utk.edu> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045929688.27180.122.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 18:01:29 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 17:10, Keith Moore wrote: > well, you wouldn't want gethostbyname (gethostname ()) to return an LL > address under any circumstances where a routable address were associated > with the host, because this would cause apps to advertise the LL address > as a way to reach that host. I agree. Even if LLMNR were implemented behind the gethostbyname() API, the implementation should not try LLMNR if the name is found in DNS. I believe the LLMNR specification already states that the resolver has to try DNS first. So, I expect no problems with applications that use gethostbyname(). > > We're trying to establish what that software might be, but so far I have > > not seen even a single good example. By "good" I mean detailed enough to > > undestand the failure mode and discuss it. > > when have had such discussions. people seem to want to disregard them, > and then later claim that they haven't happened. I can't speak for others but that is not my intention. I want to understand the exact failure modes you're seeing with specific applications, in order to get a feel for the problem. My own reasoning is telling me that there is no major problem and you are saying that there is. I want to understand why. This discussion is already improving, IMHO, now that we're now talking about concrete APIs and how they behave. > > > the vast majority of IPv4 hosts do not have multiple network interfaces, > > > or if they do, do not use more than one of those interfaces at a time. > > > and the vast majority of IPv4 hosts do not have multiple IPv4 addresses > > > assigned to them. a lot of software will break in the presence of multiple > > > addresses on a host. > > > > Show an example of software that will break. > > I just did. I guess you mean the netsolve case? That's good, let's explore it. > > If that address is a global one, why would it not be sufficient for all > > clients? > > globally scoped does not mean globally reachable. That's a problem that exists independently of LL addresses. I don't see how that is relevant to the discussion. > > > basically > > > netsolve does not have the ability to deal with scoped addresses, and it's > > > impractical to fix netsolve so that it does deal with them robustly.) > > > > Excellent, a concrete example! How does netsolve normally determine the > > address it advertises? > > I'll have to look at the code again to be sure, but from memory, it does > different things in different parts of the code Would you be so kind? It would be good to have something concrete to go on. > a. getpeername() This could be a problem if the peer is somehow selecting an LL source address. Under current rules, this would only happen if the it was attempting to connect to an LL destination address, or if the application was explicitly binding to the LL address. Which one of these would be the case with netsolve? > b. gethostbyname (gethostname ()) This will return a global address on any but LL-only nodes. If this is the way in which each netsolve node discovers its own IP address, then every node will only be advertising its global address (again assuming there are no LL-only nodes involved). Am I correct? MikaL From owner-zeroconf@merit.edu Sat Feb 22 11:25:38 2003 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 LAA12717 for ; Sat, 22 Feb 2003 11:25:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AAF7791211; Sat, 22 Feb 2003 11:29:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74C4E91276; Sat, 22 Feb 2003 11:29:21 -0500 (EST) 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 2DAB091211 for ; Sat, 22 Feb 2003 11:29:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1289A5DF12; Sat, 22 Feb 2003 11:29:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by segue.merit.edu (Postfix) with ESMTP id E3DA25DF02 for ; Sat, 22 Feb 2003 11:29:19 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mcWV-00002H-00; Sat, 22 Feb 2003 08:29:11 -0800 Date: Sat, 22 Feb 2003 11:26:09 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030222112609.18990282.moore@cs.utk.edu> In-Reply-To: <1045929688.27180.122.camel@devil> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > well, you wouldn't want gethostbyname (gethostname ()) to return an LL > > address under any circumstances where a routable address were associated > > with the host, because this would cause apps to advertise the LL address > > as a way to reach that host. > > I agree. Even if LLMNR were implemented behind the gethostbyname() API, > the implementation should not try LLMNR if the name is found in DNS. I > believe the LLMNR specification already states that the resolver has to > try DNS first. don't get me started about LLMNR. it's an even bigger mess than LL. but that's for another group to deal with. > So, I expect no problems with applications that use gethostbyname(). that's an overgeneralization. there are lots of problems with scoped addresses that have nothing to do with where the app gets the address from. > > > We're trying to establish what that software might be, but so far I have > > > not seen even a single good example. By "good" I mean detailed enough to > > > undestand the failure mode and discuss it. > > > > when have had such discussions. people seem to want to disregard them, > > and then later claim that they haven't happened. > > I can't speak for others but that is not my intention. I want to > understand the exact failure modes you're seeing with specific > applications, in order to get a feel for the problem. My own reasoning > is telling me that there is no major problem and you are saying that > there is. I want to understand why. > > This discussion is already improving, IMHO, now that we're now talking > about concrete APIs and how they behave. IMHO looking at a few concrete examples tends to misses the point - because you cannot analyze the behavior of all network applications. > > > > the vast majority of IPv4 hosts do not have multiple network > > > > interfaces, or if they do, do not use more than one of those > > > > interfaces at a time. and the vast majority of IPv4 hosts do not have > > > > multiple IPv4 addresses assigned to them. a lot of software will break > > > > in the presence of multiple addresses on a host. > > > > > > Show an example of software that will break. > > > > I just did. > > I guess you mean the netsolve case? That's good, let's explore it. > > > > If that address is a global one, why would it not be sufficient for all > > > clients? > > > > globally scoped does not mean globally reachable. > > That's a problem that exists independently of LL addresses. I don't see > how that is relevant to the discussion. well, you asked a specific question, and I gave a specific answer. frankly I don't see how your question is relevant to the discussion, but it was easy to answer. > > > > basically > > > > netsolve does not have the ability to deal with scoped addresses, and > > > > it's impractical to fix netsolve so that it does deal with them > > > > robustly.) > > > > > > Excellent, a concrete example! How does netsolve normally determine the > > > address it advertises? > > > > I'll have to look at the code again to be sure, but from memory, it does > > different things in different parts of the code > > Would you be so kind? It would be good to have something concrete to go > on. > > > a. getpeername() > > This could be a problem if the peer is somehow selecting an LL source > address. > > Under current rules, this would only happen if the it was attempting to > connect to an LL destination address, or if the application was > explicitly binding to the LL address. or if the peer did not currently have a routable address. > Which one of these would be the case with netsolve? > > > b. gethostbyname (gethostname ()) > > This will return a global address on any but LL-only nodes. not clear. for instance, my powerbook insists on setting its hostname based on its own whims. fortunately, most UNIX hosts are better behaved than that. also, when you say LL-only nodes do you mean nodes which cannot have a routable address (which IMHO should not exist) or do you mean nodes which currently do not have a routable address? > If this is the way in which each netsolve node discovers its own IP > address, then every node will only be advertising its global address > (again assuming there are no LL-only nodes involved). Am I correct? no. just because it's often possible to arrange things so that gethostbyname (gethostname ()) produces an address of one's choosing, does not mean that this is a reliable way to get a global address. From owner-zeroconf@merit.edu Sat Feb 22 12:09:27 2003 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 MAA13224 for ; Sat, 22 Feb 2003 12:09:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CB50191217; Sat, 22 Feb 2003 12:13:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F5489127C; Sat, 22 Feb 2003 12:13:10 -0500 (EST) 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 541C091217 for ; Sat, 22 Feb 2003 12:13:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 39BE95DF02; Sat, 22 Feb 2003 12:13:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 698EA5DE40 for ; Sat, 22 Feb 2003 12:13:08 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MHDgaj028599; Sat, 22 Feb 2003 19:13:42 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MHDepl028596; Sat, 22 Feb 2003 19:13:40 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com In-Reply-To: <20030222112609.18990282.moore@cs.utk.edu> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045934019.27185.157.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 19:13:39 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 18:26, Keith Moore wrote: > don't get me started about LLMNR. it's an even bigger mess than LL. > but that's for another group to deal with. Heh. I agree. Let's just say that LLMNR is a potential source of LL addresses and leave it at that. > > So, I expect no problems with applications that use gethostbyname(). > > that's an overgeneralization. there are lots of problems with scoped > addresses that have nothing to do with where the app gets the address from. Granted, but you know what I meant: I expect no problems due to applications using gethostbyname() on nodes having both LL and routable addresses. > IMHO looking at a few concrete examples tends to misses the point - because > you cannot analyze the behavior of all network applications. I'm not looking to generalize isolated examples. Concrete examples are necessary to support a viewpoint. If a problem is prevalent, coming up with concrete example cases should be quite easy. It goes to establishing credibility. > > > > If that address is a global one, why would it not be sufficient for all > > > > clients? > > > > > > globally scoped does not mean globally reachable. > > > > That's a problem that exists independently of LL addresses. I don't see > > how that is relevant to the discussion. > > well, you asked a specific question, and I gave a specific answer. frankly I > don't see how your question is relevant to the discussion, but it was easy to > answer. Ok, my bad. I was just trying to understand what you meant by your reference to the netsolve bind-to-specific-address kludge. I guess there was no particular significance hidden there. > > > a. getpeername() > > > > This could be a problem if the peer is somehow selecting an LL source > > address. > > > > Under current rules, this would only happen if the it was attempting to > > connect to an LL destination address, or if the application was > > explicitly binding to the LL address. > > or if the peer did not currently have a routable address. True. However, that is not relevant to the discussion, since neither LL1 nor LL23 can change that. > > Which one of these would be the case with netsolve? > > > > > b. gethostbyname (gethostname ()) > > > > This will return a global address on any but LL-only nodes. > > not clear. for instance, my powerbook insists on setting its hostname based > on its own whims. In other words, gethostbyname (gethostname ()) can fail to return an address even if the node only has a routable one. Clearly this can happen if the hostname is not registered in DNS, but I would say that is an unrelated problem. > fortunately, most UNIX hosts are better behaved than that. I guess any host can be misconfigured to return a bad hostname. > also, when you say LL-only nodes do you mean nodes which cannot have a > routable address (which IMHO should not exist) or do you mean nodes which > currently do not have a routable address? The latter (or both). > > If this is the way in which each netsolve node discovers its own IP > > address, then every node will only be advertising its global address > > (again assuming there are no LL-only nodes involved). Am I correct? > > no. just because it's often possible to arrange things so that > gethostbyname (gethostname ()) produces an address of one's choosing, > does not mean that this is a reliable way to get a global address. True. However, if gethostbyname (gethostname ()) fails to produce a global address it will do so regardless of whether the node has an LL address or not. I.e., the LL address is not the cause of the problem. MikaL From owner-zeroconf@merit.edu Sat Feb 22 12:19:48 2003 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 MAA13364 for ; Sat, 22 Feb 2003 12:19:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3F7899127C; Sat, 22 Feb 2003 12:23:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B27191288; Sat, 22 Feb 2003 12:23:30 -0500 (EST) 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 E2F509127C for ; Sat, 22 Feb 2003 12:23:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id C9CB05DF02; Sat, 22 Feb 2003 12:23:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id CB1C65DE40 for ; Sat, 22 Feb 2003 12:23:28 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MHO2aj028641; Sat, 22 Feb 2003 19:24:02 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MHO1Hs028640; Sat, 22 Feb 2003 19:24:01 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com In-Reply-To: <20030222112609.18990282.moore@cs.utk.edu> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045934640.27180.162.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 19:24:00 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 18:26, Keith Moore wrote: > > > > > basically > > > > > netsolve does not have the ability to deal with scoped addresses, and > > > > > it's impractical to fix netsolve so that it does deal with them > > > > > robustly.) > > > > > > > > Excellent, a concrete example! How does netsolve normally determine the > > > > address it advertises? > > > > > > I'll have to look at the code again to be sure, but from memory, it does > > > different things in different parts of the code > > > > Would you be so kind? It would be good to have something concrete to go > > on. Before I forget, can we conclude that nodes having both LL and routable addresses would not break netsolve? Or do you plan to provide additional evidence? MikaL From owner-zeroconf@merit.edu Sat Feb 22 12:39:52 2003 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 MAA13626 for ; Sat, 22 Feb 2003 12:39:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3D5C591288; Sat, 22 Feb 2003 12:43:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06E829128A; Sat, 22 Feb 2003 12:43:35 -0500 (EST) 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 A847191288 for ; Sat, 22 Feb 2003 12:43:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8C59D5DF12; Sat, 22 Feb 2003 12:43:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by segue.merit.edu (Postfix) with ESMTP id 614F45DEF9 for ; Sat, 22 Feb 2003 12:43:34 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mdgL-00024D-00; Sat, 22 Feb 2003 09:43:25 -0800 Date: Sat, 22 Feb 2003 12:40:23 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030222124023.63bc31d8.moore@cs.utk.edu> In-Reply-To: <1045934019.27185.157.camel@devil> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934019.27185.157.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > > So, I expect no problems with applications that use gethostbyname(). > > > > that's an overgeneralization. there are lots of problems with scoped > > addresses that have nothing to do with where the app gets the address > > from. > > Granted, but you know what I meant: I expect no problems due to > applications using gethostbyname() on nodes having both LL and routable > addresses. actually, no, that wasn't obvious. even then, I'm not sure it's true on hosts (like my powerbook) that arbitrarily set the hostname. > > IMHO looking at a few concrete examples tends to misses the point - > > because you cannot analyze the behavior of all network applications. > > I'm not looking to generalize isolated examples. Concrete examples are > necessary to support a viewpoint. If a problem is prevalent, coming up > with concrete example cases should be quite easy. It goes to > establishing credibility. part of the problem is that some of the examples are obscure, so people argue that it's okay to screw the net so that these obscure apps fail. what they fail to see is the harm that this does to the network's utility, and that obscure apps, and apps that don't exist yet, can be important also. also, it takes time to document examples, and when I've done so in the past people in this WG have conveniently forgotten about them. > > well, you asked a specific question, and I gave a specific answer. > > frankly I don't see how your question is relevant to the discussion, but > > it was easy to answer. > > Ok, my bad. I was just trying to understand what you meant by your > reference to the netsolve bind-to-specific-address kludge. basically that existing apps do have problems when multiple addresses are assigned to a host and not all of them are globally usable. > > > This could be a problem if the peer is somehow selecting an LL source > > > address. > > > > > > Under current rules, this would only happen if the it was attempting to > > > connect to an LL destination address, or if the application was > > > explicitly binding to the LL address. > > > > or if the peer did not currently have a routable address. > > True. However, that is not relevant to the discussion, since neither LL1 > nor LL23 can change that. it's hard to keep track of discussion contexts. > > > Which one of these would be the case with netsolve? > > > > > > > b. gethostbyname (gethostname ()) > > > > > > This will return a global address on any but LL-only nodes. > > > > not clear. for instance, my powerbook insists on setting its hostname > > based on its own whims. > > In other words, gethostbyname (gethostname ()) can fail to return an > address even if the node only has a routable one. or it can fail to return a routable address even if the node has one. it's *often* (perhaps not always) possible for a user to work around this, say by putting an entry in /etc/hosts. (I think there's an equivalent for windows, but it's fairly obscure). > > fortunately, most UNIX hosts are better behaved than that. > > I guess any host can be misconfigured to return a bad hostname. some hosts are shipped with code that overrides the user's specified hostname. > True. However, if gethostbyname (gethostname ()) fails to produce a > global address it will do so regardless of whether the node has an LL > address or not. I.e., the LL address is not the cause of the problem. I suppose it depends on the implementation. my powerbook kept insisting on setting its hostname to something like keith-moores-computer.local. whether or not it was binding that to an LL address I can't tell any longer - I did my best to disable all of that crap. Keith From owner-zeroconf@merit.edu Sat Feb 22 12:42:46 2003 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 MAA13688 for ; Sat, 22 Feb 2003 12:42:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A4B1A9128A; Sat, 22 Feb 2003 12:45:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 703629128B; Sat, 22 Feb 2003 12:45:39 -0500 (EST) 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 3DB159128A for ; Sat, 22 Feb 2003 12:45:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id D0C275DEF9; Sat, 22 Feb 2003 12:45:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by segue.merit.edu (Postfix) with ESMTP id 897F15DE40 for ; Sat, 22 Feb 2003 12:45:37 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mdiP-00010l-00; Sat, 22 Feb 2003 09:45:33 -0800 Date: Sat, 22 Feb 2003 12:42:30 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030222124230.3cd9a83b.moore@cs.utk.edu> In-Reply-To: <1045934640.27180.162.camel@devil> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934640.27180.162.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 22 Feb 2003 19:24:00 +0200 Mika Liljeberg wrote: > On Sat, 2003-02-22 at 18:26, Keith Moore wrote: > > > > > > basically > > > > > > netsolve does not have the ability to deal with scoped addresses, > > > > > > and it's impractical to fix netsolve so that it does deal with > > > > > > them robustly.) > > > > > > > > > > Excellent, a concrete example! How does netsolve normally determine > > > > > the address it advertises? > > > > > > > > I'll have to look at the code again to be sure, but from memory, it > > > > does different things in different parts of the code > > > > > > Would you be so kind? It would be good to have something concrete to go > > > on. > > Before I forget, can we conclude that nodes having both LL and routable > addresses would not break netsolve? Or do you plan to provide additional > evidence? no, we can't conclude that. there is emperical evidence that having scoped + global addresses on a host can break netsolve. that doesn't mean that I'll find the time to investigate and report in detail. Keith From owner-zeroconf@merit.edu Sat Feb 22 12:47:09 2003 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 MAA13730 for ; Sat, 22 Feb 2003 12:47:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7F13691206; Sat, 22 Feb 2003 12:50:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44E5291210; Sat, 22 Feb 2003 12:50:53 -0500 (EST) 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 368CD91206 for ; Sat, 22 Feb 2003 12:50:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 205535DE6C; Sat, 22 Feb 2003 12:50:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 0F3E35DE00 for ; Sat, 22 Feb 2003 12:50:51 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MHpQaj028746; Sat, 22 Feb 2003 19:51:27 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MHpOB0028744; Sat, 22 Feb 2003 19:51:24 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com In-Reply-To: <20030222124230.3cd9a83b.moore@cs.utk.edu> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934640.27180.162.camel@devil> <20030222124230.3cd9a83b.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045936283.27185.165.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 19:51:23 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 19:42, Keith Moore wrote: > > Before I forget, can we conclude that nodes having both LL and routable > > addresses would not break netsolve? Or do you plan to provide additional > > evidence? > > no, we can't conclude that. there is emperical evidence that having scoped + > global addresses on a host can break netsolve. that doesn't mean that I'll > find the time to investigate and report in detail. In other words the WG should just take your word for it. That's too bad. MikaL From owner-zeroconf@merit.edu Sat Feb 22 12:51:07 2003 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 MAA13770 for ; Sat, 22 Feb 2003 12:51:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6458E91210; Sat, 22 Feb 2003 12:54:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3435091213; Sat, 22 Feb 2003 12:54:52 -0500 (EST) 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 0378691210 for ; Sat, 22 Feb 2003 12:54:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id D8A205DE6C; Sat, 22 Feb 2003 12:54:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by segue.merit.edu (Postfix) with ESMTP id AFE5F5DE40 for ; Sat, 22 Feb 2003 12:54:50 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mdrI-00020U-00; Sat, 22 Feb 2003 09:54:44 -0800 Date: Sat, 22 Feb 2003 12:51:41 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030222125141.6f6171a2.moore@cs.utk.edu> In-Reply-To: <1045936283.27185.165.camel@devil> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934640.27180.162.camel@devil> <20030222124230.3cd9a83b.moore@cs.utk.edu> <1045936283.27185.165.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > > Before I forget, can we conclude that nodes having both LL and routable > > > addresses would not break netsolve? Or do you plan to provide additional > > > evidence? > > > > no, we can't conclude that. there is emperical evidence that having > > scoped + global addresses on a host can break netsolve. that doesn't > > mean that I'll find the time to investigate and report in detail. > > In other words the WG should just take your word for it. That's too bad. the problems are obvious to anyone who looks for them. From owner-zeroconf@merit.edu Sat Feb 22 13:18:05 2003 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 NAA14022 for ; Sat, 22 Feb 2003 13:18:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 97C4991223; Sat, 22 Feb 2003 13:21:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63A0C91230; Sat, 22 Feb 2003 13:21:48 -0500 (EST) 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 5D71591223 for ; Sat, 22 Feb 2003 13:21:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3DCFA5DE7A; Sat, 22 Feb 2003 13:21:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id D6B925DE00 for ; Sat, 22 Feb 2003 13:21:46 -0500 (EST) Received: from nominum.com (az-ben-pm3-2-18.ppp.theriver.com [206.25.50.18]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1MIImN15590; Sat, 22 Feb 2003 12:18:49 -0600 (CST) Date: Sat, 22 Feb 2003 11:21:43 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Zeroconf Working Group" To: "Philip Nye" From: Ted Lemon In-Reply-To: <004201c2da77$9536dfc0$131010ac@aldebaran> Message-Id: <7EBA5E17-4692-11D7-A12D-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > How? Give me a concretre example where keeping a LL address solves the > switching issue which can't be solved under LL1/LL23? You are on a network with a DHCP server, and you get a lease. Your friend is on a different network with a DHCP server, and gets a lease. You meet for lunch. You plug your computers into each other. Neither lease has yet expired. With LL1/LL23, the two computers cannot interoperate. Without LL1/LL23, they can. > You can't have it both ways. If you can stop hosts with both addresses > "advertising" the LL one, then that basically means it can't be used. > As > soon as it is used it gets picked up by aopplications and into the > system. That's right. It has to be advertised using LLMNS. It doesn't have to be provided to applications, except applications like the LLMNS agent that explicitly ask for it, and applications that connect to link-local destinations, which can get it with getlocalname(). From owner-zeroconf@merit.edu Sat Feb 22 13:25:03 2003 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 NAA14143 for ; Sat, 22 Feb 2003 13:25:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7601B9123D; Sat, 22 Feb 2003 13:27:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 418FA912A2; Sat, 22 Feb 2003 13:27:36 -0500 (EST) 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 585169123D for ; Sat, 22 Feb 2003 13:27:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 45BEC5DE40; Sat, 22 Feb 2003 13:27:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 4645C5DE7A for ; Sat, 22 Feb 2003 13:27:30 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MIS3aj028857; Sat, 22 Feb 2003 20:28:04 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MIS1um028854; Sat, 22 Feb 2003 20:28:01 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com In-Reply-To: <20030222124023.63bc31d8.moore@cs.utk.edu> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934019.27185.157.camel@devil> <20030222124023.63bc31d8.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045938480.27185.232.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 20:28:00 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 19:40, Keith Moore wrote: > > Granted, but you know what I meant: I expect no problems due to > > applications using gethostbyname() on nodes having both LL and routable > > addresses. > > actually, no, that wasn't obvious. > > even then, I'm not sure it's true on hosts (like my powerbook) that > arbitrarily set the hostname. As I said, any node can be misconfigured to return a bogus hostname. The presence or absense of an LL address has no bearing on this. An application relying on the hostname would fail regardless. > > I'm not looking to generalize isolated examples. Concrete examples are > > necessary to support a viewpoint. If a problem is prevalent, coming up > > with concrete example cases should be quite easy. It goes to > > establishing credibility. > > part of the problem is that some of the examples are obscure, so people argue > that it's okay to screw the net so that these obscure apps fail. what they > fail to see is the harm that this does to the network's utility, and that > obscure apps, and apps that don't exist yet, can be important also. I'm prepared to take your word that there are obscure examples. I expect there is. Obscure examples, however, don't support the claim that the problem would be prevalent and would somehow "cripple the net". I also agree that apps which don't exist yet are important. However, if they want to stick to routable addresses they can easily do so. They don't have the excuse of not knowing about LL addresses. I would even be prepared to take some reasonable measures to mitigate the obscure problems if I knew what is the right thing to do and if it was simple to do. Currently, I'm not convinced that LL1 or LL23 is it. Until I am, the added implementation complexity will cause me to reject them. > also, it > takes time to document examples, and when I've done so in the past people in > this WG have conveniently forgotten about them. I freely admit that I probably haven't seen those examples. If you can provide a pointer to the archive I would be happy to review them. In the interest of resolving issues LL1 and LL23, however, it would be better to discuss them on the list. > > Ok, my bad. I was just trying to understand what you meant by your > > reference to the netsolve bind-to-specific-address kludge. > > basically that existing apps do have problems when multiple addresses are > assigned to a host and not all of them are globally usable. Ok. A general argument against scoped addressing, then. Valid, perhaps, but not useful for determining the technical soundness of LL1 and LL23. > > In other words, gethostbyname (gethostname ()) can fail to return an > > address even if the node only has a routable one. > > or it can fail to return a routable address even if the node has one. Indeed. Fail is the operative word. > I suppose it depends on the implementation. my powerbook kept insisting > on setting its hostname to something like keith-moores-computer.local. > whether or not it was binding that to an LL address I can't tell any longer - > I did my best to disable all of that crap. Well, sounds like a Windows specific problem. Maybe Christian can comment? :-) MikaL From owner-zeroconf@merit.edu Sat Feb 22 13:25:10 2003 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 NAA14158 for ; Sat, 22 Feb 2003 13:25:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9AAD2912AA; Sat, 22 Feb 2003 13:28:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53E8B912B1; Sat, 22 Feb 2003 13:28:21 -0500 (EST) 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 DB50E912AA for ; Sat, 22 Feb 2003 13:28:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id C91405DE40; Sat, 22 Feb 2003 13:28:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 983535DE00 for ; Sat, 22 Feb 2003 13:28:13 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MISlaj028878; Sat, 22 Feb 2003 20:28:47 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MISieo028877; Sat, 22 Feb 2003 20:28:44 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com In-Reply-To: <20030222125141.6f6171a2.moore@cs.utk.edu> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934640.27180.162.camel@devil> <20030222124230.3cd9a83b.moore@cs.utk.edu> <1045936283.27185.165.camel@devil> <20030222125141.6f6171a2.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045938523.27180.234.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 20:28:44 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 19:51, Keith Moore wrote: > > > no, we can't conclude that. there is emperical evidence that having > > > scoped + global addresses on a host can break netsolve. that doesn't > > > mean that I'll find the time to investigate and report in detail. > > > > In other words the WG should just take your word for it. That's too bad. > > the problems are obvious to anyone who looks for them. Well, you have to admit that I'm trying very hard to understand your point of view. Are we going to be left without any concrete examples to support your view? MikaL From owner-zeroconf@merit.edu Sat Feb 22 14:32:40 2003 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 OAA14687 for ; Sat, 22 Feb 2003 14:32:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 526AA91221; Sat, 22 Feb 2003 14:36:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E4759123E; Sat, 22 Feb 2003 14:36:24 -0500 (EST) 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 BD10291221 for ; Sat, 22 Feb 2003 14:36:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9FB105DF19; Sat, 22 Feb 2003 14:36:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by segue.merit.edu (Postfix) with ESMTP id 768545DED4 for ; Sat, 22 Feb 2003 14:36:22 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mfRQ-0005Y1-00; Sat, 22 Feb 2003 11:36:08 -0800 Date: Sat, 22 Feb 2003 14:33:05 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030222143305.17390c4b.moore@cs.utk.edu> In-Reply-To: <1045938480.27185.232.camel@devil> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934019.27185.157.camel@devil> <20030222124023.63bc31d8.moore@cs.utk.edu> <1045938480.27185.232.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > > Granted, but you know what I meant: I expect no problems due to > > > applications using gethostbyname() on nodes having both LL and routable > > > addresses. > > > > actually, no, that wasn't obvious. > > > > even then, I'm not sure it's true on hosts (like my powerbook) that > > arbitrarily set the hostname. > > As I said, any node can be misconfigured to return a bogus hostname. my point is that some nodes do this out of the box, and are not easily fixed to not do this. > The presence or absense of an LL address has no bearing on this. An > application relying on the hostname would fail regardless. not true in the case of my powerbook, which will at least in some cases choose a host name that is only associated with an LL address. > I'm prepared to take your word that there are obscure examples. I expect > there is. Obscure examples, however, don't support the claim that the > problem would be prevalent and would somehow "cripple the net". actually they do - as long as the apps fail for reasons that would be commonly encountered. what causes one app to fail can cause another app to fail. > I also agree that apps which don't exist yet are important. However, if > they want to stick to routable addresses they can easily do so. only if all hosts on which the app is running have routable addresses. > I would even be prepared to take some reasonable measures to mitigate > the obscure problems if I knew what is the right thing to do and if it > was simple to do. Currently, I'm not convinced that LL1 or LL23 is it. > Until I am, the added implementation complexity will cause me to reject > them. the specific language of both proposals may be broken, but in general avoiding use of LL when a host has a routable address will greatly minimize the problems associated with LL. > > basically that existing apps do have problems when multiple addresses are > > assigned to a host and not all of them are globally usable. > > Ok. A general argument against scoped addressing, then. Valid, perhaps, > but not useful for determining the technical soundness of LL1 and LL23. I disagree, because without a way to disable LL when routable addresses are in use, this condition that causes app failures will crop up considerably more often than it does now. > > I suppose it depends on the implementation. my powerbook kept insisting > > on setting its hostname to something like keith-moores-computer.local. > > whether or not it was binding that to an LL address I can't tell any > > longer - I did my best to disable all of that crap. > > Well, sounds like a Windows specific problem. Maybe Christian can > comment? :-) how would a powerbook failure be windows-specific? it runs macos. Keith From owner-zeroconf@merit.edu Sat Feb 22 14:33:30 2003 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 OAA14704 for ; Sat, 22 Feb 2003 14:33:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D37859123E; Sat, 22 Feb 2003 14:37:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D46491246; Sat, 22 Feb 2003 14:37:14 -0500 (EST) 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 A34FB9123E for ; Sat, 22 Feb 2003 14:37:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 903BD5DED4; Sat, 22 Feb 2003 14:37:13 -0500 (EST) 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 45CFD5DDDE for ; Sat, 22 Feb 2003 14:37:13 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 85F4659886 for ; Sat, 22 Feb 2003 19:37:16 +0000 (GMT) Message-ID: <000801c2daa9$f77bf760$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <7EBA5E17-4692-11D7-A12D-00039317663C@nominum.com> Subject: Re: LL1, LL23 Date: Sat, 22 Feb 2003 19:38:24 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Ted Lemon" > > > How? Give me a concretre example where keeping a LL address solves the > > switching issue which can't be solved under LL1/LL23? > > You are on a network with a DHCP server, and you get a lease. Your > friend is on a different network with a DHCP server, and gets a lease. > You meet for lunch. You plug your computers into each other. > Neither lease has yet expired. With LL1/LL23, the two computers > cannot interoperate. Without LL1/LL23, they can. How does the system know that it is now safe to use a LL address because the DHCP addresses aren't working? This question is the same whether you have LL1/LL23 or not. If you know that LL is the only thing which will work, then you are free to use it. If you don't know this but use it anyway then you will break things. > > You can't have it both ways. If you can stop hosts with both addresses > > "advertising" the LL one, then that basically means it can't be used. > > As > > soon as it is used it gets picked up by aopplications and into the > > system. > > That's right. It has to be advertised using LLMNS. It doesn't have > to be provided to applications, except applications like the LLMNS > agent that explicitly ask for it, and applications that connect to > link-local destinations, which can get it with getlocalname(). So generic applications (like ftp) cannot use the LL network? Only apps which use LLMNS and NEVER refer to a peer other than by its LLMNS name? This seems particularly broken to me. The only point in having a LL address is to use it. If you use it then it will get into the application layer and some applications will pass it around. If LL is all you have then that is fair enough but if you have a routable address then you (and possibly the whole system) will suffer if your LL address gets out. Which means don't use it. There is a misconception here that the only way applications get IP addresses is via DNS and its derivatives. This is complete tosh - there are lots of ways that applications get hold of addresses - and whole networks without named hosts. The very idea of having to give a host a name is by definition not zero-config! If you send a packet to me using your LL address than I have that address and you have already lost control of where it gets to. Philip From owner-zeroconf@merit.edu Sat Feb 22 14:35:15 2003 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 OAA14745 for ; Sat, 22 Feb 2003 14:35:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1872591246; Sat, 22 Feb 2003 14:38:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CDE5191247; Sat, 22 Feb 2003 14:38:51 -0500 (EST) 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 A561391246 for ; Sat, 22 Feb 2003 14:38:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8CEC35DF20; Sat, 22 Feb 2003 14:38:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by segue.merit.edu (Postfix) with ESMTP id 66BD85DF19 for ; Sat, 22 Feb 2003 14:38:50 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mfTs-0001G7-00; Sat, 22 Feb 2003 11:38:40 -0800 Date: Sat, 22 Feb 2003 14:35:37 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030222143537.6bd7c13f.moore@cs.utk.edu> In-Reply-To: <1045938523.27180.234.camel@devil> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934640.27180.162.camel@devil> <20030222124230.3cd9a83b.moore@cs.utk.edu> <1045936283.27185.165.camel@devil> <20030222125141.6f6171a2.moore@cs.utk.edu> <1045938523.27180.234.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Well, you have to admit that I'm trying very hard to understand your > point of view. > > Are we going to be left without any concrete examples to support your > view? I would like to supply such examples. But I doubt I'll have time to investigate and write them up in detail within the next several days. From owner-zeroconf@merit.edu Sat Feb 22 15:08:15 2003 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 PAA14976 for ; Sat, 22 Feb 2003 15:08:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5554C91247; Sat, 22 Feb 2003 15:12:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 210BF91258; Sat, 22 Feb 2003 15:12:00 -0500 (EST) 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 D03CE91247 for ; Sat, 22 Feb 2003 15:11:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id B31E15DF19; Sat, 22 Feb 2003 15:11:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id CA0935DEFE for ; Sat, 22 Feb 2003 15:11:57 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MKCWaj029250; Sat, 22 Feb 2003 22:12:32 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MKCTKc029249; Sat, 22 Feb 2003 22:12:29 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com In-Reply-To: <20030222143305.17390c4b.moore@cs.utk.edu> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934019.27185.157.camel@devil> <20030222124023.63bc31d8.moore@cs.utk.edu> <1045938480.27185.232.camel@devil> <20030222143305.17390c4b.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045944748.27185.264.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 22:12:29 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 21:33, Keith Moore wrote: > > As I said, any node can be misconfigured to return a bogus hostname. > > my point is that some nodes do this out of the box, and are not easily > fixed to not do this. > > > The presence or absense of an LL address has no bearing on this. An > > application relying on the hostname would fail regardless. > > not true in the case of my powerbook, which will at least in some cases > choose a host name that is only associated with an LL address. That's still an OS specific problem. We don't put vendor specific bug workarounds into IETF specifications. > > I'm prepared to take your word that there are obscure examples. I expect > > there is. Obscure examples, however, don't support the claim that the > > problem would be prevalent and would somehow "cripple the net". > > actually they do - as long as the apps fail for reasons that would be > commonly encountered. what causes one app to fail can cause another app to > fail. If the failures were common they wouldn't be obscure. You can't have it both ways. > > I also agree that apps which don't exist yet are important. However, if > > they want to stick to routable addresses they can easily do so. > > only if all hosts on which the app is running have routable addresses. I agree that configurations with LL-only nodes will fail. This is not relevant to the LL1/LL23 discussion. > > I would even be prepared to take some reasonable measures to mitigate > > the obscure problems if I knew what is the right thing to do and if it > > was simple to do. Currently, I'm not convinced that LL1 or LL23 is it. > > Until I am, the added implementation complexity will cause me to reject > > them. > > the specific language of both proposals may be broken, but in general avoiding > use of LL when a host has a routable address will greatly minimize the > problems associated with LL. It's not a problem of language. It's a problem of implementation complexity versus usefulness. At the moment the tradeoff does not favor LL1/LL23. > > > basically that existing apps do have problems when multiple addresses are > > > assigned to a host and not all of them are globally usable. > > > > Ok. A general argument against scoped addressing, then. Valid, perhaps, > > but not useful for determining the technical soundness of LL1 and LL23. > > I disagree, because without a way to disable LL when routable addresses > are in use, this condition that causes app failures will crop up considerably > more often than it does now. We're degenerating to generalities again. We have yet to see any proof of this. > > > I suppose it depends on the implementation. my powerbook kept insisting > > > on setting its hostname to something like keith-moores-computer.local. > > > whether or not it was binding that to an LL address I can't tell any > > > longer - I did my best to disable all of that crap. > > > > Well, sounds like a Windows specific problem. Maybe Christian can > > comment? :-) > > how would a powerbook failure be windows-specific? it runs macos. Oops, brain fart. Sorry, Christian! Maybe Stuart can comment? :-) MikaL From owner-zeroconf@merit.edu Sat Feb 22 15:24:56 2003 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 PAA15101 for ; Sat, 22 Feb 2003 15:24:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 46BB09121F; Sat, 22 Feb 2003 15:28:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 169F591258; Sat, 22 Feb 2003 15:28:41 -0500 (EST) 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 1895E9121F for ; Sat, 22 Feb 2003 15:28:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id EFEAF5DEF9; Sat, 22 Feb 2003 15:28:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 9EAE55DDDE for ; Sat, 22 Feb 2003 15:28:39 -0500 (EST) Received: from nominum.com (az-ben-pm3-2-18.ppp.theriver.com [206.25.50.18]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1MKPbN16566 for ; Sat, 22 Feb 2003 14:25:40 -0600 (CST) Date: Sat, 22 Feb 2003 13:28:33 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030222143305.17390c4b.moore@cs.utk.edu> Message-Id: <366FFFAC-46A4-11D7-A12D-00039317663C@nominum.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > not true in the case of my powerbook, which will at least in some cases > choose a host name that is only associated with an LL address. If true, this is a bug. The right thing to do about it is to fix the bug, not to break the protocol. From owner-zeroconf@merit.edu Sat Feb 22 15:34:08 2003 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 PAA15197 for ; Sat, 22 Feb 2003 15:34:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C6BDE91258; Sat, 22 Feb 2003 15:37:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8849F9125B; Sat, 22 Feb 2003 15:37:52 -0500 (EST) 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 67E1091258 for ; Sat, 22 Feb 2003 15:37:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4701A5DEFE; Sat, 22 Feb 2003 15:37:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id A92575DEF9 for ; Sat, 22 Feb 2003 15:37:50 -0500 (EST) Received: from nominum.com (az-ben-pm3-2-18.ppp.theriver.com [206.25.50.18]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1MKYRN16670 for ; Sat, 22 Feb 2003 14:34:34 -0600 (CST) Date: Sat, 22 Feb 2003 13:37:13 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: "Zeroconf Working Group" Content-Transfer-Encoding: 7bit In-Reply-To: <000801c2daa9$f77bf760$131010ac@aldebaran> Message-Id: <6C98F925-46A5-11D7-A12D-00039317663C@nominum.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > How does the system know that it is now safe to use a LL address > because the > DHCP addresses aren't working? This question is the same whether you > have > LL1/LL23 or not. If you know that LL is the only thing which will > work, then > you are free to use it. If you don't know this but use it anyway then > you > will break things. It's always safe to use an IPv4ll address to communicate with another device with an IPv4ll address. I think that the right way to fix this is in the LLMNS resolver - if you get back an IP address that's not locally reachable, you don't provide that address to the application. So if you have two devices that both do link-local, and both also have global addresses, then each device advertises both addresses using LLMNS. If both devices are configured to use the same IP subnet, then LLMNS returns the global IP address. If the devices are configured to use different subnets, LLMNS returns the IPv4ll address. The application doesn't ever even see an inappropriate address - it's handled in the resolver. Unfortunately, this solution is somewhat off-topic, since we're talking about IPv4ll, but this is how I would solve the problem. I think that solving the problem by adding a great deal of complexity to IPv4ll isn't going to be satisfactory for anybody who uses IPv4ll. > So generic applications (like ftp) cannot use the LL network? Only apps > which use LLMNS and NEVER refer to a peer other than by its LLMNS > name? This > seems particularly broken to me. All apps use both LLMNS and DNS, according to the rules of those protocols. If you don't use LLMNS or some other link-local node discovery protocol, you can't use IPv4ll addresses anyway. The transparency of IPv4ll depends specifically on LLMNS in most cases, like it or not. > There is a misconception here that the only way applications get IP > addresses is via DNS and its derivatives. This is complete tosh - > there are > lots of ways that applications get hold of addresses - and whole > networks > without named hosts. The very idea of having to give a host a name is > by > definition not zero-config! If you send a packet to me using your LL > address > than I have that address and you have already lost control of where it > gets > to. Sure, you can use any sort of resource-discovery protocol, as long as it works. Or you can just type in IP addresses. What's your point? From owner-zeroconf@merit.edu Sat Feb 22 16:10:34 2003 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 QAA15662 for ; Sat, 22 Feb 2003 16:10:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F34CB91298; Sat, 22 Feb 2003 16:14:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2A3B91299; Sat, 22 Feb 2003 16:14:17 -0500 (EST) 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 9060691298 for ; Sat, 22 Feb 2003 16:14:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 668945DEDA; Sat, 22 Feb 2003 16:14:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 30EDE5DDD4 for ; Sat, 22 Feb 2003 16:14:15 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MLEuaj029471; Sat, 22 Feb 2003 23:14:56 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MLErKI029468; Sat, 22 Feb 2003 23:14:53 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Ted Lemon Cc: Zeroconf Working Group In-Reply-To: <6C98F925-46A5-11D7-A12D-00039317663C@nominum.com> References: <6C98F925-46A5-11D7-A12D-00039317663C@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045948492.27180.274.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 22 Feb 2003 23:14:53 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 22:37, Ted Lemon wrote: > It's always safe to use an IPv4ll address to communicate with another > device with an IPv4ll address. I think that the right way to fix this > is in the LLMNS resolver - if you get back an IP address that's not > locally reachable, you don't provide that address to the application. > So if you have two devices that both do link-local, and both also have > global addresses, then each device advertises both addresses using > LLMNS. If both devices are configured to use the same IP subnet, then > LLMNS returns the global IP address. If the devices are configured to > use different subnets, LLMNS returns the IPv4ll address. The > application doesn't ever even see an inappropriate address - it's > handled in the resolver. That's an excellent idea. A convenient way to support this is on the OS is to add a system call that returns a valid source address for a given destination address (running it through route selection and source address selection). If a valid source address can be found, the tested address can be returned from the LLMNR resolver. > Unfortunately, this solution is somewhat off-topic, since we're talking > about IPv4ll, but this is how I would solve the problem. I think that > solving the problem by adding a great deal of complexity to IPv4ll > isn't going to be satisfactory for anybody who uses IPv4ll. Very much agreed. MikaL From owner-zeroconf@merit.edu Sat Feb 22 16:16:10 2003 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 QAA15725 for ; Sat, 22 Feb 2003 16:16:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2D70491299; Sat, 22 Feb 2003 16:19:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF21C9129F; Sat, 22 Feb 2003 16:19:45 -0500 (EST) 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 F36EF91299 for ; Sat, 22 Feb 2003 16:19:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id DCCCA5DF84; Sat, 22 Feb 2003 16:19:44 -0500 (EST) 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 921CC5DF7C for ; Sat, 22 Feb 2003 16:19:44 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 2D0D859895 for ; Sat, 22 Feb 2003 21:19:48 +0000 (GMT) Message-ID: <001801c2dab8$49f8b970$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <6C98F925-46A5-11D7-A12D-00039317663C@nominum.com> Subject: Re: LL1, LL23 Date: Sat, 22 Feb 2003 21:20:56 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Ted Lemon" > > > So generic applications (like ftp) cannot use the LL network? Only apps > > which use LLMNS and NEVER refer to a peer other than by its LLMNS > > name? This > > seems particularly broken to me. > > All apps use both LLMNS and DNS, according to the rules of those > protocols. If you don't use LLMNS or some other link-local node > discovery protocol, you can't use IPv4ll addresses anyway. The > transparency of IPv4ll depends specifically on LLMNS in most cases, > like it or not. I don't buy this at all. If the IP world was a cozy place where apps dealt only with names and relied on a narrow DNS/LLMNS system to work out the details then what you propose might work. However this is only a small part of the IP world. There are many applications in the embedded world where LL is very attractive, but for which LLMNS (or DNS) is a complete irrelevance. Things like SLP and a host of specialist small scale discovery protocols are much more relevant. Don't get me wrong - I am as concerned about the case of transition from configured to LL as you are - as my previous posts show. I just don't see that running LL concurrently really helps unless you sacrifice a lot of applications. If there is a way to tell when it is safe to switch over, then that applies in all cases and I would like to explore that. > > There is a misconception here that the only way applications get IP > > addresses is via DNS and its derivatives. This is complete tosh - > > there are > > lots of ways that applications get hold of addresses - and whole > > networks > > without named hosts. The very idea of having to give a host a name is > > by > > definition not zero-config! If you send a packet to me using your LL > > address > > than I have that address and you have already lost control of where it > > gets > > to. > > Sure, you can use any sort of resource-discovery protocol, as long as > it works. Or you can just type in IP addresses. What's your point? My point is that unless you make each and every one of these myraiad ways that apps discover each other LL aware, and secure against mis-scoping, then you can't be sure that LL addresses will be confined to scope. If all those ways NEVER reveal a LL address when a configured one is present then it is true that those addresses will not leak out of scope - but a whole lot of applications will not be able to communicate using LL either. Philip From owner-zeroconf@merit.edu Sat Feb 22 16:25:55 2003 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 QAA15879 for ; Sat, 22 Feb 2003 16:25:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1AB5E912D9; Sat, 22 Feb 2003 16:29:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D602F912CE; Sat, 22 Feb 2003 16:29:12 -0500 (EST) 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 0A958912A4 for ; Sat, 22 Feb 2003 16:29:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id E38AC5DF7C; Sat, 22 Feb 2003 16:29:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by segue.merit.edu (Postfix) with ESMTP id C15935DF26 for ; Sat, 22 Feb 2003 16:29:04 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mhCV-0004Ev-00; Sat, 22 Feb 2003 13:28:51 -0800 Date: Sat, 22 Feb 2003 16:26:05 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030222162605.506279bf.moore@cs.utk.edu> In-Reply-To: <1045944748.27185.264.camel@devil> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934019.27185.157.camel@devil> <20030222124023.63bc31d8.moore@cs.utk.edu> <1045938480.27185.232.camel@devil> <20030222143305.17390c4b.moore@cs.utk.edu> <1045944748.27185.264.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Sat, 2003-02-22 at 21:33, Keith Moore wrote: > > > As I said, any node can be misconfigured to return a bogus hostname. > > > > my point is that some nodes do this out of the box, and are not easily > > fixed to not do this. > > > > > The presence or absense of an LL address has no bearing on this. An > > > application relying on the hostname would fail regardless. > > > > not true in the case of my powerbook, which will at least in some cases > > choose a host name that is only associated with an LL address. > > That's still an OS specific problem. We don't put vendor specific bug > workarounds into IETF specifications. disagree. installed base compatibility is often a design issue in IETF specs. > > > I'm prepared to take your word that there are obscure examples. I expect > > > there is. Obscure examples, however, don't support the claim that the > > > problem would be prevalent and would somehow "cripple the net". > > > > actually they do - as long as the apps fail for reasons that would be > > commonly encountered. what causes one app to fail can cause another app > > to fail. > > If the failures were common they wouldn't be obscure. You can't have it > both ways. the failures are common to several apps, but the individual apps are obscure. but because the failures are associated with obscure apps, they might not be recognized as different symptoms of the same problem. > > > I also agree that apps which don't exist yet are important. However, if > > > they want to stick to routable addresses they can easily do so. > > > > only if all hosts on which the app is running have routable addresses. > > I agree that configurations with LL-only nodes will fail. This is not > relevant to the LL1/LL23 discussion. yes it is, because even nodes capable of having routable addresses will sometimes fail to have them, or fail to use them, unless we specify the conditions under which routable addresses are preferred over LLs. > > > I would even be prepared to take some reasonable measures to mitigate > > > the obscure problems if I knew what is the right thing to do and if it > > > was simple to do. Currently, I'm not convinced that LL1 or LL23 is it. > > > Until I am, the added implementation complexity will cause me to reject > > > them. > > > > the specific language of both proposals may be broken, but in general > > avoiding use of LL when a host has a routable address will greatly > > minimize the problems associated with LL. > > It's not a problem of language. It's a problem of implementation > complexity versus usefulness. At the moment the tradeoff does not favor > LL1/LL23. strongly disagree. it's not acceptable for LL to break apps, especially not without providing a workaround. > > > > basically that existing apps do have problems when multiple addresses > > > > are assigned to a host and not all of them are globally usable. > > > > > > Ok. A general argument against scoped addressing, then. Valid, perhaps, > > > but not useful for determining the technical soundness of LL1 and LL23. > > > > I disagree, because without a way to disable LL when routable addresses > > are in use, this condition that causes app failures will crop up > > considerably more often than it does now. > > We're degenerating to generalities again. We have yet to see any proof > of this. proof has been given more than once. Keith From owner-zeroconf@merit.edu Sat Feb 22 17:02:07 2003 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 RAA16424 for ; Sat, 22 Feb 2003 17:02:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7DED9912A5; Sat, 22 Feb 2003 17:05:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51668912B0; Sat, 22 Feb 2003 17:05:43 -0500 (EST) 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 231F8912A5 for ; Sat, 22 Feb 2003 17:05:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id F3E945DDB1; Sat, 22 Feb 2003 17:05:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 3E7485DD9B for ; Sat, 22 Feb 2003 17:05:41 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MM6Gaj029652; Sun, 23 Feb 2003 00:06:16 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MM6DaU029649; Sun, 23 Feb 2003 00:06:13 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com In-Reply-To: <20030222162605.506279bf.moore@cs.utk.edu> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934019.27185.157.camel@devil> <20030222124023.63bc31d8.moore@cs.utk.edu> <1045938480.27185.232.camel@devil> <20030222143305.17390c4b.moore@cs.utk.edu> <1045944748.27185.264.camel@devil> <20030222162605.506279bf.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045951573.27180.299.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Feb 2003 00:06:13 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-02-22 at 23:26, Keith Moore wrote: > > > not true in the case of my powerbook, which will at least in some cases > > > choose a host name that is only associated with an LL address. > > > > That's still an OS specific problem. We don't put vendor specific bug > > workarounds into IETF specifications. > > disagree. installed base compatibility is often a design issue in IETF specs. Bug workarounds aren't. Bugs should be fixed, not coddled. > > If the failures were common they wouldn't be obscure. You can't have it > > both ways. > > the failures are common to several apps, but the individual apps are obscure. > but because the failures are associated with obscure apps, they might not > be recognized as different symptoms of the same problem. If there are a lot of these obscure problem apps I might be familiar with some of them. Suppose you mention a few and I say if anything rings a bell? > > I agree that configurations with LL-only nodes will fail. This is not > > relevant to the LL1/LL23 discussion. > > yes it is, because even nodes capable of having routable addresses will > sometimes fail to have them, or fail to use them, unless we specify > the conditions under which routable addresses are preferred over LLs. The draft already does that. LL1/LL23 just seeks to define different rules. What we're trying to determine is whether that change is worth the trouble. > > It's not a problem of language. It's a problem of implementation > > complexity versus usefulness. At the moment the tradeoff does not favor > > LL1/LL23. > > strongly disagree. it's not acceptable for LL to break apps, especially > not without providing a workaround. We can't possibly provide a workaround for every broken app out there. That's simply impossible, not to mention a poor design philosophy. > > We're degenerating to generalities again. We have yet to see any proof > > of this. > > proof has been given more than once. I haven't seen any proof that LL1/LL23 is a good idea. MikaL From owner-zeroconf@merit.edu Sat Feb 22 17:17:47 2003 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 RAA16559 for ; Sat, 22 Feb 2003 17:17:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 27806912B1; Sat, 22 Feb 2003 17:21:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ACE9C912B7; Sat, 22 Feb 2003 17:21:21 -0500 (EST) 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 C1F48912B1 for ; Sat, 22 Feb 2003 17:21:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9F60E5DE57; Sat, 22 Feb 2003 17:21:18 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by segue.merit.edu (Postfix) with ESMTP id 7BFA15DDF3 for ; Sat, 22 Feb 2003 17:21:18 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mi18-00063F-00; Sat, 22 Feb 2003 14:21:10 -0800 Date: Sat, 22 Feb 2003 17:18:24 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030222171824.3c6604ad.moore@cs.utk.edu> In-Reply-To: <1045951573.27180.299.camel@devil> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934019.27185.157.camel@devil> <20030222124023.63bc31d8.moore@cs.utk.edu> <1045938480.27185.232.camel@devil> <20030222143305.17390c4b.moore@cs.utk.edu> <1045944748.27185.264.camel@devil> <20030222162605.506279bf.moore@cs.utk.edu> <1045951573.27180.299.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > > > not true in the case of my powerbook, which will at least in some cases > > > > choose a host name that is only associated with an LL address. > > > > > > That's still an OS specific problem. We don't put vendor specific bug > > > workarounds into IETF specifications. > > > > disagree. installed base compatibility is often a design issue in IETF specs. > > Bug workarounds aren't. sure they are. it's just being pragmatic. > > > If the failures were common they wouldn't be obscure. You can't have it > > > both ways. > > > > the failures are common to several apps, but the individual apps are obscure. > > but because the failures are associated with obscure apps, they might not > > be recognized as different symptoms of the same problem. > > If there are a lot of these obscure problem apps I might be familiar > with some of them. Suppose you mention a few and I say if anything rings > a bell? most of them are obscure to me, too. but netsolve, PVM, and SIP certainly qualify. others worth looking at are MPI implementations, various distributed games, distributed simulations, conferencing software. > > > I agree that configurations with LL-only nodes will fail. This is not > > > relevant to the LL1/LL23 discussion. > > > > yes it is, because even nodes capable of having routable addresses will > > sometimes fail to have them, or fail to use them, unless we specify > > the conditions under which routable addresses are preferred over LLs. > > The draft already does that. the current draft does it in such a way as to *cause* problems. > > > It's not a problem of language. It's a problem of implementation > > > complexity versus usefulness. At the moment the tradeoff does not favor > > > LL1/LL23. > > > > strongly disagree. it's not acceptable for LL to break apps, especially > > not without providing a workaround. > > We can't possibly provide a workaround for every broken app out there. > That's simply impossible, not to mention a poor design philosophy. the apps aren't broken. scoped addresses are broken. > > > We're degenerating to generalities again. We have yet to see any proof > > > of this. > > > > proof has been given more than once. > > I haven't seen any proof that LL1/LL23 is a good idea. that's just because you don't want to see it. From owner-zeroconf@merit.edu Sat Feb 22 18:00:46 2003 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 SAA16908 for ; Sat, 22 Feb 2003 18:00:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 37751912CA; Sat, 22 Feb 2003 18:04:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4FEA912CE; Sat, 22 Feb 2003 18:04:12 -0500 (EST) 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 31318912CA for ; Sat, 22 Feb 2003 18:04:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 037445DEDF; Sat, 22 Feb 2003 18:04:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id DB08F5DD8D for ; Sat, 22 Feb 2003 18:04:06 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1MN4gaj029863; Sun, 23 Feb 2003 01:04:42 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1MN4dZH029860; Sun, 23 Feb 2003 01:04:39 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com In-Reply-To: <20030222171824.3c6604ad.moore@cs.utk.edu> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934019.27185.157.camel@devil> <20030222124023.63bc31d8.moore@cs.utk.edu> <1045938480.27185.232.camel@devil> <20030222143305.17390c4b.moore@cs.utk.edu> <1045944748.27185.264.camel@devil> <20030222162605.506279bf.moore@cs.utk.edu> <1045951573.27180.299.camel@devil> <20030222171824.3c6604ad.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045955078.27185.329.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Feb 2003 01:04:39 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-02-23 at 00:18, Keith Moore wrote: > > If there are a lot of these obscure problem apps I might be familiar > > with some of them. Suppose you mention a few and I say if anything rings > > a bell? > > most of them are obscure to me, too. but netsolve, PVM, and SIP certainly > qualify. others worth looking at are MPI implementations, various distributed > games, distributed simulations, conferencing software. Ok, these are apps that might have problems with scoped addresses, at least. SIP and H.323 are probably the most likely candidates. Don't know too much about MPI implementations but the rest don't look like referral apps. Multiplayer games typically just use centralized servers. LL will probably just benefit LAN gaming. Anyone know one of these well enough to give a concrete example supporting LL1 or LL23? I don't want to impose on Keith too much, since he is pressed for time. (Netsolve we already did; didn't seem to be a problem. ) > the current draft does it in such a way as to *cause* problems. > the apps aren't broken. scoped addresses are broken. > that's just because you don't want to see it. You don't give up, do you? MikaL From owner-zeroconf@merit.edu Sat Feb 22 18:31:08 2003 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 SAA17357 for ; Sat, 22 Feb 2003 18:31:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0D63A91237; Sat, 22 Feb 2003 18:34:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E056912C6; Sat, 22 Feb 2003 18:34:41 -0500 (EST) 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 2094891237 for ; Sat, 22 Feb 2003 18:34:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0EDC85DFB7; Sat, 22 Feb 2003 18:34:39 -0500 (EST) 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 CA1605DDF8 for ; Sat, 22 Feb 2003 18:34:38 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id E020F59B75 for ; Sat, 22 Feb 2003 23:34:42 +0000 (GMT) Message-ID: <005d01c2dacb$2295e3e0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934019.27185.157.camel@devil> <20030222124023.63bc31d8.moore@cs.utk.edu> <1045938480.27185.232.camel@devil> <20030222143305.17390c4b.moore@cs.utk.edu> <1045944748.27185.264.camel@devil> Subject: Re: LL1, LL23 Date: Sat, 22 Feb 2003 23:35:50 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Mika Liljeberg" > I agree that configurations with LL-only nodes will fail. This is not > relevant to the LL1/LL23 discussion. It is highly relevant because the issue of allowing LL only nodes has not yet been discussed and may go either way so far as I can tell. If LL1 and LL23 are rejected and then LL-only nodes are allowed then we are really in trouble. As it is LL-only nodes will exist anyway - because of configuration issues and because of transition issues (and because there is sufficient commercial pressure that they will be built whether or not this standard blesses them). Why define a standard which falls over in their presence when with a little more effort it can be a lot more robust? Why define a standard which relies heavily on things like LLMNS (itself not a standard ) when with a little more effort it can be far more generic? I can only conclude that you don't want to put in that effort. LL23/LL1 are not over complex and the principle behind them provides the best (though imperfect) interoperability in the widest range of situations. Philip From owner-zeroconf@merit.edu Sat Feb 22 19:24:38 2003 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 TAA18126 for ; Sat, 22 Feb 2003 19:24:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ECB989122B; Sat, 22 Feb 2003 19:28:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B27059122C; Sat, 22 Feb 2003 19:28:21 -0500 (EST) 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 83B709122B for ; Sat, 22 Feb 2003 19:28:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 64D015DFCC; Sat, 22 Feb 2003 19:28:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by segue.merit.edu (Postfix) with ESMTP id 2214D5DFBD for ; Sat, 22 Feb 2003 19:28:20 -0500 (EST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Sat, 22 Feb 2003 16:28:19 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 22 Feb 2003 16:28:19 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Sat, 22 Feb 2003 16:28:19 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 22 Feb 2003 16:28:19 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Sat, 22 Feb 2003 16:28:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: LL1, LL23 Date: Sat, 22 Feb 2003 16:28:15 -0800 Message-ID: Thread-Topic: LL1, LL23 thread-index: AcLasQMzieJuDAT7RZqWhMGEZXaFBgAHQgr9 From: "Christian Huitema" To: X-OriginalArrivalTime: 23 Feb 2003 00:28:18.0766 (UTC) FILETIME=[769B1EE0:01C2DAD2] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA18126 Erik asked for some concrete references about "what breaks when applications inadvertently stumble on site local addresses". There are at least two simple examples: application running on multi-homed hosts, and applications passing addresses to other hosts. Suppose a multi-homed host with two interfaces, e.g. an Ethernet to the regular network of the organization, and a Blue Tooth link for ad hoc connectivity. When the application issues a "connect" or a "send to", the stack tries to route the packet to the "right interface". If the same subnet (169.254/16) is reachable through two interfaces, the stack is likely to pick a default interface, which leads to failures if the target is actually connected to the other link. By reducing as much as possible the usage of link local addresses, one can reduce this failure mode. In particular, in this example, things will work much better if LL addresses are only configured on the "ad hoc" link. Consider now a host using an address passing application, such as for example VoIP using SIP. The host has just one interface. When the application wants to set up a VoIP call, it reads the IP address of the interface, and document it in the SDP payload of a SIP message; the peer will then send RTP packets to that address. If the interface has several addresses, the host needs to pick one; if the application is not LL aware and the interface has both an LL address and a routable address, the application is likely to pick at random. The SIP packet will often travel beyond the local link; if the application placed the LL address in the RTP payload, the VoIP call will fail. This failure will not happen if the host did not configure an LL address. The natural consequence of these arguments is that hosts should not be required to configure LL addresses if they have a global address; this is the rationalefor rejecting LL19. LL1 or LL23 are somewhat stronger: instead of not forcing LL addresses on unwilling hosts, it forces even willing hosts to not configure LL addresses if they have a routable address. For that, we need a stronger motivation than just the host convenience; after all, if all applications were fully LL aware, they would choose the routable address when available, or they would specify the outgoing interface when using LL addresses; a host that only support LL aware applications could choose to keep the LL addresses around, even if we don't believe that this is a good idea. The review of site local addresses in the IPv6 working group outlined another class of concern, address leakage; this was based on our experience with RFC 1918. Despite the statements in RFC 1918, we observe that non-global addresses actually leak on the global Internet. For example, the DNS root regularly recieves requests for the PTR record of RFC 1918 addresses; sites receive connection requests sourced with RFC 1918 addresses; Dynamic DNS updates sometimes result in RFC 1918 addresses appearing in DNS records, etc. Obviously, all of this results from bugs, and we could decree that software should not have bugs, but you will probably agree that this is unrealistic. Since leakage hurts the rest of the Internet, the robustness principle dictates that we limit the risk of LL addresses leaking. This is achieved, by and large, by reserving such addresses to ad hoc networks, and by not using them on connected networks. Which translate in a requirement to select either LL1 or LL23. There seems to be a preference for the text of LL23, with some revisions. -- Christian Huitema From owner-zeroconf@merit.edu Sun Feb 23 00:21:56 2003 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 AAA21808 for ; Sun, 23 Feb 2003 00:21:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BE072912E2; Sun, 23 Feb 2003 00:25:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D6A9912E4; Sun, 23 Feb 2003 00:25:36 -0500 (EST) 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 570E6912E2 for ; Sun, 23 Feb 2003 00:25:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 302225DFE0; Sun, 23 Feb 2003 00:25:35 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by segue.merit.edu (Postfix) with ESMTP id 0E2755DD8D for ; Sun, 23 Feb 2003 00:25:35 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18modl-00029C-00; Sat, 22 Feb 2003 21:25:29 -0800 Date: Sun, 23 Feb 2003 00:22:42 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030223002242.44a3c251.moore@cs.utk.edu> In-Reply-To: <1045955078.27185.329.camel@devil> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934019.27185.157.camel@devil> <20030222124023.63bc31d8.moore@cs.utk.edu> <1045938480.27185.232.camel@devil> <20030222143305.17390c4b.moore@cs.utk.edu> <1045944748.27185.264.camel@devil> <20030222162605.506279bf.moore@cs.utk.edu> <1045951573.27180.299.camel@devil> <20030222171824.3c6604ad.moore@cs.utk.edu> <1045955078.27185.329.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > most of them are obscure to me, too. but netsolve, PVM, and SIP certainly > > qualify. others worth looking at are MPI implementations, various distributed > > games, distributed simulations, conferencing software. > > Ok, these are apps that might have problems with scoped addresses, at > least. SIP and H.323 are probably the most likely candidates. Don't know > too much about MPI implementations but the rest don't look like referral > apps. you don't know what you're talking about. > Multiplayer games typically just use centralized servers. some, not all. > LL will probably just benefit LAN gaming. consider a game on a LAN with a mixture of LL and routable addresses. now add one or more hosts from another link and see what happens. > Anyone know one of these well enough to give a concrete example > supporting LL1 or LL23? I don't want to impose on Keith too much, since > he is pressed for time. > > (Netsolve we already did; didn't seem to be a problem. ) netsolve does have problems with scoped addresses. > > the current draft does it in such a way as to *cause* problems. > > the apps aren't broken. scoped addresses are broken. > > that's just because you don't want to see it. > > You don't give up, do you? nor you. but apparently you don't mind telling outright lies. Keith From owner-zeroconf@merit.edu Sun Feb 23 02:31:47 2003 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 CAA03685 for ; Sun, 23 Feb 2003 02:31:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D174E912E5; Sun, 23 Feb 2003 02:35:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0D80912E6; Sun, 23 Feb 2003 02:35:31 -0500 (EST) 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 49FE9912E5 for ; Sun, 23 Feb 2003 02:35:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2FB4D5DF25; Sun, 23 Feb 2003 02:35:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id EFA9B5DEDB for ; Sun, 23 Feb 2003 02:35:28 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1N7aAaj000380; Sun, 23 Feb 2003 09:36:10 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1N7a8BS000379; Sun, 23 Feb 2003 09:36:08 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: LL1, LL23 From: Mika Liljeberg To: Christian Huitema Cc: zeroconf@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045985767.30660.103.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Feb 2003 09:36:08 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks Christian, I found this more useful than anything that's been said so far. On Sun, 2003-02-23 at 02:28, Christian Huitema wrote: > Suppose a multi-homed host with two interfaces, e.g. an Ethernet to > the regular network of the organization, and a Blue Tooth link for ad > hoc connectivity. When the application issues a "connect" or a "send > to", the stack tries to route the packet to the "right interface". If > the same subnet (169.254/16) is reachable through two interfaces, the > stack is likely to pick a default interface, which leads to failures > if the target is actually connected to the other link. This is a very good point. Our implementation can handle the ambiguity if the application uses the IPv6 socket API with IPv4-mapped addresses and qualifies them with a scope identifier. However, it is clear that pure IPv4 applications would have a problem. > By reducing as much as possible the usage of link local addresses, one > can reduce this failure mode. Just reducing the usage of LLs is not an adequate solution. What you suggest below would be: > In particular, in this example, things will work much better if LL > addresses are only configured on the "ad hoc" link. It seems clear that, in a multihomed host, the use of LLs should generally be limited to a single interface. This is a pretty awkward limitation of LLs. I can see where the choice of interface might depend on the current connectivity situation and how this might lead to people clamoring for LL23. However: how the LL interface is chosen should be left up to the OS vendor or device manufacturer, since the right thing to do may depend on the device. I think normative language will do more harm than good here. The vendors should be warned about the problem but allowed to do their own thing. It's clear to me now that the specification should have some text describing what should happen, when the LL address needs to be configured/unconfigured. However, I'm firmly opposed to the idea that the specification should mandate *when* to do that. If LL23 were reformulated in those terms I would be willing to accept it. > Consider now a host using an address passing application, such as for > example VoIP using SIP. The host has just one interface. When the > application wants to set up a VoIP call, it reads the IP address of > the interface, and document it in the SDP payload of a SIP message; > the peer will then send RTP packets to that address. If the interface > has several addresses, the host needs to pick one; if the application > is not LL aware and the interface has both an LL address and a > routable address, the application is likely to pick at random. The SIP > packet will often travel beyond the local link; if the application > placed the LL address in the RTP payload, the VoIP call will fail. > This failure will not happen if the host did not configure an LL > address. Judging by this, SIP telephony is also likely break in any multihomed configuration where one of the interfaces is on an isolated network or where RFC1918 addresses are being used. In order to make things work in that context, the application has to be able to answer the question: "What is a good source address for this destination address?". There are several possible ways to deal with this (in the context of LLs) in an implementation without requiring LL1/LL23: a) Ted made a good suggestion: the SIOCGIFCONF ioctl (or equivalent) should return LL addresses only if explicitly requested by the application. This would make certain that only applications that know how to handle LLs would get them as result. b) Keith suggested that some applications try to pick an address from the interface, where the default route points to. If the LL address and the 169.254/16 on-link prefix are configured on a separate virtual interface, this technique will keep on working (also for SIP). c) An explicit "What is a good source address for this destination address?" syscall can be added to the OS to solve this. [Actually, a simple UDP connect(dst)+getsockname() might work on many operating systems]. This, of course, only helps those applications smart enough to do it. None of the above measures require LL1 or LL23. > The natural consequence of these arguments is that hosts should not be > required to configure LL addresses if they have a global address; this > is the rationalefor rejecting LL19. Ok. I see this would be desirable for multihomed hosts. For single homed hosts there's no problem having both LL and routable addresses on the same interface provided that other measures, such as a) - c) suggested above, are implemented. The OS vendor should have the freedom to make their own implementation choices. In fact, the address leakage concerns you outline below make me think that we should seriously reconsider LL19. Slight loss of functionality in multihomed configurations seems like a small price to pay for curtailing the address leakage problems. > LL1 or LL23 are somewhat stronger: instead of not forcing LL > addresses on unwilling hosts, it forces even willing hosts to not > configure LL addresses if they have a routable address. For that, we > need a stronger motivation than just the host convenience; Agreed, stronger justificaton is needed. > after all, if all applications were fully LL aware, they would choose > the routable address when available, or they would specify the > outgoing interface when using LL addresses; a host that only support > LL aware applications could choose to keep the LL addresses around, > even if we don't believe that this is a good idea. There are cases where this would clearly be possible, such types of restricted devices where the set of applications is known. The implementation techniques I outlined above also work well with a more random set of applications. > The review of site local addresses in the IPv6 working group outlined > another class of concern, address leakage; this was based on our > experience with RFC 1918. Despite the statements in RFC 1918, we > observe that non-global addresses actually leak on the global > Internet. For example, the DNS root regularly recieves requests for > the PTR record of RFC 1918 addresses; sites receive connection > requests sourced with RFC 1918 addresses; Dynamic DNS updates > sometimes result in RFC 1918 addresses appearing in DNS records, etc. > Obviously, all of this results from bugs, and we could decree that > software should not have bugs, but you will probably agree that this > is unrealistic. Software SHOULD not have bugs. :) But yes, this is clearly an issue. > Since leakage hurts the rest of the Internet, the robustness principle > dictates that we limit the risk of LL addresses leaking. This is > achieved, by and large, by reserving such addresses to ad hoc > networks, and by not using them on connected networks. Ultimately this boils down to how serious the leakage problem is seen to be and choosing a remedy of equal strength. It seems extremely strange to me that address leakage did not seem to be any kind of a problem when we were considering LL19. Accepting LL19 would have done a great deal to limit address leakage, by limiting the use of LL addresses only to hosts that are *compliant*. In this light, rejecting LL19 seems like a pretty huge mistake. As a purely hypothetical example, suppose the company I work for (Nokia) starts deploying a hundred million v4LL capable devices on a yearly basis. Do you think hacks like LL1 or LL23 will be sufficient? MikaL From owner-zeroconf@merit.edu Sun Feb 23 03:45:46 2003 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 DAA04245 for ; Sun, 23 Feb 2003 03:45:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DE8029123B; Sun, 23 Feb 2003 03:49:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC04D912E6; Sun, 23 Feb 2003 03:49:28 -0500 (EST) 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 3BD359123B for ; Sun, 23 Feb 2003 03:48:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1708D5E008; Sun, 23 Feb 2003 03:48:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 5FC805DE19 for ; Sun, 23 Feb 2003 03:48:45 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1N8nQaj000619; Sun, 23 Feb 2003 10:49:26 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1N8nP1g000616; Sun, 23 Feb 2003 10:49:25 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Philip Nye Cc: Zeroconf Working Group In-Reply-To: <005d01c2dacb$2295e3e0$131010ac@aldebaran> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934019.27185.157.camel@devil> <20030222124023.63bc31d8.moore@cs.utk.edu> <1045938480.27185.232.camel@devil> <20030222143305.17390c4b.moore@cs.utk.edu> <1045944748.27185.264.camel@devil> <005d01c2dacb$2295e3e0$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045990164.30660.123.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Feb 2003 10:49:24 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-02-23 at 01:35, Philip Nye wrote: > > From: "Mika Liljeberg" > > I agree that configurations with LL-only nodes will fail. This is not > > relevant to the LL1/LL23 discussion. > > It is highly relevant because the issue of allowing LL only nodes has not > yet been discussed and may go either way so far as I can tell. Looks like we have a different definition of LL-only. I mean a node that doesn't have a routable address at the moment, while you seem to mean a node that cannot have a routable address at all. Correct? > If LL1 and > LL23 are rejected and then LL-only nodes are allowed then we are really in > trouble. This claim is familiar. Please explain what you mean by "really in trouble" and back it up with a concrete example. > As it is LL-only nodes will exist anyway - because of configuration issues > and because of transition issues (and because there is sufficient commercial > pressure that they will be built whether or not this standard blesses them). > > Why define a standard which falls over in their presence when with a little > more effort it can be a lot more robust? Generalities and exaggeration again. Christian's address leakage argument is the most compelling general argument I've seen so far. However, the WG has already dismissed that concern by dismissing LL19. > Why define a standard which relies heavily on things like LLMNS (itself not > a standard ) when with a little more effort it can be far more generic? I don't see anything that relies on LLMNR. The discussion you're probably referring to concerned name resolver API behaviour on compliant nodes. > I can only conclude that you don't want to put in that effort. You're not being entirely fair, there. I'm putting a good deal of effort into reaching a design I feel would be simple and clean. Implementation complexity is nearly always a sign of shoddy design. > LL23/LL1 are not over complex LL23 is extremely difficult to implement in a manner that provides a satisfactory user experience. LL1 would be simple enough, even though it creates an alternate exceptional code path for source address selection, and I could probably live with it if that made the WG happy. > and the principle behind them provides the > best (though imperfect) interoperability in the widest range of situations. Only extensive deployment experience can give grounds to such a claim. What experience is the claim based on? MikaL From owner-zeroconf@merit.edu Sun Feb 23 03:52:57 2003 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 DAA04359 for ; Sun, 23 Feb 2003 03:52:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3E56F91208; Sun, 23 Feb 2003 03:56:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08253912E6; Sun, 23 Feb 2003 03:56:41 -0500 (EST) 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 C360D91208 for ; Sun, 23 Feb 2003 03:56:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id AB5E75DE19; Sun, 23 Feb 2003 03:56:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id CA00B5E013 for ; Sun, 23 Feb 2003 03:56:39 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1N8vFaj000654; Sun, 23 Feb 2003 10:57:15 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1N8vCeg000653; Sun, 23 Feb 2003 10:57:12 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Keith Moore Cc: Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com In-Reply-To: <20030223002242.44a3c251.moore@cs.utk.edu> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934019.27185.157.camel@devil> <20030222124023.63bc31d8.moore@cs.utk.edu> <1045938480.27185.232.camel@devil> <20030222143305.17390c4b.moore@cs.utk.edu> <1045944748.27185.264.camel@devil> <20030222162605.506279bf.moore@cs.utk.edu> <1045951573.27180.299.camel@devil> <20030222171824.3c6604ad.moore@cs.utk.edu> <1045955078.27185.329.camel@devil> <20030223002242.44a3c251.moore@cs.utk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045990631.30660.133.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Feb 2003 10:57:12 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Keith, That's certainly a civil way to end a discussion. I would have liked to discuss the applications one by one, but it looks like further argument with you would not be very productive. MikaL On Sun, 2003-02-23 at 07:22, Keith Moore wrote: > > > most of them are obscure to me, too. but netsolve, PVM, and SIP certainly > > > qualify. others worth looking at are MPI implementations, various distributed > > > games, distributed simulations, conferencing software. > > > > Ok, these are apps that might have problems with scoped addresses, at > > least. SIP and H.323 are probably the most likely candidates. Don't know > > too much about MPI implementations but the rest don't look like referral > > apps. > > you don't know what you're talking about. > > > Multiplayer games typically just use centralized servers. > > some, not all. > > > LL will probably just benefit LAN gaming. > > consider a game on a LAN with a mixture of LL and routable addresses. > now add one or more hosts from another link and see what happens. > > > Anyone know one of these well enough to give a concrete example > > supporting LL1 or LL23? I don't want to impose on Keith too much, since > > he is pressed for time. > > > > (Netsolve we already did; didn't seem to be a problem. ) > > netsolve does have problems with scoped addresses. > > > > the current draft does it in such a way as to *cause* problems. > > > the apps aren't broken. scoped addresses are broken. > > > that's just because you don't want to see it. > > > > You don't give up, do you? > > nor you. but apparently you don't mind telling outright lies. > > Keith From owner-zeroconf@merit.edu Sun Feb 23 04:25:55 2003 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 EAA04790 for ; Sun, 23 Feb 2003 04:25:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 01ADD9120F; Sun, 23 Feb 2003 04:29:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B731C912E6; Sun, 23 Feb 2003 04:29:38 -0500 (EST) 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 A4E739120F for ; Sun, 23 Feb 2003 04:29:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 83AB65E027; Sun, 23 Feb 2003 04:29:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id B29FE5DEB8 for ; Sun, 23 Feb 2003 04:29:25 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1N9S3d21548; Sun, 23 Feb 2003 16:28:03 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1N9Rmo11266; Sun, 23 Feb 2003 16:27:54 +0700 (ICT) From: Robert Elz To: Ted Lemon Cc: zeroconf@merit.edu, Bernard Aboba Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL [LL2,LL1,LL23] In-Reply-To: <99984944-45BF-11D7-A12D-00039317663C@nominum.com> References: <99984944-45BF-11D7-A12D-00039317663C@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Feb 2003 16:27:48 +0700 Message-ID: <11264.1045992468@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 21 Feb 2003 10:12:04 -0700 From: Ted Lemon Message-ID: <99984944-45BF-11D7-A12D-00039317663C@nominum.com> | This is one of the reasons why I reject LL1 and LL23 - without these | two changes, the IPv4ll failure mode you're talking about isn't | possible, whether through happenstance or a deliberate attempt to deny | service. For sure, if both LL1 and LL23 are rejected, then LL2 would no longer make any sense. But if they're not, then there's no extra security issue that relates to LL2. The conflict on all of these seems to revolve around how LL addresses are conceived as being useful. Some of us see them as a "fall back" - an address that is available and can be used in situations where there are no other possible addresses, that is, where there is no-one doing any network config Others seem to see LL addressing as solving some other problem, allowing access to nodes which have been mis-configured, and all kinds of other exotic possibilities like that. To me, the former fits within the charter, and the latter does not. The goal of the Zero Configuration Networking (ZEROCONF) Working Group is to enable networking in the absence of configuration and administration. Nothing about correcting node misconfiguration. | As with any proposal, we have to weigh the pros and cons. Of course. | The con here is that if | the client always follows this kind of advice, it will be easy to gull | the client into not using the network in situations where the client in | fact has every right to use the network. This is just like using DHCP - if a node is to take advice from the administrator, it is always possible for someone to pretend to be that admin, and give inappropriate device. Anywhere we want administrative control we have that problem - in zeroconf where by definition we cannot configure, and hence cannot indicate who is an appropriate administrator, it is necessarily worse. The question is do we sacrifice all possibility of any administrative control, in order to remove one possible way of denying access. If it was the only way, the argument would be stronger, but it clearly isn't. Someone who wants to deny hosts access to LL addresses can easily do so using ARP. So, your argument is that a tool should be removed from legitimate admins in order to force interlopers to use a different method? That doesn't sound very persuasive to me. [Aside: I have just started running arpd on a NetBSD host with two LAN interfaces. the arpd.conf file says if ex0 arpnet 169.254.0.0 arpmask 255.255.0.0 if fxp0 arpnet 169.254.0.0 arpmask 255.255.0.0 It seems to work just fine... - but is an incredibly crude way of doing what would be much nicer accomplished via the DHCP server.] | To me, the drawbacks of this approach strongly outweigh the benefits. I see zero significant drawbacks. That is, the DoS attack using this (which only works on nets without a legitimate DHCP server anyway - which mostly means on ad-hoc nets - which are generally the kind of net created by a few friends who meet at some remote location) is easily possible other ways. The benefits may not be very large for many sites, but they easily outweigh this non-disadvantage. The right way to handle this, IMO, is to include LL2 (& LL23) in the spec, and then see what happens. When we are ready to go to DS, then if no-one has bothered to implement the LL2 method, it can (and what is more, must) be removed from the spec. Similarly, if at that point you can argue that having been implemented, it is being used for DoS attacks, or simply isn't being used by anyone at all, then it could also be removed. But for sure, if it isn't included now, it won't be implemented, and there would be no reasonable way to ever include it later. Yes for LL2. Yes for LL23. (and LL1 becomes irrelevant). kre From owner-zeroconf@merit.edu Sun Feb 23 05:15:51 2003 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 FAA05289 for ; Sun, 23 Feb 2003 05:15:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1F4DE912E7; Sun, 23 Feb 2003 05:19:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C45AD912E9; Sun, 23 Feb 2003 05:19:32 -0500 (EST) 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 86039912E7 for ; Sun, 23 Feb 2003 05:19:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 64DFE5DEBA; Sun, 23 Feb 2003 05:19:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id DD6D35DE84 for ; Sun, 23 Feb 2003 05:19:23 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA02566 for ; Sun, 23 Feb 2003 02:19:22 -0800 (PST) Received: from sun.com (vpn-129-159-0-71.EMEA.Sun.COM [129.159.0.71]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1NAJJl27593 for ; Sun, 23 Feb 2003 11:19:19 +0100 (MET) Message-ID: <3E589FD9.7030904@sun.com> Date: Sun, 23 Feb 2003 11:18:01 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Re: LL1, LL23 References: <1045776694.14935.56.camel@devil> <8B083511-4524-11D7-A12D-00039317663C@nominum.com> <20030220174934.10b52b2e.moore@cs.utk.edu> <1045810765.14935.486.camel@devil> <20030221060227.7bc6339e.moore@cs.utk.edu> <1045848196.22035.8.camel@devil> <20030222004914.43555809.moore@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: >>>I disagree with your assessment of what is "compelling" or "common". >>>Users are seriously inconvenienced if the Internet is made less capable >>>of supporting applications that don't exist yet, >> >>That is a fine abstract argument against scoped addressing in general >>but it is of no help whatsoever when trying to decide whether proposals >>like LL1 and LL23 are technically sound. > > no, you have it backwards. you can't decide whether something is technically > sound based on concrete examples. concerete examples might demonstrate that > it is unsound, but they cannot demonstrate soundness. > > what you seem to want to do is feel free to dismiss any example that you > personally find insignificant. I disagree that you or anyone in this WG has > the right to determine that certain applications are insignificant enough to be > broken by linklocal. The working hypothesis is: It is possible for hosts with link-local configuration to communicate with those with non-link-local configuration and for them to successfully use existing IETF standard protocols. Keith is right that examples cannot be used to prove this hypothesis (or any other *general assertion.*) However, we need concrete counter examples which either disprove it or show its limitations. Abstract arguments against this hypothesis have not conclusively or convincingly moved our discussion forward. Unless we can conclude or get convinced that there are real concrete problems with the above hypothesis, we will not ammend it further than has already been done in the applicability statement and app consider- ations sections. Erik From owner-zeroconf@merit.edu Sun Feb 23 05:16:18 2003 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 FAA05305 for ; Sun, 23 Feb 2003 05:16:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D2BF5912E6; Sun, 23 Feb 2003 05:20:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A213E912E8; Sun, 23 Feb 2003 05:20:01 -0500 (EST) 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 9C80D912E6 for ; Sun, 23 Feb 2003 05:20:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 86B1B5DEBA; Sun, 23 Feb 2003 05:20:00 -0500 (EST) 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 07E3C5DE84 for ; Sun, 23 Feb 2003 05:20:00 -0500 (EST) 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 CAA29842; Sun, 23 Feb 2003 02:19:54 -0800 (PST) Received: from sun.com (vpn-129-159-0-71.EMEA.Sun.COM [129.159.0.71]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1NAJnl27608; Sun, 23 Feb 2003 11:19:49 +0100 (MET) Message-ID: <3E589FF7.4000100@sun.com> Date: Sun, 23 Feb 2003 11:18:31 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Keith Moore Cc: Mika Liljeberg , Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934640.27180.162.camel@devil> <20030222124230.3cd9a83b.moore@cs.utk.edu> <1045936283.27185.165.camel@devil> <20030222125141.6f6171a2.moore@cs.utk.edu> <1045938523.27180.234.camel@devil> <20030222143537.6bd7c13f.moore@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, you have to admit that I'm trying very hard to understand your >>point of view. >> >>Are we going to be left without any concrete examples to support your >>view? > > > I would like to supply such examples. But I doubt I'll have time to > investigate and write them up in detail within the next several days. It is in no way unfair to say that this process must come to an end - soon - and that we have all had months to gather evidence for our arguments and innumerable calls for concrete examples of applications which fail due to link-local. After we conclude our last call, further arguments may of course be submitted directly to the IESG for their consideration. Our goal is to settle on a revisions and give the IESG a revised draft ASAP. We must achieve at least rough consensus to conclude our WG last call with a recommendation, however. >> That's still an OS specific problem. We don't put vendor specific bug >> workarounds into IETF specifications. > > disagree. installed base compatibility is often a design issue > in IETF specs. I agree with Keith here. If we break the installed base, this is a bad, potentially unacceptable thing. How *precisely* do we break the installed base? > most of them are obscure to me, too. but netsolve, PVM, and SIP > certainly qualify. others worth looking at are MPI implementations, > various distributed games, distributed simulations, conferencing > software. SIP has increasing mechanisms for working around NAT that allow SIP to function over address scope boundaries. Netsolve has been discussed and the problems raised have not yet been made clear or convinced the list. What is PVM and MPI? What are the specific issues which would make use need to accept LL1 or LL23? Erik From owner-zeroconf@merit.edu Sun Feb 23 05:19:30 2003 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 FAA05421 for ; Sun, 23 Feb 2003 05:19:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7D59E912E8; Sun, 23 Feb 2003 05:23:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46A56912E9; Sun, 23 Feb 2003 05:23:14 -0500 (EST) 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 4922F912E8 for ; Sun, 23 Feb 2003 05:23:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 265425E03C; Sun, 23 Feb 2003 05:23:13 -0500 (EST) 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 CB5275E035 for ; Sun, 23 Feb 2003 05:23:12 -0500 (EST) 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 DAA08411; Sun, 23 Feb 2003 03:23:11 -0700 (MST) Received: from sun.com (vpn-129-159-0-71.EMEA.Sun.COM [129.159.0.71]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1NAN6l27744; Sun, 23 Feb 2003 11:23:07 +0100 (MET) Message-ID: <3E58A0BD.8080307@sun.com> Date: Sun, 23 Feb 2003 11:21:49 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Philip Nye Cc: Zeroconf Working Group Subject: Re: LL1, LL23 References: <6C98F925-46A5-11D7-A12D-00039317663C@nominum.com> <001801c2dab8$49f8b970$131010ac@aldebaran> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Philip Nye wrote: >>From: "Ted Lemon" >> >>>So generic applications (like ftp) cannot use the LL network? Only apps >>>which use LLMNS and NEVER refer to a peer other than by its LLMNS >>>name? This >>>seems particularly broken to me. >> >>All apps use both LLMNS and DNS, according to the rules of those >>protocols. If you don't use LLMNS or some other link-local node >>discovery protocol, you can't use IPv4ll addresses anyway. The >>transparency of IPv4ll depends specifically on LLMNS in most cases, >>like it or not. > > > I don't buy this at all. If the IP world was a cozy place where apps dealt > only with names and relied on a narrow DNS/LLMNS system to work out the > details then what you propose might work. However this is only a small part > of the IP world. Concrete examples, please? > There are many applications in the embedded world where LL is very > attractive, but for which LLMNS (or DNS) is a complete irrelevance. Things > like SLP and a host of specialist small scale discovery protocols are much > more relevant. > > Don't get me wrong - I am as concerned about the case of transition from > configured to LL as you are - as my previous posts show. I just don't see > that running LL concurrently really helps unless you sacrifice a lot of > applications. If there is a way to tell when it is safe to switch over, then > that applies in all cases and I would like to explore that. > > >>>There is a misconception here that the only way applications get IP >>>addresses is via DNS and its derivatives. This is complete tosh - >>>there are >>>lots of ways that applications get hold of addresses - and whole >>>networks >>>without named hosts. The very idea of having to give a host a name is >>>by >>>definition not zero-config! If you send a packet to me using your LL >>>address >>>than I have that address and you have already lost control of where it >>>gets >>>to. >> >>Sure, you can use any sort of resource-discovery protocol, as long as >>it works. Or you can just type in IP addresses. What's your point? > > > My point is that unless you make each and every one of these myraiad ways > that apps discover each other LL aware, and secure against mis-scoping, then > you can't be sure that LL addresses will be confined to scope. If all those > ways NEVER reveal a LL address when a configured one is present then it is > true that those addresses will not leak out of scope - but a whole lot of > applications will not be able to communicate using LL either. [WG chair hat off] If a host already is able to use service discovery protocols and naming services to obtain a peer's location, what more do we have to do? My concern is that most apps today get the address of a peer, or even for their own interface, and cache it. Worse, they may forward this information to others. This happens for example in http referrals and redirects Here we are pointing at content or service elsewhere in static documents. SLP service advertisements from a DA, entries in an LDAP server Here we are pointing at services elsewhere which may not be available in the future at the same address. This is different from them not being available *ever* since the advertisement is only good in one scope but is obtainable in another. See RFC 3111 on SLPv2 for IPv6. pop3 and imap client configuration This is the 'heart of the matter'. Today clients take hard coded parameters for their servers. We assume that this server will continue to remain available, otherwise we have a problem. Generally we give a name for the server, which gets resolved before use of the client-server protocol. Service discovery could be used instead, but in practice seldom is. The problem is that the client-server binding is made once and for all. If the client moves (reboots, ip mobility, whatever) and the *service* has only a link-local address, the client loses the ability to contact the server. Question: Is the real problem when a *service* uses a LL address? Services are the only application entities which offer a L3 access point which might get moved or used outside of the scope in which it is valid. Could we solve this by stating in the applicability statement that application software services which register themselves with dynamic discovery protocols should be aware of the scope which they perform these advertisements? This does *not* break existing standards or implementations, since today, very few apps use these facilities. As indicated above, the way I attempted to address this so far (RFC 3111) was *within the service discovery standard* so the app does not need to care about its address scope. The service discovery or address registration protocol can limit the propogation of an advertisement to the scope it is valid in without the application needing to be changed in any way. This could be an additional requirement for dynamic update of DNS and LLMNR. Alternatively: This could be a requirement we have on application services which use link-local configuration. But isn't this a bad alternative? Erik From owner-zeroconf@merit.edu Sun Feb 23 05:37:06 2003 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 FAA05753 for ; Sun, 23 Feb 2003 05:37:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 67FCD912E9; Sun, 23 Feb 2003 05:40:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 35581912EA; Sun, 23 Feb 2003 05:40:50 -0500 (EST) 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 1B68C912E9 for ; Sun, 23 Feb 2003 05:40:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id EEFBF5DEBA; Sun, 23 Feb 2003 05:40:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id DB3DC5DE5E for ; Sun, 23 Feb 2003 05:40:47 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1NAfLaj001136; Sun, 23 Feb 2003 12:41:22 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1NAfJAM001133; Sun, 23 Feb 2003 12:41:19 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Erik Guttman Cc: Keith Moore , Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com In-Reply-To: <3E589FF7.4000100@sun.com> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934640.27180.162.camel@devil> <20030222124230.3cd9a83b.moore@cs.utk.edu> <1045936283.27185.165.camel@devil> <20030222125141.6f6171a2.moore@cs.utk.edu> <1045938523.27180.234.camel@devil> <20030222143537.6bd7c13f.moore@cs.utk.edu> <3E589FF7.4000100@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045996878.30655.143.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Feb 2003 12:41:19 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-02-23 at 12:18, Erik Guttman wrote: > >> That's still an OS specific problem. We don't put vendor specific bug > >> workarounds into IETF specifications. > > > > disagree. installed base compatibility is often a design issue > > in IETF specs. > > I agree with Keith here. If we break the installed base, this is a > bad, potentially unacceptable thing. How *precisely* do we break > the installed base? The specific issue that was being discussed here was MacOS returning an invalid hostname, apparently in conjunction with the use of a link local addressing or name resolution. As such, I don't think it qualifies as an example of installed base. It only qualifies to point out the immaturity of said implementation (which is understandable as the specifications are not ready either). I also agree that breaking the installed base is a very bad idea if there is a clear understanding that such breakage is likely to take place. MikaL From owner-zeroconf@merit.edu Sun Feb 23 05:43:00 2003 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 FAA05947 for ; Sun, 23 Feb 2003 05:42:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 799FE912EA; Sun, 23 Feb 2003 05:46:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38AC3912EB; Sun, 23 Feb 2003 05:46:42 -0500 (EST) 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 6F18D912EA for ; Sun, 23 Feb 2003 05:46:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4EBAC5DE5E; Sun, 23 Feb 2003 05:46:38 -0500 (EST) 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 A53B85DEBA for ; Sun, 23 Feb 2003 05:46:30 -0500 (EST) 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 DAA29966; Sun, 23 Feb 2003 03:46:29 -0700 (MST) Received: from sun.com (vpn-129-159-0-71.EMEA.Sun.COM [129.159.0.71]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1NAkPl28580; Sun, 23 Feb 2003 11:46:25 +0100 (MET) Message-ID: <3E58A633.5090500@sun.com> Date: Sun, 23 Feb 2003 11:45:07 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Christian Huitema Cc: zeroconf@merit.edu Subject: Re: LL1, LL23 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Christian, [WG chair hat off] Thank you for your excellent post. (If only we had listened to your warnings back in Pittsburgh!) Christian Huitema wrote: > Erik asked for some concrete references about "what breaks when > applications inadvertently stumble on site local addresses". > There are at least two simple examples: application running on > multi-homed hosts, and applications passing addresses to other hosts. > > Suppose a multi-homed host with two interfaces, e.g. an Ethernet to > the regular network of the organization, and a Blue Tooth link for > ad hoc connectivity. When the application issues a "connect" or a > "send to", the stack tries to route the packet to the "right > interface". If the same subnet (169.254/16) is reachable through > two interfaces, the stack is likely to pick a default interface, > which leads to failures if the target is actually connected to > the other link. By reducing as much as possible the usage of > link local addresses, one can reduce this failure mode. > In particular, in this example, things will work much better if LL > addresses are only configured on the "ad hoc" link. B (169.254.33.22) | A Telnet 169.254.33.22 ??? | C (169.254.33.22) This is an excellent example of a problem. How in particular is section 3 insufficient? Should we open a new issue to limit the applicability of the protocol to a single link at the same time? > Consider now a host using an address passing application, such > as for example VoIP using SIP. The host has just one interface. > When the application wants to set up a VoIP call, it reads the > IP address of the interface, and document it in the SDP payload > of a SIP message; the peer will then send RTP packets to that > address. If the interface has several addresses, the host needs > to pick one; if the application is not LL aware and the > interface has both an LL address and a routable address, > the application is likely to pick at random. The SIP packet > will often travel beyond the local link; if the application > placed the LL address in the RTP payload, the VoIP call > will fail. This failure will not happen if the host did not > configure an LL address. I think this is an excellent justification for a host preferring to use a non-link-local scope address over a link-local scope address if it has both. One issue I have with the example you gave is that either the host has a link-local address and is using a proxy on the local link or the host has a global address and can use whatever. If the host is using a proxy, doesn't SIP increasingly support operation over address space boundaries? I know experts I can refer to about this. This is a specific case of a well known application being pushed into support of ALGs, right? But once - we have an ALG and - those with enough clue to install a proxy at all will also know how to configure them to traverse address space boundaries don't a lot of the arguments against specific protocols breaking due to address scoping lose their force? > The natural consequence of these arguments is that hosts should > not be required to configure LL addresses if they have a global > address; this is the rationale for rejecting LL19. LL1 or LL23 are > somewhat stronger: instead of not forcing LL addresses on > unwilling hosts, it forces even willing hosts to not configure > LL addresses if they have a routable address. For that, we need > a stronger motivation than just the host convenience; after all, > if all applications were fully LL aware, they would choose the > routable address when available, or they would specify the > outgoing interface when using LL addresses; a host that only > support LL aware applications could choose to keep the LL > addresses around, even if we don't believe that this is a > good idea. > > The review of site local addresses in the IPv6 working group > outlined another class of concern, address leakage; this was > based on our experience with RFC 1918. Despite the statements > in RFC 1918, we observe that non-global addresses actually > leak on the global Internet. For example, the DNS root > regularly recieves requests for the PTR record of RFC > 1918 addresses; sites receive connection requests sourced > with RFC 1918 addresses; Dynamic DNS updates sometimes > result in RFC 1918 addresses appearing in DNS records, > etc. Obviously, all of this results from bugs, and we > could decree that software should not have bugs, but you > will probably agree that this is unrealistic. This is an excellent point. Thank you for pointing this out. > Since leakage hurts the rest of the Internet, the > robustness principle dictates that we limit the risk > of LL addresses leaking. This is achieved, by and large, > by reserving such addresses to ad hoc networks, and by > not using them on connected networks. Which translate > in a requirement to select either LL1 or LL23. There > seems to be a preference for the text of LL23, with > some revisions. What specific revisions do you support? Thanks sincerely, Erik From owner-zeroconf@merit.edu Sun Feb 23 05:46:26 2003 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 FAA05971 for ; Sun, 23 Feb 2003 05:46:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DF8CF912EB; Sun, 23 Feb 2003 05:50:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ACE92912EC; Sun, 23 Feb 2003 05:50:01 -0500 (EST) 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 BFA1D912EB for ; Sun, 23 Feb 2003 05:50:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9C3A05DEBA; Sun, 23 Feb 2003 05:50:00 -0500 (EST) 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 1E9E65DE5E for ; Sun, 23 Feb 2003 05:50:00 -0500 (EST) 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 CAA07038; Sun, 23 Feb 2003 02:49:55 -0800 (PST) Received: from sun.com (vpn-129-159-0-71.EMEA.Sun.COM [129.159.0.71]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1NAnol28654; Sun, 23 Feb 2003 11:49:50 +0100 (MET) Message-ID: <3E58A701.5060304@sun.com> Date: Sun, 23 Feb 2003 11:48:33 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Mika Liljeberg Cc: Keith Moore , Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934640.27180.162.camel@devil> <20030222124230.3cd9a83b.moore@cs.utk.edu> <1045936283.27185.165.camel@devil> <20030222125141.6f6171a2.moore@cs.utk.edu> <1045938523.27180.234.camel@devil> <20030222143537.6bd7c13f.moore@cs.utk.edu> <3E589FF7.4000100@sun.com> <1045996878.30655.143.camel@devil> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mika Liljeberg wrote: > On Sun, 2003-02-23 at 12:18, Erik Guttman wrote: > >> >> That's still an OS specific problem. We don't put vendor specific bug >> >> workarounds into IETF specifications. >> > >> > disagree. installed base compatibility is often a design issue >> > in IETF specs. >> >>I agree with Keith here. If we break the installed base, this is a >>bad, potentially unacceptable thing. How *precisely* do we break >>the installed base? > > > The specific issue that was being discussed here was MacOS returning an > invalid hostname, apparently in conjunction with the use of a link local > addressing or name resolution. As such, I don't think it qualifies as an > example of installed base. It only qualifies to point out the immaturity > of said implementation (which is understandable as the specifications > are not ready either). This is not an issue with link-local autoconfiguration which is being discussed here. The behavior you are referring to is that of Apple's Rendezvous product. Erik From owner-zeroconf@merit.edu Sun Feb 23 06:11:35 2003 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 GAA06225 for ; Sun, 23 Feb 2003 06:11:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 414B4912EC; Sun, 23 Feb 2003 06:15:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1DF5912EE; Sun, 23 Feb 2003 06:15:10 -0500 (EST) 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 A1018912EC for ; Sun, 23 Feb 2003 06:15:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E4495DEBA; Sun, 23 Feb 2003 06:15:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id A5AE75DDC5 for ; Sun, 23 Feb 2003 06:15:04 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1NBFcaj001260; Sun, 23 Feb 2003 13:15:39 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1NBFaHk001257; Sun, 23 Feb 2003 13:15:36 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Erik Guttman Cc: Keith Moore , Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com In-Reply-To: <3E58A701.5060304@sun.com> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934640.27180.162.camel@devil> <20030222124230.3cd9a83b.moore@cs.utk.edu> <1045936283.27185.165.camel@devil> <20030222125141.6f6171a2.moore@cs.utk.edu> <1045938523.27180.234.camel@devil> <20030222143537.6bd7c13f.moore@cs.utk.edu> <3E589FF7.4000100@sun.com> <1045996878.30655.143.camel@devil> <3E58A701.5060304@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1045998935.30655.157.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Feb 2003 13:15:36 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-02-23 at 12:48, Erik Guttman wrote: > This is not an issue with link-local autoconfiguration which is being > discussed here. The behavior you are referring to is that of Apple's > Rendezvous product. I understand that. I took the problem to be related to transitions between LL-configured/LL-unconfigured states and MacOS trying to be smart in what it returns as its own hostname. Be as it may, rendezvous is a variant of LLMNR (or perhaps the other way around), which is not yet an accepted IETF specification. Allowing the installed base based of a work-in-progress to sway specification of said or other Internet drafts does not seem like a smart thing to do. It seems likely that Apple will fix these problems as a matter of course. But I don't know enough about their product, so I won't say more than that. Perhaps Stuart can offer a view. MikaL From owner-zeroconf@merit.edu Sun Feb 23 06:37:24 2003 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 GAA06436 for ; Sun, 23 Feb 2003 06:37:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6807A912EE; Sun, 23 Feb 2003 06:41:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B7A9912EF; Sun, 23 Feb 2003 06:41:08 -0500 (EST) 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 4247E912EE for ; Sun, 23 Feb 2003 06:41:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 244965E090; Sun, 23 Feb 2003 06:41:07 -0500 (EST) 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 9C5B85E073 for ; Sun, 23 Feb 2003 06:41:06 -0500 (EST) 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 DAA22883; Sun, 23 Feb 2003 03:41:04 -0800 (PST) Received: from sun.com (vpn-129-159-0-71.EMEA.Sun.COM [129.159.0.71]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1NBf1l00471; Sun, 23 Feb 2003 12:41:01 +0100 (MET) Message-ID: <3E58B2FF.6040303@sun.com> Date: Sun, 23 Feb 2003 12:39:43 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Robert Elz Cc: zeroconf@merit.edu Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL References: <99984944-45BF-11D7-A12D-00039317663C@nominum.com> <11264.1045992468@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Robert, [WG chair hat off] What is your argument? It is necessary to enable network administrators to be able to force normal hosts (not attackers) to not autoconfigure on the LAN because ... An administrator can't do this today. Even though hosts have been doing autoconfiguring on LANs for the past 5 years, only one actual network administration was concerned enough to express this and give a concrete argument why this is necessary. (This was the university where Ryan Troll worked, before going to @Home and writing RFC 2563.) The argument was: We paid for the wires in the dorms. We want students to pay to use them. The students who had no problem paying for network resources at the university (they had to register their mac address in order to get a DHCP assigned address, and access to the university network). The students, however, had brought additional PCs and macs to play network games on LANs. Is this the concern you want to address with issue LL2? If not what do the 'network administrators' you refer to *want to do*? The counterarguments were: LAN based access requires nominal network resources. Further, there was a genuine concern that service providers in the late 90s would conclude that since they owned the gateway, they could determine the behavior of the network beyond it and make additional money. If customers pay per-address, why not require them to buy more addresses in order to run additional IP hosts? This option would remove the autonomy of affected LANs in homes and small offices. This would reduce the simplicity and reliability of LAN based workgroup (file sharing, print sharing, etc) networking, and consequently client vendors have had no interest in this 'feature.' Reduced simplicity is the result of changes in the way it works depending on where the feature is used. Reduced reliability is the result of changes in whether it works before and after the gateway has been turned on. If LL1 or LL23 is accepted, simplicity and reliability can be retained by retaining LL support for old connections and transitioning to configured addresses for new ones. Further, an administrator who did not want LL on his network will simply have to assign addresses to those hosts and get this result. Erik From owner-zeroconf@merit.edu Sun Feb 23 06:52:12 2003 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 GAA06672 for ; Sun, 23 Feb 2003 06:52:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3AEC3912EF; Sun, 23 Feb 2003 06:55:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A483912F0; Sun, 23 Feb 2003 06:55:55 -0500 (EST) 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 19374912EF for ; Sun, 23 Feb 2003 06:55:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0A6D75DF45; Sun, 23 Feb 2003 06:55:55 -0500 (EST) 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 AE32A5DDC5 for ; Sun, 23 Feb 2003 06:55:54 -0500 (EST) 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 EAA10779; Sun, 23 Feb 2003 04:55:53 -0700 (MST) Received: from sun.com (vpn-129-159-0-71.EMEA.Sun.COM [129.159.0.71]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h1NBtnl00977; Sun, 23 Feb 2003 12:55:49 +0100 (MET) Message-ID: <3E58B677.1030208@sun.com> Date: Sun, 23 Feb 2003 12:54:31 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Ted Lemon Cc: Philip Nye , Zeroconf Working Group Subject: Re: LL1, LL23 References: <7EBA5E17-4692-11D7-A12D-00039317663C@nominum.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 Ted Lemon wrote: >> How? Give me a concretre example where keeping a LL address solves the >> switching issue which can't be solved under LL1/LL23? > > > You are on a network with a DHCP server, and you get a lease. Your > friend is on a different network with a DHCP server, and gets a lease. > You meet for lunch. You plug your computers into each other. > Neither lease has yet expired. With LL1/LL23, the two computers cannot > interoperate. Without LL1/LL23, they can. Ted, [WG chair hat off] This email explores the possibility that one could accept LL1/LL23 and avoid the problem you state above. What about LL1/LL23 precludes the host(s) from determining that though they have a valid DHCP lease, they cannot reach the gateway, nor the DHCP server and since, for example, they have woken up. They assume they must be 'somewhere else.' They then go back to link-local configuration. As Philip has brought up - this transition from configured to unconfigured needs thinking through. But nothing in LL1 or LL23 precludes a host from interpreting: LL1 A host should use an IPv4LL address as a source address when the only addresses available to the host are IPv4LL addresses. what *available* means and LL23 For this reason, a host that obtains, or is configured with, a routable address on an interface, SHOULD NOT attempt to configure a link-local address on the same interface. Where a link-local address has been configured on an interface, and a routable address is later configured on the same interface, the host MUST always use the routable address when initiating new communications, and MUST cease advertising the availability of the link-local address through whatever mechanisms that address had been made known to others. A host SHOULD continue to use the link-local address for communications underway when the routable address was configured, and MAY continue to accept new communications addressed to the link-local address. what *is configured with* means. Or - is there a requirement that a DHCP client retain a lease even if it the host is powered off, loses carrier sense, goes to sleep, determines that it has entered a new foreign network, etc? Isn't this left to the implementor's discretion? [WG chair hat on] I am fine adding a new issue like "A host may transition to use of link-local addresses if it determines it is on a foreign network" Thanks, Erik From owner-zeroconf@merit.edu Sun Feb 23 07:31:21 2003 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 HAA06928 for ; Sun, 23 Feb 2003 07:31:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 851F8912F0; Sun, 23 Feb 2003 07:35:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E7A8912F1; Sun, 23 Feb 2003 07:35:06 -0500 (EST) 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 2A567912F0 for ; Sun, 23 Feb 2003 07:35:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0E4865E09C; Sun, 23 Feb 2003 07:35:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by segue.merit.edu (Postfix) with ESMTP id E0C535DF50 for ; Sun, 23 Feb 2003 07:35:04 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mvLP-0002en-00; Sun, 23 Feb 2003 04:34:59 -0800 Date: Sun, 23 Feb 2003 07:32:12 -0500 From: Keith Moore To: Mika Liljeberg Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030223073212.2b28c0c7.moore@cs.utk.edu> In-Reply-To: <1045990631.30660.133.camel@devil> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934019.27185.157.camel@devil> <20030222124023.63bc31d8.moore@cs.utk.edu> <1045938480.27185.232.camel@devil> <20030222143305.17390c4b.moore@cs.utk.edu> <1045944748.27185.264.camel@devil> <20030222162605.506279bf.moore@cs.utk.edu> <1045951573.27180.299.camel@devil> <20030222171824.3c6604ad.moore@cs.utk.edu> <1045955078.27185.329.camel@devil> <20030223002242.44a3c251.moore@cs.utk.edu> <1045990631.30660.133.camel@devil> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Keith, > > That's certainly a civil way to end a discussion. I would have liked to > discuss the applications one by one, but it looks like further argument > with you would not be very productive. funny, I'd reached the identical conclusion about you. From owner-zeroconf@merit.edu Sun Feb 23 07:39:21 2003 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 HAA07026 for ; Sun, 23 Feb 2003 07:39:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 126E8912F1; Sun, 23 Feb 2003 07:43:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5A4B912F2; Sun, 23 Feb 2003 07:43:04 -0500 (EST) 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 A978A912F1 for ; Sun, 23 Feb 2003 07:43:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8EC7E5E0A7; Sun, 23 Feb 2003 07:43:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by segue.merit.edu (Postfix) with ESMTP id 6DB345E0A6 for ; Sun, 23 Feb 2003 07:43:03 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mvRg-00015u-00; Sun, 23 Feb 2003 04:41:28 -0800 Date: Sun, 23 Feb 2003 07:38:40 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, mika.liljeberg@welho.com, Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030223073840.17db2337.moore@cs.utk.edu> In-Reply-To: <3E58A701.5060304@sun.com> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934640.27180.162.camel@devil> <20030222124230.3cd9a83b.moore@cs.utk.edu> <1045936283.27185.165.camel@devil> <20030222125141.6f6171a2.moore@cs.utk.edu> <1045938523.27180.234.camel@devil> <20030222143537.6bd7c13f.moore@cs.utk.edu> <3E589FF7.4000100@sun.com> <1045996878.30655.143.camel@devil> <3E58A701.5060304@sun.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > The specific issue that was being discussed here was MacOS returning an > > invalid hostname, apparently in conjunction with the use of a link local > > addressing or name resolution. As such, I don't think it qualifies as an > > example of installed base. It only qualifies to point out the immaturity > > of said implementation (which is understandable as the specifications > > are not ready either). > > This is not an issue with link-local autoconfiguration which is being > discussed here. The behavior you are referring to is that of Apple's > Rendezvous product. actually it's less than that - it's just a statement about how reliable gethostbyname (gethostname ()) is at finding a routable IP address. people have been trying to make overgeneralizations of the form "LL will not break apps", and this is a counterexample. Keith From owner-zeroconf@merit.edu Sun Feb 23 07:50:04 2003 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 HAA07165 for ; Sun, 23 Feb 2003 07:50:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DCD56912F2; Sun, 23 Feb 2003 07:53:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1D1A912F3; Sun, 23 Feb 2003 07:53:48 -0500 (EST) 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 6B762912F2 for ; Sun, 23 Feb 2003 07:53:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A69B5E0AC; Sun, 23 Feb 2003 07:53:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by segue.merit.edu (Postfix) with ESMTP id 294625E0A7 for ; Sun, 23 Feb 2003 07:53:47 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18mvdR-0006p1-00; Sun, 23 Feb 2003 04:53:37 -0800 Date: Sun, 23 Feb 2003 07:50:49 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, mika.liljeberg@welho.com, Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030223075049.625959d0.moore@cs.utk.edu> In-Reply-To: <3E589FF7.4000100@sun.com> References: <200302212342.h1LNgvjC002217@burp.tkv.asdf.org> <7F580D4A-45FA-11D7-A12D-00039317663C@nominum.com> <20030222003448.701b2253.moore@cs.utk.edu> <1045906958.26682.15.camel@devil> <20030222101021.449ef2ff.moore@cs.utk.edu> <1045929688.27180.122.camel@devil> <20030222112609.18990282.moore@cs.utk.edu> <1045934640.27180.162.camel@devil> <20030222124230.3cd9a83b.moore@cs.utk.edu> <1045936283.27185.165.camel@devil> <20030222125141.6f6171a2.moore@cs.utk.edu> <1045938523.27180.234.camel@devil> <20030222143537.6bd7c13f.moore@cs.utk.edu> <3E589FF7.4000100@sun.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > I would like to supply such examples. But I doubt I'll have time to > > investigate and write them up in detail within the next several days. > > It is in no way unfair to say that this process must come to an > end - soon - and that we have all had months to gather evidence > for our arguments and innumerable calls for concrete examples > of applications which fail due to link-local. Such concrete examples have been given more times than I can count. (or at least, I'm not willing to cull through the archives to do so) Of course, responding to posts to this list only takes minutes per post, while providing detailed analysis of failures for applications takes several hours of focused work per application. Actually testing the apps for failures under controlled conditions takes a lot of time also. It's much harder to find those chunks of time, and given past experience with an attempt to provide detailed analysis it's hard to believe that such an investment is worthwhile. That and I object to the entire line of argument. It's not unreasonable to want examples of things that break, but those have been given. It is unreasonable to dismiss those examples out-of-hand because there is a fix for one specific app, or because an app doesn't fail under one artifical set of conditions that you specify, and then claim that there's no general problem. Keith From owner-zeroconf@merit.edu Sun Feb 23 12:22:13 2003 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 MAA10100 for ; Sun, 23 Feb 2003 12:22:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 29A2891226; Sun, 23 Feb 2003 12:25:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EDB3191235; Sun, 23 Feb 2003 12:25:57 -0500 (EST) 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 EFA5291226 for ; Sun, 23 Feb 2003 12:25:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id DC4D45DFBD; Sun, 23 Feb 2003 12:25:56 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 8BCBF5DE98 for ; Sun, 23 Feb 2003 12:25:56 -0500 (EST) Received: from nominum.com (az-ben-pm3-2-37.ppp.theriver.com [206.25.50.37]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1NHMlN01222 for ; Sun, 23 Feb 2003 11:22:47 -0600 (CST) Date: Sun, 23 Feb 2003 10:25:55 -0700 Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL [LL2,LL1,LL23] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <11264.1045992468@munnari.OZ.AU> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Others seem to see LL addressing as solving some other problem, > allowing > access to nodes which have been mis-configured, and all kinds of other > exotic possibilities like that. The example that I described, where two people meet over lunch with laptops that got DHCP addresses at their respective work locations is not a misconfiguration. Can you point to a place in RFC2131 where it says anything other than that the two devices are doing exactly the right thing? And yet they have incorrect configurations. So you can't argue that it's not useful to handle this case in IPv4ll. You *can* argue that it's not useful *enough* to justify the cost, but your argument that it's not useful is not valid. From owner-zeroconf@merit.edu Sun Feb 23 13:12:20 2003 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 NAA10762 for ; Sun, 23 Feb 2003 13:12:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D4111912FA; Sun, 23 Feb 2003 13:15:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27C75912FB; Sun, 23 Feb 2003 13:15:19 -0500 (EST) 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 C58EB912F8 for ; Sun, 23 Feb 2003 13:15:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3C01E5E0D4; Sun, 23 Feb 2003 13:15:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 0DEA75E0D3 for ; Sun, 23 Feb 2003 13:15:16 -0500 (EST) Received: from nominum.com (az-ben-pm3-2-37.ppp.theriver.com [206.25.50.37]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1NIC7N01722; Sun, 23 Feb 2003 12:12:07 -0600 (CST) Date: Sun, 23 Feb 2003 11:15:15 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Zeroconf Working Group To: Erik Guttman From: Ted Lemon In-Reply-To: <3E58B677.1030208@sun.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > What about LL1/LL23 precludes the host(s) from determining that > though they have a valid DHCP lease, they cannot reach the gateway, > nor the DHCP server and since, for example, they have woken up. They > assume they must be 'somewhere else.' They then go back to link-local > configuration. What LL1/LL23 do is to create an interdependency between IPv4ll and DHCP that is sufficiently strong that we would have to say that this draft now updates RFC2131. Neither LL1 nor LL23 provides sufficient detail to really update RFC2131. So if either is accepted, then we need to go through this draft very thoroughly and tweak it so that it is actually a complete update to RFC2131. We have to examine all the states that a DHCP client can get into, and update RFC2131 to describe how the client makes transitions to and from the state of running IPv4ll rather than a DHCP-supplied address. You are correct that it is possible to do this. I think it would work pretty nicely. However, it is a big job, if we do it right, and I don't think it's correct to just pretend that this draft, with the addition of LL1 and LL23, doesn't update RFC2131, so doing it right is a significant amount of additional work. So the question is, is it a big win to go through all this extra work, or is it easier just to make IPv4ll and DHCP independent of each other? What are the benefits to making DHCP and IPv4ll interdependent? What are the drawbacks? Several benefits have been raised, but none of these are very convincing. For example, Christian, Philip and Kevin are all concerned about address leakage. Another benefit that's been described is that LL1 and LL23 make the application's life easier, because the application isn't going to have to know how to choose between the IPv4ll address and the global address. But these objections are not convincing, because in order for them to be valid, it would have to be the case that LL1 or LL23 made it so that a node _never_ had both an IPv4ll address and a global address, and this is not what either proposal actually does. If there were no better way to solve this problem, we could all shrug our shoulders and get back to the business of updating RFC2131, but I don't believe this is necessary. I think the problems with multiple addresses are (a) already being dealt with for other reasons and (b) not as bad as some participants in this discussion theorize. Christian mentions the problem with queries for net 10 addresses at the root, and implies that allowing a node to have both an IPv4ll and a global address will result in similar problems. But the fact is that LL1/LL23 do not solve this problem - it's still possible that my IPv4ll-aware device that happens to have a global address will do a PTR lookup when it gets a connection from my IPv4ll device that doesn't currently have a routable address. In fact, I'm not sure in what case an actual reduction in the number of queries to the root would happen as a result of accepting LL1/LL23. Christian also mentions the problem of a multiply-connected node which does IPv4ll on both connections, and suggests that if we can in some cases reduce the number of interfaces over which we communicate using IPv4ll, this will in some way address the problem. This is a solution that we can't really depend on - there's no guarantee that one network will be managed and the other not. Even if one network is managed, there is no guarantee that some hosts on that network will not have IPv4ll addresses - for example, if there is a shortage of addresses on the DHCP server, some devices might get addresses and some not. And in fact, the problem he describes is small. In order to do IPv4ll over multiple interfaces, the IP stack must be smart enough to ARP on all interfaces that support IPv4ll when it is asked to communicate with IPv4ll address that is not currently in the ARP cache. For addresses that *are* in the ARP cache, the stack just sends the packet out whichever interface the ARP reply that created the cache entry was received. This isn't very hard to do, and it works perfectly, *except* in the case where there are devices on both links that have the same IPv4ll address. In this case, LL1/LL23 do not help at all, because they address the multihomed device, not the two devices that have conflicting addresses. This is a problem with any IPv4ll multihomed environment, and I have yet to see any proposal for how to fix it. But in fact with LL19 instead of LL1/LL23, if the device has both an IPv4ll and a routable IP address, we will always connect to its routable address, so the fact that its IPv4ll address is in conflict will never be a problem. It is unfortunate that LL19 was discussed and rejected separately from LL1/LL23, because the two are strongly interconnected. LL19 solves a lot of the problems that LL1/LL23 try to solve, in a much better way. Taken by itself, with the assumption that LL1 and LL23 would be accepted, LL19 sounds like a really bad idea, but considered as an alternative to LL1/LL23, it makes a lot of sense. From owner-zeroconf@merit.edu Sun Feb 23 13:25:00 2003 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 NAA10844 for ; Sun, 23 Feb 2003 13:25:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D47B991235; Sun, 23 Feb 2003 13:28:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0426912F5; Sun, 23 Feb 2003 13:28:44 -0500 (EST) 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 B081391235 for ; Sun, 23 Feb 2003 13:28:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8535A5E0CA; Sun, 23 Feb 2003 13:28:43 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id E95985DEDB for ; Sun, 23 Feb 2003 13:28:42 -0500 (EST) Received: from nominum.com (az-ben-pm3-2-37.ppp.theriver.com [206.25.50.37]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1NIPYN01795 for ; Sun, 23 Feb 2003 12:25:35 -0600 (CST) Date: Sun, 23 Feb 2003 11:28:42 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: "Zeroconf Working Group" Content-Transfer-Encoding: 7bit In-Reply-To: <001801c2dab8$49f8b970$131010ac@aldebaran> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > There are many applications in the embedded world where LL is very > attractive, but for which LLMNS (or DNS) is a complete irrelevance. > Things > like SLP and a host of specialist small scale discovery protocols are > much > more relevant. The thing is, I've been through the scenarios for how an address would get into SLP, for example, and I don't see how it would be the case that the wrong address would find its way into SLP, except in cases where there is no right address to put into SLP. To be more precise, *if* the O.S. presents both the IPv4ll and the global address as the same kind of address, I can see how SLP could get the wrong data. But the solution to this is easy - just don't present both addresses the same way. Most applications of which I am aware aren't even smart enough to notice address transitions. You start them up, they (maybe) check to see what addresses are configured, and they assume that whatever addresses they saw remain configured for all time. If for some reason the system's addresses change, the application simply stops working. The only reason this isn't a bigger problem is that most server applications simply listen on 0.0.0.0, not on specific IP addresses, unless the user requests otherwise, and then they just do what they're told, which is usually the right thing. Resource discovery applications are an exception to this. To make them work most smoothly, they should be IPv4ll-aware. I would think that the authors of such apps would *want* to support IPv4ll. But we can make it so that even if they are not IPv4ll-aware, they still work in the cases where they're expected to work in the absence of IPv4ll, and in many cases where IPv4ll is present. So I don't think this is a problem, and so I don't think it can be used as a reason to justify accepting LL1 or LL23. From owner-zeroconf@merit.edu Sun Feb 23 13:30:36 2003 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 NAA10904 for ; Sun, 23 Feb 2003 13:30:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0644D91236; Sun, 23 Feb 2003 13:34:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2FB591220; Sun, 23 Feb 2003 13:34:19 -0500 (EST) 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 35DB8912F5 for ; Sun, 23 Feb 2003 13:33:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1232B5E0D5; Sun, 23 Feb 2003 13:33:52 -0500 (EST) 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 B794F5E0D3 for ; Sun, 23 Feb 2003 13:33:51 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 8BA9259891 for ; Sun, 23 Feb 2003 18:33:54 +0000 (GMT) Message-ID: <001101c2db6a$4871f780$131010ac@aldebaran> From: "Philip Nye" Cc: "Zeroconf Working Group" References: <6C98F925-46A5-11D7-A12D-00039317663C@nominum.com> <001801c2dab8$49f8b970$131010ac@aldebaran> <3E58A0BD.8080307@sun.com> Subject: Re: LL1, LL23 Date: Sun, 23 Feb 2003 18:35:04 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Erik Guttman" > > >>All apps use both LLMNS and DNS, according to the rules of those > >>protocols. If you don't use LLMNS or some other link-local node > >>discovery protocol, you can't use IPv4ll addresses anyway. The > >>transparency of IPv4ll depends specifically on LLMNS in most cases, > >>like it or not. > > > > > > I don't buy this at all. If the IP world was a cozy place where apps dealt > > only with names and relied on a narrow DNS/LLMNS system to work out the > > details then what you propose might work. However this is only a small part > > of the IP world. > > Concrete examples, please? Of systems which don't get IP addresses through DNS/LLMNS? Networks where names are used but do not use DNS - Popular alternatives are netbios (and appletalk?), NIS etc. Networks where names are not used at all - generally other hosts are contacted not directly by resolving names but by service discovery. Most service discovery protocols including SLP, SSDP, Salutation (I think), SIP and probably Jini use URLs to locate services. In a system with no names, these URLs contain raw addresses. I quote from the SIP spec: ...many end systems do not have registered domain names, so IP addresses are permitted. In such systems, services are frequently distinguished using UUIDs which effectively take the place of names. However, these are not resolved to addresses in the DNS system, but through the service discovery protocol itself. Where such service discovery protocols are or can be mediated by some sort of server (as is the case in SLP, SIP, Jini and Salutation) these addresses are passed on - often multiple times (c.f. SIP and mesh enhanced SLP). My requirement is not for LL1/LL23 to succeed - that is only a means to an end. My requirement is that these systems work including LL networks such that the *only* restriction is the obvious one that hosts with only LL connectivity cannot themselves communicate off-link. Now as I understand it Mika and Ted believe that somehow the LL addresses of hosts will not get into such systems. I fail to understand how they will stop this and yet allow these systems to operate over and across LL where appropriate. Concrete examples? I gave one in http://www.merit.edu/mail.archives/zeroconf/2003-02/msg00527.html I'd like some concrete answers in return. Mika and Ted, The response to my example makes me think that you have in their minds other restrictions or rules which have not been understood or you are assuming a different set of axioms than I am - in particular in terms of what you expect to work and what you regard as an abberation. What is the set of rules which makes LL work without LL addresses getting out of scope? Simply restating LL19 (which has been rejected anyway) is not enough. Refer to my pervious example above if possible. Are permanently LL-only devices allowed, even on configured networks? Are a mixed set of LL-only and routable hosts allowed to co-operate? What is expected to happen when a DHCP server pops up on a LL network? What happens if a DHCP server refuses to supply addresses to some but not all hosts? If all hosts have configured addresses, when and why would they decide to use their LL addresses? How are misconfigured routable addresses dealt with? Philip From owner-zeroconf@merit.edu Sun Feb 23 13:32:57 2003 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 NAA10936 for ; Sun, 23 Feb 2003 13:32:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C3D0791220; Sun, 23 Feb 2003 13:36:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97BD5912F5; Sun, 23 Feb 2003 13:36:41 -0500 (EST) 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 9FD3A91220 for ; Sun, 23 Feb 2003 13:36:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 883B25E0D4; Sun, 23 Feb 2003 13:36:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 066F65E0D3 for ; Sun, 23 Feb 2003 13:36:40 -0500 (EST) Received: from nominum.com (az-ben-pm3-2-37.ppp.theriver.com [206.25.50.37]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1NIXWN01861 for ; Sun, 23 Feb 2003 12:33:32 -0600 (CST) Date: Sun, 23 Feb 2003 11:36:39 -0700 Subject: Re: LL1, LL23 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030223073840.17db2337.moore@cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > actually it's less than that - it's just a statement about how reliable > gethostbyname (gethostname ()) is at finding a routable IP address. > people have been trying to make overgeneralizations of the form > "LL will not break apps", and this is a counterexample. This is an example of how gethostbyname(gethostname()) breaks apps. Gethostbyname(gethostname()) is never the right way to get a host's IP address. When it works, it's a happy coincidence. The fact that people use it as much as they do is a result of the fact that there isn't a nice API that says "what's my address," which is in turn a result of the fact that it is usually not possible to give a good answer to that question. My point is that the fact that IPv4ll might in some cases break gethostbyname(gethostname()) isn't a very compelling worry. BTW, note that in the specific case you were talking about, with LLMNS working the way I suggested, gethostname(gethostbyname()) does in fact return a global IP address if you have one, and an IPv4ll address if you don't - that is, it's actually *more* reliable than usual, not less. From owner-zeroconf@merit.edu Sun Feb 23 15:51:08 2003 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 PAA12406 for ; Sun, 23 Feb 2003 15:51:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 71DF891244; Sun, 23 Feb 2003 15:54:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 376069124B; Sun, 23 Feb 2003 15:54:53 -0500 (EST) 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 C634491244 for ; Sun, 23 Feb 2003 15:54:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id A8C835E123; Sun, 23 Feb 2003 15:54:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 7002C5E121 for ; Sun, 23 Feb 2003 15:54:50 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1NKtTaj005404; Sun, 23 Feb 2003 22:55:30 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1NKtRD2005403; Sun, 23 Feb 2003 22:55:27 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Philip Nye Cc: Zeroconf Working Group In-Reply-To: <001101c2db6a$4871f780$131010ac@aldebaran> References: <6C98F925-46A5-11D7-A12D-00039317663C@nominum.com> <001801c2dab8$49f8b970$131010ac@aldebaran> <3E58A0BD.8080307@sun.com> <001101c2db6a$4871f780$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046033726.3298.130.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Feb 2003 22:55:26 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-02-23 at 20:35, Philip Nye wrote: > Now as I understand it Mika and Ted believe that somehow the LL addresses of > hosts will not get into such systems. I fail to understand how they will > stop this and yet allow these systems to operate over and across LL where > appropriate. > > Concrete examples? > I gave one in > http://www.merit.edu/mail.archives/zeroconf/2003-02/msg00527.html > I'd like some concrete answers in return. > > Mika and Ted, > The response to my example makes me think that you have in their minds other > restrictions or rules which have not been understood or you are assuming a > different set of axioms than I am - in particular in terms of what you > expect to work and what you regard as an abberation. > > What is the set of rules which makes LL work without LL addresses getting > out of scope? Simply restating LL19 (which has been rejected anyway) is not > enough. Refer to my pervious example above if possible. The rules I had in mind in an unsolidified form (before LL19 got rejected) are roughly as follows: a) Legacy nodes MUST NOT be configured with an LL addresses (or with an 169.254/16 on-link route) b) Only a node having a LL address can be assumed to be LL-compliant (barring misconfiguration). This depends on a). c) LL-complaint nodes MUST NOT use a LL address unless they can ascertain that the peer is LL-compliant. Recognition of an LL-compliant peer depends on b). d) If a LL-compliant node has a routable address, the system APIs on the node MUST make a reasonable attempt to hide LL addresses from non LL-aware applications (i.e., the application must either explicitly request to see LL addresses or at least routable addresses must be returned first by any enumeration APIs) e) An LL-compliant node MUST NOT advertize any of its addresses beyond the reachability of that address. The service discovery APIs provided by the OS must enforce this, because we don't expect the applications to honor this rule. f) All LL-compliant nodes should configure a LL address, regardless of whether they have a routable one or not. [You can substitute SHOULD for MUST in the above if you like, with the understanding that it makes the address leakage more likely.] Now, it is clear that the rules above are not bullet proof. If any single one is violated, there is risk of leakage. However, no solution is really is. The question is, would these rules work well enough? Let's examine some of the properties of those rules: 1) Rule a) is the only one that legacy nodes are expected to follow. This is reasonable, since by default they are configured that way. Only configuration by an administrator can cause them to break rule a). However, we cannot expect legacy nodes to follow any of the other rules. 2) Since legacy nodes cannot be expected to enforce rule e), they are a likely source of address leakage if they get hold of a LL address. One example of such behaviour was given in the LL19 problem statement. A DNS PTR query on an LL adress is another one. We must prevent that. 3) Rule c) ensures that legacy nodes will not get an LL address from getpeername(). That leaves application protocols and service discovery protocols. [And manual configuration as well as other obscure ways.] 4) Rule d) ensures legacy nodes will not receive LL addresses from non LL-aware applications running on an LL-compliant node, which has a routable address. Conversely, rule d) ensures that a legacy application running on a LL-compliant node, which also has a routable address, will not inadvertently advertise the node's LL address. 5) Rule e) ensures that legacy nodes will not get a LL address via a service discovery protocol. Conversely, rule e) ensures that OS services running on a LL-aware node will not inappropriately advertise the LL address. I think I misread your example a bit before, thinking more about plausibility than the referral chain. Let's try again by linking the rules to your example: > > A B(LL) C D > > +----+------+---+routing+---+ > > > > A, C and D have routable addresses > > B is LL only. > > > > A, B, C and D are running a collaborative service. > > > > 1. A and B communicate > > 2. B passes A's address on to C > > 3. C and A communicate > > 4. C passes A's address on to D > > 5. D communicates with A 1) we know that B is a LL-node, so it would honor all the rules above. 2) If A and C don't have LL addresses, node B would be breaking rule c) by communicating with them [since it can't be sure they are LL-compliant]. However, due to rule f) A and B would also have LL addresses. 3) If A and C have both LL and routable addresses, A may legally communicate with them and hence A's address can be passed to C via B. 4) C appears to be a multihomed host. Christian pointed out that there are problems having LL addresses on multiple interfaces. So, let's assume that C has LL+routable on B's side and only routable on D's side. 5) Node C would be breaking rule d) by advertising A's LL address to D (which is beyond the scope of the address). However, passing A's routable address to D doesn't violate the rule. The rules are somewhat harsher than I had initially envisioned, but as you can see that they would work in your scenario while effectively curtailing address leakage. > Are permanently LL-only devices allowed, even on configured networks? Permanently LL-only nodes are likely to be very restricted devices, which do not need to participate in complex applications. In practise, they should not have any need to participate in routed networks. If there was a use case, the manufacturer would surely provide a mechanism to configure a routable address. However, I don't think we can assume that such would never be connected to a link that is also part of a routed network. In fact, they probably will. What we coud do, though, is say that their utility in routed networks is limited; that they can only connect to other LL-compliant nodes. LL19 would have enforce this and thus effectively contained any problems that such LL-only nodes might cause in a routed network. > Are a > mixed set of LL-only and routable hosts allowed to co-operate? Under my proposed rules, only if the routabe nodes also have LL addresses. All LL-compliant nodes would have one. Legacy nodes would not. > What is > expected to happen when a DHCP server pops up on a LL network? All nodes that can configure a routable address will do so, leaving their LL addresses on the side. > What happens > if a DHCP server refuses to supply addresses to some but not all hosts? Some nodes will have routable addresses, and all compliant nodes will also have an LL addresses. Legacy nodes may or may not have a single routable address, depending on the DHCP server. > If > all hosts have configured addresses, when and why would they decide to use > their LL addresses? Normally they wouldn't, since the applications would be using the routable addresses (rule d). An application could explicitly try a LL-address. > How are misconfigured routable addresses dealt with? They aren't exactly, as the rules for LL are completely independent of the configuration of routablea addresses. However, all compliant nodes will have a LL address and are able to interoperate using those. A LL-aware application could explicitly switch to using a LL destination address if the MikaL From owner-zeroconf@merit.edu Sun Feb 23 16:03:50 2003 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 QAA12626 for ; Sun, 23 Feb 2003 16:03:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B94689124B; Sun, 23 Feb 2003 16:07:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88F61912F5; Sun, 23 Feb 2003 16:07:35 -0500 (EST) 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 7CEFE9124B for ; Sun, 23 Feb 2003 16:07:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 604145E0CA; Sun, 23 Feb 2003 16:07:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 5B16F5DE9E for ; Sun, 23 Feb 2003 16:07:33 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1NL8Daj005467; Sun, 23 Feb 2003 23:08:14 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1NL8B1X005466; Sun, 23 Feb 2003 23:08:11 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Philip Nye Cc: Zeroconf Working Group In-Reply-To: <1046033726.3298.130.camel@devil> References: <6C98F925-46A5-11D7-A12D-00039317663C@nominum.com> <001801c2dab8$49f8b970$131010ac@aldebaran> <3E58A0BD.8080307@sun.com> <001101c2db6a$4871f780$131010ac@aldebaran> <1046033726.3298.130.camel@devil> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046034489.3298.135.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 23 Feb 2003 23:08:10 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-02-23 at 22:55, Mika Liljeberg wrote: > They aren't exactly, as the rules for LL are completely independent of > the configuration of routablea addresses. However, all compliant nodes > will have a LL address and are able to interoperate using those. A > LL-aware application could explicitly switch to using a LL destination > address if the ...routable address of the peer was not working. > > MikaL > From owner-zeroconf@merit.edu Sun Feb 23 16:54:44 2003 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 QAA13497 for ; Sun, 23 Feb 2003 16:54:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DE5DD9124C; Sun, 23 Feb 2003 16:58:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE0CD912F5; Sun, 23 Feb 2003 16:58:27 -0500 (EST) 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 BA63C9124C for ; Sun, 23 Feb 2003 16:58:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D1525E0E8; Sun, 23 Feb 2003 16:58:26 -0500 (EST) 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 581AF5E0E7 for ; Sun, 23 Feb 2003 16:58:26 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.3/8.12.3) with ESMTP id h1NLwPTb001107 for ; Sun, 23 Feb 2003 13:58:25 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 23 Feb 2003 13:58:24 -0800 Received: from [17.219.195.46] ([17.219.195.46]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h1NLwPf11987 for ; Sun, 23 Feb 2003 13:58:25 -0800 (PST) Message-Id: <200302232158.h1NLwPf11987@scv3.apple.com> Subject: LL27 LL-only hosts Date: Sun, 23 Feb 2003 13:58:27 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Bernard Aboba wrote: >"Hosts supporting configuration of LLv4 addresses MUST also support >configuration of a routable address, netmask and default route, whether >manually or automatically. Hosts not supporting automated configuration >(such as via DHCPv4) SHOULD require manual configuration to enable LLv4." How can we say that a ZERO CONFIGURATION device "SHOULD require manual configuration"? What about tiny devices where the ONLY interface to them is through the network? How do you communicate with them to turn on their zero configuration networking capability in the first place? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sun Feb 23 16:55:06 2003 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 QAA13512 for ; Sun, 23 Feb 2003 16:55:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 48684912F6; Sun, 23 Feb 2003 16:58:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15B28912F7; Sun, 23 Feb 2003 16:58:52 -0500 (EST) 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 CDFF9912F6 for ; Sun, 23 Feb 2003 16:58:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id B4A385DE0A; Sun, 23 Feb 2003 16:58:50 -0500 (EST) 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 40CF35DF6A for ; Sun, 23 Feb 2003 16:58:50 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.3/8.12.3) with ESMTP id h1NLwng7028203 for ; Sun, 23 Feb 2003 13:58:49 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Sun, 23 Feb 2003 13:58:49 -0800 Received: from [17.219.195.46] ([17.219.195.46]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h1NLwnQ12086 for ; Sun, 23 Feb 2003 13:58:49 -0800 (PST) Message-Id: <200302232158.h1NLwnQ12086@scv2.apple.com> Subject: Re: ACCEPT [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses Date: Sun, 23 Feb 2003 13:58:52 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Robert Elz wrote: >you cannot require ARP, because not all link levels use it. >The wording needs to be in such a way that specific link level >technologies are not implied. Excuse me for stating the obvious: 1.2. Applicability The specifications in this document apply to any IEEE 802 media [802] including Ethernet [802.3], and other similar link-layer network technologies that operate at data rates of at least 1Mb/s, have a round-trip latency of at most one second, and support ARP [RFC 826]. Link-layer network technologies that do not support ARP may be able to use other techniques for determining whether a particular IP address is currently in use. However, the application of claim-and- defend mechanisms to such networks is left to a future document. Any questions? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sun Feb 23 16:55:26 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13525 for ; Sun, 23 Feb 2003 16:55:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6E8E3912F5; Sun, 23 Feb 2003 16:58:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 37BF9912F6; Sun, 23 Feb 2003 16:58:39 -0500 (EST) 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 1F022912F5 for ; Sun, 23 Feb 2003 16:58:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BBA05DF6A; Sun, 23 Feb 2003 16:58:36 -0500 (EST) 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 882B65DDD3 for ; Sun, 23 Feb 2003 16:58:35 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.3/8.12.3) with ESMTP id h1NLwZg7028171 for ; Sun, 23 Feb 2003 13:58:35 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 23 Feb 2003 13:58:33 -0800 Received: from [17.219.195.46] ([17.219.195.46]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h1NLwYf12007 for ; Sun, 23 Feb 2003 13:58:34 -0800 (PST) Message-Id: <200302232158.h1NLwYf12007@scv3.apple.com> Subject: Re: ACCEPT [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses Date: Sun, 23 Feb 2003 13:58:37 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Mika Liljeberg wrote: >a) the sender cannot know whether another node is a router or not As Philip Nye already pointed out, a host *does* know this. If a host has a packet addressed to IP address X, and it ARPs for IP address X, and it gets a reply, and then it sends the packet to the hardware address in that ARP reply, then the host is sending the packet directly. If a host has a packet addressed to IP address X, and it ARPs for IP address Y, and it gets a reply, and then it sends the packet to the hardware address in that ARP reply, then why did the host do that? What made the host send the packet to IP address Y instead of IP address X? That's because the host's routing tables told the host that IP address X was not on the local link, and that IP address Y was the correct router to send the packet to for forwarding to IP address X. When a host sends a packet to an IP address other than the one the packet is addressed to, the host is sending it to be forwarded. (Devices that do proxy ARP allow hosts that are not on the local link to masquerade as if they were on the local link, but the devices doing the proxy ARP take on the responsibility for making this work properly. It is not the responsibility of all other hosts on the link to be aware of this masquerade and modify their behaviour to accomodate it.) Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sun Feb 23 16:57:45 2003 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 QAA13557 for ; Sun, 23 Feb 2003 16:57:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 65BE3912F7; Sun, 23 Feb 2003 17:00:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B388912F8; Sun, 23 Feb 2003 17:00:31 -0500 (EST) 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 47D7E912F7 for ; Sun, 23 Feb 2003 17:00:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7184B5DF6A; Sun, 23 Feb 2003 17:00:29 -0500 (EST) 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 D58685DE0A for ; Sun, 23 Feb 2003 17:00:28 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.3/8.12.3) with ESMTP id h1NM0STb001325 for ; Sun, 23 Feb 2003 14:00:28 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 23 Feb 2003 14:00:26 -0800 Received: from [17.219.195.46] ([17.219.195.46]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h1NM0Sf12308 for ; Sun, 23 Feb 2003 14:00:28 -0800 (PST) Message-Id: <200302232200.h1NM0Sf12308@scv3.apple.com> Subject: Oppose: LL1 Preferred use of configured to v4 LL address Date: Sun, 23 Feb 2003 14:00:30 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk I do not support requiring the host to always use its "global" address, if it has one. There are a number of problems with this: 1. How does the host know what address is truly global? What about addresses that are being translated by a NAT gateway? Saying, "This Working Group refuses to acknowledge the existence of NAT because there is no IETF standard for NAT," is not of any practical use to companies that are trying to sell products to real customers in the real world. Like it or not, the fact is that in today's world, all IPv4 addresses are scoped, with no reliable programmatic way to tell what scope each has. At least with v4LL addresses, the scope is clearly defined. 2. What about stale DHCP addresses, or manually configured addresses that are just plain wrong? People have said that it is outside the charter of this Working Group to try to make devices that work reliably even in the face of accidental misconfiguration. That may be true, but developing devices that work reliably even in the face of accidental misconfiguration is a high priority for Apple, and most of the consumer electronics companies adding networking to their home Hi-Fi equipment. This Working Group should give at least some small consideration to those companies. The benefit of sending a packet with a v4LL source address to a v4LL-compliant peer is that the peer will always reply directly back to you, because all v4LL addresses are defined to be on-link. There is no way for the peer to be accidentally misconfigured, because you can't have a configuration error when there is no configuration. (This is the point of "zero configuration".) If you send a packet with a routable address, then whether the peer replies to you can be dependent on things like whether that peer has the correct subnet mask set, what routing table entries are present, etc. Possibly it may make sense to attempt a connection first using the routable address first, and then, if that fails, after a short interval (half second?) try with the LL address as well. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sun Feb 23 16:57:54 2003 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 QAA13571 for ; Sun, 23 Feb 2003 16:57:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0A362912F8; Sun, 23 Feb 2003 17:01:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DCA1B912FC; Sun, 23 Feb 2003 17:01:17 -0500 (EST) 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 771E9912F8 for ; Sun, 23 Feb 2003 17:00:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8A66D5DF6A; Sun, 23 Feb 2003 17:00:39 -0500 (EST) 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 32B435DE0A for ; Sun, 23 Feb 2003 17:00:39 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.3/8.12.3) with ESMTP id h1NM0cTb001357 for ; Sun, 23 Feb 2003 14:00:38 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Sun, 23 Feb 2003 14:00:38 -0800 Received: from [17.219.195.46] ([17.219.195.46]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h1NM0bQ12411 for ; Sun, 23 Feb 2003 14:00:37 -0800 (PST) Message-Id: <200302232200.h1NM0bQ12411@scv2.apple.com> Subject: Oppose: LL2 DHCP Mechanism to disable v4 LL Date: Sun, 23 Feb 2003 14:00:40 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk I strongly oppose requiring the host to implement a DHCP Mechanism to disable v4 LL. This makes it too easy for greedy ISPs (like the now-bankrupt @Home, whose name appears at the top of never-implemented-by-anyone RFC 2563) to exert unjustified control over what the customer may do on their own Ethernet network in their own home. Ted Lemon also listed many good reasons why this is an inappropriate mechanism. If you want to deny a host access to the network, then DHCP-based solutions are just not the right mechanism. They just encourage people to continue using AppleTalk. If you want to deny a host access to the network, then 802.1X gives you the control you want, and blocks ALL protocols. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sun Feb 23 16:58:11 2003 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 QAA13585 for ; Sun, 23 Feb 2003 16:58:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 132E0912F9; Sun, 23 Feb 2003 17:01:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F99E912FB; Sun, 23 Feb 2003 17:01:17 -0500 (EST) 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 AF1A0912F9 for ; Sun, 23 Feb 2003 17:01:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id BD5885DEC6; Sun, 23 Feb 2003 17:00:50 -0500 (EST) 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 13D895DF6A for ; Sun, 23 Feb 2003 17:00:50 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.3/8.12.3) with ESMTP id h1NM0ng7028370 for ; Sun, 23 Feb 2003 14:00:49 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Sun, 23 Feb 2003 14:00:48 -0800 Received: from [17.219.195.46] ([17.219.195.46]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h1NM0nf12375 for ; Sun, 23 Feb 2003 14:00:49 -0800 (PST) Message-Id: <200302232200.h1NM0nf12375@scv3.apple.com> Subject: Support: LL2 ARP Mechanism to disable v4 LL Date: Sun, 23 Feb 2003 14:00:51 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Keith Moore suggested an ARP-based mechanism to disable use of IPv4LL. Since an ARP-based denial-of-service attack is possible anyway by another device on the same physical link, it makes sense to standardize this, instead of having different vendors each invent their own different denial-of-service attack to shut down IPv4LL. I propose that in response to an ARP Probe, an ARP Response giving all-zeroes as the sender hardware address, and the requested address as the sender IP address, serves to tell the sender not to use IPv4LL on this network for some period of time. The time period could be the standard one-minute mentioned elsewhere in the document, or longer. It should not be longer than five minutes, because we don't want it to take an undue length of time for the network to recover after such a denial-of-service attack. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sun Feb 23 16:58:32 2003 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 QAA13599 for ; Sun, 23 Feb 2003 16:58:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6F13E912FB; Sun, 23 Feb 2003 17:01:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3845E912FC; Sun, 23 Feb 2003 17:01:50 -0500 (EST) 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 D4BE2912FB for ; Sun, 23 Feb 2003 17:01:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 885F85DE0A; Sun, 23 Feb 2003 17:01:18 -0500 (EST) 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 481D35DDD3 for ; Sun, 23 Feb 2003 17:01:18 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.3/8.12.3) with ESMTP id h1NM1HTb001423 for ; Sun, 23 Feb 2003 14:01:17 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Sun, 23 Feb 2003 14:01:17 -0800 Received: from [17.219.195.46] ([17.219.195.46]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h1NM1Hf12481 for ; Sun, 23 Feb 2003 14:01:17 -0800 (PST) Message-Id: <200302232201.h1NM1Hf12481@scv3.apple.com> Subject: Oppose: LL23 Don't configure needless LL addresses Date: Sun, 23 Feb 2003 14:01:20 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Robert Elz wrote: >A node with any address assigned for a link can communicate with >all other devices on that link This is only true if all devices on the link are correctly configured with compatible addresses, subnet masks, routing tables, etc. It has been said that making devices work reliably even in the face of accidental misconfiguration is outside the charter of this Working Group. If this is true, then we may just have to accept that this is a point where industry and the IETF will have to agree to disagree, and accept that our solutions will be broadly similar but will differ in a few minor details. The consumer electronics companies need interconnects that are as reliable and fail-safe as the venerable red, white and yellow analog RCA cables. When a customer connects their rack of Hi-Fi and television equipment using Ethernet cables, they need to know that it will definitely work, not, "It will work some times, and fail some times, and here are the reasons why..." Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sun Feb 23 17:00:55 2003 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 RAA13638 for ; Sun, 23 Feb 2003 17:00:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6BE40912FC; Sun, 23 Feb 2003 17:04:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E04079124E; Sun, 23 Feb 2003 17:04:30 -0500 (EST) 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 BF896912FC for ; Sun, 23 Feb 2003 17:02:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id A4CB35DE6E; Sun, 23 Feb 2003 17:02:50 -0500 (EST) 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 CABEF5DDD3 for ; Sun, 23 Feb 2003 17:02:49 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.3/8.12.3) with ESMTP id h1NM2ng7028708 for ; Sun, 23 Feb 2003 14:02:49 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Sun, 23 Feb 2003 14:02:49 -0800 Received: from [17.219.195.46] ([17.219.195.46]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h1NM2mQ12937 for ; Sun, 23 Feb 2003 14:02:48 -0800 (PST) Message-Id: <200302232202.h1NM2mQ12937@scv2.apple.com> Subject: Oppose: LL27 LL-only hosts are out of scope for this specification Date: Sun, 23 Feb 2003 14:02:51 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Keith Moore wrote: >IETF has considered the >behavior of private networks (i.e. networks that are entirely >controlled by a single party) as outside of its scope >Use of the Internet Protocol on purely isolated, ad hoc networks >would also be out-of-scope and of little interest to IETF The people who have such mini-networks want to buy products that will interoperate on those networks. The vendors who sell products to use on such mini-networks need standards to follow to make their devices interoperate. Keith Moore's position on this seems to be declaring the IETF irrelevant to this large market of new devices, and seems to be willfully abdicating whatever kind of authority the IETF may have had in this area to some other (as yet unidentified) standards body. I do not believe this is correct. I believe it is a mistake for the IETF to limit its scope to TCP/IP devices and applications only where those devices and applications are used on the one large network we call the Internet. IP-based protocols have useful application in many other contexts too. I don't see any strong argument why the IETF should close its eyes to those contexts and pretend they don't exist. Keith Moore also wrote: >Inherent in the entire concept of "INTERnet", and the "Internet >Protocol" is the ability to communicate _between_ networks. This is true, and this capability of IP is a great benefit. However, everyone is not obliged to use every capability of IP. My BMW is capable of driving at 150MPH. It is nice to know it can do that, but is every owner of a BMW obliged to drive it at 150MPH every time they use it? It's still a good car at 65MPH too. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sun Feb 23 17:08:51 2003 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 RAA13769 for ; Sun, 23 Feb 2003 17:08:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9A7DD9124E; Sun, 23 Feb 2003 17:12:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64067912FD; Sun, 23 Feb 2003 17:12:35 -0500 (EST) 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 581059124E for ; Sun, 23 Feb 2003 17:12:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 377785E0E8; Sun, 23 Feb 2003 17:12:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 2C1DB5E04E for ; Sun, 23 Feb 2003 17:12:33 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1NMDAaj005744; Mon, 24 Feb 2003 00:13:10 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1NMD8v3005741; Mon, 24 Feb 2003 00:13:08 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: ACCEPT [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses From: Mika Liljeberg To: Stuart Cheshire Cc: zeroconf@merit.edu In-Reply-To: <200302232158.h1NLwYf12007@scv3.apple.com> References: <200302232158.h1NLwYf12007@scv3.apple.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046038387.3304.147.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Feb 2003 00:13:08 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sun, 2003-02-23 at 23:58, Stuart Cheshire wrote: > That's because the host's routing tables told the host that IP address X > was not on the local link, and that IP address Y was the correct router > to send the packet to for forwarding to IP address X. I understand all this. Didn't you read my mail? On-link determination happens as part of route selection, before ARP is ever attempted. Hence, ARP does not need to be mentioned. I was only asking for more precise language. The same with proxy ARP routers. The sender cannot know about those, so let's say the requirement in a different way. Was there something wrong with the text I proposed? MikaL From owner-zeroconf@merit.edu Sun Feb 23 17:42:43 2003 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 RAA14142 for ; Sun, 23 Feb 2003 17:42:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3245A912FD; Sun, 23 Feb 2003 17:45:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 01BF3912FE; Sun, 23 Feb 2003 17:45:23 -0500 (EST) 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 0C827912FD for ; Sun, 23 Feb 2003 17:45:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 101B15E075; Sun, 23 Feb 2003 17:45:22 -0500 (EST) 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 418595E04E for ; Sun, 23 Feb 2003 17:45:21 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id B4EF759B4E; Sun, 23 Feb 2003 22:45:24 +0000 (GMT) Message-ID: <001b01c2db8d$6a7ca320$131010ac@aldebaran> From: "Philip Nye" To: "Mika Liljeberg" Cc: "Zeroconf Working Group" References: <6C98F925-46A5-11D7-A12D-00039317663C@nominum.com> <001801c2dab8$49f8b970$131010ac@aldebaran> <3E58A0BD.8080307@sun.com> <001101c2db6a$4871f780$131010ac@aldebaran> <1046033726.3298.130.camel@devil> Subject: Re: LL1, LL23 Date: Sun, 23 Feb 2003 22:46:33 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Mika Liljeberg" > > a) Legacy nodes MUST NOT be configured with an LL addresses (or with an > 169.254/16 on-link route) By legacy I think you mean ones with no LL sense at all? Where do the large numbers of nodes with Apple/Windows LL implementations fit in? Philip From owner-zeroconf@merit.edu Sun Feb 23 18:00:40 2003 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 SAA14570 for ; Sun, 23 Feb 2003 18:00:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0259491240; Sun, 23 Feb 2003 18:04:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1F65912FE; Sun, 23 Feb 2003 18:04:15 -0500 (EST) 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 D30C791240 for ; Sun, 23 Feb 2003 18:04:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id BFF945DDD3; Sun, 23 Feb 2003 18:04:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id D5DE25DD9F for ; Sun, 23 Feb 2003 18:04:12 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1NN4saj005942; Mon, 24 Feb 2003 01:04:54 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1NN4rJu005940; Mon, 24 Feb 2003 01:04:53 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Philip Nye Cc: Zeroconf Working Group In-Reply-To: <001b01c2db8d$6a7ca320$131010ac@aldebaran> References: <6C98F925-46A5-11D7-A12D-00039317663C@nominum.com> <001801c2dab8$49f8b970$131010ac@aldebaran> <3E58A0BD.8080307@sun.com> <001101c2db6a$4871f780$131010ac@aldebaran> <1046033726.3298.130.camel@devil> <001b01c2db8d$6a7ca320$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046041492.3298.163.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Feb 2003 01:04:52 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-02-24 at 00:46, Philip Nye wrote: > > From: "Mika Liljeberg" > > > > a) Legacy nodes MUST NOT be configured with an LL addresses (or with an > > 169.254/16 on-link route) > > By legacy I think you mean ones with no LL sense at all? Correct. > Where do the large numbers of nodes with Apple/Windows LL implementations > fit in? We'll find a free spot somewhere among the legacy nodes. :) Seriously, there'll be lots of legacy nodes around, since not everyone runs Windows or Macos and many of those who do don't really update their machines all that often. I probably overemphasized the legacy nodes a bit, but if we're talking about address leakage, legacy nodes and legacy apps are the obvious culprits. MikaL From owner-zeroconf@merit.edu Mon Feb 24 01:07:55 2003 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 BAA22338 for ; Mon, 24 Feb 2003 01:07:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 58CE491221; Mon, 24 Feb 2003 01:11:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2AB3591223; Mon, 24 Feb 2003 01:11:40 -0500 (EST) 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 269BF91221 for ; Mon, 24 Feb 2003 01:11:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 06EF05DF57; Mon, 24 Feb 2003 01:11:39 -0500 (EST) 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 8F2795DE3A for ; Mon, 24 Feb 2003 01:11:38 -0500 (EST) 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 BAA20930 for ; Mon, 24 Feb 2003 01:11:38 -0500 (EST) 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 BAA10425 for ; Mon, 24 Feb 2003 01:11:37 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id BAA23998 for ; Mon, 24 Feb 2003 01:11:37 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 24 Feb 2003 01:11:35 -0500 Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: 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 02/21/2003 14:07, "Erik Guttman" wrote: >> The aim is to advise the node what is appropriate for it to use on the >> LAN it happens to have been connected to. > > We understand this is your aim. What is the justification for adding > 'LAN policy awareness management' (if there is such a thing) to the > charter of this working group? Just as a point...when I have been teaching seminars on OS X to IT groups, and I talk about Zeroconf/Rendezvous, the *biggest* question is "Where's the off switch in case we need to totally disable it?" Manual turnoffs are needed. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Feb 24 02:15:41 2003 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 CAA03528 for ; Mon, 24 Feb 2003 02:15:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 82E4391227; Mon, 24 Feb 2003 02:19:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F9F39122B; Mon, 24 Feb 2003 02:19:24 -0500 (EST) 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 3B84491227 for ; Mon, 24 Feb 2003 02:17:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1D8645DDF2; Mon, 24 Feb 2003 02:17:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by segue.merit.edu (Postfix) with ESMTP id D0CEE5DDA4 for ; Mon, 24 Feb 2003 02:17:46 -0500 (EST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Sun, 23 Feb 2003 23:17:46 -0800 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 23 Feb 2003 23:17:44 -0800 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 23 Feb 2003 23:17:45 -0800 Received: from WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sun, 23 Feb 2003 23:17:45 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Sun, 23 Feb 2003 23:17:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: LL1, LL23 Date: Sun, 23 Feb 2003 23:17:42 -0800 Message-ID: Thread-Topic: LL1, LL23 thread-index: AcLbKOpBadasxMLKRtaBDdE0EsFZ6QAqh4zA From: "Christian Huitema" To: "Erik Guttman" Cc: X-OriginalArrivalTime: 24 Feb 2003 07:17:44.0089 (UTC) FILETIME=[D317B090:01C2DBD4] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA03528 >> Since leakage hurts the rest of the Internet, the >> robustness principle dictates that we limit the risk >> of LL addresses leaking. This is achieved, by and large, >> by reserving such addresses to ad hoc networks, and by >> not using them on connected networks. Which translate >> in a requirement to select either LL1 or LL23. There >> seems to be a preference for the text of LL23, with >> some revisions. > What specific revisions do you support? I was under the impression that somewhere in the recent exchanges there was some almost consensual wordsmithing of LL23. However, after parsing the thread, I could not find this wordsmithing -- I guess it is a testimony to the S/N ratio of the discussion. My personal vote is to just accept LL23. By the way, regarding the responses to my original message: no, you cannot really rely on the SIP servers to rewrite the addresses. Doing so would break the S-MIME signature of the SIP payload, or would prevent encryption of that payload. Also, SIP is really just an example of a class of applications; several proprietary IM systems and also several "game lobby" enable the same type of exchange. It is true that NAT makes the all thing harder, but it is enough for us to observe that the use of NAT is not mandatory; for example, VoIP is also commonly use within a corporate network, without tracersing the NAT. Also, regarding the concern that legacy hosts contribute to leakage: most legacy hosts, be it Windows or Mac, actually implement a variation of LL23, and try to limit use of IPv4LL to "ad hoc" networks -- which is precisely what we need if we want to reduce leakage. -- Christian Huitema From owner-zeroconf@merit.edu Mon Feb 24 04:04:33 2003 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 EAA05204 for ; Mon, 24 Feb 2003 04:04:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2720C91221; Mon, 24 Feb 2003 04:08:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED40A91227; Mon, 24 Feb 2003 04:08:19 -0500 (EST) 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 DEF7591221 for ; Mon, 24 Feb 2003 04:08:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id C3CB45E1A9; Mon, 24 Feb 2003 04:08:18 -0500 (EST) 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 968F35DFB6 for ; Mon, 24 Feb 2003 04:08:18 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 93F8459988 for ; Mon, 24 Feb 2003 09:08:19 +0000 (GMT) Message-ID: <005801c2dbe4$71963110$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" Subject: LL27 Date: Mon, 24 Feb 2003 09:09:32 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I reject this proposal - its wording is far too draconian. I would consider supporting a proposal which specified a warning requirement for any LL-only device claiming conformance with or referencing the spec. Philip From owner-zeroconf@merit.edu Mon Feb 24 04:12:40 2003 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 EAA05563 for ; Mon, 24 Feb 2003 04:12:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DCC9691227; Mon, 24 Feb 2003 04:16:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3F9A91237; Mon, 24 Feb 2003 04:16:01 -0500 (EST) 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 6AD5491227 for ; Mon, 24 Feb 2003 04:15:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8A3915E1AB; Mon, 24 Feb 2003 04:15:22 -0500 (EST) 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 D9A965DFB6 for ; Mon, 24 Feb 2003 04:15:21 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id D36285998A for ; Mon, 24 Feb 2003 09:15:22 +0000 (GMT) Message-ID: <006201c2dbe5$6ddb2f70$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" Subject: LL1, LL23 Date: Mon, 24 Feb 2003 09:16:35 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I support the principle behind both LL1 and LL23 (this will have been obvious) On final consideration, I prefer LL23 over LL1. Philip From owner-zeroconf@merit.edu Mon Feb 24 04:38:05 2003 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 EAA05999 for ; Mon, 24 Feb 2003 04:38:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4320891237; Mon, 24 Feb 2003 04:41:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0EFE29123B; Mon, 24 Feb 2003 04:41:50 -0500 (EST) 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 1B16891237 for ; Mon, 24 Feb 2003 04:41:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id EFDD05DF78; Mon, 24 Feb 2003 04:41:49 -0500 (EST) 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 C22865DE0F for ; Mon, 24 Feb 2003 04:41:49 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id BA42659985; Mon, 24 Feb 2003 09:41:50 +0000 (GMT) Message-ID: <009e01c2dbe9$204bd9e0$131010ac@aldebaran> From: "Philip Nye" To: "Mika Liljeberg" Cc: "Zeroconf Working Group" References: <6C98F925-46A5-11D7-A12D-00039317663C@nominum.com> <001801c2dab8$49f8b970$131010ac@aldebaran> <3E58A0BD.8080307@sun.com> <001101c2db6a$4871f780$131010ac@aldebaran> <1046033726.3298.130.camel@devil> Subject: Re: LL1, LL23 Date: Mon, 24 Feb 2003 09:43:03 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mika, > The rules I had in mind in an unsolidified form (before LL19 got > rejected) are roughly as follows: Thank you for taking the trouble to give such a complete description of your vision of LL. It helps clear up a lot of misunderstanding. I can see that under the full set of conditions you describe, that it could be made to work. However, I don't find all these conditions acceptable or even achievable. Firstly, I think interoperation with the vast number of Mac and Windos hosts running their own form of LL is important. Secondly, I think that your solution relies too heavily on making a lot of application level software LL aware. In particular with respect to rule e), service discovery protocols are numerous (many of them in little niches), are already deployed, and are not generally a part of the OS. Therefore you are effectively imposing a requirement to rewrite and update all of them. Since last call for these issues is in and I have placed my vote, I will now shut up on these issues on the list. regards, Philip From owner-zeroconf@merit.edu Mon Feb 24 05:05:17 2003 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 FAA06694 for ; Mon, 24 Feb 2003 05:05:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B38FC91227; Mon, 24 Feb 2003 05:09:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7946E91237; Mon, 24 Feb 2003 05:09:03 -0500 (EST) 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 7120B91227 for ; Mon, 24 Feb 2003 05:09:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 53A525DFC5; Mon, 24 Feb 2003 05:09:02 -0500 (EST) 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 25B925DE0F for ; Mon, 24 Feb 2003 05:09:02 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 529445998F; Mon, 24 Feb 2003 10:09:03 +0000 (GMT) Message-ID: <011801c2dbec$ed574700$131010ac@aldebaran> From: "Philip Nye" To: , "Ralph Droms" References: <4.3.2.7.2.20030221093548.03ebaac8@funnel.cisco.com> Subject: OT DHCP Date: Mon, 24 Feb 2003 10:10:15 -0000 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 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Ralph Droms" > > If it would be useful to allow a server to respond with a DHCPNAK to a > DHCPDISCOVER, we can certainly explore the idea in the dhc WG. I think that this would be useful. A variation would be to formalise the message DHCPOFFER with yiaddr=0.0.0.0 to mean "I'm here but I'm not giving you an address" which would I suppose allow a subsequent DHCPREQUEST to then return an DHCPNAK with a message. This is off topic for this list but somewhat relevant. I won't pursue it further here, but I don't have the energy at the moment to join the DHC WG. Philip From owner-zeroconf@merit.edu Mon Feb 24 08:02:46 2003 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 IAA13172 for ; Mon, 24 Feb 2003 08:02:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 271829122E; Mon, 24 Feb 2003 08:06:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED2FF9123B; Mon, 24 Feb 2003 08:06:30 -0500 (EST) 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 F12859122E for ; Mon, 24 Feb 2003 08:06:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id D62065E1A9; Mon, 24 Feb 2003 08:06:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 5486B5E180 for ; Mon, 24 Feb 2003 08:06:29 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21744; Mon, 24 Feb 2003 05:06:24 -0800 (PST) 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 h1OD6Ll17339; Mon, 24 Feb 2003 14:06:21 +0100 (MET) Date: Mon, 24 Feb 2003 14:06:22 +0100 (MET) From: Erik Guttman X-Sender: erikg@sr-ehdb03-01 Reply-To: Erik Guttman To: Keith Moore Cc: Erik Guttman , mika.liljeberg@welho.com, Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 In-Reply-To: <20030223075049.625959d0.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Sun, 23 Feb 2003, Keith Moore wrote: > Date: Sun, 23 Feb 2003 07:50:49 -0500 > From: Keith Moore > To: Erik Guttman > Cc: moore@cs.utk.edu, mika.liljeberg@welho.com, Ted.Lemon@nominum.com, > msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com > Subject: Re: LL1, LL23 > > > > I would like to supply such examples. But I doubt I'll have time to > > > investigate and write them up in detail within the next several days. > > > > It is in no way unfair to say that this process must come to an > > end - soon - and that we have all had months to gather evidence > > for our arguments and innumerable calls for concrete examples > > of applications which fail due to link-local. > > Such concrete examples have been given more times than I can count. > (or at least, I'm not willing to cull through the archives to do so) > > Of course, responding to posts to this list only takes minutes per post, while > providing detailed analysis of failures for applications takes several hours > of focused work per application. Actually testing the apps for failures under > controlled conditions takes a lot of time also. It's much harder to find > those chunks of time, and given past experience with an attempt to provide > detailed analysis it's hard to believe that such an investment is worthwhile. > > That and I object to the entire line of argument. It's not unreasonable to > want examples of things that break, but those have been given. It is > unreasonable to dismiss those examples out-of-hand because there is a fix for > one specific app, or because an app doesn't fail under one artifical set of > conditions that you specify, and then claim that there's no general problem. Concrete examples have to be given here or pointed to in the mailing list in order to weigh as evidence of a problem. We have a document which has gone through WG and IETF last call multiple times. There were objections that the WG had not considered problems. It is in no way inappropriate to demand specific examples. Erik From owner-zeroconf@merit.edu Mon Feb 24 08:05:36 2003 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 IAA13324 for ; Mon, 24 Feb 2003 08:05:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 676309123B; Mon, 24 Feb 2003 08:09:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 395709123D; Mon, 24 Feb 2003 08:09:22 -0500 (EST) 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 1CD449123B for ; Mon, 24 Feb 2003 08:09:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id F3BC95E10A; Mon, 24 Feb 2003 08:09:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by segue.merit.edu (Postfix) with ESMTP id C9CAF5E106 for ; Mon, 24 Feb 2003 08:09:20 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18nIM2-0003Om-00; Mon, 24 Feb 2003 05:09:11 -0800 Date: Mon, 24 Feb 2003 08:06:18 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, erik.guttman@sun.com, mika.liljeberg@welho.com, Ted.Lemon@nominum.com, msa@burp.tkv.asdf.org, zeroconf@merit.edu, philip@engarts.com Subject: Re: LL1, LL23 Message-Id: <20030224080618.29c2d213.moore@cs.utk.edu> In-Reply-To: References: <20030223075049.625959d0.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.10 (GTK+ 1.2.10; i386--netbsdelf) 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 > Concrete examples have to be given here or pointed to in the mailing > list in order to weigh as evidence of a problem. We have a document > which has gone through WG and IETF last call multiple times. There were > objections that the WG had not considered problems. It is in no way > inappropriate to demand specific examples. it's not inappropriate to demand specific examples, but these have been given. it is inappropriate to try to disregard the general problem by saying that there are workarounds for those specific examples, or that they don't fail in every case. From owner-zeroconf@merit.edu Mon Feb 24 13:16:20 2003 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 NAA21382 for ; Mon, 24 Feb 2003 13:16:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5DDE291233; Mon, 24 Feb 2003 13:20:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2DBBD91239; Mon, 24 Feb 2003 13:20:05 -0500 (EST) 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 1148791233 for ; Mon, 24 Feb 2003 13:20:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id F01535DED7; Mon, 24 Feb 2003 13:20:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 352D45DE5B for ; Mon, 24 Feb 2003 13:20:03 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1OIKiaj013136; Mon, 24 Feb 2003 20:20:44 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1OIKhuC013134; Mon, 24 Feb 2003 20:20:43 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: LL1, LL23 From: Mika Liljeberg To: Philip Nye Cc: Zeroconf Working Group In-Reply-To: <009e01c2dbe9$204bd9e0$131010ac@aldebaran> References: <6C98F925-46A5-11D7-A12D-00039317663C@nominum.com> <001801c2dab8$49f8b970$131010ac@aldebaran> <3E58A0BD.8080307@sun.com> <001101c2db6a$4871f780$131010ac@aldebaran> <1046033726.3298.130.camel@devil> <009e01c2dbe9$204bd9e0$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046110842.6104.34.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Feb 2003 20:20:42 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-02-24 at 11:43, Philip Nye wrote: > Mika, > > > The rules I had in mind in an unsolidified form (before LL19 got > > rejected) are roughly as follows: > > Thank you for taking the trouble to give such a complete description of your > vision of LL. It helps clear up a lot of misunderstanding. > > I can see that under the full set of conditions you describe, that it could > be made to work. > > However, I don't find all these conditions acceptable or even achievable. > Firstly, I think interoperation with the vast number of Mac and Windos hosts > running their own form of LL is important. Interoperability would not be a problem, since a host following my model would have both addresses and would just use the appropriate one to communicate with a Mac or a Windows system regardless of its current mode of operation. > Secondly, I think that your solution relies too heavily on making a lot of > application level software LL aware. Not really. The key control points are the APIs on a compliant node. Those should protect legacy applications from making any typical mistakes. This is a good practise to adopt regardless of whether LL23 is accepted or not. > In particular with respect to rule e), > service discovery protocols are numerous (many of them in little niches), > are already deployed, and are not generally a part of the OS. Therefore you > are effectively imposing a requirement to rewrite and update all of them. As Erik pointed out, the service discovery mechanisms are not yet that widely used. I don't think it would be a huge problem in practise. The LL23 approach is not exactly leak proof either. > Since last call for these issues is in and I have placed my vote, I will now > shut up on these issues on the list. I respect your choice, but I feel that adopting LL23 is clearly an implementation decision and should not be mandated for every OS. It may be a good approach for Windows and Macos, but on another type of device (e.g. with a more controlled set of applications) it might be more appropriate to have both LL and routable addresses active. Rejecting L23 does not preclude OS vendors from implementing it, if they consider it justified. MikaL From owner-zeroconf@merit.edu Mon Feb 24 14:21:52 2003 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 OAA23336 for ; Mon, 24 Feb 2003 14:21:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3534391239; Mon, 24 Feb 2003 14:25:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F11679123F; Mon, 24 Feb 2003 14:25:37 -0500 (EST) 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 D6AD391239 for ; Mon, 24 Feb 2003 14:25:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id BDBF25DFF6; Mon, 24 Feb 2003 14:25:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id C6C945DFBD for ; Mon, 24 Feb 2003 14:25:35 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1OJQIaj013532 for ; Mon, 24 Feb 2003 21:26:18 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1OJQHk7013530 for zeroconf@merit.edu; Mon, 24 Feb 2003 21:26:17 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: My positions on LL1, LL2, LL23 and LL27 From: Mika Liljeberg To: zeroconf@merit.edu Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046114776.13213.56.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 24 Feb 2003 21:26:17 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit LL1 and LL23 - REJECT I reject the issue cited by LL1/LL23. I stated my initial position in http://www.merit.edu/mail.archives/zeroconf/2003-02/msg00425.html and recent discussion has only served to reaffirm my opinion. I feel that adopting LL23 should be left as an implementation decision. The approach of having both LL+routable address on a node is not incompatible with the approach of switching between the two. Nodes following these two approaches can coexist in a network. The choice of implementation approach should be left to the OS vendor. Heated arguments have been tossed back and forth, however real proof of the technical merits of these proposals has been in very short supply. Some real problems in the mechanism of switching between LL and configured addresses, however, have been pointed out. This is clearly a case were more real deployment exprience is needed. Since rejecting LL23 does not preclude an implementation, it is not necessary to modify the specification. I also detest the dependency this would create between v4LL and the DHCP specification. LL2 - REJECT I reject the change as stated. It is not feasible to use DHCP as a policy re-enforcement mechanism and it is not for this WG to try. See also: http://www.merit.edu/mail.archives/zeroconf/2003-02/msg00415.html I will agree, however, to a manual configuration mechanism to disable LL. LL27 - REJECT I compared this proposal to the charter and found *nothing* in common. Ruling isolated systems out of IETF scope is simply stupid. Supporting link-layer independent reusable mechanisms is always the right thing to. I've seen enough non-standard stove pipe solutions to last me a lifetime. Regards, MikaL From owner-zeroconf@merit.edu Mon Feb 24 17:16:48 2003 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 RAA28460 for ; Mon, 24 Feb 2003 17:16:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7B9E89122E; Mon, 24 Feb 2003 17:20:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B74291233; Mon, 24 Feb 2003 17:20:35 -0500 (EST) 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 5DBC49122E for ; Mon, 24 Feb 2003 17:20:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 363CB5E1C0; Mon, 24 Feb 2003 17:20:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id BA4575E1AF for ; Mon, 24 Feb 2003 17:20:33 -0500 (EST) Received: from nominum.com (az-ben-pm3-2-13.ppp.theriver.com [206.25.50.13]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1OMHBN17697; Mon, 24 Feb 2003 16:17:11 -0600 (CST) Date: Mon, 24 Feb 2003 15:20:33 -0700 Subject: Re: My positions on LL1, LL2, LL23 and LL27 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Mika Liljeberg From: Ted Lemon In-Reply-To: <1046114776.13213.56.camel@devil> Message-Id: <30BD188E-4846-11D7-8498-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I concur with Mika on all of these items - they should all be rejected. From owner-zeroconf@merit.edu Tue Feb 25 05:52:26 2003 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 FAA22974 for ; Tue, 25 Feb 2003 05:52:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 12D739120D; Tue, 25 Feb 2003 05:56:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8A3D91222; Tue, 25 Feb 2003 05:56:11 -0500 (EST) 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 B040B9120D for ; Tue, 25 Feb 2003 05:56:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 97AE15DDCE; Tue, 25 Feb 2003 05:56:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 5F5735DDC7 for ; Tue, 25 Feb 2003 05:56:05 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1PAtjd27115; Tue, 25 Feb 2003 17:55:51 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1PAtUo23747; Tue, 25 Feb 2003 17:55:30 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL In-Reply-To: <3E58B2FF.6040303@sun.com> References: <3E58B2FF.6040303@sun.com> <99984944-45BF-11D7-A12D-00039317663C@nominum.com> <11264.1045992468@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Feb 2003 17:55:30 +0700 Message-ID: <23745.1046170530@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 23 Feb 2003 12:39:43 +0100 From: Erik Guttman Message-ID: <3E58B2FF.6040303@sun.com> | What is your argument? It certainly isn't what you seem to believe it is. | An administrator can't do this today. Even though hosts | have been doing autoconfiguring on LANs for the past 5 years, I suspect that many sites don't realise that LL addresses are being configured - nodes that configure them tend to "not work" just the same as nodes that have no addresses. I had someone ask me a couple of months ago why they were unable to fetch their e-mail - turns out that the problem was that the DHCP server had died for some reason or other, and the system concerned had configured itself with a LL address, and as far as it was concerned, everything was fine. To the user, the system had an IP address (numeric values of IP addresses mean little to most people, and 169.254 is actually close enough to the address it should have had that there was nothing "obviously" wrong). Now this was a laptop (or desktop, I forget) and so looking into it was no great problem - and it was fairly obviously not working, so having a LL address wasn't doing it any real harm (it certainly wasn't doing it any good though). Where there start to be problems is when we have devices that don't have fairly comprehensive user interfaces - that is, where looking from the outside to see what is going on inside is difficult. Such a device can't treat obtaining a LL address as a failure, as in isolated networks (zeroconf nets) that's what is supposed to happen. On the other hand, in a managed network, getting a LL address is failure, and the device really needs to be able to report, however it is able to, that it is inoperable. For example, where I work in Melb (which isn't where I am now) there's a LAN to which all printers, and aside from the router(s) absolutely nothing else is connected. Printers get addresses using DHCP. If a new printer is connected, and the DHCP server doesn't give it an address (fixed addresses are assigned, as there needs to be a known relationship between the printer and its location - which is the only distinguishing feature between many of the printers - yet people want to print to one specific printer, not one on another floor at the other end of the building) then it is easy currently to detect that, and discover why no-one is able to print anything on the printer (showing 0.0.0.0 as the IP address is a dead give-away, to any tech or tech assistant). On the other hand, getting 169.254.xxx.yyy makes the printer look as if everything is working - do you really expect the kind of person who takes a job whose job description is "make sure the printers all have paper in the paper trays, and that toner hasn't run out" to understand that 169.254.xxx.yyy is materially different from 169.245.xxx.yyy ? As far as the printer is concerned, it is functioning fine on a zeorconf lan - so it can't provide any kind of "network config failure" message for assistance. Maybe the reason that there aren't more problems like this is that so-far the only place LL addresses are used are in workstation type devices, where the difference between working and not working tends to be obvious (they tend to initiate connections, rather than passively waiting for someone to talk). | The argument was: We paid for the wires in the dorms. This is an access control argument. It is bogus, and shooting it down one more time gets us no-where. Clearly anyone who wants to specifically configure their system to avoid a DHCP hint can do so, trivially easily. Once again, the aim is to advise hosts that actually want to know whether or not they should bother using LL addresses, whether using one is productive or not. This should be all hosts (subject to user override of course, just like everything else), as the host, without configuration, can't possibly know whether using LL addresses is going to be useful in the environment it finds itself or not. It is *NOT* to control access to the LAN. Nor does this have anything at all to do with simplicity or reliability or anything else like that (in the sense of whether or not having multiple addresses is worthwhile) - that is all being considered under other issues. kre From owner-zeroconf@merit.edu Tue Feb 25 06:15:41 2003 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 GAA23497 for ; Tue, 25 Feb 2003 06:15:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D87E291222; Tue, 25 Feb 2003 06:19:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A61591251; Tue, 25 Feb 2003 06:19:12 -0500 (EST) 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 BF27391222 for ; Tue, 25 Feb 2003 06:17:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id A01265E05D; Tue, 25 Feb 2003 06:17:33 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id DECE55DE5A for ; Tue, 25 Feb 2003 06:17:31 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1PBHRd10907; Tue, 25 Feb 2003 18:17:28 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1PBGIo23782; Tue, 25 Feb 2003 18:16:19 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Oppose: LL2 DHCP Mechanism to disable v4 LL In-Reply-To: <200302232200.h1NM0bQ12411@scv2.apple.com> References: <200302232200.h1NM0bQ12411@scv2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Feb 2003 18:16:18 +0700 Message-ID: <23780.1046171778@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 23 Feb 2003 14:00:40 -0800 From: Stuart Cheshire Message-ID: <200302232200.h1NM0bQ12411@scv2.apple.com> | I strongly oppose requiring the host to implement a DHCP Mechanism to | disable v4 LL. That isn't what LL2 says, unless the host is using DHCP to configure itself anyway (which is optional). | This makes it too easy for greedy ISPs (like the now-bankrupt @Home, | whose name appears at the top of never-implemented-by-anyone RFC 2563) to | exert unjustified control over what the customer may do on their own | Ethernet network in their own home. Not true. If you have your hosts using "greedy ISP's" DHCP servers to obtain addresses, then they can easily control your net without any need to deny you LL addresses. If your ISP is going to send you bogus DHCP answers, don't use their DHCP server (or certainly don't use it for devices where you don't want their answers). | If you want to deny a host access to the network, I don't, and never did (or not this way). | They just encourage people to continue using AppleTalk. Why would that be a problem? (assuming that denying access to the net was the aim, and that was to be done by un-configuring IP) | If you want to deny a host access to the | network, then 802.1X gives you the control you want, and blocks ALL | protocols. Yes, I know, and already do that. But that doesn't achieve the objective - for some hosts, what I might actually want to accomplish is to disable IP in the node, and have it use appletalk instead. Why not? But ... cheshire@apple.com said: | Since an ARP-based denial-of-service attack is possible anyway by another | device on the same physical link, it makes sense to standardize this, | instead of having different vendors each invent their own different | denial-of-service attack to shut down IPv4LL. There is no need to standardise that, if the aim is just to shut off v4LL, doing so using ARP responses is trivial. There's no particular reason for everyone to have to do it the same way. If the node is going to be effectively dead anyway, however that happened, it should go ahead and keep on trying to obtain an address - the current draft says so anyway (keep trying, at a somewhat reduced rate, to avoid net overload). Adding a standard method to do this adds nothing useful at all. But it is good to see you admit that the techniques exist (to shut down LL usage) and cannot be avoided (which writes off Ted's argument against LL2 which basically said that nodes should always be able to get LL2 addresses in case the rest of their config is bogus - then they can still be managed). Clearly it is trivially possible if anyone wants to prevent a node getting a LL address. What we seem to have come down to now, is not a discussion of whether or not there should be such a mechanism, but which particular mechanism it should be. LL2 only says 2563 in the case of nodes using DHCP already (and I personally don't care if it is 2563 or some other DHCP mechanism, so if someone really wants to object to 2563 because its author worked for what some believe was a "greedy ISP", then fine, some other method would do). But I see no rational reason at all to make life difficult for administrators of large nets, by requiring them to connect nodes directly to all LANS, just so they can disable LL there when that's what should be done. That makes no sense - it is possible, but it is an administrative nightmare. Now the LAN I described in my recent reply to Erik, which has only printers connected, also needs a workstation (or similar) that can answer ARP requests - but being connected, now I also need to be able to get to iit to manage it. That means either I have to allow all kinds of protocols through the filters in the router which wouldn't be necessary for printers, or this system needs to have connectivity via some other interface. If the latter, then I now have two access paths to the printers that have to be controlled, one via the router, and another via the workstation. And all of this because you don't like the possibility that someone to whom you have abrogated control of your nodes (by using their DHCP server to configure them) will actually make use of that control in a way that you don't like? No thanks. If the control is to exist at all (and it certainly does exist) let's have it in a mechanism that is reasonable to actually operate. kre From owner-zeroconf@merit.edu Tue Feb 25 06:38:21 2003 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 GAA23998 for ; Tue, 25 Feb 2003 06:38:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5BB5E91225; Tue, 25 Feb 2003 06:42:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D9359124F; Tue, 25 Feb 2003 06:42:06 -0500 (EST) 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 1537891225 for ; Tue, 25 Feb 2003 06:42:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id ED44F5E1E5; Tue, 25 Feb 2003 06:42:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 297375DE5A for ; Tue, 25 Feb 2003 06:42:03 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1PBfrd27560; Tue, 25 Feb 2003 18:41:54 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1PBfco23831; Tue, 25 Feb 2003 18:41:39 +0700 (ICT) From: Robert Elz To: Ted Lemon Cc: zeroconf@merit.edu Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL [LL2,LL1,LL23] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Feb 2003 18:41:38 +0700 Message-ID: <23829.1046173298@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 23 Feb 2003 10:25:55 -0700 From: Ted Lemon Message-ID: | > Others seem to see LL addressing as solving some other problem, | > allowing | > access to nodes which have been mis-configured, and all kinds of other | > exotic possibilities like that. | | The example that I described, where two people meet over lunch with | laptops that got DHCP addresses at their respective work locations is | not a misconfiguration. No, but nor did anyone suggest that LL addresses shouldn't be used there. | Can you point to a place in RFC2131 where it | says anything other than that the two devices are doing exactly the | right thing? 3.7 When clients should use DHCP A client SHOULD use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed; e.g., at system boot time or after a disconnection from the local network, as the local network configuration may change without the client's or user's knowledge. If that isn't clear enough, then perhaps 2131 should be revised. But this is not the place to do that. Now, assuming that the friends who meet over lunch didn't carry their DHCP server along with them (if they did, it can just assign them all addresses, right?) then they're not going to get a response when they attempt to reacquire their network parameters, as required above. When that happens, the first thing to note is that this clearly has nothing at all to do with LL2, as in this scenario, there clearly isn't going to be anything telling the nodes not to use LL addresses. So, the nodes are quite at liberty to configure their LL addresses when this happens (DHCP config having failed). What's the issue supposed to be? 3.7 of 2131 goes on to say that the node may (not even MAY) continue to use its lease until it expires, if it wants to, it doesn't say that it is required to. Personally, I think I'd do what the ISC client does (your code, I believe) and attempt to determine if some previous (existing) lease is valid or not. If it looks as if the previous address works, then go ahead, use it. But don't just use it because it was the address I used 5 minutes ago, unless I cannot get any other address at all (but in this scenario I can, right - I can get an LL address). Now if it happens that the friends meeting over lunch all had previously been assigned 192.168.1.x addresses, and there's still something answering at 192.168.1.1 (very likely intended to be the default router) then they may end up all believing that they're still on their home nets, and keep on using their home addresses. So? They're all still able to communicate. If two of them happen to clash, then they'll know they have a problem with their addresses, and being unable to get new ones, will go ahead and assign LL addresses. If one (or more) of the friends had a 172.16.x.y address, then it is almost certain that it isn't going to find its router, or something pretending to be it (after all, we're assuming something has answered at 192.168.1.1) - so they're going to detect that their routable addresses don't work, and configure LL addresses. What's more, since LL19 was rejected, we are requiring that nodes with routable addresses be able to communicate with nodes that happen to have only LL addresses, so everyone is able to communicate (with each other), right? Of course, it is possible to dream up some unlikely scenarios where this might fail (nodes just happening to have addresses on their home links that are the magic "test for working" address on someone else's link), so everyone believes they are still at home, but with diverse addresses. Personally I think the chances of that are so tiny that it isn't worth worrying about - and in any case, it certainly has nothing to do with LL2. | And yet they have incorrect configurations. So you | can't argue that it's not useful to handle this case in IPv4ll. No, and I don't want to. Ad-hoc networks are the primary example of why zeroconf (LL addresses) are useful in the first place. But all of this has nothing to do with LL2 at all (clearly) - its only relationship would seem to be with LL23 (or LL1). And for the argument to carry much weight there, you have to assume that the implementation was done by someone with no clue as to what might happen, and no interest in actually making it work correctly. | You | *can* argue that it's not useful *enough* to justify the cost, but your | argument that it's not useful is not valid. No, the argument quoted above (which was in the context of LL2) related to the suggestion that LL2 should not be allowed, because it enables people to disable LL addressing in a node which is otherwise misconfigured, and so cannot be reached. Clearly that cannot be on a zeroconf (ad-hoc) LAN, as the fiends at lunch is assumed to be, as there there's is nothing to give the LL2 type advice. kre From owner-zeroconf@merit.edu Tue Feb 25 07:03:55 2003 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 HAA26236 for ; Tue, 25 Feb 2003 07:03:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6E4D291228; Tue, 25 Feb 2003 07:07:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A5069122A; Tue, 25 Feb 2003 07:07:39 -0500 (EST) 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 3E27491228 for ; Tue, 25 Feb 2003 07:07:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 172405E1E9; Tue, 25 Feb 2003 07:07:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 53D725E1E7 for ; Tue, 25 Feb 2003 07:07:36 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1PC7Vd13011; Tue, 25 Feb 2003 19:07:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1PC7Do24430; Tue, 25 Feb 2003 19:07:13 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: ACCEPT [LL17] Hosts with configured addresses MUST ARP for v4 LL addresses In-Reply-To: <200302232158.h1NLwnQ12086@scv2.apple.com> References: <200302232158.h1NLwnQ12086@scv2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Feb 2003 19:07:13 +0700 Message-ID: <24428.1046174833@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 23 Feb 2003 13:58:52 -0800 From: Stuart Cheshire Message-ID: <200302232158.h1NLwnQ12086@scv2.apple.com> | >you cannot require ARP, because not all link levels use it. | >The wording needs to be in such a way that specific link level | >technologies are not implied. | | Excuse me for stating the obvious: | | 1.2. Applicability | | The specifications in this document apply to any IEEE 802 media [802] | including Ethernet [802.3], and other similar link-layer network | technologies that operate at data rates of at least 1Mb/s, have a | round-trip latency of at most one second, and support ARP [RFC 826]. | | Link-layer network technologies that do not support ARP may be able | to use other techniques for determining whether a particular IP | address is currently in use. However, the application of claim-and- | defend mechanisms to such networks is left to a future document. | | Any questions? Yes. The second of those paragraphs implies, strongly, that non-ARP networks can use LL addresses, and says that how the claim-and-defend mechanism will operate there will be defined someplace else, some other time, when it is needed. That's all fine. However, this also suggests that the rest of the rules for using LL addresses, even on non-ARP networks, are specified in this document. That's good, because this, unless we were to split it into two docs, one for LL in general, and one for LL on ARPable nets, is where it should be. There's no reason for them not to be, after all, you wouldn't want the doc for using LL on X.25 (or ATM without LANE, or something) telling hosts that they should send packets using LL addresses to a router to be forwarded (especially as there's no way to know if the router understands LL or not). This is actually another issue, that I sent to the list back on Feb 13, but which Erik hasn't been able to find the time to add to the web page yet (I assume it will become LL28 eventually). Look for a message from me, on Feb 13, with the msgid <4413.1045133363@munnari.OZ.AU> and Subject: New Issue: Applicability of Document It proposes adding new text to the first para of section 1.2 to clarify this issue, and make it clear that (aside from address acquisition and defence, that is ARP issues) the rest of the specification of LL addresses is in this doc, for all network types. But the time to discuss that is sometime after the issue gets posted, and we start on it, rather than now. kre From owner-zeroconf@merit.edu Tue Feb 25 07:07:23 2003 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 HAA26558 for ; Tue, 25 Feb 2003 07:07:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 556CE9122A; Tue, 25 Feb 2003 07:11:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2342D91251; Tue, 25 Feb 2003 07:11:09 -0500 (EST) 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 254AF9122A for ; Tue, 25 Feb 2003 07:11:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 077365E1E7; Tue, 25 Feb 2003 07:11:08 -0500 (EST) 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 7E0D55DECC for ; Tue, 25 Feb 2003 07:11:07 -0500 (EST) 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 FAA25733 for ; Tue, 25 Feb 2003 05:11:06 -0700 (MST) 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 h1PCB3l08796 for ; Tue, 25 Feb 2003 13:11:03 +0100 (MET) Date: Tue, 25 Feb 2003 13:11:02 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: End of WG last call for LL1, LL2, LL23, LL27 - please await results In-Reply-To: <23829.1046173298@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Please hold further discussion of these issues. We have all had an opportunity to air our views on this. I now need to work on a consensus call and issue a new set of last call issues. Thanks and regards, Erik From owner-zeroconf@merit.edu Tue Feb 25 07:19:43 2003 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 HAA26922 for ; Tue, 25 Feb 2003 07:19:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8C5E091258; Tue, 25 Feb 2003 07:23:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C0689125A; Tue, 25 Feb 2003 07:23:29 -0500 (EST) 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 43DB191258 for ; Tue, 25 Feb 2003 07:23:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D02D5E1E9; Tue, 25 Feb 2003 07:23:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 91D135DECC for ; Tue, 25 Feb 2003 07:23:22 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1PCNJd20232; Tue, 25 Feb 2003 19:23:20 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1PCN8o24455; Tue, 25 Feb 2003 19:23:08 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Oppose: LL1 Preferred use of configured to v4 LL address In-Reply-To: <200302232200.h1NM0Sf12308@scv3.apple.com> References: <200302232200.h1NM0Sf12308@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Feb 2003 19:23:08 +0700 Message-ID: <24453.1046175788@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 23 Feb 2003 14:00:30 -0800 From: Stuart Cheshire Message-ID: <200302232200.h1NM0Sf12308@scv3.apple.com> | 1. How does the host know what address is truly global? LL1 is badly worded. It means "routable" in the same sense that is used in the document (where I would actually prefer to say "non-link-local" in all uses for extra clarity, as routable suggests other things in many minds). But this just amounts to definitions of terms, and isn't very important. I'd reject LL1 just because (IMNSHO) LL23 achieves the same objective, better. | 2. What about stale DHCP addresses, or manually configured addresses that | are just plain wrong? My opinion is that a node with a "wrong" address has no address, and can go on to assign a LL address (unless LL2 mechanisms tell it not to). | People have said that it is outside the charter of | this Working Group to try to make devices that work reliably even in the | face of accidental misconfiguration. That may be true, but developing | devices that work reliably even in the face of accidental | misconfiguration is a high priority for Apple, and most of the consumer | electronics companies adding networking to their home Hi-Fi equipment. | This Working Group should give at least some small consideration to those | companies. That's fine, I wouldn't like to do anything that makes this impossible. But for me, home Hi-Fi equipment that doesn't work (fully) using routable addresses (in the sense defined in the draft) is plain useless. That said, I also accept the responsibility that if I arrange to configure addresses for that equipment, it is my job to get it correct. I do not want the nodes attempting to outsmart me. If they are misconfigured, I want them to fail, so I can easily detect that they are misconfigured. I don't want them ignoring me, and going on and doing their own thing anyway, seemingly working. When that happens I end up with a half-functional network, which makes it truly difficult to discover that I made a stupid typo in some configuration. If the device simply failed to work as soon as I configured it, then I'd have a pretty good chance of realising that I was the cause, and so fix my error. In your more average house though, there is likely to be nothing doing any configuration, LL gets used, and everyone is happy. If there is any config happening, then it is most likely from one of those "turn me on and I do DHCP" boxes that are common these days, which are basically designed to never give out bad information (they tend to have very little config info that the user can play about with, they just give addresses in the same (1918 usually) range to anyone who asks). | Possibly it may make sense to attempt a connection first using the | routable address first, and then, if that fails, after a short interval | (half second?) try with the LL address as well. The question here might be, how did you discover the peer's address in the first place? Does it have a LL address or a routable one, and which was advertised to you? If you contact it using its LL address, then it knows that you are on link, and can (must) reply to you directly (if it is LL aware, if it isn't, all of this is irrelevant anyway). If you (attempt to) contact it using its routable address, then how do you tell the difference between its config being incorrect, and yours? You might be sending to some bogus location in each case. Trying again using a LL source address doesn't help. kre From owner-zeroconf@merit.edu Tue Feb 25 07:30:27 2003 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 HAA27468 for ; Tue, 25 Feb 2003 07:30:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8FCCF91201; Tue, 25 Feb 2003 07:34:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 202C09125D; Tue, 25 Feb 2003 07:34:10 -0500 (EST) 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 6AE7291201 for ; Tue, 25 Feb 2003 07:32:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4318F5DEB0; Tue, 25 Feb 2003 07:32:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 658595DE08 for ; Tue, 25 Feb 2003 07:32:05 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1PCVmd23586; Tue, 25 Feb 2003 19:31:49 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1PCVTo24474; Tue, 25 Feb 2003 19:31:29 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Oppose: LL27 LL-only hosts are out of scope for this specification In-Reply-To: <200302232202.h1NM2mQ12937@scv2.apple.com> References: <200302232202.h1NM2mQ12937@scv2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Feb 2003 19:31:29 +0700 Message-ID: <24472.1046176289@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 23 Feb 2003 14:02:51 -0800 From: Stuart Cheshire Message-ID: <200302232202.h1NM2mQ12937@scv2.apple.com> | This is true, and this capability of IP is a great benefit. However, | everyone is not obliged to use every capability of IP. My BMW is capable | of driving at 150MPH. It is nice to know it can do that, but is every | owner of a BMW obliged to drive it at 150MPH every time they use it? It's | still a good car at 65MPH too. This is actually the essence of this issue, I believe. But not in the way you expect I think. The answer to the embedded question is, of course, no - but the analogy does not hold to LL27 - nothing there is requiring all nodes to use routable addresses all the time, just to be able to. A better question would be would it be acceptable for a standard for car designed to operate on freeways to suggest that cars that cannot be driven faster than 100km/hr (that's close enough to the obsolete units used above) should comply? Nothing stops people building bicycles, nor others from using them. They don't (usually) manage 100km/hr, but nor do they claim to be freeway compatible cars. Even though they still have many things in common (wheels, lights, their purpose in getting people from one place to another). I might never drive faster than 100 (well, if you knew me, you'd know that's not very likely accurate, but never mind) but I certainly expect my vehicle to be able to do that, should I need it to. Even if I usually only drive around local neighbourhoods at much lower speeds even than 100. kre From owner-zeroconf@merit.edu Tue Feb 25 07:39:25 2003 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 HAA27928 for ; Tue, 25 Feb 2003 07:39:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DB09F9125F; Tue, 25 Feb 2003 07:43:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A09AB91269; Tue, 25 Feb 2003 07:43:10 -0500 (EST) 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 A6D279125F for ; Tue, 25 Feb 2003 07:43:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 82C1B5E1F0; Tue, 25 Feb 2003 07:43:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id D21C35DE5A for ; Tue, 25 Feb 2003 07:43:07 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1PCh2d28005; Tue, 25 Feb 2003 19:43:03 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1PCgro24496; Tue, 25 Feb 2003 19:42:53 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: LL27 LL-only hosts In-Reply-To: <200302232158.h1NLwPf11987@scv3.apple.com> References: <200302232158.h1NLwPf11987@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Feb 2003 19:42:53 +0700 Message-ID: <24494.1046176973@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 23 Feb 2003 13:58:27 -0800 From: Stuart Cheshire Message-ID: <200302232158.h1NLwPf11987@scv3.apple.com> | How can we say that a ZERO CONFIGURATION device "SHOULD require manual | configuration"? Only where no automated config is being done. | What about tiny devices where the ONLY interface to them is through the | network? They do DHCP (or perhaps RARP, or something in weird cases). kre From owner-zeroconf@merit.edu Tue Feb 25 08:00:58 2003 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 IAA29389 for ; Tue, 25 Feb 2003 08:00:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4965C9122D; Tue, 25 Feb 2003 08:04:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F14E91269; Tue, 25 Feb 2003 08:04:43 -0500 (EST) 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 CF00C9122D for ; Tue, 25 Feb 2003 08:04:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id B3D2D5DE08; Tue, 25 Feb 2003 08:04:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id E9DFA5DDD5 for ; Tue, 25 Feb 2003 08:04:39 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1PD4Yd05560; Tue, 25 Feb 2003 20:04:37 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1PD4Lo24527; Tue, 25 Feb 2003 20:04:23 +0700 (ICT) From: Robert Elz To: Ted Lemon Cc: Erik Guttman , Zeroconf Working Group Subject: Re: LL1, LL23 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 25 Feb 2003 20:04:21 +0700 Message-ID: <24525.1046178261@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 23 Feb 2003 11:15:15 -0700 From: Ted Lemon Message-ID: | What LL1/LL23 do is to create an interdependency between IPv4ll and | DHCP that is sufficiently strong that we would have to say that this | draft now updates RFC2131. This is certainly not the case with LL23. LL23 just talks about having a routable address, how that address is obtained is not considered. It may be via DHCP, in which case what DHCP considers to be assigning a routable address is for DHCP to define (receiving an ACK to a REQUEST would usually be that I think, and not getting any answer at all from a DHCP server, would be not getting an address). What's important is that the node tries to obtain a routable address. Having tried, and failed, then go ahead, and use the LL address. I'm even not adverse to having something which says that if the routable address seems to fail (and the node hasn't been explicitly configured not to use LL) then it should attempt to renew its routable address using whatever means exist (there are none for a manually configured address of course), and if that fails, then go ahead and configure LL. The mechanisms by which a node discovers that an address it has been assigned is no longer working are really outside the scope of this WG, and what's more, I see no need to standardise them at all. Different nodes can do this in their own ways. Further, nothing in this requires any changes to 2131, which does not require nodes to keep on using assigned addresses until the lease runs out, or not even until the initial renewal timer goes off. A node can decide to renew its address any time it feels inclined to do so. If that fails, then it has many options - including just continuing to use the address while it tries more agressively to renew, but if coupled with any other evidence of the address being unworkable (rather than just the DHCP server being rebooted or something) it can assign itself a LL address, and use it, if that seems best (nothing in LL23 prohibits that). | Neither LL1 nor LL23 provides sufficient detail to really update RFC2131. For LL23, that's good, as updating 2131 was never its aim. | So if either is accepted, then we | need to go through this draft very thoroughly and tweak it so that it | is actually a complete update to RFC2131. Nonsense. | Christian mentions the problem with queries for net 10 addresses at the | root, and implies that allowing a node to have both an IPv4ll and a | global address will result in similar problems. But the fact is that | LL1/LL23 do not solve this problem That's probably true, but ... | - it's still possible that my | IPv4ll-aware device that happens to have a global address will do a PTR | lookup when it gets a connection from my IPv4ll device that doesn't | currently have a routable address. That indicates an implementation bug in your node, surely? If it is LL aware, than aside from someone explicitly using some diagnostic tool, it should never be doing DNS lookups for LL addresses. It knows it can't succeed, and deliberately executing code that cannot work is almost the definition of a bug... (nb: we are assuming LL aware there, LL unaware nodes will be doing PTR lookups for LL addresses for sure - they'll fail, and inconvience the roots, but the only way to avoid that would be to not have LL addresses - we can minimise it though by having LL aware nodes not use LL addresses except when that is essential, then the other nodes won't see LL addresses very often, and the root load will at least be lower). | In fact, I'm not sure in what case | an actual reduction in the number of queries to the root would happen | as a result of accepting LL1/LL23. If I don't have an LL address, then no peer node will ever see that non-existing LL address, and so will never do a PTR lookup of it. If I do have an LL address (when I don't have to have it) then some peer node (unaware of LL) might see that address, and attempt to determine a hostname from it. This should be obvious. | In order to do IPv4ll over multiple interfaces, the IP stack must be | smart enough to ARP on all interfaces that support IPv4ll when it is | asked to communicate with IPv4ll address that is not currently in the | ARP cache. This is unreliable. I would consider any such implementation horribly broken. What's needed is for the v4 stack to grow address scoping capabilities in its address identifier, as has been done in v6, so the application can be told, and/or tell the stack, which particular link this link local address belongs to. I'd be tempted to add this as an absolute requirement before allowing a node with multiple interfaces to communicate using LL out more than one of them. | It is unfortunate that LL19 was discussed and rejected separately from | LL1/LL23, because the two are strongly interconnected. LL19 solves a | lot of the problems that LL1/LL23 try to solve, in a much better way. Unfortunately, it was impractical, regardless of what it solves. In some idealised world where everything understands LL, it might have been practical, but that world, and our world, are not the same thing. kre From owner-zeroconf@merit.edu Tue Feb 25 13:15:39 2003 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 NAA09280 for ; Tue, 25 Feb 2003 13:15:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7C9AD91253; Tue, 25 Feb 2003 13:19:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 37F6691254; Tue, 25 Feb 2003 13:19:23 -0500 (EST) 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 27EA191253 for ; Tue, 25 Feb 2003 13:19:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 13C2C5DDFC; Tue, 25 Feb 2003 13:19:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id C9DD05DDDB for ; Tue, 25 Feb 2003 13:19:20 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1PIK1aj020741; Tue, 25 Feb 2003 20:20:02 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1PIJw7S020737; Tue, 25 Feb 2003 20:19:58 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [LL2]: Explicit Additional Mechanism to disable v4LL From: Mika Liljeberg To: Robert Elz Cc: Erik Guttman , zeroconf@merit.edu In-Reply-To: <23745.1046170530@munnari.OZ.AU> References: <3E58B2FF.6040303@sun.com> <99984944-45BF-11D7-A12D-00039317663C@nominum.com> <11264.1045992468@munnari.OZ.AU> <23745.1046170530@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046197197.15627.64.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 25 Feb 2003 20:19:58 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 2003-02-25 at 12:55, Robert Elz wrote: > I suspect that many sites don't realise that LL addresses are being > configured - nodes that configure them tend to "not work" just the > same as nodes that have no addresses. I had someone ask me a couple of > months ago why they were unable to fetch their e-mail - turns out that > the problem was that the DHCP server had died for some reason or other, > and the system concerned had configured itself with a LL address, and > as far as it was concerned, everything was fine. To the user, the > system had an IP address (numeric values of IP addresses mean little to > most people, and 169.254 is actually close enough to the address it > should have had that there was nothing "obviously" wrong). Isn't that just a user interface problem? The laptop should tell the user "I'm ok for networking" if it has a routable address, "I can only do limited networking" if it only has a LL one, or "I can't network at all" if it doesn't have anything. Given the right input, users can learn what to expect in different situations. MikaL From owner-zeroconf@merit.edu Thu Feb 27 07:50:27 2003 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 HAA28304 for ; Thu, 27 Feb 2003 07:50:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1B63D91201; Thu, 27 Feb 2003 07:54:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF2099120D; Thu, 27 Feb 2003 07:54:13 -0500 (EST) 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 D32CB91201 for ; Thu, 27 Feb 2003 07:54:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id BA30F5DEAF; Thu, 27 Feb 2003 07:54:12 -0500 (EST) 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 6A26F5DDB0 for ; Thu, 27 Feb 2003 07:54:12 -0500 (EST) 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 FAA15116 for ; Thu, 27 Feb 2003 05:54:10 -0700 (MST) 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 h1RCs8l25330 for ; Thu, 27 Feb 2003 13:54:09 +0100 (MET) Date: Thu, 27 Feb 2003 13:54:06 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: new issue [LL28] Applicability of Document Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The following new issue has been added to http://www.spybeam.org/issues.html Description of Issue: Applicability of Document Submitter Name: Robert Elz Submitter Email Address: kre@munnari.OZ.AU Date first submitted: 2003-02-13 Reference: Comment Type ['T'echnical | 'E'ditorial]: E Priority ['S' Must fix | '1' Should fix | '2' May fix ]: 1 Section: 1.2 Rationale/Explanation of issue: It isn't clear just which types of networks which parts of the spec apply to, and/or whether some parts of the spec apply to all link levels Lengthy description of problem: Section 1.2 starts off saying "The specifications in this document apply to any IEEE 802 media" and then later says ... "Link-layer network technologies that do not support ARP may be able to use other techniques ..." This leads to confusion as to whether or not anything in this document is applicable to the use of LL addresses on anything other than IEEE 802 media. Requested Change: Change the first paragraph of section 1.2 to read Link-local addresses as defined in this document, and the methods by which they are used, and not to be used, once acquired, apply in general to any network technology. The specification of how link local addresses are initially acquired, and then later defended, and in particular, the timers to be used, vary from network technology to network technology, and will in general be described in other documents as required in the future. Because IEEE 802 media, including Ethernet (IEEE 802.3), are very commonly used, particularly in environments where link-local addresses are likely to be most desired, this document includes the specification of how link-local addresses are to be acquired and defended using such media. Whenever this document uses the term "Ethernet", that should be read to include any other network technology that uses ARP [RFC826] for IP address resolution, operates at a data rate of at least one megabit per second, and has a round trip latency of no more than one second. Then continue with what is currently the second paragraph (etc). From owner-zeroconf@merit.edu Thu Feb 27 07:50:45 2003 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 HAA28323 for ; Thu, 27 Feb 2003 07:50:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5B1CB9120D; Thu, 27 Feb 2003 07:54:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A29791222; Thu, 27 Feb 2003 07:54:31 -0500 (EST) 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 4BF4F9120D for ; Thu, 27 Feb 2003 07:54:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 38D405DE8D; Thu, 27 Feb 2003 07:54:29 -0500 (EST) 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 AF1325DDB0 for ; Thu, 27 Feb 2003 07:54:28 -0500 (EST) 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 FAA11739 for ; Thu, 27 Feb 2003 05:54:27 -0700 (MST) 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 h1RCsPl25337 for ; Thu, 27 Feb 2003 13:54:25 +0100 (MET) Date: Thu, 27 Feb 2003 13:54:23 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG Action REJECT [LL1] Preferred use of configured to v4 LL address Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Action: Reject Notes: This issue was considered equivalent to LL23. Support and criticism for this problem shifted to LL23. Erik ZEROCONF WG chair From owner-zeroconf@merit.edu Thu Feb 27 07:50:58 2003 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 HAA28341 for ; Thu, 27 Feb 2003 07:50:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 05F6E91222; Thu, 27 Feb 2003 07:54:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C304191225; Thu, 27 Feb 2003 07:54:45 -0500 (EST) 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 0CDD091222 for ; Thu, 27 Feb 2003 07:54:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id F01A25DEE7; Thu, 27 Feb 2003 07:54:43 -0500 (EST) 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 72C6E5DE8D for ; Thu, 27 Feb 2003 07:54:43 -0500 (EST) 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 EAA11675 for ; Thu, 27 Feb 2003 04:54:41 -0800 (PST) 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 h1RCscl25356 for ; Thu, 27 Feb 2003 13:54:38 +0100 (MET) Date: Thu, 27 Feb 2003 13:54:36 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG Action REJECT [LL2] Explicit Additional Mechanism to disable v4 LL Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Action: Reject Dissenting views: Robert Elz: Once again, the aim is to advise hosts that actually want to know whether or not they should bother using LL addresses, whether using one is productive or not. This should be all hosts (subject to user override of course, just like everything else), as the host, without configuration, can't possibly know whether using LL addresses is going to be useful in the environment it finds itself or not. Christian Huitema: I agree with KRE's assessment. This is not a security issue, but a usability issue. Suppose a network in which, for whatever reason, the resident hosts have been configured not to interact with LL addresses. In such a network, the visiting host which configures an LL address will find out eventually that it cannot communicate with any other host. Wouldn't it be better to have a way to learn that immediately? Notes: The criteria for accepting issues is either that they answer IESG concerns or establish a new concern which has strong WG consensus support. This issue satisfied neither criteria. The usability argument rests upon several assumptions regarding how networks are administered, DHCP can refuse addresses but support a new feature and how users can be informed by their computers how to better interact with network management. These are all areas which might be interesting to explore, but are certainly not worked out and have significant problems. Security issues were raised in the cited message, and were never adequately answered: http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00473.html RFC 2563 has not been accepted by client vendors and has been suggested for being moved to 'Historic' by the DHC WG. It would be inappropriate to accept this issue's suggested text. Recommendation: If standardization of this mechanism is of sufficient interest, initiate an IETF standards track effort to pursue it. Recommendation: Further work could be done in the area of user signalling by DHCP, for example - defining a new DHC option for a URL 'greeting.' Stuart Cheshire initiated this promising work 3 or so years ago. Erik ZEROCONF WG chair From owner-zeroconf@merit.edu Thu Feb 27 07:51:18 2003 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 HAA28368 for ; Thu, 27 Feb 2003 07:51:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B85A391228; Thu, 27 Feb 2003 07:55:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 862059122A; Thu, 27 Feb 2003 07:55:08 -0500 (EST) 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 1C3B691228 for ; Thu, 27 Feb 2003 07:55:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 07AEC5DEE7; Thu, 27 Feb 2003 07:55:04 -0500 (EST) 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 AB33F5DEAF for ; Thu, 27 Feb 2003 07:55:03 -0500 (EST) 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 FAA22052 for ; Thu, 27 Feb 2003 05:55:02 -0700 (MST) 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 h1RCt0l25408 for ; Thu, 27 Feb 2003 13:55:00 +0100 (MET) Date: Thu, 27 Feb 2003 13:54:58 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG Action - 1 week last call [LL3] TTL=244 on send, check on receive? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The following issue will be under discussion till March 6, 2003. At that time a consensus call will be made. Please post your comments on the zeroconf mailing list. Please see http://www.spybeam.org/ll3.html The issue is reproduced here for the record: Description of Issue TTL=255 on send, check on receive? Submitter Name Erik Guttman Submitter Email Address erik.guttman@sun.com Date first submitted 6 Feb 2003 Reference http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00041.html http://www.merit.edu/mail.archives/zeroconf/2002-10/msg00000.html Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section 2.7 Rationale/Explanation of issue: There are various problems with the current text relating to setting TTL=255 and checking it. Lengthy description of problem: The current text says: "Any host sending an IPv4 packet with a source and/or destination address in the 169.254/16 prefix MUST set the TTL in the IP header to 255. This includes multicast and broadcast packets with a source address in the 169.254/16 prefix." And: "A host receiving a packet with a source and/or destination address in the 169.254/16 prefix and a TTL less than 255, MAY choose to consider such packets as potentially having been generated by a malicious attacker outside the local link, and MAY choose to silently discard such packets." WG chair attempt at an unbiased overview of the points raised so far: * Setting the TTL to 255 may cause packets to leave the LAN as routers do not know to filter them. (REBUTTAL: If a host knows enough to set to 255 it also knows enough not to forward such a message to a router in the first place.) (REBUTTAL TO REBUTTAL: A message to a multicast address will be forwarded. Some routers also perform proxy ARP, so these messages can escape from the local LAN). * Some existing implementations do not set to 255. Filtering will decrease interoperability. We must 'do no harm.' * The security benefits to be had here are dubious. The document is misleading in that it creates unreasonably high expectations of security benefits from this feature. * Setting the TTL to 1 will prevent routers which have not been specifically configured to specially treat v4LL source addressed messages from forwarding LL messages. REBUTTAL: This decreases the incentive to reconfigure routers to comply with these recommendations. REBUTTAL TO REBUTTAL: We cannot expect all routers in the world to be reconfigured overnight. Thomas Narten wrote: The way I understand the issues: Enforcing the 255-on-receipt check is non-backwards compatable. Indeed, it occurred to me today that its non-backwards compatable with nodes that don't even implement LL addressing. Consider a node A, on the same link with B. A has a global address, B has a LL address. If A attempts to communicate with B, but B notices that the dest address is LL, and then checks for a TTL of 255 (following the recommendation in the current ID), communication will likely fail. So here we have a case where two nodes with valid addresses can't communicate for non-obvious reasons. Neither implementation is violating a Standard. Note the A has not implemented LL at all, so it can't be violating any LL standard. Is this not a potential interoperability problem that we shouldn't knowingly encourage? However, now that Apple does this check, setting the TTL to anything other than 255 is also problematic. That might argue for setting it to 255 (and explaining in the document why), but also saying SHOULD NOT or MUST NOT do the check on receipt since we know it also causes problems with existing implementations that don't set the TTL this way. (Note we could say that the test might be changed in a future standard once the deployed base is upgraded/junked, but it is too early to say that today if one wants to avoid interoperability problems today). But setting the TTL to 255 (rather than 1) also will lead to more LL packets going off link then if the TTL is set to 1. Sure, hosts aren't *supposed* to forward them to routers, but some leakage will inevitably happen as a result of misconfigurations, and other things that are "not supposed to happen". This may cause operational problems. How much? Hard to say. Depends on how many (and which) routers do filtering. I don't believe we need 100% compliance here in order to get enough filtering in practice to keep LL traffic from leaking in horrible ways. For a home site, for example, does it care if its LL traffic goes off link? Probably not. What it cares about is that it doesn't go across the DSL link to its ISP (or that packets from the ISP come in with LL addresses). But that is something the ISP probably cares about enough to ensure that filters are fairly likely to get put at that boundary. Etc. Stuart Cheshire wrote: There are four practical alternatives for the Working Group to choose between: 1. Always check TTL=255 2. Always check TTL=1 3. Don't check TTL at all 4. Have an optional (user configured) check for TTL=255 The three metrics to examine are: (Mac) Always compatible with existing Macs (Win) Always compatible with existing Windows boxes (Orig) Always able to determine if packet originated on the local link The scores: (Mac) (Win) (Orig) 1. Always check TTL=255 + - + 2. Always check TTL=1 - - - 3. Don't check TTL at all + + - 4. User configured TTL=255 + - - Option 1 works with Macs. Option 1 tells you the origin of the packet. Option 1 works with Windows, but only after you've changed the registry key as described in Appendix A.3. (This registry change doesn't have to be done manually by the user -- we're recommending to printer vendors that their printer driver software should automatically make the registry change so that Windows will automatically work properly with their Zeroconf printers.) Option 2 works with nothing today. It tells you nothing about the origin of the packet. It may limit forwarding of the packet, but this is a moot point because compliant hosts don't send LL packets to routers for forwarding anyway. Option 3 works with today's Macs and Windows boxes, but doesn't tell you the origin on the packet. Option 4 lets the user configure whether they want their printer to guard gainst off-link packets, or whether they want their printer to be compatible with the old version of Windows they are using. If the user configures it to check, it might not work with old Windows boxes, generating expensive support calls, so it fails the "Always works with Windows" test. If the user configures it to not check, then it might accept off-link packets, so it fails the "Always able to determine if packet originated on the local link" test. I have only one further comment to make on this topic: Which part of "Zero" and "Configuration" did you not understand? If we have to configure something to make it all work properly, lets configure the Registry key on last-year's Windows boxes to make them work better, not force the customer who buys next year's Zeroconf devices to understand and change some configuration setting to make them work worse. Of the four, options 1 and 3 get two points each. Option 1 has the benefit that receivers know the origin of the packet. Option 3 has the benefit that it saves Microsoft the hassle of having to change its software. My vote goes for option 1, because it gives the bigger long-term benefit. Some people have suggested a policy where we require senders to set the TTL to 255, but not check the TTL on reception, and then in future, after Windows has been updated, we update the specification to require the check too. This simply doesn't work. The fact is that there is no incentive for vendors to set the TTL correctly if no one is checking. The longer time goes on, the more non-conformant devices there will be, and it will become impossible to enforce the check later. We have to decide now. Bernard Aboba wrote: The way to think about this is what the default behavior should be. The single most important thing about TCP/IP is that it is interoperable -- that is, that you can take two hosts with dissimilar operating systems and do an FTP between them. Put together, Zeroconf now has the potential to break the basic interoperability of TCP/IP -- by taking two hosts that formerly could do an FTP using global addresses and now making them unable to communicate. The breakage occurs two ways -- by introducing non-interoperable IPV4 linklocal, and by introducing non-interoperable name resolution. I would argue that if Zeroconf does nothing else, it MUST "do no harm". That is, two hosts with global addresses MUST be guaranteed to be able to continue to communicate interoperably after Zeroconf is introduced. To accomplish this, we need several things: a. Zeroconf protocols MUST be a last resort -- that is, linklocal addresses MUST NOT be used if the two peers have global addresses available. b. A host MUST NOT by default silently discard packets with TTL < 255. Ran Atkinson wrote: Probability of a packet both leaking and arriving with a TTL exactly equal 1 is quite low. Leaking and having a TTL between 1 and 254 is MUCH MUCH higher probability -- and is protected against. > Are you saying that the sending problem is more important than the > receiving one? Among other things, I do think the sending problem is more significant -- but also note that I think that TTL of 1 actually helps the overwhelming majority of receivers also. Please see the archive from mid October 2002 to the end of December 2002 for more on this thread. Requested Change: Replace "A host receiving..." with "At a future time, when legacy pre-standard implementations are in the minority a follow on standard may be issued which will state that hosts SHOULD discard packets with a source and/or destination address in the 169.254/16 prefix and a TTL less than 255. This will lessen the possibility that a host with a v4LL configured address will receive a datagram from a host off the local link, to which it cannot respond." From owner-zeroconf@merit.edu Thu Feb 27 07:51:35 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28407 for ; Thu, 27 Feb 2003 07:51:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CE09691225; Thu, 27 Feb 2003 07:54:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B8A091228; Thu, 27 Feb 2003 07:54:55 -0500 (EST) 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 1209991225 for ; Thu, 27 Feb 2003 07:54:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id E93DD5DEAF; Thu, 27 Feb 2003 07:54:52 -0500 (EST) 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 68FA05DE8D for ; Thu, 27 Feb 2003 07:54:52 -0500 (EST) 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 FAA15452 for ; Thu, 27 Feb 2003 05:54:51 -0700 (MST) 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 h1RCsnl25378 for ; Thu, 27 Feb 2003 13:54:50 +0100 (MET) Date: Thu, 27 Feb 2003 13:54:48 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG Action REJECT [LL27] LL-only hosts are out of scope for this specification Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Action: Reject Notes: While there is rough consensus regarding the behavior of a host which supports this specification, if it is unconfigured and if it gets configured (LL23), there is no consensus (rough or otherwise) that this specification only applies to hosts which can be configured. Recommendation: Create a new issue which recommends (SHOULD, etc) that hosts be configurable with the necessary host configuration parameters. Erik ZEROCONF WG chair From owner-zeroconf@merit.edu Thu Feb 27 07:51:41 2003 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 HAA28452 for ; Thu, 27 Feb 2003 07:51:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F3C9E9122A; Thu, 27 Feb 2003 07:55:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B59839122D; Thu, 27 Feb 2003 07:55:18 -0500 (EST) 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 090D29122A for ; Thu, 27 Feb 2003 07:55:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id E8A405DEE9; Thu, 27 Feb 2003 07:55:12 -0500 (EST) 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 929415DEE7 for ; Thu, 27 Feb 2003 07:55:12 -0500 (EST) 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 FAA12046 for ; Thu, 27 Feb 2003 05:55:11 -0700 (MST) 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 h1RCtAl25425 for ; Thu, 27 Feb 2003 13:55:10 +0100 (MET) Date: Thu, 27 Feb 2003 13:55:08 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG Action ACCEPT [LL10] Add warnings to applicability statement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk LL10 Add warnings to applicability statement Accept the *modified* text in the issue (see http://www.spybeam.org/ll10.html) IPv4 link-local addresses and their dynamic configuration have profound implications upon applications which use them. This is discussed in Section 7. Many applications fundamentally assume that addresses of communicating peers are routable, relatively unchanging and unique. These assumptions no longer hold with IPv4 link-local addresses, or a mixture of link-local and routable addresses. Therefore while many applications will work properly with LL addresses, or a mixture of LL and routable addresses, others may do so only after modification, or will exhibit reduced or partial functionality. In some cases it may be infeasible for the application to be modified to operate under such conditions. IPv4 link-local addresses should therefore only be used where stable, routable addresses are not available (such as on ad hoc or isolated networks) or in controlled situations where these limitations and their impact on applications are understood and accepted. Erik ZEROCONF WG Chair From owner-zeroconf@merit.edu Thu Feb 27 07:51:51 2003 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 HAA28494 for ; Thu, 27 Feb 2003 07:51:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BAF709122D; Thu, 27 Feb 2003 07:55:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 598C391253; Thu, 27 Feb 2003 07:55:29 -0500 (EST) 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 133939122D for ; Thu, 27 Feb 2003 07:55:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 035A75DEE9; Thu, 27 Feb 2003 07:55:24 -0500 (EST) 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 78C0A5DEAF for ; Thu, 27 Feb 2003 07:55:23 -0500 (EST) 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 FAA15660 for ; Thu, 27 Feb 2003 05:55:22 -0700 (MST) 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 h1RCtLl25450 for ; Thu, 27 Feb 2003 13:55:21 +0100 (MET) Date: Thu, 27 Feb 2003 13:55:19 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG Action ACCEPT [LL23] Don't configure needless LL addresses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Action: Accept Dissenting Views (summarized by the WG chair) Ted Lemon: He worries about the behavior of nodes which configure and then cannot 'unconfigure' to interoperate again. He thinks this has to be dealt with here instead of in the DHC WG. Mika Liljeberg: His basic point is that this is not foolproof. There will be problems of leakage of identifers, scope selection, inability to communicate in some cases, etc. and that the transition cases have not been fully worked out. Stuart Cheshire: In order for configuration to enable interoperation, all host configuration on a link must agree (subnet, etc). If we go with LL23 we lose the ability to get interoperation on the link even in the face of misconfiguration. Notes: (1) It must be noted that LL23 is very close if not identical to the behavior of hosts already supporting IPv4LL configuration today (MacOS9, Windows98 and onward, etc). We have operational experience which shows that (a) it is useful, (b) it is not horribly broken. (2) We have WG consensus that issues can arise when there are hosts with more than one scope on the network. This multi-scoped host will have issues with source address selection and may forward protocol messages with locators, referrals, redirects or addresses in-line off-link. The host which only supports LL will also be effected if (a) it supports a service and (b) its location is forwarded off link, where the service cannot be reached. Implication: Mixed scopes *do* present a problem. (3) The behavior described in LL23 will ensure that there is an orderly way of transitioning from LL to configured interface operation. This will respond to problems in (2) in a way known to work (consistent with (1)). (4) In response to Ted's concern: The wording of LL23 does not specify when or how a host must consider itself 'configured.' LL23 does not preclude an attempt to verify configuration upon awakening from sleep mode, changing of carrier sense, etc. A host could determine that it needs to configure with LL in the case that it cannot reach the router, the DHCP server, etc in a bounded period of time (reasonable both for operational stability and for usability). The rules for how and when to determine network reattachment have not been given. It is unlikely that this WG can solve this problem conclusively. Recommendation: Open a new issue with RECOMMENDED behavior for transitioning from configured to unconfigured state based on experience from Apple, Microsoft, etc. clients. (5) In response to Mika's concern: We realize there are potential issues when hosts have multiple address scopes configured. This state with known problems is *bounded* in that hosts will only experience these problems during transition. (6) In response to Stuart's concern: Support for networking in misconfigured networks is not a work item on the charter. It is unfortunate that we cannot offer a solution to this problem, but to do so would leave the can of worms open for an indefinite period of time. (7) Accepting LL23 goes a long way toward answering IESG concerns. Erik ZEROCONF WG chair From owner-zeroconf@merit.edu Thu Feb 27 07:52:15 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28539 for ; Thu, 27 Feb 2003 07:52:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D822291253; Thu, 27 Feb 2003 07:55:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DA4E91258; Thu, 27 Feb 2003 07:55:39 -0500 (EST) 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 14E2591253 for ; Thu, 27 Feb 2003 07:55:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 04E595DEAF; Thu, 27 Feb 2003 07:55:36 -0500 (EST) 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 79CD15DDB0 for ; Thu, 27 Feb 2003 07:55:35 -0500 (EST) 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 FAA15772; Thu, 27 Feb 2003 05:55:33 -0700 (MST) 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 h1RCtVl25515; Thu, 27 Feb 2003 13:55:32 +0100 (MET) Date: Thu, 27 Feb 2003 13:55:29 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: smb@research.att.com Subject: WG Action - 1 week to discuss [LL7] How do existing hosts respond to broadcast requests? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The following issue will be discussed for the week ending March 6, 2003. Please send comments to the mailing list during the last call period. This issue is described at http://www.spybeam.org/ll7.html and reproduced here for the record: (Steve: Please look over the proposed solution and make sure that your concern is addressed.) -------------------------------------------------------------------- Description of Issue How do existing hosts respond to broadcast requests? Submitter Name Steve Bellovin Submitter Email Address smb@research.att.com Date first submitted 6 Feb 03 Reference http://www.merit.edu/mail.archives/zeroconf/2002-10/msg00000.html Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section 2.5 Rationale/Explanation of issue: Broadcast arp replies - is this commonly done? How do hosts behave? Lengthy description of problem: Steve Bellovin wrote: How do current hosts behave with respect to this: All ARP packets (*replies* as well as requests) that contain a link-local 'sender IP address' MUST be sent using link-level broadcast instead of link-level unicast. This aids timely detection of duplicate addresses. An example illustrating how this helps is given in Section 4. (I understand the necessity, but is it done? I suspect not. This suggests that there be a warning that link-local addresses SHOULD NOT be manually configured.) Stuart Cheshire replied: No change is required because this is already answered by the document: Section 1.4 Note that addresses in the 169.254/16 prefix SHOULD NOT be configured manually ------------------------------------------------------------------- Requested Change: No change. From owner-zeroconf@merit.edu Thu Feb 27 07:52:27 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28554 for ; Thu, 27 Feb 2003 07:52:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 14B8491258; Thu, 27 Feb 2003 07:55:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D26E99125F; Thu, 27 Feb 2003 07:55:50 -0500 (EST) 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 661E091258 for ; Thu, 27 Feb 2003 07:55:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 518635DEAF; Thu, 27 Feb 2003 07:55:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id C80125DDB0 for ; Thu, 27 Feb 2003 07:55:46 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24958 for ; Thu, 27 Feb 2003 04:55:45 -0800 (PST) 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 h1RCthl25551; Thu, 27 Feb 2003 13:55:43 +0100 (MET) Date: Thu, 27 Feb 2003 13:55:41 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: erik.nordmark@sun.com Subject: WG Action - 1 week to discuss [LL9] Introduction to make it clear this is not a replacement for a DHCP assigned address Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk We will discuss this issue for the next week, ending March 6, 2003. This issue is reproduced below and can also be found at http://www.spybeam.org/ll9.html Description of Issue Introduction to make it clear this is not a replacement for a DHCP assigned address Submitter Name Erik Nordmark Submitter Email Address erik.nordmark@sun.com Date first submitted 6 Feb 2003 Reference http://www.merit.edu/mail.archives/zeroconf/2002-10/msg00000.html Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section Abstract, 1 Rationale/Explanation of issue: Lengthy description of problem: The abstract and first paragraph in the introduction can easily be read as these addresses being a full-fledged replacement of DHCP assigned addresses. Having the text explicitly say that such addresses can not be used for communication outside a single link would make sense. Requested Change: Link-local communication using link-local addresses is only suitable for communication with other devices connected to the same physical (or logical) link. Link-local communication using link-local addresses is not suitable for communication with devices not directly connected to the same physical (or logical) link. From owner-zeroconf@merit.edu Thu Feb 27 07:52:29 2003 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 HAA28568 for ; Thu, 27 Feb 2003 07:52:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 46578912A0; Thu, 27 Feb 2003 07:56:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B7419126C; Thu, 27 Feb 2003 07:56:07 -0500 (EST) 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 68FAF9125F for ; Thu, 27 Feb 2003 07:56:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 54E8F5DEAF; Thu, 27 Feb 2003 07:56:04 -0500 (EST) 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 C92A15DDB0 for ; Thu, 27 Feb 2003 07:56:03 -0500 (EST) 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 FAA22610 for ; Thu, 27 Feb 2003 05:56:02 -0700 (MST) 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 h1RCu1l25594; Thu, 27 Feb 2003 13:56:01 +0100 (MET) Date: Thu, 27 Feb 2003 13:55:59 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: erik.nordmark@sun.com Subject: WG Action - 1 week to discuss [LL13] If the destination is a global multicast address a host SHOULD use a global source address Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk This issue wil be discussed for 1 week, ending March 6, 2003. Please post to the zeroconf mailing list so we can arrive at a consensus action. Note that since LL23 has been accepted, this issue should be accepted as well. The question is: Does this go without saying? The issue is given at http://www.spybeam.org/ll13.html and reproduced here for the record: Description of Issue If the destination is a global multicast address a host SHOULD use a global source address Submitter Name Erik Nordmark Submitter Email Address erik.nordmark@sun.com Date first submitted 6 Feb 2003 Reference http://www.merit.edu/mail.archives/zeroconf/2002-10/msg00000.html Comment Type ['T'echnical | 'E'ditorial] T Priority['S' Must fix | '1' Should fix | '2' May fix ] S Section 2.6 Rationale/Explanation of issue: Lengthy description of problem: 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 for a link-local multicast destination. But for other multicast destinations I assume it SHOULD use any routable address instead of the link-local. Requested Change: If the destination address is the 255.255.255.255 broadcast address or a link-local multicast address, then the host may use either its link-local source address or a routable address, as appropriate. If the destination address is a multicast address with scope larger than link-local then the host SHOULD use an appropriate routable source address, if available, or its link-local source address otherwise. From owner-zeroconf@merit.edu Thu Feb 27 07:52:36 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28589 for ; Thu, 27 Feb 2003 07:52:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 093D69129E; Thu, 27 Feb 2003 07:56:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D09939126C; Thu, 27 Feb 2003 07:56:00 -0500 (EST) 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 0A62C9125F for ; Thu, 27 Feb 2003 07:55:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id E3DEE5DEAF; Thu, 27 Feb 2003 07:55:56 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 65F025DDB0 for ; Thu, 27 Feb 2003 07:55:56 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25211 for ; Thu, 27 Feb 2003 04:55:55 -0800 (PST) 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 h1RCtrl25579 for ; Thu, 27 Feb 2003 13:55:53 +0100 (MET) Date: Thu, 27 Feb 2003 13:55:51 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG Action - 1 week last call for [LL21] Alternate text for: TTL=255 on send, check on receive? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk This issue will be discussed for the next week ending on March 6, 2003. Please post your comments to the zeroconf list so we can arrive at a consensus action. This issue is available at http://www.spybeam.org/ll21.html and is reproduced here for the record: Description of Issue Alternate text for: TTL=255 on send, check on receive? Submitter Name Robert Elz Submitter Email Address kre@munnari.OZ.AU Date first submitted 8 Feb 2003 Reference http://www.spybeam.org/ll3.html Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section 2.7 Rationale/Explanation of issue: See LL3 Lengthy description of problem: See LL3 Requested Change: Delete the first two paragraphs of section 2.7. From owner-zeroconf@merit.edu Thu Feb 27 07:55:16 2003 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 HAA28651 for ; Thu, 27 Feb 2003 07:55:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2457D9125F; Thu, 27 Feb 2003 07:59:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E214D9126C; Thu, 27 Feb 2003 07:59:02 -0500 (EST) 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 EA5DF9125F for ; Thu, 27 Feb 2003 07:59:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id D50E55DEE7; Thu, 27 Feb 2003 07:59:01 -0500 (EST) 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 50AE65DEAF for ; Thu, 27 Feb 2003 07:59:01 -0500 (EST) 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 FAA24173 for ; Thu, 27 Feb 2003 05:59:00 -0700 (MST) 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 h1RCwwl25752 for ; Thu, 27 Feb 2003 13:58:58 +0100 (MET) Date: Thu, 27 Feb 2003 13:58:56 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: WG Action - 1 week to discuss [LL24] Weaken the PRN generated address requirement from MUST to MAY Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk This issue will be discussed for the next week, ending March 6, 2003. We will reach a decision whether to accept or reject it at that time. Please post your response to the zeroconf list. Description of Issue Weaken the PRN generated address requirement from MUST to MAY Submitter Name Subrata Goswami Submitter Email Address sgoswami@umich.edu Date first submitted 11 Feb 03 Reference Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] 2 Section 2.1 Rationale/Explanation of issue: The algorithm that a LL node uses to determine its LL address does not need to be always PRN based, as ARP can be used validate if it is unique in the Link. Lengthy description of problem: Section 2.1 says, "When a host wishes to configure a link-local address, it selects an address using a pseudo-random number generator with a uniform distribution in the range from 169.254.1.0 to 169.254.254.255." ".. The pseudo-random number generation algorithm MUST be chosen so that different hosts do not generate the same sequence of numbers." Here text should be changed to indicted that the node can use other means to select a LL address than PRN, but has to varify uniqueness by ARPing before it intends to use that adderess on a link the first time (or after absence). Requested Change: ".. The pseudo-random number generation algorithm MAY be chosen so that different hosts do not generate the same sequence of numbers." From owner-zeroconf@merit.edu Thu Feb 27 07:57:34 2003 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 HAA28930 for ; Thu, 27 Feb 2003 07:57:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 38A1A9126C; Thu, 27 Feb 2003 08:01:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0A91912A1; Thu, 27 Feb 2003 08:01:06 -0500 (EST) 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 AD82F9126C for ; Thu, 27 Feb 2003 08:01:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8FE395DEAF; Thu, 27 Feb 2003 08:00:52 -0500 (EST) 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 D85A25DDB0 for ; Thu, 27 Feb 2003 08:00:51 -0500 (EST) 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 GAA20346 for ; Thu, 27 Feb 2003 06:00:50 -0700 (MST) 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 h1RD0nl25920 for ; Thu, 27 Feb 2003 14:00:49 +0100 (MET) Date: Thu, 27 Feb 2003 14:00:47 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: WG Action - 1 week to discuss [LL25] Delete inappropriate "send" requirement on LL nodes. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk This issue will be discussed for the next week, ending March 6, 2003. Please send comments to the zeroconf mailing list. Description of Issue Delete inappropriate "send" requirement on LL nodes. Submitter Name Subrata Goswami Submitter Email Address sgoswami@umich.edu Date first submitted 11 Feb 03 Reference none Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section 2.6 Rationale/Explanation of issue: Delete the following statements ".. The host MUST NOT send the packet to any router for forwarding." Lengthy description of problem: Section 2.6 requires the following of an LL node at several places. ".. The host MUST NOT send the packet to any router for forwarding." The nodes on a link should not have the responsibility of determining whether the router can forward a packet or not. Requested Change: Delete the following statements (throughout the document) ".. The host MUST NOT send the packet to any router for forwarding." From owner-zeroconf@merit.edu Thu Feb 27 08:08:25 2003 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 IAA29907 for ; Thu, 27 Feb 2003 08:08:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B3180912A1; Thu, 27 Feb 2003 08:12:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E8EA912A3; Thu, 27 Feb 2003 08:12:11 -0500 (EST) 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 91284912A1 for ; Thu, 27 Feb 2003 08:12:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 747105DEE7; Thu, 27 Feb 2003 08:12:10 -0500 (EST) 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 E9F725DFC2 for ; Thu, 27 Feb 2003 08:12:09 -0500 (EST) 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 GAA29041; Thu, 27 Feb 2003 06:12:06 -0700 (MST) 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 h1RDC4l26478; Thu, 27 Feb 2003 14:12:04 +0100 (MET) Date: Thu, 27 Feb 2003 14:12:02 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: zeroconf status summary Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Folks, We have a few items up for discussion, but aside from LL3 and LL21 there will likely be little discussion. LL3 and LL21 need to be discussed together. LL24 and LL25 seem uncontroversial (headed for rejection). LL7 is easy now that LL23 has been decided. LL9 is likely not to be controversial. We still need text for LL4, LL5 and LL18. Thanks for your continuing contributions. Erik From owner-zeroconf@merit.edu Thu Feb 27 08:59:58 2003 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 IAA02967 for ; Thu, 27 Feb 2003 08:59:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9D7EE9121C; Thu, 27 Feb 2003 09:03:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F5CA912A6; Thu, 27 Feb 2003 09:03:44 -0500 (EST) 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 777AA9121C for ; Thu, 27 Feb 2003 09:03:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 67C395DEAB; Thu, 27 Feb 2003 09:03:43 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id F37285DE8D for ; Thu, 27 Feb 2003 09:03:42 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1RCntR22172 for ; Thu, 27 Feb 2003 04:49:55 -0800 Date: Thu, 27 Feb 2003 04:49:55 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: LL24: Weaken the PRN requirement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I would urge this one be rejected. The issue is not whether a single address conflict can be detected. The issue is whether two conflicting hosts could then move to another conflicting address. Weakening the PRN requirement would make this more likely. From owner-zeroconf@merit.edu Thu Feb 27 09:03:02 2003 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 JAA03176 for ; Thu, 27 Feb 2003 09:03:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F0F11912A6; Thu, 27 Feb 2003 09:06:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA57C912A7; Thu, 27 Feb 2003 09:06:48 -0500 (EST) 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 B8A8A912A6 for ; Thu, 27 Feb 2003 09:06:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D6C95DDA9; Thu, 27 Feb 2003 09:06:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 2ED5C5DDE6 for ; Thu, 27 Feb 2003 09:06:47 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1RCr0d22318 for ; Thu, 27 Feb 2003 04:53:00 -0800 Date: Thu, 27 Feb 2003 04:52:59 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: LL25: Inappropriate "send" requirement Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I would also urge that this one be rejected. We've already discussed why it is important that packets sent to a LL4 address not be sent to the gateway where it is likely that 169.254/16 will not be handled correctly. Making the change recommended in this issue would result in the packets being shovelled off to the backbone router where they will be dropped, rather than being sent on the local link. This change is therefore quite damaging. From owner-zeroconf@merit.edu Thu Feb 27 09:04:17 2003 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 JAA03300 for ; Thu, 27 Feb 2003 09:04:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BFA35912A7; Thu, 27 Feb 2003 09:08:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8EEFC912A9; Thu, 27 Feb 2003 09:08:03 -0500 (EST) 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 9F74A912A7 for ; Thu, 27 Feb 2003 09:08:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E1F15DF01; Thu, 27 Feb 2003 09:08:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 2AC735DDE6 for ; Thu, 27 Feb 2003 09:08:02 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h1RCsFv22371 for ; Thu, 27 Feb 2003 04:54:15 -0800 Date: Thu, 27 Feb 2003 04:54:14 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: LL9: Not a replacement for DHCP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I am favor of this change as stated. From owner-zeroconf@merit.edu Thu Feb 27 09:11:10 2003 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 JAA03768 for ; Thu, 27 Feb 2003 09:11:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2A06D912A9; Thu, 27 Feb 2003 09:14:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EBB01912AB; Thu, 27 Feb 2003 09:14:55 -0500 (EST) 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 127C6912A9 for ; Thu, 27 Feb 2003 09:14:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC91B5DEAB; Thu, 27 Feb 2003 09:14:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 5C0C15DF01 for ; Thu, 27 Feb 2003 09:14:53 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1REEgO07588; Thu, 27 Feb 2003 21:14:43 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1REEco22558; Thu, 27 Feb 2003 21:14:39 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: WG Action - 1 week to discuss [LL13] If the destination is a global multicast address a host SHOULD use a global source address In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Feb 2003 21:14:38 +0700 Message-ID: <22556.1046355278@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 27 Feb 2003 13:55:59 +0100 (CET) From: Erik Guttman Message-ID: | Note that since LL23 has been accepted, this issue should be accepted as | well. The question is: Does this go without saying? It has already been said, so it is too late for that ... but yes, accept this issue. kre From owner-zeroconf@merit.edu Thu Feb 27 09:16:55 2003 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 JAA04262 for ; Thu, 27 Feb 2003 09:16:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A7A6D912AB; Thu, 27 Feb 2003 09:20:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CC44912AC; Thu, 27 Feb 2003 09:20:42 -0500 (EST) 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 7D531912AB for ; Thu, 27 Feb 2003 09:20:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D8B05E074; Thu, 27 Feb 2003 09:20:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id DADE85DF08 for ; Thu, 27 Feb 2003 09:20:39 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1REKZO07930; Thu, 27 Feb 2003 21:20:35 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1REKRo22574; Thu, 27 Feb 2003 21:20:27 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: WG Action - 1 week to discuss [LL24] Weaken the PRN generated address requirement from MUST to MAY In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Feb 2003 21:20:27 +0700 Message-ID: <22572.1046355627@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Reject LL24. I suspect that the intent here is more along the lines of "I could use real random numbers, rather than fake ones", but it reads as if "I should be able to use 1 2 3 ... as my sequence" is what is being suggested. Certainly there's a point here, there's no need for the random numbers used to be pseudo-random, real random numbers would work just as well. But I don't think anyone with real random numbers available, and who has the desire to use them will be very worried by the requirement that a pseudo-random set of numbers be used (it isn't as if it is justified by some requirement that the sequence be repeatable). Just leaving the text as it is is good enough for now. kre ps: if I'm wrong, and the intent really was to allow 1 2 3 or 2 4 6 or similar as the number sequence, then this would be too silly to even bother commenting on - a PRNG is just a multiply/add sequence, there's no conceivable reason not to do at least that. From owner-zeroconf@merit.edu Thu Feb 27 09:18:31 2003 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 JAA04379 for ; Thu, 27 Feb 2003 09:18:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C79E8912AC; Thu, 27 Feb 2003 09:22:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84E69912AD; Thu, 27 Feb 2003 09:22:18 -0500 (EST) 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 9B8AB912AC for ; Thu, 27 Feb 2003 09:22:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B5C45E076; Thu, 27 Feb 2003 09:22:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 144995DDA0 for ; Thu, 27 Feb 2003 09:22:16 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1REMCO07988; Thu, 27 Feb 2003 21:22:12 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1REM2o22585; Thu, 27 Feb 2003 21:22:02 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: WG Action - 1 week to discuss [LL25] Delete inappropriate "send" requirement on LL nodes. In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Feb 2003 21:22:02 +0700 Message-ID: <22583.1046355722@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Reject LL25. The reason given makes no sense to me. The very definition of LL is that all the addresses are on the link - there is nothing for the nodes on the link to determine - it is all defined for them. kre From owner-zeroconf@merit.edu Thu Feb 27 09:29:34 2003 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 JAA05135 for ; Thu, 27 Feb 2003 09:29:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8A03591205; Thu, 27 Feb 2003 09:33:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5AB98912AD; Thu, 27 Feb 2003 09:33:15 -0500 (EST) 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 DAB1D91205 for ; Thu, 27 Feb 2003 09:32:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id BD3755E187; Thu, 27 Feb 2003 09:32:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id BF0425DDB0 for ; Thu, 27 Feb 2003 09:31:59 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1REVtO08490; Thu, 27 Feb 2003 21:31:55 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1REVbo22612; Thu, 27 Feb 2003 21:31:37 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: WG Action - 1 week to discuss [LL9] Introduction to make it clear this is not a replacement for a DHCP assigned address In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Feb 2003 21:31:37 +0700 Message-ID: <22610.1046356297@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk LL9 is noise - it is fine, unremarkable (also most likely unnecessary, but who cares). Just accept it and avoid hassles. kre From owner-zeroconf@merit.edu Thu Feb 27 09:32:04 2003 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 JAA05283 for ; Thu, 27 Feb 2003 09:32:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 02A0E91264; Thu, 27 Feb 2003 09:35:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C305E912AD; Thu, 27 Feb 2003 09:35:51 -0500 (EST) 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 D77AE91264 for ; Thu, 27 Feb 2003 09:35:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9C02E5E18A; Thu, 27 Feb 2003 09:35:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 179725DDDF for ; Thu, 27 Feb 2003 09:35:49 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1REZeO08669; Thu, 27 Feb 2003 21:35:45 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1REZbo22630; Thu, 27 Feb 2003 21:35:37 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: WG Action - 1 week last call for [LL21] Alternate text for: TTL=255 on send, check on receive? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 27 Feb 2003 21:35:37 +0700 Message-ID: <22628.1046356537@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Accept LL21 (well, obviously...) More reasons given in a message I sent (only to) Erik (which I am hoping he will forward to the list, I didn't keep a copy...) related to LL3 (for which LL21 is an alternative resolution). kre From owner-zeroconf@merit.edu Thu Feb 27 09:34:22 2003 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 JAA05336 for ; Thu, 27 Feb 2003 09:34:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 12885912AD; Thu, 27 Feb 2003 09:38:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2233912AE; Thu, 27 Feb 2003 09:38:09 -0500 (EST) 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 ECD60912AD for ; Thu, 27 Feb 2003 09:38:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id D50085DDDF; Thu, 27 Feb 2003 09:38:08 -0500 (EST) 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 554C85DDB0 for ; Thu, 27 Feb 2003 09:38:08 -0500 (EST) 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 HAA23015 for ; Thu, 27 Feb 2003 07:38:07 -0700 (MST) 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 h1REc5l00829 for ; Thu, 27 Feb 2003 15:38:05 +0100 (MET) Date: Thu, 27 Feb 2003 15:38:03 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: Re: WG Action - 1 week last call [LL3] TTL=244 on send, check on receive? (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk ---------- Forwarded message ---------- Date: Thu, 27 Feb 2003 21:30:28 +0700 From: Robert Elz To: Erik Guttman Subject: Re: WG Action - 1 week last call [LL3] TTL=244 on send, check on receive? Reject LL3, (accept LL21 in its place...) LL3 as it stands changes nothing, leaving the TTL==255 on send, and expecting that hosts will (sometime in the future) check it on receive - which is what the doc already implies (it says that hosts MAY check on receive - but no-one sane would do that when there are known implementations that don't send 255). There's no good reason for using 255 (even assuming it is being checked - if it isn't, its absurd). The absolute most that this gains is to allow a host to drop a packet if it has passed through a (broken) router (just how that could even happen, however broken the router, is left to the imagination, of which lots is required). If the packet isn't dropped, the host attempts to reply, and that fails, which is not exactly a huge loss to anyone (given that in practice this isn't going to happen anyway). The alternative that has been suggested is TTL==1 instead. That's so routers won't forward packets. But any host that knows to set TTL==1 will also know not to send the packet to a router, so that turns out to be a null benefit as well. This all boils down to there being no reason that makes any sense to specify anything at all about TTLs (though it might be prudent to note, if it is in fact true - I am relying on my memory of remarks made on the list, that some implementations actually check that packets have TTL==255 - which might suggest to implementors in the short term that using 255 would be safest, without actually requiring it). kre From owner-zeroconf@merit.edu Thu Feb 27 09:40:41 2003 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 JAA05740 for ; Thu, 27 Feb 2003 09:40:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6DE82912AE; Thu, 27 Feb 2003 09:44:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 371C8912AF; Thu, 27 Feb 2003 09:44:28 -0500 (EST) 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 45DFC912AE for ; Thu, 27 Feb 2003 09:44:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C0D55DDDF; Thu, 27 Feb 2003 09:44:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 97BEA5DDB0 for ; Thu, 27 Feb 2003 09:44:26 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-454.cisco.com [10.82.241.198]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1REiCP8000761; Thu, 27 Feb 2003 06:44:12 -0800 (PST) Message-Id: <4.3.2.7.2.20030227093335.01feb028@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Feb 2003 09:44:11 -0500 To: Erik Guttman From: John Schnizlein Subject: Re: WG Action - 1 week last call [LL3] TTL=244 on send, check on receive? Cc: zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk The subject line seems to include a typo, since I recall no discussion of TTL=244, but much discussion of 255 and 1. The proposal (at the very end) advocates TTL=255 on send, check on receive. This should be rejected in favor of TTL=1 on send, which implies that all traffic that is supposed to be local to the origin link is not forwarded by a reasonable router. The argument that the originating host can prevent a packet with a larger TTL from reaching a router is flawed; proxy-ARP is a clear counter-example. Do no harm is more important than compatibility with pre-standard implementations. At 07:54 AM 2/27/2003, Erik Guttman wrote: >... >Description of Issue TTL=255 on send, check on receive? >... >The current text says: > >"Any host sending an IPv4 packet with a source and/or destination >address in the 169.254/16 prefix MUST set the TTL in the IP header >to 255. This includes multicast and broadcast packets with a source >address in the 169.254/16 prefix." > >And: > >"A host >receiving a packet with a source and/or destination address in the >169.254/16 prefix and a TTL less than 255, MAY choose to consider >such packets as potentially having been generated by a malicious >attacker outside the local link, and MAY choose to silently discard >such packets." > >WG chair attempt at an unbiased overview of the points raised so far: > > * Setting the TTL to 255 may cause packets to leave the LAN as >routers do not know to filter them. > > (REBUTTAL: If a host knows enough to set to 255 it also knows >enough not to forward such a message to a router in the first place.) > > (REBUTTAL TO REBUTTAL: A message to a multicast address will be >forwarded. Some routers also perform proxy ARP, so these messages can >escape from the local LAN). > * Some existing implementations do not set to 255. Filtering will >decrease interoperability. We must 'do no harm.' > * The security benefits to be had here are dubious. The document is >misleading in that it creates unreasonably high expectations of security >benefits from this feature. > * Setting the TTL to 1 will prevent routers which have not been >specifically configured to specially treat v4LL source addressed >messages from forwarding LL messages. > > REBUTTAL: This decreases the incentive to reconfigure routers to >comply with these recommendations. > >REBUTTAL TO REBUTTAL: We cannot expect all routers in the world to be >reconfigured overnight. From owner-zeroconf@merit.edu Thu Feb 27 09:41:27 2003 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 JAA05830 for ; Thu, 27 Feb 2003 09:41:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 14DE3912AF; Thu, 27 Feb 2003 09:45:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 998B6912B1; Thu, 27 Feb 2003 09:45:03 -0500 (EST) 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 CA215912AF for ; Thu, 27 Feb 2003 09:45:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 54E1A5E187; Thu, 27 Feb 2003 09:45:01 -0500 (EST) 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 3653A5DDDF for ; Thu, 27 Feb 2003 09:45:00 -0500 (EST) 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 JAA20968 for ; Thu, 27 Feb 2003 09:44:59 -0500 (EST) 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 JAA13410 for ; Thu, 27 Feb 2003 09:44:59 -0500 (EST) Received: from [18.18.3.76] (WINDEL1.MIT.EDU [18.18.3.76]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id JAA28997 for ; Thu, 27 Feb 2003 09:44:58 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 27 Feb 2003 09:44:54 -0500 Subject: Re: WG Action - 1 week last call [LL3] TTL=244 on send, check on receive? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: 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 02/27/2003 07:54, "Erik Guttman" wrote: > Stuart Cheshire wrote: > > There are four practical alternatives for the Working Group to choose > between: > > 1. Always check TTL=255 > 2. Always check TTL=1 > 3. Don't check TTL at all > 4. Have an optional (user configured) check for TTL=255 > What Stuart said works for me. john -- John C. Welch Consultant III Office Computing Practice (IS) (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Feb 27 09:57:29 2003 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 JAA06352 for ; Thu, 27 Feb 2003 09:57:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7F1BB912B2; Thu, 27 Feb 2003 10:00:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 468B6912B5; Thu, 27 Feb 2003 10:00:53 -0500 (EST) 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 40BC2912B2 for ; Thu, 27 Feb 2003 10:00:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7CFF25E18C; Thu, 27 Feb 2003 10:00:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id C89055E18A for ; Thu, 27 Feb 2003 10:00:45 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-454.cisco.com [10.82.241.198]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1RF0VP8017767; Thu, 27 Feb 2003 07:00:31 -0800 (PST) Message-Id: <4.3.2.7.2.20030227095046.01ff12a8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Feb 2003 10:00:43 -0500 To: Erik Guttman From: John Schnizlein Subject: Re: WG Action - 1 week last call for [LL21] Alternate text for: TTL=255 on send, check on receive? Cc: zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk This well-intended proposal should be rejected as insufficient because the paragraph following them is inadequate. (copied below) The new requirement that all routers, wherever LL hosts appear, must not perform traditional proxy-ARP for the special case of source or destination addresses with 169.254/16 prefixes is not reasonable. Expecting all routers to be changed in order to protect against undesirable leakage of LL traffic is not practical. There is still a reasonable way that hosts using LL addresses can minimize the risk of leakage: TTL=1. John At 07:55 AM 2/27/2003, Erik Guttman wrote: >Requested Change: >Delete the first two paragraphs of section 2.7. These two paragraphs - and the next one - are as follows: 2.7 Link-Local Packets Are Not Forwarded Any host sending an IPv4 packet with a source and/or destination address in the 169.254/16 prefix MUST set the TTL in the IP header to 255. This includes multicast and broadcast packets with a source address in the 169.254/16 prefix. This allows hosts to guard against misconfigured routers, which may allow packets to leak in from outside the local link. Since even the most dysfunctional router will decrement the TTL in the IP header, a host can know with reasonable certainty that any packet received with a TTL of 255 did come from another host on the local link. A host receiving a packet with a source and/or destination address in the 169.254/16 prefix and a TTL less than 255, MAY choose to consider such packets as potentially having been generated by a malicious attacker outside the local link, and MAY choose to silently discard such packets. [See Appendix for details of current implementations.] An IPv4 packet whose source and/or destination address is in the 169.254/16 prefix MUST NOT be sent to any router for forwarding, and any network device receiving such a packet MUST NOT forward it, regardless of the TTL in the IP header. Similarly, a router or other host MUST NOT indiscriminately answer all ARP requests for addresses in the 169.254/16 prefix. A router may of course answer ARP requests for the one (or more) own link-local address(es) that it has legitimately claimed for its own use according to the claim-and- defend protocol described in this document. From owner-zeroconf@merit.edu Thu Feb 27 10:55:52 2003 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 KAA09059 for ; Thu, 27 Feb 2003 10:55:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F2721912BD; Thu, 27 Feb 2003 10:59:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDA70912BE; Thu, 27 Feb 2003 10:59:39 -0500 (EST) 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 B9EBE912BD for ; Thu, 27 Feb 2003 10:59:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 996965DDCB; Thu, 27 Feb 2003 10:59:38 -0500 (EST) 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 2F52F5DD8F for ; Thu, 27 Feb 2003 10:59:38 -0500 (EST) 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 KAA04206 for ; Thu, 27 Feb 2003 10:59:37 -0500 (EST) 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 KAA01352 for ; Thu, 27 Feb 2003 10:55:05 -0500 (EST) Received: from [18.18.3.76] (WINDEL1.MIT.EDU [18.18.3.76]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA07728 for ; Thu, 27 Feb 2003 10:51:36 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 27 Feb 2003 10:51:33 -0500 Subject: Re: WG Action - 1 week last call for [LL21] Alternate text for: TTL=255 on send, check on receive? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <4.3.2.7.2.20030227095046.01ff12a8@wells.cisco.com> 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 02/27/2003 10:00, "John Schnizlein" wrote: > There is still a reasonable way that hosts using LL addresses can > minimize the risk of leakage: TTL=1. That only prevents leakage out. It does not prevent bad packets from other links leaking *in*. john -- John C. Welch Consultant III Office Computing Practice (IS) (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Feb 27 11:14:30 2003 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 LAA09841 for ; Thu, 27 Feb 2003 11:14:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A8A219122D; Thu, 27 Feb 2003 11:18:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 746819126C; Thu, 27 Feb 2003 11:18:19 -0500 (EST) 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 207379122D for ; Thu, 27 Feb 2003 11:18:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id E1D4D5DDBB; Thu, 27 Feb 2003 11:18:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 737205DD8F for ; Thu, 27 Feb 2003 11:18:16 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-454.cisco.com [10.82.241.198]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1RGI1P8021939; Thu, 27 Feb 2003 08:18:02 -0800 (PST) Message-Id: <4.3.2.7.2.20030227111506.01fe35c0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Feb 2003 11:18:13 -0500 To: "John C. Welch" From: John Schnizlein Subject: Re: WG Action - 1 week last call for [LL21] Alternate text for: TTL=255 on send, check on receive? Cc: Zeroconf In-Reply-To: References: <4.3.2.7.2.20030227095046.01ff12a8@wells.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk At 10:51 AM 2/27/2003, John C. Welch wrote: >On 02/27/2003 10:00, "John Schnizlein" wrote: > >> There is still a reasonable way that hosts using LL addresses can >> minimize the risk of leakage: TTL=1. > >That only prevents leakage out. >It does not prevent bad packets from other links leaking *in*. This is a true statement, but not relevant to the goal of avoiding causing harm to the rest of the Internet due to the creation of special link-local behavior. What bad packets are you concerned about? If the standard specifies that link-local traffic does not get out, then it should not be out there to leak in. John From owner-zeroconf@merit.edu Thu Feb 27 11:29:49 2003 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 LAA10348 for ; Thu, 27 Feb 2003 11:29:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D298F9126C; Thu, 27 Feb 2003 11:33:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1B99912C2; Thu, 27 Feb 2003 11:33:22 -0500 (EST) 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 0A2C6912A0 for ; Thu, 27 Feb 2003 11:32:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 71FB85E19F; Thu, 27 Feb 2003 11:32:01 -0500 (EST) 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 1F2775E19D for ; Thu, 27 Feb 2003 11:32:01 -0500 (EST) 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 JAA07562; Thu, 27 Feb 2003 09:31:59 -0700 (MST) 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 h1RGVwl06504; Thu, 27 Feb 2003 17:31:58 +0100 (MET) Date: Thu, 27 Feb 2003 17:31:56 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: "John C. Welch" Cc: Zeroconf Subject: Re: WG Action - 1 week last call for [LL21] Alternate text for: TTL=255 on send, check on receive? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Thu, 27 Feb 2003, John C. Welch wrote: > On 02/27/2003 10:00, "John Schnizlein" wrote: > > There is still a reasonable way that hosts using LL addresses can > > minimize the risk of leakage: TTL=1. > > That only prevents leakage out. It does not prevent bad packets from other > links leaking *in*. [WG chair hat off] To refresh everyone's memory - there were two main reasons why it was seen to be a good idea to set TTL=255 to send and check 255 on receive. 1. A host could filter improperly sent packets from off-link (mistaken or malevolent). 2. Setting TTL to 255 would be consistent with the behavior of some shipped systems, eventually *all* such systems (someday). The counter arguments to this were: 1'. This does not provide meaningful security against off-link attacks. Sending with TTL=1 would ensure that conforming hosts would not improperly send packets off link. Setting TTL>1 will encourage leakage, from improperly configured routers. 2'. There are many shipped systems which send with other TTL settings and it is not clear when these will go away. Filtering for only receivers with TTL=255 will do harm. The counter arguments for this were: 1''. setting TTL=1 will not encourage folks to reconfigure routers to refuse to forward datagrams in the LL prefix. Erik From owner-zeroconf@merit.edu Thu Feb 27 11:36:08 2003 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 LAA10550 for ; Thu, 27 Feb 2003 11:36:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A617B912A0; Thu, 27 Feb 2003 11:39:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D410912BE; Thu, 27 Feb 2003 11:39:54 -0500 (EST) 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 69C0E912A0 for ; Thu, 27 Feb 2003 11:39:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C12E5DEF2; Thu, 27 Feb 2003 11:39:52 -0500 (EST) 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 B2E995DEBE for ; Thu, 27 Feb 2003 11:39:51 -0500 (EST) 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 LAA29323 for ; Thu, 27 Feb 2003 11:39:50 -0500 (EST) 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 LAA10473 for ; Thu, 27 Feb 2003 11:39:50 -0500 (EST) Received: from [18.18.3.76] (WINDEL1.MIT.EDU [18.18.3.76]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA06212 for ; Thu, 27 Feb 2003 11:39:49 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 27 Feb 2003 11:39:47 -0500 Subject: Re: WG Action - 1 week last call for [LL21] Alternate text for: TTL=255 on send, check on receive? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <4.3.2.7.2.20030227111506.01fe35c0@wells.cisco.com> 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 02/27/2003 11:18, "John Schnizlein" wrote: >> That only prevents leakage out. >> It does not prevent bad packets from other links leaking *in*. > > This is a true statement, but not relevant to the goal of avoiding > causing harm to the rest of the Internet due to the creation of > special link-local behavior. Well, since you (in theory), can't route LL packets anyway, because your router should be rejecting LL - addresses, I don't see the *Internet* being harmed. It's rather resilient, as Bob Metcalfe found out a few years ago. > > What bad packets are you concerned about? If the standard specifies > that link-local traffic does not get out, then it should not be out > there to leak in. If LL traffic can't get out, then the TTL doesn't matter anyway. But TTL = 1 is a bit too passive for me. TTL = 255 is not terribly better, but it handles packets coming in correctly better, in that TTL decrementing is not something that breaks too often, but it is very possible to accidentally tell your router to pass LL traffic. If that happens, the TTL could very easily be 1, even though it came from a totally different link. It's going to be a little harder to get a router to not decrement.* john *I am not going to go down the road of deliberate attempts at spoofage. That's a different can of worms, and will bypass any TTL setting we set up anyway. -- John C. Welch Consultant III Office Computing Practice (IS) (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Feb 27 11:46:00 2003 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 LAA10925 for ; Thu, 27 Feb 2003 11:46:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 884C991276; Thu, 27 Feb 2003 11:49:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 59FC1912BE; Thu, 27 Feb 2003 11:49:49 -0500 (EST) 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 56B8F91276 for ; Thu, 27 Feb 2003 11:49:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 29B0A5E005; Thu, 27 Feb 2003 11:49:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by segue.merit.edu (Postfix) with ESMTP id D7DC25DD8F for ; Thu, 27 Feb 2003 11:49:46 -0500 (EST) Received: from SGOSWAMIPCL ([63.164.145.161]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with ESMTP id LAA00966; Thu, 27 Feb 2003 11:49:43 -0500 (EST) From: "Subrata Goswami" To: "'Bernard Aboba'" , Subject: RE: LL24: Weaken the PRN requirement Date: Thu, 27 Feb 2003 08:43:15 -0800 Message-ID: <004b01c2de7f$537da030$1bc0140a@SGOSWAMIPCL> 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.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Actually I am trying to say that if there is a way for a LL nodes to determine the other LL nodes' LLv4 addresses, then it does not need to use the PRN. An alternative algorithm is provided below - although it is somewhat extreme it would work. A node can start at 169.254.0.1 and iterate to 169.254.255.254 picking up each LLv4 address and ARP'ing for conflict. The node can pick the first LLv4 address it does not get an ARP reply back. Subrata > -----Original Message----- > From: owner-zeroconf@merit.edu > [mailto:owner-zeroconf@merit.edu] On Behalf Of Bernard Aboba > Sent: Thursday, February 27, 2003 4:50 AM > To: zeroconf@merit.edu > Subject: LL24: Weaken the PRN requirement > > > I would urge this one be rejected. The issue is not whether a > single address conflict can be detected. The issue is whether > two conflicting hosts could then move to another conflicting > address. Weakening the PRN requirement would make this more likely. > From owner-zeroconf@merit.edu Thu Feb 27 11:57:19 2003 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 LAA11322 for ; Thu, 27 Feb 2003 11:57:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 36954912BE; Thu, 27 Feb 2003 12:00:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1A9F912C2; Thu, 27 Feb 2003 12:00:31 -0500 (EST) 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 E84AF912BE for ; Thu, 27 Feb 2003 12:00:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8EEF45E19D; Thu, 27 Feb 2003 12:00:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id A8BF35E18C for ; Thu, 27 Feb 2003 12:00:28 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-454.cisco.com [10.82.241.198]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1RH0EP8021142; Thu, 27 Feb 2003 09:00:14 -0800 (PST) Message-Id: <4.3.2.7.2.20030227114736.020d7c60@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Feb 2003 12:00:26 -0500 To: Erik Guttman From: John Schnizlein Subject: Re: WG Action - 1 week last call for [LL21] Alternate text for: TTL=255 on send, check on receive? Cc: Zeroconf In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk Wasn't there a moratorium declared some time ago on discussion of vague security claims for TTL settings? Declaring routers that comply with all existing router requirements "improperly configured" because they do not perform special operations for a new specification is not compatible with the do-no-harm goal. The special handling of a particular prefix might require more than a simple configuration change, and how could we justify forcing everyone to reconfigure their routers to protect the Internet from link-local traffic, when we have an easy alternative using TTL as intended, to limit the spread of packets beyond their useful scope. John At 11:31 AM 2/27/2003, Erik Guttman wrote: >[WG chair hat off] >To refresh everyone's memory - there were two main reasons why it was >seen to be a good idea to set TTL=255 to send and check 255 on receive. > > 1. A host could filter improperly sent packets from off-link (mistaken > or malevolent). > > 1'. This does not provide meaningful security against off-link attacks. > > Sending with TTL=1 would ensure that conforming hosts would not > improperly send packets off link. > > Setting TTL>1 will encourage leakage, from improperly configured > routers. > > 1''. setting TTL=1 will not encourage folks to reconfigure routers > to refuse to forward datagrams in the LL prefix. > > 2. Setting TTL to 255 would be consistent with the behavior of some > shipped systems, eventually *all* such systems (someday). > > 2'. There are many shipped systems which send with other TTL settings > and it is not clear when these will go away. Filtering for only > receivers with TTL=255 will do harm. From owner-zeroconf@merit.edu Thu Feb 27 11:59:51 2003 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 LAA11473 for ; Thu, 27 Feb 2003 11:59:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A8A4B912A5; Thu, 27 Feb 2003 12:03:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61B3F912A3; Thu, 27 Feb 2003 12:03:38 -0500 (EST) 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 7729A912A5 for ; Thu, 27 Feb 2003 12:03:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 605E45E005; Thu, 27 Feb 2003 12:03:35 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 802875DE54 for ; Thu, 27 Feb 2003 12:03:34 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11445; Thu, 27 Feb 2003 09:03:32 -0800 (PST) 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 h1RH3Ul08129; Thu, 27 Feb 2003 18:03:31 +0100 (MET) Date: Thu, 27 Feb 2003 18:03:28 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: John Schnizlein Cc: Erik Guttman , Zeroconf Subject: Re: WG Action - 1 week last call for [LL21] Alternate text for: TTL=255 on send, check on receive? In-Reply-To: <4.3.2.7.2.20030227114736.020d7c60@wells.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Thu, 27 Feb 2003, John Schnizlein wrote: > Wasn't there a moratorium declared some time ago on discussion > of vague security claims for TTL settings? Please do not consider any topic off limits, as long as it directly pertains to the issue being discussed. Regards, Erik ZEROCONF WG chair From owner-zeroconf@merit.edu Thu Feb 27 12:23:56 2003 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 MAA12628 for ; Thu, 27 Feb 2003 12:23:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9B343912C2; Thu, 27 Feb 2003 12:27:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05975912C3; Thu, 27 Feb 2003 12:27:41 -0500 (EST) 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 185A3912C2 for ; Thu, 27 Feb 2003 12:27:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 006BF5DE78; Thu, 27 Feb 2003 12:27:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 8BB835DE32 for ; Thu, 27 Feb 2003 12:27:40 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-454.cisco.com [10.82.241.198]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1RHRQP8001817; Thu, 27 Feb 2003 09:27:26 -0800 (PST) Message-Id: <4.3.2.7.2.20030227121510.02105e20@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Feb 2003 12:27:35 -0500 To: Erik Guttman From: John Schnizlein Subject: Re: new issue tracking for ZEROCONF WG Cc: zeroconf@merit.edu In-Reply-To: <3E42BAA1.7050606@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk New Issue: Description of issue: Link-local sources should specify TTL=1 Submitter name: John Schnizlein Submitter email address: jschnizl@cisco.com Date first submitted: 2003-02-27 Comment type: ['T'echnical | 'E'ditorial] T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] S Section: 2.7 Rationale/Explanation of issue: Alternative to LL3 and LL21 Proposal: Replace the current contents of section 2.7 with the following: Any host sending an IPv4 packet with a source and/or destination address in the 169.254/16 prefix MUST set the TTL in the IP header to 1. This includes multicast and broadcast packets with a source address in the 169.254/16 prefix." This requirement enables the normal behavior of Internet routers to preclude leaking traffic that is supposed to be confined to a single link out into the Internet when the local link has an attachment to the Internet that it did not discover. Setting TTL to 1 precludes mistaken forwarding of link-local traffic even when proxy-ARP is used on a link. Lengthy description of problem: see discussion of LL3 and LL21 From owner-zeroconf@merit.edu Thu Feb 27 12:57:22 2003 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 MAA14050 for ; Thu, 27 Feb 2003 12:57:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8F71B912C4; Thu, 27 Feb 2003 13:00:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5EBCC912C9; Thu, 27 Feb 2003 13:00:44 -0500 (EST) 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 69AE4912C4 for ; Thu, 27 Feb 2003 13:00:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 309C65E005; Thu, 27 Feb 2003 13:00:43 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by segue.merit.edu (Postfix) with ESMTP id 8B2175DE32 for ; Thu, 27 Feb 2003 13:00:42 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e32.co.us.ibm.com (8.12.7/8.12.2) with ESMTP id h1RI0QJi027486; Thu, 27 Feb 2003 13:00:27 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-198-57.mts.ibm.com [9.65.198.57]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h1RI0V7a062932; Thu, 27 Feb 2003 11:00:32 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h1RHw4X05604; Thu, 27 Feb 2003 12:58:04 -0500 Message-Id: <200302271758.h1RHw4X05604@cichlid.adsl.duke.edu> To: "Subrata Goswami" Cc: "'Bernard Aboba'" , zeroconf@merit.edu Subject: Re: LL24: Weaken the PRN requirement In-Reply-To: Message from sgoswami@umich.edu of "Thu, 27 Feb 2003 08:43:15 PST." <004b01c2de7f$537da030$1bc0140a@SGOSWAMIPCL> Date: Thu, 27 Feb 2003 12:58:04 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Subrata, What problem are you trying to fix with your issue and suggestion? Generating PRNs is not hard and works well in practice. The current wording doesn't seem to be a problem to implement. Why is this not a reasonable recommendation? Thomas From owner-zeroconf@merit.edu Thu Feb 27 13:17:10 2003 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 NAA14856 for ; Thu, 27 Feb 2003 13:17:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A6D6B9120D; Thu, 27 Feb 2003 13:20:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 729549121C; Thu, 27 Feb 2003 13:20:59 -0500 (EST) 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 8D0299120D for ; Thu, 27 Feb 2003 13:20:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6CD325E18C; Thu, 27 Feb 2003 13:20:58 -0500 (EST) 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 E7AC95E005 for ; Thu, 27 Feb 2003 13:20:57 -0500 (EST) 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 LAA06014 for ; Thu, 27 Feb 2003 11:20:56 -0700 (MST) 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 h1RIKtl11618 for ; Thu, 27 Feb 2003 19:20:55 +0100 (MET) Date: Thu, 27 Feb 2003 19:20:53 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: WG Action - 1 week to discuss [LL29] Link-local sources should specify TTL=1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The following issue is an alternative to LL3 and LL21. Please discuss this over the following week, ending March 6. We will make a consensus decision at that point between accepting issue LL3, LL21 or LL29. Please also see http://www.spybeam.org/ll29.html Description of issue: Link-local sources should specify TTL=1 Submitter name: John Schnizlein Submitter email address: jschnizl@cisco.com Date first submitted: 2003-02-27 Comment type: ['T'echnical | 'E'ditorial] T Priority: ['S' Must fix | '1' Should fix | '2' May fix ] S Section: 2.7 Rationale/Explanation of issue: Alternative to LL3 and LL21 Proposal: Replace the current contents of section 2.7 with the following: Any host sending an IPv4 packet with a source and/or destination address in the 169.254/16 prefix MUST set the TTL in the IP header to 1. This includes multicast and broadcast packets with a source address in the 169.254/16 prefix." This requirement enables the normal behavior of Internet routers to preclude leaking traffic that is supposed to be confined to a single link out into the Internet when the local link has an attachment to the Internet that it did not discover. Setting TTL to 1 precludes mistaken forwarding of link-local traffic even when proxy-ARP is used on a link. Lengthy description of problem: see discussion of LL3 and LL21 From owner-zeroconf@merit.edu Thu Feb 27 13:30:17 2003 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 NAA15407 for ; Thu, 27 Feb 2003 13:30:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 42BEA9121C; Thu, 27 Feb 2003 13:34:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 109CC91222; Thu, 27 Feb 2003 13:34:05 -0500 (EST) 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 0ED409121C for ; Thu, 27 Feb 2003 13:34:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id E42015DD94; Thu, 27 Feb 2003 13:34:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 5E10A5E1B2 for ; Thu, 27 Feb 2003 13:34:04 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h1RIV3J00615; Thu, 27 Feb 2003 12:31:03 -0600 (CST) Date: Thu, 27 Feb 2003 12:34:00 -0600 Subject: Re: WG Action - 1 week last call [LL3] TTL=244 on send, check on receive? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Erik Guttman From: Ted Lemon In-Reply-To: Message-Id: <0A06EC5E-4A82-11D7-AF3B-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit One somewhat sad note WRT this discussion is that the two legacy installed bases we have to contend with are Microsoft Windows, from Windows 98 through the present, and Apple. If I have a Windows 98 machine that can't communicate with an Apple because of this problem, I can't get an upgrade from Microsoft to fix the problem - Microsoft, AFAIK, does not support Win98 anymore, so I have to buy an upgrade to WinXP, at great cost, and great loss of performance. But chances are that I can get an upgrade from Apple, for a reasonable price. So I would rather have the solution that requires me to get an upgrade from Apple than the one that requires me to get an upgrade from Microsoft. This would seem extremely unfair to Apple, except that it is Apple that made the change requiring a TTL of 255. Requiring that the TTL be set to one seems like it's good enough - it prevents accidental leakage. Off-network attacks on IPv4ll-addressed nodes seem unlikely anyway - how does the remote device know which IP address to attack, since the IP address is not visible off-link? So while I agree that there is a minor technical advantage to Apple's change, I don't think it's worth the cost, and I don't agree with Stuart's cost/benefit analysis. From owner-zeroconf@merit.edu Thu Feb 27 14:57:50 2003 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 OAA19080 for ; Thu, 27 Feb 2003 14:57:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3D7E091276; Thu, 27 Feb 2003 15:01:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60A29912A9; Thu, 27 Feb 2003 15:01:26 -0500 (EST) 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 5EFE291264 for ; Thu, 27 Feb 2003 15:01:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id D02285DE1F; Thu, 27 Feb 2003 15:00:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by segue.merit.edu (Postfix) with ESMTP id 48BFE5DE00 for ; Thu, 27 Feb 2003 15:00:57 -0500 (EST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Thu, 27 Feb 2003 12:00:56 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 27 Feb 2003 12:00:54 -0800 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 27 Feb 2003 12:00:55 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 27 Feb 2003 12:00:58 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 27 Feb 2003 12:00:54 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Thu, 27 Feb 2003 12:00:54 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: WG Action - 1 week to discuss [LL29] Link-local sources should specify TTL=1 Date: Thu, 27 Feb 2003 12:00:50 -0800 Message-ID: Thread-Topic: WG Action - 1 week to discuss [LL29] Link-local sources should specify TTL=1 Thread-Index: AcLejQiwPF5TLsCiRBynTkxZJo02YQAC7vHg From: "Christian Huitema" To: "Erik Guttman" , X-OriginalArrivalTime: 27 Feb 2003 20:00:54.0221 (UTC) FILETIME=[EF6097D0:01C2DE9A] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA19080 My preference would be that the document makes no recommendation of TTL at all, or that if it makes any recommendation that recommendation could be overridden by the application. An example is LLMNR, which specifies a "check TTL=255 on receive" in order to avoid some specific attacks. This check is implemented by the application; the draft explains how to use existing API on various systems to set and check the TTL value. Another example is the Universal Plug & Play discovery protocol, SSDP. The implementation recommendation specifies that the TTL should be set to 4 or 1 (depending on the version) before sending a multicast packet; it does not specify a check on receive. The concern there was to avoid leakage, and the resulting network overload in some configurations. My proposed resolution is that the IPv4LL specification should not make any recommendation whatsoever regarding the TTL, and that if we make one it should be qualified by stating that this is a default value that can be overridden by the application. I would suggest accepting LL29, but rewriting it as: Any host sending an IPv4 packet with a source and/or destination address in the 169.254/16 prefix SHOULD set the TTL in the IP header to 1, unless another value is specifically requested by the application. This includes multicast and broadcast packets with a source address in the 169.254/16 prefix." -- Christian Huitema From owner-zeroconf@merit.edu Thu Feb 27 15:25:05 2003 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 PAA20567 for ; Thu, 27 Feb 2003 15:25:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D9FFB91230; Thu, 27 Feb 2003 15:28:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A5C5F91264; Thu, 27 Feb 2003 15:28:51 -0500 (EST) 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 C22F391230 for ; Thu, 27 Feb 2003 15:28:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id A6B5D5DE86; Thu, 27 Feb 2003 15:28:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 3D8AF5DE1F for ; Thu, 27 Feb 2003 15:28:50 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-454.cisco.com [10.82.241.198]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1RKSZP8000310; Thu, 27 Feb 2003 12:28:36 -0800 (PST) Message-Id: <4.3.2.7.2.20030227152207.01ff12a8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Feb 2003 15:28:48 -0500 To: "Christian Huitema" From: John Schnizlein Subject: RE: WG Action - 1 week to discuss [LL29] Link-local sources should specify TTL=1 Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk This is a good suggestion. It might also provide for interoperability, for example, where a Windows LL host wants to mount an AppleShare file-store, it could use the TTL in legacy Macintosh implementations. The default value protects the Internet; applications that want to can accommodate the historical choices of pre-standard values. John At 03:00 PM 2/27/2003, Christian Huitema wrote: >.... I would suggest accepting LL29, but rewriting it as: > > Any host sending an IPv4 packet with a source and/or destination > address in the 169.254/16 prefix SHOULD set the TTL in the IP > header to 1, unless another value is specifically requested by the > application. This includes multicast and broadcast packets with a > source address in the 169.254/16 prefix." From owner-zeroconf@merit.edu Thu Feb 27 15:54:13 2003 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 PAA23238 for ; Thu, 27 Feb 2003 15:54:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DC3F79125B; Thu, 27 Feb 2003 15:57:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADE5391260; Thu, 27 Feb 2003 15:57:59 -0500 (EST) 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 AA09E9125B for ; Thu, 27 Feb 2003 15:57:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 950545DE1F; Thu, 27 Feb 2003 15:57:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 5B0305DE40 for ; Thu, 27 Feb 2003 15:57:57 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1RKwdaj001596; Thu, 27 Feb 2003 22:58:40 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h1RKwa8j001593; Thu, 27 Feb 2003 22:58:36 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: WG Action - 1 week to discuss [LL29] Link-local sources should specify TTL=1 From: Mika Liljeberg To: Christian Huitema Cc: Erik Guttman , zeroconf@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046379514.1247.14.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 27 Feb 2003 22:58:35 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-02-27 at 22:00, Christian Huitema wrote: > My proposed resolution is that the IPv4LL specification should not make > any recommendation whatsoever regarding the TTL, and that if we make one > it should be qualified by stating that this is a default value that can > be overridden by the application. I would suggest accepting LL29, but > rewriting it as: > > Any host sending an IPv4 packet with a source and/or destination > address in the 169.254/16 prefix SHOULD set the TTL in the IP > header > to 1, unless another value is specifically requested by the > application. This includes multicast and broadcast packets with a > source address in the 169.254/16 prefix." I support this proposal. Setting TTL=1 on send, no check on receive is the conservative and compatible approach to take. Checking TTL=255 on receive is a bogus idea for two reasons: 1) It's damn nigh impossible to send a packet with a 169.254/16 destination address from an outside network. An attacker is much better off choosing a routable destination address. 2) Every host should implement adequate security measures, regardless of what destination address the attacker is trying to use. MikaL From owner-zeroconf@merit.edu Thu Feb 27 18:32:41 2003 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 SAA27742 for ; Thu, 27 Feb 2003 18:32:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3C3DB91218; Thu, 27 Feb 2003 18:36:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C1269121D; Thu, 27 Feb 2003 18:36:28 -0500 (EST) 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 F1FFF91218 for ; Thu, 27 Feb 2003 18:36:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id D838A5DE01; Thu, 27 Feb 2003 18:36:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by segue.merit.edu (Postfix) with ESMTP id 815335DDBD for ; Thu, 27 Feb 2003 18:36:27 -0500 (EST) Received: from robotron.gpcc.itd.umich.edu (robotron.gpcc.itd.umich.edu [141.211.2.207]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id SAA07797; Thu, 27 Feb 2003 18:36:23 -0500 (EST) Received: from localhost (sgoswami@localhost) by robotron.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id SAA01714; Thu, 27 Feb 2003 18:36:23 -0500 (EST) Date: Thu, 27 Feb 2003 18:36:23 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@robotron.gpcc.itd.umich.edu To: Thomas Narten Cc: "'Bernard Aboba'" , Subject: Re: LL24: Weaken the PRN requirement In-Reply-To: <200302271758.h1RHw4X05604@cichlid.adsl.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Hi Thomas, I am not saying do not use PRN. I would like the selection algorithm to be kept open for other ones beside PRN. The PRN SHOULD be the recommended way to determine the LLv4 address, but if the LL node chooses so it can use something else. I have given example of an iterative algorithm in my previous email - I would like the draft to not preclude such solutions. Subrata On Thu, 27 Feb 2003, Thomas Narten wrote: > Subrata, > > What problem are you trying to fix with your issue and suggestion? > > Generating PRNs is not hard and works well in practice. The current > wording doesn't seem to be a problem to implement. Why is this not a > reasonable recommendation? > > Thomas > From owner-zeroconf@merit.edu Fri Feb 28 05:38:28 2003 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 FAA19756 for ; Fri, 28 Feb 2003 05:38:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C041691252; Fri, 28 Feb 2003 05:42:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85D0A91259; Fri, 28 Feb 2003 05:42:16 -0500 (EST) 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 6D97891252 for ; Fri, 28 Feb 2003 05:42:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4CD625DE1A; Fri, 28 Feb 2003 05:42:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id B3C1E5DE19 for ; Fri, 28 Feb 2003 05:42:13 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1SAg3O25624; Fri, 28 Feb 2003 17:42:03 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1SAfYo03445; Fri, 28 Feb 2003 17:41:36 +0700 (ICT) From: Robert Elz To: "Subrata Goswami" Cc: "'Bernard Aboba'" , zeroconf@merit.edu Subject: Re: LL24: Weaken the PRN requirement In-Reply-To: <004b01c2de7f$537da030$1bc0140a@SGOSWAMIPCL> References: <004b01c2de7f$537da030$1bc0140a@SGOSWAMIPCL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Feb 2003 17:41:34 +0700 Message-ID: <3443.1046428894@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 27 Feb 2003 08:43:15 -0800 From: "Subrata Goswami" Message-ID: <004b01c2de7f$537da030$1bc0140a@SGOSWAMIPCL> | Actually I am trying to say that if there is a way for a LL nodes to | determine the other LL nodes' LLv4 addresses, then it does not need | to use the PRN. Even given that there was a way, this doesn't work, as we want 20 or 30 (or 200 or 300) nodes all running the algorithm at the same time to start at (mostly) different values - if they all somehow just knew what LL addresses were assigned currently, and just picked some unallocated one algorithmically, then they're all likely to pick the same one (given that most of them will be running the same code on the same kind of processor). When that happens, at most one of them can succeed to obtain that address, after which they all have to start again, now knowing (perhaps) one more address that has been allocated, and all allocating the next one in their sequence. This just doesn't work. What's more .. | An alternative algorithm is provided below - although it is somewhat | extreme it would work. Work in the sense that it would find out what is in use, currently, perhaps yes. Work in that the network would survive such an attack I doubt ... Up to 64K broadcast packets from every host as it starts is not something that you'd want to see happening on your net. Using random numbers avoids these problems (given a big enough range, which we have here). It is a common technique, and works well. What's more, it is enormously cheaper for the node, and the net, than attempting to find everything that is allocated. There is no reason to even allow different methods (except perhaps, for real random numbers instead of PRNs). kre From owner-zeroconf@merit.edu Fri Feb 28 05:45:50 2003 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 FAA19880 for ; Fri, 28 Feb 2003 05:45:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9518991259; Fri, 28 Feb 2003 05:49:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60B1891266; Fri, 28 Feb 2003 05:49:38 -0500 (EST) 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 5ACBB91259 for ; Fri, 28 Feb 2003 05:49:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 439955DE15; Fri, 28 Feb 2003 05:49:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 9696D5DDDF for ; Fri, 28 Feb 2003 05:49:31 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1SAnFO00717; Fri, 28 Feb 2003 17:49:16 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1SAn9o03457; Fri, 28 Feb 2003 17:49:09 +0700 (ICT) From: Robert Elz To: "Christian Huitema" Cc: zeroconf@merit.edu Subject: Re: WG Action - 1 week to discuss [LL29] Link-local sources should specify TTL=1 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Feb 2003 17:49:09 +0700 Message-ID: <3455.1046429349@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 27 Feb 2003 12:00:50 -0800 From: "Christian Huitema" Message-ID: | My proposed resolution is that the IPv4LL specification should not make | any recommendation whatsoever regarding the TTL, That's LL21, which I also believe is the best way. | and that if we make one | it should be qualified by stating that this is a default value that can | be overridden by the application. Agreed. Which certainly rules out TTL checking by recipients (except perhaps specific protocols that impose extra rules, which is where such things should be done). | I would suggest accepting LL29, but rewriting it as: I could live with that, though TTL=1 (except perhaps in multicast) achieves nothing (the packets don't go to routers anyway, so nothing is going to be considering forwarding them). TTL's for multicast are a whole other world, but for sure, using anything other than TTL=1 for a multicast from a LL source addr would make no sense. Broadcast doesn't matter, those packets don't get forwarded anyway, regardless of TTL or source addr (or if the dest addr is 169.254.255.255). How about "MAY set the TTL in the IP header to 1 unless..." for unicast packets, and "MUST set the TTL in the IP header to 1" for multicast ? That is, if we have to say anything at all about TTL's, which I would still prefer not to do at all. kre From owner-zeroconf@merit.edu Fri Feb 28 08:23:50 2003 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 IAA26794 for ; Fri, 28 Feb 2003 08:23:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D22FA9129D; Fri, 28 Feb 2003 08:27:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 656819129E; Fri, 28 Feb 2003 08:27:37 -0500 (EST) 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 34F669129D for ; Fri, 28 Feb 2003 08:27:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1DDE85DE07; Fri, 28 Feb 2003 08:27:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id A6A815DDF7 for ; Fri, 28 Feb 2003 08:27:35 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-373.cisco.com [10.82.241.117]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1SDRKP8006583; Fri, 28 Feb 2003 05:27:21 -0800 (PST) Message-Id: <4.3.2.7.2.20030228082022.020a23a8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Feb 2003 08:27:32 -0500 To: Robert Elz From: John Schnizlein Subject: Re: WG Action - 1 week to discuss [LL29] Link-local sources should specify TTL=1 Cc: zeroconf@merit.edu In-Reply-To: <3455.1046429349@munnari.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk Specifying that hosts must not send LL traffic to routers, which appears to be the basis of the assumption that LL traffic does not go to routers, makes them responsible for something they do not actually control. Since proxy-ARP gives the host a reply that appears to be that of the ultimate host, but is a router, the originating host cannot enforce the requirement. Relying on a mechanism that is known not to work in a well-know case is not sufficient protection against LL traffic leaking out. John At 05:49 AM 2/28/2003, Robert Elz wrote: >I could live with that, though TTL=1 (except perhaps in multicast) >achieves nothing (the packets don't go to routers anyway, so nothing >is going to be considering forwarding them). TTL's for multicast >are a whole other world, but for sure, using anything other than >TTL=1 for a multicast from a LL source addr would make no sense. >Broadcast doesn't matter, those packets don't get forwarded anyway, >regardless of TTL or source addr (or if the dest addr is 169.254.255.255). > >How about "MAY set the TTL in the IP header to 1 unless..." for unicast >packets, and "MUST set the TTL in the IP header to 1" for multicast ? >That is, if we have to say anything at all about TTL's, which I would >still prefer not to do at all. From owner-zeroconf@merit.edu Fri Feb 28 10:22:51 2003 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 KAA01371 for ; Fri, 28 Feb 2003 10:22:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E1227912A2; Fri, 28 Feb 2003 10:26:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8889912A4; Fri, 28 Feb 2003 10:26:38 -0500 (EST) 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 7CBC5912A2 for ; Fri, 28 Feb 2003 10:26:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6D7105DE53; Fri, 28 Feb 2003 10:26:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 01B5B5DE40 for ; Fri, 28 Feb 2003 10:26:34 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h1SFQWO04683 for ; Fri, 28 Feb 2003 22:26:32 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h1SFQPo04708 for ; Fri, 28 Feb 2003 22:26:25 +0700 (ICT) From: Robert Elz To: zeroconf@merit.edu Subject: LL21 vs LL29 In-Reply-To: <4.3.2.7.2.20030228082022.020a23a8@wells.cisco.com> References: <4.3.2.7.2.20030228082022.020a23a8@wells.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Feb 2003 22:26:25 +0700 Message-ID: <4706.1046445985@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 28 Feb 2003 08:27:32 -0500 From: John Schnizlein Message-ID: <4.3.2.7.2.20030228082022.020a23a8@wells.cisco.com> | Relying on a mechanism that is known not to work in a well-know | case is not sufficient protection against LL traffic leaking out. But why does it matter? That is, who cares? Nothing in the text in LL21 says that a host should not set TTL==1, and for a host that knows it is doing link local, and so forwarding off link should never happen anyway, that probably makes lots of sense. An occasional packet bound for nowhere, in a somewhat bizarre scenario (how many routers do you know that proxy-arp for 169.254.*.* ?) doesn't seem to me like sufficient justification to add this as an extra requirement. This is particularly as we are told there are scenarios now where hosts have to send with TTL==255 for their packets to be received, so it is quite likely that some implementations are going to want to at least allow that - the gain from TTL=1 isn't enough to prohibit it IMO. kre From owner-zeroconf@merit.edu Fri Feb 28 15:59:11 2003 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 PAA13182 for ; Fri, 28 Feb 2003 15:59:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6774D912B0; Fri, 28 Feb 2003 16:00:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE3B8912B2; Fri, 28 Feb 2003 16:00:14 -0500 (EST) 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 E437F912B0 for ; Fri, 28 Feb 2003 16:00:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id EB9CB5DEAE; Fri, 28 Feb 2003 16:00:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id AD6B85DEAD for ; Fri, 28 Feb 2003 16:00:10 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-937.cisco.com [10.82.243.169]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h1SKxtP8011446; Fri, 28 Feb 2003 12:59:56 -0800 (PST) Message-Id: <4.3.2.7.2.20030228155032.021a5ad8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Feb 2003 16:00:06 -0500 To: Robert Elz From: John Schnizlein Subject: Re: LL21 vs LL29 Cc: zeroconf@merit.edu In-Reply-To: <4706.1046445985@munnari.OZ.AU> References: <4.3.2.7.2.20030228082022.020a23a8@wells.cisco.com> <4.3.2.7.2.20030228082022.020a23a8@wells.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk At 10:26 AM 2/28/2003, Robert Elz wrote: >(how many routers do you know that proxy-arp for 169.254.*.* ?) My concern regards legacy routers that proxy for all addresses outside the subnet for which the interface is configured. This is a "historic" method of avoiding router discovery that was widely used on stub networks when listening to the (RIP) routing protocol was discouraged. While I would prefer that hosts get reasonable parameters for configuration of a default gateway, I consider it rude to cause these old network configurations that used to be causing no trouble to start spewing LL traffic out into the Internet. Expecting the people who have this old configuration to change it to "protect the Internet from trash" coming from their subnets is not reasonable. Does using TTL=1, which rather blatantly declares "no forwarding" on link-local traffic have any down side, after adjusted as Christian proposed for applications that "know better"? John