From owner-zeroconf@merit.edu Fri Dec 5 10:43: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 KAA10261 for ; Fri, 5 Dec 2003 10:43:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 24F80912CA; Fri, 5 Dec 2003 10:43:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8860912CB; Fri, 5 Dec 2003 10:43: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 E7723912CA for ; Fri, 5 Dec 2003 10:43:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id D2ABD5DE37; Fri, 5 Dec 2003 10:43:35 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 7FE325DE2E for ; Fri, 5 Dec 2003 10:43:35 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hB5FhOUP005556; Fri, 5 Dec 2003 07:43:25 -0800 (PST) Received: from sun.com (vpn-129-156-96-122.EMEA.Sun.COM [129.156.96.122]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hB5FhKm05884; Fri, 5 Dec 2003 16:43:21 +0100 (MET) Message-ID: <3FD0A6C3.1070502@sun.com> Date: Fri, 05 Dec 2003 16:39:47 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Cc: Ted Lemon , Ralph Droms , Thomas Narten Subject: zeroconf wg status report Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I regret that I have been very busy for the past couple months. Let's work determinedly to wrap up the remaining issues facing the ZEROCONF WG and conclude it. The status is: - There has been informal agreement to remove the requirements document from our charter. Action: I will seek formal (consensus) agreement on this point now. - All IPv4LL issues had been closed and the document went to Thomas Narten for review. He returned a list of comments to me on Nov 4. Action: His issues are included below. - Discussion was raised on the DHC WG mailing list. This resulted in an additional set of comments (from Ralph Droms and Ted Lemon). Action: Their issues are included below. - There was discussion of adding a 'state machine' diagram. While this was useful on the mailing list, new material will not be suggested for the IPv4LL specification. Action: None. - One issue (LL34) achieved an extremely rough consensus, for which there was much ensuing discussion. The change suggested by LL34 is already in draft-ietf-zeroconf-ipv4-linklocal-10.txt Action: While we will consider this issue 'approved', a summary of the issues presented in LL34 thread and the suggested changes will be presented in a separate email. We must come to closure on these issues. I will be sending the following issues which arose during the last round of discussion, ending mid October. Submitter Issue ------------- ------------------------------------------ Ralph Droms LL35 Improve abstract Ralph Droms LL36 Combine and rework section 1.7 and 2.11 to be clearer **needs text**! Thomas Narten LL37 Aggressive time-outs and total delay range confusion Thomas Narten LL38 Remove vestigial link-local only device text Thomas Narten LL39 Remove multiple interface discussion from probe details Ted Lemon LL40 IPv4 LL does not alter the behavior of the DHCPv4 state machine Best regards, Erik From owner-zeroconf@merit.edu Fri Dec 5 10:44: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 KAA10278 for ; Fri, 5 Dec 2003 10:43:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 896A2912CC; Fri, 5 Dec 2003 10:43:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58AFE912CB; Fri, 5 Dec 2003 10:43:40 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D38E4912CC for ; Fri, 5 Dec 2003 10:43:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id B869E5DE01; Fri, 5 Dec 2003 10:43:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 753AC5DDCF for ; Fri, 5 Dec 2003 10:43:38 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hB5FhaPh001208; Fri, 5 Dec 2003 08:43:36 -0700 (MST) Received: from sun.com (vpn-129-156-96-122.EMEA.Sun.COM [129.156.96.122]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hB5FhWm05897; Fri, 5 Dec 2003 16:43:33 +0100 (MET) Message-ID: <3FD0A6D0.8050309@sun.com> Date: Fri, 05 Dec 2003 16:40:00 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu, Thomas Narten Subject: new issue: [LL37] Aggressive time-outs and total delay range confusion Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Description of Issue Aggressive time-outs and total delay range confusion Submitter Name Thomas Narten Submitter Email Address narten@raleigh.ibm.com Date first submitted 4 Nov 03 Reference http://www.drizzle.com/~aboba/ZEROCONF/ll12.html http://www.drizzle.com/~aboba/ZEROCONF/ll20.html http://www.drizzle.com/~aboba/ZEROCONF/ll31.html Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section Rationale/Explanation of issue: Discussion of the 'aggressive time outs' and total delay range Lengthy description of problem: 1) The time values specified above are intended for use on technologies > such as IEEE 802, 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. Is the time above right? I count 3 transmission, waiting 1-2 seconds before starting and two after the last probe, resulting in 5-8 seconds only. Is there another delay added somewhere? Erik: 2.2.1 says When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range PROBE_MIN to PROBE_MAX seconds, and should then send three probe packets, spaced randomly, PROBE_MIN to PROBE_MAX seconds apart. ... If, by PROBE_MAX seconds after the transmission of the last ARP probe no conflicting ARP Reply or ARP probe has been received, then the host has successfully claimed the desired Link-Local IPv4 address. This is an equivalent to 4*PROBE_MIN + PROBE_MAX minimum to 4*PROBE_MAX + PROBE_MAX maximum, or 6-10 seconds, right? ================= 2) But more to the point, where did this IEEE 802 Spanning Tree motivation come in? Is this even true? Seems like an awful long delay. When I asked Bernard about this, he didn't seem to think this was the way LANs actually worked. Erik: The motivation for the 1-2 second delay at each step comes from section 1.3: This specification applies to all IEEE 802 Local Area Networks (LANs) [802], including Ethernet [802.3], Token-Ring [802.5] and IEEE 802.11 wireless LANs [802.11], as well as to other link-layer technologies that operate at data rates of at least 1 Mbps, !!! have a round-trip latency of at most one second, and support ARP [RFC826]. Wherever this document uses the term "IEEE 802", the text applies equally to any of these network technologies. Note the 'round-trip latency of at most one second' requirement. If this is the case - a timeout of less than one second on any of the timers does not make sense. Is this a valid timing assumption. Should section 1.3 be revised? Christian Huitema argues the timers should be much shorter in http://www.drizzle.com/~aboba/ZEROCONF/ll31.html How should we revise section 1.3 to accomodate such a change? ================== 3) > a chosen IP address may be used. For a desktop machine on an IEEE > 802 LAN, this 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 IPv4 address may be > used. The above text seems pretty silly. What network technologies would this be? And since this document isn't immediately applicable to other technologies (per earlier text), this document probably shouldn't be saying random implementations can choose _MUCH_ lower timer values here. Can someone refresh my thinking on why the subsecond recommendations above shouldn't be the ones we use in all cases this document applies to? Replacement text: I will provide some, if we can agree on what the right general timers should be. Erik: An additional argument against this text which has been brought up several times is that a bridge may exist between different L2 links. Even though one L2 technology would allow shorter delays, some will not. The algorithm cannot be so aggressive that it will fail to account for address conflicts on slower media. Requested Change: 1) section 2.3, from time values specified above result in a delay of 8-10 seconds before to time values specified above result in a delay of 6-10 seconds before ============= 2) no change, unless section 1.3 is to be revised. ============= 3) proposal: since we can't agree on the text and have been over this four times in less than a year, let's replace this paragraph with: Network technologies may emerge for which shorter delays are appropriate than those required by this document. A subsequent IETF publication may be produced providing guidelines for different timer settings for PROBE_MIN and PROBE_MAX on those technologies. From owner-zeroconf@merit.edu Fri Dec 5 10:44:31 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 KAA10312 for ; Fri, 5 Dec 2003 10:44:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C6B74912CE; Fri, 5 Dec 2003 10:43:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A7D2912CB; Fri, 5 Dec 2003 10:43:43 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 62544912CE for ; Fri, 5 Dec 2003 10:43:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A0AC5DE3A; Fri, 5 Dec 2003 10:43:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 07C585DDCF for ; Fri, 5 Dec 2003 10:43:41 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hB5FhVUP005613; Fri, 5 Dec 2003 07:43:32 -0800 (PST) Received: from sun.com (vpn-129-156-96-122.EMEA.Sun.COM [129.156.96.122]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hB5FhMm05887; Fri, 5 Dec 2003 16:43:23 +0100 (MET) Message-ID: <3FD0A6C6.4080004@sun.com> Date: Fri, 05 Dec 2003 16:39:50 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu, Ralph Droms Subject: new issue: [LL35] Improve abstract Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit We need to evaluate whether to make this change. =========================================================================== Description of Issue Improve abstract Submitter Name Ralph Droms Submitter Email Address rdroms@cisco.com Date first submitted 20.10.03 Reference Comment Type ['T'echnical | 'E'ditorial] E Priority ['S' Must fix | '1' Should fix | '2' May fix ] 1 Section Abstract Rationale/Explanation of issue: While technically the Abstract is correct, I found the initial reference to "configuration" confusing relative to the address assignment provided by v4LL. I suggest editing the Abstract. Lengthy description of problem: Requested Change: http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-ipv4-linklocal-10.txt To participate in wide-area IP networking, a host needs to be configured, either manually by the user or automatically from a source on the network such as a DHCP server. Unfortunately, such external configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link. becomes To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a DHCP server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link. From owner-zeroconf@merit.edu Fri Dec 5 10:44:41 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 KAA10329 for ; Fri, 5 Dec 2003 10:44:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD757912D0; Fri, 5 Dec 2003 10:43:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8CE1912CB; Fri, 5 Dec 2003 10:43:46 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E11E3912D0 for ; Fri, 5 Dec 2003 10:43:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id BE5F75DDCF; Fri, 5 Dec 2003 10:43:43 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 4C86F5DDA2 for ; Fri, 5 Dec 2003 10:43:43 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hB5FhexA011799; Fri, 5 Dec 2003 07:43:41 -0800 (PST) Received: from sun.com (vpn-129-156-96-122.EMEA.Sun.COM [129.156.96.122]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hB5Fhcm05906; Fri, 5 Dec 2003 16:43:39 +0100 (MET) Message-ID: <3FD0A6D6.9040300@sun.com> Date: Fri, 05 Dec 2003 16:40:06 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu, Thomas Narten Subject: new issue: [LL38] Remove vestigial link-local only device text Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit We need to evaluate whether to make this change. =========================================================================== Description of Issue Remove vestigial link-local only device text Submitter Name Thomas Narten Submitter Email Address narten@us.ibm.com Date first submitted 04 Nov 03 Reference Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section 2.8 Rationale/Explanation of issue: Lengthy description of problem: Section 2.8 includes some wording that I suspect is a vestige of earlier text. E.g.: > The non-forwarding rule is important because it is expected that > Link-Local-only devices will often be simple devices of the kind that > currently use X10 [X10], USB [USB] or FireWire [1394]. The non-forwarding reason is justified for lots of reasons, and has little to do with LL-only devices. Second, there is text that talks about LL-only devices, and how it is important for them that LL traffic not be forwarded off-link. That text is also suspect, because this document is not really about supporting LL-only devices. The issue applies to any application jusing LL addresses. Also if someone wants to build a LL-only device, that is their issue, but this document doesn't need to explicitely mention that case. Thus, text about LL only devices should just be removed. Third, there is text that suggests simultaneous use of LL and global addressing (i.e., pick global if one wants to talk beyond the router, use LL to restrict communication). This text is also inconsistent with the recommendation to use LL only when another address is not available. I actually went about trying to come up with replacement text, but concluded that all of the existing text in 2.8 (except for the first paragraph) should just be deleted instead. Requested Change: Delete all of the existing text in 2.8 (except for the first paragraph). From owner-zeroconf@merit.edu Fri Dec 5 10:44:44 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10344 for ; Fri, 5 Dec 2003 10:44:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 50800912CB; Fri, 5 Dec 2003 10:43:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E8F7912D2; Fri, 5 Dec 2003 10:43:57 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74BB9912CB for ; Fri, 5 Dec 2003 10:43:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 629045DDFB; Fri, 5 Dec 2003 10:43:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id E2E9A5DDCF for ; Fri, 5 Dec 2003 10:43:51 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hB5FhmPh001310; Fri, 5 Dec 2003 08:43:49 -0700 (MST) Received: from sun.com (vpn-129-156-96-122.EMEA.Sun.COM [129.156.96.122]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hB5Fhkm05914; Fri, 5 Dec 2003 16:43:46 +0100 (MET) Message-ID: <3FD0A6DC.8010505@sun.com> Date: Fri, 05 Dec 2003 16:40:12 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu, Ted Lemon Subject: new issue: [LL40] IPv4 LL does not alter the behavior of the DHCPv4 state machine Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit We need to evaluate whether to make this change. =========================================================================== Description of Issue IPv4 LL does not alter the behavior of the DHCPv4 state machine Submitter Name Ted Lemon Submitter Email Address mellon@fugue.com Date first submitted 24 Oct 03 Reference Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] 1 Section 2.12 (new section) Rationale/Explanation of issue: Lengthy description of problem: So I think the right answer to this question is to simply decouple the IPv4LL and DHCP state machines. As long as the IPV4ll state machine can reach out and touch the DHCP state machine, it's likely to do things that break the operation of the DHCP state machine. So the right answer is, IMHO, that if the IPv4LL believes that it *may* be in a state where connectivity has been lost, it should configure itself a link-local address, and when it leaves that state, it should make the transition back to using the globally routable address exclusively. In other words, the IPv4LL state machine should watch the DHCP state machine and make decisions at least in part based on what state the DHCP client is in, but the DHCP client should not change its behavior at all to accomodate this. So if the DHCP client is in the INIT-REBOOT state and doesn't get an answer from the DHCP server, it should continue using its globally routable address. But the IPv4LL agent should make note of this, and configure an IPv4LL address. Requested Change: Add section this new section: ! 2.12 Interaction between DHCPv4 client and IPv4ll state machines ! ! A device that implements both IPv4ll and a DHCPv4 client should not ! alter the behavior of the DHCPv4 client to accommodate IPv4 ! Link-Local configuration. Some early implementations of IPv4 ! Link-Local that were tightly coupled to the DHCP client chose to ! abandon routable IPv4 addresses acquired using DHCP, in favor of ! IPv4 Link-Local addresses, in cases where the DHCP server could not ! be contacted, and to stop the DHCP client from attempting to ! acquire a new IP address for much longer than the maximum time of ! 60 seconds specified in Dynamic Host Configuration Protocol ! [RFC2131]. The maximum time specified in RFC2131 should be ! observed even in cases where IPv4 link-local presents an ! alternative to DHCP. ! ! Similarly, in some cases where IPv4 Link-Local implementations are ! tightly coupled to the DHCP client, the DHCP client detects changes ! in connectivity and immediately triggers an INIT-REBOOT cycle in ! the client. If the DHCP client is not immediately able to contact ! the DHCP server, it abandons the address acquired through DHCP, ! which triggers a switch to IPv4 Link-Local. This behavior is ! allowed by RFC2131, but it has problems. Users of devices that ! are moving from one location to another and experience temporary ! loss of connectivity can lose all active TCP connections, even ! though the time they spent out of reach of the DHCP server was far ! less than the timeout on a TCP connection. We therefore ! recommend that implementors of IPv4 Link-Local avoid this ! strategy. ! ! Further discussion of this issue is provided in [DNAv4]. From owner-zeroconf@merit.edu Fri Dec 5 10:44:51 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 KAA10359 for ; Fri, 5 Dec 2003 10:44:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 43779912D1; Fri, 5 Dec 2003 10:43:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00C63912D2; Fri, 5 Dec 2003 10:43:52 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2C7D0912D1 for ; Fri, 5 Dec 2003 10:43:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id ED9C05DE3A; Fri, 5 Dec 2003 10:43:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id A73205DDFB for ; Fri, 5 Dec 2003 10:43:47 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hB5FhjPh001281; Fri, 5 Dec 2003 08:43:46 -0700 (MST) Received: from sun.com (vpn-129-156-96-122.EMEA.Sun.COM [129.156.96.122]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hB5Fhgm05910; Fri, 5 Dec 2003 16:43:42 +0100 (MET) Message-ID: <3FD0A6D9.8000001@sun.com> Date: Fri, 05 Dec 2003 16:40:09 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu, Thomas Narten Subject: new issue: [LL39] Remove multiple interface discussion from probe details Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable We need to evaluate whether to make this change. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Description of Issue Remove multiple interface discussion from probe=20 details Submitter Name Thomas Narten Submitter Email Address narten@us.ibm.com Date first submitted 04 Nov 03 Reference Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section 2.2.1 Rationale/Explanation of issue: Lengthy description of problem: 1) > If during this period, from the beginning of the probing process > until PROBE_MAX seconds after the last probe packet is sent, the host > receives any ARP packet (Request *or* Reply) where the packet's including ARP packets on other interfaces? ---------------- 2) > =C3=82=C2=B3sender IP address' is the address being probed for, then t= he host > MUST treat this address as being in use by some other host, and MUST > select a new pseudo-random address and repeat the process. In > addition, if during this period the host receives any ARP probe where > the packet's 'target IP address' is the address being probed for, and > the packet's 'sender hardware address' is not the hardware address of > any of the host's interfaces, then the host MUST similarly treat this > as an address collision and select a new address as above. This can > occur if two (or more) hosts attempt to configure the same Link-Local > IPv4 address at the same time. Can we remove the wording that talks about multiple interfaces? This document should really assume that the algorithm runs on a single interface, leaving all multi-homing issues to Section 3 (since we aren't being complete). The above is actually wrong, in some sense, because if an implementation is stupid enough to try and configure the same LL address on multiple interfaces that are attached to the same link, it will not detect the problem above, when it maybe should... Text later in the document suggests the same address on multiple interfaces should be treated as an error. (note: same wording appears later in document) ------------------------ 3) > Care must be taken if a multihomed host can support more than one > interface on the same link, all of which support Link-Local IPv4 > autoconfiguration. If these interfaces attempt to allocate the same > address, they will defend the host against itself - causing the > claiming algorithm to fail. The simplest solution to this problem is > to run the algorithm independently on each interface configured with > Link-Local IPv4 addresses. Not according to the algorithm, per above... Requested Change: 1) Change 2.2.1 text If during this period, from the beginning of the probing process until PROBE_MAX seconds after the last probe packet is sent, the host receives any ARP packet (Request *or* Reply) where the packet's 'sender IP address' is the address being probed for, then the host MUST treat this address as being in use by some other host, and MUST select a new pseudo-random address and repeat the process. to If during this period, from the beginning of the probing process until PROBE_MAX seconds after the last probe packet is sent, the host receives any ARP packet (Request *or* Reply) on the interface where the probe is being performed where the packet's 'sender IP address' is the address being probed for, then the host MUST treat this address as being in use by some other host, and MUST select a new pseudo-random address and repeat the process. ----------------------- 2) Change 2.2.1 text In addition, if during this period the host receives any ARP probe where the packet's 'target IP address' is the address being probed for, and the packet's 'sender hardware address' is not the hardware address of any of the host's interfaces, then the host MUST similarly treat this as an address collision and select a new address as above. This can occur if two (or more) hosts attempt to configure the same Link-Local IPv4 address at the same time. To: In addition, if during this period the host receives any ARP probe where the packet's 'target IP address' is the address being probed for, and the packet's 'sender hardware address' is not the hardware address of the interfaces the host is attempting to configure, then the host MUST similarly treat this as an address collision and select a new address as above. This can occur if two (or more) hosts attempt to configure the same Link-Local IPv4 address at the same time. And in section 2.5 From: At any time, if a host receives an ARP packet (request *or* reply) where the 'sender IP address' is the host's own IP address, but the 'sender hardware address' does not match any of the host's own interface addresses, then this is a conflicting ARP packet, indicating an address collision. To: At any time, if a host receives an ARP packet (request *or* reply) where the 'sender IP address' is the host's own IP address, but the 'sender hardware address' does not match the hardware address of the interface the host is attempting to configure= then this is a conflicting ARP packet, indicating an address collision. --------------------------- 3) This text is now OK. The text above (from 2.2.1 and 2.5) which require= d a host to compare received ARP messages *on any interface* with those of an interface being configured has been removed. From owner-zeroconf@merit.edu Fri Dec 5 10:47:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10409 for ; Fri, 5 Dec 2003 10:47:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1A9F4912CF; Fri, 5 Dec 2003 10:45:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA1E6912D4; Fri, 5 Dec 2003 10:45: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 E8BA8912CF for ; Fri, 5 Dec 2003 10:45:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id D27815DDAA; Fri, 5 Dec 2003 10:45:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 8872E5DD8C for ; Fri, 5 Dec 2003 10:45:52 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hB5FjoPh002501 for ; Fri, 5 Dec 2003 08:45:51 -0700 (MST) Received: from sun.com (vpn-129-156-96-122.EMEA.Sun.COM [129.156.96.122]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hB5Fjnm06490 for ; Fri, 5 Dec 2003 16:45:49 +0100 (MET) Message-ID: <3FD0A758.40107@sun.com> Date: Fri, 05 Dec 2003 16:42:16 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit We need to evaluate whether to make this change. NOTE: TEXT IS NEEDED, please contribute some. ----------------------------------------------------------------------- Description of Issue Combine and rework section 1.7 and 2.11 to be clearer Submitter Name Ralph Droms Submitter Email Address rdroms@cisco.com Date first submitted 15.10.03 Reference Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] 1 Section 1.7 Rationale/Explanation of issue: Seems to me the underlying issue is the interaction between v4LL and any "working routable address" (a routable address that can be used for off-link communication). That is, I don't think it matters where the routable address comes from - whether it be DHCP, manual configuration, or some other mechanism - rather, the issue is how to get the interface to a state in which it can use a v4LL address when no working routable address is available Lengthy description of problem: The way in which I would describe how a device uses v4LL would be to use the state of the interface itself as the basis for invoking v4LL. If an interface does not have a working routable address, the device invokes v4LL for that interface. When the interface does have a working routable address, v4LL is not used. The issue of when to use v4LL is indirectly addressed in section 1.7 and more directly in 2.11. I suggest combining 1.7 and 2.11 into a single section that: * states the conditions under which v4LL is used (paraphrasing what I wrote in the previous paragraph) - based on state of interface - defines "working routable address" - v4LL used when no working routable address is available * gives pointers to other documents, such as draft-ietf-dhc-dns-ipv4-01.txt, that define how to determine if an interface has a working routable address * points out the it is an implementation detail for the protocol software to monitor the state of the interface and invoke v4LL as appropriate * emphasizes that v4Ll has no effect on the use of other configuration mechanism Requested Change: From owner-zeroconf@merit.edu Fri Dec 5 12:03:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13832 for ; Fri, 5 Dec 2003 12:03:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4541A912DA; Fri, 5 Dec 2003 12:02:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 108D4912DF; Fri, 5 Dec 2003 12:02:31 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 13031912DA for ; Fri, 5 Dec 2003 12:02:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0249B5DDCE; Fri, 5 Dec 2003 12:02:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 87DFD5DD9E for ; Fri, 5 Dec 2003 12:02:30 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id hB5H2TDX012181 for ; Fri, 5 Dec 2003 12:02:29 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id hB5H2TGh014336 for ; Fri, 5 Dec 2003 12:02:29 -0500 (EST) Received: from [172.16.245.21] ([216.87.40.137]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id hB5H2SRj006487 for ; Fri, 5 Dec 2003 12:02:28 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 05 Dec 2003 11:02:27 -0600 Subject: Re: new issue: [LL35] Improve abstract From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <3FD0A6C6.4080004@sun.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/5/03 9:39 AM, "Erik Guttman" wrote: > We need to evaluate whether to make this change. I would say yes...it's clearer as to the specific configuration that is happening, and clarity is always good. john -- "Keecking butt fahr gudness" Baldur's Gate From owner-zeroconf@merit.edu Fri Dec 5 12:04:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13872 for ; Fri, 5 Dec 2003 12:04:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E1811912DC; Fri, 5 Dec 2003 12:04:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3B86912E1; Fri, 5 Dec 2003 12:03:59 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B980F912DC for ; Fri, 5 Dec 2003 12:03:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id A2E915DE01; Fri, 5 Dec 2003 12:03:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 52E175DDEF for ; Fri, 5 Dec 2003 12:03:54 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hB5H3qxA022333; Fri, 5 Dec 2003 09:03:52 -0800 (PST) Received: from sun.com (vpn-129-159-0-253.EMEA.Sun.COM [129.159.0.253]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hB5H3nm11102; Fri, 5 Dec 2003 18:03:50 +0100 (MET) Message-ID: <3FD0B9A0.7040701@sun.com> Date: Fri, 05 Dec 2003 18:00:16 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Cc: Thomas Narten , Margaret.Wasserman@nokia.com Subject: proposed new ZEROCONF charter Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please send comments on this proposed new charter for the ZEROCONF WG. The current charter is listed at http://www.ietf.org/html.charters/zeroconf-charter.html Change bars show where text has changed. Description of Working Group: The goal of the Zero Configuration Networking (ZEROCONF) Working Group is to enable networking in the absence of configuration and administration. Zero configuration networking is required for environments where administration is impractical or impossible, such as in the home or small office, embedded systems 'plugged together' as in an automobile, or to allow impromptu networks as between the devices of strangers on a train. | ZEROCONF will make networking as easy as possible, but no easier. In some cases other considerations may dominate ease of use. For example, network security requires some configuration which may not be as easy as the unacceptable alternative of 'no security.' | [text omitted] | The working group originally was orginally chartered to | develop a requirements specification for host and application | operation in environments lacking configuration. The areas | for consideration included: * Interface Configuration (IP address, network prefix, gateway router) * Name-to-Address Translation * Service Discovery * Automatic allocation of Multicast Addresses * Sufficient security features to prevent networks from being any less secure than networks which do not use ZEROCONF protocols | The ZEROCONF WG could not come to a consensus regarding these | requirements. A ZEROCONF requirements document will not be | published by this working group. | This WG will produce one protocol specification, describing | automatic generation and assignment of link-local IPv4 addresses | in environments lacking host configuration (static or using DHCP). | The document will describe existing practice as well as define | recommendations for future implementations. Goals and Milestones: Done Submit internet-draft to be considered as an Informational RFC on Requirements for Zero Configuration Networking. Done Submit Automatic Address Configuration for IPv4 to be considered as a Standards Track RFC. | Jan 03 Submit Revised Automatic Address Configuration for IPv4 draft | which has passed WG last call to the IESG for consideration as | a Standards Track RFC. From owner-zeroconf@merit.edu Fri Dec 5 12:16:48 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14245 for ; Fri, 5 Dec 2003 12:16:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7CB98912DE; Fri, 5 Dec 2003 12:15:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3FFC7912E0; Fri, 5 Dec 2003 12:15:51 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 30202912DE for ; Fri, 5 Dec 2003 12:15:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1B4925DD9E; Fri, 5 Dec 2003 12:15:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id A0AE35DD98 for ; Fri, 5 Dec 2003 12:15:49 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id hB5HFmDX022724 for ; Fri, 5 Dec 2003 12:15:48 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id hB5HFlBh011713 for ; Fri, 5 Dec 2003 12:15:47 -0500 (EST) Received: from [172.16.245.21] ([65.170.48.201]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id hB5HFjRj011117 for ; Fri, 5 Dec 2003 12:15:46 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 05 Dec 2003 11:15:44 -0600 Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <3FD0A758.40107@sun.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/5/03 9:42 AM, "Erik Guttman" wrote: > The way in which I would describe how a device uses v4LL would be to use > the state of the interface itself as the basis for invoking v4LL. If an > interface does not have a working routable address, the device invokes > v4LL for that interface. When the interface does have a working routable > address, v4LL is not used. Clarify this line please: " When the interface does have a working routable address, v4LL is not used." Does "not used" mean effectively "turned off", as in there is no v4LL address whatsoever, or does "not used" mean, "Not using a separate 169.254/16 address, and just using the working routable address"? If it means the former, I'd say that's bad. If it means the latter, I'd say that's good. In that case, I'd also suggest changing that line to read: " When the interface does have a working routable address, a separate v4LL address is not configured, and the working routable address is mapped over as the v4LL address." This is a change from my (much) earlier stance, but having used this methodology for quite some time now, it is convenient, easy to understand regardless of knowledge level, easy to explain regardless of the knowledge level of the person you explain it to, (training and education are huge parts of my career, so being able to easily and correctly explain something matters), and it works well in the "real" world, (however you chose to define it). john -- "It is not the critic who counts, not the one who points out how the strong man stumbled or how the doer of deeds might have done them better. The credit belongs to the man who is actually in the arena, whose face is marred with sweat and dust and blood; who strives valiantly; who errs and comes short again and again; who knows the great enthusiasms, the great devotions, and spends himself in a worthy cause; who, if he wins, knows the triumph of high achievement; and who, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who know neither victory nor defeat." - Theodore Roosevelt From owner-zeroconf@merit.edu Fri Dec 5 12:54: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 MAA16201 for ; Fri, 5 Dec 2003 12:54:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 76FD091383; Fri, 5 Dec 2003 12:53:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5820291395; Fri, 5 Dec 2003 12:53: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 B59A29135F for ; Fri, 5 Dec 2003 12:44:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9F1665DE01; Fri, 5 Dec 2003 12:44:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by segue.merit.edu (Postfix) with ESMTP id 48BB65DE11 for ; Fri, 5 Dec 2003 12:44:52 -0500 (EST) Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB5Himxg029075; Fri, 5 Dec 2003 12:44:49 -0500 (EST) Received: from rdroms-w2k01.cisco.com ([161.44.65.206]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEL48470; Fri, 5 Dec 2003 12:44:47 -0500 (EST) Message-Id: <4.3.2.7.2.20031205123853.00b66908@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 05 Dec 2003 12:44:45 -0500 To: "John C. Welch" From: Ralph Droms Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer Cc: Zeroconf In-Reply-To: References: <3FD0A758.40107@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Comments in line... At 11:15 AM 12/5/2003 -0600, John C. Welch wrote: >On 12/5/03 9:42 AM, "Erik Guttman" wrote: > > > The way in which I would describe how a device uses v4LL would be to use > > the state of the interface itself as the basis for invoking v4LL. If an > > interface does not have a working routable address, the device invokes > > v4LL for that interface. When the interface does have a working routable > > address, v4LL is not used. > >Clarify this line please: " When the interface does have a working routable >address, v4LL is not used." > >Does "not used" mean effectively "turned off", as in there is no v4LL >address whatsoever, or does "not used" mean, "Not using a separate >169.254/16 address, and just using the working routable address"? I mean that the interface has a routable address, and the v4LL mechanisms are not invoked to assign a 169.254/16 address to the interface. I don't understand the difference between the two alternatives you've presented. I also don't understand, from below, "and the working routable address is mapped over as the v4LL address". - Ralph >If it means the former, I'd say that's bad. If it means the latter, I'd say >that's good. In that case, I'd also suggest changing that line to read: > >" When the interface does have a working routable address, a separate v4LL >address is not configured, and the working routable address is mapped over >as the v4LL address." > >This is a change from my (much) earlier stance, but having used this >methodology for quite some time now, it is convenient, easy to understand >regardless of knowledge level, easy to explain regardless of the knowledge >level of the person you explain it to, (training and education are huge >parts of my career, so being able to easily and correctly explain something >matters), and it works well in the "real" world, (however you chose to >define it). > >john > >-- >"It is not the critic who counts, not the one who points out how the strong >man stumbled or how the doer of deeds might have done them better. The >credit belongs to the man who is actually in the arena, whose face is marred >with sweat and dust and blood; who strives valiantly; who errs and comes >short again and again; who knows the great enthusiasms, the great devotions, >and spends himself in a worthy cause; who, if he wins, knows the triumph of >high achievement; and who, if he fails, at least fails while daring greatly, >so that his place shall never be with those cold and timid souls who know >neither victory nor defeat." >- Theodore Roosevelt From owner-zeroconf@merit.edu Fri Dec 5 16:06: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 QAA26748 for ; Fri, 5 Dec 2003 16:06:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 10D5D912DE; Fri, 5 Dec 2003 16:06:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC445912E2; Fri, 5 Dec 2003 16:06: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 E715D912DE for ; Fri, 5 Dec 2003 16:06:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id D331E5DDC4; Fri, 5 Dec 2003 16:06:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fuchsia.noi.kre.to (unknown [192.150.250.67]) by segue.merit.edu (Postfix) with ESMTP id 4FCFE5DE01 for ; Fri, 5 Dec 2003 16:06:12 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.noi.kre.to with ESMTP id hB5L5B0H003464; Sat, 6 Dec 2003 04:05:18 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id hB5KwNt26188; Sat, 6 Dec 2003 03:58:31 +0700 (ICT) From: Robert Elz To: "John C. Welch" Cc: Zeroconf Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 06 Dec 2003 03:58:23 +0700 Message-ID: <9266.1070657903@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 05 Dec 2003 11:15:44 -0600 From: "John C. Welch" Message-ID: | Clarify this line please: " When the interface does have a working routable | address, v4LL is not used." | | Does "not used" mean effectively "turned off", as in there is no v4LL | address whatsoever, or does "not used" mean, "Not using a separate | 169.254/16 address, and just using the working routable address"? What distinction are you trying to get at there? I can't understand that at all. If there is no 169.254/16 address, there is no v4LL address, surely??? | If it means the former, I'd say that's bad. If it means the latter, I'd say | that's good. In that case, I'd also suggest changing that line to read: | | " When the interface does have a working routable address, a separate v4LL | address is not configured, and the working routable address is mapped over | as the v4LL address." That is totally incomprehensible to me, what does "mapped over as" mean ? kre From owner-zeroconf@merit.edu Fri Dec 5 16:15:25 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26916 for ; Fri, 5 Dec 2003 16:15:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A1FB0912E2; Fri, 5 Dec 2003 16:15:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E7CA912E3; Fri, 5 Dec 2003 16:15:10 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1DD69912E2 for ; Fri, 5 Dec 2003 16:15:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0B9045DE51; Fri, 5 Dec 2003 16:15:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 977515DE4B for ; Fri, 5 Dec 2003 16:15:05 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id hB5LF4e2023664 for ; Fri, 5 Dec 2003 16:15:04 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id hB5LF36w009348 for ; Fri, 5 Dec 2003 16:15:03 -0500 (EST) Received: from [172.16.245.21] ([65.170.48.201]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id hB5LF1Rj003217 for ; Fri, 5 Dec 2003 16:15:02 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 05 Dec 2003 15:14:59 -0600 Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <4.3.2.7.2.20031205123853.00b66908@flask.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/5/03 11:44 AM, "Ralph Droms" wrote: >> Does "not used" mean effectively "turned off", as in there is no v4LL >> address whatsoever, or does "not used" mean, "Not using a separate >> 169.254/16 address, and just using the working routable address"? > > I mean that the interface has a routable address, and the v4LL mechanisms > are not invoked to assign a 169.254/16 address to the interface. > > I don't understand the difference between the two alternatives you've > presented. I also don't understand, from below, "and the working routable > address is mapped over as the v4LL address". For example...I have a manually assigned IPv4 address: 172.16.245.21 If I ping my Unicast DNS name, I get that address. If I ping my Zeroconf/Rendezvous name, "aurora.local" that address is what is used for the ping as well. john -- "Kill one, terrify a thousand." - Sun Tzu From owner-zeroconf@merit.edu Fri Dec 5 16:22: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 QAA27201 for ; Fri, 5 Dec 2003 16:22:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF5E6912F0; Fri, 5 Dec 2003 16:20:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A9F8912F5; Fri, 5 Dec 2003 16:20: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 4DD11912F0 for ; Fri, 5 Dec 2003 16:20:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 30CC55DDDE; Fri, 5 Dec 2003 16:20:21 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id B61695DDCE for ; Fri, 5 Dec 2003 16:20:20 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id hB5LKJe2028090 for ; Fri, 5 Dec 2003 16:20:19 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id hB5LKJ6w010018 for ; Fri, 5 Dec 2003 16:20:19 -0500 (EST) Received: from [172.16.245.21] ([65.170.48.201]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id hB5LKHRj005221 for ; Fri, 5 Dec 2003 16:20:18 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 05 Dec 2003 15:20:15 -0600 Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <9266.1070657903@munnari.OZ.AU> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/5/03 2:58 PM, "Robert Elz" wrote: > | Clarify this line please: " When the interface does have a working > routable > | address, v4LL is not used." > | > | Does "not used" mean effectively "turned off", as in there is no v4LL > | address whatsoever, or does "not used" mean, "Not using a separate > | 169.254/16 address, and just using the working routable address"? > > What distinction are you trying to get at there? I can't understand > that at all. If there is no 169.254/16 address, there is no v4LL > address, surely??? Well, if I look at Apple's implementation, which is right now, the major one to look at, when an interface is configured, either manually, or via DHCP, then that address is what shows up when you use the zeroconf protocols to look at it. So if I use SSH to the zeroconf mDNS name, the non v4LL - configured address is used here. So it would appear that what is being done is that when an address is configured by a non-v4LL method, that address is used for all zeroconf-method communications. So it appears as though the system is simply saying, "okay, we have a 'proper' ip address, use that for all the other zeroconf stuff as well." > > | If it means the former, I'd say that's bad. If it means the latter, I'd > say > | that's good. In that case, I'd also suggest changing that line to read: > | > | " When the interface does have a working routable address, a separate v4LL > | address is not configured, and the working routable address is mapped over > | as the v4LL address." > > That is totally incomprehensible to me, what does "mapped over as" mean ? Working routable address is used as the v4LL address as well. john -- "I have not yet begun to fight." - John Paul Jones (aboard the Bon Homme Richard),Sept. 1779 From owner-zeroconf@merit.edu Sat Dec 6 05:59:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05375 for ; Sat, 6 Dec 2003 05:59:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9801691211; Sat, 6 Dec 2003 05:59:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BE6F91217; Sat, 6 Dec 2003 05:59:10 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8852791211 for ; Sat, 6 Dec 2003 05:59:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6C9D55DE5A; Sat, 6 Dec 2003 05:59:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fuchsia.noi.kre.to (unknown [192.150.250.67]) by segue.merit.edu (Postfix) with ESMTP id 474275DE3E for ; Sat, 6 Dec 2003 05:51:06 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.noi.kre.to with ESMTP id hB6AoD0H000927; Sat, 6 Dec 2003 17:50:18 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id hB6An3D15681; Sat, 6 Dec 2003 17:49:07 +0700 (ICT) From: Robert Elz To: "John C. Welch" Cc: Zeroconf Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 06 Dec 2003 17:49:03 +0700 Message-ID: <26099.1070707743@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 05 Dec 2003 15:20:15 -0600 From: "John C. Welch" Message-ID: | So it appears as though the system is simply saying, "okay, we have a | 'proper' ip address, use that for all the other zeroconf stuff as well." That's just fine, this is what we want to happen - but the final part of your sentence should be "use that for all the other stuff as well", zeroconf has nothing whatever to do with it. v4LL addresses are not something magic for zeroconf use - neither restricted to be used by protocols defined here, nor required to be used by protocols defined here - they're just a way of getting a limited use address when nothing else is available. Once obtained, they operate just like any other address, given their limitations (totally unroutable). | Working routable address is used as the v4LL address as well. No, a workable routable address cannot possibly be a v4LL address, by definition, a LL address is not routable. I suspect that you mean that you use a non-LL address in a secnario where you migt have been imagining a LL address would be used - that's nothing special, LL addresses have no magic extra properties (aside from being able to be created by a node on its own) - once they exist, they do absolutely nothing that any other address can't do equally as well (they are just more restricted in with what they can communicate, because they can't be routed). It is always possible to use a wider scope address (1918, or global) instead of a LL address in the v4 world (not so in v6, where some usages require the use of LL addresses). kre From owner-zeroconf@merit.edu Sat Dec 6 23:14: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 XAA00470 for ; Sat, 6 Dec 2003 23:14:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B8FC591207; Sat, 6 Dec 2003 23:14:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8CF0D91220; Sat, 6 Dec 2003 23: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 8EEA891207 for ; Sat, 6 Dec 2003 23:14:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7AB6D5DEAB; Sat, 6 Dec 2003 23:14:43 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 098245DEA8 for ; Sat, 6 Dec 2003 23:14:43 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id hB74EgXE007551 for ; Sat, 6 Dec 2003 23:14:42 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id hB74EfCt002014 for ; Sat, 6 Dec 2003 23:14:41 -0500 (EST) Received: from [10.0.0.50] (CPE-24-163-147-32.kc.rr.com [24.163.147.32]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id hB74EeRj013589 for ; Sat, 6 Dec 2003 23:14:40 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Sat, 06 Dec 2003 22:14:37 -0600 Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <26099.1070707743@munnari.OZ.AU> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/6/03 4:49 AM, "Robert Elz" wrote: > No, a workable routable address cannot possibly be a v4LL address, > by definition, a LL address is not routable. > > I suspect that you mean that you use a non-LL address in a secnario where > you migt have been imagining a LL address would be used - that's nothing > special, LL addresses have no magic extra properties (aside from being > able to be created by a node on its own) - once they exist, they do absolutely > nothing that any other address can't do equally as well (they are just > more restricted in with what they can communicate, because they can't be > routed). ...yes robert I know that a LL address isn't magic. I was simply saying that I like how Apple does things. It's convenient, it's handy, and it makes more sense to me than either shutting the usage of Zeroconf protocols entirely once a non v4LL address was configured, or configuring a separate address for v4LL. The statement I was referring to was unclear as to what it mean, and I really only wanted clarification of it. That's all. Really. john -- "The truth shall set you free." U.S. Central Intelligence Agency Motto From owner-zeroconf@merit.edu Sun Dec 7 20:25: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 UAA09596 for ; Sun, 7 Dec 2003 20:25:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 721C291225; Sun, 7 Dec 2003 20:25:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4201891226; Sun, 7 Dec 2003 20:25:10 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4E21691225 for ; Sun, 7 Dec 2003 20:25:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3695F5DEE7; Sun, 7 Dec 2003 20:25:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from motgate7.mot.com (motgate7.mot.com [129.188.136.7]) by segue.merit.edu (Postfix) with ESMTP id 001E75DEE5 for ; Sun, 7 Dec 2003 20:25:08 -0500 (EST) Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id hB81Nb2F011769; Sun, 7 Dec 2003 18:23:37 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id hB81Nb1u001198; Sun, 7 Dec 2003 19:23:42 -0600 Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.10/8.12.10) with ESMTP id hB81OsoF008815; Mon, 8 Dec 2003 12:24:55 +1100 (EST) Message-ID: <3FD3D2E5.2020109@motorola.com> Date: Mon, 08 Dec 2003 12:24:53 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Guttman Cc: zeroconf@merit.edu, Ted Lemon , Ralph Droms , Thomas Narten Subject: Re: zeroconf wg status report References: <3FD0A6C3.1070502@sun.com> In-Reply-To: <3FD0A6C3.1070502@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Erik Guttman wrote: > - There has been informal agreement to remove the requirements > document from our charter. > > Action: I will seek formal (consensus) agreement on this point now. OK by me. There seems little chance of moving it to completion. - aidan From owner-zeroconf@merit.edu Mon Dec 15 08:12:35 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07155 for ; Mon, 15 Dec 2003 08:12:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1522991225; Mon, 15 Dec 2003 08:12:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D71C791226; Mon, 15 Dec 2003 08:12: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 0573D91225 for ; Mon, 15 Dec 2003 08:12:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id E8FAD5DE1B; Mon, 15 Dec 2003 08:12:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 6796C5DE15 for ; Mon, 15 Dec 2003 08:12:24 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hBFDCL0H021106; Mon, 15 Dec 2003 05:12:22 -0800 (PST) Received: from sun.com (vpn-129-156-96-197.EMEA.Sun.COM [129.156.96.197]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hBFDCIm22017; Mon, 15 Dec 2003 14:12:19 +0100 (MET) Message-ID: <3FDDB240.2090404@sun.com> Date: Mon, 15 Dec 2003 14:08:16 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Cc: Thomas Narten , Margaret.Wasserman@nokia.com Subject: WG ACTION: 1 week to discuss "Proposed New Charter" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please send your comments to the working group mailing list. Unless there is an objection due to lack of time to work on this before the holidays, the discussion will conclude on December 23. Please see: http://www.merit.edu/mail.archives/zeroconf/msg00008.html Regards, Erik From owner-zeroconf@merit.edu Mon Dec 15 08:12: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 IAA07177 for ; Mon, 15 Dec 2003 08:12:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BE34591229; Mon, 15 Dec 2003 08:12:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F86391228; Mon, 15 Dec 2003 08:12: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 776F991226 for ; Mon, 15 Dec 2003 08:12:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id E21175DE1C; Mon, 15 Dec 2003 08:12:31 -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 748E45DE15 for ; Mon, 15 Dec 2003 08:12:31 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hBFDCPr5001743 for ; Mon, 15 Dec 2003 05:12:30 -0800 (PST) Received: from sun.com (vpn-129-156-96-197.EMEA.Sun.COM [129.156.96.197]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hBFDCNm22023 for ; Mon, 15 Dec 2003 14:12:24 +0100 (MET) Message-ID: <3FDDB244.2010608@sun.com> Date: Mon, 15 Dec 2003 14:08:20 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: WG ACTION: 1 week to discuss [LL35] Improve Abstract Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please send your comments to the working group mailing list. Unless there is an objection due to lack of time to work on this before the holidays, the discussion will conclude on December 23. Please see: http://www.merit.edu/mail.archives/zeroconf/msg00002.html And: http://www.drizzle.org/~aboba/ZEROCONF/ll35.html Erik From owner-zeroconf@merit.edu Mon Dec 15 08:13: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 IAA07200 for ; Mon, 15 Dec 2003 08:13:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 668A991227; Mon, 15 Dec 2003 08:12:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A67B591226; Mon, 15 Dec 2003 08:12: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 9A3F091227 for ; Mon, 15 Dec 2003 08:12:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 081945DE15; Mon, 15 Dec 2003 08:12:32 -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 8C63E5DE1B for ; Mon, 15 Dec 2003 08:12:31 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hBFDCT0H021135; Mon, 15 Dec 2003 05:12:30 -0800 (PST) Received: from sun.com (vpn-129-156-96-197.EMEA.Sun.COM [129.156.96.197]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hBFDCRm22034; Mon, 15 Dec 2003 14:12:27 +0100 (MET) Message-ID: <3FDDB249.3080901@sun.com> Date: Mon, 15 Dec 2003 14:08:25 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Cc: Thomas Narten Subject: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please send your comments to the working group mailing list. Unless there is an objection due to lack of time to work on this before the holidays, the discussion will conclude on December 23. Please see: http://www.merit.edu/mail.archives/zeroconf/msg00001.html And: http://www.drizzle.org/~aboba/ZEROCONF/ll37.html Regards, Erik From owner-zeroconf@merit.edu Mon Dec 15 08:13:21 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07221 for ; Mon, 15 Dec 2003 08:13:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 46F2B9122A; Mon, 15 Dec 2003 08:13:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1630B9122B; Mon, 15 Dec 2003 08:13:04 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 494549122A for ; Mon, 15 Dec 2003 08:13:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 21D8F5DE1C; Mon, 15 Dec 2003 08:13:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 8A87D5DE1B for ; Mon, 15 Dec 2003 08:12:59 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hBFDCkAR015042; Mon, 15 Dec 2003 06:12:47 -0700 (MST) Received: from sun.com (vpn-129-156-96-197.EMEA.Sun.COM [129.156.96.197]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hBFDCem22053; Mon, 15 Dec 2003 14:12:44 +0100 (MET) Message-ID: <3FDDB255.9080005@sun.com> Date: Mon, 15 Dec 2003 14:08:37 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Cc: Ralph Droms , Ted Lemon Subject: WG ACTION: 1 week to discuss [LL40] IPv4 LL does not alter the behavior of the DHCPv4 state machine Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please send your comments to the working group mailing list. Unless there is an objection due to lack of time to work on this before the holidays, the discussion will conclude on December 23. Please see: http://www.merit.edu/mail.archives/zeroconf/msg00004.html And: http://www.drizzle.org/~aboba/ZEROCONF/ll40.html Erik From owner-zeroconf@merit.edu Mon Dec 15 08:13:38 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 IAA07248 for ; Mon, 15 Dec 2003 08:13:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 50C6A91228; Mon, 15 Dec 2003 08:12:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 221809122A; Mon, 15 Dec 2003 08:12:50 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A435491228 for ; Mon, 15 Dec 2003 08:12:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B55B5DE15; Mon, 15 Dec 2003 08:12:46 -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 1C7585DDFF for ; Mon, 15 Dec 2003 08:12:46 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hBFDCdr5001816; Mon, 15 Dec 2003 05:12:40 -0800 (PST) Received: from sun.com (vpn-129-156-96-197.EMEA.Sun.COM [129.156.96.197]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hBFDCbm22047; Mon, 15 Dec 2003 14:12:37 +0100 (MET) Message-ID: <3FDDB252.4090206@sun.com> Date: Mon, 15 Dec 2003 14:08:34 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Cc: Thomas Narten Subject: WG ACTION: 1 week to discuss [LL39] Remove multiple interface discussion from probe details Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please send your comments to the working group mailing list. Unless there is an objection due to lack of time to work on this before the holidays, the discussion will conclude on December 23. Please see: http://www.merit.edu/mail.archives/zeroconf/msg00005.html And: http://www.drizzle.org/~aboba/ZEROCONF/ll39.html Regards, Erik From owner-zeroconf@merit.edu Mon Dec 15 08:20: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 IAA07357 for ; Mon, 15 Dec 2003 08:20:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1531891226; Mon, 15 Dec 2003 08:20:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD3359122B; Mon, 15 Dec 2003 08:20: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 097D691226 for ; Mon, 15 Dec 2003 08:20:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id DE6255DE15; Mon, 15 Dec 2003 08:20:01 -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 62A885DDB6 for ; Mon, 15 Dec 2003 08:20:01 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hBFDJx0H024058 for ; Mon, 15 Dec 2003 05:20:00 -0800 (PST) Received: from sun.com (vpn-129-156-96-197.EMEA.Sun.COM [129.156.96.197]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hBFDJvm22906 for ; Mon, 15 Dec 2003 14:19:58 +0100 (MET) Message-ID: <3FDDB40A.3000702@sun.com> Date: Mon, 15 Dec 2003 14:15:54 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: WG ACTION: 1 week to discuss [LL38] Remove vestigial link-local only device text Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please send your comments to the working group mailing list. Unless there is an objection due to lack of time to work on this before the holidays, the discussion will conclude on December 23. Please see: http://www.merit.edu/mail.archives/zeroconf/msg00003.html And: http://www.drizzle.org/~aboba/ZEROCONF/ll38.html Regards, Erik From owner-zeroconf@merit.edu Tue Dec 16 03:53: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 DAA04757 for ; Tue, 16 Dec 2003 03:53:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E407A91240; Tue, 16 Dec 2003 03:53:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF1419123F; Tue, 16 Dec 2003 03:53:22 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A98CC9123F for ; Tue, 16 Dec 2003 03:53:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 96BA45DDC2; Tue, 16 Dec 2003 03:53:21 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from server21.ukservers.net (server21.ukservers.net [217.10.138.198]) by segue.merit.edu (Postfix) with ESMTP id 1ADCE5DD99 for ; Tue, 16 Dec 2003 03:53:21 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server21.ukservers.net (Postfix) with ESMTP id 12D0D39C14A; Tue, 16 Dec 2003 08:53:16 +0000 (GMT) Message-ID: <000901c3c3b2$0ca6f850$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , "Zeroconf Working Group" References: <3FDDB240.2090404@sun.com> Subject: Re: WG ACTION: 1 week to discuss "Proposed New Charter" Date: Tue, 16 Dec 2003 08:53:17 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: quoted-printable Erik, Typo in your new paragraph - delete the first "originally": | The working group originally was orginally chartered to --------------------^^^^^^^^^^-----^^^^^^^^^ | develop a requirements specification for host and application | operation in environments lacking configuration. The areas | for consideration included: ----- Original Message -----=20 From: "Erik Guttman" To: Cc: "Thomas Narten" ; Sent: Monday, December 15, 2003 1:08 PM Subject: WG ACTION: 1 week to discuss "Proposed New Charter" >=20 > Please send your comments to the working group mailing list. Unless > there is an objection due to lack of time to work on this before the > holidays, the discussion will conclude on December 23. >=20 > Please see: http://www.merit.edu/mail.archives/zeroconf/msg00008.html >=20 > Regards, >=20 > Erik >=20 > From owner-zeroconf@merit.edu Tue Dec 16 04:29:35 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05610 for ; Tue, 16 Dec 2003 04:29:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 56C939123F; Tue, 16 Dec 2003 04:29:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2ABD791241; Tue, 16 Dec 2003 04:29: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 3EFFE9123F for ; Tue, 16 Dec 2003 04:29:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0546E5DDE7; Tue, 16 Dec 2003 04:29:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from server21.ukservers.net (server21.ukservers.net [217.10.138.198]) by segue.merit.edu (Postfix) with ESMTP id A47E75DDDF for ; Tue, 16 Dec 2003 04:29:24 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server21.ukservers.net (Postfix) with ESMTP id 2328639C14A; Tue, 16 Dec 2003 09:29:25 +0000 (GMT) Message-ID: <002101c3c3b7$197e6090$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , Cc: "Thomas Narten" References: <3FDDB249.3080901@sun.com> Subject: Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs Date: Tue, 16 Dec 2003 09:29:26 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: quoted-printable LL37 part 1) It is quite right that the arithmetic in the document should be correct! = I therefore support revising any inaccuracies. However, my = interpretation of the text agrees with Thomas Narten: +-PROBE_TIME-+-PROBE_TIME-+-PROBE_TIME-+-PROBE_MAX-+ probe here-^ here-^ and here-^ done-^ This gives a time from 5-8 seconds (When PROBE_MIN=3D1s and = PROBE_MAX=3D2s). Not as in the proposed change! Philip ----- Original Message -----=20 From: "Erik Guttman" To: Cc: "Thomas Narten" Sent: Monday, December 15, 2003 1:08 PM Subject: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs >=20 > Please send your comments to the working group mailing list. Unless > there is an objection due to lack of time to work on this before the > holidays, the discussion will conclude on December 23. >=20 > Please see: http://www.merit.edu/mail.archives/zeroconf/msg00001.html > And: http://www.drizzle.org/~aboba/ZEROCONF/ll37.html >=20 > Regards, >=20 > Erik >=20 > From owner-zeroconf@merit.edu Tue Dec 16 05:07:58 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07540 for ; Tue, 16 Dec 2003 05:07:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C0D4F91241; Tue, 16 Dec 2003 05:07:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9092F91242; Tue, 16 Dec 2003 05:07:49 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A90A391241 for ; Tue, 16 Dec 2003 05:07:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9507A5DDC6; Tue, 16 Dec 2003 05:07:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from server21.ukservers.net (server21.ukservers.net [217.10.138.198]) by segue.merit.edu (Postfix) with ESMTP id 498C05DDC0 for ; Tue, 16 Dec 2003 05:07:48 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server21.ukservers.net (Postfix) with ESMTP id 5E49239C109; Tue, 16 Dec 2003 10:07:42 +0000 (GMT) Message-ID: <002701c3c3bc$72c384f0$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , "Zeroconf Working Group" References: <3FDDB249.3080901@sun.com> Subject: Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs Date: Tue, 16 Dec 2003 10:07:43 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: quoted-printable LL37 part 3) I support the proposed change. If we are to keep the existing text we need a convincing use-case for a = network with shorter timeouts. The current reference to "future versions of the IEEE 802 Spanning Tree = Protocol" seems entirely spurious in the light of Erik's comments on = "The motivation for the 1-2 second delay..." which has nothing to do = with Spanning Tree. Philip From owner-zeroconf@merit.edu Tue Dec 16 05:23: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 FAA08215 for ; Tue, 16 Dec 2003 05:23:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C23091242; Tue, 16 Dec 2003 05:23:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9E6D91243; Tue, 16 Dec 2003 05:23:31 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1045E91242 for ; Tue, 16 Dec 2003 05:23:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF41B5DDD0; Tue, 16 Dec 2003 05:23:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from server21.ukservers.net (server21.ukservers.net [217.10.138.198]) by segue.merit.edu (Postfix) with ESMTP id A406C5DDA5 for ; Tue, 16 Dec 2003 05:23:30 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server21.ukservers.net (Postfix) with ESMTP id E2B9839C07C; Tue, 16 Dec 2003 10:21:46 +0000 (GMT) Message-ID: <003001c3c3be$6a222110$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , Cc: "Thomas Narten" References: <3FDDB252.4090206@sun.com> Subject: Re: WG ACTION: 1 week to discuss [LL39] Remove multiple interface discussion from probe details Date: Tue, 16 Dec 2003 10:21:48 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: quoted-printable I really thought this had been sorted out! The proposed change is = correct except in the change to 2.5 where the sentiment is correct but = the proposed details are not. The text of 2.5 refers to a configured interface, not one which is being = configured. It also ambiguously refers to "the host's own IP address". = The text should read: "At any time, if a host receives an ARP packet (request *or* reply) on = an interface where the 'sender IP address' is the IP address the host = has configured for that interface, but the 'sender hardware address' = does not match the hardware address of that interface, then this is a = conflicting ARP packet, indicating an address collision." Philip From owner-zeroconf@merit.edu Tue Dec 16 07:58: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 HAA13550 for ; Tue, 16 Dec 2003 07:58:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D1CA491247; Tue, 16 Dec 2003 07:58:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 939A491248; Tue, 16 Dec 2003 07:58: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 D2DFB91240 for ; Tue, 16 Dec 2003 07:58:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id AE96E5DE0A; Tue, 16 Dec 2003 07:58:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from server21.ukservers.net (server21.ukservers.net [217.10.138.198]) by segue.merit.edu (Postfix) with ESMTP id 508975DE03 for ; Tue, 16 Dec 2003 07:58:26 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server21.ukservers.net (Postfix) with ESMTP id 2989F39C276; Tue, 16 Dec 2003 12:58:24 +0000 (GMT) Message-ID: <00e301c3c3d4$4b166db0$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , "Zeroconf Working Group" References: <3FDDB244.2010608@sun.com> Subject: Re: WG ACTION: 1 week to discuss [LL35] Improve Abstract Date: Tue, 16 Dec 2003 12:16:45 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: quoted-printable I accept the new abstract as an improvement. Particularly, in view of = the proposed new charter. Philip ----- Original Message -----=20 From: "Erik Guttman" To: Sent: Monday, December 15, 2003 1:08 PM Subject: WG ACTION: 1 week to discuss [LL35] Improve Abstract >=20 > Please send your comments to the working group mailing list. Unless > there is an objection due to lack of time to work on this before the > holidays, the discussion will conclude on December 23. >=20 > Please see: http://www.merit.edu/mail.archives/zeroconf/msg00002.html > And: http://www.drizzle.org/~aboba/ZEROCONF/ll35.html >=20 > Erik >=20 > From owner-zeroconf@merit.edu Tue Dec 16 07:58:59 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13569 for ; Tue, 16 Dec 2003 07:58:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 063AB9124A; Tue, 16 Dec 2003 07:58:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C940591240; Tue, 16 Dec 2003 07:58: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 F21EF91247 for ; Tue, 16 Dec 2003 07:58:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id C16965DE0B; Tue, 16 Dec 2003 07:58:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from server21.ukservers.net (server21.ukservers.net [217.10.138.198]) by segue.merit.edu (Postfix) with ESMTP id 520745DE04 for ; Tue, 16 Dec 2003 07:58:26 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server21.ukservers.net (Postfix) with ESMTP id 10EC839C26A; Tue, 16 Dec 2003 12:58:23 +0000 (GMT) Message-ID: <00e101c3c3d4$4a791c40$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , Cc: "Ralph Droms" , "Ted Lemon" References: <3FDDB255.9080005@sun.com> Subject: Re: WG ACTION: 1 week to discuss [LL40] IPv4 LL does not alter the behavior of the DHCPv4 state machine Date: Tue, 16 Dec 2003 10:52:11 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: quoted-printable I am happy with the point but feel the proposed text is unwieldy. How about: "2.12 Interaction between DHCPv4 client and IPv4ll state machines A device that implements both IPv4ll and a DHCPv4 client should not = alter the behavior of the DHCPv4 client to accommodate IPv4 Link-Local = configuration. In particular configuration of an IPv4 Link-Local = address, whether or not a DHCP server is currently responding, is not = sufficient reason to unconfigure a valid DHCP lease, to stop the DHCP = client from attempting to acquire a new IP address, to change DHCP = timeouts or to change the behaviour of the DHCP state machine in any = other way. Note that this has not been observed in some early implementations of = IPv4 Link-Local configuration." Philip From owner-zeroconf@merit.edu Tue Dec 16 12:01:01 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23484 for ; Tue, 16 Dec 2003 12:01:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E60FA9124B; Tue, 16 Dec 2003 12:00:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AFB699124C; Tue, 16 Dec 2003 12:00:49 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D4739124B for ; Tue, 16 Dec 2003 12:00:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6C0D05DD9F; Tue, 16 Dec 2003 12:00:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by segue.merit.edu (Postfix) with ESMTP id 158035DD94 for ; Tue, 16 Dec 2003 12:00:48 -0500 (EST) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Dec 2003 09:03:47 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hBGH0hZ2022597; Tue, 16 Dec 2003 09:00:45 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([161.44.65.247]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AER90365; Tue, 16 Dec 2003 12:00:42 -0500 (EST) Message-Id: <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Dec 2003 12:00:40 -0500 To: Erik Guttman From: Ralph Droms Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer Cc: zeroconf@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk In response to this issue, I suggest deleting subsections 1.7 and 2.11, and inserting the following text as the last subsection of section 1 (in particular, to come after subsection 1.9. "Communication with Routable Addresses"): 1.x When to configure a Link-Local IPv4 address on an interface Having addresses of multiple different scopes assigned to an interface, with no adequate way to determine in what circumstances each address should be used, leads to complexity for applications and confusion for users. A host with an address on a link can communicate with all other devices on that link, whether those devices use Link-Local addresses, or routable addresses. For these reasons, a host SHOULD NOT have both a valid routable address and a Link-Local IPv4 address configure on the same interface. A routable address is any address that is: * a unicast address * not a loopback address * not in the 169..2.54/32 subnet reserved for Link-Local IPv4 addresses A "valid routable address" is a routable address that passes the reachability test described in section 2 of "Detection of Network Attachment (DNA) in IPv4" [DNAv4]. The assignment and use of a Link-Local IPv4 address on an interface is based solely on the state of the interface, and is independent of any other protocols such as DHCP or RADIUS. A host MUST NOT alter its behavior and use of other protocols such as DHCP and RADIUS because the host has assigned a Link-Local IPv4 address to an interface. When an interface has a valid routable address configured on an interface, the host SHOULD NOT also assign a Link-Local IPv4 address to that interface. If a host finds that an interface that was previous configured with a Link-Local IPv4 address is now configured with a valid routable address, the host MUST always use the routable address when initiating new communications, and MUST cease advertising the availability of the Link-Local IPv4 address through whatever mechanisms that address had been made known to others. The host SHOULD continue to use the Link-Local IPv4 address for communications underway when the routable address was configured, and MAY continue to accept new communications addressed to the Link-Local IPv4 address. Ways in which a valid routable address might be configured for the interface include: * Manual configuration * Address assignment through RADIUS or DHCP * Roaming of the host to a network on which a routable address assigned to the interface is valid If a host finds that an interface that was previously configured with a valid routable address no longer has a valid routable address, the host MAY identify a usable Link-Local IPv4 address (as described in section 2) and assign that address to the interface. Ways in which a valid routable address might no longer be assigned to an interface include: * Removal of the address from the interface through manual configuration * Expiration of the lease on the address assigned through DHCP * Roaming of the host to a new network on which the address is no longer valid. Further discussion of the issues in detection of transient failures and the use of DHCP in response to network attachment failure is provided in "Detection of Network Attachment (DNA) in IPv4". From owner-zeroconf@merit.edu Tue Dec 16 15:20: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 PAA01825 for ; Tue, 16 Dec 2003 15:20:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9AC729124C; Tue, 16 Dec 2003 15:20:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 686DD9124D; Tue, 16 Dec 2003 15:20:50 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4E2A89124C for ; Tue, 16 Dec 2003 15:20:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 23BE65DDF8; Tue, 16 Dec 2003 15:20:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from home.karahalios.org (dsl093-162-009.tus1.dsl.speakeasy.net [66.93.162.9]) by segue.merit.edu (Postfix) with ESMTP id 0C64C5DDD6 for ; Tue, 16 Dec 2003 15:20:48 -0500 (EST) Received: from [192.168.2.2] (usr2.Karahalios.org [192.168.2.2]) (authenticated) by home.karahalios.org (8.11.1/8.10.1) with ESMTP id hBGKJTL11417; Tue, 16 Dec 2003 13:19:29 -0700 In-Reply-To: <4.3.2.7.2.20031216122752.036d3688@flask.cisco.com> References: <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> <4.3.2.7.2.20031216122752.036d3688@flask.cisco.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <26D0BD60-3005-11D8-899C-00039377AD70@Outersoft.com> Content-Transfer-Encoding: 7bit Cc: Ralph Droms From: Alex Karahalios Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer Date: Tue, 16 Dec 2003 13:19:29 -0700 To: Zeroconf X-Mailer: Apple Mail (2.609) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, Yes, I understand this, but I think the phrase you are proposing, a host "MUST cease advertising the availability of the Link-Local IPv4 address through whatever mechanisms that address had been made known to others," will make it such that a new LL IPv4 device will not be able to interoperate on the network. Take the case of a printer using mDNS, for example. A new device would only get routable address information from the printer, but the new device is only configured for LL IPv4 and thus is shut out of communicating with the printer. Alex Karahalios On Dec 16, 2003, at 11:09 AM, Ralph Droms wrote: > Well, section 1.9 of draft-ietf-zeroconf-ipv4-linklocal-10.txt, > "Communication with Routable Addresses", describes how two devices can > communicate in the case you describe, where one device has a routable > address and one device has a Link-Local IPv4 address. > > Of course, there's a difference between "finding" and "communicating > with". > "Finding" printers is out of scope for Link-Local IPv4, so > draft-ietf-zeroconf-ipv4-linklocal-10.txt doesn't address how the > computer > determines the printer's address, regardless of whether the printer is > using > a routable address or a Link-Local IPv4 address. > > - Ralph > > At 10:25 AM 12/16/2003 -0700, Alex Karahalios wrote: >> Given the below text which specifies the a host "MUST cease >> advertising the availability of the Link-Local IPv4 address", could >> some explain how I would be able to make use of LL IPv4 addressing in >> the following circumstances: >> >> Let's say a printer stops advertising LL IPv4 addresses because it >> obtains a DHCP address. A new computer is introduced into the network >> that wants to print, but it cannot obtain a routable address, so it >> configures a LL IPv4 address. How is the new computer suppose to find >> the printer if the printer has stopped advertising its LL address? >> >> I've asked a similar version of this question before and was told >> that there are provisions in draft to address this, but the follow >> text preclude this. >> >> Thanks, >> >> Alex Karahalios >> >> On Dec 16, 2003, at 10:00 AM, Ralph Droms wrote: >> >>> If a host finds that an interface that was previous configured >>> with >>> a Link-Local IPv4 address is now configured with a valid routable >>> address, the host MUST always use the routable address when >>> initiating new communications, and MUST cease advertising the >>> availability of the Link-Local IPv4 address through whatever >>> mechanisms that address had been made known to others. The host >>> SHOULD continue to use the Link-Local IPv4 address for >>> communications underway when the routable address was configured, >>> and MAY continue to accept new communications addressed to the >>> Link-Local IPv4 address. Ways in which a valid routable address >>> might be configured for the interface include: > From owner-zeroconf@merit.edu Tue Dec 16 15:51:12 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03203 for ; Tue, 16 Dec 2003 15:51:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A2EB59124D; Tue, 16 Dec 2003 15:51:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70A0F91258; Tue, 16 Dec 2003 15:51:04 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5857E9124D for ; Tue, 16 Dec 2003 15:51:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4491F5DE00; Tue, 16 Dec 2003 15:51:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from home.karahalios.org (dsl093-162-009.tus1.dsl.speakeasy.net [66.93.162.9]) by segue.merit.edu (Postfix) with ESMTP id 381BE5DDD9 for ; Tue, 16 Dec 2003 15:51:02 -0500 (EST) Received: from [192.168.2.2] (usr2.Karahalios.org [192.168.2.2]) (authenticated) by home.karahalios.org (8.11.1/8.10.1) with ESMTP id hBGKp1L11748; Tue, 16 Dec 2003 13:51:01 -0700 In-Reply-To: <26D0BD60-3005-11D8-899C-00039377AD70@Outersoft.com> References: <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> <4.3.2.7.2.20031216122752.036d3688@flask.cisco.com> <26D0BD60-3005-11D8-899C-00039377AD70@Outersoft.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8EB1CF34-3009-11D8-899C-00039377AD70@Outersoft.com> Content-Transfer-Encoding: 7bit Cc: Zeroconf From: Alex Karahalios Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer Date: Tue, 16 Dec 2003 13:51:01 -0700 To: Ralph Droms X-Mailer: Apple Mail (2.609) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ralph, Sorry to imply you are proposing this text since it's part of section 1.7 already... Alex Karahalios On Dec 16, 2003, at 1:19 PM, Alex Karahalios wrote: > Ralph, > > Yes, I understand this, but I think the phrase you are proposing, a > host "MUST cease advertising the availability of the Link-Local IPv4 > address through whatever mechanisms that address had been made known > to others," will make it such that a new LL IPv4 device will not be > able to interoperate on the network. > > Take the case of a printer using mDNS, for example. A new device would > only get routable address information from the printer, but the new > device is only configured for LL IPv4 and thus is shut out of > communicating with the printer. > > Alex Karahalios > > On Dec 16, 2003, at 11:09 AM, Ralph Droms wrote: > >> Well, section 1.9 of draft-ietf-zeroconf-ipv4-linklocal-10.txt, >> "Communication with Routable Addresses", describes how two devices can >> communicate in the case you describe, where one device has a routable >> address and one device has a Link-Local IPv4 address. >> >> Of course, there's a difference between "finding" and "communicating >> with". >> "Finding" printers is out of scope for Link-Local IPv4, so >> draft-ietf-zeroconf-ipv4-linklocal-10.txt doesn't address how the >> computer >> determines the printer's address, regardless of whether the printer >> is using >> a routable address or a Link-Local IPv4 address. >> >> - Ralph >> >> At 10:25 AM 12/16/2003 -0700, Alex Karahalios wrote: >>> Given the below text which specifies the a host "MUST cease >>> advertising the availability of the Link-Local IPv4 address", could >>> some explain how I would be able to make use of LL IPv4 addressing >>> in the following circumstances: >>> >>> Let's say a printer stops advertising LL IPv4 addresses because it >>> obtains a DHCP address. A new computer is introduced into the >>> network that wants to print, but it cannot obtain a routable >>> address, so it configures a LL IPv4 address. How is the new computer >>> suppose to find the printer if the printer has stopped advertising >>> its LL address? >>> >>> I've asked a similar version of this question before and was told >>> that there are provisions in draft to address this, but the follow >>> text preclude this. >>> >>> Thanks, >>> >>> Alex Karahalios >>> >>> On Dec 16, 2003, at 10:00 AM, Ralph Droms wrote: >>> >>>> If a host finds that an interface that was previous configured >>>> with >>>> a Link-Local IPv4 address is now configured with a valid routable >>>> address, the host MUST always use the routable address when >>>> initiating new communications, and MUST cease advertising the >>>> availability of the Link-Local IPv4 address through whatever >>>> mechanisms that address had been made known to others. The host >>>> SHOULD continue to use the Link-Local IPv4 address for >>>> communications underway when the routable address was configured, >>>> and MAY continue to accept new communications addressed to the >>>> Link-Local IPv4 address. Ways in which a valid routable address >>>> might be configured for the interface include: >> > From owner-zeroconf@merit.edu Tue Dec 16 16:26: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 QAA07725 for ; Tue, 16 Dec 2003 16:26:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 48D3C9125E; Tue, 16 Dec 2003 16:26:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 146BB9125F; Tue, 16 Dec 2003 16:26:05 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EA4319125E for ; Tue, 16 Dec 2003 16:26:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id D8E285DD90; Tue, 16 Dec 2003 16:26:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from hades.pp.htv.fi (cs78147060.pp.htv.fi [62.78.147.60]) by segue.merit.edu (Postfix) with ESMTP id A0F925DDD7 for ; Tue, 16 Dec 2003 16:26:02 -0500 (EST) Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) with ESMTP id hBGLRK94013473; Tue, 16 Dec 2003 23:27:21 +0200 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) id hBGLRGiD013472; Tue, 16 Dec 2003 23:27:16 +0200 Subject: Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs From: Mika Liljeberg To: Erik Guttman Cc: zeroconf@merit.edu, Thomas Narten In-Reply-To: <3FDDB249.3080901@sun.com> References: <3FDDB249.3080901@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1071610036.12327.17.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 16 Dec 2003 23:27:16 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Instead of trying to figure out how long it takes to send three probes, I would like to step back a little and ask the question WHY exactly do we have to send THREE PROBES? What exactly in v4LL necessitates sending three DAD probes when IPv6 can get away with only one? Here's the relevant bit from RFC2462: ... 5.1. Node Configuration Variables A node MUST allow the following autoconfiguration-related variable to be configured by system management for each multicast interface: DupAddrDetectTransmits The number of consecutive Neighbor Solicitation messages sent while performing Duplicate Address Detection on a tentative address. A value of zero indicates that Duplicate Address Detection is not performed on tentative addresses. A value of one indicates a single transmission with no follow up retransmissions. Default: 1, but may be overridden by a link-type specific value in the document that covers issues related to the transmission of IP over a particular link type (e.g., [IPv6-ETHER]). Autoconfiguration also assumes the presence of the variable RetransTimer as defined in [DISCOVERY]. For autoconfiguration purposes, RetransTimer specifies the delay between consecutive Neighbor Solicitation transmissions performed during Duplicate Address Detection (if DupAddrDetectTransmits is greater than 1), as well as the time a node waits after sending the last Neighbor Solicitation before ending the Duplicate Address Detection process. ... Here's my proposal (three fold): 1. Let's specify DAD probe in the same way as in IPv6, defaulting to a single probe packet 2. In the event of a conflict (slightly more probable with v4LL compared to IPv6), allow the node to select a new v4LL and retry up to, e.g., AddrSelectRetries times 3. Let's get rid of the text describing shorter timeouts. If we default to a single probe, DAD only takes 1..2 seconds (with a high probability). That is good enough from the usability point of view. Regards, MikaL On Mon, 2003-12-15 at 15:08, Erik Guttman wrote: > Please send your comments to the working group mailing list. Unless > there is an objection due to lack of time to work on this before the > holidays, the discussion will conclude on December 23. > > Please see: http://www.merit.edu/mail.archives/zeroconf/msg00001.html > And: http://www.drizzle.org/~aboba/ZEROCONF/ll37.html > > Regards, > > Erik > From owner-zeroconf@merit.edu Tue Dec 16 18:32:29 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14534 for ; Tue, 16 Dec 2003 18:32:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D105491262; Tue, 16 Dec 2003 18:32:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9EB8E91263; Tue, 16 Dec 2003 18:32:21 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A6F0291262 for ; Tue, 16 Dec 2003 18:32:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 90F2A5DDB3; Tue, 16 Dec 2003 18:32:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from server21.ukservers.net (server21.ukservers.net [217.10.138.198]) by segue.merit.edu (Postfix) with ESMTP id 3294D5DD8D for ; Tue, 16 Dec 2003 18:32:20 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server21.ukservers.net (Postfix) with ESMTP id 135E739C0B5; Tue, 16 Dec 2003 23:32:19 +0000 (GMT) Message-ID: <010901c3c42c$d90f0070$131010ac@aldebaran> From: "Philip Nye" To: "Ted Lemon" Cc: "Erik Guttman" , , "Ralph Droms" , "Ted Lemon" References: <3FDDB255.9080005@sun.com> <00e101c3c3d4$4a791c40$131010ac@aldebaran> Subject: Re: WG ACTION: 1 week to discuss [LL40] IPv4 LL does not alter the behavior of the DHCPv4 state machine Date: Tue, 16 Dec 2003 23:32:19 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: quoted-printable > From: "Ted Lemon" > ... > This one I don't love: >=20 > > Note that this has not been observed in some early implementations = of=20 > > IPv4 Link-Local configuration." >=20 > I would say instead: >=20 > Several early implementations of IPv4 link-local have modified the = DHCP=20 > state machine in an attempt to make IPv4 link-local more reliable, and = > the field experience we have gained from this has shown that it does=20 > not work - reliability of DHCP service is significantly reduced. If=20 > increased reliability of IPv4 link-local is desired, we recommend that = > the IPv4 link-local state machine track the DHCP client state machine=20 > and, in cases where it is not certain that the DHCP-assigned address = is=20 > correct, the IPv4ll state machine acquire an IPv4ll address without=20 > causing the DHCP state machine to relinquish its address. That's fine by me. Philip From owner-zeroconf@merit.edu Wed Dec 17 05:09:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01903 for ; Wed, 17 Dec 2003 05:09:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ABB5891266; Wed, 17 Dec 2003 05:08:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 735D091267; Wed, 17 Dec 2003 05:08:53 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 87B9191266 for ; Wed, 17 Dec 2003 05:08:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 77FFF5DDFB; Wed, 17 Dec 2003 05:08:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id CDF255DDE7 for ; Wed, 17 Dec 2003 05:08:19 -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 hBHA7au08292; Wed, 17 Dec 2003 17:07:39 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id hBHA7Gj04880; Wed, 17 Dec 2003 17:07:19 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: Erik Guttman , zeroconf@merit.edu, Thomas Narten Subject: Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs In-Reply-To: <1071610036.12327.17.camel@hades> References: <1071610036.12327.17.camel@hades> <3FDDB249.3080901@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 17 Dec 2003 17:07:16 +0700 Message-ID: <12600.1071655636@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 16 Dec 2003 23:27:16 +0200 From: Mika Liljeberg Message-ID: <1071610036.12327.17.camel@hades> | Instead of trying to figure out how long it takes to send three probes, | I would like to step back a little and ask the question WHY exactly do | we have to send THREE PROBES? What exactly in v4LL necessitates sending | three DAD probes when IPv6 can get away with only one? v6 has 64 bits of address space, it is incredibly unlikely that something doing random address assignment (which is what is relevant here) is ever going to clash with something else - so one check, no reply, and all is OK. v4LL has only 16 bits to play in (slightly less because of the exclusions of the first and last /24's from contention) - the birthday paradox tells us that with perfect random assignments we're going to get a clash as soon as the number of hosts on the link gets to around 256 (2^8 being sqrt(2^16) which is a very rough approximation of the point where probability goes > 50%). 256 hosts is not at all implausible on a link (2^32 is), so v4LL has to actually expect to get duplicates, where in v6 they are only likely to occur due to human stupidity. v4LL simply has to try harder to detect those duplicates. kre From owner-zeroconf@merit.edu Wed Dec 17 13:52: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 NAA26083 for ; Wed, 17 Dec 2003 13:52:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0968D9127D; Wed, 17 Dec 2003 13:52:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD33F9127C; Wed, 17 Dec 2003 13:52:45 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ACF0F9127D for ; Wed, 17 Dec 2003 13:52:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8724C5DE11; Wed, 17 Dec 2003 13:52:44 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from hades.pp.htv.fi (cs78147060.pp.htv.fi [62.78.147.60]) by segue.merit.edu (Postfix) with ESMTP id 60D675DDF2 for ; Wed, 17 Dec 2003 13:52:43 -0500 (EST) Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) with ESMTP id hBHIsP94016936; Wed, 17 Dec 2003 20:54:26 +0200 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) id hBHIsKaT016935; Wed, 17 Dec 2003 20:54:20 +0200 Subject: Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs From: Mika Liljeberg To: Robert Elz Cc: Erik Guttman , zeroconf@merit.edu, Thomas Narten In-Reply-To: <12600.1071655636@munnari.OZ.AU> References: <1071610036.12327.17.camel@hades> <3FDDB249.3080901@sun.com> <12600.1071655636@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1071687260.15146.3.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 17 Dec 2003 20:54:20 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-12-17 at 12:07, Robert Elz wrote: > | Instead of trying to figure out how long it takes to send three probes, > | I would like to step back a little and ask the question WHY exactly do > | we have to send THREE PROBES? What exactly in v4LL necessitates sending > | three DAD probes when IPv6 can get away with only one? > v4LL has only 16 bits to play in (slightly less because of the exclusions of > the first and last /24's from contention) - the birthday paradox tells us > that with perfect random assignments we're going to get a clash as soon as > the number of hosts on the link gets to around 256 (2^8 being sqrt(2^16) which > is a very rough approximation of the point where probability goes > 50%). You're missing the point. The spec is telling us to probe the SAME ADDRESS three times. The retransmissions might make sense if the link has a high loss probability, but address collision probability has nothing to do with it. Please read this bit again: Here's my proposal (three fold): 1. Let's specify DAD probe in the same way as in IPv6, defaulting to a single probe packet 2. In the event of a conflict (slightly more probable with v4LL compared to IPv6), allow the node to select a new v4LL and retry up to, e.g., AddrSelectRetries times 3. Let's get rid of the text describing shorter timeouts. If we default to a single probe, DAD only takes 1..2 seconds (with a high probability). That is good enough from the usability point of view. Regards, MikaL From owner-zeroconf@merit.edu Wed Dec 17 15:51: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 PAA04322 for ; Wed, 17 Dec 2003 15:51:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 193E491282; Wed, 17 Dec 2003 15:51:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DAEDE91283; Wed, 17 Dec 2003 15:51:11 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 87F9F91282 for ; Wed, 17 Dec 2003 15:51:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 69D005DD9F; Wed, 17 Dec 2003 15:51:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fuchsia.home (unknown [192.150.250.67]) by segue.merit.edu (Postfix) with ESMTP id D24BA5DD96 for ; Wed, 17 Dec 2003 15:45:32 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id hBHKiOMA021011; Thu, 18 Dec 2003 03:44:25 +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 hBHKhEg06466; Thu, 18 Dec 2003 03:43:19 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: Erik Guttman , zeroconf@merit.edu, Thomas Narten Subject: Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs In-Reply-To: <1071687260.15146.3.camel@hades> References: <1071687260.15146.3.camel@hades> <1071610036.12327.17.camel@hades> <3FDDB249.3080901@sun.com> <12600.1071655636@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 18 Dec 2003 03:43:14 +0700 Message-ID: <4683.1071693794@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 17 Dec 2003 20:54:20 +0200 From: Mika Liljeberg Message-ID: <1071687260.15146.3.camel@hades> | You're missing the point. I don't think so. | The spec is telling us to probe the SAME ADDRESS three times. Yes, that (or twice, at an absolute minimum) is what needs to happen. | The retransmissions might make sense if the link | has a high loss probability, but address collision probability has | nothing to do with it. Not true. What matters is the probability of failure to detect a duplicate address (that could be detected - ones owned by nodes that are disconnected we can do nothing about). That is (approximately) the product of the probability of packet loss (of either the query, or the reply), and the probability that there is in fact a duplicate to detect. For v6, the second of those is a much smaller (MUCH smaller) number than on v4 (v4 is not just "slightly more probable" to have a conflict, it is in fact likely there, and almost unimaginable on v6). That number we cannot do anything about, it is controlled by the number of available addresses from which to make our random choice. So, if we want to get the overall probability of failure of v4 LL allocation down somewhere near what it is for v6, the only thing we can alter to achieve that is to make the probability of packet loss much smaller - that's done by simply retransmitting, if the probability of the loss of 1 packet is 0.01% (probably a little high for an ethernet, but not too far away I suspect) then the probability of either of 2 (query&reply) being lost is a bit more than that (but I think, if I remember that formula, less than 0.02% - or was it more? Doesn't matter much) The probability of all 3 of 3 attempts suffering a lost packet is then something like 0.0000000008% if I did the arithmetic right (which I probably didn't, but it is small anyway). While not getting us to the overall confidence level of v6, this at least gets us a lot closer. | Please read this bit again: I read it the first time... | Here's my proposal (three fold): | 1. Let's specify DAD probe in the same way as in IPv6, defaulting | to a single probe packet No, that's what we cannot do. The probability of undetected failure then is too high. | 2. In the event of a conflict (slightly more probable with v4LL | compared to IPv6), allow the node to select a new v4LL and retry | up to, e.g., AddrSelectRetries times That's not any kind of change. But the "slightly" should be "much". | 3. Let's get rid of the text describing shorter timeouts. If we | default to a single probe, DAD only takes 1..2 seconds (with a | high probability). That is good enough from the usability point | of view. Since (1) is already ruled out, this becomes irrelevant. This is no longer important, but ages ago I argued that the timer values make no sense as they are - 1-2 seconds is way too long to wait for a reply from a local 802.x style network - if a reply doesn't arrive in (well under really) 100ms, then it isn't coming. On the other hand, if the spanning tree algorithm may be running in a connected switch (which is actually very likely, every time the address assignment algorithm needs to run, if connected to a switch port that runs spanning tree), then the timer values are way too short (at least, the first one). Either way, the values specified make no real sense (we could have 3 transmits and be done in 0.5 seconds if we ignore spanning tree delays). The WG decided to ignore this - partly I believe out of a desire to spread out probes, if a large net all happens to start at the same time, which is a valid concern. They also decided to ignore spanning trees - because specifying a timer long enough to cope would irritate lots of people, and specifying an algorithm to dynamically detect whether a long delay is needed or not seemed too complex (though several reasonable suggestions were made). This isn't something important enough to fight over. A few more years (one hopes) and v4 will be header for the scrap heap anyway. kre From owner-zeroconf@merit.edu Wed Dec 17 16:05:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05228 for ; Wed, 17 Dec 2003 16:05:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9CD829127F; Wed, 17 Dec 2003 16:04:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3441491286; Wed, 17 Dec 2003 16:04:40 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D33E79127F for ; Wed, 17 Dec 2003 16:04:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id AF7495DE2D; Wed, 17 Dec 2003 16:04:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from server21.ukservers.net (server21.ukservers.net [217.10.138.198]) by segue.merit.edu (Postfix) with ESMTP id 15B225DE2C for ; Wed, 17 Dec 2003 16:04:38 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server21.ukservers.net (Postfix) with ESMTP id 8605239C13B; Wed, 17 Dec 2003 21:04:39 +0000 (GMT) Message-ID: <01f301c3c4e1$638370b0$131010ac@aldebaran> From: "Philip Nye" To: "Robert Elz" , "Mika Liljeberg" Cc: "Erik Guttman" , , "Thomas Narten" References: <1071610036.12327.17.camel@hades> <3FDDB249.3080901@sun.com> <12600.1071655636@munnari.OZ.AU> Subject: Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs Date: Wed, 17 Dec 2003 21:04:40 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: quoted-printable > From: "Robert Elz" >=20 > | Instead of trying to figure out how long it takes to send three = probes, > | I would like to step back a little and ask the question WHY = exactly do > | we have to send THREE PROBES? What exactly in v4LL necessitates = sending > | three DAD probes when IPv6 can get away with only one? >=20 > v6 has 64 bits of address space, it is incredibly unlikely that = something > doing random address assignment (which is what is relevant here) is = ever > going to clash with something else - so one check, no reply, and all = is OK. >=20 > v4LL has only 16 bits to play in (slightly less because of the = exclusions of > the first and last /24's from contention) - the birthday paradox tells = us > that with perfect random assignments we're going to get a clash as = soon as > the number of hosts on the link gets to around 256 (2^8 being = sqrt(2^16) which > is a very rough approximation of the point where probability goes > = 50%). >=20 > 256 hosts is not at all implausible on a link (2^32 is), so v4LL has = to > actually expect to get duplicates, where in v6 they are only likely to = occur > due to human stupidity. v4LL simply has to try harder to detect = those > duplicates. In addition to this, it is probably the case that IPv4 systems do not = cope so well as IPv6 with clashes and changing addresses, so having a = higher confidence level that the address you have picked is unique on = the link is probably going to make life that bit easier for the user. The final and probably strongest argument against Mika's suggestion is = that it is way too late in the process to be re-opening this algorithm = at this point. Unless you can show that three probes will break where = one won't (which I doubt) then we should tidy up the arithmetic so at = least we get the answer to 2+2 right, and get it out of the door. Philip From owner-zeroconf@merit.edu Wed Dec 17 16:50:36 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07433 for ; Wed, 17 Dec 2003 16:50:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B391091221; Wed, 17 Dec 2003 16:50:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 878559127E; Wed, 17 Dec 2003 16:50: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 62EFB91221 for ; Wed, 17 Dec 2003 16:50:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 332305DDE5; Wed, 17 Dec 2003 16:50:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from hades.pp.htv.fi (cs78147060.pp.htv.fi [62.78.147.60]) by segue.merit.edu (Postfix) with ESMTP id 2F2465DDEF for ; Wed, 17 Dec 2003 16:50:25 -0500 (EST) Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) with ESMTP id hBHLq294017450; Wed, 17 Dec 2003 23:52:02 +0200 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) id hBHLpwCf017449; Wed, 17 Dec 2003 23:51:58 +0200 Subject: Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs From: Mika Liljeberg To: Philip Nye Cc: Robert Elz , Erik Guttman , zeroconf@merit.edu, Thomas Narten In-Reply-To: <01f301c3c4e1$638370b0$131010ac@aldebaran> References: <1071610036.12327.17.camel@hades> <3FDDB249.3080901@sun.com> <12600.1071655636@munnari.OZ.AU> <01f301c3c4e1$638370b0$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1071697918.15146.45.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Wed, 17 Dec 2003 23:51:58 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I see what you and kre are saying, but I don't buy the number game. The fact remains that three is a wholly arbitrary number and likely to be wrong for most environments. Who is to say one probe is not enough? It all depends on the link error rate and the number of nodes supported by the link. For instance, a Bluetooth PAN piconet (radio range 10 meters) supports a maximum of 7 nodes and the link layer is reliable. Three probes is completely unnecessary and at the same time constitute a usability problem, since many of the use cases involve quick ad-hoc interactions. My objection to three probes is as I have stated before: 5..8 seconds is too long from the usability point of view. The feedback gathered from users of data services in GSM/GPRS networks is overwhelming on this. A user expects to see results within a few seconds of the first button press. Address configuration is just one of the initial steps that needs to take place in a typical use case. I think we can pretty well start out with the assumption that v4LL address collisions will sometimes happen. What could be spelled out is, what is an acceptable probability for failing to detect one? Knowing that, the number of probe retransmissions can be adjusted accordingly for a particular environment. IPv6 allows adjusting the number of probes transmitted. Why should v4LL be any different? As for it being too late, the last time I raised this point no-one seemed inclined to discuss it. I must say two responses are a distinct improvement. MikaL On Wed, 2003-12-17 at 23:04, Philip Nye wrote: > > From: "Robert Elz" > > > > | Instead of trying to figure out how long it takes to send three probes, > > | I would like to step back a little and ask the question WHY exactly do > > | we have to send THREE PROBES? What exactly in v4LL necessitates sending > > | three DAD probes when IPv6 can get away with only one? > > > > v6 has 64 bits of address space, it is incredibly unlikely that something > > doing random address assignment (which is what is relevant here) is ever > > going to clash with something else - so one check, no reply, and all is OK. > > > > v4LL has only 16 bits to play in (slightly less because of the exclusions of > > the first and last /24's from contention) - the birthday paradox tells us > > that with perfect random assignments we're going to get a clash as soon as > > the number of hosts on the link gets to around 256 (2^8 being sqrt(2^16) which > > is a very rough approximation of the point where probability goes > 50%). > > > > 256 hosts is not at all implausible on a link (2^32 is), so v4LL has to > > actually expect to get duplicates, where in v6 they are only likely to occur > > due to human stupidity. v4LL simply has to try harder to detect those > > duplicates. > > In addition to this, it is probably the case that IPv4 systems do not cope so well as IPv6 with clashes and changing addresses, so having a higher confidence level that the address you have picked is unique on the link is probably going to make life that bit easier for the user. > > The final and probably strongest argument against Mika's suggestion is that it is way too late in the process to be re-opening this algorithm at this point. Unless you can show that three probes will break where one won't (which I doubt) then we should tidy up the arithmetic so at least we get the answer to 2+2 right, and get it out of the door. > > Philip > From owner-zeroconf@merit.edu Wed Dec 17 18:45: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 SAA14336 for ; Wed, 17 Dec 2003 18:45:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7090491289; Wed, 17 Dec 2003 18:45:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C1649128A; Wed, 17 Dec 2003 18:45:29 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3640D91289 for ; Wed, 17 Dec 2003 18:45:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 22B695DDD2; Wed, 17 Dec 2003 18:45:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from server21.ukservers.net (server21.ukservers.net [217.10.138.198]) by segue.merit.edu (Postfix) with ESMTP id 4B58E5DD9F for ; Wed, 17 Dec 2003 18:45:27 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server21.ukservers.net (Postfix) with ESMTP id A392F39C289; Wed, 17 Dec 2003 23:45:28 +0000 (GMT) Message-ID: <021e01c3c4f7$da8c2650$131010ac@aldebaran> From: "Philip Nye" Cc: "Robert Elz" , "Erik Guttman" , , "Thomas Narten" References: <1071610036.12327.17.camel@hades> <3FDDB249.3080901@sun.com> <12600.1071655636@munnari.OZ.AU> <01f301c3c4e1$638370b0$131010ac@aldebaran> <1071697918.15146.45.camel@hades> Subject: Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs Date: Wed, 17 Dec 2003 23:45:29 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: quoted-printable > From: "Mika Liljeberg" >=20 > The feedback gathered from > users of data services in GSM/GPRS networks is overwhelming on this. A > user expects to see results within a few seconds of the first button > press. Address configuration is just one of the initial steps that = needs > to take place in a typical use case. I must completely misunderstand what GPRS is all about if users are = depending to any significant extent on IPv4 LL addresses. Philip From owner-zeroconf@merit.edu Wed Dec 17 19:07: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 TAA14980 for ; Wed, 17 Dec 2003 19:07:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 06B6C9128A; Wed, 17 Dec 2003 19:07:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C45059128B; Wed, 17 Dec 2003 19:07:01 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BA7719128A for ; Wed, 17 Dec 2003 19:07:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id A1CBE5DE12; Wed, 17 Dec 2003 19:07:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from hades.pp.htv.fi (cs78147060.pp.htv.fi [62.78.147.60]) by segue.merit.edu (Postfix) with ESMTP id CA0075DE25 for ; Wed, 17 Dec 2003 19:06:59 -0500 (EST) Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) with ESMTP id hBI08n94017959; Thu, 18 Dec 2003 02:08:49 +0200 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) id hBI08jBk017958; Thu, 18 Dec 2003 02:08:45 +0200 Subject: Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs From: Mika Liljeberg To: Philip Nye Cc: Robert Elz , Erik Guttman , zeroconf@merit.edu, Thomas Narten In-Reply-To: <021e01c3c4f7$da8c2650$131010ac@aldebaran> References: <1071610036.12327.17.camel@hades> <3FDDB249.3080901@sun.com> <12600.1071655636@munnari.OZ.AU> <01f301c3c4e1$638370b0$131010ac@aldebaran> <1071697918.15146.45.camel@hades> <021e01c3c4f7$da8c2650$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1071706125.17659.6.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 18 Dec 2003 02:08:45 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-12-18 at 01:45, Philip Nye wrote: > > From: "Mika Liljeberg" > > > > The feedback gathered from > > users of data services in GSM/GPRS networks is overwhelming on this. A > > user expects to see results within a few seconds of the first button > > press. Address configuration is just one of the initial steps that needs > > to take place in a typical use case. > > I must completely misunderstand what GPRS is all about if users are depending to any significant extent on IPv4 LL addresses. No, you just misunderstood my comment. I was using GSM/GPRS as an example of where address configuration time for a handset is a usability issue. We've found that it has to be squeezed down to 2..3 seconds in order to make end users happy. v4ll configuration in handsets has to meet the same user expectations. MikaL From owner-zeroconf@merit.edu Thu Dec 18 02:43: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 CAA09688 for ; Thu, 18 Dec 2003 02:43:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B1E349128E; Thu, 18 Dec 2003 02:43:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 816FA91290; Thu, 18 Dec 2003 02:43:21 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7FB1F9128E for ; Thu, 18 Dec 2003 02:43:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6CD165DE2B; Thu, 18 Dec 2003 02:43:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 18B865DE27 for ; Thu, 18 Dec 2003 02:43:20 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hBI7hCAR024980; Thu, 18 Dec 2003 00:43:13 -0700 (MST) Received: from sun.com (vpn-129-156-96-18.EMEA.Sun.COM [129.156.96.18]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hBI7h7m17637; Thu, 18 Dec 2003 08:43:07 +0100 (MET) Message-ID: <3FE15990.5070309@sun.com> Date: Thu, 18 Dec 2003 08:38:56 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Mika Liljeberg Cc: Philip Nye , Robert Elz , zeroconf@merit.edu, Thomas Narten , christian.huitema@microsoft.com, aboba@internaut.com Subject: Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs References: <1071610036.12327.17.camel@hades> <3FDDB249.3080901@sun.com> <12600.1071655636@munnari.OZ.AU> <01f301c3c4e1$638370b0$131010ac@aldebaran> <1071697918.15146.45.camel@hades> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The fundamental assumption which leads us to long time outs is the required support for link-layer technologies which "have a round-trip latency of at most one second." If this latency were redefined as 375 ms (just to make up a value), then three retries would take 1.875-3 seconds. The questions (for you experts out there) are - why are we required to support link-layer technologies with a latency of at most one second instead of a lower value? - what is the lowest value we could choose and still support most (if not all) link-layer technologies? Which technologies can expose hosts to several hundred millisecond latencies? - are there other considerations (such as set up time for network infrastructure) before ARP requests and replies would propogate to hosts? (Does 5-8 seconds of start up work better for these than would, say, 1.875-3 seconds would?) Thanks, Erik Mika Liljeberg wrote: > I see what you and kre are saying, but I don't buy the number game. The > fact remains that three is a wholly arbitrary number and likely to be > wrong for most environments. Who is to say one probe is not enough? It > all depends on the link error rate and the number of nodes supported by > the link. > > For instance, a Bluetooth PAN piconet (radio range 10 meters) supports a > maximum of 7 nodes and the link layer is reliable. Three probes is > completely unnecessary and at the same time constitute a usability > problem, since many of the use cases involve quick ad-hoc interactions. > > My objection to three probes is as I have stated before: 5..8 seconds is > too long from the usability point of view. The feedback gathered from > users of data services in GSM/GPRS networks is overwhelming on this. A > user expects to see results within a few seconds of the first button > press. Address configuration is just one of the initial steps that needs > to take place in a typical use case. > > I think we can pretty well start out with the assumption that v4LL > address collisions will sometimes happen. What could be spelled out is, > what is an acceptable probability for failing to detect one? Knowing > that, the number of probe retransmissions can be adjusted accordingly > for a particular environment. IPv6 allows adjusting the number of probes > transmitted. Why should v4LL be any different? > > As for it being too late, the last time I raised this point no-one > seemed inclined to discuss it. I must say two responses are a distinct > improvement. > > MikaL > > On Wed, 2003-12-17 at 23:04, Philip Nye wrote: > >>>From: "Robert Elz" >>> >>> | Instead of trying to figure out how long it takes to send three probes, >>> | I would like to step back a little and ask the question WHY exactly do >>> | we have to send THREE PROBES? What exactly in v4LL necessitates sending >>> | three DAD probes when IPv6 can get away with only one? >>> >>>v6 has 64 bits of address space, it is incredibly unlikely that something >>>doing random address assignment (which is what is relevant here) is ever >>>going to clash with something else - so one check, no reply, and all is OK. >>> >>>v4LL has only 16 bits to play in (slightly less because of the exclusions of >>>the first and last /24's from contention) - the birthday paradox tells us >>>that with perfect random assignments we're going to get a clash as soon as >>>the number of hosts on the link gets to around 256 (2^8 being sqrt(2^16) which >>>is a very rough approximation of the point where probability goes > 50%). >>> >>>256 hosts is not at all implausible on a link (2^32 is), so v4LL has to >>>actually expect to get duplicates, where in v6 they are only likely to occur >>>due to human stupidity. v4LL simply has to try harder to detect those >>>duplicates. >> >>In addition to this, it is probably the case that IPv4 systems do not cope so well as IPv6 with clashes and changing addresses, so having a higher confidence level that the address you have picked is unique on the link is probably going to make life that bit easier for the user. >> >>The final and probably strongest argument against Mika's suggestion is that it is way too late in the process to be re-opening this algorithm at this point. Unless you can show that three probes will break where one won't (which I doubt) then we should tidy up the arithmetic so at least we get the answer to 2+2 right, and get it out of the door. >> >>Philip >> > -- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Erik Guttman - N1 Manageability - Sun Microsystems cell: +49 172 865 5497 - time zone: CET (GMT+1) From owner-zeroconf@merit.edu Thu Dec 18 04:19: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 EAA12265 for ; Thu, 18 Dec 2003 04:19:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B459191224; Thu, 18 Dec 2003 04:19:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A17B91294; Thu, 18 Dec 2003 04:19:15 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4F68991224 for ; Thu, 18 Dec 2003 04:19:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3D0EC5DDCB; Thu, 18 Dec 2003 04:19:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id AE8F05DDC2 for ; Thu, 18 Dec 2003 04:19:13 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hBI9JAAR001758; Thu, 18 Dec 2003 02:19:11 -0700 (MST) Received: from sun.com (vpn-129-156-96-18.EMEA.Sun.COM [129.156.96.18]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hBI9J6m22949; Thu, 18 Dec 2003 10:19:07 +0100 (MET) Message-ID: <3FE17010.3040708@sun.com> Date: Thu, 18 Dec 2003 10:14:56 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Mika Liljeberg Cc: Robert Elz , zeroconf@merit.edu, Thomas Narten Subject: Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs References: <1071610036.12327.17.camel@hades> <3FDDB249.3080901@sun.com> <12600.1071655636@munnari.OZ.AU> <1071687260.15146.3.camel@hades> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mika, Please see http://www.drizzle.com/~aboba/ZEROCONF/ll31.html This issue was accepted. It argues that 3 tries are needed for reliability guarantees. It states that IPv6 uses 1 second timeouts and suggests we do the same without motivating that choice. Retries are needed for robustness, he asserts, because there is a real, though small collision chance on 802 technologies. If there are certain technologies without collisions or with a lower maximum latency, why not create an additional document entitled "Timer settings for IPv4 Link Local Autoconfiguration on Foo"? As discussed previously in this WG there are problems with this approach. 1 Foo may be bridged to a slower, collision-prone link-layer. We cannot assume interoperation will succeed between the two links using values appropriate to Foo but inappropriate to 802. 2 IETF standards have not specified different timer settings for different link-layers to my knowledge. 3 Until your specific example of bluetooth, no one had submitted specific examples of link-layer technology which would require special treatment. I still think the best way forward is to have knowledgeable folks inform us as to the maximum latency expectations for link-layers we are concerned about. I will contact folks involved with PILC for their input. Regards, Erik Mika Liljeberg wrote: > On Wed, 2003-12-17 at 12:07, Robert Elz wrote: > >> | Instead of trying to figure out how long it takes to send three probes, >> | I would like to step back a little and ask the question WHY exactly do >> | we have to send THREE PROBES? What exactly in v4LL necessitates sending >> | three DAD probes when IPv6 can get away with only one? > > >>v4LL has only 16 bits to play in (slightly less because of the exclusions of >>the first and last /24's from contention) - the birthday paradox tells us >>that with perfect random assignments we're going to get a clash as soon as >>the number of hosts on the link gets to around 256 (2^8 being sqrt(2^16) which >>is a very rough approximation of the point where probability goes > 50%). > > > You're missing the point. The spec is telling us to probe the SAME > ADDRESS three times. The retransmissions might make sense if the link > has a high loss probability, but address collision probability has > nothing to do with it. > > Please read this bit again: > > Here's my proposal (three fold): > 1. Let's specify DAD probe in the same way as in IPv6, defaulting > to a single probe packet > 2. In the event of a conflict (slightly more probable with v4LL > compared to IPv6), allow the node to select a new v4LL and retry > up to, e.g., AddrSelectRetries times > 3. Let's get rid of the text describing shorter timeouts. If we > default to a single probe, DAD only takes 1..2 seconds (with a > high probability). That is good enough from the usability point > of view. > > Regards, > > MikaL From owner-zeroconf@merit.edu Thu Dec 18 04:27: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 EAA12406 for ; Thu, 18 Dec 2003 04:27:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 83E2A91294; Thu, 18 Dec 2003 04:27:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F67191295; Thu, 18 Dec 2003 04:27:05 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2B24891294 for ; Thu, 18 Dec 2003 04:27:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0EED65DE1D; Thu, 18 Dec 2003 04:27:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtp107.mail.sc5.yahoo.com (smtp107.mail.sc5.yahoo.com [66.163.169.227]) by segue.merit.edu (Postfix) with SMTP id 4B3D15DDD2 for ; Thu, 18 Dec 2003 04:27:03 -0500 (EST) Received: from unknown (HELO jhu.edu) (uberfoot@69.3.93.122 with plain) by smtp107.mail.sc5.yahoo.com with SMTP; 18 Dec 2003 09:27:02 -0000 Message-ID: <3FE172D7.7090604@jhu.edu> Date: Thu, 18 Dec 2003 01:26:47 -0800 From: Bill Rees Reply-To: breeze@jhu.edu User-Agent: Mozilla Thunderbird 0.5a (20031211) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Guttman Cc: Mika Liljeberg , Philip Nye , Robert Elz , zeroconf@merit.edu, Thomas Narten , christian.huitema@microsoft.com, aboba@internaut.com Subject: Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs References: <1071610036.12327.17.camel@hades> <3FDDB249.3080901@sun.com> <12600.1071655636@munnari.OZ.AU> <01f301c3c4e1$638370b0$131010ac@aldebaran> <1071697918.15146.45.camel@hades> <3FE15990.5070309@sun.com> In-Reply-To: <3FE15990.5070309@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit As I understand this thread, the latency comes from waiting for a spanning tree routine to run which to me implies a wan, no? So a bit off kilter here, what is the likelihood that the llv4 situation occurs in such a congested, logically disparate locations? Is it likely that linklocal will show up in such an environment? Given all the discussion surrounding moving off of the llv4 address as quickly as possible, even in a congested environment what is the likelihood that the number of llv4 devices will exist on the network at the same time isd 2 or more? So in summary I'm wondering what the mean lifetime of a llv4 address is, what the probability of two llv4 users occurring at the same time is, and the likelihood they'll pick the same address. The number of probes required to uniqueify a llv4 address is in here somewhere I just am beginning to doubt the likelihood of a collision. Bill Rees Erik Guttman wrote: > The fundamental assumption which leads us to long time outs is the > required support for link-layer technologies which "have a round-trip > latency of at most one second." > > > Mika Liljeberg wrote: > >> I see what you and kre are saying, but I don't buy the number game. The >> fact remains that three is a wholly arbitrary number and likely to be >> wrong for most environments. Who is to say one probe is not enough? It >> all depends on the link error rate and the number of nodes supported by >> the link. >> >> On Wed, 2003-12-17 at 23:04, Philip Nye wrote: >> >>>> From: "Robert Elz" >>>> >>>> | Instead of trying to figure out how long it takes to send three >>>> probes, >>>> | I would like to step back a little and ask the question WHY >>>> exactly do >>>> | we have to send THREE PROBES? What exactly in v4LL necessitates >>>> sending >>>> | three DAD probes when IPv6 can get away with only one? >>>> >>>> v6 has 64 bits of address space, it is incredibly unlikely that >>>> something >>>> doing random address assignment (which is what is relevant here) is >>>> ever >>>> going to clash with something else - so one check, no reply, and >>>> all is OK. >>>> >>>> v4LL has only 16 bits to play in (slightly less because of the >>>> exclusions of >>>> the first and last /24's from contention) - the birthday paradox >>>> tells us >>>> that with perfect random assignments we're going to get a clash as >>>> soon as >>>> the number of hosts on the link gets to around 256 (2^8 being >>>> sqrt(2^16) which >>>> is a very rough approximation of the point where probability goes > >>>> 50%). >>>> >>>> 256 hosts is not at all implausible on a link (2^32 is), so v4LL >>>> has to >>>> actually expect to get duplicates, where in v6 they are only likely >>>> to occur >>>> due to human stupidity. v4LL simply has to try harder to detect >>>> those >>>> duplicates. >>> >>> >>> In addition to this, it is probably the case that IPv4 systems do >>> not cope so well as IPv6 with clashes and changing addresses, so >>> having a higher confidence level that the address you have picked is >>> unique on the link is probably going to make life that bit easier >>> for the user. >>> >>> The final and probably strongest argument against Mika's suggestion >>> is that it is way too late in the process to be re-opening this >>> algorithm at this point. Unless you can show that three probes will >>> break where one won't (which I doubt) then we should tidy up the >>> arithmetic so at least we get the answer to 2+2 right, and get it >>> out of the door. >>> >>> Philip >>> >> > > From owner-zeroconf@merit.edu Thu Dec 18 04:40:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13026 for ; Thu, 18 Dec 2003 04:40:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BB19191296; Thu, 18 Dec 2003 04:40:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90C3991297; Thu, 18 Dec 2003 04:40:08 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 686D191296 for ; Thu, 18 Dec 2003 04:40:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 539805DE54; Thu, 18 Dec 2003 04:40:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from server21.ukservers.net (server21.ukservers.net [217.10.138.198]) by segue.merit.edu (Postfix) with ESMTP id C5D295DE1F for ; Thu, 18 Dec 2003 04:40:06 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server21.ukservers.net (Postfix) with ESMTP id B280039C31C; Thu, 18 Dec 2003 09:40:06 +0000 (GMT) Message-ID: <024c01c3c54a$edd273b0$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , "Ralph Droms" Cc: References: <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer Date: Thu, 18 Dec 2003 09:40:09 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: quoted-printable Ralph's approach seems reasonable and I think improves the draft. = However, I am concerned that as written it does not allow operation with = stacks which only allow a single address per interface. Philip ----- Original Message -----=20 From: "Ralph Droms" To: "Erik Guttman" Cc: Sent: Tuesday, December 16, 2003 5:00 PM Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 = to be clearer > In response to this issue, I suggest deleting subsections 1.7 and = 2.11, and=20 > inserting the following text as the last subsection of section 1 (in=20 > particular, to come after subsection 1.9. "Communication with Routable = > Addresses"): >=20 >=20 > 1.x When to configure a Link-Local IPv4 address on an interface >=20 > Having addresses of multiple different scopes assigned to an > interface, with no adequate way to determine in what circumstances > each address should be used, leads to complexity for applications > and confusion for users. A host with an address on a link can > communicate with all other devices on that link, whether those > devices use Link-Local addresses, or routable addresses. For = these > reasons, a host SHOULD NOT have both a valid routable address and = a > Link-Local IPv4 address configure on the same interface. >=20 > A routable address is any address that is: >=20 > * a unicast address > * not a loopback address > * not in the 169..2.54/32 subnet reserved for Link-Local IPv4 > addresses >=20 > A "valid routable address" is a routable address that passes the > reachability test described in section 2 of "Detection of Network > Attachment (DNA) in IPv4" [DNAv4]. >=20 > The assignment and use of a Link-Local IPv4 address on an = interface > is based solely on the state of the interface, and is independent > of any other protocols such as DHCP or RADIUS. A host MUST NOT > alter its behavior and use of other protocols such as DHCP and > RADIUS because the host has assigned a Link-Local IPv4 address to > an interface. >=20 > When an interface has a valid routable address configured on an > interface, the host SHOULD NOT also assign a Link-Local IPv4 > address to that interface. >=20 > If a host finds that an interface that was previous configured = with > a Link-Local IPv4 address is now configured with a valid routable > address, the host MUST always use the routable address when > initiating new communications, and MUST cease advertising the > availability of the Link-Local IPv4 address through whatever > mechanisms that address had been made known to others. The host > SHOULD continue to use the Link-Local IPv4 address for > communications underway when the routable address was configured, > and MAY continue to accept new communications addressed to the > Link-Local IPv4 address. Ways in which a valid routable address > might be configured for the interface include: >=20 > * Manual configuration > * Address assignment through RADIUS or DHCP > * Roaming of the host to a network on which a routable address > assigned to the interface is valid >=20 > If a host finds that an interface that was previously configured > with a valid routable address no longer has a valid routable > address, the host MAY identify a usable Link-Local IPv4 address = (as > described in section 2) and assign that address to the interface. > Ways in which a valid routable address might no longer be assigned > to an interface include: >=20 > * Removal of the address from the interface through manual > configuration > * Expiration of the lease on the address assigned through DHCP > * Roaming of the host to a new network on which the address is no > longer valid. >=20 > Further discussion of the issues in detection of transient = failures > and the use of DHCP in response to network attachment failure is > provided in "Detection of Network Attachment (DNA) in IPv4".=20 >=20 > From owner-zeroconf@merit.edu Thu Dec 18 04:49: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 EAA13250 for ; Thu, 18 Dec 2003 04:49:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 96C4A91297; Thu, 18 Dec 2003 04:49:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6650791298; Thu, 18 Dec 2003 04:49:07 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D7D8691297 for ; Thu, 18 Dec 2003 04:49:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id B504B5DDCB; Thu, 18 Dec 2003 04:49:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from server21.ukservers.net (server21.ukservers.net [217.10.138.198]) by segue.merit.edu (Postfix) with ESMTP id 5AADC5DDA7 for ; Thu, 18 Dec 2003 04:49:00 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server21.ukservers.net (Postfix) with ESMTP id 62B8C39C303; Thu, 18 Dec 2003 09:48:57 +0000 (GMT) Message-ID: <025701c3c54c$2a023540$131010ac@aldebaran> From: "Philip Nye" To: "Alex Karahalios" , "Zeroconf" Cc: "Ralph Droms" References: <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> <4.3.2.7.2.20031216122752.036d3688@flask.cisco.com> <26D0BD60-3005-11D8-899C-00039377AD70@Outersoft.com> Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer Date: Thu, 18 Dec 2003 09:49:00 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: quoted-printable Alex, Provided they are on the same link, the LL device _can_ communicate with = the printer just so long as the printer has the necessary route for the = 169.254.x.x network. This has been the preferred mode of operation for = several successive drafts now. Communication between LL and routable = hosts on the same link is perfectly possible. I would expect a printer using mDNS to configure the necessary route = automatically. Getting the IPv4LL draft to RFC status would make this = even more likely! Philip ----- Original Message -----=20 From: "Alex Karahalios" To: "Zeroconf" Cc: "Ralph Droms" Sent: Tuesday, December 16, 2003 8:19 PM Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 = to be clearer > Ralph, >=20 > Yes, I understand this, but I think the phrase you are proposing, a=20 > host "MUST cease advertising the availability of the Link-Local IPv4=20 > address through whatever mechanisms that address had been made known = to=20 > others," will make it such that a new LL IPv4 device will not be able=20 > to interoperate on the network. >=20 > Take the case of a printer using mDNS, for example. A new device would = > only get routable address information from the printer, but the new=20 > device is only configured for LL IPv4 and thus is shut out of=20 > communicating with the printer. >=20 > Alex Karahalios >=20 > On Dec 16, 2003, at 11:09 AM, Ralph Droms wrote: >=20 > > Well, section 1.9 of draft-ietf-zeroconf-ipv4-linklocal-10.txt, > > "Communication with Routable Addresses", describes how two devices = can > > communicate in the case you describe, where one device has a = routable > > address and one device has a Link-Local IPv4 address. > > > > Of course, there's a difference between "finding" and "communicating = > > with". > > "Finding" printers is out of scope for Link-Local IPv4, so > > draft-ietf-zeroconf-ipv4-linklocal-10.txt doesn't address how the=20 > > computer > > determines the printer's address, regardless of whether the printer = is=20 > > using > > a routable address or a Link-Local IPv4 address. > > > > - Ralph > > > > At 10:25 AM 12/16/2003 -0700, Alex Karahalios wrote: > >> Given the below text which specifies the a host "MUST cease=20 > >> advertising the availability of the Link-Local IPv4 address", could = > >> some explain how I would be able to make use of LL IPv4 addressing = in=20 > >> the following circumstances: > >> > >> Let's say a printer stops advertising LL IPv4 addresses because it=20 > >> obtains a DHCP address. A new computer is introduced into the = network=20 > >> that wants to print, but it cannot obtain a routable address, so it = > >> configures a LL IPv4 address. How is the new computer suppose to = find=20 > >> the printer if the printer has stopped advertising its LL address? > >> > >> I've asked a similar version of this question before and was told=20 > >> that there are provisions in draft to address this, but the follow=20 > >> text preclude this. > >> > >> Thanks, > >> > >> Alex Karahalios > >> > >> On Dec 16, 2003, at 10:00 AM, Ralph Droms wrote: > >> > >>> If a host finds that an interface that was previous configured=20 > >>> with > >>> a Link-Local IPv4 address is now configured with a valid = routable > >>> address, the host MUST always use the routable address when > >>> initiating new communications, and MUST cease advertising the > >>> availability of the Link-Local IPv4 address through whatever > >>> mechanisms that address had been made known to others. The = host > >>> SHOULD continue to use the Link-Local IPv4 address for > >>> communications underway when the routable address was = configured, > >>> and MAY continue to accept new communications addressed to the > >>> Link-Local IPv4 address. Ways in which a valid routable = address > >>> might be configured for the interface include: > > >=20 > From owner-zeroconf@merit.edu Thu Dec 18 05:09: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 FAA13858 for ; Thu, 18 Dec 2003 05:09:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3D3099129D; Thu, 18 Dec 2003 05:09:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08B5391298; Thu, 18 Dec 2003 05:09:05 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A826A9129D for ; Thu, 18 Dec 2003 05:09:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0C4245DE0A; Thu, 18 Dec 2003 05:09:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from server21.ukservers.net (server21.ukservers.net [217.10.138.198]) by segue.merit.edu (Postfix) with ESMTP id 7B8005DDCB for ; Thu, 18 Dec 2003 05:09:01 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server21.ukservers.net (Postfix) with ESMTP id 6C26139C132; Thu, 18 Dec 2003 10:09:01 +0000 (GMT) Message-ID: <02d301c3c54e$f7a93b90$131010ac@aldebaran> From: "Philip Nye" To: "Mika Liljeberg" , "Zeroconf Working Group" References: <1071610036.12327.17.camel@hades> <3FDDB249.3080901@sun.com> <12600.1071655636@munnari.OZ.AU> <01f301c3c4e1$638370b0$131010ac@aldebaran> <1071697918.15146.45.camel@hades> Subject: Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs Date: Thu, 18 Dec 2003 10:09:04 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: quoted-printable > From: "Mika Liljeberg" > I see what you and kre are saying, but I don't buy the number game. = The > fact remains that three is a wholly arbitrary number and likely to be > wrong for most environments. Who is to say one probe is not enough? It > all depends on the link error rate and the number of nodes supported = by > the link. >=20 > For instance, a Bluetooth PAN piconet (radio range 10 meters) supports = a > maximum of 7 nodes and the link layer is reliable. Three probes is > completely unnecessary and at the same time constitute a usability > problem, since many of the use cases involve quick ad-hoc = interactions. Link layer reliability is not the issue. Experience shows that in many = networks the single most common cause of lost packets is busy hosts = dropping them on input. A reliable link layer just ensures that both = hosts know that the packet was received. There is no guarantee that a = packet delivered is a packet processed. Either the new host sending the = ARP probe, or the holder of a conflicting address could miss a packet = this way. Does Bluetooth's link layer reliability extend to broadcast probes? I would accept that the number of probes could be a symbolic parameter = NUM_PROBES rather than a hard coded number, but for this spec = NUM_PROBES=3D3 is appropriate. A subsequent document for Bluetooth = piconets (or whatever), could then specify NUM_PROBES=3D0 or 666 or = anything appropriate. Philip From owner-zeroconf@merit.edu Thu Dec 18 05:26:32 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14430 for ; Thu, 18 Dec 2003 05:26:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A76CD91298; Thu, 18 Dec 2003 05:26:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B01291299; Thu, 18 Dec 2003 05:26:24 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7334291298 for ; Thu, 18 Dec 2003 05:26:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 607BB5DE2D; Thu, 18 Dec 2003 05:26:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from server21.ukservers.net (server21.ukservers.net [217.10.138.198]) by segue.merit.edu (Postfix) with ESMTP id 263C25DE16 for ; Thu, 18 Dec 2003 05:26:23 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by server21.ukservers.net (Postfix) with ESMTP id A1E6739C05F; Thu, 18 Dec 2003 10:26:23 +0000 (GMT) Message-ID: <033b01c3c551$64eb7040$131010ac@aldebaran> From: "Philip Nye" To: , "Erik Guttman" Cc: "Mika Liljeberg" , "Robert Elz" , , "Thomas Narten" , , References: <1071610036.12327.17.camel@hades> <3FDDB249.3080901@sun.com> <12600.1071655636@munnari.OZ.AU> <01f301c3c4e1$638370b0$131010ac@aldebaran> <1071697918.15146.45.camel@hades> <3FE15990.5070309@sun.com> <3FE172D7.7090604@jhu.edu> Subject: Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs Date: Thu, 18 Dec 2003 10:26:26 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: quoted-printable > From: "Bill Rees" >=20 > As I understand this thread, the latency comes from waiting for a=20 > spanning tree routine to run which to me implies a wan, no? It seems that spanning tree can take quite a bit longer so the = difference between 2 and 8 seconds is little help. > So a bit=20 > off kilter here, what is the likelihood that the llv4 situation occurs = > in such a congested, logically disparate locations? Is it likely that = > linklocal will show up in such an environment? Given all the = discussion=20 > surrounding moving off of the llv4 address as quickly as possible, = even=20 > in a congested environment what is the likelihood that the number of=20 > llv4 devices will exist on the network at the same time isd 2 or more? The answer to this was discussed a long time ago. If the network has a = DHCP server, which refuses to hand you an address or if it is primarily = a statically configured network, you can still go ahead and configure a = LL address and use it to whatever extent it works (e.g. to talk to a = printer or another ad-hoc user). This could easily apply on a large = multiply bridged network. Philip From owner-zeroconf@merit.edu Thu Dec 18 11:57: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 LAA02517 for ; Thu, 18 Dec 2003 11:57:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 40151912A6; Thu, 18 Dec 2003 11:57:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1530912A5; Thu, 18 Dec 2003 11:57: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 ACC88912A2 for ; Thu, 18 Dec 2003 11:57:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8D8B25DE53; Thu, 18 Dec 2003 11:57:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by segue.merit.edu (Postfix) with ESMTP id 483B65DE4D for ; Thu, 18 Dec 2003 11:57:11 -0500 (EST) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 Dec 2003 09:00:54 +0000 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBIGv7BN028859; Thu, 18 Dec 2003 08:57:08 -0800 (PST) Received: from rdroms-w2k01.cisco.com (dhcp-64-100-227-72.cisco.com [64.100.227.72]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AET55746; Thu, 18 Dec 2003 11:57:02 -0500 (EST) Message-Id: <4.3.2.7.2.20031218115424.01e38628@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Dec 2003 11:56:59 -0500 To: "Philip Nye" From: Ralph Droms Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer Cc: "Erik Guttman" , In-Reply-To: <024c01c3c54a$edd273b0$131010ac@aldebaran> References: <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Philip - I think I surrounded the text that describes using multiple addresses on an interface with conditionals (SHOULD, MAY) so that a stack that only allows a single address on an interface can still be compliant with the spec. If you don't agree, can you point out the text that requires multiple addresses on an interface and/or suggest new text? - Ralph At 09:40 AM 12/18/2003 +0000, Philip Nye wrote: >Ralph's approach seems reasonable and I think improves the draft. However, >I am concerned that as written it does not allow operation with stacks >which only allow a single address per interface. > >Philip > >----- Original Message ----- >From: "Ralph Droms" >To: "Erik Guttman" >Cc: >Sent: Tuesday, December 16, 2003 5:00 PM >Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to >be clearer > > > > In response to this issue, I suggest deleting subsections 1.7 and 2.11, > and > > inserting the following text as the last subsection of section 1 (in > > particular, to come after subsection 1.9. "Communication with Routable > > Addresses"): > > > > > > 1.x When to configure a Link-Local IPv4 address on an interface > > > > Having addresses of multiple different scopes assigned to an > > interface, with no adequate way to determine in what circumstances > > each address should be used, leads to complexity for applications > > and confusion for users. A host with an address on a link can > > communicate with all other devices on that link, whether those > > devices use Link-Local addresses, or routable addresses. For these > > reasons, a host SHOULD NOT have both a valid routable address and a > > Link-Local IPv4 address configure on the same interface. > > > > A routable address is any address that is: > > > > * a unicast address > > * not a loopback address > > * not in the 169..2.54/32 subnet reserved for Link-Local IPv4 > > addresses > > > > A "valid routable address" is a routable address that passes the > > reachability test described in section 2 of "Detection of Network > > Attachment (DNA) in IPv4" [DNAv4]. > > > > The assignment and use of a Link-Local IPv4 address on an interface > > is based solely on the state of the interface, and is independent > > of any other protocols such as DHCP or RADIUS. A host MUST NOT > > alter its behavior and use of other protocols such as DHCP and > > RADIUS because the host has assigned a Link-Local IPv4 address to > > an interface. > > > > When an interface has a valid routable address configured on an > > interface, the host SHOULD NOT also assign a Link-Local IPv4 > > address to that interface. > > > > If a host finds that an interface that was previous configured with > > a Link-Local IPv4 address is now configured with a valid routable > > address, the host MUST always use the routable address when > > initiating new communications, and MUST cease advertising the > > availability of the Link-Local IPv4 address through whatever > > mechanisms that address had been made known to others. The host > > SHOULD continue to use the Link-Local IPv4 address for > > communications underway when the routable address was configured, > > and MAY continue to accept new communications addressed to the > > Link-Local IPv4 address. Ways in which a valid routable address > > might be configured for the interface include: > > > > * Manual configuration > > * Address assignment through RADIUS or DHCP > > * Roaming of the host to a network on which a routable address > > assigned to the interface is valid > > > > If a host finds that an interface that was previously configured > > with a valid routable address no longer has a valid routable > > address, the host MAY identify a usable Link-Local IPv4 address (as > > described in section 2) and assign that address to the interface. > > Ways in which a valid routable address might no longer be assigned > > to an interface include: > > > > * Removal of the address from the interface through manual > > configuration > > * Expiration of the lease on the address assigned through DHCP > > * Roaming of the host to a new network on which the address is no > > longer valid. > > > > Further discussion of the issues in detection of transient failures > > and the use of DHCP in response to network attachment failure is > > provided in "Detection of Network Attachment (DNA) in IPv4". > > > > From owner-zeroconf@merit.edu Thu Dec 18 13:08:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06359 for ; Thu, 18 Dec 2003 13:08:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 77F9E912AB; Thu, 18 Dec 2003 13:08:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4996F912AC; Thu, 18 Dec 2003 13:08:33 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E02B912AB for ; Thu, 18 Dec 2003 13:08:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5C1415DDE9; Thu, 18 Dec 2003 13:08:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from hades.pp.htv.fi (cs78147060.pp.htv.fi [62.78.147.60]) by segue.merit.edu (Postfix) with ESMTP id 78C8F5DD92 for ; Thu, 18 Dec 2003 13:08:30 -0500 (EST) Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) with ESMTP id hBIIAc94020936; Thu, 18 Dec 2003 20:10:39 +0200 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.10/8.12.10/Debian-5) id hBIIAbMN020935; Thu, 18 Dec 2003 20:10:37 +0200 Subject: Re: WG ACTION: 1 week to discuss [LL37] Aggressive Time-outs From: Mika Liljeberg To: Philip Nye Cc: Zeroconf Working Group In-Reply-To: <02d301c3c54e$f7a93b90$131010ac@aldebaran> References: <1071610036.12327.17.camel@hades> <3FDDB249.3080901@sun.com> <12600.1071655636@munnari.OZ.AU> <01f301c3c4e1$638370b0$131010ac@aldebaran> <1071697918.15146.45.camel@hades> <02d301c3c54e$f7a93b90$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1071771037.18065.8.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 18 Dec 2003 20:10:37 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-12-18 at 12:09, Philip Nye wrote: > I would accept that the number of probes could be a symbolic parameter > NUM_PROBES rather than a hard coded number, but for this spec > NUM_PROBES=3 is appropriate. I would agree to that. I'm fine with a default of 3, as long as the number of probes can be adjusted where another value makes more sense for a particular environment. > A subsequent document for Bluetooth piconets (or whatever), could > then specify NUM_PROBES=0 or 666 or anything appropriate. I doubt a separate document for each possible environment is feasible. Just make NUM_PROBES a configurable system parameter, recommend a default of 3, and leave it at that. Regards, MikaL From owner-zeroconf@merit.edu Thu Dec 18 16:06:50 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18895 for ; Thu, 18 Dec 2003 16:06:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 48FD3912AB; Thu, 18 Dec 2003 16:06:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 188B4912B2; Thu, 18 Dec 2003 16:06:40 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 20F39912AB for ; Thu, 18 Dec 2003 16:06:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0F30E5DDEE; Thu, 18 Dec 2003 16:06:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from home.karahalios.org (dsl093-162-009.tus1.dsl.speakeasy.net [66.93.162.9]) by segue.merit.edu (Postfix) with ESMTP id E9B415DDC2 for ; Thu, 18 Dec 2003 16:06:37 -0500 (EST) Received: from [192.168.2.2] (usr2.Karahalios.org [192.168.2.2]) (authenticated) by home.karahalios.org (8.11.1/8.10.1) with ESMTP id hBIL6aL03167; Thu, 18 Dec 2003 14:06:36 -0700 In-Reply-To: <025701c3c54c$2a023540$131010ac@aldebaran> References: <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> <4.3.2.7.2.20031216122752.036d3688@flask.cisco.com> <26D0BD60-3005-11D8-899C-00039377AD70@Outersoft.com> <025701c3c54c$2a023540$131010ac@aldebaran> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <105A50E0-319E-11D8-870A-00039377AD70@Outersoft.com> Content-Transfer-Encoding: 7bit Cc: Zeroconf From: Alex Karahalios Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer Date: Thu, 18 Dec 2003 14:06:35 -0700 To: "Philip Nye" X-Mailer: Apple Mail (2.609) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Philip, Yes, this works. But what I am trying to address is that, due to the wording of section 1.7, the mDNS printer will no longer broadcast the LL address once it obtains a routable address and thus the LL only device will never know that the printer exists and thus cannot communicate with it. That is why the phrase "the host MUST always use the routable address when initiating new communications, and MUST cease advertising the availability of the Link-Local IPv4 address through whatever mechanisms that address had been made known to others" is not acceptable since it precludes LL only devices from participating in the network. Alex Karahalios On Dec 18, 2003, at 2:49 AM, Philip Nye wrote: > Provided they are on the same link, the LL device _can_ communicate > with the printer just so long as the printer has the necessary route > for the 169.254.x.x network. This has been the preferred mode of > operation for several successive drafts now. Communication between LL > and routable hosts on the same link is perfectly possible. > > I would expect a printer using mDNS to configure the necessary route > automatically. Getting the IPv4LL draft to RFC status would make this > even more likely! > From owner-zeroconf@merit.edu Fri Dec 19 08:44: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 IAA08892 for ; Fri, 19 Dec 2003 08:44:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1A6F391241; Fri, 19 Dec 2003 08:44:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC42A91247; Fri, 19 Dec 2003 08:44:47 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EA99E91241 for ; Fri, 19 Dec 2003 08:44:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id D3E365DDFD; Fri, 19 Dec 2003 08:44:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 83C205DE26 for ; Fri, 19 Dec 2003 08:44:46 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hBJDif0H014442; Fri, 19 Dec 2003 05:44:42 -0800 (PST) Received: from sun.com (vpn-129-156-96-65.EMEA.Sun.COM [129.156.96.65]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id hBJDidm12027; Fri, 19 Dec 2003 14:44:39 +0100 (MET) Message-ID: <3FE2FFC7.8070403@sun.com> Date: Fri, 19 Dec 2003 14:40:23 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Alex Karahalios Cc: Philip Nye , Zeroconf Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer References: <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> <4.3.2.7.2.20031216122752.036d3688@flask.cisco.com> <26D0BD60-3005-11D8-899C-00039377AD70@Outersoft.com> <025701c3c54c$2a023540$131010ac@aldebaran> <105A50E0-319E-11D8-870A-00039377AD70@Outersoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Alex, You are incorrect in asserting there is a problem. A host whose interface is configured with a link-local address can communicate with a host with a routable address (See Section 2.6.2). The host with the link-local address may also *discover* the address of a host with a routable address (on the same link), for example by using mDNS. A host with a routable address which complies with this specification can communicate with a host configured with a link-local address (See Section 3.3). The host with the routable address that receives discovery messages (such as sent by mDNS) will respond. If the discoverer's source address is link-local, the discovered service will respond to that destination address. Best regards, Erik = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = Alex Karahalios wrote: > Hi Philip, > > Yes, this works. But what I am trying to address is that, due to the > wording of section 1.7, the mDNS printer will no longer broadcast the LL > address once it obtains a routable address and thus the LL only device > will never know that the printer exists and thus cannot communicate with > it. > > That is why the phrase > > "the host MUST always use the routable address when > initiating new communications, and MUST cease advertising the > availability of the Link-Local IPv4 address through whatever > mechanisms that address had been made known to others" > > is not acceptable since it precludes LL only devices from participating > in the network. > > Alex Karahalios > > On Dec 18, 2003, at 2:49 AM, Philip Nye wrote: > >> Provided they are on the same link, the LL device _can_ communicate >> with the printer just so long as the printer has the necessary route >> for the 169.254.x.x network. This has been the preferred mode of >> operation for several successive drafts now. Communication between LL >> and routable hosts on the same link is perfectly possible. >> >> I would expect a printer using mDNS to configure the necessary route >> automatically. Getting the IPv4LL draft to RFC status would make this >> even more likely! >> > -- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Erik Guttman - N1 Manageability - Sun Microsystems cell: +49 172 865 5497 - time zone: CET (GMT+1) From owner-zeroconf@merit.edu Fri Dec 19 11:42:29 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 LAA15396 for ; Fri, 19 Dec 2003 11:42:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AE6E0912C1; Fri, 19 Dec 2003 11:35:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 71903912D1; Fri, 19 Dec 2003 11:35:16 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 489BE912C1 for ; Fri, 19 Dec 2003 11:35:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 33D905DDFC; Fri, 19 Dec 2003 11:35:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from home.karahalios.org (dsl093-162-009.tus1.dsl.speakeasy.net [66.93.162.9]) by segue.merit.edu (Postfix) with ESMTP id 7E69E5DDF2 for ; Fri, 19 Dec 2003 11:35:12 -0500 (EST) Received: from [192.168.2.2] (usr2.Karahalios.org [192.168.2.2]) (authenticated) by home.karahalios.org (8.11.1/8.10.1) with ESMTP id hBJGZ8L12685; Fri, 19 Dec 2003 09:35:08 -0700 In-Reply-To: <3FE2FFC7.8070403@sun.com> References: <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> <4.3.2.7.2.20031216122752.036d3688@flask.cisco.com> <26D0BD60-3005-11D8-899C-00039377AD70@Outersoft.com> <025701c3c54c$2a023540$131010ac@aldebaran> <105A50E0-319E-11D8-870A-00039377AD70@Outersoft.com> <3FE2FFC7.8070403@sun.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4E4F1D45-3241-11D8-832A-00039377AD70@Outersoft.com> Content-Transfer-Encoding: 7bit Cc: Philip Nye , Zeroconf From: Alex Karahalios Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer Date: Fri, 19 Dec 2003 09:35:07 -0700 To: Erik Guttman X-Mailer: Apple Mail (2.609) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eric, OK, I see now. Based on section 3.3, a LL only device can sent directly to a routable address device (provided it's on the same link). And by section 2.6.2 the LL only device will ARP for the routable address. Sorry for being dense about this. I was just focusing on section 1.7. Thanks, Alex On Dec 19, 2003, at 6:40 AM, Erik Guttman wrote: > You are incorrect in asserting there is a problem. > > A host whose interface is configured with a link-local address can > communicate with a host with a routable address (See Section 2.6.2). > The host with the link-local address may also *discover* the address > of a host with a routable address (on the same link), for example by > using mDNS. > > A host with a routable address which complies with this specification > can communicate with a host configured with a link-local address > (See Section 3.3). The host with the routable address that receives > discovery messages (such as sent by mDNS) will respond. If the > discoverer's source address is link-local, the discovered service will > respond to that destination address. From owner-zeroconf@merit.edu Fri Dec 19 12:26: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 MAA16743 for ; Fri, 19 Dec 2003 12:26:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BC1329131E; Fri, 19 Dec 2003 12:24:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75DE29132F; Fri, 19 Dec 2003 12:24:47 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7066391423 for ; Fri, 19 Dec 2003 12:17:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 596ED5DE08; Fri, 19 Dec 2003 12:17:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fuchsia.home (unknown [192.150.250.67]) by segue.merit.edu (Postfix) with ESMTP id 7DDEB5DDE3 for ; Fri, 19 Dec 2003 12:17:13 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id hBJHFiMA019893; Sat, 20 Dec 2003 00:15:45 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id hBJ8nIG01761; Fri, 19 Dec 2003 15:50:47 +0700 (ICT) From: Robert Elz To: Alex Karahalios Cc: "Philip Nye" , Zeroconf Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer In-Reply-To: <105A50E0-319E-11D8-870A-00039377AD70@Outersoft.com> References: <105A50E0-319E-11D8-870A-00039377AD70@Outersoft.com> <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> <4.3.2.7.2.20031216122752.036d3688@flask.cisco.com> <26D0BD60-3005-11D8-899C-00039377AD70@Outersoft.com> <025701c3c54c$2a023540$131010ac@aldebaran> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Dec 2003 15:49:18 +0700 Message-ID: <8130.1071823758@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 18 Dec 2003 14:06:35 -0700 From: Alex Karahalios Message-ID: <105A50E0-319E-11D8-870A-00039377AD70@Outersoft.com> | Yes, this works. But what I am trying to address is that, due to the | wording of section 1.7, the mDNS printer will no longer broadcast the | LL address once it obtains a routable address yes, that's intended. | and thus the LL only device will never know that the printer exists But how does that possibly follow? The printer will just broadcast its routable address instead, the LL only device will see that address, and use it. "LL-only" devices assume that *every* IP address is on the local link (as to them, that's true, for the world as they know it). kre From owner-zeroconf@merit.edu Fri Dec 19 12:35:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17162 for ; Fri, 19 Dec 2003 12:35:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CD0E891382; Fri, 19 Dec 2003 12:34:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2AF6491491; Fri, 19 Dec 2003 12:34: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 C1BEB91472 for ; Fri, 19 Dec 2003 12:31:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC57A5DDEF; Fri, 19 Dec 2003 12:31:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from home.karahalios.org (dsl093-162-009.tus1.dsl.speakeasy.net [66.93.162.9]) by segue.merit.edu (Postfix) with ESMTP id EF9635DD94 for ; Fri, 19 Dec 2003 12:31:02 -0500 (EST) Received: from [192.168.2.2] (usr2.Karahalios.org [192.168.2.2]) (authenticated) by home.karahalios.org (8.11.1/8.10.1) with ESMTP id hBJHUwL13247; Fri, 19 Dec 2003 10:31:00 -0700 In-Reply-To: <8130.1071823758@munnari.OZ.AU> References: <105A50E0-319E-11D8-870A-00039377AD70@Outersoft.com> <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> <4.3.2.7.2.20031216120031.01fcc310@flask.cisco.com> <4.3.2.7.2.20031216122752.036d3688@flask.cisco.com> <26D0BD60-3005-11D8-899C-00039377AD70@Outersoft.com> <025701c3c54c$2a023540$131010ac@aldebaran> <8130.1071823758@munnari.OZ.AU> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <199AF2A0-3249-11D8-832A-00039377AD70@Outersoft.com> Content-Transfer-Encoding: 7bit Cc: Zeroconf From: Alex Karahalios Subject: Re: new issue: [LL36] Combine and rework section 1.7 and 2.11 to be clearer Date: Fri, 19 Dec 2003 10:30:55 -0700 To: Robert Elz X-Mailer: Apple Mail (2.609) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yes, you are right - I understand now. I was just focusing on section 1.7 of the draft and ignoring the rest of the draft. Thanks, Alex On Dec 19, 2003, at 1:49 AM, Robert Elz wrote: > But how does that possibly follow? The printer will just broadcast > its routable address instead, the LL only device will see that address, > and use it. "LL-only" devices assume that *every* IP address is on > the > local link (as to them, that's true, for the world as they know it). From owner-zeroconf@merit.edu Mon Dec 22 14:49: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 OAA02435 for ; Mon, 22 Dec 2003 14:49:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E601F9132D; Mon, 22 Dec 2003 14:46:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7390A91336; Mon, 22 Dec 2003 14:46:33 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C08C91277 for ; Mon, 22 Dec 2003 14:44:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2790D5DEA9; Mon, 22 Dec 2003 14:44:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from magic.adaptec.com (magic-mail.adaptec.com [216.52.22.10]) by segue.merit.edu (Postfix) with ESMTP id 97B4E5DE79 for ; Mon, 22 Dec 2003 14:44:49 -0500 (EST) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id hBMJimJ18633 for ; Mon, 22 Dec 2003 11:44:48 -0800 Received: from aime2k02.adaptec.com (aime2k02.adaptec.com [10.25.8.42]) by redfish.adaptec.com (8.11.6/8.11.6) with ESMTP id hBMJim820616 for ; Mon, 22 Dec 2003 11:44:48 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: Document review blast Date: Mon, 22 Dec 2003 11:44:48 -0800 Message-ID: Thread-Topic: Document review blast Thread-Index: AcPGVnDEP9NRu8pzT7C3iGwF/yfP/ACakuLg From: "Elder, Alex" To: "Zeroconf" Cc: "Elder, Alex" Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable The following are comments on the ZEROCONF Working group Internet Draft document, named "draft-ietf-zeroconf-ipv4-linklocal-10.txt". I recently corresponded directly with Erik Guttman, who suggested that (after reviewing the latest draft and issues list and mail list archive) I submit my comments and let them be hashed out by the group. Some of the following is also related to earlier correspondence I had with Stuart Cheshire regarding address conflict detection. I have broken my comments into three general groups: - General. Overall impressions - Technical. Suggestions/observations related to technical details - Editorial. More alolng the lines of rewording suggestions, etc. Within the technical area, I have grouped my comments into four subgroups: - Parameterization. I think the document would benefit from more explicitly stating some parameters to the algorithms, even if those parameter values are expected to never change - Probing intervals. Yes, I dare to suggest changes to the underlying protocol, despite the recent flurry of discussion about "Aggressive Time-outs" (my suggestion is even more aggressive). - Multiple interfaces. - Other clarifications. I don't expect to be able to participate very fully in this group, but felt that my observations based on my recent work with the Link-Local and address conflict detection stuff might be worth sharing. I will be happy to answer questions about the content of this message though. - Alex Elder =09 alex_elder@adaptec.com General ------- - There is a huge amount of overlap between this document and the document "draft-cheshire-ipv4-acd.txt" which covers the more general problem of address conflict detection. It would be nice if the two jobs (LL address selection and general conflict detection) could be more clearly separated, to avoid the redundancy. The obvious problem with this redundancy is keeping both documents mutually consistent, and already details of the content of the two documents are diverging in places where they should be the same. (Example: ACD document indicates specifically that the host can begin using a claimed IP address *after* it sends out an announcement packet, while the LL document currently doesn't say this quite so specifically.) - (Related to issues 30, 39.) Generally, this document talks about support for multiple interfaces, but doesn't cover it very uniformly. As an example, In section 2.2.1, 4th paragraph, it's mentioned that any ARP packet received which has a sender IP address matching the probe address indicates a conflict. In fact, I think that should state that any such ARP packet received *on any of the host's interfaces* indicates a conflict. Technical Feedback ------------------ a) Parameterization - Section 2.2.1, last paragraph. The value "10" for the number of collisions during the probe cycle is clearly arbitrary. That's OK, but I suggest it be called out with an explicit parameter name rather than fixing it in stone in the text (even if in reality it is fixed in stone). - Section 2.2.1, last paragraph. Similarly, the "1 address probe attempt per minute" is another arbitrary selection, and there too I suggest this rate be defined as a named parameter, even if it ends up being a permanently fixed parameter. (This one, more than the "10" value just mentioned, seems like it might worthy of scaling based on characteristics of the underlying medium someday.) - Section 2.5, paragraph (b). The value *ten seconds* for the period over which a previous ARP message should be considered "recent" is arbitrary. As I have suggested for other things above, I think this should be defined by an explicit parameter rather than fixing it permanently in the text (even if its value is permanently fixed). - All of these parameters, their values, and their meanings, should be explicitly listed in section 9, Constants. b) Probing Intervals (related to issues 31, 37) - Section 2.2.1, third paragraph. What is the purpose of delaying *at least* PROBE_MIN (=3D 1 second) *before* anything ever gets = started? The initial delay should range from 0.., not from ..; the extra initial delay is just a waste of time. - Section 2.2.1, third paragraph. What is the benefit of having the delays between probes be random? Isn't it sufficient for the initial delay to be random, followed by a fixed, as-small-as-possible (presumably PROBE_MIN) delay between probes? I don't know that the subsequent random delays really improve anything with respect to simultaneous probes that an initial random delay wouldn't already mitigate. So the suggestion is use a fixed minimum inter-probe delay rather than randomizing it. - If the previous two suggestions were implemented, the range of time required for a successful claim of an unused address (using PROBE_MIN=3D1 and PROBE_MAX=3D2) could be cut about in half, changing from 4-8 = seconds (+ 2 seconds between announcements) down to 3-4 seconds (+ 1 second between announcements). (This would need to be reflected in the text in section 2.3.) - Section 2.2.1, third paragraph. I think the range of the random initial delay needs not to be dependent on the inter-probe delay. The purpose of the inter-probe delay (as I understand it) is to ensure at least one probe has a chance of not being lost as a result of a known design constraint (which has to do with details of the 802.3 spanning tree protocol[?]). The purpose of the initial randomness is to avoid a flood of simultaneous probes occurring in lock-step due to, e.g., sudden power-on of a whole network link full of interfaces. I suggest the initial delay be a parameter separate from the inter-probe delay (currently defined by PROBE_MIN and PROBE_MAX). Whether it should be shorter or longer than PROBE_MIN or PROBE_MAX I can't answer at this point. - Section 2.2.1, fourth paragraph. If all inter-probe delays were PROBE_MIN (rather than the range PROBE_MIN to PROBE_MAX), I think the delay following the last probe and the first announcement can be reduced to PROBE_MIN as well. So I guess my proposal would be something like: delay(random(0..INITIAL_DELAY=3D1 second)) send_arp_probe(addr) \___ repeat PROBE_COUNT=3D3 times delay(PROBE_DELAY=3D1 second) / send_arp_annoucement(addr) \___ repeat ANNOUNCE_COUNT=3D2 times delay(ANNOUNCE_DELAY=3D1 second) / (but skip delay after the last) c) Multiple interfaces - Section 2.2.1, fourth paragraph. Do *all* interfaces on a host need to be monitored for ARP's indicating an address for *any/all* of the host's interfaces (and defend the other interface IP's when a conflict is seen)? I think they do, to avoid address ambiguity. I.e., it shouldn't be acceptable for a host's eth1 to have the same LL address as a different interface reachable via that host's eth0. - Perhaps related, should ARP probes, announcements, and defense announcements go out over *all* of a host's interfaces? (I think so.) Should defense packets go out only on the interface that received an ARP packet indicating a conflict (I think so); or on the interface whose LL IP conflicts (I think not); or on both, or on all interfaces? - Section 2.5, first paragraph (related to issue 15). I don't understand why the probe case differs from the ongoing monitoring case with respect to the 'sender hardware address' field in a received ARP. While probing, an ARP containing a 'sender IP address' in conflict with the probe address is considered a conflict irrespective of the sender hardware address. But in the ongoing monitoring case only such ARP's for which the sender hardware address is not one of the host's own are considered indicative of conflict. It seems to me they should both only "care" if the packet originates from a different host (i.e., the probe case should be just as specific as the ongoing monitoring case). Is this just to support of the idea of multiple interfaces on a host being handled independently (i.e., each having no knowledge of any other's address configuration state?) - Section 2.5, first paragraph. Again, I think the host probably needs to be monitoring *all* of its interfaces for conflicts indicated for *any* of its own Link-Local addresses. So this section should state that "At any time, if a host receives an ARP packet (request *or* reply) ***on any of its interfaces*** where the ..." d) Other clarifications - A situation could arise that is not currently addressed by the specification. It is conceivable that a pathological rogue host only answers the ARP *announcements*, not the *probes*, in which case addresses could be claimed, then immediately (after a defense announcement) given up, restarting the process indefinitely, with no throttle action such as what exists for repeated conflicts during the probing phase. Mitigating this probably requires a separate counter or timer that tracks how recently or how frequently *claimed* (not just probed) addresses are lost. - Last paragraph of section 2.1. When should an address be saved to persistent storage? I believe it should occur only after an address has been successfully claimed. The text is not so specific, allowing (for example) a newly selected but not yet probed address to be saved to persistent storage. This difference may not matter much in the end, but my suggested approach could avoid some unnecessary saves of the information, and adds a bit of increased value to the address saved (i.e., not only is it an address that has been selected, but it's known to have been "good" at one time). - Section 2.2.1, fourth paragraph. It is not clear what constitutes "the beginning of the probing process". I believe the probing process begins at the moment the initial random delay begins. But as worded, it could be interpreted as, for example, beginning when the first probe packet is sent out. - Section 2.2.1, fifth paragraph. It is not clear from the specification at what point the failed address claim attempt counter gets reset to zero. I believe it should be reset whenever an address gets claimed (i.e., at the point at which the first address announcement gets sent). If it isn't reset, then having "trouble" acquiring an address once will penalize all future attempts to acquire a new address in the face of a post-claim collision. - Section 2.2.1, last paragraph. This paragraph indicates that "the host has successfully claimed the desired Link-Local IPv4 address" after PROBE_MAX after the last probe. A separate draft standard (on address conflict detection) says more explicitly that the host can begin using the address once the host had sent out the first ARP announcement. The part about when the host can begin using the address should be stated explicitly. And the discrepancy between the two documents should be resolved (one way or another). - Section 2.4, last paragraph. This comment is really a set of questions, I guess rhetorical. Why is the period between announcements PROBE_MAX? Why can't it be PROBE_MIN (is it because the maximum inter-probe delay is PROBE_MAX)? Does this delay have anything to do with spanning tree protocol? If not, does it have to be tied to PROBE_MAX or is that just an arbitrary way of reusing an existing parameter of the specification? Why is this value *not* scaled by the shorter timeouts? Perhaps the document could at least attempt to give some answers to these kinds of questions, maybe in an appendix. - Section 2.5, paragraph (b). It think it may be important to distinguish more precisely what the differences (and similarities) are between what happens when an interface using a LL address is shut down and reconfigured due to a repeated collision, and when an interface using a LL address is shut down to reconfigure it with a routable address as mentioned in section 1.7. One difference I note is that in the LL->routable case the "host SHOULD continue to use the Link-Local IPv4 address for communications underway" while in the LL->LL case it "MUST immediately cease using this address." Editorial Feedback ------------------ - The abstract, and subsequent sections repeatedly use the phrase "physical (or logical) link" without really describing why it is spelled out this way until later. Section 1.2 defines the phrase "on the same link" but never says anything about the "physical (or logical)" part. Suggest using something less awkward, such as "network link" until the more precise definition is provided. - Abstract, second paragraph, as well as end of paragraph in section 1.4 at the top of page 4. The statement is made that "This document does not recommend that Link Local IPv4 addresses and routable addresses be configured simultaneously on the same interface." Is it intentional to not go so far as "recommends not to" rather than "does not recommend?" It's a subtle difference; maybe this phraseology is normal for this type of document. - Section 1.3, last line of page 4. Does "round-trip latency" have a well-defined meaning? I know what I think is meant (i.e., twice the maximum time it takes for data to travel between a pair of interfaces on the medium), I just wondered whether "round-trip latency of at most one second" has the same sort of precision as "data rates of at least 1 Mbps," for example. - Section 1.3, top of page 5. The sentence starting with "Link layer technologies..." is phrased in such a way that it seems to conflict the earlier statement that this specification only applies to certain technologies. Suggest rewording something more like: "This specification could also apply to link-layer technologies that support ARP but operate at rates below 1 Mbps or latencies above one second, if different values are specified for one or more of the following parameters described in sections 2.2, 2.3, and 2.4:" ... - Section 1.3, top of page 5. Suggest mentioning the names of the parameters described here (e.g., PROBE_MIN and PROBE_MAX). Also, some (most?) of these haven't been given formal names, and in those cases I recommend names get assigned. - Section 1.3, top of page 5. Other values that could be called out as parameters of the specification (these should probably be considered technical feedback as well): - number of consecutive unsuccessful addresses probed before limiting the rate of subsequent address probes (currently 10) - Rate at which probes occur after that point (currently no more than one probe per 60 seconds) - Definition of "recent" with respect to defending an address. That is, the time period between receipt of ARP packets that indicate an address conflict, such that if the second arrives less than that time after the first the interface stops using its address, but greater than that time it continues using it. (See section 2.5(b).) (currently 10 seconds) - Last paragraph in section 1.3. (Related to issue 22) The specificity of the value "1300" here seems strange, at least in the way it gets presented. What's seems to be happening is that an arbitrary threshold of 2% is being chosen as reasonable, in other words, getting an address the first try 98% of the time is acceptable. Out of this comes the precise sounding number 1300 (i.e., 2% of a 65024 addresses in the IPv4 Link-Local range) as a point where network operators should consider partitioning their network. (In fact, they should have considered this long before then...) I don't have a suggested rewording for you, I'm just making note of the fact that it didn't read well. - Section 1.7, second paragraph. It may be possible to reword this so it's more clear you're talking about configuring BOTH a routable AND a Link-Local address on the same interface at the same time. As it is it could be interpreted as maybe reconfiguring an interface that has a routable address with a link local one instead (i.e., in its place). - Section 2.2.1, third paragraph. PROBE_MIN and PROBE_MAX are used here without any prior introduction. Suggest introducing them earlier in the document (such as in section 1.3, when some parameters of the specification are first mentioned), or at least earlier in this section. - Section 2.2.1, fourth paragraph. The term "address collision" is first used here. I know it's interchangeable with "address conflict" (which was first used in section 1.3). However, I recommend a single term be consistently throughout the document. I would recommend using "conflict," given the historical significance of the term "collision" in the Ethernet world. I also would try to define the term in such a way that it includes the condition of finding an address being probed already in use by another interface, as well as an when an already-claimed address is found to be in use. This way a common term would be meaningful in both sections of the document to mean, more or less, that an address you're concerned with is in use by another host. - Section 2.3. This whole section was obviously not updated at the time the PROBE_MIN and PROBE_MAX concepts were added earlier in the document. The section should be reconsidered in its entirety so I won't really give much suggestion how to rewrite it. But I will point out that the 8-10 seconds is now wrong given the assumed values of PROBE_MIN and PROBE_MAX and the number of probes now specified. - Section 2.3. It would be nice to have a more specific reference that explains (or refers to an explanation of) why 802.1d STP "often silently discard[s] all packets for several seconds." - Section 2.5, first paragraph. This section is only talking about a host's *link local* addresses, and should specify that. Specifically, near the middle it says "where the 'sender IP address' is the host's own IP address, but..." and it should read something more like "where the 'sender IP address' is one of the host's own IPv4 Link-Local addresses, but...". - Section 2.5, paragraph (b), second-to-last sentence. Replace "as described above" with "using the process described in sections 2.2 and 2.4, above" to be more clear about what is being referred to.