From owner-zeroconf@merit.edu Thu Apr 3 11:16: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 LAA27742 for ; Thu, 3 Apr 2003 11:16:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F37C5912D1; Thu, 3 Apr 2003 11:19:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7611912D4; Thu, 3 Apr 2003 11:19: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 0C176912D1 for ; Thu, 3 Apr 2003 11:19:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id E38235DE00; Thu, 3 Apr 2003 11:19:03 -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 5D21C5DDEB for ; Thu, 3 Apr 2003 11:19:03 -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 IAA11825 for ; Thu, 3 Apr 2003 08:19:02 -0800 (PST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h33GIxl04340; Thu, 3 Apr 2003 18:19:00 +0200 (MEST) Date: Thu, 3 Apr 2003 18:18:57 +0200 (CEST) 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 last call [LL12] Does shorter timeouts for specific link technology lead to problems? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk This item is entering a 1 week last call discussion period, ending Apr 10, 2003. Please send a comment to the working group list indicating whether you accept or reject the proposal, including more information if appropriate. Please use the subject line: [LL12] Does shorter timeouts for specific link technology lead to problems? ==================================================================== Note that you are asked to choose between LL12 and LL20. ==================================================================== See also http://www.spybeam.org/ll12.html Description of Issue Does shorter timeouts for specific link technology text lead to problems? 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/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.3 Rationale/Explanation of issue: The text in the document is bad advice in known cases. Lengthy description of problem: There is text in section 2.3 which suggests shorter time outs can be used for 802 media. I suggested some new, less specific text which Erik Nordmark had continuing issues with. > 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. Later, Erik sent If we talk about the protocol and not the text, I know of two interesting cases on IEEE 802 media: 1. No spanning tree on the port to which you connect, or the port has been enabled for a long time before the address claim is done. In this case it probably makes sense to have slightly shorter timers i.e. a few packets over a few seconds might suffice. Thus 3 seconds instead of 8. 2. Spanning tree on the port to which you connect. If the address claim is done immediately after bringing up the link the host might as well wait for 45 seconds before sending any packet. I don't know if the host can tell the difference between #1 and #2 - or if it can "ask" (at the Ethernet layer) if the switch is running STP. With RSTP I think the problem goes away and the approach used in #1 can be used. Requested Change: Remove the text regarding shortening the timing for different media. This area is not well enough understood to make any general recommendations. Erik Guttman Zeroconf WG chair From owner-zeroconf@merit.edu Thu Apr 3 11:17: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 LAA27761 for ; Thu, 3 Apr 2003 11:17:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F3CD1912D6; Thu, 3 Apr 2003 11:19:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C0ECB912D5; Thu, 3 Apr 2003 11:19: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 C07E0912D4 for ; Thu, 3 Apr 2003 11:19:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id AE5C95DE00; Thu, 3 Apr 2003 11:19:26 -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 30BB95DDEB for ; Thu, 3 Apr 2003 11:19:26 -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 JAA29119 for ; Thu, 3 Apr 2003 09:19:25 -0700 (MST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h33GJNl04361; Thu, 3 Apr 2003 18:19:23 +0200 (MEST) Date: Thu, 3 Apr 2003 18:19:20 +0200 (CEST) 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 last call [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 item is entering a 1 week last call discussion period, ending Apr 10, 2003. Please send a comment to the working group list indicating whether you accept or reject the proposal, including more information if appropriate. Please use the subject line: [LL13] If the destination is a global multicast address a host SHOULD use a global source address ======================================================================= In light of LL23, this goes without saying. Do you agree? In case LL23 gets revisited, please do express your opinion of this item. ======================================================================= 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. Erik Guttman Zeroconf WG chair From owner-zeroconf@merit.edu Thu Apr 3 11:17: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 LAA27775 for ; Thu, 3 Apr 2003 11:17:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 06CF5912D4; Thu, 3 Apr 2003 11:19:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C21AC912D3; Thu, 3 Apr 2003 11:19: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 4F0D5912D5 for ; Thu, 3 Apr 2003 11:19:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 399125DDEB; Thu, 3 Apr 2003 11:19:38 -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 A3A5F5DE00 for ; Thu, 3 Apr 2003 11:19: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 IAA04590 for ; Thu, 3 Apr 2003 08:19:36 -0800 (PST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h33GJYl04395; Thu, 3 Apr 2003 18:19:34 +0200 (MEST) Date: Thu, 3 Apr 2003 18:19:31 +0200 (CEST) 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 last call [LL14] Add security consideration for the threat if the same address is used for multiple interfaces - force reconfiguration will effect multiple links Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk This item is entering a 1 week last call discussion period, ending Apr 10, 2003. Please send a comment to the working group list indicating whether you accept or reject the proposal, including more information if appropriate. Please use the subject line: [LL14] Add security consideration for the threat ... ====================================================================== If LL15 is accepted, this security consideration no longer applies, right? ====================================================================== Description of Issue Add security consideration for the threat if the same address is used for multiple interfaces - force reconfiguration will effect multiple links 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 5 Rationale/Explanation of issue: Lengthy description of problem: 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. Requested Change: Change text to: 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 not necessary to ensure that all local interfaces have distinct addresses, nor to ensure that all local interfaces have addresses that are distinct with respect to ALL links to which the host has connectivity. Such a host may choose to initially configure all interfaces with a single common IPv4 link-local address, and defend that address on all interfaces, but in the event that an address conflict is detected on a particular link, only the interface(s) directly connected to that link should select a new address as described in Section 2. Reconfiguring all interfaces to a new common IPv4 link-local address could needlessly break TCP connections that may have already been established on other links where there is no address conflict. Erik Guttman Zeroconf WG chair From owner-zeroconf@merit.edu Thu Apr 3 11: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 LAA27796 for ; Thu, 3 Apr 2003 11:17:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2E75D912D5; Thu, 3 Apr 2003 11:19:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F4033912D2; Thu, 3 Apr 2003 11: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 BECCD912D3 for ; Thu, 3 Apr 2003 11:19:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9EA025DE00; Thu, 3 Apr 2003 11:19: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 484C25DDEB for ; Thu, 3 Apr 2003 11:19: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 JAA19258 for ; Thu, 3 Apr 2003 09:19:51 -0700 (MST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h33GJnl04458; Thu, 3 Apr 2003 18:19:49 +0200 (MEST) Date: Thu, 3 Apr 2003 18:19:46 +0200 (CEST) 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 last call [LL15] Algorithm for claim/defend will break if multiple interfaces Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk This item is entering a 1 week last call discussion period, ending Apr 10, 2003. Please send a comment to the working group list indicating whether you accept or reject the proposal, including more information if appropriate. Please use the subject line: [LL15] Algorithm for claim/defend will break if multiple interfaces ----------------------------------------------------------------------- Please consider LL30. If we accept LL30, then this issue should be rejected. ----------------------------------------------------------------------- Description of Issue Algorithm for claim/defend will break if multiple interfaces are connected to the same link 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 3.2 Rationale/Explanation of issue: Lengthy description of problem: section 3.2 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. 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. Erik Guttman suggests Each interface should be assigned a different v4LL address and can then operate independently. Requested Change: Replace Section 3.2 text with A host MUST run the address selection and defense algorithm distinctly on each interface supporting IPv4 link-local configuration. This ensures that in the case where more than one of the interfaces are on the same link the algorithm will terminate. Otherwise, the host may detect collisions from its own allocations and cause the claim and defend algorithm to fail. Erik Guttman Zeroconf WG chair From owner-zeroconf@merit.edu Thu Apr 3 11:17: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 LAA27817 for ; Thu, 3 Apr 2003 11:17:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E2627912D2; Thu, 3 Apr 2003 11:20:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A5640912D3; Thu, 3 Apr 2003 11:20: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 51D3B912D2 for ; Thu, 3 Apr 2003 11:20:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3B5725DE00; Thu, 3 Apr 2003 11:20:06 -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 A127C5DE2E for ; Thu, 3 Apr 2003 11:20:05 -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 IAA12694 for ; Thu, 3 Apr 2003 08:20:04 -0800 (PST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h33GK2l04505; Thu, 3 Apr 2003 18:20:02 +0200 (MEST) Date: Thu, 3 Apr 2003 18:19:59 +0200 (CEST) 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 last call [LL20] Alternate text for 'Does shorter timeouts for specific link technology lead to problems?' Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk This item is entering a 1 week last call discussion period, ending Apr 10, 2003. Please send a comment to the working group list indicating whether you accept or reject the proposal, including more information if appropriate. Please use the subject line: [LL20] Alternate text for 'Does shorter timeouts for specific link technology lead to problems?' ----------------------------------------------------------------- see also http://www.spybeam.org/ll20.html Description of Issue Alternate text for 'Does shorter timeouts for specific link technology lead to problems?' Submitter Name Stuart Cheshire Submitter Email Address cheshire@apple.com Date first submitted 8 Feb 2003 Reference http://www.spybeam.org/ll12.html Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section 2.3 Rationale/Explanation of issue: See LL12 Lengthy description of problem: See LL12 Requested Change: The time values specified above result in a delay of 8-10 seconds before a chosen IP address may be used. 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. There may be additional delays before a host is able to send and receive datagrams on a link. Some switches may only forward packets after several seconds. Implementors should exercise some restraint, therefore, in setting timers to short, aggressive values. If hosts configure IPv4 link-local addresses before these addresses can be defended, there is an increased risk of collision once the host is able to send and receive datagrams on the link. For a desktop machine on Ethernet, long delays before network access is established may not be a great problem, but for other types of device, particularly portable hand-held wireless devices, a ten-second delay before networking services becomes available may not be acceptable. For this reason, shorter time values may be used on network technologies that allow the device to determine when the link has become active and can be reasonably trusted to deliver packets reliably. On these network technologies the recommended time values are: The host should first wait for a random time interval selected uniformly in the range 0-200 milliseconds, and then send four probe packets, waiting 200 milliseconds after each probe, making a total delay of 800-1000 milliseconds before a chosen IP address may be used. Erik Guttman Zeroconf WG chair From owner-zeroconf@merit.edu Thu Apr 3 11:18: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 LAA27850 for ; Thu, 3 Apr 2003 11:18:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 12CB4912D3; Thu, 3 Apr 2003 11:20:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D431A912D7; Thu, 3 Apr 2003 11:20: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 7BED6912D3 for ; Thu, 3 Apr 2003 11:20:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 66D045DE00; Thu, 3 Apr 2003 11:20: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 19DA25DDEB for ; Thu, 3 Apr 2003 11:20:26 -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 JAA19790 for ; Thu, 3 Apr 2003 09:20:24 -0700 (MST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h33GKMl04632; Thu, 3 Apr 2003 18:20:23 +0200 (MEST) Date: Thu, 3 Apr 2003 18:20:20 +0200 (CEST) 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 last call [LL30] Use of link-local configuration on more than one link is NOT RECOMMENDED Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk This item is entering a 1 week last call discussion period, ending Apr 10, 2003. Please send a comment to the working group list indicating whether you accept or reject the proposal, including more information if appropriate. Please use the subject line: [LL30] Use of link-local configuration on more than one link is NOT RECOMMENDED see also http://www.spybeam.org/ll30.html Description of Issue Use of link-local configuration on more than one link is NOT RECOMMENDED Submitter Name Erik Guttman Submitter Email Address erik.guttman@sun.com Date first submitted 03 Apr 2003 Reference Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] 1 Section 3 (and all subsections of 3) Rationale/Explanation of issue: Several technical issues remain unresolved regarding the use of link-local autoconfiguration of multiple interfaces. We should recommend that this not done, or if it is, that these are not easily solved problems. Lengthy description of problem: The specification currently discusses use of the protocol on multihomed hosts. Section 3 offers only a few complex solutions to the problems it raises, each requiring sophisticated use of application programming interfaces which this specification has no control over. Further, this mechanism (binding TCP connections to interfaces explicitely, and keeping interface, source and destination tuples associated in applications) will require applications to be rewritten. This is a major concern (see issues LL4 and LL5). For the sake of clarity, brevity and the best chance that stable interoperable protocol implementations will result, we should remove this section all together and replace it with one which simply recommens that ipv4 LL autoconfiguration be done on a single interface unless mechanisms can be used to alleviate some known problems. Note that the 'big issue' of address ambiguity is not addressed by this issue. A host which is multihomed may encounter hosts on different links which have the same address, whether or not the host supports LL configuration on those distinct interfaces. Consider H1(a)-------(b)H2(c)------(a)H3 H1 and H3 are both configured with LL address (a). They are on distinct links. H2 has configured (non-link-local) addresses. H2 knows to send to link-local destinations directly. (H2 will not forward packets to a router which have link-local prefix destinations. Rather it will use ARP and then send the packet directly to the destination.) H2 uses SLP to discover a service on both links it is connected to. Both H1 and H3 support the service and respond. H2 now has locators for address (a) which are ambiguous - unless the response to the SLP request keeps the interface information (from which the request originated). These issues are spelled out and addressed in RFC 3111). So - unfortunately, this issue does not eliminate the scoped address problem. Requested Change: Replace section 3 and subsections with the following text: It is RECOMMENDED that configuration of link-local addresses be done on only one active interface at a time. This avoids a number of known problems: 1. Address ambiguity: A host H1 has addresses A1 and A2 configured on its interfaces to L1 and L2 respectively. There is a host H2 with address A2 on L1. H1 cannot easily determine whether A2 should be used to communicate with itself or with the host H2. 2. Complexity in address selection: A multihomed host may be attached to the same link with more than interface. This complicates the claim and defend algorithm somewhat since a host may defend against itself if the algorithm is implemented in a flawed manner. Erik Guttman Zeroconf WG Chair From owner-zeroconf@merit.edu Thu Apr 3 12:21: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 MAA00831 for ; Thu, 3 Apr 2003 12:21:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 65AD5912DF; Thu, 3 Apr 2003 12:23:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 32BED912E0; Thu, 3 Apr 2003 12:23: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 394CA912DF for ; Thu, 3 Apr 2003 12:23:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 238325DE3D; Thu, 3 Apr 2003 12:23: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 902615DDE1 for ; Thu, 3 Apr 2003 12:23: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 JAA23090 for ; Thu, 3 Apr 2003 09:23:34 -0800 (PST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h33HNVl07689; Thu, 3 Apr 2003 19:23:32 +0200 (MEST) Date: Thu, 3 Apr 2003 19:23:29 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: Erik Guttman Cc: zeroconf@merit.edu, erik.nordmark@sun.com Subject: [LL30] Use of link-local configuration on more than one link is NOT RECOMMENDED In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The title of this issue is unfortunate - it should have been "Use of link-local configuration on more than one interface is NOT RECOMMENDED" Sorry, Erik From owner-zeroconf@merit.edu Fri Apr 4 06:10: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 GAA14152 for ; Fri, 4 Apr 2003 06:10:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 28FF09123B; Fri, 4 Apr 2003 06:12:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0D2A9123C; Fri, 4 Apr 2003 06: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 E4DE99123B for ; Fri, 4 Apr 2003 06:12:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id C36BB5DEDC; Fri, 4 Apr 2003 06:12: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 876695DE95 for ; Fri, 4 Apr 2003 06:12: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 A0E7D599AD; Fri, 4 Apr 2003 12:12:35 +0100 (BST) Message-ID: <031301c2fa9b$14232e40$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , Cc: References: Subject: Re: WG Action - 1 week last call [LL13] If the destination is a global multicast address a host SHOULD use a global source address Date: Fri, 4 Apr 2003 11:12:27 -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 > 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. What is a link-local multicast address? how would the host know whether a multicast address is being routed? If a LL multicast means the 24.0.0/24 link-local scoped multicast prefix then the text should say so with a reference. Philip From owner-zeroconf@merit.edu Fri Apr 4 06:12: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 GAA14200 for ; Fri, 4 Apr 2003 06:12:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AB3169123C; Fri, 4 Apr 2003 06:14:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B05C9123D; Fri, 4 Apr 2003 06:14: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 8F54D9123C for ; Fri, 4 Apr 2003 06:14:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A51E5DF2A; Fri, 4 Apr 2003 06:14: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 2EBB75DE95 for ; Fri, 4 Apr 2003 06:14: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 E951259916; Fri, 4 Apr 2003 12:14:44 +0100 (BST) Message-ID: <031e01c2fa9b$61342f40$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , Cc: References: Subject: Re: WG Action - 1 week last call [LL14] Add security consideration for the threat if the same address is used for multiple interfaces - force reconfiguration will effect multiple links Date: Fri, 4 Apr 2003 11:14:37 -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 LL14 Philip From owner-zeroconf@merit.edu Fri Apr 4 06:28: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 GAA14440 for ; Fri, 4 Apr 2003 06:28:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3AABE9123D; Fri, 4 Apr 2003 06:30:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A91B9123E; Fri, 4 Apr 2003 06: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 EA5D69123D for ; Fri, 4 Apr 2003 06:30:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id C44FB5DF30; Fri, 4 Apr 2003 06:30:40 -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 734575DF2C for ; Fri, 4 Apr 2003 06:30:40 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA21809; Fri, 4 Apr 2003 04:30:39 -0700 (MST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h34BUbS08610; Fri, 4 Apr 2003 13:30:37 +0200 (MEST) Date: Fri, 4 Apr 2003 13:30:34 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: WG Action - 1 week last call [LL14] Add security consideration for the threat if the same address is used for multiple interfaces - force reconfiguration will effect multiple links To: Ted Lemon Cc: Erik Guttman , zeroconf@merit.edu, Erik Nordmark 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 > The case of multicast to global multicast addresses is handled by > routing - not a problem. There are APIs for multicast like the IP_MULTICAST_IF and IP_ADD_MEMBERSHIP which indentify the interface on which to send and join, respectively, by using an IPv4 address assigned to the interface. Thus *if* there are multiple interfaces that have only link-local addresses, two or more of those addresses are identical for different interfaces on the box, and there are applications which want to choose which interface to use for multicast using the above type of API, then there is in fact a problem. FYI: In IPv6 the corresponding APIs use interface indicies to identify the interfaces. Erik From owner-zeroconf@merit.edu Fri Apr 4 06:29: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 GAA14460 for ; Fri, 4 Apr 2003 06:29:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 18EC29123E; Fri, 4 Apr 2003 06:31:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02F519123F; Fri, 4 Apr 2003 06:31: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 9FDC39123E for ; Fri, 4 Apr 2003 06:31:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 898455DF32; Fri, 4 Apr 2003 06:31: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 64E0D5DF2C for ; Fri, 4 Apr 2003 06:31: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 103935991D for ; Fri, 4 Apr 2003 12:31:33 +0100 (BST) Message-ID: <033b01c2fa9d$ba04a030$131010ac@aldebaran> From: "Philip Nye" To: References: <031e01c2fa9b$61342f40$131010ac@aldebaran> Subject: Re: WG Action - 1 week last call [LL14] Add security consideration for the threat if the same address is used for multiple interfaces - force reconfiguration will effect multiple links Date: Fri, 4 Apr 2003 11:31: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: "Philip Nye" > I support LL14 I thought I did until I read LL15 and LL30 better. I shouldn't be in so much hurry! - see my reply to LL30. Philip From owner-zeroconf@merit.edu Fri Apr 4 06:44: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 GAA15363 for ; Fri, 4 Apr 2003 06:44:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E67A89123F; Fri, 4 Apr 2003 06:46:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 755FA91240; Fri, 4 Apr 2003 06:46: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 07C1A9123F for ; Fri, 4 Apr 2003 06:46:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id C42065DF37; Fri, 4 Apr 2003 06:46: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 5D6C85DF2C for ; Fri, 4 Apr 2003 06:46: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 D6B1E599A3 for ; Fri, 4 Apr 2003 12:46:07 +0100 (BST) Message-ID: <034701c2fa9f$c3703510$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: Subject: LL20, LL12 Date: Fri, 4 Apr 2003 11:45: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 I don't know enough to decide between LL20 and LL12. The text of LL20 strongly suggests (without actually stating) that a wireless connection is a case where time intervals could be shortened. This is clearly not true - 802.11 APs frequently bridge (rather than route) to wired ethernet and connections may be subject to all sorts of restrictions arising indirectly from the wired infrastructure. If LL20 is to be adopted, I think the text needs changing to really emphasise the fact that the host using shorter times needs "to determine when the link has become active and can be reasonably trusted to deliver packets reliably". I don't have any knowledge of how the host might determine this. LL12 on the other hand points out that the chosen time of 8-10 seconds might be inadequate with spanning tree switches but makes no attempt to remedy this. Philip ----- Original Message ----- From: "Erik Guttman" To: Cc: Sent: Thursday, April 03, 2003 4:19 PM Subject: WG Action - 1 week last call [LL20] Alternate text for 'Does shorter timeouts for specific link technology lead to problems?' > > This item is entering a 1 week last call discussion period, ending Apr > 10, 2003. Please send a comment to the working group list indicating > whether you accept or reject the proposal, including more information if > appropriate. Please use the subject line: > > [LL20] Alternate text for 'Does shorter timeouts for specific link > technology lead to problems?' > > ----------------------------------------------------------------- > see also http://www.spybeam.org/ll20.html > > Description of Issue Alternate text for 'Does shorter timeouts for > specific link technology lead to problems?' > Submitter Name Stuart Cheshire > Submitter Email Address cheshire@apple.com > Date first submitted 8 Feb 2003 > Reference > http://www.spybeam.org/ll12.html > Comment Type ['T'echnical | 'E'ditorial] T > Priority ['S' Must fix | '1' Should fix | '2' May fix ] S > Section 2.3 > Rationale/Explanation of issue: > See LL12 > Lengthy description of problem: > See LL12 > Requested Change: > > The time values specified above result in a delay of 8-10 seconds before > a chosen IP address may be used. 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. > > There may be additional delays before a host is able to send and receive > datagrams on a link. Some switches may only forward packets after > several seconds. Implementors should exercise some restraint, therefore, > in setting timers to short, aggressive values. If hosts configure IPv4 > link-local addresses before these addresses can be defended, there is an > increased risk of collision once the host is able to send and receive > datagrams on the link. > > For a desktop machine on Ethernet, long delays before network access is > established may not be a great problem, but for other types of device, > particularly portable hand-held wireless devices, a ten-second delay > before networking services becomes available may not be acceptable. For > this reason, shorter time values may be used on network technologies > that allow the device to determine when the link has become active and > can be reasonably trusted to deliver packets reliably. On these network > technologies the recommended time values are: The host should first wait > for a random time interval selected uniformly in the range 0-200 > milliseconds, and then send four probe packets, waiting 200 milliseconds > after each probe, making a total delay of 800-1000 milliseconds before a > chosen IP address may be used. > > > Erik Guttman > Zeroconf WG chair > > > > > > From owner-zeroconf@merit.edu Fri Apr 4 07:51: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 HAA20278 for ; Fri, 4 Apr 2003 07:51:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 615E391243; Fri, 4 Apr 2003 07:54:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 330DA912F4; Fri, 4 Apr 2003 07:54: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 2916791243 for ; Fri, 4 Apr 2003 07:54:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 14E7E5DF55; Fri, 4 Apr 2003 07:54:11 -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 8F5885DF02 for ; Fri, 4 Apr 2003 07:54:10 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA06871 for ; Fri, 4 Apr 2003 04:54:09 -0800 (PST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h34Cs7l28176 for ; Fri, 4 Apr 2003 14:54:07 +0200 (MEST) Date: Fri, 4 Apr 2003 14:54:05 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: concerns about 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 I have received requests from three WG participants who have concerns both about the decision to accept LL23 and the process by which it was decided. Regarding the process - I am doing my best to include all points of view and discover the consensus, even if it is rough. If I could do a better job of this, please let me know and offer concrete suggestions. We do not have the luxury of leaving these decisions for a brighter day when we finally collectively emerge from the cave of ignorance. Further, we have to consider the context in which we are making these decisions: We must answer IESG issues expressed *LAST OCTOBER* so we can get this document out as a standards track RFC. Regarding the decision - The following concerns have been expressed to me (1) While LL23 instructs a host to use a routable address instead of a link-local address as its source address (if it has one), the host can keep using link-local addresses for connections underway and even accept new communications on the link-local address. Thus, the scoped address (source address selection) problem does not go away - it is only 'contained' to some extent. (2) If we 'give up' our link-local address and cease to advertise it (using LLMNR, SLP, etc) as long as we have a valid DHCP lease, there are situations where we will roam and not use link-local auto-configuration (where we could). If we eagerly shed our DHCP configuration in INIT-REBOOT state and we do not hear from the DHCP server (see (3) in Sec 3.2 of RFC 2131), we may lose our legitimate configuration in a network where we should keep it. This problem is exacerbated by the pressure for rapid usability of systems. Waiting 5 minutes is not acceptable. LL23 forces vendors to trade off rapid usability and robust operation. As WG chair I must emphasize that the bar on revisiting a close issue is very high. We must show either that the resolution is totally broken or that a significantly better alternative exists which can achieve WG consensus. - An alternative which leaves open issues of scoped address architecture for an indefinite period of time has been shown to not achieve WG consensus and leave several issues open which will prove very difficult to address without a 'transition' mechanism (namely LL1, LL4 and LL5). - Is (1) really a problem, given that only 'open' connections and 'accepted' connections are possible with link-local after a routable configuration occurred? - We should explore (2) more. Can we give guidance for timers and express caveats like - if you eagerly give up DHCP configuration, you MUST regularly attempt to reenter INIT-REBOOT and resume use of the configured address if the DHCP server responds. Or, you should attempt to send a ICMP message to your configured router and if it responds, continue to use the routable address even if DHCP doesn't respond, etc. Next steps - Those who are intent on revisiting this point, please post a message to the list expressing why we must do so, how we can meet existing concerns (see LL1, LL4 and LL5), and why your proposal is better than LL23. If there is rough consensus support for your proposal - we will create an issue to track it and take it through 1 week last call. Remember the bar is high. We cannot keep cycling over decisions unless there is an extremely compelling alternative. I hope that those of you who were not satisfied with the process by which we arrived at an ACCEPT of LL23 rough consensus call will find that this manner of revisiting LL23 is fair and appropriate. Erik Guttman Zeroconf WG chair From owner-zeroconf@merit.edu Sat Apr 5 07:11: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 HAA05374 for ; Sat, 5 Apr 2003 07:11:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 14D2191271; Sat, 5 Apr 2003 07:13:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D49DA91273; Sat, 5 Apr 2003 07:13: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 DAD2C91271 for ; Sat, 5 Apr 2003 07:13:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id BD55B5DF59; Sat, 5 Apr 2003 07:13:22 -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 380275DF4A for ; Sat, 5 Apr 2003 07:13: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 h35CDAD20217; Sat, 5 Apr 2003 19:13:11 +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 h35CD0r28771; Sat, 5 Apr 2003 19:13:02 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: concerns about ACCEPT [LL23] Don't configure needless LL addresses In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Apr 2003 19:13:00 +0700 Message-ID: <28769.1049544780@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 4 Apr 2003 14:54:05 +0200 (CEST) From: Erik Guttman Message-ID: | Further, we | have to consider the context in which we are making these decisions: We | must answer IESG issues expressed *LAST OCTOBER* so we can get this | document out as a standards track RFC. Actually no - you should abandon that line of thinking. if something could have been done, quickly, in that direction last November, or perhaps even December, that would have been a correct approach. But that isn't what happened, the whole doc has been revised, with a new look at just about everything. By this stage, what is essentially being done is the new submission of a new document. That should still be done as rapidly as possible, and it is still reasonable to start from the base of the document as it was submitted last year, but it is no longer reasonable (nor has it in fact been done) to consider that all that is happening here is that the WG is looking for answers to a few questions asked of it by the IESG. Even if it wasn't obvious that this is what is happening in fact, there's a new IESG now, even if all the previous points are answered, nothing says that the new IESG won't have a whole new set of concerns. The best way to avoid that, is to make the document as complete and workable as possible - which means to consider all of the issues raised, not ignore or avoid any because they weren't on that IESG list. | Regarding the decision - | | The following concerns have been expressed to me Both of those are technical concerns, which were expressed (over and over again) during the dicussions. I can't see how raising them again is going to help anything. But if that's what we (the WG as a whole) want to do, I can make the same kinds of points about other decisions where the "wrong" decision was obviously (IMO) made (like LL2). | - We should explore (2) more. (2) is just reflecting upon lazy implementations. Nothing that we can do can avoid problems from implementors who can't be bothered doing rational implementations. It is already quite clear from 2131 what implementors who want to do a good implementation of a DHCP client should be doing (though 2131 doesn't require that implementations all be good ones - that isn't required for interoperability, just user happiness, that the implementations in the most common platforms happen to have ignored the users and gone for an easy solution certainly isn't our problem). This WG should most certainly not be bending its specification in any way at all based upon the assumption that only lazy DHCP client implementations will ever exist. kre From owner-zeroconf@merit.edu Sat Apr 5 07:38: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 HAA05696 for ; Sat, 5 Apr 2003 07:38:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 71D7B91274; Sat, 5 Apr 2003 07:40:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 355A091275; Sat, 5 Apr 2003 07:40: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 170A591274 for ; Sat, 5 Apr 2003 07:40:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id F1DB55DF53; Sat, 5 Apr 2003 07:40:46 -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 7C02C5DF4A for ; Sat, 5 Apr 2003 07:40:45 -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 h35CeeD03357 for ; Sat, 5 Apr 2003 19:40: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 h35CeRr28829 for ; Sat, 5 Apr 2003 19:40:27 +0700 (ICT) From: Robert Elz To: zeroconf@merit.edu Subject: [LL14] [LL15] [LL30] Multi-interface hosts Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Apr 2003 19:40:27 +0700 Message-ID: <28827.1049546427@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Ignoring [LL30] for now, that is, assuming it gets rejected (see below), what's the downside of simply requiring hosts to assign different LL addresses to each interface ? That is, what conceivable benefit is there in having the same LL address on more than one interface? If there's none, and at the minute I certainly can't think of one, then we may as well simply require that hosts don't allocate the same address on any two of their interfaces. It isn't as though there aren't plenty of LL addresses to go around (I can't really imagine a host with 64K interfaces, and desiring to allocate LL addresses on all of them - that is, hosts with large numbers of interfaces usually have most of them being point to point interfaces (serial, or more likely, tunnels) and allocating LL addresses on those seems totally pointless (mostly, I suppose someone will dream up a use in some odd circumstance). If we were to require that a host use distinct LL addresses on all interfaces, then both LL14 becomes moot I think. The proposed resolution of LL15 also becomes the obvious thing to do. However, I'm not sure what that resolution has to do with the problem in Ll15. I also have no idea why the wording that LL15 is objecting to is there in the first place. That is, why would a host care that one of its addresses is owned by another host on some other link. I guess that the hope is that it would allow a host to talk to any other host, without ever being fooled into thinking it is talking to itself, and without having to keep some kind of "scope identifier" around to distinguish the cases "me talking to 169.254.22.33 on link A" and "me owning 169.254.22.33 on link B". But that's bogus anyway, it can't be done, the node still needs to know on which link a LL address is located, or the requirement would have to be altered to insist that a multi-interface node should repeat address probes out all other interfaces, and then respond on the original interface if anyone were to respond to a repeated probe (and at the same time, create some kind of mechanism for loop avoidance). That is, somehow the node would need to assure itself that the same address can't be in use by two different nodes on any two links to which it is connected. That's impractical (especially using just ARP to accomplish address assignment). This means that nodes MUST keep track of on which link every link local address resides, and treat that information as a part of the address (for identification purposes anyway). This is exactly as IPv6 has done. As soon as you admit that, there is no longer any rationale for wanting to avoid some other node on link B using the same address as I'm using on link A, as the addresses are all qualified by some kind of identification of each link. Of course, the alternative to all of this would be LL30, but "NOT RECOMMENDED" wouldn't be strong enough, "NOT DEFINED" would really be needed (that is, for anyone who attempts that, making it work is their problem, the WG spec has nothing to offer to help). I could almost support that if I could think of any way to decide which particular interface should be the blessed one to get LL addresses, and accomplish that without configuration. But I'm afraid I can't do that, no one interface (link) is necessarily better suited than any other to having LL addresses assigned to it. Without some way to pick a blessed interface (the "first found" by the hardware probe doesn't sound attractive to me, nor "first in some sort order or interface names" or something) I don't think that LL30 is sustainable. That means that we do have to deal with multi-interface hosts. Which means that we should, I suggest, demand different addresses on each interface, ignore LL14, and certainly do what LL15 suggests, which I think causes the "bad bits" in the current doc to go away. kre From owner-zeroconf@merit.edu Sat Apr 5 07:51: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 HAA05771 for ; Sat, 5 Apr 2003 07:51:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4BEAF91275; Sat, 5 Apr 2003 07:53:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1BA1E91276; Sat, 5 Apr 2003 07:53: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 27EFF91275 for ; Sat, 5 Apr 2003 07:53:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0B6875DF6E; Sat, 5 Apr 2003 07:53:52 -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 84ED65DF6D for ; Sat, 5 Apr 2003 07:53:50 -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 h35CrjD09529 for ; Sat, 5 Apr 2003 19:53: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 h35Crcr28856 for ; Sat, 5 Apr 2003 19:53:38 +0700 (ICT) From: Robert Elz To: zeroconf@merit.edu Subject: [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: Sat, 05 Apr 2003 19:53:38 +0700 Message-ID: <28854.1049547218@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk I support LL13. Wording the text to correctly refer to multicast addresses with a link scope would be a good idea, and a reference to the multicast docs where that is defined, essential, but those are just nits. It might also be worth pointing out that an "available routable address" for multicast purposes has tighter requirements than an available routable address for just about any other use imaginable - the routable address needs to be assigned to (or at least, routed in via) the interface through which the multicast packet is to be forwarded, or it won't be correctly processed. kre From owner-zeroconf@merit.edu Sat Apr 5 08: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 IAA06069 for ; Sat, 5 Apr 2003 08:23:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 98C6F91276; Sat, 5 Apr 2003 08:25:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6670191277; Sat, 5 Apr 2003 08:25: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 3DFE691276 for ; Sat, 5 Apr 2003 08:25:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1645E5DF74; Sat, 5 Apr 2003 08:25:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by segue.merit.edu (Postfix) with ESMTP id CF8B65DF73 for ; Sat, 5 Apr 2003 08:25:22 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) with ESMTP id h35DQf4l025558; Sat, 5 Apr 2003 16:26:42 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h35DQdxk025557; Sat, 5 Apr 2003 16:26:39 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [LL14] [LL15] [LL30] Multi-interface hosts From: Mika Liljeberg To: Robert Elz Cc: zeroconf@merit.edu In-Reply-To: <28827.1049546427@munnari.OZ.AU> References: <28827.1049546427@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1049549198.20485.41.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2003 16:26:38 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Robert, I agree completely. Let's reject LL30 and require that each interface assigns its LL address independently. All this removes a lot of crud from the draft. MikaL On Sat, 2003-04-05 at 15:40, Robert Elz wrote: > Ignoring [LL30] for now, that is, assuming it gets rejected (see below), > what's the downside of simply requiring hosts to assign different > LL addresses to each interface ? > > That is, what conceivable benefit is there in having the same > LL address on more than one interface? > > If there's none, and at the minute I certainly can't think of one, > then we may as well simply require that hosts don't allocate the > same address on any two of their interfaces. > > It isn't as though there aren't plenty of LL addresses to go > around (I can't really imagine a host with 64K interfaces, and > desiring to allocate LL addresses on all of them - that is, hosts > with large numbers of interfaces usually have most of them being > point to point interfaces (serial, or more likely, tunnels) and > allocating LL addresses on those seems totally pointless (mostly, > I suppose someone will dream up a use in some odd circumstance). > > If we were to require that a host use distinct LL addresses on all > interfaces, then both LL14 becomes moot I think. > > The proposed resolution of LL15 also becomes the obvious thing to do. > > However, I'm not sure what that resolution has to do with the problem > in Ll15. I also have no idea why the wording that LL15 is objecting > to is there in the first place. > > That is, why would a host care that one of its addresses is owned by > another host on some other link. I guess that the hope is that it > would allow a host to talk to any other host, without ever being fooled > into thinking it is talking to itself, and without having to keep some > kind of "scope identifier" around to distinguish the cases "me talking > to 169.254.22.33 on link A" and "me owning 169.254.22.33 on link B". > > But that's bogus anyway, it can't be done, the node still needs > to know on which link a LL address is located, or the requirement > would have to be altered to insist that a multi-interface node should > repeat address probes out all other interfaces, and then respond on the > original interface if anyone were to respond to a repeated probe (and > at the same time, create some kind of mechanism for loop avoidance). > That is, somehow the node would need to assure itself that the same > address can't be in use by two different nodes on any two links to which > it is connected. > > That's impractical (especially using just ARP to accomplish address > assignment). This means that nodes MUST keep track of on which link > every link local address resides, and treat that information as a part > of the address (for identification purposes anyway). This is exactly > as IPv6 has done. As soon as you admit that, there is no longer any > rationale for wanting to avoid some other node on link B using the same > address as I'm using on link A, as the addresses are all qualified by > some kind of identification of each link. > > Of course, the alternative to all of this would be LL30, but "NOT > RECOMMENDED" wouldn't be strong enough, "NOT DEFINED" would really > be needed (that is, for anyone who attempts that, making it work is > their problem, the WG spec has nothing to offer to help). > > I could almost support that if I could think of any way to decide > which particular interface should be the blessed one to get LL > addresses, and accomplish that without configuration. But I'm afraid > I can't do that, no one interface (link) is necessarily better suited > than any other to having LL addresses assigned to it. > > Without some way to pick a blessed interface (the "first found" by > the hardware probe doesn't sound attractive to me, nor "first in some > sort order or interface names" or something) I don't think that LL30 > is sustainable. > > That means that we do have to deal with multi-interface hosts. Which > means that we should, I suggest, demand different addresses on each > interface, ignore LL14, and certainly do what LL15 suggests, which I > think causes the "bad bits" in the current doc to go away. > > kre > From owner-zeroconf@merit.edu Sat Apr 5 08:34: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 IAA06159 for ; Sat, 5 Apr 2003 08:34:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 61C2991277; Sat, 5 Apr 2003 08:37:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 295B591279; Sat, 5 Apr 2003 08:37: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 1733A91277 for ; Sat, 5 Apr 2003 08:37:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 002535DF60; Sat, 5 Apr 2003 08:37: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 60C5E5DF4B for ; Sat, 5 Apr 2003 08:36: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 h35DarD29490 for ; Sat, 5 Apr 2003 20:36: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 h35Dajr28909 for ; Sat, 5 Apr 2003 20:36:45 +0700 (ICT) From: Robert Elz To: zeroconf@merit.edu Subject: [LL12] [LL20] and a possible solution Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Apr 2003 20:36:45 +0700 Message-ID: <28907.1049549805@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk The problem that these two are trying to deal with are the totally inappropriate timer values specified in the draft. The timers that are there now satisfy no-one, they're not long enough to cope with switches blocking packets while running the spanning tree algorithm (to decide if it is safe to allow the link to be brought up and process packets). But they're too long to satisfy nodes that know there's not going to be any of that happening, and want to be connected and working as quickly as possible. The problem is that there's no way (that I'm aware of) for a node to know whether or not packets it sends are being received by other nodes or not. We could just wait for IEEE to define one, and then hope that the NIC makers (chip makers, and then board vendors) incorporate that quickly. And in the meantime we wait (after all, that could probably all happen quicker than this doc is going to emerge from this WG...) Or we could just adopt the conservative safe approach, and specify timers long enough that they're guaranteed to work (which means something of the order of 45 seconds from when the link has come up at a hardware level). Or we could adopt the risky, works frequently, occasionally self destructs method, and wish spanning tree algorithms into non-existence (require that network operators disable spanning tree on any switch interfaces where a node that might want to use LL addresses is to be connected), pick low timers, and simply live with the occasional address conflicts that result (even in the worst circumstances, they won't happen often, and nodes have to be able to deal with them in the case of partitioned networks rejoining). Or, we could just fix the problem ourselves. That is, we could make the algorithm be Send probe Wait short interval (randomised, 80-100 ms max) for a reply. If there's a reply, pick a new random address goto A: If there's no reply, retransmit the probe, and also broadcast an ARP request for 169.254.0.0 Wait for a reply (for up to 60 seconds, with occasional retransmits of the address probe (every 5 secs or so), and frequent retransmits (every 300 ms or so, randomised) of the 169.254.0.0 ARP query). If no reply (at all, after 60 secs), take the address, and defend it. If there's a reply to the selected address probe, pick a new random address, goto A: If there's a reply to the 169.254.0.0 request, or if there's an ARP reply/request for any other address, keep the same address selected, goto A: /* NOT REACHED */ A: send probe for selected address wait short interval for reply (randomised, 40-80 ms). if a reply comes, pick a new random address (unless we have tried too many times already - abort in that case) goto A: if no reply, and less than 5 (or 3 or something) probes for this address have been sent (since point A), keep same addr, goto A: Assign the probed address to the interface. Then, the ARP listener, that runs the whole time this is going on and forever after, handles ARP just as now (in the doc) for all cases, except for when an ARP request for 169.254.0.0 is received. When that happens, the node picks a random interval, in the range 1-200 ms, and waits, While waiting, if it sees an ARP reply for 169.254.0.0, it cancels its timer, and forgets it ever saw the 169.254.0.0 ARP request. If it sees no reply, then after its timer expires, it broadcasts an ARP reply (to everyone) claiming to own the 169.254.0.0 address for itself (other nodes can, and probably should, choose to ignore this reply, other than to cancel any timer they have running). The idea of this is for the node to be able to discover whether its packets are going anywhere or not. While they're being blocked, no-one is going to see the 169.254.0.0 ARP request, there will be no reply, and the node will remain in the "I have to wait 60 seconds" mode. On the other hand, if packets are being transmitted, some other node (and usually just one other node) will reply to the 169.254.0.0 ARP request - getting that reply allows the node to know that it is connected to a net, the connection works, and so, it can use short timers instead of long slow ones. The one remaining case is where the node is connected to a link which is working, but where there are no nodes on the link that understand LL addresses (note that any node that understands the spec will reply to the 169.254.0.0 ARP probe - not only one that has a LL address assigned on the interface). In that case, the node that is trying to assign itself a LL address will remain on the slow path, when it need not. But it doesn't matter - there's no-one out there to talk to anyway (no-one who will understand the LL address if it is assigned). So, it really doesn't matter how quickly the first node to connect to this link acquires its LL address (if that slow assignment slows down availability of the node for other, non networking, functions, then that's a poor implementation - the non-net part of the node should be getting itself running in parallel with all of this, the networking part of it is useless with no peers to communicate with, and so may as well wait an extra minute during its config, just to be safe). If we do this, we can rid ourselves of the "too long but not long enough" timers that are currently in the draft, allow most nodes to assign themselves a LL address very quickly (since the 169.254.0.0 probe will be answered, by someone, quite quickly), while still working correctly in the presence of spanning tree algorithms being left enabled in switches (it also dynamically detects just how quickly the switch is available, as soon as it unblocks the port, someone will reply to the next probe for that address, and the algorithm will switch into fast mode). There could probably be a better algorithm than the one above (which needs fleshing out in some of the details anyway) - but even if that ends up being it, I think it is simple enough to understand, and implement, and cheap enough to actually use (even with thousands of nodes all booting on the same link at the same time) that it is a workable solution. kre From owner-zeroconf@merit.edu Sat Apr 5 08:52: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 IAA06339 for ; Sat, 5 Apr 2003 08:52:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 877A191279; Sat, 5 Apr 2003 08:54:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 532199127A; Sat, 5 Apr 2003 08: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 513A291279 for ; Sat, 5 Apr 2003 08:54:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3D3FB5DF7D; Sat, 5 Apr 2003 08:54:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by segue.merit.edu (Postfix) with ESMTP id 360875DF7A for ; Sat, 5 Apr 2003 08:54:24 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) with ESMTP id h35Dth4l025663; Sat, 5 Apr 2003 16:55:44 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h35Dtgu8025662; Sat, 5 Apr 2003 16:55:42 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [LL12] [LL20] and a possible solution From: Mika Liljeberg To: Robert Elz Cc: zeroconf@merit.edu In-Reply-To: <28907.1049549805@munnari.OZ.AU> References: <28907.1049549805@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1049550941.20483.48.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Apr 2003 16:55:42 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I propose a simple approach [not fully fleshed out]. Let's specify that a newly picked LL address is "tentative" for the first 60 seconds. The host is allowed to use it immediately but will also be sending DAD probes (possibly with exponential backoff) while the address is in "tentative" state. If a conflict is detected, the node with the tentative address is required to yield immediately and pick a new address. MikaL From owner-zeroconf@merit.edu Sat Apr 5 10:32: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 KAA09024 for ; Sat, 5 Apr 2003 10:32:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7DCD39127A; Sat, 5 Apr 2003 10:34:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4FA1E9127B; Sat, 5 Apr 2003 10:34: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 D70719127A for ; Sat, 5 Apr 2003 10:33:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id AFCAB5DF9F; Sat, 5 Apr 2003 10:33: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 285255DF93 for ; Sat, 5 Apr 2003 10:33: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 h35FXUD04276; Sat, 5 Apr 2003 22:33: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 h35FXAr29777; Sat, 5 Apr 2003 22:33:12 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: Re: [LL12] [LL20] and a possible solution In-Reply-To: <1049550941.20483.48.camel@devil> References: <1049550941.20483.48.camel@devil> <28907.1049549805@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 05 Apr 2003 22:33:10 +0700 Message-ID: <29775.1049556790@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 05 Apr 2003 16:55:42 +0300 From: Mika Liljeberg Message-ID: <1049550941.20483.48.camel@devil> | Let's specify that a newly picked LL address is "tentative" for the | first 60 seconds. The host is allowed to use it immediately but will | also be sending DAD probes (possibly with exponential backoff) while the | address is in "tentative" state. That's not a productive approach. If the immediate use of the address works (actually achieves something), then there's no need to keep probing. You know the net is working, you know you have the address, you also are pretty sure there can't be a conflict (at the very most one more probe might be required). That is, all we need is to get some indication that the net works, and then we can do fast probing, and allocate an address with almost no delay. On the other hand, if the net didn't work (blocked port), and we allocate an address, then start sending packets from it, and the net unblocks, then we keep sending packets, we can achieve things like TCP reset sent to the "other" user of the address (if there happened to be a conflict). Having the node that incorrectly probed and allocated the address that it must give up the address in this case doesn't help the other node that has been trodden all over. kre From owner-zeroconf@merit.edu Sun Apr 6 07:24: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 HAA26066 for ; Sun, 6 Apr 2003 07:24:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EB25F91288; Sun, 6 Apr 2003 07:26:24 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE85491289; Sun, 6 Apr 2003 07:26:23 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6DDBD91288 for ; Sun, 6 Apr 2003 07:26:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4CD495E09C; Sun, 6 Apr 2003 07:26:22 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by segue.merit.edu (Postfix) with ESMTP id 7CC0C5E09B for ; Sun, 6 Apr 2003 07:26:21 -0400 (EDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) with ESMTP id h36BRg4l002269; Sun, 6 Apr 2003 14:27:42 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h36BReT9002268; Sun, 6 Apr 2003 14:27:40 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [LL12] [LL20] and a possible solution From: Mika Liljeberg To: Robert Elz Cc: zeroconf@merit.edu In-Reply-To: <29775.1049556790@munnari.OZ.AU> References: <1049550941.20483.48.camel@devil> <28907.1049549805@munnari.OZ.AU> <29775.1049556790@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1049628459.20483.1034.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Apr 2003 14:27:40 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-04-05 at 18:33, Robert Elz wrote: > Date: 05 Apr 2003 16:55:42 +0300 > From: Mika Liljeberg > Message-ID: <1049550941.20483.48.camel@devil> > > | Let's specify that a newly picked LL address is "tentative" for the > | first 60 seconds. The host is allowed to use it immediately but will > | also be sending DAD probes (possibly with exponential backoff) while the > | address is in "tentative" state. > > That's not a productive approach. It's certainly a different approach but I think it could be made to work. > If the immediate use of the address > works (actually achieves something), then there's no need to keep probing. > You know the net is working, That's true. You don't have to keep DADding for the full 60 seconds once you get confirmation that the link is responsive. You just have to send a few more quick DADs and, if there is no response, move your LL address from "tentative" to "assigned". > you know you have the address, you also are > pretty sure there can't be a conflict (at the very most one more probe > might be required). That's not true. You are trying to communicate with a tentative LL source address and have ARPed for some destination address. You have not yet completed DAD on the your own LL address. At this point you still have to send a few rapid DADs in order to validate your LL address. > That is, all we need is to get some indication that the net works, and then > we can do fast probing, and allocate an address with almost no delay. True, I agree (see above). Letting the host ARP for a real destination address, rather than 169.254.0.0, solves the problem where the link does not have any other LL-compliant nodes. Note that there may be non-LL compliant nodes with a configured 169.254/16 on-link route (people seemed to want this earlier), which you would like to communicate with. Your solution would keep spamming the link with ARP broadcasts to 169.254.0.0 for the full 60 seconds (you can't use backoff if you want rapid link responsiveness detection). > On the other hand, if the net didn't work (blocked port), and we allocate > an address, then start sending packets from it, and the net unblocks, > then we keep sending packets, we can achieve things like TCP reset sent to > the "other" user of the address (if there happened to be a conflict). There is not much difference to your solution in this respect. The address only becomes allocated after 60 seconds, after which the node starts to defend it. While the address is tentative you can minimize collision hazards with the following simple rules: 1) Delay ARP response for a tentative address by a small delay, e.g. one second, (and yield immediately if you hear an ARP response from another node for the same address, as required by conflict resolution) 2) Only send unicast ARP responses for a tentative address. This will avoid triggering conflict resolution in other nodes. > Having the node that incorrectly probed and allocated the address that it > must give up the address in this case doesn't help the other node that > has been trodden all over. It's not quite as unworkable as that, I think. :-) MikaL From owner-zeroconf@merit.edu Sun Apr 6 08:11: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 IAA26390 for ; Sun, 6 Apr 2003 08:11:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D525A91289; Sun, 6 Apr 2003 08:13:53 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C5639128A; Sun, 6 Apr 2003 08:13:53 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 65D7E91289 for ; Sun, 6 Apr 2003 08:13:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A1B75E0A4; Sun, 6 Apr 2003 08:13:52 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by segue.merit.edu (Postfix) with ESMTP id 370A85DFFD for ; Sun, 6 Apr 2003 08:13:51 -0400 (EDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) with ESMTP id h36CFC4l002425; Sun, 6 Apr 2003 15:15:12 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h36CFB9c002424; Sun, 6 Apr 2003 15:15:11 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: concerns about ACCEPT [LL23] Don't configure needless 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: <1049631310.20483.1059.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Apr 2003 15:15:11 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Any way I look at it, concern (2) is a show stopper for us. Before the SF meeting I was trying to come up with an alternative solution that would satisfy both camps but the more I turn it over in my head the more convinced I become that retracting LL23 completely is the only robust solution. At this point in time, I think the onus for finding a workable solution to (2) now rests on the proponents of LL23. Until such a solution is forthcoming, I believe we will simply have to ignore these particular requirements in our implementation. Technically this is allowed, as we can assign a global address to one interface and a LL address to another, and connect those interfaces to the same link. We have a multi-site, multi-homing capable host implementation that has the necessary APIs to deal with the address ambiguity. So, we should be able to cope. As Stuart so aptly stated, "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". Regards, MikaL On Fri, 2003-04-04 at 15:54, Erik Guttman wrote: > I have received requests from three WG participants who have concerns > both about the decision to accept LL23 and the process by which it was > decided. > > Regarding the process - I am doing my best to include all points of view > and discover the consensus, even if it is rough. If I could do a better > job of this, please let me know and offer concrete suggestions. We do > not have the luxury of leaving these decisions for a brighter day when > we finally collectively emerge from the cave of ignorance. Further, we > have to consider the context in which we are making these decisions: We > must answer IESG issues expressed *LAST OCTOBER* so we can get this > document out as a standards track RFC. > > Regarding the decision - > > The following concerns have been expressed to me > > (1) While LL23 instructs a host to use a routable address instead of > a link-local address as its source address (if it has one), the > host can keep using link-local addresses for connections underway > and even accept new communications on the link-local address. > Thus, the scoped address (source address selection) problem does > not go away - it is only 'contained' to some extent. > > (2) If we 'give up' our link-local address and cease to advertise it > (using LLMNR, SLP, etc) as long as we have a valid DHCP lease, > there are situations where we will roam and not use link-local > auto-configuration (where we could). If we eagerly shed our > DHCP configuration in INIT-REBOOT state and we do not hear > from the DHCP server (see (3) in Sec 3.2 of RFC 2131), we may > lose our legitimate configuration in a network where we should > keep it. This problem is exacerbated by the pressure for rapid > usability of systems. Waiting 5 minutes is not acceptable. LL23 > forces vendors to trade off rapid usability and robust operation. > > As WG chair I must emphasize that the bar on revisiting a close issue is > very high. We must show either that the resolution is totally broken or > that a significantly better alternative exists which can achieve WG > consensus. > > - An alternative which leaves open issues of scoped address > architecture for an indefinite period of time has been shown to > not achieve WG consensus and leave several issues open which will > prove very difficult to address without a 'transition' mechanism > (namely LL1, LL4 and LL5). > > - Is (1) really a problem, given that only 'open' connections and > 'accepted' connections are possible with link-local after a routable > configuration occurred? > > - We should explore (2) more. Can we give guidance for timers and > express caveats like - if you eagerly give up DHCP configuration, > you MUST regularly attempt to reenter INIT-REBOOT and resume use > of the configured address if the DHCP server responds. Or, you > should attempt to send a ICMP message to your configured router > and if it responds, continue to use the routable address even if > DHCP doesn't respond, etc. > > Next steps - > > Those who are intent on revisiting this point, please post a message to > the list expressing why we must do so, how we can meet existing concerns > (see LL1, LL4 and LL5), and why your proposal is better than LL23. If > there is rough consensus support for your proposal - we will create an > issue to track it and take it through 1 week last call. > > Remember the bar is high. We cannot keep cycling over decisions unless > there is an extremely compelling alternative. > > I hope that those of you who were not satisfied with the process by > which we arrived at an ACCEPT of LL23 rough consensus call will find > that this manner of revisiting LL23 is fair and appropriate. > > Erik Guttman > Zeroconf WG chair > From owner-zeroconf@merit.edu Mon Apr 7 07:12: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 HAA15247 for ; Mon, 7 Apr 2003 07:12:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 562A19120E; Mon, 7 Apr 2003 06:58:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 17C1F9120F; Mon, 7 Apr 2003 06:58:35 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB76E9120E for ; Mon, 7 Apr 2003 06:58:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C11FE5E197; Mon, 7 Apr 2003 06:58:33 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 626875E18F for ; Mon, 7 Apr 2003 06:58:32 -0400 (EDT) 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 h37AwSD21793; Mon, 7 Apr 2003 17:58: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 h37AvCr13794; Mon, 7 Apr 2003 17:57:28 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: Re: [LL12] [LL20] and a possible solution In-Reply-To: <1049628459.20483.1034.camel@devil> References: <1049628459.20483.1034.camel@devil> <1049550941.20483.48.camel@devil> <28907.1049549805@munnari.OZ.AU> <29775.1049556790@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 07 Apr 2003 17:57:12 +0700 Message-ID: <13792.1049713032@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 06 Apr 2003 14:27:40 +0300 From: Mika Liljeberg Message-ID: <1049628459.20483.1034.camel@devil> | That's not true. You are trying to communicate with a tentative LL | source address and have ARPed for some destination address. Yes, and after that, you've most likely sent packets and received replies. All of that working correctly is pretty strong evidence that the address isn't used by anyone else, which is all the extra probes are intended to discover (neither is proof, just a better indication). Doing extra probes, for no better reason that we would want to do them if we had no other evidence, is dumb. The only reason for not just going ahead and doing all of this, is the potential for standing on someone else who is using your tentative address (just doing an ARP query for some address has your IP/MAC address mapping in the request, and supplies that to the destination node, possibly overwriting the mapping for some other node that was previously using the address). | Letting the host ARP for a real destination address, rather than | 169.254.0.0, solves the problem where the link does not have any other | LL-compliant nodes. If the link has no other LL aware nodes, the whole issue is irrelevant, as having obtained our LL address, there will be no-one to communicate with. | Note that there may be non-LL compliant nodes with a | configured 169.254/16 on-link route (people seemed to want this | earlier), which you would like to communicate with. Your solution would | keep spamming the link with ARP broadcasts to 169.254.0.0 for the full | 60 seconds (you can't use backoff if you want rapid link responsiveness | detection). Yes, but if you're willing to configure a node to know that 169.254/16 is on link (which is certainly not impossible) you can easily also configure it to respond to those ARP requests (even if it just does a unicast reply, which in this scenario would be fine). But you do point out one minor disadvantage to my proposal, in that if a link has one LL aware node (exactly one) and perhaps large numbers of non LL aware nodes, they're all going to be bothered by several ARP packets a second (2 or 3, depending upon the final values of the timers) for a minute, when that LL aware node connects. I think I could live with that (150-200 ARP requests in a minute, occasionally), but it is something worth bearing in mind. The other reason why "just go ahead and ARP for a real address" as a solution is (for many implementations anyway) not useful, is that while they're in the stages of configuring interfaces, they have no-one else with whom they want to communicate. Interface config is one of the very early parts of getting started, way before any applications are running (many apps prefer to have interfaces configured before they start, as they want to extract the information from the interface config so they know the local environment). In any case, as I think (hope) I said in my first message, the algorithm I came up with isn't what's important here - what matters for now is to decide whether nodes should attempt do do the right thing when connected to switches that are blocking ports while doing spanning tree processing (loop detection), or whether we want to simply define some numbers as "good enough". It looks to me as if you're agreeing that having the nodes attempt to work out that the link is functional - from which point relatively small timer numbers are good enough for the algorithm's purposes. I think my main point is that the numbers in the draft currently aren't right for anyone - except perhaps by some fluke of some implementation, where LL address configuration is being delayed already by several seconds, perhaps while attempting to get a DHCP response, which fails because the port is blocked, then once that is done with, it just happens that the numbers in the draft are what is needed (on that implementation) to get past the port block time. kre From owner-zeroconf@merit.edu Mon Apr 7 15:46: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 PAA04168 for ; Mon, 7 Apr 2003 15:46:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DF02E91217; Mon, 7 Apr 2003 15:49:02 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8BA09121A; Mon, 7 Apr 2003 15:49:02 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9E9A291217 for ; Mon, 7 Apr 2003 15:49:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7EA0B5E168; Mon, 7 Apr 2003 15:49:01 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by segue.merit.edu (Postfix) with ESMTP id 7EF3E5E031 for ; Mon, 7 Apr 2003 15:49:00 -0400 (EDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) with ESMTP id h37JoN4l013748; Mon, 7 Apr 2003 22:50:23 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-1) id h37JoLSS013747; Mon, 7 Apr 2003 22:50:21 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [LL12] [LL20] and a possible solution From: Mika Liljeberg To: Robert Elz Cc: zeroconf@merit.edu In-Reply-To: <13792.1049713032@munnari.OZ.AU> References: <1049628459.20483.1034.camel@devil> <1049550941.20483.48.camel@devil> <28907.1049549805@munnari.OZ.AU> <29775.1049556790@munnari.OZ.AU> <13792.1049713032@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1049745020.5157.71.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Apr 2003 22:50:20 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 2003-04-07 at 13:57, Robert Elz wrote: > But you do point out one minor disadvantage to my proposal, in that if a > link has one LL aware node (exactly one) and perhaps large numbers of > non LL aware nodes, they're all going to be bothered by several ARP packets > a second (2 or 3, depending upon the final values of the timers) for > a minute, when that LL aware node connects. I think I could live with > that (150-200 ARP requests in a minute, occasionally), but it is something > worth bearing in mind. Maybe it wouldn't be so bad to use exponential backoff here? Start with an initial delay of a few hundred milliseconds (tuned according to the link-layer latency), and double the interval with every transmission. I could live with that. Also, I would suggest that ANY packet received from the link is a signal that the link is responsive, so even if there are no nodes that recognize 169.254.0.0, it would be likely that the algorithm would terminate before the maximum timeout. > The other reason why "just go ahead and ARP for a real address" as a solution > is (for many implementations anyway) not useful, is that while they're in > the stages of configuring interfaces, they have no-one else with whom they > want to communicate. Interface config is one of the very early parts of > getting started, way before any applications are running (many apps prefer to > have interfaces configured before they start, as they want to extract the > information from the interface config so they know the local environment). Um, yeah. There are devices with on-demand interfaces, but even so the first packet is likely to be a multicast generated by e.g. the LLMNR responder. So scrap that idea. > It looks to me as if you're agreeing that having the nodes attempt to > work out that the link is functional - from which point relatively small > timer numbers are good enough for the algorithm's purposes. Well, I would welcome an approach that spends less than 10 seconds configuring a LL address (barring those damnable switches). MikaL From owner-zeroconf@merit.edu Tue Apr 8 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 MAA20951 for ; Tue, 8 Apr 2003 12:23:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B61791227; Tue, 8 Apr 2003 12:26:22 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B35F9122B; Tue, 8 Apr 2003 12:26:21 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE59591227 for ; Tue, 8 Apr 2003 12:26:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A4C385E285; Tue, 8 Apr 2003 12:26:20 -0400 (EDT) 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 676085E1AA for ; Tue, 8 Apr 2003 12:26:20 -0400 (EDT) Received: (covad.net 13386 invoked from network); 8 Apr 2003 16:26:18 -0000 Received: from unknown (HELO STUDY) (66.167.13.252) by sun-qmail03 with SMTP; 8 Apr 2003 16:26:18 -0000 To: zeroconf@merit.edu Subject: Re: [LL12] [LL20] and a possible solution References: <28907.1049549805@munnari.OZ.AU> Organization: Seeking Work... From: Scott Lawrence Date: 08 Apr 2003 12:26:11 -0400 In-Reply-To: <28907.1049549805@munnari.OZ.AU> Message-ID: Lines: 46 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 Robert Elz writes: > The timers that are there now satisfy no-one, they're not long enough > to cope with switches blocking packets while running the spanning tree > algorithm (to decide if it is safe to allow the link to be brought up > and process packets). > > [...] > > Or we could adopt the risky, works frequently, occasionally self destructs > method, and wish spanning tree algorithms into non-existence (require that > network operators disable spanning tree on any switch interfaces where a > node that might want to use LL addresses is to be connected), pick low > timers, and simply live with the occasional address conflicts that > result (even in the worst circumstances, they won't happen often, and > nodes have to be able to deal with them in the case of partitioned > networks rejoining). I favor the simplest of approaches - use short timers (which means the whole thing works quickly in the unsegmented LAN case), and just let the collision detection work to resolve conflicts when the port unblocks (or other temporary partition ends). I think that the thing to keep in mind is that the probability of the problem occuring is low so long as everyone is making good random address choices. Further, it only causes a problem when the address had actually come into active use (used to set up a TCP connection or made known to some other node). If my node is behind a blocked port, I will be able to put the address into use only on my own segment - further reducing the likelyhood that I can get to the problem of discovering a conflict with an active address. Since the time window is not long even in the case of a slow spanning tree bridge, these two things have to happen quickly. Further, all the code to deal with conflicts on an active address still needs to be there regardless of what we do during the selection process. I think the complexity cost is not justified by the frequency (low) and severity (not very) of the problem. -- Scott Lawrence Actively seeking work http://skrb.org/scott/ [ is deprecated ] From owner-zeroconf@merit.edu Fri Apr 11 08:51: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 IAA10659 for ; Fri, 11 Apr 2003 08:51:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 73ABC9127B; Fri, 11 Apr 2003 08:54:01 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F4589127D; Fri, 11 Apr 2003 08:54:01 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 57D179127B for ; Fri, 11 Apr 2003 08:54:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3676D5DF90; Fri, 11 Apr 2003 08:54:00 -0400 (EDT) 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 ADC775DF83 for ; Fri, 11 Apr 2003 08:53:59 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA12922 for ; Fri, 11 Apr 2003 05:53:58 -0700 (PDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h3BCrvl08112 for ; Fri, 11 Apr 2003 14:53:57 +0200 (MEST) Date: Fri, 11 Apr 2003 14:53:55 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG Action - Reject [LL3] 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 LL3: TTL=255 on send, check on receive? Decision: Reject Action: None Notes: This proposal requires setting TTL to a value which available for modification by higher level (application) interfaces. Legacy devices exist which do not send with TTL = 255, but otherwise comply with the specification. It would be impossible to communicate with such devices if TTL != 255 messages were dropped. It is not clear *when* or under *which conditions* the dropping policy can be used safely in the future, based on this suggestion. The argument that router reconfiguration to not forward from LL sources or to LL destinations will take a while and may never be complete cannot be dismissed. It is also possible to send to a non-link-local multicast address from a link-local source. Using flood and prune multicast routing algorithms, link-local sourced datagrams will be widely distributed on the network if TTL = 255. Arguments for security benefits for this protocol were not widely accepted. Indeed many felt that assertions of this as a 'security feature' was pernicious and raised false expections. Erik Guttman Zeroconf WG chair From owner-zeroconf@merit.edu Fri Apr 11 08:52:17 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 IAA10681 for ; Fri, 11 Apr 2003 08:52:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 16D349127D; Fri, 11 Apr 2003 08:54:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D49629127E; Fri, 11 Apr 2003 08:54:10 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E8879127D for ; Fri, 11 Apr 2003 08:54:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6BF2A5DF90; Fri, 11 Apr 2003 08:54:07 -0400 (EDT) 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 CED555DF83 for ; Fri, 11 Apr 2003 08:54:06 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA12978 for ; Fri, 11 Apr 2003 05:54:05 -0700 (PDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h3BCs4l08123 for ; Fri, 11 Apr 2003 14:54:04 +0200 (MEST) Date: Fri, 11 Apr 2003 14:54:03 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG Action - Reject [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 LL21: Alternate text for: TTL=255 on send, check on receive? Decision: Reject Action: None Note: It seems useful to an overwhelming majority of contributors to the discussion to express the reasoning and recommendations made in LL29. Even KRE (proponent of LL21) said he could 'live with' LL29. Erik Guttman Zeroconf WG chair From owner-zeroconf@merit.edu Fri Apr 11 08:52: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 IAA10696 for ; Fri, 11 Apr 2003 08:52:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8521D9127E; Fri, 11 Apr 2003 08:54:17 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 526349127F; Fri, 11 Apr 2003 08:54:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 39AC09127E for ; Fri, 11 Apr 2003 08:54:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1EDD35DF90; Fri, 11 Apr 2003 08:54:14 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id A07B75DF83 for ; Fri, 11 Apr 2003 08:54:13 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA04327 for ; Fri, 11 Apr 2003 06:54:12 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h3BCsAl08130 for ; Fri, 11 Apr 2003 14:54:11 +0200 (MEST) Date: Fri, 11 Apr 2003 14:54:09 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG Action - Accept [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 LL29: Link-local sources should specify TTL=1 Decision: Accept Action: Change the first two paragraphs of section 2.7 to read 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 by default. This includes multicast and broadcast packets with a source address in the 169.254/16 prefix. An application may set the TTL to any value, using established interfaces for this purpose, overriding the default. This suggested behavior 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. Notes: This proposal is consistent with current practice and interpretation of TTL. (Ralph Droms) This proposal prevents leakage of datagrams from the local link in several plausible scenarios. This proposal explicitely allows setting of TTL for apps. This proposal was supported by most of the WG participants. Erik Guttman Zeroconf WG chair From owner-zeroconf@merit.edu Fri Apr 11 08: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 IAA10711 for ; Fri, 11 Apr 2003 08:52:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 920BC91284; Fri, 11 Apr 2003 08:54:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6971591282; Fri, 11 Apr 2003 08:54:45 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C58DD91283 for ; Fri, 11 Apr 2003 08:54:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A8FBC5DF93; Fri, 11 Apr 2003 08:54:40 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 0F4CF5DF90 for ; Fri, 11 Apr 2003 08:54:40 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA04533 for ; Fri, 11 Apr 2003 06:54:38 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h3BCsbl08251 for ; Fri, 11 Apr 2003 14:54:37 +0200 (MEST) Date: Fri, 11 Apr 2003 14:54:36 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG Action - Reject [LL18] Host with LL address MUST ARP for all addresses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk This issue never had text submitted for it. At such a time as an issue comes to mind - we will take the submission and open it for discussion. Erik From owner-zeroconf@merit.edu Fri Apr 11 08: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 IAA10728 for ; Fri, 11 Apr 2003 08:52:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DC5B59127F; Fri, 11 Apr 2003 08:54:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1D4791281; Fri, 11 Apr 2003 08:54:28 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4CFED9127F for ; Fri, 11 Apr 2003 08:54:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E7B75DF95; Fri, 11 Apr 2003 08:54:23 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id B44685DF90 for ; Fri, 11 Apr 2003 08:54:22 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA06478; Fri, 11 Apr 2003 06:54:21 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h3BCsJl08161; Fri, 11 Apr 2003 14:54:19 +0200 (MEST) Date: Fri, 11 Apr 2003 14:54:18 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: Mika Liljeberg Cc: Erik Guttman , zeroconf@merit.edu Subject: Re: concerns about ACCEPT [LL23] Don't configure needless LL addresses In-Reply-To: <1049631310.20483.1059.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On 6 Apr 2003, Mika Liljeberg wrote: > > Any way I look at it, concern (2) is a show stopper for us. Before the > SF meeting I was trying to come up with an alternative solution that > would satisfy both camps but the more I turn it over in my head the more > convinced I become that retracting LL23 completely is the only robust > solution. > > At this point in time, I think the onus for finding a workable solution > to (2) now rests on the proponents of LL23. Until such a solution is > forthcoming, I believe we will simply have to ignore these particular > requirements in our implementation. Technically this is allowed, as we > can assign a global address to one interface and a LL address to > another, and connect those interfaces to the same link. We have a > multi-site, multi-homing capable host implementation that has the > necessary APIs to deal with the address ambiguity. So, we should be able > to cope. > > As Stuart so aptly stated, "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". Can we come to consensus on LL23 substituting SHOULD for MUST in the paragraph below: 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. ****Can we get agreement on this if we also include a list of potential risks if we go against recommendations? *** Who will volunteer to write up this list of potential risks and to work diligently till the WG is satisfied the risks are well documented? (I do not volunteer to do this.) *** Who will volunteer to document applications which will and will not have problems with mixed scope hosts (LL4 and LL5 - which need text) and to work with the WG and Harald till we reach consensus? Erik Guttman Zeroconf WG chair ------------------------------------- > On Fri, 2003-04-04 at 15:54, Erik Guttman wrote: > > I have received requests from three WG participants who have concerns > > both about the decision to accept LL23 and the process by which it was > > decided. > > > > Regarding the process - I am doing my best to include all points of view > > and discover the consensus, even if it is rough. If I could do a better > > job of this, please let me know and offer concrete suggestions. We do > > not have the luxury of leaving these decisions for a brighter day when > > we finally collectively emerge from the cave of ignorance. Further, we > > have to consider the context in which we are making these decisions: We > > must answer IESG issues expressed *LAST OCTOBER* so we can get this > > document out as a standards track RFC. > > > > Regarding the decision - > > > > The following concerns have been expressed to me > > > > (1) While LL23 instructs a host to use a routable address instead of > > a link-local address as its source address (if it has one), the > > host can keep using link-local addresses for connections underway > > and even accept new communications on the link-local address. > > Thus, the scoped address (source address selection) problem does > > not go away - it is only 'contained' to some extent. > > > > (2) If we 'give up' our link-local address and cease to advertise it > > (using LLMNR, SLP, etc) as long as we have a valid DHCP lease, > > there are situations where we will roam and not use link-local > > auto-configuration (where we could). If we eagerly shed our > > DHCP configuration in INIT-REBOOT state and we do not hear > > from the DHCP server (see (3) in Sec 3.2 of RFC 2131), we may > > lose our legitimate configuration in a network where we should > > keep it. This problem is exacerbated by the pressure for rapid > > usability of systems. Waiting 5 minutes is not acceptable. LL23 > > forces vendors to trade off rapid usability and robust operation. > > > > As WG chair I must emphasize that the bar on revisiting a close issue is > > very high. We must show either that the resolution is totally broken or > > that a significantly better alternative exists which can achieve WG > > consensus. > > > > - An alternative which leaves open issues of scoped address > > architecture for an indefinite period of time has been shown to > > not achieve WG consensus and leave several issues open which will > > prove very difficult to address without a 'transition' mechanism > > (namely LL1, LL4 and LL5). > > > > - Is (1) really a problem, given that only 'open' connections and > > 'accepted' connections are possible with link-local after a routable > > configuration occurred? > > > > - We should explore (2) more. Can we give guidance for timers and > > express caveats like - if you eagerly give up DHCP configuration, > > you MUST regularly attempt to reenter INIT-REBOOT and resume use > > of the configured address if the DHCP server responds. Or, you > > should attempt to send a ICMP message to your configured router > > and if it responds, continue to use the routable address even if > > DHCP doesn't respond, etc. > > > > Next steps - > > > > Those who are intent on revisiting this point, please post a message to > > the list expressing why we must do so, how we can meet existing concerns > > (see LL1, LL4 and LL5), and why your proposal is better than LL23. If > > there is rough consensus support for your proposal - we will create an > > issue to track it and take it through 1 week last call. > > > > Remember the bar is high. We cannot keep cycling over decisions unless > > there is an extremely compelling alternative. > > > > I hope that those of you who were not satisfied with the process by > > which we arrived at an ACCEPT of LL23 rough consensus call will find > > that this manner of revisiting LL23 is fair and appropriate. > > > > Erik Guttman > > Zeroconf WG chair > > > ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n N1 Installation and Provisioning Sun Microsystems cell: +49 172 865 5497 From owner-zeroconf@merit.edu Fri Apr 11 08:52: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 IAA10742 for ; Fri, 11 Apr 2003 08:52:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A921891285; Fri, 11 Apr 2003 08:54:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7435091283; Fri, 11 Apr 2003 08:54:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 751D791282 for ; Fri, 11 Apr 2003 08:54:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 623085DF83; Fri, 11 Apr 2003 08:54:50 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id E13035DF90 for ; Fri, 11 Apr 2003 08:54:49 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA08357 for ; Fri, 11 Apr 2003 06:54:48 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h3BCsll08307; Fri, 11 Apr 2003 14:54:47 +0200 (MEST) Date: Fri, 11 Apr 2003 14:54:45 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: erik.nordmark@Sun.COM Subject: WG Action - Reject [LL14] Add security consideration for the threat if the same address is used for multiple interfaces - force reconfiguration will effect multiple links In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Action: Reject Since LL15 has been accepted - this issue is no longer relevent. Erik Guttman ZEROCONF WG Chair --------------------------------------------------------- On Thu, 3 Apr 2003, Erik Guttman wrote: > Date: Thu, 3 Apr 2003 18:19:31 +0200 (CEST) > From: Erik Guttman > To: zeroconf@merit.edu > Cc: erik.nordmark@Sun.COM > Subject: WG Action - 1 week last call [LL14] Add security consideration for the threat if the same address is used for multiple interfaces - force reconfiguration will effect multiple links > > > This item is entering a 1 week last call discussion period, ending Apr > 10, 2003. Please send a comment to the working group list indicating > whether you accept or reject the proposal, including more information if > appropriate. Please use the subject line: > > [LL14] Add security consideration for the threat ... > > ====================================================================== > If LL15 is accepted, this security consideration no longer applies, > right? > ====================================================================== > > Description of Issue Add security consideration for the threat if the > same address is used for multiple interfaces - force reconfiguration > will effect multiple links > 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 5 > Rationale/Explanation of issue: > Lengthy description of problem: > 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. > > Requested Change: > > Change text to: > > 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 > not necessary to ensure that all local interfaces have distinct > addresses, nor to ensure that all local interfaces have addresses that > are distinct with respect to ALL links to which the host has > connectivity. Such a host may choose to initially configure all > interfaces with a single common IPv4 link-local address, and defend that > address on all interfaces, but in the event that an address conflict is > detected on a particular link, only the interface(s) directly connected > to that link should select a new address as described in Section 2. > Reconfiguring all interfaces to a new common IPv4 link-local address > could needlessly break TCP connections that may have already been > established on other links where there is no address conflict. > > > Erik Guttman > Zeroconf WG chair > > > > ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n N1 Installation and Provisioning Sun Microsystems cell: +49 172 865 5497 From owner-zeroconf@merit.edu Fri Apr 11 08:52:44 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 IAA10758 for ; Fri, 11 Apr 2003 08:52:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 43D8891281; Fri, 11 Apr 2003 08:54:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1320291283; Fri, 11 Apr 2003 08:54:36 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1356C91281 for ; Fri, 11 Apr 2003 08:54:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E88985DF90; Fri, 11 Apr 2003 08:54:31 -0400 (EDT) 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 608815DF83 for ; Fri, 11 Apr 2003 08:54:31 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA13140 for ; Fri, 11 Apr 2003 05:54:30 -0700 (PDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h3BCsSl08180 for ; Fri, 11 Apr 2003 14:54:28 +0200 (MEST) Date: Fri, 11 Apr 2003 14:54:27 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: [LL12] [LL20] discussion not yet conclusive - continue till 17 Apr 03 In-Reply-To: <28907.1049549805@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 help try and close these issues by Apr 17. Aside from the authors of the proposed text it appears no one supports these issue formulations. Given that there are millions of hosts using LL right now with fixed timer values - successfully - this cannot be a very hard problem to get right for a general case. If it doesn't work in some cases, well gee, we will get conflicts we will have to resolve. Please either support or reject these issues or offer a *simple and complete alternative.* Erik Guttman Zeroconf WG chair From owner-zeroconf@merit.edu Fri Apr 11 08:52: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 IAA10760 for ; Fri, 11 Apr 2003 08:52:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D2D2291282; Fri, 11 Apr 2003 08:55:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A45D891283; Fri, 11 Apr 2003 08:55:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3B24191282 for ; Fri, 11 Apr 2003 08:55:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 29B485DF90; Fri, 11 Apr 2003 08:55:17 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 9ADCB5DF83 for ; Fri, 11 Apr 2003 08:55:16 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA06737 for ; Fri, 11 Apr 2003 05:55:15 -0700 (PDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h3BCsxl08371; Fri, 11 Apr 2003 14:55:14 +0200 (MEST) Date: Fri, 11 Apr 2003 14:54:57 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: erik.nordmark@sun.com Subject: WG Action - Accept [LL15] Algorithm for claim/defend will break if multiple interfaces In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Action: Accept Erik Guttman Zeroconf WG chair On Thu, 3 Apr 2003, Erik Guttman wrote: > Subject: WG Action - 1 week last call [LL15] Algorithm for claim/defend will break if multiple interfaces > > > This item is entering a 1 week last call discussion period, ending Apr > 10, 2003. Please send a comment to the working group list indicating > whether you accept or reject the proposal, including more information if > appropriate. Please use the subject line: > > [LL15] Algorithm for claim/defend will break if multiple interfaces > > ----------------------------------------------------------------------- > Please consider LL30. If we accept LL30, then this issue should > be rejected. > ----------------------------------------------------------------------- > > Description of Issue Algorithm for claim/defend will break if multiple > interfaces are connected to the same link > 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 3.2 > Rationale/Explanation of issue: > > Lengthy description of problem: > > section 3.2 > > 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. 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. > > Erik Guttman suggests > > Each interface should be assigned a different v4LL address and can then > operate independently. > > Requested Change: > > Replace Section 3.2 text with > > A host MUST run the address selection and defense algorithm distinctly > on each interface supporting IPv4 link-local configuration. This > ensures that in the case where more than one of the interfaces are on > the same link the algorithm will terminate. Otherwise, the host may > detect collisions from its own allocations and cause the claim and > defend algorithm to fail. > > > Erik Guttman > Zeroconf WG chair > > > > ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n N1 Installation and Provisioning Sun Microsystems cell: +49 172 865 5497 From owner-zeroconf@merit.edu Fri Apr 11 08:53: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 IAA10802 for ; Fri, 11 Apr 2003 08:53:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D354891283; Fri, 11 Apr 2003 08:55:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9058C91286; Fri, 11 Apr 2003 08:55:28 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2A81491283 for ; Fri, 11 Apr 2003 08:55:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1745C5DF93; Fri, 11 Apr 2003 08:55:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 97D9E5DF94 for ; Fri, 11 Apr 2003 08:55:24 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA04956 for ; Fri, 11 Apr 2003 06:55:23 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h3BCtMl08521; Fri, 11 Apr 2003 14:55:22 +0200 (MEST) Date: Fri, 11 Apr 2003 14:55:20 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: erik.nordmark@sun.com Subject: WG Action - Reject [LL30] Use of link-local configuration on more than one link is NOT RECOMMENDED In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Action: Rejected Note: We may revisit this changing 'NOT RECOMMENDED' to 'NOT DEFINED' if there is support for this on the list. Erik ---------------------------------------------------------------- On Thu, 3 Apr 2003, Erik Guttman wrote: > > This item is entering a 1 week last call discussion period, ending Apr > 10, 2003. Please send a comment to the working group list indicating > whether you accept or reject the proposal, including more information if > appropriate. Please use the subject line: > > [LL30] Use of link-local configuration on more than one link is NOT > RECOMMENDED > > see also http://www.spybeam.org/ll30.html > > Description of Issue Use of link-local configuration on more than one > link is NOT RECOMMENDED > Submitter Name Erik Guttman > Submitter Email Address erik.guttman@sun.com > Date first submitted 03 Apr 2003 > Reference > Comment Type ['T'echnical | 'E'ditorial] T > Priority ['S' Must fix | '1' Should fix | '2' May fix ] 1 > Section 3 (and all subsections of 3) > Rationale/Explanation of issue: > > Several technical issues remain unresolved regarding the use of > link-local autoconfiguration of multiple interfaces. We should recommend > that this not done, or if it is, that these are not easily solved > problems. Lengthy description of problem: The specification currently > discusses use of the protocol on multihomed hosts. > > Section 3 offers only a few complex solutions to the problems it raises, > each requiring sophisticated use of application programming interfaces > which this specification has no control over. Further, this mechanism > (binding TCP connections to interfaces explicitely, and keeping > interface, source and destination tuples associated in applications) > will require applications to be rewritten. This is a major concern (see > issues LL4 and LL5). > > For the sake of clarity, brevity and the best chance that stable > interoperable protocol implementations will result, we should remove > this section all together and replace it with one which simply recommens > that ipv4 LL autoconfiguration be done on a single interface unless > mechanisms can be used to alleviate some known problems. > > Note that the 'big issue' of address ambiguity is not addressed by this > issue. A host which is multihomed may encounter hosts on different > links which have the same address, whether or not the host supports LL > configuration on those distinct interfaces. Consider > > H1(a)-------(b)H2(c)------(a)H3 > > H1 and H3 are both configured with LL address (a). They are on distinct > links. H2 has configured (non-link-local) addresses. H2 knows to send to > link-local destinations directly. (H2 will not forward packets to a > router which have link-local prefix destinations. Rather it will use ARP > and then send the packet directly to the destination.) > > H2 uses SLP to discover a service on both links it is connected to. Both > H1 and H3 support the service and respond. H2 now has locators for > address (a) which are ambiguous - unless the response to the SLP request > keeps the interface information (from which the request originated). > These issues are spelled out and addressed in RFC 3111). > > So - unfortunately, this issue does not eliminate the scoped address > problem. > > Requested Change: > > Replace section 3 and subsections with the following text: > > It is RECOMMENDED that configuration of link-local addresses be done on > only one active interface at a time. This avoids a number of known > problems: > > 1. Address ambiguity: A host H1 has addresses A1 and A2 configured on > its interfaces to L1 and L2 respectively. There is a host H2 with > address A2 on L1. H1 cannot easily determine whether A2 should be used > to communicate with itself or with the host H2. > > 2. Complexity in address selection: A multihomed host may be attached to > the same link with more than interface. This complicates the claim and > defend algorithm somewhat since a host may defend against itself if the > algorithm is implemented in a flawed manner. > > > Erik Guttman > Zeroconf WG Chair > > > ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n N1 Installation and Provisioning Sun Microsystems cell: +49 172 865 5497 From owner-zeroconf@merit.edu Fri Apr 11 08:57: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 IAA10874 for ; Fri, 11 Apr 2003 08:57:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E67A291286; Fri, 11 Apr 2003 09:00:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 751E191287; Fri, 11 Apr 2003 09:00:06 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A58C291286 for ; Fri, 11 Apr 2003 09:00:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD1595DF90; Fri, 11 Apr 2003 09:00:03 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 8A7F85DF9B for ; Fri, 11 Apr 2003 09:00:02 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA06970; Fri, 11 Apr 2003 06:59:59 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h3BCxwl08936; Fri, 11 Apr 2003 14:59:58 +0200 (MEST) Date: Fri, 11 Apr 2003 14:59:57 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: [LL3][LL21][LL29] Decision Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I want to apologize for the amount of time required to reach a decision about the TTL issues. There is a lot of background reading needed to get the full context. I wish we had a less rough consensus for this item. The main thing is - we need to close these issues and complete this work in an orderly manner. Best regards, Erik From owner-zeroconf@merit.edu Fri Apr 11 09:09: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 JAA11273 for ; Fri, 11 Apr 2003 09:09:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2B7EE91287; Fri, 11 Apr 2003 09:12:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB19191288; Fri, 11 Apr 2003 09:11:59 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F38CD91287 for ; Fri, 11 Apr 2003 09:11:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DE1685DD8F; Fri, 11 Apr 2003 09:11:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id 70F615DD8E for ; Fri, 11 Apr 2003 09:11:58 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id HAA16790 for ; Fri, 11 Apr 2003 07:11:53 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h3BDBql09544; Fri, 11 Apr 2003 15:11:52 +0200 (MEST) Date: Fri, 11 Apr 2003 15:11:51 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Cc: erik.nordmark@sun.com Subject: WG Action - Accept [LL13] If the destination is a global multicast address a host SHOULD use a global source address In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Action: Accept Note: A proper reference for link-local multicast is needed. RFC 2365 describes this scope. There may be a better reference (normative) - but I do not know it. Erik Guttman Zeroconf WG chair -------------------------------- On Thu, 3 Apr 2003, Erik Guttman wrote: > Subject: WG Action - 1 week last call [LL13] If the destination is a global multicast address a host SHOULD use a global source address > > This item is entering a 1 week last call discussion period, ending Apr > 10, 2003. Please send a comment to the working group list indicating > whether you accept or reject the proposal, including more information if > appropriate. Please use the subject line: > > [LL13] If the destination is a global multicast address a host SHOULD > use a global source address > > ======================================================================= > In light of LL23, this goes without saying. Do you agree? > > In case LL23 gets revisited, please do express your opinion of > this item. > ======================================================================= > > 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. > > > > Erik Guttman > Zeroconf WG chair > > > > ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n N1 Installation and Provisioning Sun Microsystems cell: +49 172 865 5497 From owner-zeroconf@merit.edu Fri Apr 11 09:12: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 JAA11368 for ; Fri, 11 Apr 2003 09:12:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2359891288; Fri, 11 Apr 2003 09:14:37 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E6C1D91289; Fri, 11 Apr 2003 09:14:36 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1980191288 for ; Fri, 11 Apr 2003 09:14:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0147E5DD8E; Fri, 11 Apr 2003 09:14:36 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id B82705DD8D for ; Fri, 11 Apr 2003 09:14:30 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id HAA17999; Fri, 11 Apr 2003 07:14:28 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h3BDEQl09666; Fri, 11 Apr 2003 15:14:26 +0200 (MEST) Date: Fri, 11 Apr 2003 15:14:25 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: REQUEST FOR TEXT: [LL4][LL5] Need Text input! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk In order to respond to issues LL4 and LL5, we need text input. Please see http://www.spybeam.org/ll4.html and http://www.spybeam.org/ll5.html Thank you, Erik From owner-zeroconf@merit.edu Fri Apr 11 09:17: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 JAA11465 for ; Fri, 11 Apr 2003 09:17:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A543691289; Fri, 11 Apr 2003 09:19:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70B9C9128A; Fri, 11 Apr 2003 09:19:39 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7F41591289 for ; Fri, 11 Apr 2003 09:19:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 688F75DD94; Fri, 11 Apr 2003 09:19:38 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id BCD145DD93 for ; Fri, 11 Apr 2003 09:19:37 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id HAA21020 for ; Fri, 11 Apr 2003 07:19:36 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h3BDJZl10090 for ; Fri, 11 Apr 2003 15:19:35 +0200 (MEST) Date: Fri, 11 Apr 2003 15:19:33 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: WG Action - 1 week to discuss [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 discuss the following item. Discussion should conclude by Apr 18, 2003. Please post your comments to the WG mailing list zeroconf@merit.edu. Description of Issue Delete inappropriate advice to network operators Submitter Name Robert Elz Submitter Email Address kre@munnari.OZ.AU Date first submitted 8 Feb 2003 Reference Comment Type ['T'echnical | 'E'ditorial] T & E Priority ['S' Must fix | '1' Should fix | '2' May fix ] 1 Section 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 Fri Apr 11 09: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 JAA11563 for ; Fri, 11 Apr 2003 09:22:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4C4319128A; Fri, 11 Apr 2003 09:24:59 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19C1A9128B; Fri, 11 Apr 2003 09:24:59 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E5DF9128A for ; Fri, 11 Apr 2003 09:24:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1FAAE5DD91; Fri, 11 Apr 2003 09:24:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id A53CB5DD8E for ; Fri, 11 Apr 2003 09:24:57 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id HAA24027 for ; Fri, 11 Apr 2003 07:24:56 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h3BDOtl10404 for ; Fri, 11 Apr 2003 15:24:55 +0200 (MEST) Date: Fri, 11 Apr 2003 15:24:53 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: WG Action - 1 week to discuss [LL28] Applicability of Document Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Please discuss this item and post your comments to the ZEROCONF WG list . The discussion should conclude by Apr 18, 2003. Please also see http://www.spybeam.org/ll28.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 Fri Apr 11 09:43: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 JAA12285 for ; Fri, 11 Apr 2003 09:43:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0F03E9128C; Fri, 11 Apr 2003 09:45:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC5579128D; Fri, 11 Apr 2003 09:45:33 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C48A89128C for ; Fri, 11 Apr 2003 09:45:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A7F0C5DDA4; Fri, 11 Apr 2003 09:45:32 -0400 (EDT) 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 29F885DDA3 for ; Fri, 11 Apr 2003 09:45:32 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA08519; Fri, 11 Apr 2003 06:45:19 -0700 (PDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h3BDjHl11218; Fri, 11 Apr 2003 15:45:17 +0200 (MEST) Date: Fri, 11 Apr 2003 15:45:16 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: ZEROCONF WG status Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The following items remain for the ZEROCONF WG ------------------------------------------------------------------- Requirements for Automatic Configuration of IP Hosts No work has been done on this document for some time. Key areas never achieved consensus (even rough) in the WG. There is no longer energy to continue work on it. I think we need to put it to sleep and the Internet Area Directors concur. Unless someone can leap to the defense of this work, we will remove it from the WG charter. I thank Myron Hattig and Aidan Williams for their editorial and textual contributions in any case. It is a shame we could not determine the contour and extent of zeroconf networking through a definition of its requirements. ------------------------------------------------------------------- Dynamic Configuration of IPv4 Link-Local addresses We currently have the following items open for discussion till next Friday 18, Apr 2003. Please send support/reject/alternatives for [LL12] Does shorter timeouts for specific link technology lead to problems? [LL20] Alternate text for 'Does shorter timeouts for specific link technology lead to problems?' [LL22] Delete inappropriate advice to network operators [LL28] Applicability of Document The following items are still open and require text before we can discuss them: [LL4] No examples of applications [LL5] Higher layer protocol considerations is not sufficiently draconian I owe Alex Zinin and the WG list a new issue on a Routing Considerations section I volunteered to write. Alex has given me lots of feedback. We have had two rough consensus calls [LL23] and [LL29] vs. alternatives. Given the contentiousness of the debate on these points over many months (years, actually) - it is not surprising we did not come to a unanimous conclusion. The plan: - close remaining items (by end of April) - issue a new draft (early May at the latest, though an interim draft before then incorporating changes would be welcome!) - additional editing pass (LL26) and clean up by mid May - deliver to IESG for their review (probably a new IETF last call will be required, etc) by mid May Thanks for your continuing efforts to complete work on this document. Erik From owner-zeroconf@merit.edu Fri Apr 11 10: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 KAA14515 for ; Fri, 11 Apr 2003 10:25:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BB6B291277; Fri, 11 Apr 2003 10:28:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D1399128D; Fri, 11 Apr 2003 10:28:00 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 852DC91277 for ; Fri, 11 Apr 2003 10:27:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6F2F95DDAA; Fri, 11 Apr 2003 10:27:59 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 49A6F5DDAB for ; Fri, 11 Apr 2003 10:27:58 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3BE9iJ14682 for ; Fri, 11 Apr 2003 07:09:44 -0700 Date: Fri, 11 Apr 2003 07:09:44 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: LL4 text Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Before coming up with text for this, I think that we need to have agreement on the characteristics of applications that will cause them to fail when used with LLv4 addresses. I do not believe that just because an application uses LLv4 addresses that it will fail. The problem is not use by itself -- it is use of linklocal addresses IPv4 addresses in the wrong context. If an application uses its LLv4 address in communicating with a host off the link, it will break. However, if it uses that address in communicating with a host on-link then that should not happen. In looking at this, I believe the problem is "leakage". Including an LLv4 address in an off-link application exchange is an example of leakage -- and I believe that this MUST NOT be done at any layer. Similarly, I do not believe that including domain names in an application is by itself a problem -- unless it involves leakage. Examples of leakage include using LLv4 addresses in DNS. Including a name in an application where DNS is not configured among the conversants is not a problem -- assuming LLMNR is available to resolve the name. If the above makes sense, then I do not think it is necessarily appropriate to come up with "lists of applications" that will automatically fail. Rather we should focus on what applications need to do in order to be successful. Here is some proposed text: "Use of linklocal IPv4 addresses in off-link communication is likely to cause application failures. This can occur within any application that includes embedded addresses, if an LLv4 addresses is embedded when communicating with a host that is not on the link. Examples of applications that include embedded addresses are found in [RFC3027]. This includes IPsec, Kerberos 4/5, X-Windows/Xterm/Telnet, FTP, RSVP, SMTP, SIP, Real Audio, H.323, and SNMP. In order to prevent use of LLv4 addresses in off-link communication, the following cautionary measures are advised: a. Routable addresses should be used within applications whenever they are available. b. Names that are globally resolvable to routable addresses should be used within applications whenever they are available. Names that are resolvable only on the local link (such as through use of protocols such as LLMNR) MUST NOT be used in off-link communication. This can be prevented by using LLv4 addresses or names resolvable on the local link when an LLv4 address is used as the source address in the packet. c. LLv4 addresses MUST NOT be configured in the DNS." From owner-zeroconf@merit.edu Fri Apr 11 12: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 MAA20789 for ; Fri, 11 Apr 2003 12:47:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D2DC191290; Fri, 11 Apr 2003 12:49:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A062691291; Fri, 11 Apr 2003 12:49:45 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7242591290 for ; Fri, 11 Apr 2003 12:49:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 57C205DDC4; Fri, 11 Apr 2003 12:49:44 -0400 (EDT) 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 F2BEE5DDC1 for ; Fri, 11 Apr 2003 12:49:43 -0400 (EDT) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Fri, 11 Apr 2003 09:49:42 -0700 Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 11 Apr 2003 09:49:42 -0700 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.3788.0); Fri, 11 Apr 2003 09:49:42 -0700 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); Fri, 11 Apr 2003 09:49:41 -0700 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.3788.0); Fri, 11 Apr 2003 09:49:41 -0700 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: [LL12] [LL20] discussion not yet conclusive - continue till 17 Apr 03 Date: Fri, 11 Apr 2003 09:49:40 -0700 Message-ID: Thread-Topic: [LL12] [LL20] discussion not yet conclusive - continue till 17 Apr 03 Thread-Index: AcMAKZqlJgHTRtBDTMedootxrg2xVwAGImTQ From: "Christian Huitema" To: "Erik Guttman" , X-OriginalArrivalTime: 11 Apr 2003 16:49:41.0675 (UTC) FILETIME=[58F83FB0:01C3004A] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA20789 Perfection is not achievable: we can always envisage that two auto-configured networks are suddenly merged, e.g. by someone plugging a wire in a hub. The number of repetitions and the timers are thus a compromise between the desired reliability and the time it takes to achieve it. There is already an equivalent proposed standard, the duplicate address detection procedure used during auto-configuration of IPv6 addresses. The text says (RFC 2462, page 14): To check an address, a node sends DupAddrDetectTransmits Neighbor Solicitations, each separated by RetransTimer milliseconds. The solicitation's Target Address is set to the address being checked, the IP source is set to the unspecified address and the IP destination is set to the solicited-node multicast address of the target address. The retransmission timer can be configured by the routers (through the router advertisements), and the default value is set to 1000 milliseconds (RFC 2641). The default value for DupAddrDetectTransmits in RFC 2462 is 1. The important value is the residual collision rate after a cycle of retransmissions. This probability is a function of the number of hosts, the size of the number space, and the probability that a single transmission fails. I would contend that the "spanning tree black-out" is a rare event that can be incorporated in the transmission failure probability; that this transmission failure should generally be under a few % for TCP to operate correctly; and that it is safe to assume that the probability of a request/response transaction failing is under 5%. Under these circumstances, we can compute the residual probability for a network of 1300 hosts, a 62 bit number space (RFC 2462), and a population of 1300 hosts: it is about 1.4E-17. To achieve the same reliability with a 16 bit number space would require 12 repetitions. To achieve "five nines" (i.e. a failure rate lower than 10-5) requires 3 repetitions. Setting the timer to 1 second is consistent with RFC 2462. Setting the repetition number to 3 achieves a better than 5 nines reliability in most networks. I propose to resolve LL12 and LL20 by proposing the following replacement text. In section 2.2, replace: When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range zero to two seconds, and should then send four probe packets, spaced two seconds apart. This initial random delay helps ensure that a large number of hosts powered on at the same time do not all send their initial probe packets simultaneously. By: Probing is performed in two phases: a random initial interval, followed by repeated probes. The purpose of the initial interval is to ensure that a large number of hosts powered on at the same time do not all send their initial probe packets simultaneously. When ready to begin probing, the host SHOULD then wait for a random time interval selected uniformly in the range zero to 200 milliseconds. During that period, the host should listen for probes sent by other nodes on the link. If the host receives more than 50 probes during the interval, it SHOULD restart the timer to a new value, chosen again between 0 and 200 milliseconds. Listening during the probing interval introduces an automatic back-off procedure. It allows the use of a short interval while ensuring that the number of probes on the network will be at most a few hundred per second. Hosts that cannot implement the listen and back-off algorithm described in the previous paragraph MAY simply wait for random spreading interval selected uniformly in the range zero to two seconds. After the random spreading interval, the host SHOULD send 3 probe packets, spaced 1 second apart. In fact, we may debate the spacing requirement. A random spacing would be better, as it would avoid synchronization effects. And there is no real justification for the 1 second interval. A random interval should be just as good. -- Christian Huitema > -----Original Message----- > From: Erik Guttman [mailto:Erik.Guttman@Sun.COM] > Sent: Friday, April 11, 2003 5:54 AM > To: zeroconf@merit.edu > Subject: [LL12] [LL20] discussion not yet conclusive - continue till 17 > Apr 03 > > > Folks, > > Please help try and close these issues by Apr 17. > > Aside from the authors of the proposed text it appears no one supports > these issue formulations. Given that there are millions of hosts using > LL right now with fixed timer values - successfully - this cannot be a > very hard problem to get right for a general case. If it doesn't work > in some cases, well gee, we will get conflicts we will have to resolve. > > Please either support or reject these issues or offer a *simple and > complete alternative.* > > Erik Guttman > Zeroconf WG chair > > From owner-zeroconf@merit.edu Fri Apr 11 13: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 NAA22924 for ; Fri, 11 Apr 2003 13:59:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7AED691296; Fri, 11 Apr 2003 14:01:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4464491297; Fri, 11 Apr 2003 14:01:39 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E5E291296 for ; Fri, 11 Apr 2003 14:01:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0F8265DDCF; Fri, 11 Apr 2003 14:01:38 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 963695DDC3 for ; Fri, 11 Apr 2003 14:01:37 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.9/8.12.9) with ESMTP id h3BI1b3h029614 for ; Fri, 11 Apr 2003 11:01:37 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 11 Apr 2003 11:01:36 -0700 Received: from apple.com (graejo5.apple.com [17.202.43.251]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h3BI1abN002794 for ; Fri, 11 Apr 2003 11:01:36 -0700 (PDT) Date: Fri, 11 Apr 2003 11:01:42 -0700 Subject: Re: WG Action - Accept [LL29] Link-local sources should specify TTL=1 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The last paragraph of section A.2 regarding Mac OS X 10.2's should be changed. Mac OS X 10.2 sets the TTL on all outgoing packets with a source or destination IPv4LL address to 255. Mac OS X 10.2 discards all incoming packets with a source or destination IPv4LL address if the TTL is not 255, making any implementation of this standard incompatible with Mac OS X 10.2. -josh On Friday, Apr 11, 2003, at 05:54 US/Pacific, Erik Guttman wrote: > LL29: Link-local sources should specify TTL=1 > > Decision: Accept > Action: Change the first two paragraphs of section 2.7 to read > > 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 by default. This includes multicast and broadcast > packets with a source address in the 169.254/16 prefix. An > application may set the TTL to any value, using established > interfaces for this purpose, overriding the default. > > This suggested behavior 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. > > > Notes: This proposal is consistent with current practice and > interpretation of TTL. (Ralph Droms) > > This proposal prevents leakage of datagrams from the local > link in several plausible scenarios. > > This proposal explicitely allows setting of TTL for apps. > > This proposal was supported by most of the WG participants. > > Erik Guttman > Zeroconf WG chair > > From owner-zeroconf@merit.edu Fri Apr 11 15:04: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 PAA24905 for ; Fri, 11 Apr 2003 15:04:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BAD0A91201; Fri, 11 Apr 2003 15:06:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8856C91297; Fri, 11 Apr 2003 15:06:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6DF8E91201 for ; Fri, 11 Apr 2003 15:06:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 505855DDC2; Fri, 11 Apr 2003 15:06:37 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id D75885DDB1 for ; Fri, 11 Apr 2003 15:06:36 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.9/8.12.9) with ESMTP id h3BJ6a3h018707 for ; Fri, 11 Apr 2003 12:06:36 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 11 Apr 2003 12:06:35 -0700 Received: from apple.com (graejo5.apple.com [17.202.43.251]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h3BJ6ZbN025223 for ; Fri, 11 Apr 2003 12:06:35 -0700 (PDT) Date: Fri, 11 Apr 2003 12:06:41 -0700 Subject: Re: WG Action - Accept [LL29] Link-local sources should specify TTL=1 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I apologize for not responding earlier. I had given up on this working group for a while. I recognize that the issue is closed, but I believe there is a technical reason that this issue should be reopened. The new proposal breaks existing implementations. While this isn't necessarily a problem, it's a bit ironic since one of the reasons the document was changed was the fear of breaking compatibility. A while ago, the draft was set TTL 255, check TTL 255. It was noted that the TTL 255 check would cause compatibility problems so it was dropped from the draft. It was later noted that since the TTL 255 check can not be performed for the foreseeable future, setting the TTL to 255 was silly, so the draft was changed to say the TTL should be set to 1. Set TTL 255 and not check doesn't break anything. Set TTL 255 and check breaks some implementations, though we've never received a report of problems. Set TTL 1 breaks some implementations. If you're really serious about not breaking any implementations, it seems the right thing to do is set the TTL to 255. If you don't care about compatibility, then why is setting the TTL to 1 an better than 255? If I'm too late, let me know and I won't argue further. -josh On Friday, Apr 11, 2003, at 05:54 US/Pacific, Erik Guttman wrote: > LL29: Link-local sources should specify TTL=1 > > Decision: Accept > Action: Change the first two paragraphs of section 2.7 to read > > 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 by default. This includes multicast and broadcast > packets with a source address in the 169.254/16 prefix. An > application may set the TTL to any value, using established > interfaces for this purpose, overriding the default. > > This suggested behavior 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. > > > Notes: This proposal is consistent with current practice and > interpretation of TTL. (Ralph Droms) > > This proposal prevents leakage of datagrams from the local > link in several plausible scenarios. > > This proposal explicitely allows setting of TTL for apps. > > This proposal was supported by most of the WG participants. > > Erik Guttman > Zeroconf WG chair > > From owner-zeroconf@merit.edu Mon Apr 14 21:28: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 VAA29574 for ; Mon, 14 Apr 2003 21:28:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3433B91262; Mon, 14 Apr 2003 21:30:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F20FD91263; Mon, 14 Apr 2003 21:30:35 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E5F7D91262 for ; Mon, 14 Apr 2003 21:30:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD3555DF93; Mon, 14 Apr 2003 21:30:27 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1DD885DF94 for ; Mon, 14 Apr 2003 21:30:27 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3F1Brc00796 for ; Mon, 14 Apr 2003 18:11:53 -0700 Date: Mon, 14 Apr 2003 18:11:53 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: WG Action - Accept [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 I agree with Joshua on this one. The impetus for raising this issue was backward compatibility. There are some implementations that send with TTL=255 and check it; there are some implementations that send with TTL != 255 (128, specifically) and don't check it. There are *no* implementations that send with TTL=1 today. Given this, it's difficult to see how we promote maximum "backward compatibility" by choosing an option that *noone* implements. This way most implementations break, not just some. Of course, this choice is probably equivalent to deleting all mention of TTL since I doubt that any implementations will change to support TTL=1. About the only thing that TTL=1 achieves is to limit global multicast propagation by packets sourced from an IPv4 LL address. This is somewhat useful, but hardly a major concern (if it were, it could be special cased). From owner-zeroconf@merit.edu Wed Apr 16 18:12: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 SAA19425 for ; Wed, 16 Apr 2003 18:12:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EE6F9912A0; Wed, 16 Apr 2003 18:01:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBD08912A2; Wed, 16 Apr 2003 18:00:59 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 711CA912A0 for ; Wed, 16 Apr 2003 18:00:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5F43C5DDEC; Wed, 16 Apr 2003 18:00:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id BD4C35DDD7 for ; Wed, 16 Apr 2003 18:00:57 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id DEF7C59901; Wed, 16 Apr 2003 23:00:55 +0100 (BST) Message-ID: <004501c30463$a215b1b0$1a1010ac@aldebaran> From: "Philip Nye" To: "Mika Liljeberg" , "Erik Guttman" Cc: References: <1049631310.20483.1059.camel@devil> Subject: Re: concerns about ACCEPT [LL23] Don't configure needless LLaddresses Date: Wed, 16 Apr 2003 22:00:46 -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 I am beginning to think that this issue is a red herring. Whether or not you maintain two separate addresses or just one, the real problem is to establish whether an address "works" and particularly to do so at the stack/OS level. Maintaining both an LL address and a global one, doesn't really help (or hinder) that process. Simply having a LL address available does not help the stack know when to use it. You say that you have the necessary APIs to deal with address ambiguity - does this mean that you are writing or adapting your own apps to take advantage of this API? In cases (typical of many embedded systems) where apps are more or less custom written and are very closely coupled to the stack/OS, I can't see any abjection to running both LL and global side by side - but nor can I see an abjection to the LL23 approach either - because in both cases the app and the stack work together to use the best address available and the app can be written to be aware of scope limitations when it is using or communicating with a LL address. Couldn't an API similar to yours work with LL23, by allowing the app to say "communications aren't working, please try a different address strategy"? It is generally far easier for an application to make the decision as to when an address is working than for the stack/OS. This would be consistent with Erik's suggestion of changing some MUSTs to SHOULDs. It would also be consistent with Erik's suggestion a few weeks ago of interpreting "Configured routable address" as implying that that address works. Would it help if the text was changed to refer to when to *use* a particular address rather than when to *obtain* (or relinquish) it? I see no real problem in continuing to defend an LL address "in the background" even when a routable address is working so long as that LL address doesn't get used (it is kept in case the network configuration changes). Similarly I do not see that a valid DHCP lease or manual configuration needs to be relinquished because it is not currently working and an LL address is being used in the interim (perhaps because the host has moved to another network). What does cause real trouble is using the LL address in a network where the routable one is valid and working and where applications are not scope aware (that's most applications for general purpose computers). Philip ----- Original Message ----- From: "Mika Liljeberg" To: "Erik Guttman" Cc: Sent: Sunday, April 06, 2003 12:15 PM Subject: Re: concerns about ACCEPT [LL23] Don't configure needless LLaddresses > Erik, > > Any way I look at it, concern (2) is a show stopper for us. Before the > SF meeting I was trying to come up with an alternative solution that > would satisfy both camps but the more I turn it over in my head the more > convinced I become that retracting LL23 completely is the only robust > solution. > > At this point in time, I think the onus for finding a workable solution > to (2) now rests on the proponents of LL23. Until such a solution is > forthcoming, I believe we will simply have to ignore these particular > requirements in our implementation. Technically this is allowed, as we > can assign a global address to one interface and a LL address to > another, and connect those interfaces to the same link. We have a > multi-site, multi-homing capable host implementation that has the > necessary APIs to deal with the address ambiguity. So, we should be able > to cope. > > As Stuart so aptly stated, "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". > > Regards, > > MikaL > > On Fri, 2003-04-04 at 15:54, Erik Guttman wrote: > > I have received requests from three WG participants who have concerns > > both about the decision to accept LL23 and the process by which it was > > decided. > > > > Regarding the process - I am doing my best to include all points of view > > and discover the consensus, even if it is rough. If I could do a better > > job of this, please let me know and offer concrete suggestions. We do > > not have the luxury of leaving these decisions for a brighter day when > > we finally collectively emerge from the cave of ignorance. Further, we > > have to consider the context in which we are making these decisions: We > > must answer IESG issues expressed *LAST OCTOBER* so we can get this > > document out as a standards track RFC. > > > > Regarding the decision - > > > > The following concerns have been expressed to me > > > > (1) While LL23 instructs a host to use a routable address instead of > > a link-local address as its source address (if it has one), the > > host can keep using link-local addresses for connections underway > > and even accept new communications on the link-local address. > > Thus, the scoped address (source address selection) problem does > > not go away - it is only 'contained' to some extent. > > > > (2) If we 'give up' our link-local address and cease to advertise it > > (using LLMNR, SLP, etc) as long as we have a valid DHCP lease, > > there are situations where we will roam and not use link-local > > auto-configuration (where we could). If we eagerly shed our > > DHCP configuration in INIT-REBOOT state and we do not hear > > from the DHCP server (see (3) in Sec 3.2 of RFC 2131), we may > > lose our legitimate configuration in a network where we should > > keep it. This problem is exacerbated by the pressure for rapid > > usability of systems. Waiting 5 minutes is not acceptable. LL23 > > forces vendors to trade off rapid usability and robust operation. > > > > As WG chair I must emphasize that the bar on revisiting a close issue is > > very high. We must show either that the resolution is totally broken or > > that a significantly better alternative exists which can achieve WG > > consensus. > > > > - An alternative which leaves open issues of scoped address > > architecture for an indefinite period of time has been shown to > > not achieve WG consensus and leave several issues open which will > > prove very difficult to address without a 'transition' mechanism > > (namely LL1, LL4 and LL5). > > > > - Is (1) really a problem, given that only 'open' connections and > > 'accepted' connections are possible with link-local after a routable > > configuration occurred? > > > > - We should explore (2) more. Can we give guidance for timers and > > express caveats like - if you eagerly give up DHCP configuration, > > you MUST regularly attempt to reenter INIT-REBOOT and resume use > > of the configured address if the DHCP server responds. Or, you > > should attempt to send a ICMP message to your configured router > > and if it responds, continue to use the routable address even if > > DHCP doesn't respond, etc. > > > > Next steps - > > > > Those who are intent on revisiting this point, please post a message to > > the list expressing why we must do so, how we can meet existing concerns > > (see LL1, LL4 and LL5), and why your proposal is better than LL23. If > > there is rough consensus support for your proposal - we will create an > > issue to track it and take it through 1 week last call. > > > > Remember the bar is high. We cannot keep cycling over decisions unless > > there is an extremely compelling alternative. > > > > I hope that those of you who were not satisfied with the process by > > which we arrived at an ACCEPT of LL23 rough consensus call will find > > that this manner of revisiting LL23 is fair and appropriate. > > > > Erik Guttman > > Zeroconf WG chair > > > From owner-zeroconf@merit.edu Thu Apr 17 16: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 QAA06405 for ; Thu, 17 Apr 2003 16:23:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CA128912C6; Thu, 17 Apr 2003 16:26:23 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9121A912C7; Thu, 17 Apr 2003 16:26:23 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F10B912C6 for ; Thu, 17 Apr 2003 16:26:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3FB645DDEC; Thu, 17 Apr 2003 16:26:22 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by segue.merit.edu (Postfix) with ESMTP id 47EE95DE2F for ; Thu, 17 Apr 2003 16:26:21 -0400 (EDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-2) with ESMTP id h3HKS07o015051; Thu, 17 Apr 2003 23:28:01 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-2) id h3HKRxW9015050; Thu, 17 Apr 2003 23:27:59 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: concerns about ACCEPT [LL23] Don't configure needless LLaddresses From: Mika Liljeberg To: Philip Nye Cc: Erik Guttman , zeroconf@merit.edu In-Reply-To: <004501c30463$a215b1b0$1a1010ac@aldebaran> References: <1049631310.20483.1059.camel@devil> <004501c30463$a215b1b0$1a1010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1050611278.14867.56.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 17 Apr 2003 23:27:59 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Philip, On Thu, 2003-04-17 at 01:00, Philip Nye wrote: > I am beginning to think that this issue is a red herring. Well, the words "red haze" seem more appropriate when one tries to implement it. :-) > Whether or not you > maintain two separate addresses or just one, the real problem is to > establish whether an address "works" and particularly to do so at the > stack/OS level. This I fully agree with. > Maintaining both an LL address and a global one, doesn't > really help (or hinder) that process. This I don't. If you have more than one addresses configured, you can try to choose one that works. If you only have one, there is nothing to choose from. It either works or it doesn't. For the application at hand, it's too late to start trying to configure another one. > Simply having a LL address available > does not help the stack know when to use it. True. You have to have rules such as those in RFC3484. > You say that you have the necessary APIs to deal with address ambiguity - > does this mean that you are writing or adapting your own apps to take > advantage of this API? No, quite the opposite. We have a fully scoped implementation. We carry scoping information in address structures and our name resolver APIs return scoped addresses with zone IDs. We observe default address selection rules as described in RFC3484 (applied to both IPv4 and IPv6). Applications don't really have to care about scopes, unless they want to. > In cases (typical of many embedded systems) where > apps are more or less custom written and are very closely coupled to the > stack/OS, I can't see any abjection to running both LL and global side by > side - but nor can I see an abjection to the LL23 approach either - because > in both cases the app and the stack work together to use the best address > available and the app can be written to be aware of scope limitations when > it is using or communicating with a LL address. This is exactly what we're trying to avoid. We have an open OS and we specifically don't require applications to be custom written. If a specific zone needs to be selected, the user does it, not the application. > Couldn't an API similar to yours work with LL23, by allowing the app to say > "communications aren't working, please try a different address strategy"? We don't have such an API and we don't want one. > It > is generally far easier for an application to make the decision as to when > an address is working than for the stack/OS. True. But the right way to do this, IMHO, is to offer the application a choise of destination addresses pre-ordered so that the ones most likely to work are up first. All a robust application has to do is try them in order until it find one that works. A less robust application may only try the first one. That's ok, too. The source address actually has very little relevance. The OS can easily choose one that works in the reverse direction. > This would be consistent with > Erik's suggestion of changing some MUSTs to SHOULDs. It would also be > consistent with Erik's suggestion a few weeks ago of interpreting > "Configured routable address" as implying that that address works. I suppose either of those suggestions would make our implementation slightly more legitimate in the eyes of IETF and, as such, I'm in favor. However, they don't solve the concrete problems we have, and therefore don't effect a change in our implementation. > Would it help if the text was changed to refer to when to *use* a particular > address rather than when to *obtain* (or relinquish) it? This would definately be a step in the right direction. RFC3484 is all about when to use a particular address. However, I also have a problem with the "when to advertise" rules. A node that advertises its addresses has no way of knowing which of those addresses are usable to the recipient of the advertisement. Therefore, a node should be allowed to advertise all the addresses it has, and let the recipient choose the ones that are likely to work, and to present them to the application in order of preference. > I see no real > problem in continuing to defend an LL address "in the background" even when > a routable address is working so long as that LL address doesn't get used > (it is kept in case the network configuration changes). That's good, and I agree, although it's more complex than that. A particular address is not categorically usable or unusable. It depends on context (i.e. the peer). You might have nodes A, B, and C such that A and B are able to communicate using global addresses. So are B and C. However, A and C may not be and therefore have to resort to link-local addresses. It all depends on what on-link routes each of those nodes have. > Similarly I do not > see that a valid DHCP lease or manual configuration needs to be relinquished > because it is not currently working and an LL address is being used in the > interim (perhaps because the host has moved to another network). I agree. > What does > cause real trouble is using the LL address in a network where the routable > one is valid and working and where applications are not scope aware (that's > most applications for general purpose computers). I don't mind other vendors opting for an implementation approach where they only use a single address at a time. That choice may be justified in light of their customer base. However, we're targeting the mobile wireless environment where scoping, intermittent reachability, and changes in topology are facts of life and no amount of wishing otherwise is going to make them go away. Applications also tend to be smarter about reachability and also tend be updated fairly frequently, so there is no significant base of dumb legacy applications to deal with. I appreciate your effort at trying to find a compromise. However, I don't think we need a compromise. I think we need to recognize that the specification is going too far in attempting to guide implementations to a specific solution and, in so doing, limits the applicability of the specification itself. The specification should stick to saying how link-local addresses are supposed to work and not attempt to specify how they interact with the rest of the world. MikaL From owner-zeroconf@merit.edu Sun Apr 20 17:23: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 RAA15945 for ; Sun, 20 Apr 2003 17:23:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A203891217; Sun, 20 Apr 2003 17:25:49 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77D2691218; Sun, 20 Apr 2003 17:25:49 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 65B7091217 for ; Sun, 20 Apr 2003 17:25:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A8B75DED7; Sun, 20 Apr 2003 17:25:48 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 0E7F75DED3 for ; Sun, 20 Apr 2003 17:25:48 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 6BE6C59896; Sun, 20 Apr 2003 22:25:49 +0100 (BST) Message-ID: <000701c30783$63927a40$1a1010ac@aldebaran> From: "Philip Nye" To: "Bernard Aboba" , References: Subject: Re: LL4 text Date: Sun, 20 Apr 2003 21:25:38 -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" ... > > "Use of linklocal IPv4 addresses in off-link communication is likely to > cause application failures. This can occur within any application that > includes embedded addresses, if an LLv4 addresses is embedded when > communicating with a host that is not on the link. Examples of > applications that include embedded addresses are found in [RFC3027]. This > includes IPsec, Kerberos 4/5, X-Windows/Xterm/Telnet, FTP, RSVP, SMTP, > SIP, Real Audio, H.323, and SNMP. I would add any application which passes URLs, where there is any chance that those URLs will contain an IP address rather than a name - this includes HTML, SLP, SSDP and a whole lot more applications. Philip From owner-zeroconf@merit.edu Sun Apr 20 17:59: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 RAA16429 for ; Sun, 20 Apr 2003 17:59:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E13C59121A; Sun, 20 Apr 2003 18:00:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC7EB9121C; Sun, 20 Apr 2003 18:00:14 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3361D9121A for ; Sun, 20 Apr 2003 18:00:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 966A25DF3E; Sun, 20 Apr 2003 18:00:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 665095DEAC for ; Sun, 20 Apr 2003 18:00:07 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h3KLexA26021; Sun, 20 Apr 2003 14:40:59 -0700 Date: Sun, 20 Apr 2003 14:40:59 -0700 (PDT) From: Bernard Aboba To: Philip Nye Cc: zeroconf@merit.edu Subject: Re: LL4 text In-Reply-To: <000701c30783$63927a40$1a1010ac@aldebaran> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Sure. On Sun, 20 Apr 2003, Philip Nye wrote: > > From: "Bernard Aboba" > ... > > > > "Use of linklocal IPv4 addresses in off-link communication is likely to > > cause application failures. This can occur within any application that > > includes embedded addresses, if an LLv4 addresses is embedded when > > communicating with a host that is not on the link. Examples of > > applications that include embedded addresses are found in [RFC3027]. This > > includes IPsec, Kerberos 4/5, X-Windows/Xterm/Telnet, FTP, RSVP, SMTP, > > SIP, Real Audio, H.323, and SNMP. > > I would add any application which passes URLs, where there is any chance > that those URLs will contain an IP address rather than a name - this > includes HTML, SLP, SSDP and a whole lot more applications. > > Philip > From owner-zeroconf@merit.edu Wed Apr 30 12:03: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 MAA10122 for ; Wed, 30 Apr 2003 12:03:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B70779129F; Wed, 30 Apr 2003 12:05:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 907B49129C; Wed, 30 Apr 2003 12:05:11 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2CFD991267 for ; Wed, 30 Apr 2003 12:05:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 176B35DE53; Wed, 30 Apr 2003 12:05:07 -0400 (EDT) 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 C97705DE52 for ; Wed, 30 Apr 2003 12:05:06 -0400 (EDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Wed, 30 Apr 2003 09:05:06 -0700 Received: from 157.54.8.109 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 30 Apr 2003 09:05:06 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 30 Apr 2003 09:05:06 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 30 Apr 2003 09:05:05 -0700 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.3788.0); Wed, 30 Apr 2003 09:05:04 -0700 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 - Accept [LL29] Link-local sources should specify TTL=1 Date: Wed, 30 Apr 2003 09:04:57 -0700 Message-ID: Thread-Topic: WG Action - Accept [LL29] Link-local sources should specify TTL=1 Thread-Index: AcMAZBJ2+B9ItS/GRGmHlBtja1gvfgOzU8fg From: "Christian Huitema" To: "Joshua Graessley" , X-OriginalArrivalTime: 30 Apr 2003 16:05:04.0721 (UTC) FILETIME=[433ABC10:01C30F32] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA10122 > Set TTL 255 and not check doesn't break anything. > Set TTL 255 and check breaks some implementations, though we've never > received a report of problems. > Set TTL 1 breaks some implementations. > > If you're really serious about not breaking any implementations, it > seems the right thing to do is set the TTL to 255. If you don't care > about compatibility, then why is setting the TTL to 1 an better than > 255? It is very clear that any mandate is going to break something. The question is very much what the default should be. I believe that using a TTL 1 makes sense in a lot of cases. It is the right thing to do when sending UDP multicast. With TCP, the combination of TTL=1 and the three ways handshake gives you a pretty airtight solution. So it is pretty clear that if a system wanted to choose TTL=1 by default, they should be authorized to do so. -- Christian Huitema From owner-zeroconf@merit.edu Wed Apr 30 13:09: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 NAA12695 for ; Wed, 30 Apr 2003 13:09:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AEB3691273; Wed, 30 Apr 2003 13:11:50 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8240A9129B; Wed, 30 Apr 2003 13:11:50 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 88A5291273 for ; Wed, 30 Apr 2003 13:11:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 69A9D5DE90; Wed, 30 Apr 2003 13:11:49 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id F190D5DE89 for ; Wed, 30 Apr 2003 13:11:48 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.9/8.12.9) with ESMTP id h3UHBm3h013087 for ; Wed, 30 Apr 2003 10:11:48 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 30 Apr 2003 10:11:36 -0700 Received: from apple.com (graejo5.apple.com [17.202.43.251]) by scv3.apple.com (8.12.9/8.12.9) with ESMTP id h3UHBlIa015226 for ; Wed, 30 Apr 2003 10:11:47 -0700 (PDT) Date: Wed, 30 Apr 2003 10:11:48 -0700 Subject: Re: WG Action - Accept [LL29] Link-local sources should specify TTL=1 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Apr 30, 2003, at 09:04 US/Pacific, Christian Huitema wrote: >> Set TTL 255 and not check doesn't break anything. >> Set TTL 255 and check breaks some implementations, though we've never >> received a report of problems. >> Set TTL 1 breaks some implementations. >> >> If you're really serious about not breaking any implementations, it >> seems the right thing to do is set the TTL to 255. If you don't care >> about compatibility, then why is setting the TTL to 1 an better than >> 255? > > It is very clear that any mandate is going to break something. The > question is very much what the default should be. I believe that using > a > TTL 1 makes sense in a lot of cases. It is the right thing to do when > sending UDP multicast. With TCP, the combination of TTL=1 and the three > ways handshake gives you a pretty airtight solution. So it is pretty > clear that if a system wanted to choose TTL=1 by default, they should > be > authorized to do so. I'm not sure I follow. How does requiring the TTL be set to 255 and not requiring any check break anything? The only implementations doing any checking are checking for TTL 255. If you set the TTL to 255, you will work with those implementations. If you check for TTL 255, you will fail to interoperate with implementations that don't set the TTL to 255. If you set the TTL to anything other than 255, you fail to interoperate with implementations that perform the TTL 255 check. -josh From owner-zeroconf@merit.edu Wed Apr 30 15:13: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 PAA20416 for ; Wed, 30 Apr 2003 15:13:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A53969126C; Wed, 30 Apr 2003 15:15:26 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64A089129B; Wed, 30 Apr 2003 15:15:26 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 466359126C for ; Wed, 30 Apr 2003 15:15:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 572185DF15; Wed, 30 Apr 2003 15:15:16 -0400 (EDT) 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 DF45D5DF13 for ; Wed, 30 Apr 2003 15:15:15 -0400 (EDT) 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, 30 Apr 2003 12:15:15 -0700 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 30 Apr 2003 12:15:15 -0700 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); Wed, 30 Apr 2003 12:15:14 -0700 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); Wed, 30 Apr 2003 12:15:14 -0700 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.3788.0); Wed, 30 Apr 2003 12:15:13 -0700 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 - Accept [LL29] Link-local sources should specify TTL=1 Date: Wed, 30 Apr 2003 12:06:32 -0700 Message-ID: Thread-Topic: WG Action - Accept [LL29] Link-local sources should specify TTL=1 Thread-Index: AcMPQ1LMZptwTH9jTXOmXNzcPF4AbgACA4xQ From: "Christian Huitema" To: "Joshua Graessley" , X-OriginalArrivalTime: 30 Apr 2003 19:15:14.0093 (UTC) FILETIME=[D3BEBDD0:01C30F4C] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA20416 > The only implementations doing any checking are checking for TTL 255. ... and failing to interoperate with pre-existing implementations that don't check the TTL to 255. Let's face it: there will not be a consensus to set the TTL to any particular value, including 255. -- Christian Huitema From owner-zeroconf@merit.edu Wed Apr 30 15:45: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 PAA21979 for ; Wed, 30 Apr 2003 15:45:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F1185912A0; Wed, 30 Apr 2003 15:48:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE8FC912A3; Wed, 30 Apr 2003 15:48:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 575CB912A0 for ; Wed, 30 Apr 2003 15:48:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 31A5F5DF3B; Wed, 30 Apr 2003 15:48:33 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id D00815DF34 for ; Wed, 30 Apr 2003 15:48:32 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id DDB7A5988D; Wed, 30 Apr 2003 20:48:35 +0100 (BST) Message-ID: <001701c30f51$7686a8d0$131010ac@aldebaran> From: "Philip Nye" To: "Joshua Graessley" , References: Subject: Re: WG Action - Accept [LL29] Link-local sources should specify TTL=1 Date: Wed, 30 Apr 2003 20:48:23 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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 Can anyone here say whether the Apple implementations which set/check TTL=255 do so for multicast in exactly the same way as for unicast? Philip ----- Original Message ----- From: "Joshua Graessley" To: Sent: Wednesday, April 30, 2003 6:11 PM Subject: Re: WG Action - Accept [LL29] Link-local sources should specify TTL=1 > > On Wednesday, Apr 30, 2003, at 09:04 US/Pacific, Christian Huitema > wrote: > > >> Set TTL 255 and not check doesn't break anything. > >> Set TTL 255 and check breaks some implementations, though we've never > >> received a report of problems. > >> Set TTL 1 breaks some implementations. > >> > >> If you're really serious about not breaking any implementations, it > >> seems the right thing to do is set the TTL to 255. If you don't care > >> about compatibility, then why is setting the TTL to 1 an better than > >> 255? > > > > It is very clear that any mandate is going to break something. The > > question is very much what the default should be. I believe that using > > a > > TTL 1 makes sense in a lot of cases. It is the right thing to do when > > sending UDP multicast. With TCP, the combination of TTL=1 and the three > > ways handshake gives you a pretty airtight solution. So it is pretty > > clear that if a system wanted to choose TTL=1 by default, they should > > be > > authorized to do so. > > I'm not sure I follow. How does requiring the TTL be set to 255 and not > requiring any check break anything? > > The only implementations doing any checking are checking for TTL 255. > If you set the TTL to 255, you will work with those implementations. If > you check for TTL 255, you will fail to interoperate with > implementations that don't set the TTL to 255. If you set the TTL to > anything other than 255, you fail to interoperate with implementations > that perform the TTL 255 check. > > -josh > >