From owner-zeroconf@merit.edu Mon May 5 05:05:10 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 FAA27282 for ; Mon, 5 May 2003 05:05:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C4C829122D; Mon, 5 May 2003 05:07:24 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8FF9D9122C; Mon, 5 May 2003 05:07:24 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F6B89122D for ; Mon, 5 May 2003 05:07:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CEECD5E07E; Mon, 5 May 2003 05:07:18 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 3B33F5E084 for ; Mon, 5 May 2003 05:07:18 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id DAA19762 for ; Mon, 5 May 2003 03:07:16 -0600 (MDT) Received: from sr-ehdb03-01 (sr-ehdb03-01 [129.157.142.202]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h4597EA28530 for ; Mon, 5 May 2003 11:07:15 +0200 (MEST) Date: Mon, 5 May 2003 11:07:15 +0200 (MEST) From: Erik Guttman X-Sender: erikg@sr-ehdb03-01 Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG Action - 1 week to discuss [LL31] Alternate text for 'Does shorter timeouts for specific link technology lead to problems?' Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk This issue will be discussed till May 12. Unless there is a strong objection it will be accepted. Please post comments to the working group mailing list zeroconf@merit.edu Erik From owner-zeroconf@merit.edu Mon May 5 05:05: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 FAA27272 for ; Mon, 5 May 2003 05:04:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6CA829122E; Mon, 5 May 2003 05:07:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BBC19122C; Mon, 5 May 2003 05:07:29 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 317879122E for ; Mon, 5 May 2003 05:07:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1C7BE5E081; Mon, 5 May 2003 05:07:26 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 941845E07E for ; Mon, 5 May 2003 05:07:25 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id CAA04621 for ; Mon, 5 May 2003 02:07:24 -0700 (PDT) Received: from sr-ehdb03-01 (sr-ehdb03-01 [129.157.142.202]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h4597MA28545 for ; Mon, 5 May 2003 11:07:22 +0200 (MEST) Date: Mon, 5 May 2003 11:07:22 +0200 (MEST) From: Erik Guttman X-Sender: erikg@sr-ehdb03-01 Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: www.spybeam.org is out of date, sorry Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I have not been able to access this website to update it based on the current set of actions. I will do so as soon as I can. Best regards, Erik From owner-zeroconf@merit.edu Mon May 5 05:05:05 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 FAA27273 for ; Mon, 5 May 2003 05:05:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ABAE39122B; Mon, 5 May 2003 05:07:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6528B9122C; Mon, 5 May 2003 05:07:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 79B869122B for ; Mon, 5 May 2003 05:07:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 65D3C5E081; Mon, 5 May 2003 05:07:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id C31B15E07E for ; Mon, 5 May 2003 05:07:12 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id DAA02547; Mon, 5 May 2003 03:07:10 -0600 (MDT) Received: from sr-ehdb03-01 (sr-ehdb03-01 [129.157.142.202]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h45978A28509; Mon, 5 May 2003 11:07:08 +0200 (MEST) Date: Mon, 5 May 2003 11:07:08 +0200 (MEST) From: Erik Guttman X-Sender: erikg@sr-ehdb03-01 Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: Christian Huitema , Erik Guttman Subject: New Issue [LL31] Alternate text for 'Does shorter timeouts for specific link technology lead to problems?' Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Description of Issue: Alternate text for 'Does shorter timeouts for specific link technology lead to problems?' Submitter Name: Christian Huitema Submitter Email Address: First submitted: 11 Apr 03 Reference: http://www.spybeam.org/ll12.html http://www.spybeam.org/ll20.html Comment type: T (technical) Priority: S (Must fix) Section : 2.2 Rationale/ Explanation: See http://www.spybeam.org/ll12 Lengthy description of problem: Perfection is not achievable: we can always envisage that two auto-configured networks are suddenly merged, e.g. by someone plugging a wire in a hub. The number of repetitions and the timers are thus a compromise between the desired reliability and the time it takes to achieve it. There is already an equivalent proposed standard, the duplicate address detection procedure used during auto-configuration of IPv6 addresses. The text says (RFC 2462, page 14): To check an address, a node sends DupAddrDetectTransmits Neighbor Solicitations, each separated by RetransTimer milliseconds. The solicitation's Target Address is set to the address being checked, the IP source is set to the unspecified address and the IP destination is set to the solicited-node multicast address of the target address. The retransmission timer can be configured by the routers (through the router advertisements), and the default value is set to 1000 milliseconds (RFC 2641). The default value for DupAddrDetectTransmits in RFC 2462 is 1. The important value is the residual collision rate after a cycle of retransmissions. This probability is a function of the number of hosts, the size of the number space, and the probability that a single transmission fails. I would contend that the "spanning tree black-out" is a rare event that can be incorporated in the transmission failure probability; that this transmission failure should generally be under a few % for TCP to operate correctly; and that it is safe to assume that the probability of a request/response transaction failing is under 5%. Under these circumstances, we can compute the residual probability for a network of 1300 hosts, a 62 bit number space (RFC 2462), and a population of 1300 hosts: it is about 1.4E-17. To achieve the same reliability with a 16 bit number space would require 12 repetitions. To achieve "five nines" (i.e. a failure rate lower than 10-5) requires 3 repetitions. Setting the timer to 1 second is consistent with RFC 2462. Setting the repetition number to 3 achieves a better than 5 nines reliability in most networks. In fact, we may debate the spacing requirement. A random spacing would be better, as it would avoid synchronization effects. And there is no real justification for the 1 second interval. A random interval should be just as good. Proposed Resolution: I propose to resolve LL12 and LL20 by proposing the following replacement text. In section 2.2, replace: When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range zero to two seconds, and should then send four probe packets, spaced two seconds apart. This initial random delay helps ensure that a large number of hosts powered on at the same time do not all send their initial probe packets simultaneously. By: Probing is performed in two phases: a random initial interval, followed by repeated probes. The purpose of the initial interval is to ensure that a large number of hosts powered on at the same time do not all send their initial probe packets simultaneously. When ready to begin probing, the host SHOULD then wait for a random time interval selected uniformly in the range zero to 200 milliseconds. During that period, the host should listen for probes sent by other nodes on the link. If the host receives more than 50 probes during the interval, it SHOULD restart the timer to a new value, chosen again between 0 and 200 milliseconds. Listening during the probing interval introduces an automatic back-off procedure. It allows the use of a short interval while ensuring that the number of probes on the network will be at most a few hundred per second. Hosts that cannot implement the listen and back-off algorithm described in the previous paragraph MAY simply wait for random spreading interval selected uniformly in the range zero to two seconds. After the random spreading interval, the host SHOULD send 3 probe packets, spaced 1 second apart. ---------------------- Erik Guttman Zeroconf WG chair From owner-zeroconf@merit.edu Mon May 5 05:05:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27331 for ; Mon, 5 May 2003 05:05:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 92ED19122F; Mon, 5 May 2003 05:08:02 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5817B91230; Mon, 5 May 2003 05:08:02 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2821E9122F for ; Mon, 5 May 2003 05:07:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 178095E082; Mon, 5 May 2003 05:07:57 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id 765E15E07E for ; Mon, 5 May 2003 05:07:56 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id DAA02802; Mon, 5 May 2003 03:07:44 -0600 (MDT) Received: from sr-ehdb03-01 (sr-ehdb03-01 [129.157.142.202]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h4597gA28700; Mon, 5 May 2003 11:07:42 +0200 (MEST) Date: Mon, 5 May 2003 11:07:43 +0200 (MEST) From: Erik Guttman X-Sender: erikg@sr-ehdb03-01 Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: Harald Alvestrand Subject: WG Action - 1 week last call [LL4] No examples of applications Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk This issue will be resolved by discussion during the next week. Please send comments to the zeroconf working group mailing list until May 12. This issue directly addresses an IESG concern brought up during IESG review. Thanks, Erik From owner-zeroconf@merit.edu Mon May 5 05:05:35 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27345 for ; Mon, 5 May 2003 05:05:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4F4539122C; Mon, 5 May 2003 05:07:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F1839122F; Mon, 5 May 2003 05:07:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4E0719122C for ; Mon, 5 May 2003 05:07:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 336E45E083; Mon, 5 May 2003 05:07:33 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 7CE135E081 for ; Mon, 5 May 2003 05:07:32 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id DAA19834 for ; Mon, 5 May 2003 03:07:31 -0600 (MDT) Received: from sr-ehdb03-01 (sr-ehdb03-01 [129.157.142.202]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h4597TA28614 for ; Mon, 5 May 2003 11:07:29 +0200 (MEST) Date: Mon, 5 May 2003 11:07:29 +0200 (MEST) From: Erik Guttman X-Sender: erikg@sr-ehdb03-01 Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: [LL3][LL21][LL29] Reconsideration --- Discuss till May 12 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk It seems my consensus call was flawed. After reading recent comments, I believe the right thing to do would be to accept LL21 as Robert Elz suggested. I believe that we should add the following advice to implementors: ''A sensible default for applications which are sending from a link-local address is to explicitely set the IP TTL to 1. This is not appropriate in all cases as some applications may require that the IP TTL be set to other values.'' Please send comments by May 12. If there is no further discussion on this topic, LL21 will be accepted and LL29 rejected. Erik From owner-zeroconf@merit.edu Mon May 5 05:07: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 FAA27430 for ; Mon, 5 May 2003 05:07:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2054391230; Mon, 5 May 2003 05:10:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E637591231; Mon, 5 May 2003 05:10:27 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 522F991230 for ; Mon, 5 May 2003 05:10:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 305DF5E082; Mon, 5 May 2003 05:10:26 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id A7CE65E07E for ; Mon, 5 May 2003 05:10:25 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id CAA04718; Mon, 5 May 2003 02:07:36 -0700 (PDT) Received: from sr-ehdb03-01 (sr-ehdb03-01 [129.157.142.202]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h4597XA28643; Mon, 5 May 2003 11:07:34 +0200 (MEST) Date: Mon, 5 May 2003 11:07:34 +0200 (MEST) From: Erik Guttman X-Sender: erikg@sr-ehdb03-01 Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: Harald Alvestrand Subject: New text for [LL4] No Examples of Applications Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Description of Issue No examples of applications Submitter Name Harald Alvestrand Submitter Email Address chair@ietf.org Date first submitted 6 Feb 2003 Reference http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00041.html http://www.merit.edu/mail.archives/zeroconf/2002-10/msg00000.html Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] 1 Section A new introduction section? Rationale/Explanation of issue: There was a request for a list of example applications which can safely be used with link-local addresses. Lengthy description of problem: I supplied the following list: File sharing (NFS, SMB), Print sharing (LPD, IPP), Local file sharing & web browsing (FTP, HTTP), Remote login (TELNET) This raised questions which I have not had the time, and lack enough expertise to answer: o Doesn't NFSv3 include addresses? Will that cause NFSv3 to fail? o Doesn't NFSv4 and IPP carry domain names? DNS will not have LL entries, most likely. Won't this cause NFSv4 and IPP to fail? ============================================== Before coming up with text for this, I think that we need to have agreement on the characteristics of applications that will cause them to fail when used with LLv4 addresses. I do not believe that just because an application uses LLv4 addresses that it will fail. The problem is not use by itself -- it is use of linklocal addresses IPv4 addresses in the wrong context. If an application uses its LLv4 address in communicating with a host off the link, it will break. However, if it uses that address in communicating with a host on-link then that should not happen. In looking at this, I believe the problem is "leakage". Including an LLv4 address in an off-link application exchange is an example of leakage -- and I believe that this MUST NOT be done at any layer. Similarly, I do not believe that including domain names in an application is by itself a problem -- unless it involves leakage. Examples of leakage include using LLv4 addresses in DNS. Including a name in an application where DNS is not configured among the conversants is not a problem -- assuming LLMNR is available to resolve the name. If the above makes sense, then I do not think it is necessarily appropriate to come up with "lists of applications" that will automatically fail. Rather we should focus on what applications need to do in order to be successful. Here is some proposed text: Requested Change: "Use of linklocal IPv4 addresses in off-link communication is likely to cause application failures. This can occur within any application that includes embedded addresses, if an LLv4 addresses is embedded when communicating with a host that is not on the link. Examples of applications that include embedded addresses are found in [RFC3027]. This includes IPsec, Kerberos 4/5, X-Windows/Xterm/Telnet, FTP, RSVP, SMTP, SIP, Real Audio, H.323, and SNMP. In order to prevent use of LLv4 addresses in off-link communication, the following cautionary measures are advised: a. Routable addresses should be used within applications whenever they are available. b. Names that are globally resolvable to routable addresses should be used within applications whenever they are available. Names that are resolvable only on the local link (such as through use of protocols such as LLMNR) MUST NOT be used in off-link communication. This can be prevented by using LLv4 addresses or names resolvable on the local link when an LLv4 address is used as the source address in the packet. c. LLv4 addresses MUST NOT be configured in the DNS." From owner-zeroconf@merit.edu Mon May 5 05:27: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 FAA27720 for ; Mon, 5 May 2003 05:27:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C75EC91229; Mon, 5 May 2003 05:06:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 950E59122A; Mon, 5 May 2003 05:06:54 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 84F2891229 for ; Mon, 5 May 2003 05:06:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 68A215E081; Mon, 5 May 2003 05:06:53 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id E01CB5E07E for ; Mon, 5 May 2003 05:06:52 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id CAA04450 for ; Mon, 5 May 2003 02:06:51 -0700 (PDT) Received: from sr-ehdb03-01 (sr-ehdb03-01 [129.157.142.202]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h4596nA28488 for ; Mon, 5 May 2003 11:06:49 +0200 (MEST) Date: Mon, 5 May 2003 11:06:49 +0200 (MEST) From: Erik Guttman X-Sender: erikg@sr-ehdb03-01 Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: REJECT [LL22][LL28] - These issues got no comment during WG last call Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk There was no discussion or support for these issues. Unless there is an a strong objection with support from the WG - the action we will take is LL22: Reject LL28: Reject Erik Guttman ZEROCONF WG chair From owner-zeroconf@merit.edu Mon May 5 05:55:13 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 FAA27274 for ; Mon, 5 May 2003 05:05:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0FA859122A; Mon, 5 May 2003 05:07:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD7379122C; Mon, 5 May 2003 05:07:13 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 722729122A for ; Mon, 5 May 2003 05:07:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5CD3F5E07E; Mon, 5 May 2003 05:07:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id D41635E083 for ; Mon, 5 May 2003 05:07:11 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id CAA04525; Mon, 5 May 2003 02:07:05 -0700 (PDT) Received: from sr-ehdb03-01 (sr-ehdb03-01 [129.157.142.202]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h45972A28497; Mon, 5 May 2003 11:07:02 +0200 (MEST) Date: Mon, 5 May 2003 11:07:03 +0200 (MEST) From: Erik Guttman X-Sender: erikg@sr-ehdb03-01 Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: Christian Huitema , Erik Guttman Subject: REJECT [LL12][LL20] - Resolution is to open [LL31] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk It appears we accept Christian's suggestion below. It seems reasonable and there was no additional comment. Unless there are any serious objections - this is the outcome of the discussion: [LL12] Reject [LL20] Reject I will open a new issue [LL31]. Erik --------------------------------------------------------------------- On Fri, 11 Apr 2003, Christian Huitema wrote: > Date: Fri, 11 Apr 2003 09:49:40 -0700 > From: Christian Huitema > To: Erik Guttman , zeroconf@merit.edu > Subject: RE: [LL12] [LL20] discussion not yet conclusive - continue till 17 Apr 03 > > Perfection is not achievable: we can always envisage that two > auto-configured networks are suddenly merged, e.g. by someone plugging a > wire in a hub. The number of repetitions and the timers are thus a > compromise between the desired reliability and the time it takes to > achieve it. > > There is already an equivalent proposed standard, the duplicate address > detection procedure used during auto-configuration of IPv6 addresses. > The text says (RFC 2462, page 14): > > To check an address, a node sends DupAddrDetectTransmits Neighbor > Solicitations, each separated by RetransTimer milliseconds. The > solicitation's Target Address is set to the address being checked, > the IP source is set to the unspecified address and the IP > destination is set to the solicited-node multicast address of the > target address. > > The retransmission timer can be configured by the routers (through the > router advertisements), and the default value is set to 1000 > milliseconds (RFC 2641). The default value for DupAddrDetectTransmits in > RFC 2462 is 1. > > The important value is the residual collision rate after a cycle of > retransmissions. This probability is a function of the number of hosts, > the size of the number space, and the probability that a single > transmission fails. I would contend that the "spanning tree black-out" > is a rare event that can be incorporated in the transmission failure > probability; that this transmission failure should generally be under a > few % for TCP to operate correctly; and that it is safe to assume that > the probability of a request/response transaction failing is under 5%. > > Under these circumstances, we can compute the residual probability for a > network of 1300 hosts, a 62 bit number space (RFC 2462), and a > population of 1300 hosts: it is about 1.4E-17. To achieve the same > reliability with a 16 bit number space would require 12 repetitions. To > achieve "five nines" (i.e. a failure rate lower than 10-5) requires 3 > repetitions. > > Setting the timer to 1 second is consistent with RFC 2462. Setting the > repetition number to 3 achieves a better than 5 nines reliability in > most networks. > > I propose to resolve LL12 and LL20 by proposing the following > replacement text. In section 2.2, replace: > > When ready to begin probing, the host should then wait for a > random time interval selected uniformly in the range zero to two > seconds, and should then send four probe packets, spaced two > seconds apart. This initial random delay helps ensure that a > large number of hosts powered on at the same time do not all send > their initial probe packets simultaneously. > > By: > > Probing is performed in two phases: a random initial interval, > followed by repeated probes. The purpose of the initial interval is > to ensure that a large number of hosts powered on at the same time do > > not all send their initial probe packets simultaneously. > > When ready to begin probing, the host SHOULD then wait for a > random time interval selected uniformly in the range zero to > 200 milliseconds. During that period, the host should > listen for probes sent by other nodes on the link. If the host > receives more than 50 probes during the interval, it SHOULD > restart the timer to a new value, chosen again between 0 and 200 > milliseconds. > > Listening during the probing interval introduces an automatic > back-off procedure. It allows the use of a short interval while > ensuring that the number of probes on the network will be at most > a few hundred per second. Hosts that cannot implement the listen > and back-off algorithm described in the previous paragraph MAY simply > wait for random spreading interval selected uniformly in the range > zero > to two seconds. > > After the random spreading interval, the host SHOULD send 3 > probe packets, spaced 1 second apart. > > In fact, we may debate the spacing requirement. A random spacing would > be better, as it would avoid synchronization effects. And there is no > real justification for the 1 second interval. A random interval should > be just as good. > > -- Christian Huitema > > > -----Original Message----- > > From: Erik Guttman [mailto:Erik.Guttman@Sun.COM] > > Sent: Friday, April 11, 2003 5:54 AM > > To: zeroconf@merit.edu > > Subject: [LL12] [LL20] discussion not yet conclusive - continue till > 17 > > Apr 03 > > > > > > Folks, > > > > Please help try and close these issues by Apr 17. > > > > Aside from the authors of the proposed text it appears no one supports > > these issue formulations. Given that there are millions of hosts > using > > LL right now with fixed timer values - successfully - this cannot be a > > very hard problem to get right for a general case. If it doesn't work > > in some cases, well gee, we will get conflicts we will have to > resolve. > > > > Please either support or reject these issues or offer a *simple and > > complete alternative.* > > > > Erik Guttman > > Zeroconf WG chair > > > > > > > > ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n N1 Installation and Provisioning Sun Microsystems cell: +49 172 865 5497 From owner-zeroconf@merit.edu Mon May 5 10:01:03 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02154 for ; Mon, 5 May 2003 10:01:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 39FC79122B; Mon, 5 May 2003 10:01:49 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 03A999122C; Mon, 5 May 2003 10:01:48 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EDC159122B for ; Mon, 5 May 2003 10:01:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C6A805DEAD; Mon, 5 May 2003 10:00:50 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (unknown [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 07D0E5E133 for ; Mon, 5 May 2003 10:00:50 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id IAA26567; Mon, 5 May 2003 08:00:47 -0600 (MDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h45E0iL10609; Mon, 5 May 2003 16:00:44 +0200 (MEST) Date: Mon, 5 May 2003 16:00:20 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: New Issue [LL31] Alternate text for 'Does shorter timeouts for specific link technology lead to problems?' To: Erik Guttman Cc: zeroconf@merit.edu, Christian Huitema , Erik Guttman In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I think the proposal is good. Question: does it also make sense to point out in an Appendix that Ethernet switches/bridges following IEEE 802.3D defaults, normally block packets for up to approximately 45 seconds immediately after a bridge port has been enabled. Techniques for avoiding adverse impact of such L2 behavior is outside of the scope of this protocol. That would at least provide a bit of a warning. Erik From owner-zeroconf@merit.edu Mon May 5 11:24: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 LAA05421 for ; Mon, 5 May 2003 11:24:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5CC059122D; Mon, 5 May 2003 11:27:25 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C4A39122E; Mon, 5 May 2003 11:27:25 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EDF7E9122D for ; Mon, 5 May 2003 11:27:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D66B15E15C; Mon, 5 May 2003 11:27:23 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from droopy.kallisys.net (e060.dhcp212-198-37.noos.fr [212.198.37.60]) by segue.merit.edu (Postfix) with ESMTP id 624705E14C for ; Mon, 5 May 2003 11:27:23 -0400 (EDT) Received: from [10.0.1.202] (localhost [127.0.0.1]) by droopy.kallisys.net (Postfix) with ESMTP id B6C6B1771C2 for ; Mon, 5 May 2003 17:27:19 +0200 (CEST) Mime-Version: 1.0 Message-Id: Date: Mon, 5 May 2003 17:27:17 +0200 To: zeroconf@merit.edu From: Paul Guyot Subject: DNS-SD: locally defined service names Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk Hello all, I have a question/comment regarding the service names for DNS-SD. According to the DNS-SD website http://www.dns-sd.org/ and the NBP replacement draft (http://files.dns-sd.org/draft-cheshire-dnsext-nbp.txt) and the SD draft (http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt), the service name shall be of the form _Foo._[tcp|udp]. where Foo is IANA assigned and the underscore is there to avoid collision (that's how the RFC 2782 justifies it) Nevertheless, the RFC 2782 mentions that the service (Foo) could be either a IANA defined service or defined locally. I wonder (a) what is the rationale of not accepting locally defined services and (b) if, considering that we use "_tcp.local." suffix for local services anyway, we could extend this to Bar._tcp. for local services Bar. Or shall I use _Bar for my local services? This strictness about IANA registration is contrary to the idea that although IANA services have the port assigned to the service identifier (Foo), DNS-SD gives the port number in addition to the service name (the client does not deduce the port from the service name). Here is a real situation where this could be (well, is) used: I happen to be developing a multiagent simulation software that picks a free port randomly and publishes its service on that port with DNS-SD. This allows me to run several instances on the same machine and not care on which port they are. I don't think I'm abusing of DNS-SD and we could imagine local peer-to-peer services that uses DNS-SD in the same way. I will not register 10 or 100 ports at IANA to be able to run 10 or 100 agents on the same machine, it would be a waste of their time and of port numbers (plus they'll probably not give me 10 or 100 ports). I don't mean that IANA registration should never be done. For services that are linked to a single port, it is fine and it lets one use _Foo._tcp.domain.com services (still have to see when this really interacts with multicast DNS, but it's another story). I was happy, even if it took 2 months, to register a service now published with DNS-SD. But I am not sure it is really worth it for many applications, especially peer-to-peer ones, which should also not be manually configured when possible but instead take advantage of zero-conf (plus in my very case, this makes the set of agents *very* robust since the UDP-Multicast group plays the role of a central server). Paul -- NPDS: http://newton.kallisys.net:8080/ Apache: http://www.kallisys.com/ From owner-zeroconf@merit.edu Tue May 6 11:13:46 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25641 for ; Tue, 6 May 2003 11:13:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3544B91254; Tue, 6 May 2003 11:16:32 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EADEC91255; Tue, 6 May 2003 11:16:31 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0F43891254 for ; Tue, 6 May 2003 11:16:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EFC085DDBF; Tue, 6 May 2003 11:16:30 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by segue.merit.edu (Postfix) with ESMTP id 8610F5DDB3 for ; Tue, 6 May 2003 11:16:30 -0400 (EDT) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-525.cisco.com [10.82.242.13]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h46FGRmb003890; Tue, 6 May 2003 11:16:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20030506110901.0213a548@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 06 May 2003 11:16:27 -0400 To: Erik Guttman From: John Schnizlein Subject: Re: [LL3][LL21][LL29] Reconsideration --- Discuss till May 12 Cc: zeroconf@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk Please explain the reasons for your reversal. Statements like "was flawed" and "reading recent comments", which were apparently after the previous discussion deadline, do not seem adequate to reverse the formal process of the WG. At 05:07 AM 5/5/2003, Erik Guttman wrote: >It seems my consensus call was flawed. After reading recent comments, I >believe the right thing to do would be to accept LL21 as Robert Elz >suggested. I believe that we should add the following advice to >implementors: > > ''A sensible default for applications which are sending from a > link-local address is to explicitely set the IP TTL to 1. This > is not appropriate in all cases as some applications may require > that the IP TTL be set to other values.'' > >Please send comments by May 12. If there is no further discussion on >this topic, LL21 will be accepted and LL29 rejected. > >Erik From owner-zeroconf@merit.edu Wed May 7 01:45: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 BAA21435 for ; Wed, 7 May 2003 01:45:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C43719127E; Wed, 7 May 2003 01:47:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97E1E9127F; Wed, 7 May 2003 01:47:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 89EAE9127E for ; Wed, 7 May 2003 01:47:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 64B2B5E024; Wed, 7 May 2003 01:47:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id D891F5E02B for ; Wed, 7 May 2003 01:47:53 -0400 (EDT) Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h475lq9J021993 for ; Tue, 6 May 2003 22:47:53 -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 h475lm2J015975 for ; Wed, 7 May 2003 00:47:50 -0500 Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.9/8.12.8) with ESMTP id h475llVI009530 for ; Wed, 7 May 2003 15:47:47 +1000 (EST) Message-ID: <3EB89E03.7090402@motorola.com> Date: Wed, 07 May 2003 15:47:47 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Re: [LL12] [LL20] and a possible solution References: <28907.1049549805@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Scott Lawrence wrote: > I think the complexity cost is not justified by the frequency (low) > and severity (not very) of the problem. > Basically, I agree with your assessment. Reading the thread another option occurred to me, however I'm not sure whether it would work. Configure an LL address quickly, but mark it as tentative. It remains tentative for some long time (e.g. 60 seconds), or until we can receive some indication that our packets can be received. A non-destructive way of getting this indication is to perform ARP probes for addresses we would like to communicate with using LL rather than ARPing for them directly with our tentative address. Whilst the LL address is "tentative", we change the way that we ARP for destinations. Rather than ARP directly for a destination using our LL address (thus polluting the ARP cahce), we probe for every destinations that we are trying to communicate with. If we get an ARP probe response we know our packets are being received, so we can DAD the LL address and begin communicating and perform normal ARPs. - aidan From owner-zeroconf@merit.edu Wed May 7 02:04:03 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25949 for ; Wed, 7 May 2003 02:04:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 647DA9127F; Wed, 7 May 2003 02:06:52 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3612C91280; Wed, 7 May 2003 02:06:52 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 386849127F for ; Wed, 7 May 2003 02:06:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 185315DF41; Wed, 7 May 2003 02:06:51 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id 873075DDA8 for ; Wed, 7 May 2003 02:06:50 -0400 (EDT) Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h4766n9J000170 for ; Tue, 6 May 2003 23:06:49 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by il06exr01.mot.com (Motorola/il06exr01) with ESMTP id h4766jac018000 for ; Wed, 7 May 2003 01:06:47 -0500 Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.9/8.12.8) with ESMTP id h4766iVI010416 for ; Wed, 7 May 2003 16:06:44 +1000 (EST) Message-ID: <3EB8A274.8070204@motorola.com> Date: Wed, 07 May 2003 16:06:44 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Re: [LL3][LL21][LL29] Reconsideration --- Discuss till May 12 References: <4.3.2.7.2.20030506110901.0213a548@wells.cisco.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 John Schnizlein wrote: > Please explain the reasons for your reversal. > Statements like "was flawed" and "reading recent comments", > which were apparently after the previous discussion deadline, > do not seem adequate to reverse the formal process of the WG. > I was surprised at the result of the consensus call, however Erik did say that he thought the consensus was rather rough. Since I agree with Christian's comment that there won't be any consensus on a specific value for the TTL, I support Erik opening up the discussion on LL21 again. Given that there doesn't seem to be any knock-down argument for TTL=1 vs TTL=255 vs TTL=anything_in_particular, and that we aren't going to be able to agree on a specific value, I think we're better off with a spec that documents the issues and leaves it up to the implementer. Hence, I continue to support LL21. - aidan > At 05:07 AM 5/5/2003, Erik Guttman wrote: > > >>It seems my consensus call was flawed. After reading recent comments, I >>believe the right thing to do would be to accept LL21 as Robert Elz >>suggested. I believe that we should add the following advice to >>implementors: >> >> ''A sensible default for applications which are sending from a >> link-local address is to explicitely set the IP TTL to 1. This >> is not appropriate in all cases as some applications may require >> that the IP TTL be set to other values.'' >> >>Please send comments by May 12. If there is no further discussion on >>this topic, LL21 will be accepted and LL29 rejected. >> >>Erik > > From owner-zeroconf@merit.edu Wed May 7 07:01:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23374 for ; Wed, 7 May 2003 07:01:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E57889127F; Wed, 7 May 2003 07:04:23 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B105491280; Wed, 7 May 2003 07:04:23 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98E809127F for ; Wed, 7 May 2003 07:04:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 792AA5E142; Wed, 7 May 2003 07:04:22 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from smtp.covadmail.net (mx03.covadmail.net [63.65.120.63]) by segue.merit.edu (Postfix) with SMTP id 0748D5E13F for ; Wed, 7 May 2003 07:04:22 -0400 (EDT) Received: (covad.net 6758 invoked from network); 7 May 2003 11:04:20 -0000 Received: from unknown (HELO STUDY) (66.167.173.158) by sun-qmail07 with SMTP; 7 May 2003 11:04:19 -0000 To: zeroconf@merit.edu Cc: Aidan Williams Subject: Re: [LL12] [LL20] and a possible solution References: <28907.1049549805@munnari.OZ.AU> <3EB89E03.7090402@motorola.com> Organization: Seeking Work... From: Scott Lawrence Date: 07 May 2003 07:04:05 -0400 In-Reply-To: <3EB89E03.7090402@motorola.com> Message-ID: Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-zeroconf@merit.edu Precedence: bulk Aidan Williams writes: > Whilst the LL address is "tentative", we change the way that > we ARP for destinations. Rather than ARP directly for a > destination using our LL address (thus polluting the ARP > cahce) But that's solving a problem (introducing conflicts into ARP caches), only when it doesn't exist - if your packets are not being received, then no one will get them to pollute the cache either. In some sense, all zeroconf addresses are "tentative" - if we detect a collision, then we give them up and get a new one anyway. -- Scott Lawrence Actively seeking work http://skrb.org/scott/ [ is deprecated ] From owner-zeroconf@merit.edu Wed May 7 12:49:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07972 for ; Wed, 7 May 2003 12:49:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C11DC91288; Wed, 7 May 2003 12:52:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E7A291289; Wed, 7 May 2003 12:52:39 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 84C3D91288 for ; Wed, 7 May 2003 12:52:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E2725DDB3; Wed, 7 May 2003 12:52:38 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by segue.merit.edu (Postfix) with ESMTP id 4BDB55DD8E for ; Wed, 7 May 2003 12:52:37 -0400 (EDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h47Gt0QK028838; Wed, 7 May 2003 19:55:00 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h47Gsxha028837; Wed, 7 May 2003 19:54:59 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [LL12] [LL20] and a possible solution From: Mika Liljeberg To: Aidan Williams Cc: zeroconf@merit.edu In-Reply-To: <3EB89E03.7090402@motorola.com> References: <28907.1049549805@munnari.OZ.AU> <3EB89E03.7090402@motorola.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1052326498.4604.43.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 07 May 2003 19:54:59 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-05-07 at 08:47, Aidan Williams wrote: > Scott Lawrence wrote: > > I think the complexity cost is not justified by the frequency (low) > > and severity (not very) of the problem. > > > > Basically, I agree with your assessment. So do I. > Configure an LL address quickly, but mark it as tentative. > It remains tentative for some long time (e.g. 60 seconds), > or until we can receive some indication that our packets > can be received. A non-destructive way of getting this > indication is to perform ARP probes for addresses we would > like to communicate with using LL rather than ARPing for > them directly with our tentative address. I proposed a similar thing but I abandoned this line of thinking when I realized that there is a chicken egg problem with LLMNR. You probably need something like LLMNR to get the first destination address. So the question is, what do you do if the first packet has a multicast destination? You can't probe. You could let the packet go on the link and hope for a response but then you have to decide if you allow a tentative address as source address. Assuming the switches aren't a big issue, I think Christian's proposal about the listening period is good. Given that, I don't see any reason to mandate any particular timeout values, though. Just require a random initial period, suggest the number of retransmissions, and allow implementations to scale the timeouts as appropriate for that particular link. MikaL From owner-zeroconf@merit.edu Thu May 8 21:15:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18701 for ; Thu, 8 May 2003 21:15:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 81A9A9120E; Thu, 8 May 2003 21:18:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 244589120D; Thu, 8 May 2003 21:18:35 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2C48491209 for ; Thu, 8 May 2003 21:17:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0BFCC5DE4B; Thu, 8 May 2003 21:17:32 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id 511E25DD8C for ; Thu, 8 May 2003 21:17:31 -0400 (EDT) Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h491HU9J023376 for ; Thu, 8 May 2003 18:17:30 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h491HQax016732 for ; Thu, 8 May 2003 20:17:27 -0500 Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.9/8.12.8) with ESMTP id h491HLVI025452; Fri, 9 May 2003 11:17:23 +1000 (EST) Message-ID: <3EBB01A0.1070603@motorola.com> Date: Fri, 09 May 2003 11:17:20 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence Cc: zeroconf@merit.edu Subject: Re: [LL12] [LL20] and a possible solution References: <28907.1049549805@munnari.OZ.AU> <3EB89E03.7090402@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Scott Lawrence wrote: > Aidan Williams writes: >>Whilst the LL address is "tentative", we change the way that >>we ARP for destinations. Rather than ARP directly for a >>destination using our LL address (thus polluting the ARP >>cahce) > > But that's solving a problem (introducing conflicts into ARP caches), > only when it doesn't exist - if your packets are not being received, > then no one will get them to pollute the cache either. > The problem that this is trying to solve is where a node using IPv4-LL is on a switch port that is blocked waiting for spanning tree timers. It does DAD on an address and it thinks it is unique. Subsequently, the switch port starts to forward. When it ARPs for a destination (any destination) third party hosts will see a conflicting IP address/MAC mapping in the broadcast ARP message. Doing a probe (ie setting the source IP address to 0) prevents the cache pollution. > In some sense, all zeroconf addresses are "tentative" - if we detect a > collision, then we give them up and get a new one anyway. Yes, but we might have taken out some other hosts on the network when we could have avoided doing so. I also think that it is a common case. - aidan From owner-zeroconf@merit.edu Thu May 8 21:53:09 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19348 for ; Thu, 8 May 2003 21:53:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 90E5D91209; Thu, 8 May 2003 21:55:58 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5886F9120C; Thu, 8 May 2003 21:55:58 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5A9EE91209 for ; Thu, 8 May 2003 21:55:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 431505DE9A; Thu, 8 May 2003 21:55:57 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 2556F5DE75 for ; Thu, 8 May 2003 21:55:57 -0400 (EDT) Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h491tu6n025559 for ; Thu, 8 May 2003 18:55:56 -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 h491tr2J006610 for ; Thu, 8 May 2003 20:55:54 -0500 Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.9/8.12.8) with ESMTP id h491tqVI027041; Fri, 9 May 2003 11:55:52 +1000 (EST) Message-ID: <3EBB0AA8.30008@motorola.com> Date: Fri, 09 May 2003 11:55:52 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: Re: [LL12] [LL20] and a possible solution References: <28907.1049549805@munnari.OZ.AU> <3EB89E03.7090402@motorola.com> <1052326498.4604.43.camel@devil> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mika Liljeberg wrote: > I proposed a similar thing but I abandoned this line of thinking when I > realized that there is a chicken egg problem with LLMNR. You probably > need something like LLMNR to get the first destination address. So the > question is, what do you do if the first packet has a multicast > destination? You can't probe. You could let the packet go on the link > and hope for a response but then you have to decide if you allow a > tentative address as source address. > That's a good point. Using the tentative address just relies on the low probability of two nodes picking the same address, hence we don't seem to gain much. - aidan From owner-zeroconf@merit.edu Fri May 9 02:13: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 CAA05677 for ; Fri, 9 May 2003 02:13:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 95F969120D; Fri, 9 May 2003 02:16:32 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5FB0D9120F; Fri, 9 May 2003 02:16:32 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 373129120D for ; Fri, 9 May 2003 02:16:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1144A5DF26; Fri, 9 May 2003 02:16:31 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id 6DB1E5DF00 for ; Fri, 9 May 2003 02:16:27 -0400 (EDT) Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h496GQ9J020339 for ; Thu, 8 May 2003 23:16:26 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h496GInd006544 for ; Fri, 9 May 2003 01:16:23 -0500 Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.9/8.12.8) with ESMTP id h496GFVI007790; Fri, 9 May 2003 16:16:15 +1000 (EST) Message-ID: <3EBB47B0.3070902@motorola.com> Date: Fri, 09 May 2003 16:16:16 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Guttman Cc: zeroconf@merit.edu, Harald Alvestrand Subject: Re: New text for [LL4] No Examples of Applications References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit It looks to me that this text could resolve both LL4 and LL5. LL4 wants a list of protocols definately work LL5 wants a list of protocols that might break Describing the characteristics of applications that will cause them to fail sounds like the right approach to me. - aidan Erik Guttman wrote: > > Description of Issue No examples of applications > Submitter Name Harald Alvestrand > Submitter Email Address chair@ietf.org > Date first submitted 6 Feb 2003 > Reference > http://www.merit.edu/mail.archives/zeroconf/2003-01/msg00041.html > > http://www.merit.edu/mail.archives/zeroconf/2002-10/msg00000.html > Comment Type ['T'echnical | 'E'ditorial] T > Priority ['S' Must fix | '1' Should fix | '2' May fix ] 1 > Section A new introduction section? > Rationale/Explanation > of issue: There was a request for a list of example applications which > can safely be used with link-local addresses. > Lengthy description of problem: I supplied the following list: File > sharing (NFS, SMB), > Print sharing (LPD, IPP), Local file sharing & web browsing > (FTP, HTTP), Remote login (TELNET) > > This raised questions which I have not had the time, and lack enough > expertise to answer: > > o Doesn't NFSv3 include addresses? Will that cause NFSv3 > to fail? > o Doesn't NFSv4 and IPP carry domain names? DNS will not > have LL entries, most likely. Won't this cause NFSv4 > and IPP to fail? > > ============================================== > > Before coming up with text for this, I think that we need to have > agreement on the characteristics of applications that will cause them to > fail when used with LLv4 addresses. > > I do not believe that just because an application uses LLv4 addresses > that it will fail. The problem is not use by itself -- it is use of > linklocal addresses IPv4 addresses in the wrong context. > > If an application uses its LLv4 address in communicating with a host > off the link, it will break. However, if it uses that address in > communicating with a host on-link then that should not happen. > > In looking at this, I believe the problem is "leakage". Including an LLv4 > address in an off-link application exchange is an example of leakage -- > and I believe that this MUST NOT be done at any layer. > > Similarly, I do not believe that including domain names in an application > is by itself a problem -- unless it involves leakage. Examples of > leakage include using LLv4 addresses in DNS. Including a name in an > application where DNS is not configured among the conversants is not a > problem -- assuming LLMNR is available to resolve the name. > > If the above makes sense, then I do not think it is necessarily > appropriate to come up with "lists of applications" that will > automatically fail. Rather we should focus on what applications need to do > in order to be successful. Here is some proposed text: > > > Requested Change: > > "Use of linklocal IPv4 addresses in off-link communication is likely to > cause application failures. This can occur within any application that > includes embedded addresses, if an LLv4 addresses is embedded when > communicating with a host that is not on the link. Examples of > applications that include embedded addresses are found in [RFC3027]. This > includes IPsec, Kerberos 4/5, X-Windows/Xterm/Telnet, FTP, RSVP, SMTP, > SIP, Real Audio, H.323, and SNMP. > > In order to prevent use of LLv4 addresses in off-link communication, the > following cautionary measures are advised: > > a. Routable addresses should be used within applications whenever they are > available. > b. Names that are globally resolvable to routable addresses should be > used within applications whenever they are available. Names that are > resolvable only on the local link (such as through use of protocols such > as LLMNR) MUST NOT be used in off-link communication. This can be > prevented by using LLv4 addresses or names resolvable on the > local link when an LLv4 address is used as the source address in the > packet. > c. LLv4 addresses MUST NOT be configured in the DNS." > > > > From owner-zeroconf@merit.edu Fri May 9 04:38: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 EAA09425 for ; Fri, 9 May 2003 04:38:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 46A7F9120F; Fri, 9 May 2003 04:41:20 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0630691210; Fri, 9 May 2003 04:41:19 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0A58A9120F for ; Fri, 9 May 2003 04:41:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E706C5DF9E; Fri, 9 May 2003 04:41:18 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 6663D5DF76 for ; Fri, 9 May 2003 04:41:18 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id BAA03406; Fri, 9 May 2003 01:40:45 -0700 (PDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h498ehA22126; Fri, 9 May 2003 10:40:43 +0200 (MEST) Date: Fri, 9 May 2003 10:40:41 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: Aidan Williams Cc: Erik Guttman , zeroconf@merit.edu, Harald Alvestrand Subject: Re: New text for [LL4] No Examples of Applications In-Reply-To: <3EBB47B0.3070902@motorola.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Fri, 9 May 2003, Aidan Williams wrote: > It looks to me that this text could resolve both LL4 and LL5. > LL4 wants a list of protocols definately work > LL5 wants a list of protocols that might break > > Describing the characteristics of applications that will cause > them to fail sounds like the right approach to me. Indeed, Harald agreed that the suggested text satisfies his concerns. This was sent in private email to me, after I solicited Harald's response to this issue. Erik From owner-zeroconf@merit.edu Fri May 9 05:02: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 FAA09874 for ; Fri, 9 May 2003 05:02:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9588491210; Fri, 9 May 2003 05:05:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F33491211; Fri, 9 May 2003 05:05:31 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42E2F91210 for ; Fri, 9 May 2003 05:05:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1EE195DFAD; Fri, 9 May 2003 05:05:30 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-3.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id BFCC75DFA8 for ; Fri, 9 May 2003 05:05:29 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4995PWs001015; Fri, 9 May 2003 03:05:25 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h4995OA23513; Fri, 9 May 2003 11:05:24 +0200 (MEST) Date: Fri, 9 May 2003 11:05:22 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: John Schnizlein Cc: Erik Guttman , zeroconf@merit.edu Subject: Re: [LL3][LL21][LL29] Reconsideration --- Discuss till May 12 In-Reply-To: <4.3.2.7.2.20030506110901.0213a548@wells.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Tue, 6 May 2003, John Schnizlein wrote: > Please explain the reasons for your reversal. > Statements like "was flawed" and "reading recent comments", > which were apparently after the previous discussion deadline, > do not seem adequate to reverse the formal process of the WG. > > At 05:07 AM 5/5/2003, Erik Guttman wrote: > > >It seems my consensus call was flawed. After reading recent comments, I > >believe the right thing to do would be to accept LL21 as Robert Elz > >suggested. I believe that we should add the following advice to > >implementors: > > > > ''A sensible default for applications which are sending from a > > link-local address is to explicitely set the IP TTL to 1. This > > is not appropriate in all cases as some applications may require > > that the IP TTL be set to other values.'' > > > >Please send comments by May 12. If there is no further discussion on > >this topic, LL21 will be accepted and LL29 rejected. John, You are right, more context and specific information is required to discuss this point. Sorry I did not included it in the initial note. The consensus call was extremely rough. [LL3] Stuart Cheshire and some others are concerned to remain consistent with the earlier decision of WG. This serves Apple customers and those who implemented the protocol based on an earlier i-d. However: Many pointed out that checking the TTL of incoming datagrams & deciding whether to discard the packet on the basis of that would not interoperate with existing implementations. Christian Huitema pointed out that IP TTL is exposed to apps and under their control. Different apps set IP TTL for their own purposes and we cannot disallow or overrule that. Ralph Droms argued that IP TTL is well defined already and we have no business redefining it here. [LL29] (as accepted) stated: Any host sending an IPv4 packet with a source and/or destination address in the 169.254/16 prefix SHOULD set the TTL in the IP header to 1 by default. This includes multicast and broadcast packets with a source address in the 169.254/16 prefix. An application may set the TTL to any value, using established interfaces for this purpose, overriding the default. This suggested behavior enables the normal behavior of Internet routers to preclude leaking traffic that is supposed to be confined to a single link out into the Internet when the local link has an attachment to the Internet that it did not discover. Setting TTL to 1 precludes mistaken forwarding of link-local traffic even when proxy-ARP is used on a link. Concerns which have been related to me: - To the extent that we are trying to preserve backwards compatibility we do not serve this by recommending ttl=1. None of the existing implementations use this setting. (Bernard Aboba) - The whole point of this standard is to provide a standard which expresses what has been done by vendors and to give advice for how to make this interoperation as safe and non-disruptive to networks and higher level applications as possible. We should not extend well beyond the current well understood practice except as advice unless absolutely necessary. (Christian Huitema) [LL21] Aidan Williams and Robert Elz argued persuasively that we do not have consensus on this point. This conclusion, together with the cited 'advice' seems to be the best we can do. Please provide your input so we can close these issues for good. Best regards, Erik From owner-zeroconf@merit.edu Fri May 9 07:45:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13078 for ; Fri, 9 May 2003 07:45:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9D9E291212; Fri, 9 May 2003 07:48:33 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4F5E91213; Fri, 9 May 2003 07:48:31 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 866A191212 for ; Fri, 9 May 2003 07:47:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 676455E06F; Fri, 9 May 2003 07:47:49 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by segue.merit.edu (Postfix) with ESMTP id 036E95E036 for ; Fri, 9 May 2003 07:47:48 -0400 (EDT) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-270.cisco.com [10.82.241.14]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h49BlfZF015611; Fri, 9 May 2003 07:47:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20030509071705.0430bd30@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 May 2003 07:47:38 -0400 To: Erik Guttman From: John Schnizlein Subject: Re: [LL3][LL21][LL29] Reconsideration --- Discuss till May 12 Cc: zeroconf@merit.edu In-Reply-To: References: <4.3.2.7.2.20030506110901.0213a548@wells.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk Thanks, the context helps us focus on the important issues. The compatibility the WG should seek for a standards-track specification should be with Internet standards, such as the existing meaning of TTL, rather than installed base of a proprietary (pre-standards draft) implementation. LL3 redefines TTL, and has reported interoperability problems, but maintains compatibility with deployed Rendezvous. LL21 advocates that we ignore this problem and say nothing. LL29 includes accommodation for applications to interoperate with the proprietary implementation as a technical compromise. The way to publish an RFC to support interoperation with an already deployed implementation (even if it happens to re-interpret TTL) is as Informational, not standards-track. Why not do that? How does an argument that there is no consensus among three alternatives become an argument for selecting a particular one? The "advice" seems to shift compliance with the existing meaning of TTL from an official SHOULD to easily-ignored advice. Especially when consensus is "rough", the right course is the one that deviates least from existing standards rather than one that sets a particular point of the standard aside in favor of a particular novel implementation. After the formal process has concluded with a rough consensus is not a good time to argue for a different outcome. That practice calls into question the entire process of limited-duration debate on specific issues. It is worth noting that the discussion of LLMNR (in DNS-EXT) has recognized the incompatibility of redefining TTL and settled, after some debate there, on TTL=1 for both unicast and multicast. My impression is that this decision followed the rough consensus in Zero-Conf; reversing the TTL position in Zero-Conf threatens to keep this issue cycling for a long time. John At 05:05 AM 5/9/2003, Erik Guttman wrote: >... more context and specific information is required to discuss >this point. Sorry I did not included it in the initial note. > >The consensus call was extremely rough. > > [LL3] Stuart Cheshire and some others are concerned to remain > consistent with the earlier decision of WG. This serves Apple > customers and those who implemented the protocol based on an > earlier i-d. > > However: > > Many pointed out that checking the TTL of incoming datagrams & > deciding whether to discard the packet on the basis of that > would not interoperate with existing implementations. > > Christian Huitema pointed out that IP TTL is exposed to apps > and under their control. Different apps set IP TTL for their > own purposes and we cannot disallow or overrule that. > > Ralph Droms argued that IP TTL is well defined already and > we have no business redefining it here. > > [LL29] (as accepted) stated: > > Any host sending an IPv4 packet with a source and/or destination > address in the 169.254/16 prefix SHOULD set the TTL in the IP > header to 1 by default. This includes multicast and broadcast > packets with a source address in the 169.254/16 prefix. An > application may set the TTL to any value, using established > interfaces for this purpose, overriding the default. > > This suggested behavior enables the normal behavior of Internet > routers to preclude leaking traffic that is supposed to be > confined to a single link out into the Internet when the local > link has an attachment to the Internet that it did not discover. > Setting TTL to 1 precludes mistaken forwarding of link-local > traffic even when proxy-ARP is used on a link. > >Concerns which have been related to me: > > - To the extent that we are trying to preserve backwards compatibility > we do not serve this by recommending ttl=1. None of the existing > implementations use this setting. (Bernard Aboba) > > - The whole point of this standard is to provide a standard which > expresses what has been done by vendors and to give advice for how > to make this interoperation as safe and non-disruptive to networks > and higher level applications as possible. We should not extend > well beyond the current well understood practice except as advice > unless absolutely necessary. (Christian Huitema) > > [LL21] Aidan Williams and Robert Elz argued persuasively that we do > not have consensus on this point. > >This conclusion, together with the cited 'advice' seems to be the best >we can do. Please provide your input so we can close these issues for >good. > >Best regards, > >Erik From owner-zeroconf@merit.edu Fri May 9 16:51: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 QAA01801 for ; Fri, 9 May 2003 16:51:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A0EB3912D5; Fri, 9 May 2003 16:54:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63FFB912D6; Fri, 9 May 2003 16:54:34 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 78CFA912D5 for ; Fri, 9 May 2003 16:54:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 61A455E1B6; Fri, 9 May 2003 16:54:33 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id E4E345E1AF for ; Fri, 9 May 2003 16:54:32 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.9/8.12.9) with ESMTP id h49KsW3h026374 for ; Fri, 9 May 2003 13:54:32 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 9 May 2003 13:54:31 -0700 Received: from apple.com (graejo5.apple.com [17.202.43.251]) by scv2.apple.com (8.12.9/8.12.9) with ESMTP id h49KsV7k002296 for ; Fri, 9 May 2003 13:54:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v569) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6D9EAE9D-8260-11D7-ADD9-000A959D832C@apple.com> Content-Transfer-Encoding: 7bit From: Joshua Graessley Subject: Re: [LL3][LL21][LL29] Reconsideration --- Discuss till May 12 Date: Fri, 9 May 2003 13:54:29 -0700 To: zeroconf@merit.edu X-Mailer: Apple Mail (2.569) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I prefer LL3, the modifications to not require TTL 255 checks. This is the least amount of change from the previous IPv4LL drafts. It's time to stop churning on the same issues and get this thing out. If there can be no agreement, then I think LL21 is an acceptable alternative. I don't think any mention of the TTL should be made, including the recommended text below. -josh On Monday, May 5, 2003, at 2:07, Erik Guttman wrote: > It seems my consensus call was flawed. After reading recent comments, > I > believe the right thing to do would be to accept LL21 as Robert Elz > suggested. I believe that we should add the following advice to > implementors: > > ''A sensible default for applications which are sending from a > link-local address is to explicitely set the IP TTL to 1. This > is not appropriate in all cases as some applications may require > that the IP TTL be set to other values.'' > > Please send comments by May 12. If there is no further discussion on > this topic, LL21 will be accepted and LL29 rejected. From owner-zeroconf@merit.edu Sat May 10 06:06: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 GAA27832 for ; Sat, 10 May 2003 06:06:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4B86591227; Sat, 10 May 2003 06:09:12 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 11861912D6; Sat, 10 May 2003 06:09:12 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1128A91227 for ; Sat, 10 May 2003 06:09:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F19C55E36E; Sat, 10 May 2003 06:09:10 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 6DB305E09A for ; Sat, 10 May 2003 06:09:09 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h4AA8sj06659; Sat, 10 May 2003 17:08:55 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4AA8dY19858; Sat, 10 May 2003 17:08:40 +0700 (ICT) From: Robert Elz To: John Schnizlein Cc: Erik Guttman , zeroconf@merit.edu Subject: Re: [LL3][LL21][LL29] Reconsideration --- Discuss till May 12 In-Reply-To: <4.3.2.7.2.20030509071705.0430bd30@wells.cisco.com> References: <4.3.2.7.2.20030509071705.0430bd30@wells.cisco.com> <4.3.2.7.2.20030506110901.0213a548@wells.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 May 2003 17:08:39 +0700 Message-ID: <19856.1052561319@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 09 May 2003 07:47:38 -0400 From: John Schnizlein Message-ID: <4.3.2.7.2.20030509071705.0430bd30@wells.cisco.com> | How does an argument that there is no consensus among three | alternatives become an argument for selecting a particular one? I don't think that's quite what was intended. More along the lines of "there's no consensus about which particular TTL should be specified, so perhaps the best thing to do is to specify none". The "particular one" was just that - that is, I looked at the arguments for TTL=1 and TTL=255, and couldn't see any reason to prefer one over the other, so I suggested just not specifying either. The way this group is attempting to make actual progress is by making every suggestion become an "issue" - so to allow for the possibility of specifying nothing, that had to be one of the issues. Even though the TTL=255 case is an issue with a higher number, the 1 vs 255 choice had been around for a long time, and was going nowhere. LL21 is just what you get when you reject both LL3 and LL29 for lack of consensus for either of those, it is kind of the default case, not something new of itself. | Especially when consensus is "rough", the right course is the one | that deviates least from existing standards There is no existing "standard" - there are two (maybe 3 now) existing implementations, one of which used TTL=255 (and the other original one, if I recall what I have read correctly, and I may not, so apologies if this is wrong, picked 128). That is, there isn't even an existing common implementation. This doc is intended to become the first standard in this area. | It is worth noting that the discussion of LLMNR (in DNS-EXT) has | recognized the incompatibility of redefining TTL and settled, | after some debate there, on TTL=1 for both unicast and multicast. That makes sense (multicast really wants TTL=1 for good reason, unicast doesn't much care, but using the same value for both simplifies things). On the other hand, Rendezvous seems to want TTL=255, which is also fine. | My impression is that this decision followed the rough consensus | in Zero-Conf; reversing the TTL position in Zero-Conf threatens | to keep this issue cycling for a long time. Are you sure it wasn't just that they no longer felt obliged by zeroconf to use TTL=255 for the unicast case? kre From owner-zeroconf@merit.edu Sat May 10 15:38:52 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07309 for ; Sat, 10 May 2003 15:38:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A5F859122F; Sat, 10 May 2003 15:41:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77A6E91230; Sat, 10 May 2003 15:41:36 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 71A6C9122F for ; Sat, 10 May 2003 15:41:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 59B835E45C; Sat, 10 May 2003 15:41:35 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id E8F7E5E45B for ; Sat, 10 May 2003 15:41:34 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h4AJfYgM003851 for ; Sat, 10 May 2003 15:41:34 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h4AJfXF5029264 for ; Sat, 10 May 2003 15:41:34 -0400 (EDT) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h4AJfVU8004651 for ; Sat, 10 May 2003 15:41:32 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Sat, 10 May 2003 15:41:30 -0400 Subject: Re: [LL3][LL21][LL29] Reconsideration --- Discuss till May 12 From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <19856.1052561319@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 05/10/2003 06:08, "Robert Elz" did proclaim: > The way this group is attempting to make actual progress is by making > every suggestion become an "issue" - so to allow for the possibility > of specifying nothing, that had to be one of the issues. Even though > the TTL=255 case is an issue with a higher number, the 1 vs 255 > choice had been around for a long time, and was going nowhere. I say, Erik should write the number 1 on the heads side of a coin, and the number 255 on the other. Flip the coin. Let it land on the ground. Whatever number is not facing the ground is the TTL value. The only time there will be a second flip is if the coin lands on edge. This seems to be the only way that a number will ever be picked, and it's about as valid as any other reason to pick one at this point, and it's for sure a lot faster. john -- John C. Welch Consultant III Office Computing Practice (IS) (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue May 13 04:30: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 EAA00783 for ; Tue, 13 May 2003 04:30:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 61BCA91271; Tue, 13 May 2003 04:33:40 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3361591275; Tue, 13 May 2003 04:33:40 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2364791271 for ; Tue, 13 May 2003 04:33:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 08BB05E07B; Tue, 13 May 2003 04:33:39 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-2.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 789D85E032 for ; Tue, 13 May 2003 04:33:38 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4D8XYY9019222; Tue, 13 May 2003 02:33:34 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h4D8XXA16239; Tue, 13 May 2003 10:33:33 +0200 (MEST) Date: Tue, 13 May 2003 10:33:30 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: Harald Alvestrand Subject: WG Action - ACCEPT [LL4] No Examples of Applications Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk See http://www.spybeam.org/ll4.html and http://www.spybeam.org/ll5.html for details about the issues. Action: [LL4] Accepted [LL5] Closed Accepting the text supplied by Bernard Aboba satisfies both LL4 and LL5 considerations. Implication: Create a new introduction section with the text: Use of linklocal IPv4 addresses in off-link communication is likely to cause application failures. This can occur within any application that includes embedded addresses, if an LLv4 addresses is embedded when communicating with a host that is not on the link. Examples of applications that include embedded addresses are found in [RFC3027]. This includes IPsec, Kerberos 4/5, X-Windows/Xterm/Telnet, FTP, RSVP, SMTP, SIP, Real Audio, H.323, and SNMP. In order to prevent use of LLv4 addresses in off-link communication, the following cautionary measures are advised: a. Routable addresses should be used within applications whenever they are available. b. Names that are globally resolvable to routable addresses should be used within applications whenever they are available. Names that are resolvable only on the local link (such as through use of protocols such as LLMNR) MUST NOT be used in off-link communication. This can be prevented by using LLv4 addresses or names resolvable on the local link when an LLv4 address is used as the source address in the packet. c. LLv4 addresses MUST NOT be configured in the DNS." Erik Guttman ZEROCONF WG chair From owner-zeroconf@merit.edu Tue May 13 04:37:08 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00882 for ; Tue, 13 May 2003 04:37:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C74A391275; Tue, 13 May 2003 04:40:01 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94CF991277; Tue, 13 May 2003 04:40:01 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6E8E191275 for ; Tue, 13 May 2003 04:40:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 51A8B5E07B; Tue, 13 May 2003 04:40:00 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-3.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id C0D335E09D for ; Tue, 13 May 2003 04:39:59 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4D8dwRh029433 for ; Tue, 13 May 2003 02:39:58 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h4D8dvA16512 for ; Tue, 13 May 2003 10:39:57 +0200 (MEST) Date: Tue, 13 May 2003 10:39:54 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: WG Action - REJECT [LL29] Link-local sources should specify TTL=1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Action: [LL29] Reject Please note that this reverses an earlier decision. Instead LL21 is adopted, with minor changes (see the separate message). The reasons for this reversal were - Very rough consensus the first call. - Dissatisfaction with the consensus call from many working group members reopened discussion. - There is now a clear (though still rough) consensus for LL21. - The difference between LL21 as ammended by the admonition that TTL=1 is a sensible default and the use of 'SHOULD' in LL29 did not seem to be a huge difference. We need to put this issue to rest (it is the last unresolved issue). Erik Guttman ZEROCONF WG Chair From owner-zeroconf@merit.edu Tue May 13 04:43:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00980 for ; Tue, 13 May 2003 04:43:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 915E791277; Tue, 13 May 2003 04:45:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5EEB491278; Tue, 13 May 2003 04:45:54 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5911E91277 for ; Tue, 13 May 2003 04:45:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D44B85E0A4; Tue, 13 May 2003 04:45:52 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 52B505E0A2 for ; Tue, 13 May 2003 04:45:52 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4D8joPH026264 for ; Tue, 13 May 2003 01:45:51 -0700 (PDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h4D8jnA16715 for ; Tue, 13 May 2003 10:45:49 +0200 (MEST) Date: Tue, 13 May 2003 10:45:46 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG Action - ACCEPT [LL21] Alternate text for: TTL=255 on send, check , on receive? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Note: This reverses the wg consensus call on this issue from Reject to Accept. Action: [LL21] Accept Notes: For detailed information about this consensus call, please see the message on REJECT LL29. After much discussion it became clear that there was not a consensus for either LL3 or LL29. It is clear that there is rough consensus that we should at least give some advice, hence, add the following in place of the first two paragraphs of section 2.7: ''A sensible default for applications which are sending from a link-local address is to explicitely set the IP TTL to 1. This is not appropriate in all cases as some applications may require that the IP TTL be set to other values.'' Erik Guttman ZEROCONF WG chair From owner-zeroconf@merit.edu Tue May 13 05:03: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 FAA01286 for ; Tue, 13 May 2003 05:03:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8B5991278; Tue, 13 May 2003 05:06:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7024C91279; Tue, 13 May 2003 05:06:21 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5E2AA91278 for ; Tue, 13 May 2003 05:06:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 41BEF5E066; Tue, 13 May 2003 05:06:20 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-3.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id E1CB15DDEE for ; Tue, 13 May 2003 05:06:19 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4D96IRh014479 for ; Tue, 13 May 2003 03:06:18 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h4D96GA17592; Tue, 13 May 2003 11:06:16 +0200 (MEST) Date: Tue, 13 May 2003 11:06:13 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: erik.nordmark@sun.com Subject: WG Action - ACCEPT [LL31] Alternate text for 'Does shorter timeouts for specific link technology lead to problems?' Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Action: [LL31] Accept Notes: This is a follow on to the rejection of LL12 and LL20. All steps to resolve these three items are described below. To do: In Section 2.2 Replace: When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range zero to two seconds, and should then send four probe packets, spaced two seconds apart. This initial random delay helps ensure that a large number of hosts powered on at the same time do not all send their initial probe packets simultaneously. With: When ready to begin probing, the host should then wait for a random time interval selected uniformly in the range zero to one seconds, and should then send three probe packets, spaced randomly, zero to one seconds apart. And: Add to a (new) appendix section: Ethernet switches/bridges following IEEE 802.3D defaults, normally block packets for up to approximately 45 seconds immediately after a bridge port has been enabled. Techniques for avoiding adverse impact of such L2 behavior is outside of the scope of this protocol. And: Section 2.8 from: The time values specified above result in a delay of 8-10 seconds before a chosen IP address may be used. ^^^^ To: The time values specified above result in a delay of around 3.5 seconds before a chosen IP address may be used. ^^^^^^^^^^ From: For a desktop machine on Ethernet, 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. To: For a desktop machine on Ethernet, this may not be a great problem, but for other types of device, particularly portable hand-held wireless devices, this delay ^^^^ before networking services becomes available may not be acceptable. From owner-zeroconf@merit.edu Tue May 13 05:07: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 FAA01420 for ; Tue, 13 May 2003 05:07:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2E3F191279; Tue, 13 May 2003 05:10:46 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9D139127A; Tue, 13 May 2003 05:10:45 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0014791279 for ; Tue, 13 May 2003 05:10:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E1B985E0AE; Tue, 13 May 2003 05:10:44 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 630495E0AD for ; Tue, 13 May 2003 05:10:44 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id CAA10783; Tue, 13 May 2003 02:10:11 -0700 (PDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h4D9A8A17804; Tue, 13 May 2003 11:10:08 +0200 (MEST) Date: Tue, 13 May 2003 11:10:05 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Cc: Harald Alvestrand Subject: WG Action - CLOSE [LL5] Higher layer protocol considerations is not sufficiently draconian Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Action: [LL5] Closed Notes: - LL4 has been Accepted and its text satisfies both LL4 and LL5. See http://www.spybeam.org/ll4.html and http://www.spybeam.org/ll5 for further details on this issue and the message to the WG list accepting the resolution to LL4. Erik Guttman ZEROCONF WG chair From owner-zeroconf@merit.edu Tue May 13 05:10: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 FAA01486 for ; Tue, 13 May 2003 05:10:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 105989127A; Tue, 13 May 2003 05:13:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CFFB59127B; Tue, 13 May 2003 05:13:03 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D863C9127A for ; Tue, 13 May 2003 05:13:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD3F15E0B0; Tue, 13 May 2003 05:13:02 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 3F8055E0AE for ; Tue, 13 May 2003 05:13:02 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id CAA12842 for ; Tue, 13 May 2003 02:13:00 -0700 (PDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h4D9CwA17959 for ; Tue, 13 May 2003 11:12:59 +0200 (MEST) Date: Tue, 13 May 2003 11:12:56 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: All issues have been accounted for Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk According to my records, all zeroconf issues have been resolved. Once we have a new draft, we will take this to WG last call. The result will then be given to the IESG so they can consider advancing it to Proposed Standard RFC. Spybeam will be updated in a few minutes - see http://www.spybeam.org/issues for the final resolution of all issues. Thanks for all your hard work over recent months. Erik Guttman ZEROCONF WG chair From owner-zeroconf@merit.edu Tue May 13 07:48: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 HAA04650 for ; Tue, 13 May 2003 07:48:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 606C69127C; Tue, 13 May 2003 07:51:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29EA89127D; Tue, 13 May 2003 07:51:27 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E7979127C for ; Tue, 13 May 2003 07:51:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 21BC75E112; Tue, 13 May 2003 07:51:26 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 970855DFCD for ; Tue, 13 May 2003 07:51:25 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA24479 for ; Tue, 13 May 2003 04:51:23 -0700 (PDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h4DBpMA26783 for ; Tue, 13 May 2003 13:51:22 +0200 (MEST) Date: Tue, 13 May 2003 13:51:19 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: spybeam has been updated In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Tue, 13 May 2003, Erik Guttman wrote: > http://www.spybeam.org/issues for the final resolution of all issues. Correction: Please see http://www.spybeam.org/issues.html Regards, Erik From owner-zeroconf@merit.edu Tue May 13 11:32: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 LAA16928 for ; Tue, 13 May 2003 11:32:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4FF1E91286; Tue, 13 May 2003 11:35:10 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 173A691287; Tue, 13 May 2003 11:35:10 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0B83891286 for ; Tue, 13 May 2003 11:35:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E7FCE5DDCB; Tue, 13 May 2003 11:35:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by segue.merit.edu (Postfix) with ESMTP id D479A5DDAD for ; Tue, 13 May 2003 11:35:07 -0400 (EDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h4DFbXHZ019598; Tue, 13 May 2003 18:37:34 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h4DFbVwO019597; Tue, 13 May 2003 18:37:31 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: All issues have been accounted for From: Mika Liljeberg To: Erik Guttman Cc: zeroconf@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1052840250.17101.15.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 13 May 2003 18:37:31 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit What was the conclusion on revisiting LL23? The connectivity problems caused by LL23 are still unresolved. MikaL On Tue, 2003-05-13 at 12:12, Erik Guttman wrote: > According to my records, all zeroconf issues have been resolved. Once > we have a new draft, we will take this to WG last call. The result will > then be given to the IESG so they can consider advancing it to Proposed > Standard RFC. > > Spybeam will be updated in a few minutes - see > http://www.spybeam.org/issues for the final resolution of all issues. > > Thanks for all your hard work over recent months. > > Erik Guttman > ZEROCONF WG chair > > From owner-zeroconf@merit.edu Wed May 14 03:10: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 DAA07680 for ; Wed, 14 May 2003 03:10:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9F11491298; Wed, 14 May 2003 03:13:44 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55AD29120D; Wed, 14 May 2003 03:13:44 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BA4D29120D for ; Wed, 14 May 2003 03:13:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8F0225DFC2; Wed, 14 May 2003 03:13:42 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-3.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 1E6BF5DED8 for ; Wed, 14 May 2003 03:13:42 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4E7Ddsa011060; Wed, 14 May 2003 01:13:40 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h4E7DcA05936; Wed, 14 May 2003 09:13:38 +0200 (MEST) Date: Wed, 14 May 2003 09:13:34 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Cc: mika.liljeberg@welho.com Subject: Final word - ACCEPT [LL23] Don't configure needless LL addresses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On 13 May 2003 18:37:31 +0300 Mika Liljeberg wrote: > > What was the conclusion on revisiting LL23? > > The connectivity problems caused by LL23 are still unresolved. Mika, The final word on this is that the ACCEPT [LL23] decision stands. The reasons for this are as follows: a) The decision has been validated by a parallel decision being made for LLMNR. In this case, once a host has a routable address the link-local is no longer advertised. b) concern (2) below is a matter for implementors to decide, depending on their priorities. We 'violate' only a suggestion (a MAY) in RFC 2131 by not requiring that hosts hold onto their leases when they restart/attach to a network/etc & instead use LL autoconf. c) The problems posed by an open-ended scoped address architecture posed in the message where LL23 reconsideration was broached were not taken up. d) As stated in that message (attached below) - the bar is high. No new alternatives or additional arguments supporting a change in the ACCEPT were presented during the weeks since this message was posted. I realize that the consensus call here is rough, but a call *must* be made, *has* been made, and stands. Thanks, Erik Guttman ZEROCONF WG chair --------------------------------------------------------------------- I have received requests from three WG participants who have concerns both about the decision to accept LL23 and the process by which it was decided. Regarding the process - I am doing my best to include all points of view and discover the consensus, even if it is rough. If I could do a better job of this, please let me know and offer concrete suggestions. We do not have the luxury of leaving these decisions for a brighter day when we finally collectively emerge from the cave of ignorance. Further, we have to consider the context in which we are making these decisions: We must answer IESG issues expressed *LAST OCTOBER* so we can get this document out as a standards track RFC. Regarding the decision - The following concerns have been expressed to me (1) While LL23 instructs a host to use a routable address instead of a link-local address as its source address (if it has one), the host can keep using link-local addresses for connections underway and even accept new communications on the link-local address. Thus, the scoped address (source address selection) problem does not go away - it is only 'contained' to some extent. (2) If we 'give up' our link-local address and cease to advertise it (using LLMNR, SLP, etc) as long as we have a valid DHCP lease, there are situations where we will roam and not use link-local auto-configuration (where we could). If we eagerly shed our DHCP configuration in INIT-REBOOT state and we do not hear from the DHCP server (see (3) in Sec 3.2 of RFC 2131), we may lose our legitimate configuration in a network where we should keep it. This problem is exacerbated by the pressure for rapid usability of systems. Waiting 5 minutes is not acceptable. LL23 forces vendors to trade off rapid usability and robust operation. As WG chair I must emphasize that the bar on revisiting a close issue is very high. We must show either that the resolution is totally broken or that a significantly better alternative exists which can achieve WG consensus. - An alternative which leaves open issues of scoped address architecture for an indefinite period of time has been shown to not achieve WG consensus and leave several issues open which will prove very difficult to address without a 'transition' mechanism (namely LL1, LL4 and LL5). - Is (1) really a problem, given that only 'open' connections and 'accepted' connections are possible with link-local after a routable configuration occurred? - We should explore (2) more. Can we give guidance for timers and express caveats like - if you eagerly give up DHCP configuration, you MUST regularly attempt to reenter INIT-REBOOT and resume use of the configured address if the DHCP server responds. Or, you should attempt to send a ICMP message to your configured router and if it responds, continue to use the routable address even if DHCP doesn't respond, etc. Next steps - Those who are intent on revisiting this point, please post a message to the list expressing why we must do so, how we can meet existing concerns (see LL1, LL4 and LL5), and why your proposal is better than LL23. If there is rough consensus support for your proposal - we will create an issue to track it and take it through 1 week last call. Remember the bar is high. We cannot keep cycling over decisions unless there is an extremely compelling alternative. I hope that those of you who were not satisfied with the process by which we arrived at an ACCEPT of LL23 rough consensus call will find that this manner of revisiting LL23 is fair and appropriate. Erik Guttman Zeroconf WG chair From owner-zeroconf@merit.edu Thu May 15 15:17:03 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20315 for ; Thu, 15 May 2003 15:17:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E05DB9122A; Thu, 15 May 2003 15:19:59 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B40D391231; Thu, 15 May 2003 15:19:59 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AA1589122A for ; Thu, 15 May 2003 15:19:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 98CCC5E01B; Thu, 15 May 2003 15:19:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by segue.merit.edu (Postfix) with ESMTP id 98E475E00D for ; Thu, 15 May 2003 15:19:57 -0400 (EDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h4FJMRHZ001511; Thu, 15 May 2003 22:22:28 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h4FJMPmp001510; Thu, 15 May 2003 22:22:25 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Final word - ACCEPT [LL23] Don't configure needless LL addresses From: Mika Liljeberg To: Erik Guttman Cc: zeroconf@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1053026544.21141.48.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 15 May 2003 22:22:25 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-05-14 at 10:13, Erik Guttman wrote: > a) The decision has been validated by a parallel decision being made > for LLMNR. In this case, once a host has a routable address the > link-local is no longer advertised. Unfortunately that decision is rather pointless, since two nodes with global addresses and matching prefixes are likely to have access to a DNS server and LLMNR will never be invoked. If one of the two nodes is not on the home link, the nodes will be unable to communicate because their on-link prefixes will not match. If one of the two nodes only has a LL address, they will be unable to communicate because (again) their on-link prefixes will not match. > b) concern (2) below is a matter for implementors to decide, depending > on their priorities. We 'violate' only a suggestion (a MAY) in > RFC 2131 by not requiring that hosts hold onto their leases when > they restart/attach to a network/etc & instead use LL autoconf. Yes, let's leave it to the implementors to fix the broken specification: 1) Nodes having a valid DHCP lease will not benefit from zero configuration, unless the user manually releases the configured address. 2) Nodes having a manually configured address will not benefit from zero configuration, unless the user manually unconfigures the configuerd address. 3) Nodes having only a LL address will be unable to communicate with nodes having a global address, unless the user manually adds an appropriate on-link route for the link. See anything wrong with this picture? > c) The problems posed by an open-ended scoped address architecture > posed in the message where LL23 reconsideration was broached were > not taken up. This is a minor issue compared to b). Worrying about niche applications is pointless when point-to-point communication between two nodes on the same link is not working. MikaL From owner-zeroconf@merit.edu Fri May 16 06:07: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 GAA18060 for ; Fri, 16 May 2003 06:07:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B9972912E2; Fri, 16 May 2003 06:10:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8EE3D912E3; Fri, 16 May 2003 06:10:27 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7520A912E2 for ; Fri, 16 May 2003 06:10:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5E4E95DE4F; Fri, 16 May 2003 06:10:26 -0400 (EDT) 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 0F2155DE45 for ; Fri, 16 May 2003 06:10:26 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4GAANY9026716; Fri, 16 May 2003 04:10:24 -0600 (MDT) Received: from sun.com (vpn-129-159-0-55.EMEA.Sun.COM [129.159.0.55]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h4GAAJw27718; Fri, 16 May 2003 12:10:20 +0200 (MEST) Message-ID: <3EC4B876.4070206@sun.com> Date: Fri, 16 May 2003 12:07:50 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: Re: Final word - ACCEPT [LL23] Don't configure needless LL addresses References: <1053026544.21141.48.camel@devil> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mika Liljeberg wrote: > On Wed, 2003-05-14 at 10:13, Erik Guttman wrote: > >>a) The decision has been validated by a parallel decision being made >> for LLMNR. In this case, once a host has a routable address the >> link-local is no longer advertised. > > > Unfortunately that decision is rather pointless, since two nodes with > global addresses and matching prefixes are likely to have access to a > DNS server and LLMNR will never be invoked. I disagree. There are several important cases where the hosts will not be able to access DNS and for which LLMNR is crucial. The DNS server may not be up, the network may be partitioned so that local hosts cannot reach the DNS server, etc. > If one of the two nodes is not on the home link, the nodes will be > unable to communicate because their on-link prefixes will not match. > > If one of the two nodes only has a LL address, they will be unable to > communicate because (again) their on-link prefixes will not match. Why? LL23 says 'if you have a routeable address, use it for new connections and advertise it.' It does not say that hosts cannot (a) respond to hosts using a LL prefix (b) continue to communicate using an LL address (for open connections) A host H using a LL address can - use service discovery or name resolution to find the address of an on-link host H2 to communicate with (whether this discovered H2 has a ll or routeable address) - establish communication with H2 - if that communication fails, because the peer H2 has renumbered say, the H can initiate service discovery or name resolution to find its new address. The host H2 could have gotten a routable address and stopped advertising its ll address, but H can still find it. - H can send H2 messages, H2 can respond. Note that *existing hosts* not yet supporting this protocol will not be able to respond, since if H is not on the same subnet as H2, H2 will forward the message to the router. The router will toss the packet into the bit bucket since the destination address for H is link-local, if the router has been properly configured. If it has not been properly configured, the router will probably forward the packet along its default path. However, if H2 supports this protocol specification, it will use ARP to resolve the address of H (since it is in the link-local prefix) and send the message directly to H. If this is not clear in the specification, we need to open a new issue describing the process. Here are the scenarios: Host H2 has LL has routable has address and knows routable how to foward to LL (legacy) Host H has LL + no routers H can discover H can discover H2 H can't dis- H2 and ex- and exchange cover H2 as change packets packets H2 cannot send to H. H2 & H are not on the same subnet. + Routers will as above as above H can't dis- drop pkts with cover H2 as LL src or LL H2 & H are dest (as not on the specified) same subnet. H2 will fwd to a router which will drop the pkt + Routers will as above as above H can't dis- forward pkts cover H2 as with LL src or H2 & H are LL dest (not not on the compliant with same subnet. this spec) H2 will fwd to a router which will do something wrong with the packet. Does anyone disagree with the above assessment? Basicly it says that if the specification is followed, communication is possible between a host with LL & LL or LL and routable configuration, provided that the host with routable configuration knows how to communicate with a host with LL configuration. >>b) concern (2) below is a matter for implementors to decide, depending >> on their priorities. We 'violate' only a suggestion (a MAY) in >> RFC 2131 by not requiring that hosts hold onto their leases when >> they restart/attach to a network/etc & instead use LL autoconf. > > > Yes, let's leave it to the implementors to fix the broken specification: > > 1) Nodes having a valid DHCP lease will not benefit from zero > configuration, unless the user manually releases the configured address. That is not what LL23 says. LL23 only says that if you have routable configuration, use it. It does not say under which situations you consider yourself to have routable configuration. That is up to the vendor. For example, when a host wakes up after sleeping or determines that they have lost and then recovered network connectivity - what do they do? They may try their best to find the dhcp server, their router, whatever, and if they can't they may give up. We do not have to specify this here. > 2) Nodes having a manually configured address will not benefit from zero > configuration, unless the user manually unconfigures the configuerd > address. If the nodes know how to communicate with a LL host (see discussion above) they do gain. They are able to communicate with any hosts on the local link who support LL. This is better than the situation we are in today, where hosts do not know how to communicate with them, right? > 3) Nodes having only a LL address will be unable to communicate with > nodes having a global address, unless the user manually adds an > appropriate on-link route for the link. This is only the case for 'legacy hosts' which do not understand this specification. > See anything wrong with this picture? I think that the problem may be that we do not have the picture sufficiently colored in yet. We do not sppear to be looking at the same picture. Erik From owner-zeroconf@merit.edu Fri May 16 13:50:52 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04913 for ; Fri, 16 May 2003 13:50:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 19BB39123D; Fri, 16 May 2003 13:53:50 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DDA6891243; Fri, 16 May 2003 13:53:49 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8A8199123D for ; Fri, 16 May 2003 13:53:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E2EA5E14F; Fri, 16 May 2003 13:53:48 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by segue.merit.edu (Postfix) with ESMTP id 5D0575E149 for ; Fri, 16 May 2003 13:53:47 -0400 (EDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h4GHuJHZ006125; Fri, 16 May 2003 20:56:20 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h4GHuHE0006124; Fri, 16 May 2003 20:56:17 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Final word - ACCEPT [LL23] Don't configure needless LL addresses From: Mika Liljeberg To: Erik Guttman Cc: zeroconf@merit.edu In-Reply-To: <3EC4B876.4070206@sun.com> References: <1053026544.21141.48.camel@devil> <3EC4B876.4070206@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1053107776.21141.126.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 16 May 2003 20:56:16 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Erik, Thanks for the thorough response. In the interest of keeping things focused on the main problem, I'm only responding to the scenarios table. I've taken the liberty of filling in the routing tables to illustrate my point. On Fri, 2003-05-16 at 13:07, Erik Guttman wrote: > If this is not clear in the specification, we need to open a new > issue describing the process. Here are the scenarios: > Host H2 > > has LL has routable has > address and knows routable > how to foward to LL (legacy) Route tables: 169.254/16 ->link a.b.c.d/x ->link a.b.c.d/x ->link 169.254/16 ->link > Host H has LL Route table: 169.254/16 -> link > + no routers H can discover H can discover H2 H can't dis- > H2 and ex- and exchange cover H2 as > change packets packets H2 cannot > send to H. > H2 & H are > not on the > same subnet. > TRUE FALSE. H2 adver- The reverse tizes its global is true as address but H well. H does only has a route not have a for LL destina- route for H2 tions. Host H has routable address and knows how to send to LL Route table: e.f.g.h/y -> link BROKEN. H adver BROKEN. Both H and As above. 169.254/16 -> link tises global H2 advertise global address but H2 addresses but can't only has a rou- communicate because te for LL. they don't have routes for each other. I left out the cases with default routers, since the problems are essentially the same. The only real difference is that nodes away from the home link will have a default gateway route pointing to /dev/null in addition to having a bogus netmask. > Does anyone disagree with the above assessment? I do. As shown by the above table, only the trivial cases work: 1) LL <-> LL 2) global <-> global, when the subnet masks are same In all other cases the nodes have mismatching on-link routes, which prevent communication, even though the nodes are on the same link. > I think that the problem may be that we do not have the picture > sufficiently colored in yet. We do not sppear to be looking at > the same picture. I think the table above is a good start. Maybe others have a different idea about how the routing tables are populated? Let's work on it. MikaL From owner-zeroconf@merit.edu Sat May 17 10:43: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 KAA09325 for ; Sat, 17 May 2003 10:43:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0F14E9122C; Sat, 17 May 2003 10:45:42 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6B2691236; Sat, 17 May 2003 10:45:41 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BCB559122C for ; Sat, 17 May 2003 10:45:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 61DE75E1A7; Sat, 17 May 2003 10:45:40 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id AA3055E12B for ; Sat, 17 May 2003 10:45:39 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4HEjbx9007640; Sat, 17 May 2003 07:45:38 -0700 (PDT) Received: from sun.com (vpn-129-159-0-63.EMEA.Sun.COM [129.159.0.63]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h4HEjZw24651; Sat, 17 May 2003 16:45:35 +0200 (MEST) Message-ID: <3EC64A79.3030105@sun.com> Date: Sat, 17 May 2003 16:43:05 +0200 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: Erik Guttman Cc: Mika Liljeberg , zeroconf@merit.edu Subject: Re: Final word - ACCEPT [LL23] Don't configure needless LL addresses References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sorry to reply to myself, but I wanted to clarify one statement I made. Erik Guttman wrote: > Once we rejected LL we all knew that we would have to face the > transition problem, both ways, eventually. I meant once we rejected LL19 and accepted LL23, it opened the door to the transition problem. Hosts configure LL, then configure routable and in some cases, may configure LL again. LL23 does not state under what conditions one considers that a host is configured with a global address. This cannot be stated generally, since some hosts are mobile, some hosts sleep/wake, some hosts may be multihomed with one home on a local link, the other on a routable link (which goes up and down), and many other possibilities. Erik From owner-zeroconf@merit.edu Sat May 17 12:07:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10777 for ; Sat, 17 May 2003 12:07:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A5D7D91242; Sat, 17 May 2003 12:10:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 716C391244; Sat, 17 May 2003 12:10:45 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1853091242 for ; Sat, 17 May 2003 12:10:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ECF695E1FD; Sat, 17 May 2003 12:10:43 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by segue.merit.edu (Postfix) with ESMTP id F23AF5E1F9 for ; Sat, 17 May 2003 12:10:41 -0400 (EDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h4HGDAqs002239; Sat, 17 May 2003 19:13:10 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h4HGD81C002238; Sat, 17 May 2003 19:13:08 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Final word - ACCEPT [LL23] Don't configure needless LL addresses From: Mika Liljeberg To: Erik Guttman Cc: Erik Guttman , zeroconf@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1053187987.1956.110.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 17 May 2003 19:13:08 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Sat, 2003-05-17 at 17:33, Erik Guttman wrote: > Mika, > > > > On 16 May 2003, Mika Liljeberg wrote: > > Thanks for the thorough response. In the interest of keeping things > > focused on the main problem, I'm only responding to the scenarios table. > > I've taken the liberty of filling in the routing tables to illustrate my > > point. > > > > On Fri, 2003-05-16 at 13:07, Erik Guttman wrote: > > > If this is not clear in the specification, we need to open a new > > > issue describing the process. Here are the scenarios: > > > > > Host H2 > > > > > > has LL has routable has > > > address and knows routable > > > how to foward to LL (legacy) > > > > Route tables: > > 169.254/16 ->link a.b.c.d/x ->link a.b.c.d/x ->link > > 169.254/16 ->link > > Why not: > * -> link That's unacceptable. This is not compatible with multihoming. You can't just add a default on-link route to /dev/null, when you might have a perfectly good default gateway behind another interface. > > > Host H has LL > > > > Route table: > > 169.254/16 -> link > > > > > > > + no routers H can discover H can discover H2 H can't dis- > > > H2 and ex- and exchange cover H2 as > > > change packets packets H2 cannot > > > send to H. > > > H2 & H are > > > not on the > > > same subnet. > > > > > TRUE FALSE. H2 adver- The reverse > > tizes its global is true as > > address but H well. H does > > only has a route not have a > > for LL destina- route for H2 > > tions. > > If H routes to the link for all destinations then H can reach H2. That breaks multihoming. > > > Host H has routable > > address and knows > > how to send to LL > > > > Route table: > > e.f.g.h/y -> link BROKEN. H adver BROKEN. Both H and As above. > > 169.254/16 -> link tises global H2 advertise global > > address but H2 addresses but can't > > only has a rou- communicate because > > te for LL. they don't have > > routes for each > > other. > > > (A) (B) > > I do not understand what you mean by (A). H2 doesn't have an on-link route for e.f.g.h/y, so it can't send packets to H's routable address. > In the case of (B) - we do not purport to fix the problem of > communication between two hosts which are not using LL, on the same link > but with different subnets. We are creating the problem by telling the nodes not to use LL. > This is solved by a router. How? If the router is up and one of the nodes has a valid netmask, while the other one doesn't, you're out of luck. Use case: "I'll just stick my laptop into your hub for a moment and transfer this file to you." > If the router > is down, these hosts are no worse off than hosts are today. If the nodes meet in an ad-hoc situation, both may have manually configured routable addesses (appropriate for their home location) and mismatching netmasks. Zeroconf should address this problem. Otherwise, why are we here? > Further, > these hosts *could determine* that they are *no longer* configured with > a routable address (since the router is down). In this case they would > revert to using LL. I suggest you try to write an algorithm for this, because I sure can't come up with one. Besides, trasitioning to LL doesn't even help in the above case, where one node is visiting a foreign link. > If (B) is a network without a router (ever), then it would be a mistake > to configure host H and H2 with global addresses on different subnets. Both configurations may be valid on the home links of those hosts. Zeroconf should solve the ad-hoc scenario, where the two hosts meet. > The fact that legacy hosts cannot communicate with LL hosts is true: > That is the case and has been the case since this protocol was first > deployed. That's fine with me, I don't expect them to. > > I do. As shown by the above table, only the trivial cases work: > > > > 1) LL <-> LL > > 2) global <-> global, when the subnet masks are same > > This is not the case if you accept that > > a) LL hosts route 'to the link' for all destinations, not just LL I don't accept that. This breaks multihoming. > b) LL-capable hosts will route 'to the link' for LL destinations > even if they have a routable address This fine. > c) hosts with routable addresses but no router may eventually choose > to 'transition back' to using LL. "may eventually" ? In other words, the user "may eventually" get connectivity if he keeps trying? Sorry, but I don't call that zero configuration networking. > This is no different than a host > choosing to configure an LL address after waking up - after it > could not contact a DHCP server or a router. This is an aggressive > strategy which only makes sense if the host continues to try to > get configured (using DHCP, RARP or whatever), so as to not become > unavailable off the local link once the router doesn't respond for > a moment, etc. > > Once we rejected LL we all knew that we would have to face the > transition problem, both ways, eventually. Well, the WG is not facing the transitioning problem. You yourself (with your wg chair hat on) proposed to leave it as an implementation issue. Well, consider this feedback from one of those implementors: I don't have the foggiest how to implement it in a robust way and still be compliant with the specification. I'm finding I have to choose between conformance and interoperability which, I'm sure you'll agree, is a pretty strange situation. ... > I meant once we rejected LL19 and accepted LL23, it opened the > door to the transition problem. Which we have done nothing to solve. > Hosts configure LL, then > configure routable and in some cases, may configure LL again. > > LL23 does not state under what conditions one considers that a > host is configured with a global address. This cannot be stated > generally, since some hosts are mobile, some hosts sleep/wake, > some hosts may be multihomed with one home on a local link, the > other on a routable link (which goes up and down), and many > other possibilities. That is exactly the problem. Conversely, there is no way to know under what conditions a host will have a LL address and there is no way to know under what conditions communication with another host will be possible. This means that zeroconf has failed in its purpose. > > In all other cases the nodes have mismatching on-link routes, which > > prevent communication, even though the nodes are on the same link. > > I believe assumptions a-c answer your concerns. No doubt they raise > others. a) breaks multihoming b) is ok c) is an unsolved problem False assumptions are a nice way to justify just about any point of view. MikaL From owner-zeroconf@merit.edu Sun May 18 09:16:52 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08563 for ; Sun, 18 May 2003 09:16:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6855C91247; Sun, 18 May 2003 09:19:51 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31CB691249; Sun, 18 May 2003 09:19:51 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15A8F91247 for ; Sun, 18 May 2003 09:19:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EB3D45E5CD; Sun, 18 May 2003 09:19:50 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 9C9BB5E5CC for ; Sun, 18 May 2003 09:19:49 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4IDJlHN006450; Sun, 18 May 2003 06:19:47 -0700 (PDT) Received: from sun.com (vpn-129-159-0-36.EMEA.Sun.COM [129.159.0.36]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h4IDJcw21988; Sun, 18 May 2003 15:19:38 +0200 (MEST) Message-ID: <3EC787D3.9060208@sun.com> Date: Sun, 18 May 2003 15:17:07 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: Re: Final word - ACCEPT [LL23] Don't configure needless LL addresses References: <1053187987.1956.110.camel@devil> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mika, I reply to a somewhat trimmed thread accumulation. Mika Liljeberg wrote: >>>On Fri, 2003-05-16 at 13:07, Erik Guttman wrote: >>> >>>>If this is not clear in the specification, we need to open a new >>>>issue describing the process. Here are the scenarios: >>> >>>> Host H2 >>>> >>>> has LL has routable has >>>> address and knows routable >>>> how to foward to LL (legacy) >>> >>>Route tables: >>> 169.254/16 ->link a.b.c.d/x ->link a.b.c.d/x ->link >>> 169.254/16 ->link >> >>Why not: >> * -> link > > > That's unacceptable. This is not compatible with multihoming. I agree. What one adds to H is a host route to H2. H sends a service discovery or name resolution request using a LL source address to a link local multicast address. H2 replies to H, from a global address, to H. H now has an arp cache entry for H2->L2 address. A completely reasonable thing to do at this point would be to add an entry to the routing table for H for H2/32. This would in no way interfere with H being multihomed unless H were multihomed using LL on more than one interface. In this case H2/32 may be a collision. We do not handle LL on multiple interfaces except as a degenerate case which requires higher level application intervention, as discussed in section 3. >>>Route table: >>> e.f.g.h/y -> link BROKEN. H adver BROKEN. Both H and As above. >>> 169.254/16 -> link tises global H2 advertise global >>> address but H2 addresses but can't >>> only has a rou- communicate because >>> te for LL. they don't have >>> routes for each >>> other. >>> >> >> (A) (B) >> >>I do not understand what you mean by (A). > > > H2 doesn't have an on-link route for e.f.g.h/y, so it can't send packets > to H's routable address. > It can if there is a router present. As indicated: If there is not a router present, eventually H and H2 may choose to use LL configuration. There are really only two options: Allow for constant use of LL and intermittent use of global addresses (as they get configured), or to transition between their use. The WG has opted for the latter, accepting that the transition is neither one-size-fits-all or completely clean. In doing so, the WG is accepting as part of the specification what has been deployed since 1998. Codifying and standardizing what is there, as long as it is not horribly broken is really what this standardization effort is attempting to do. The alternative, requiring a scoped address architecture, has been rejected by the working group. Efforts to express how this would work on this group have failed. Even with much more concentrated work and determination, it has been difficult to achieve in the IPv6 WG. >>In the case of (B) - we do not purport to fix the problem of >>communication between two hosts which are not using LL, on the same link >>but with different subnets. > > > We are creating the problem by telling the nodes not to use LL. > > >> This is solved by a router. > > > How? If the router is up and one of the nodes has a valid netmask, while > the other one doesn't, you're out of luck. Use case: "I'll just stick my > laptop into your hub for a moment and transfer this file to you." > Why isn't your laptop using LL? If it were, this would work (assuming that the laptop adds the host route for H2). >> If the router >>is down, these hosts are no worse off than hosts are today. > > > If the nodes meet in an ad-hoc situation, both may have manually > configured routable addesses (appropriate for their home location) and > mismatching netmasks. Zeroconf should address this problem. Otherwise, > why are we here? I do not believe we are here to solve the problem of communication between staticly configured machines. That is certainly not in our charter statement. >>Once we rejected LL we all knew that we would have to face the >>transition problem, both ways, eventually. > > Well, the WG is not facing the transitioning problem. You yourself (with > your wg chair hat on) proposed to leave it as an implementation issue. Apologies - this was meant to be working group chair hat off. > Well, consider this feedback from one of those implementors: I don't > have the foggiest how to implement it in a robust way and still be > compliant with the specification. I'm finding I have to choose between > conformance and interoperability which, I'm sure you'll agree, is a > pretty strange situation. Transition has been a discussion item on the list for some time. Please refer back to Philip Nye's responses to discussion of LL19. > False assumptions are a nice way to justify just about any point of > view. :-) Erik From owner-zeroconf@merit.edu Sun May 18 15:56:19 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16342 for ; Sun, 18 May 2003 15:56:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D5D5591203; Sun, 18 May 2003 15:59:17 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A36CE9124C; Sun, 18 May 2003 15:59:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6ADE791203 for ; Sun, 18 May 2003 15:59:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4D3FA5E708; Sun, 18 May 2003 15:59:16 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by segue.merit.edu (Postfix) with ESMTP id 641055E128 for ; Sun, 18 May 2003 15:59:14 -0400 (EDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h4IK1oFI003157; Sun, 18 May 2003 23:01:52 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h4IK1mMt003156; Sun, 18 May 2003 23:01:48 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Final word - ACCEPT [LL23] Don't configure needless LL addresses From: Mika Liljeberg To: Erik Guttman Cc: zeroconf@merit.edu In-Reply-To: <3EC787D3.9060208@sun.com> References: <1053187987.1956.110.camel@devil> <3EC787D3.9060208@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1053288107.2534.94.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 18 May 2003 23:01:48 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Eric, Trimming some more... On Sun, 2003-05-18 at 16:17, Erik Guttman wrote: > >>Why not: > >> * -> link > > > > > > That's unacceptable. This is not compatible with multihoming. > > I agree. What one adds to H is a host route to H2. > > H sends a service discovery or name resolution request using a LL source > address to a link local multicast address. H2 replies to H, from a > global address, to H. H now has an arp cache entry for H2->L2 address. > A completely reasonable thing to do at this point would be to add an > entry to the routing table for H for H2/32. No, that's a terrible idea. Firstly, that makes it possible for a malicious node to completely trash someone elses routing table. Secondly, how would you know when it is appropriate to remove the host route? Thirdly, the zeroconf protocol should work correctly as a standalone specification. The proper solution, in my opinion, is to keep both LL and routable addresses configured and use the one that is appropriate. We can still place limitations on how those addresses are advertised. For instance, a LLMNR responder would advertise a routable address if the query comes from a routable address and the responder has a route back to the sender. Otherwise, the responder would advertise its LL address. This approach prefers routable addresses but correctly falls back on link-locals when routables don't work. > This would in no way interfere with H being multihomed unless H were > multihomed using LL on more than one interface. In this case H2/32 may > be a collision. We do not handle LL on multiple interfaces except as > a degenerate case which requires higher level application intervention, > as discussed in section 3. Incidentally, our "degenerate" implementation does support LLs on multiple interfaces. > >>>Route table: > >>> e.f.g.h/y -> link BROKEN. H adver BROKEN. Both H and As above. > >>> 169.254/16 -> link tises global H2 advertise global > >>> address but H2 addresses but can't > >>> only has a rou- communicate because > >>> te for LL. they don't have > >>> routes for each > >>> other. > >>> > >> > >> (A) (B) > >> > >>I do not understand what you mean by (A). > > > > > > H2 doesn't have an on-link route for e.f.g.h/y, so it can't send packets > > to H's routable address. > > > > It can if there is a router present. This was a routerless case. Two people meet in an ad-hoc situation. They just happen to have their routable addresses configured (as appropriate on their home links). > As indicated: If there is not a > router present, eventually H and H2 may choose to use LL configuration. I say again: "may eventually" is not good enough. The user will end up doing it manually (or more likely just give up), which means that zeroconf has failed. > There are really only two options: Allow for constant use of LL and > intermittent use of global addresses (as they get configured), or to > transition between their use. The WG has opted for the latter, > accepting that the transition is neither one-size-fits-all or > completely clean. In doing so, the WG is accepting as part of the > specification what has been deployed since 1998. Codifying and > standardizing what is there, as long as it is not horribly broken > is really what this standardization effort is attempting to do. Let's not go into that rat hole right now or we will get nothing done. Instead, let's try to fix the connectivity problems that are plainly there. > > How? If the router is up and one of the nodes has a valid netmask, while > > the other one doesn't, you're out of luck. Use case: "I'll just stick my > > laptop into your hub for a moment and transfer this file to you." > > > > Why isn't your laptop using LL? It is using LL but it doesn't have a route for the other node's routable address. > If it were, this would work (assuming > that the laptop adds the host route for H2). Making up new rules as we go on? Adding a host route is not part of the specification, nor is it a good idea, for the reasons I gave above. > > > > If the nodes meet in an ad-hoc situation, both may have manually > > configured routable addesses (appropriate for their home location) and > > mismatching netmasks. Zeroconf should address this problem. Otherwise, > > why are we here? > > I do not believe we are here to solve the problem of communication > between staticly configured machines. That is certainly not in our > charter statement. > > Then you and I read the charter differently. I want "...to allow impromptu networks as between the devices of strangers on a train.". That's the use case I'm talking about and it plainly is in the charter. MikaL From owner-zeroconf@merit.edu Mon May 19 03:02: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 DAA10164 for ; Mon, 19 May 2003 03:02:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 76E5491209; Mon, 19 May 2003 03:05:46 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48AA29120C; Mon, 19 May 2003 03:05:46 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 56FB791209 for ; Mon, 19 May 2003 03:05:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E5675DECD; Mon, 19 May 2003 03:05:45 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 5273A5DECC for ; Mon, 19 May 2003 03:05:44 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4J75fHN028462; Mon, 19 May 2003 00:05:42 -0700 (PDT) Received: from sun.com (vpn-129-159-0-141.EMEA.Sun.COM [129.159.0.141]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h4J75Yw19992; Mon, 19 May 2003 09:05:34 +0200 (MEST) Message-ID: <3EC881A5.7@sun.com> Date: Mon, 19 May 2003 09:03:01 +0200 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: Mika Liljeberg Subject: Re: Final word - ACCEPT [LL23] Don't configure needless LL addresses References: <1053187987.1956.110.camel@devil> <3EC787D3.9060208@sun.com> <1053288107.2534.94.camel@devil> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit We need some input from the rest of the WG on this discussion. Erik From owner-zeroconf@merit.edu Mon May 19 06:03:53 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13547 for ; Mon, 19 May 2003 06:03:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 366009120C; Mon, 19 May 2003 06:06:50 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A1659120D; Mon, 19 May 2003 06:06:49 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE08D9120C for ; Mon, 19 May 2003 06:06:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D19935E012; Mon, 19 May 2003 06:06:48 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 7F5775DE86 for ; Mon, 19 May 2003 06:06:48 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id DA39E598D2; Mon, 19 May 2003 11:06:48 +0100 (BST) Message-ID: <013601c31dee$59b25ff0$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , Cc: "Mika Liljeberg" References: <1053187987.1956.110.camel@devil> <3EC787D3.9060208@sun.com> <1053288107.2534.94.camel@devil> <3EC881A5.7@sun.com> Subject: Re: Final word - ACCEPT [LL23] Don't configure needless LL addresses Date: Mon, 19 May 2003 11:06:43 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I hate to come back in to this discussion. As Eric has pointed out, the options are either to use concurrent addresses and have a full scoped address architecture or to have a transitioning mechanism. Both have been shown to be problematic in some cases. The IPv4 architecture was never designed for scoped addressing and while some limited scoped addressing features (rfc1918 etc.) these have typically been troublesome and have not caused scoping to be integrated into the IPv4 architecture. Whichever option is taken, the issue of when to use LL and when to use Routable addressing needs to be tackled somewhere. The concurrent use option requires application intervention while the transition mechanism makes it possible to do all or most of the decision making at a system level and this is why I prefer it - it is more likely to work with legacy applications and with applications which will continue to be written by millions of programmers who will not be aware that IPv4 has suddenly become a scoped architecture. The third option is to allow either and to carefully document the pitfalls and indicate which method is likely to work best in which environments. From Mika's descriptions of the architecture he is working with, I can see that a concurrent use mechanism can work well for him. I have not been fully convinced that the transition mechanism cannot work for him too - some of his objections appear almost deliberately obtuse - but I can see that making it work may require some fairly liberal interpretation of terms like "configured with a routable address" and could be less "elegant". However, this third option would need careful examination to establish that it did not introduce it's own interoperability problems between hosts using different mechanisms. It also needs drafting of some fairly extensive text changes. I do not have the energy or motivation to do any of this and am not even sure that it is possible. If somebody offered a proposal I would consider it. Meanwhile, I agree with Eric's analysis and with his conclusion of rough consensus - the transitioning mechanism is the least worst option. Philip ----- Original Message ----- From: "Erik Guttman" To: Cc: "Mika Liljeberg" Sent: Monday, May 19, 2003 8:03 AM Subject: Re: Final word - ACCEPT [LL23] Don't configure needless LL addresses > > We need some input from the rest of the WG on this discussion. > > Erik > > > > From owner-zeroconf@merit.edu Mon May 19 06:52: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 GAA15286 for ; Mon, 19 May 2003 06:52:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 827B39120D; Mon, 19 May 2003 06:55:22 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5222A9120F; Mon, 19 May 2003 06:55:22 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 628519120D for ; Mon, 19 May 2003 06:55:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4D6595E041; Mon, 19 May 2003 06:55:21 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by segue.merit.edu (Postfix) with ESMTP id DEAF15E03F for ; Mon, 19 May 2003 06:55:20 -0400 (EDT) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-72.cisco.com [10.82.240.72]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4JAtIkM015609; Mon, 19 May 2003 06:55:18 -0400 (EDT) Message-Id: <4.3.2.7.2.20030519065236.00b23840@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 May 2003 06:55:17 -0400 To: Erik Guttman From: John Schnizlein Subject: Re: Final word - ACCEPT [LL23] Don't configure needless LL addresses Cc: zeroconf@merit.edu In-Reply-To: <3EC881A5.7@sun.com> References: <1053187987.1956.110.camel@devil> <3EC787D3.9060208@sun.com> <1053288107.2534.94.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk At 03:03 AM 5/19/2003, Erik Guttman wrote: >We need some input from the rest of the WG on this discussion. Why is more input needed on an issue that was resolved using the formal process? Does just one person continuing debate after the rough consensus was done require rehash of the whole thing? John From owner-zeroconf@merit.edu Mon May 19 07:08: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 HAA16218 for ; Mon, 19 May 2003 07:07:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B9FE69120F; Mon, 19 May 2003 07:10:48 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 87B409124E; Mon, 19 May 2003 07:10:48 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3B3899120F for ; Mon, 19 May 2003 07:10:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 189FB5E058; Mon, 19 May 2003 07:10:46 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id AEC385E050 for ; Mon, 19 May 2003 07:10:45 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h4JBAjTh025271 for ; Mon, 19 May 2003 07:10:45 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h4JBAind004714 for ; Mon, 19 May 2003 07:10:44 -0400 (EDT) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h4JBAgU8001251 for ; Mon, 19 May 2003 07:10:43 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 19 May 2003 07:10:36 -0400 Subject: Re: Final word - ACCEPT [LL23] Don't configure needless LL addresses From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <3EC881A5.7@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 05/19/2003 03:03, "Erik Guttman" did proclaim: > We need some input from the rest of the WG on this discussion. I agree with Mika, but quite frankly, got tired of arguing it. I think that he's right, for the right reasons, and that his point about static addresses is almost the same as mine. But anymore, my attitude is, y'all just do what you want, I've no longer the energy, or the motivation to be the voice of the people who will want to sit in an airport, or on a train, or , and just be able to use this. I've learned the hard way exactly where they fit in. john -- John C. Welch Consultant III Office Computing Practice (IS) (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon May 19 08:36: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 IAA19083 for ; Mon, 19 May 2003 08:36:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ECABB9124F; Mon, 19 May 2003 08:39:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B630091250; Mon, 19 May 2003 08:39:29 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE4849124F for ; Mon, 19 May 2003 08:39:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 97CD45E0AE; Mon, 19 May 2003 08:39:28 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by segue.merit.edu (Postfix) with ESMTP id 359935E0AC for ; Mon, 19 May 2003 08:39:28 -0400 (EDT) Received: from cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4JCdQJh015304 for ; Mon, 19 May 2003 08:39:26 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn4-478.cisco.com [10.21.81.222]) by cisco.com (8.8.5-Cisco.1/8.8.8) with ESMTP id IAA08616 for ; Mon, 19 May 2003 08:39:25 -0400 (EDT) Message-Id: <4.3.2.7.2.20030519083338.0a977eb0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 May 2003 08:39:24 -0400 To: zeroconf@merit.edu From: Ralph Droms Subject: Re: Final word - ACCEPT [LL23] Don't configure needless LL addresses In-Reply-To: <3EC881A5.7@sun.com> References: <1053187987.1956.110.camel@devil> <3EC787D3.9060208@sun.com> <1053288107.2534.94.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk My input is that we accepted LL23 through the agreed upon process. The WG should move on and apply its energies to other remaining issues... - Ralph At 09:03 AM 5/19/2003 +0200, you wrote: >We need some input from the rest of the WG on this discussion. > >Erik > > From owner-zeroconf@merit.edu Mon May 19 16:42: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 QAA05221 for ; Mon, 19 May 2003 16:42:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6D67D91213; Mon, 19 May 2003 16:20:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 32F6F91216; Mon, 19 May 2003 16:20:11 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE22391213 for ; Mon, 19 May 2003 16:20:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB91B5DEDD; Mon, 19 May 2003 16:20:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by segue.merit.edu (Postfix) with ESMTP id D492F5DEDC for ; Mon, 19 May 2003 16:20:08 -0400 (EDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h4JKMkFI011879; Mon, 19 May 2003 23:22:47 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h4JKMiZl011878; Mon, 19 May 2003 23:22:44 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Can we compromise? From: Mika Liljeberg To: Philip Nye Cc: Erik Guttman , zeroconf@merit.edu In-Reply-To: <013601c31dee$59b25ff0$131010ac@aldebaran> References: <1053187987.1956.110.camel@devil> <3EC787D3.9060208@sun.com> <1053288107.2534.94.camel@devil> <3EC881A5.7@sun.com> <013601c31dee$59b25ff0$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1053375763.2553.143.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 19 May 2003 23:22:44 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I could live with the third option. I think we all recognize that both points of view have valid concerns. We're trying to achieve the best possible user experience but clearly we are thinking about different use cases, and hence we have different requirements. Given that the choice depends on the use case, the rational approach would be to recommend that vendors put in a configuration switch and leave the decision up to the user (or the network manager). Only they can know whether the concurrent use mode or the transition mode suits the user's needs best. I have no problem with recommending that the default mode should be the transition mode, unless it is clear that the primary use cases for the device benefit from the concurrent mode. I would be glad to propose some text if people are willing to agree to this. Can we reach a compromise this way? MikaL On Mon, 2003-05-19 at 13:06, Philip Nye wrote: > I hate to come back in to this discussion. > > As Eric has pointed out, the options are either to use concurrent addresses > and have a full scoped address architecture or to have a transitioning > mechanism. Both have been shown to be problematic in some cases. The IPv4 > architecture was never designed for scoped addressing and while some limited > scoped addressing features (rfc1918 etc.) these have typically been > troublesome and have not caused scoping to be integrated into the IPv4 > architecture. > > Whichever option is taken, the issue of when to use LL and when to use > Routable addressing needs to be tackled somewhere. The concurrent use option > requires application intervention while the transition mechanism makes it > possible to do all or most of the decision making at a system level and this > is why I prefer it - it is more likely to work with legacy applications and > with applications which will continue to be written by millions of > programmers who will not be aware that IPv4 has suddenly become a scoped > architecture. > > The third option is to allow either and to carefully document the pitfalls > and indicate which method is likely to work best in which environments. From > Mika's descriptions of the architecture he is working with, I can see that a > concurrent use mechanism can work well for him. I have not been fully > convinced that the transition mechanism cannot work for him too - some of > his objections appear almost deliberately obtuse - but I can see that making > it work may require some fairly liberal interpretation of terms like > "configured with a routable address" and could be less "elegant". > > However, this third option would need careful examination to establish that > it did not introduce it's own interoperability problems between hosts using > different mechanisms. It also needs drafting of some fairly extensive text > changes. I do not have the energy or motivation to do any of this and am not > even sure that it is possible. If somebody offered a proposal I would > consider it. Meanwhile, I agree with Eric's analysis and with his conclusion > of rough consensus - the transitioning mechanism is the least worst option. > > Philip > > > > ----- Original Message ----- > From: "Erik Guttman" > To: > Cc: "Mika Liljeberg" > Sent: Monday, May 19, 2003 8:03 AM > Subject: Re: Final word - ACCEPT [LL23] Don't configure needless LL > addresses > > > > > > We need some input from the rest of the WG on this discussion. > > > > Erik > > > > > > > > > From owner-zeroconf@merit.edu Tue May 20 18:42:46 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04266 for ; Tue, 20 May 2003 18:42:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2BBD89122A; Tue, 20 May 2003 18:42:40 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F39819122F; Tue, 20 May 2003 18:42:39 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C51D29122A for ; Tue, 20 May 2003 18:42:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A73945DE04; Tue, 20 May 2003 18:42:38 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 6A4C15DE01 for ; Tue, 20 May 2003 18:42:38 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.9/8.12.9) with ESMTP id h4KMgcqh002000 for ; Tue, 20 May 2003 15:42:38 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 20 May 2003 15:42:37 -0700 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv3.apple.com (8.12.9/8.12.9) with SMTP id h4KMgaI2019820 for ; Tue, 20 May 2003 15:42:36 -0700 (PDT) Message-Id: <200305202242.h4KMgaI2019820@scv3.apple.com> Subject: LL11: Add security consideration Date: Tue, 20 May 2003 15:42:38 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk I've been busy working on products for the last couple of months, but I'm making time now to catch up again with the Zeroconf mailing list. More comments will follow later today or tomorrow, but for now, here's a simple editorial request: Issue LL11: Add security consideration for the threat where an attacker forces address reconfiguration A host implementing IPv4 link-local configuration has the additional vulnerability to selective reconfiguration and disruption. It is possible for an on-link attacker to issue ARP packets that would cause a host to believe the address it is using is also being used by someone else and must be given up. Giving up the address and configuring another address will cause a host to break all its connections by switching to a new address. The attacker could force the host implementing IPv4 link-local configuration to select certain addresses, or prevent it from ever completing address selection. This is a distinct threat from that posed by fraudulent ARPs, described in the preceding paragraph. I'd like to request some editorial softening of this text. We need to remember the point of this document: The point of this document is to help vendors make products that work well, and interoperate. This is not an academic research paper read by a handful of experts. This document will be read (and the draft is currently being read) by a lot of inexperienced implementers. Many of them are contract programmers who know little about networking, working on short-term contracts for hardware manufacturers who know even less. They assume that if text is in the document, it is there for a reason. They assume that if the document says something, it wouldn't say it if it didn't require some specific action on their part. Recently I have had to persuade implementers that simply ignoring address conflicts is not acceptable. They were happy with the part of IPv4LL that entailed picking a random IP address at boot time, but not the part about detecting conflicts, or changing the IP address if a conflict occurs. I'm confident that if the LL11 text is put in the draft as-is, then implementers will seize on it to justify their position that there's no need to pick a new IP address if a conflict occurs; indeed, it is better ("more secure") NOT to change IP address if a conflict occurs (and they get the added benefit of not having to implement that part of the code). The LL11 text may be technically true, but is it helpful? It's like printing a label on car seat belts that says, "WARNING: Wearing your seat belt may cause you to be trapped in a burning vehicle and die." This statement is technically true (in the sense that it probably happened to someone once, or at least it could happen), but not helpful (in the sense that printing this warning on car seat belts would encourage people not to wear them, leading to thousands of deaths). Perhaps we can add the following text: Nevertheless, all hosts implementing IPv4LL MUST implement the rules described in Section 2.5, and MUST configure a new IP address when required by those rules. While there is a theoretical risk of a host being tricked into changing its IP address unnecessarily, the problems that would result from hosts ignoring address conflicts would be even worse. Remember that the whole basis of IPv4 LL is that it is a method to configure workable IP addresses in the absence of any kind of central authority. In the absence of any kind of central authority, no participant has any more authority than any other, so all participants have to be willing to participate with each other equally to arrive at an acceptable distribution of addresses. If one or more of those participants is malicious or destructive, then the problem fundamentally can't be solved without some kind of outside intervention. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu May 22 15:05:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25396 for ; Thu, 22 May 2003 15:05:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CA58491227; Thu, 22 May 2003 15:05:37 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A01689122B; Thu, 22 May 2003 15:05:37 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 89F7591227 for ; Thu, 22 May 2003 15:05:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5F3B65DFD5; Thu, 22 May 2003 15:05:36 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id E56915DF41 for ; Thu, 22 May 2003 15:05:35 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.9/8.12.9) with ESMTP id h4MJ5Zqh008403 for ; Thu, 22 May 2003 12:05:35 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 22 May 2003 12:05:20 -0700 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv2.apple.com (8.12.9/8.12.9) with SMTP id h4MJ5J7h021942 for ; Thu, 22 May 2003 12:05:19 -0700 (PDT) Message-Id: <200305221905.h4MJ5J7h021942@scv2.apple.com> Subject: Re: LL11: Add security consideration Date: Thu, 22 May 2003 12:05:20 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >There is no precedent for including additional stern and palliating text >to Security Considerations sections. When the protocol specification >says a feature MUST be implemented, this is unambiguous. An implementor >has to be informed about the security implications, and that's what >belongs in the Security Considerations section. > >It is dangerous to mention a that specific feature is 'still' required, >despite a vulnerability it exposes. This could imply (to a reader with >imagination) that other requirements are not necessarily firm and >*could* be ignored to address vulnerabilities. The underlying problem is that I don't agree with the proposed warning. I believe it is incorrect, misleading, unhelpful, and ultimately counter-productive with respect to the purpose of the document, which is supposed to be to help vendors make products that work well and interoperate. The proposed warning says that a rogue host on the local link could send fraudulent ARPs to trick you into changing your address, and furthermore: This is a distinct threat from that posed by fraudulent ARPs, described in the preceding paragraph. The simple fact is this: If two devices on the same link are broadcasting ARP packets with the same sender IP address and different sender hardware addresses, neither will achieve reliable TCP communication until one or other stops doing that (e.g. by changing to a different address). Anyone who doubts this should try it with a pair of Linux machines and see for themselves what happens. The truth is that changing to a different address is the *solution* to the problem of two hosts trying to use the same address, and any text that casts this in the light of "problem" rather than "solution" leads to less clarity of understanding, rather than more. I know that Erik Nordmark views changing your IP address firmly in the category of "problem" rather than "solution", which is why he wants language in the draft to encourage other people to see it that way too, but speaking as someone who has to deal with vendors making actual products, encouraging them to perceive changing your IP address as a bad idea is leading to a bunch of crummy products that don't work. By making their product guard against this hypothetical malicious attack (which in reality will *never* happen on the typical user's home network) they make their product fail in the face of accidental address conflicts (which -- counting all home networks on the entire planet -- is likely to happen relatively frequently). Let us be clear on this: If a fraudulent ARP attack were to happen on your home network, having your LL devices fail to reconfigure is not going to help one little bit. Stopping the attack is going to help you. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu May 22 16:08: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 QAA27785 for ; Thu, 22 May 2003 16:08:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7329A9122B; Thu, 22 May 2003 16:08:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44E039122C; Thu, 22 May 2003 16:08:30 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 34D8A9122B for ; Thu, 22 May 2003 16:08:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 114E15E036; Thu, 22 May 2003 16:08:29 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 96A6E5E031 for ; Thu, 22 May 2003 16:08:28 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.9/8.12.9) with ESMTP id h4MK8Sqh019284 for ; Thu, 22 May 2003 13:08:28 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 22 May 2003 13:08:13 -0700 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv3.apple.com (8.12.9/8.12.9) with SMTP id h4MK8MI2016495; Thu, 22 May 2003 13:08:22 -0700 (PDT) Message-Id: <200305222008.h4MK8MI2016495@scv3.apple.com> Subject: Example email from vendor: Probe after cable connection or not? Date: Thu, 22 May 2003 13:08:23 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Below is an email from a vendor I received today. I have removed names and email addresses to protect the innocent. This is just today's example of how the slightest vagueness or omission in the document makes it susceptible to misinterpretation. We at Apple have to answer questions of this nature on a regular basis, something I mention because I suspect it is a task that most people on this list have been spared. Background information for the email below: As part of the licensing procedure for products to use Apple's Rendezvous logo, we verify that the device correctly probes to verify the uniqueness of its address at the times it is supposed to, including, specifically, when it is connected to an Ethernet hub while already powered on -- what the author of the email below refers to as "hot-plugging". > Regarding the hot-plugging issue and auto IP behavior. In the > reference spec for auto ip (draft-ietf-zeroconf-ipv4-linklocal-07.txt) > it doesnt talk specifically about hot plugging. However, in section 4 > it comes close when it talks about joining a previously separate > network. I know its not the same, but as far as the node and how it > acts when it is configured and a new "group" of nodes is introduced, > the spec indicates that it is better to handle these types of > conflicts when they occur and not necessarily waste network bandwidth > with probes. Now I agree that hot-plugging is an event that we can > detect, and as such it is different than the "joined network" scenario. > However, I would think that (when a cable is unplugged) it is just as > likely (if not more likely) that the same network is being plugged > back into than it is a different network being plugged into. So, in > many cases, we would be sending probes on the network for no reason. > > Our code does work if the network is changed. Its just that our code > would detect the collision sometime later and then go through the > process of dealing with the conflict at that point rather than > immediately. Our code will also not send unnecessary probes in either > case, which is better if we are plugged back into the same network. The LL document says *how* you configure, probe and announce LL addresses, but not *when* you should do this. Looking back, I think we assumed that the "when" would be obvious: you do it whenever there is plausible risk there there might be some other host already using that same address which would be disrupted by your use of that address; namely, you do it after any new attachment to a network link. To spell this out, you need to probe for address uniqueness: * Upon reboot/startup * Upon wake from sleep (if network interface was inactive during sleep) * Upon bringing up previously inactive network interface * Upon Ethernet hardware link-state change that indicates a cable was attached. * Upon association with a wireless base station. * etc. * (but NOT periodically as a matter of course) I would have thought it obvious that if a device is powered on without the cable attached, then performing address probes without the cable connected is unlikely to yield any useful information, and consequently, when the cable is subsequently connected, any assumption that your address has been verified unique is completely baseless. However, this is evidently not obvious. We need to explicitly spell out the occasions when address probing is necessary, either in IPv4LL itself, or in some other "wrapper" document that describes the times at which the rules described in IPv4LL are to be applied. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Mon May 26 05:33:26 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06634 for ; Mon, 26 May 2003 05:33:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 071D991220; Mon, 26 May 2003 05:33:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAB3091221; Mon, 26 May 2003 05:33:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD28D91220 for ; Mon, 26 May 2003 05:33:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE05E5E990; Mon, 26 May 2003 05:33:14 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 947BA5E9AD for ; Mon, 26 May 2003 05:31:50 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4Q9Vmep002668 for ; Mon, 26 May 2003 03:31:49 -0600 (MDT) Received: from sun.com (vpn-129-156-96-91.EMEA.Sun.COM [129.156.96.91]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h4Q9Vlw08687 for ; Mon, 26 May 2003 11:31:47 +0200 (MEST) Message-ID: <3ED1DE54.6050809@sun.com> Date: Mon, 26 May 2003 11:28:52 +0200 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 Subject: test Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit please disregard Sorry for the disturbance, Erik From owner-zeroconf@merit.edu Mon May 26 05:55:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07130 for ; Mon, 26 May 2003 05:55:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E5D2391221; Mon, 26 May 2003 05:55:13 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A12CA91222; Mon, 26 May 2003 05:55:13 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 70A6991221 for ; Mon, 26 May 2003 05:55:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4EE115E9D4; Mon, 26 May 2003 05:55:12 -0400 (EDT) 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 E25A05E9D3 for ; Mon, 26 May 2003 05:55:11 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4Q9tAYU017068 for ; Mon, 26 May 2003 03:55:10 -0600 (MDT) Received: from sun.com (vpn-129-156-96-91.EMEA.Sun.COM [129.156.96.91]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h4Q9t6w09823 for ; Mon, 26 May 2003 11:55:07 +0200 (MEST) Message-ID: <3ED1E3CF.3020508@sun.com> Date: Mon, 26 May 2003 11:52:15 +0200 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 Subject: New Issue [LL32] Multihoming problems not solved but that is OK Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I thought I posted this last week, but I do not see it in the mailing list archive. The purpose of this issue is to * resolve the concern Mika raised about interoperation between a multihomed host communicating with a non-LL destination address through a LL address configured interface. * to rework the entire multihoming section so as to give advice and issue warnings, but not to treat the subject as if the text were definitive or multihoming and use of LL is a solved and well understood topic Description of Issue Multihoming problems not solved but that is OK Submitter Name Erik Guttman Submitter Email Address erik.guttman@sun.com Date first submitted May 21, 2003 Reference zeroconf mailing list Comment Type ['T'echnical | 'E'ditorial] T Priority ['S' Must fix | '1' Should fix | '2' May fix ] S Section 3 (entire section) Rationale/Explanation of issue: While the document does describe the problem of using dynamic configuration for IPv4 LL on more than one link, it does not solve the problem. It is not possible for this to be done transparently to upper layer applications given existing interfaces and expectations. Further, there are routing issues when LL is used on one link and another link is active (whether it is LL or not). Lengthy description of problem: Section 3 outlines options and strategies but does not definitively solve the problem of multihoming used concurrently with IPv4 LL autoconfiguration. Long discussion on the zeroconf mailing list shows there is a tension between two objectives: (1) Continuous use of LL on one or more interface - to ensure availability of local communication in all cases and (2) A process by which a scoped address architecture for IPv4 can be avoided. A scoped address architecture presents problems for upper layers and in any case has not yet been thought through so as to work generally for IPv4. The second objective has more support in the working group, but the first objective is a real concern. The purpose of this issue is to o Remove text in section 3 which could mislead or confuse implementors by presenting multihoming as an understood or solvable problem, simply by by following the steps given in the document. o To not preclude those who have a plan on how to get multihoming from doing so and not then be non-compliant with the specification. o To not stand in the way for later work to describe how to solve the multihoming problem of scoped addresses in a general and correct way. All we can say in this document with certainty is how hosts use IPv4 LL on a single link to configure addresses. We must also give guidance to router vendors. In the multihoming section we will simply give warnings about known problems and indicate that if you proceed there, you are on your own. ---------------------------------- Requested Change: Replace Section 3 with the following text: 3. Considerations for Multiple Interfaces Hosts which have more than one active interface and elect to implement dynamic configuration of Link-Local IPv4 addresses on one or more of those interfaces will face various problems. This section lists these problems but does no more than indicate how one might solve them. At the time of this writing, there is no silver bullet which solves these problems in all cases, in a general way. Implementors must think through these issues before implementing the protocol specified in this document which will have more than one active interface. 3.1. Scoped addresses The general problem here is that a host may be attached to more than one network at the same time. This could be due to having more than one interface attached to distinct physical networks, or due to support of a tunnel, virtual private network, or some other interface termination at the host over a single interface. It would be nice if there was a single address space used in every network, but this is not the case. Addresses used in one network, be it a network behind a NAT or a link on which Link-Local IPv4 addresses are used, cannot be used in another network and have the same effect. It would also be nice if addresses were not exposed to applications, but they are. Most software using TCP/IP which await messages receives from any interface at a particular port number, for a particular transport protocol. Applications are generally only aware (and care) that they have received a message. The application knows the source address of the sender to whom the application will reply. The first scoped address problem is source address selection. A multihomed host has more than one address. Which address should be used as the source address when sending to a particular destination? This answer is usually answered by referring to a routing table, which expresses which interface (with which address) to send, and how to send (should one forward to a router, or send directly). The choice is made complicated by scoped addresses because the address range in which the destination lies may be ambiguous. The table may not be able to yield a good answer. The second scoped address problem arises from scoped parameters leaking outside their scope. This is discussed in Section 7. It is possible to overcome these problems. One way is to expose scope information to applications such that they are always aware of what scope a peer is in. This way, the correct interface could be selected, a safe procedure could be followed with respect to forwarding addresses and other scoped parameters. There are other possible approaches. None of these methods have been standardized for IPv4 nor are they specified in this document. An implementor could undertake to solve these problems, but cannot simply ignore them. With sufficient experience, it is hoped that specifications will emerge explaining how to overcome scoped address multihoming problems. 3.2. Address Ambiguity This is a core problem with respect to Link-Local IPv4 addresses configured on more than one interface. What should a host do when it needs to send to Link-Local destination L and L can be resolved using ARP on more than one link? One possibility is to support this only in the case where the application specifically expresses which interface to send from. Another possibility is to determine routes by expressing destinations with a higher layer, unambiguous identifier. That is, if addresses are not exposed to applications at all, routing decisions can be made by the IPv4 stack without having to resort to routing decisions based on ambiguous addresses. The obvious candidate for this 'higher level identifier' is the Fully Qualified Domain Name (FQDN). However caution is advisable since routing on the basis of names is not standardized. Just as address spaces can be scoped and ambiguous, so can name spaces. This is especially true for self assigned or automatically generated names. In short, there no standard or obvious solution to this problem. Existing application software written for the Internet protocol suite is largely incapable of dealing with address ambiguity. This does not preclude an implementor from finding a solution, writing applications which are able to use it, and providing a host which can support dynamic configuration of Link-Local IPv4 addresses on more than one interface. This solution will almost surely not be generally applicable to existing software and transparent to higher layers, however. 3.3. Interoperation with Legacy Hosts Attention is paid in this specification to transition from the use of Link-Local IPv4 addresses to routable addresses (see Section 1.5). The intention is to allow a host with a single interface to first support Link-Local configuration then gracefully transition to the use of a routable address. Since the host transitioning to the use of a routable address will not advertise scoped address information, the scoped address issues described in Section 3.1 will apply. A host which conforms to this specification will know that a Link-Local IPv4 destination must be reached by forwarding to the destination, not to a router, even if the host is sending from a routable address. A host with a Link-Local IPv4 address may send to a destination which does not have a Link-Local IPv4 address. If the host is not multihomed, the procedure is simple and unambiguous: Using ARP and forwarding directly to on-link destinations is the default route. If the host is multihomed, however, the routing policy is more complex, especially if one of the interfaces is configured with a routable address and the default route is (sensibly) directed at a router accessible through that interface. The following example illustrates this problem and provides a common solution to it. i1 +---------+ i2 i3 +-------+ ROUTER-------= HOST1 =---------= HOST2 | link1 +-------=-+ link2 +-------+ In the figure above, HOST1 is connected to link1 and link2. Interface i1 is configured with a routable address, while i2 is a Link-Local IPv4 address. HOST1 has its default route set to ROUTER's address, through i1. HOST1 will route to destinations in 169.252/16 to i2, sending directly to the destination. HOST2 has a configured (non-Link-Local) IPv4 address assigned to i3. Using a name resolution or service discovery protocol HOST1 can discover HOST2's address. Since HOST2's address is not in 169.254/16, HOST1's routing policy will send datagrams to HOST2 via i1, to the ROUTER. Unless there is a route from ROUTER to HOST2, the datagrams sent from HOST1 to HOST2 will not reach it. One solution to this problem is for a host to attempt to reach any host locally (using ARP) for which it receives an unreachable ICMP error message (ICMP message codes 0, 1, 6 or 7, see [RFC792]). The host tries all its attached links in a round robin fashion. This has been implemented successfully for some IPv6 hosts, to circumvent exactly this problem. In terms of this example, HOST1 upon failing to reach HOST2 via the ROUTER, will attempt to forward to HOST2 via i2 and succeed. It may also be possible to overcome this problem using techniques described in section 3.2, or other means not discussed here. This specification does not provide a standard solution, nor does it preclude implementors from supporting multihomed configurations, provided that they address the concerns in this section for the applications which will be supported on the host. 3.4. Unintentional Autoimmunity Care must be taken if a multihomed host can support more than one interface onto the same link, all of which will support Link-Local 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. From owner-zeroconf@merit.edu Mon May 26 05:56: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 FAA07154 for ; Mon, 26 May 2003 05:56:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EDC4991222; Mon, 26 May 2003 05:55:56 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C173891226; Mon, 26 May 2003 05:55:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE10D91222 for ; Mon, 26 May 2003 05:55:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BECCE5E9D6; Mon, 26 May 2003 05:55:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 74F455E9CC for ; Mon, 26 May 2003 05:55:54 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4Q9tq4Z000307 for ; Mon, 26 May 2003 02:55:53 -0700 (PDT) Received: from sun.com (vpn-129-156-96-91.EMEA.Sun.COM [129.156.96.91]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h4Q9tpw09859 for ; Mon, 26 May 2003 11:55:51 +0200 (MEST) Message-ID: <3ED1E3FB.20302@sun.com> Date: Mon, 26 May 2003 11:52:59 +0200 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 Subject: WG Action - 1 week to discuss [LL32] Multihoming problems not solved but that is OK Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Please discuss LL32 from now till May 3 (leaving an extra day since May 26 is a holiday in the US and May 29 is a holiday in southern Europe). Please send any comments to the zeroconf mailing list regarding replacing section 3 entirely, as described in LL32. Since I have received support from many WG members for this text already, if the disposition is to accept the text. Please speak up and help us to clarify, improve or if necessary reject this text. If there are no comments, this issue will be ACCEPTED. Thanks, Erik Guttman. ps. apologies if this is a duplicate message From owner-zeroconf@merit.edu Mon May 26 06:05:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07320 for ; Mon, 26 May 2003 06:05:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 45FAF91226; Mon, 26 May 2003 06:05:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E62CC91229; Mon, 26 May 2003 06:05:26 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EC5E791226 for ; Mon, 26 May 2003 06:05:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D04A75E9DD; Mon, 26 May 2003 06:04:07 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 241C75E9CC for ; Mon, 26 May 2003 06:04:04 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4QA3v4Z003526; Mon, 26 May 2003 03:03:58 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4QA3uL17150; Mon, 26 May 2003 12:03:56 +0200 (MEST) Date: Mon, 26 May 2003 12:03:10 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: LL11: Add security consideration To: Stuart Cheshire Cc: zeroconf@merit.edu In-Reply-To: "Your message with ID" <200305221905.h4MJ5J7h021942@scv2.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > I know that Erik Nordmark views changing your IP address firmly in the > category of "problem" rather than "solution", which is why he wants > language in the draft to encourage other people to see it that way too, Stuart, I truly believe you've misunderstood what I've said. The alternative is that you are intentionally misconstruing my comments, which I do not think is the case. My first point is that the change to the way ARP is used from detecting and doing nothing, to detecting and changing the IP address, is a significant change hence it makes sense to think carefully about this change. My second point is that without being able to secure ARP, there is a very difficult tradeoff between reacting to ARP messages by changing the IP address (helps when the box doesn't need a long-term stable IP address when there are no attackers on the link) and defending the address (helps when those are not true). Glossing over the existence of this tradeoff would be a disservice to the quality and integrity of the standards issued by the IETF. Since we are not going to get a secure ARP deployed at a minimum the specification needs to present this tradeoff to the readers/implementors. So this is not a black and white technical discussion. Erik From owner-zeroconf@merit.edu Tue May 27 04:04:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03191 for ; Tue, 27 May 2003 04:04:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B147E91203; Tue, 27 May 2003 04:04:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76DDF91207; Tue, 27 May 2003 04:04:16 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4022D91203 for ; Tue, 27 May 2003 04:04:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1D2255DE22; Tue, 27 May 2003 04:04:15 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 66E675DE21 for ; Tue, 27 May 2003 04:04:05 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h4R83IE15959; Tue, 27 May 2003 15:03: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 h4R7oJM08301; Tue, 27 May 2003 14:50:22 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf Subject: Re: WG Action - 1 week to discuss [LL32] Multihoming problems not solved but that is OK In-Reply-To: <3ED1E3FB.20302@sun.com> References: <3ED1E3FB.20302@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 May 2003 14:50:19 +0700 Message-ID: <8299.1054021819@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 26 May 2003 11:52:59 +0200 From: Erik Guttman Message-ID: <3ED1E3FB.20302@sun.com> | Please discuss LL32 from now till May 3 (leaving an extra day since May | 26 is a holiday in the US and May 29 is a holiday in southern Europe). Don't we also get an extra day because May 30 is a new moon? (And I suspect that you meant June 3 anyway...) | Please send any comments to the zeroconf mailing list regarding | replacing section 3 entirely, as described in LL32. The general thrust seems fine to me, just a few editorial nits ... Implementors must think through these issues before implementing the protocol specified in this document which will have more than one active interface. Insert "on a system" before "which". Perhaps change "will" to "might" (or "may") (systems with plug in slots to which new interfaces can be connected are a problem, even if they won't necessarily have anything plugged in). With sufficient experience, it is hoped that specifications will emerge explaining how to overcome scoped address multihoming problems. I'd delete that - by the time this could happen, what is really hoped is that IPv4 will be obsolete. IPv6 already has a standardised API to handle this problem, so applications can cope there. But even if IPv4 is still around, getting all the necessary experience will mean multiple (probably) different solutions tried by different people - at that stage, attempting to pick one of them and converge upon it really won't be worth the bother. Another possibility is to determine routes by expressing destinations with a higher layer, unambiguous identifier. That is, if addresses are not exposed to applications at all, routing decisions can be made by the IPv4 stack without having to resort to routing decisions based on ambiguous addresses. I think I understand the motivation for that (where it comes from), but actually making anything like that work would be a major undertaking, and would have major ramifications to the whole IP stack (this is a bigger change than IPv6...) The simple "use something else at the app layer" implementation just translates the something else into addresses for use over the wire, (whether in the app, in the stack, or somewhere between doesn't matter). The potentially ambiguous addresses remain - if the same address exists at multiple places, there's still no way at the routing or packet forwarding level to know which was intended (without tagging the addresses in some way, which was the previous possible solution in the supplied text). Note here that it is necessary to deal with things like DNS servers (any UDP application) which is responding to packets received - there is no other identifier, just the address. The app may receive packets from the same address (over different interfaces of course), and then reply to them in either order. Handling this all gets very messy (without tagging the addresses - with address tags, so that in the "I came from here", "here" isn't just a 32 bit address and 16 bit port, but contains more). I know there's a desire to express at least two different ways by which the ambiguous address problem might be overcome, but I don't think suggesting this one makes sense - and if that means leaving just one method even mentioned, then so be it. Delete all this reference to using higher level names instead of addresses as the application API. 3.3. Interoperation with Legacy Hosts I'm not sure that most of this section really belongs in section 3, it isn't really discussing the same issue is it? Nevermind. HOST1 will route to destinations in 169.252/16 to i2, sending directly to the destination. 169.254/16 ?? One solution to this problem is for a host to attempt to reach any host locally (using ARP) for which it receives an unreachable ICMP error This really has nothing at all to do with LL addresses, does it? That is, the fact that HOST1 is using LL addresses on i2 is irrelevant to this problem, isn't it? It would certainly be nice if all the world's routing problems could magically be solved by the introduction of LL addresses, but I don't think that's going to happen. The problem here is the existence of a legacy host (HOST2) using an inappropriate address for the link to which it is connected. There's nothing new about this, and nothing that LL should necessarily be doing to fix it. It is kind of nice that in a few scenarios, hosts that are LL aware will actually be able to figure out what is probably going on here, and make it all work. But we shouldn't be expecting that, nor encouraging anyone to go out of their way to try and make LL addresses perform more magic than that which they're intended to perform. We don't have to fix every problem. I think I'd just delete the whole of the (proposed new) section 3.3. kre From owner-zeroconf@merit.edu Tue May 27 16:01:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28834 for ; Tue, 27 May 2003 16:01:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4D7E19121E; Tue, 27 May 2003 16:00:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 150F091223; Tue, 27 May 2003 16:00:20 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ABED49121E for ; Tue, 27 May 2003 16:00:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 891555DDBC; Tue, 27 May 2003 16:00:19 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by segue.merit.edu (Postfix) with ESMTP id 1EEF45DDC9 for ; Tue, 27 May 2003 16:00:18 -0400 (EDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h4RK3BFI013370; Tue, 27 May 2003 23:03:12 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h4RK39Ls013369; Tue, 27 May 2003 23:03:09 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: New Issue [LL32] Multihoming problems not solved but that is OK From: Mika Liljeberg To: Erik Guttman Cc: zeroconf In-Reply-To: <3ED1E3CF.3020508@sun.com> References: <3ED1E3CF.3020508@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1054065788.5547.194.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 27 May 2003 23:03:09 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Comments below. On Mon, 2003-05-26 at 12:52, Erik Guttman wrote: [...] > All we can say in this document with certainty is how hosts use IPv4 LL > on a single link to configure addresses. We must also give guidance to > router vendors. In the multihoming section we will simply give warnings > about known problems and indicate that if you proceed there, you are on > your own. Given this, section 1.5 should state explicitly that the text only applies to singlehomed hosts, and refer multihomed implementations to section 3. [...] > 3. Considerations for Multiple Interfaces > > Hosts which have more than one active interface and elect to implement > dynamic configuration of Link-Local IPv4 addresses on one or more of > those interfaces will face various problems. This section lists these > problems but does no more than indicate how one might solve them. At the > time of this writing, there is no silver bullet which solves these > problems in all cases, in a general way. Implementors must think through > these issues before implementing the protocol specified in this document something missing? I'll assume the sentence was supposed to end with something like "...as part of a multihoming capable TCP/IP stack", rather than > which will have more than one active interface. But what does this mean, anyway? I hear developers asking: "Most TCP/IP stacks support multihoming. Is this specification supposed to be implementable on multihomed stacks or not?" Assuming the implementor of a multhomed stack does not want to wing it, is he supposed to: 1) not implement LLs at all? 2) turn LLs off if more than one interface is activated? 3) provide per-interface configuration knobs and leave it to the user to deal with the problem? 4) any of the above? (probably) > 3.1. Scoped addresses This section seems to be primarily talking about ambiguous addresses. [...] > The first scoped address problem is source address selection. A > multihomed host has more than one address. Which address should be used > as the source address when sending to a particular destination? This > answer is usually answered by referring to a routing table, which > expresses which interface (with which address) to send, and how to send > (should one forward to a router, or send directly). The choice is made > complicated by scoped addresses because the address range in which the > destination lies may be ambiguous. The table may not be able to yield a > good answer. This isn't really talking about source address selection, is it? This describes a difficulty with next hop selection, caused by the ambiguity of the destination address. Move this to section 3.2. > The second scoped address problem arises from scoped parameters leaking > outside their scope. This is discussed in Section 7. > > It is possible to overcome these problems. One way is to expose scope > information to applications such that they are always aware of what > scope a peer is in. This way, the correct interface could be selected, a > safe procedure could be followed with respect to forwarding addresses > and other scoped parameters. There are other possible approaches. None > of these methods have been standardized for IPv4 nor are they specified > in this document. The last sentence is stating the obvious, since IETF is not in the habit of standardizing APIs. It would be more helpful to start off by suggesting that good API design can mitigate the problems and then go on to give a few pointers on how to do that. [...] > 3.2. Address Ambiguity [...] > Another possibility is to determine routes by expressing destinations > with a higher layer, unambiguous identifier. That is, if addresses are > not exposed to applications at all, routing decisions can be made by the > IPv4 stack without having to resort to routing decisions based on > ambiguous addresses. > > The obvious candidate for this 'higher level identifier' is the Fully > Qualified Domain Name (FQDN). However caution is advisable since routing > on the basis of names is not standardized. Just as address spaces can be > scoped and ambiguous, so can name spaces. This is especially true for > self assigned or automatically generated names. The above is going a bit far afield. Probably more confusing than helpful. > In short, there no standard or obvious solution to this problem. > Existing application software written for the Internet protocol suite is > largely incapable of dealing with address ambiguity. This does not > preclude an implementor from finding a solution, writing applications > which are able to use it, and providing a host which can support dynamic > configuration of Link-Local IPv4 addresses on more than one interface. > This solution will almost surely not be generally applicable to existing > software and transparent to higher layers, however. > 3.3. Interoperation with Legacy Hosts This section is mis-named. The discussion applies to all cases where a node using a LL address communicates with a node using a routable address. This is ESPECIALLY relevant when the other node is LL-compliant but happens to have a routable address configured. > Attention is paid in this specification to transition from the use of > Link-Local IPv4 addresses to routable addresses (see Section 1.5). The > intention is to allow a host with a single interface to first support > Link-Local configuration then gracefully transition to the use of a > routable address. Since the host transitioning to the use of a routable > address will not advertise scoped address information, the scoped > address issues described in Section 3.1 will apply. A host which > conforms to this specification will know that a Link-Local IPv4 > destination must be reached by forwarding to the destination, not to a > router, even if the host is sending from a routable address. > > A host with a Link-Local IPv4 address may send to a destination which > does not have a Link-Local IPv4 address. If the host is not multihomed, > the procedure is simple and unambiguous: Using ARP and forwarding > directly to on-link destinations is the default route. I have a problem with this claim. If you apply this rule to the figure below, the routing table of interface i2 depends on whether interface i1 is UP (HOST1 is multihomed) or DOWN (HOST1 is singlehomed). That's hardly simple or unambiguous. > If the host is > multihomed, however, the routing policy is more complex, especially if > one of the interfaces is configured with a routable address and the > default route is (sensibly) directed at a router accessible through that > interface. The following example illustrates this problem and provides > a common solution to it. > > i1 +---------+ i2 i3 +-------+ > ROUTER-------= HOST1 =---------= HOST2 | > link1 +-------=-+ link2 +-------+ > > In the figure above, HOST1 is connected to link1 and link2. Interface > i1 is configured with a routable address, while i2 is a Link-Local IPv4 > address. HOST1 has its default route set to ROUTER's address, through > i1. HOST1 will route to destinations in 169.252/16 to i2, sending > directly to the destination. > > HOST2 has a configured (non-Link-Local) IPv4 address assigned to i3. > > Using a name resolution or service discovery protocol HOST1 can discover > HOST2's address. Since HOST2's address is not in 169.254/16, HOST1's > routing policy will send datagrams to HOST2 via i1, to the ROUTER. > Unless there is a route from ROUTER to HOST2, the datagrams sent from > HOST1 to HOST2 will not reach it. > > One solution to this problem is for a host to attempt to reach any host > locally (using ARP) for which it receives an unreachable ICMP error > message (ICMP message codes 0, 1, 6 or 7, see [RFC792]). It looks like this will either block the ICMP error delivery to transport and application layers or cause the applicatins to see some interesting transient failures. > The host tries > all its attached links in a round robin fashion. This has been > implemented successfully for some IPv6 hosts, to circumvent exactly this > problem. Interesting, I wasn't aware of that. Last time I asked about this on the ipng list (maybe a couple of months ago), nobody owned up to having implemented a solution. The KAME people actually said that they support the "try on-link" rule but that it is turned off by default, because it does not work with multihoming. Can you point me to some implementations that actually do this? MikaL From owner-zeroconf@merit.edu Tue May 27 16:10: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 QAA29380 for ; Tue, 27 May 2003 16:10:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 89C6291223; Tue, 27 May 2003 16:10:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B8C991224; Tue, 27 May 2003 16:10:11 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3D36891223 for ; Tue, 27 May 2003 16:10:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1D9C15DE0D; Tue, 27 May 2003 16:10:10 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by segue.merit.edu (Postfix) with ESMTP id F19715DE04 for ; Tue, 27 May 2003 16:10:08 -0400 (EDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h4RKCtFI013427; Tue, 27 May 2003 23:12:56 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h4RKCo8s013425; Tue, 27 May 2003 23:12:50 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG Action - 1 week to discuss [LL32] Multihoming problems not solved but that is OK From: Mika Liljeberg To: Robert Elz Cc: Erik Guttman , zeroconf In-Reply-To: <8299.1054021819@munnari.OZ.AU> References: <3ED1E3FB.20302@sun.com> <8299.1054021819@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1054066367.5544.205.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 27 May 2003 23:12:50 +0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Robert, On Tue, 2003-05-27 at 10:50, Robert Elz wrote: > 3.3. Interoperation with Legacy Hosts [...] > The problem here is the existence of a legacy host (HOST2) using an > inappropriate address for the link to which it is connected. There's > nothing new about this, and nothing that LL should necessarily be > doing to fix it. The section is incorrectly named. The problem, as described, occurs because HOST2 is LL-compliant and has a routable address. > I think I'd just delete the whole of the (proposed new) section 3.3. Disagree. MikaL From owner-zeroconf@merit.edu Wed May 28 07:17: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 HAA24865 for ; Wed, 28 May 2003 07:17:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 852F691233; Wed, 28 May 2003 07:17:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B0B791235; Wed, 28 May 2003 07:17:21 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E624A91233 for ; Wed, 28 May 2003 07:17:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 615675E2AC; Wed, 28 May 2003 07:17:18 -0400 (EDT) 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 95C0A5E2AD for ; Wed, 28 May 2003 07:17:02 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h4SBGwP28138; Wed, 28 May 2003 18:16:59 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4SB3xV15982; Wed, 28 May 2003 18:04:02 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: Erik Guttman , zeroconf Subject: Re: WG Action - 1 week to discuss [LL32] Multihoming problems not solved but that is OK In-Reply-To: <1054066367.5544.205.camel@devil> References: <1054066367.5544.205.camel@devil> <3ED1E3FB.20302@sun.com> <8299.1054021819@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 May 2003 18:03:59 +0700 Message-ID: <15980.1054119839@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 27 May 2003 23:12:50 +0300 From: Mika Liljeberg Message-ID: <1054066367.5544.205.camel@devil> | The section is incorrectly named. The problem, as described, occurs | because HOST2 is LL-compliant and has a routable address. No, the same problem occurs of HOST2 isn't LL compliant. It is that it has a routable address that is the problem. If HOST2 were LL compliant, then given its routable address is non-functional it ought to disable it, and give itself a LL address, in which case everything would work OK (well, HOST2 would be able to contact HOST1 anyway). This, in combination with the section title ("Legacy Hosts") (which I know you think is the wrong title, but is what is there) makes me suspect that this stuff is really intended to be about HOST1 (LL compliant) talking to HOST2 (not LL compliant). That's where the real problem for the LL spec arises in the multi-homed case, as there's nothing that can be done to change HOST2's behaviour, and no reasonable way that HOST1's forwarding table can be built so that a route to HOST2's address is out i2. Without the multi-homing, HOST1 could assume that "everything" is out i2, and just ARP there. So, in the single interface case, a solution is possible - which is why all of this is being dealt with in the "problems of multi homing" section - but the reason problem here is the legacy host using an address which can't really work (certainly in the diagram there's no way HOST2 could ever talk with anything other than HOST1). That's what I meant about not attempting to make LL solve all the world's problems - HOST2 (being a legacy host) simply needs to be properly configured (in this case, that may mean manually configured with a LL address) for the net to which it is connected. That's the way it has always been, and I personally see no problem with not fixing problems for hosts that haven't implemented the spec. kre From owner-zeroconf@merit.edu Wed May 28 11:20:33 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08053 for ; Wed, 28 May 2003 11:20:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6B5C091239; Wed, 28 May 2003 11:20:26 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3711E9123A; Wed, 28 May 2003 11:20:26 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 414EC91239 for ; Wed, 28 May 2003 11:20:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 236EC5DDC9; Wed, 28 May 2003 11:20:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id D1C4D5DDBD for ; Wed, 28 May 2003 11:20:24 -0400 (EDT) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id CC9FA598B7; Wed, 28 May 2003 16:20:26 +0100 (BST) Message-ID: <008701c3252c$a8db5100$131010ac@aldebaran> From: "Philip Nye" To: "Robert Elz" , "Erik Guttman" Cc: "zeroconf" References: <3ED1E3FB.20302@sun.com> <8299.1054021819@munnari.OZ.AU> Subject: Re: WG Action - 1 week to discuss [LL32] Multihoming problems not solved but that is OK Date: Wed, 28 May 2003 16:20:23 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Robert Elz" > > The problem here is the existence of a legacy host (HOST2) using an > inappropriate address for the link to which it is connected. Not necessarily. Link2 could be a routable link which HOST2 is fully and properly configured for. It could be that HOST1 has just assigned an LL address there because it received no DHCP response - exactly the sort of ad-hoc connection which many here have been pressing for - perhaps HOST2 is the printer which HOST1 just wants to print a quick page on... I agree with Mika that this problem is not to do with whether HOST2 is "legacy" or not - just that it has a non-LL address. Philip From owner-zeroconf@merit.edu Wed May 28 13:50:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13388 for ; Wed, 28 May 2003 13:50:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 340869123D; Wed, 28 May 2003 13:50:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05C1F9123E; Wed, 28 May 2003 13:50:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C2B19123D for ; Wed, 28 May 2003 13:50:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0111A5DDC4; Wed, 28 May 2003 13:50:15 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id B2DB45DDBA for ; Wed, 28 May 2003 13:50:14 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4SHoBLv017675; Wed, 28 May 2003 10:50:11 -0700 (PDT) Received: from sun.com (vpn-129-159-0-237.EMEA.Sun.COM [129.159.0.237]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h4SHo8w01617; Wed, 28 May 2003 19:50:08 +0200 (MEST) Message-ID: <3ED4F623.40905@sun.com> Date: Wed, 28 May 2003 19:47:15 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Philip Nye Cc: Robert Elz , zeroconf Subject: Re: WG Action - 1 week to discuss [LL32] Multihoming problems not solved but that is OK References: <3ED1E3FB.20302@sun.com> <8299.1054021819@munnari.OZ.AU> <008701c3252c$a8db5100$131010ac@aldebaran> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I agree with Mika that this problem is not to do with whether HOST2 is > "legacy" or not - just that it has a non-LL address. The section title was originally called "Interoperation with hosts that support link-local which currently don't have a link-local address" but that was way too long and doesn't really get at what this section is about. "Interoperation with Legacy Hosts" is clearly wrong. How about "Reaching link-local savvy routable address configured neighbors" Erik From owner-zeroconf@merit.edu Thu May 29 21:02:57 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01454 for ; Thu, 29 May 2003 21:02:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8E6E991287; Thu, 29 May 2003 21:02:50 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 596149128A; Thu, 29 May 2003 21:02:50 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE1C891287 for ; Thu, 29 May 2003 21:02:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 97B225DFF6; Thu, 29 May 2003 21:02:42 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 590CA5DFF4 for ; Thu, 29 May 2003 21:02:42 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.9/8.12.9) with ESMTP id h4U12ffR029837 for ; Thu, 29 May 2003 18:02:41 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 29 May 2003 18:02:26 -0700 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv1.apple.com (8.12.9/8.12.9) with SMTP id h4U12eFf012412 for ; Thu, 29 May 2003 18:02:40 -0700 (PDT) Message-Id: <200305300102.h4U12eFf012412@scv1.apple.com> Subject: Re: Example email from vendor: Probe after cable connection or not? Date: Thu, 29 May 2003 18:02:42 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >If this text is acceptable to you I will open a new 'issue' for >discussion. It looks completely reasonable and uncontroversial to me. >I want to follow the 'issue' procedure since I have been wrong about how >controversial things can prove quite often in this WG. Thank you Erik. I am torn between the desire to get the document finished, and the desire to not have obvious known omissions in it. If you think this new issue will not cause substantial delay, please introduce it. My proposed wording would be: 2.2 Claiming a Link-Local Address After it has selected an address, a host MUST test to see if the address is already in use before beginning to use it. To be more specific, any time that a network interface transitions from an inactive to an active state, the host is in a position where it has no knowledge of what addresses may be currently in use on that link. Were it immediately to begin using an address which is already in use by some other host, this would be disruptive to that other host. For this reason, before using the address (e.g. using it as the source address in an IP packet, or as the Sender IP address in an ARP packet) a host MUST perform the probing test described below to achieve better confidence that using the address will not cause disruption. Examples of events that entail an interface becoming active include: * Reboot/startup * Wake from sleep (if network interface was inactive during sleep) * Bringing up previously inactive network interface * Ethernet hardware link-state change that indicates a cable was attached. * Association with a wireless base station. * etc. Note that a host MUST NOT perform this check periodically as a matter of course. This would be a waste of network bandwidth, and is unnecessary due to the ability of hosts to passively discover conflicts, as described in Section 2.5. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri May 30 04:02: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 EAA24182 for ; Fri, 30 May 2003 04:02:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C9D6591291; Fri, 30 May 2003 04:02:43 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F0AF91293; Fri, 30 May 2003 04:02:43 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A005D91291 for ; Fri, 30 May 2003 04:02:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 61A7F5E08D; Fri, 30 May 2003 04:02:16 -0400 (EDT) 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 9CF5B5E023 for ; Fri, 30 May 2003 04:02:14 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h4U829P13291; Fri, 30 May 2003 15:02:10 +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 h4U7mEE08481; Fri, 30 May 2003 14:48:16 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Example email from vendor: Probe after cable connection or not? In-Reply-To: <200305300102.h4U12eFf012412@scv1.apple.com> References: <200305300102.h4U12eFf012412@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 May 2003 14:48:14 +0700 Message-ID: <8479.1054280894@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 29 May 2003 18:02:42 -0700 From: Stuart Cheshire Message-ID: <200305300102.h4U12eFf012412@scv1.apple.com> | I am torn between the desire to get the document finished, and the desire | to not have obvious known omissions in it. If you think this new issue | will not cause substantial delay, please introduce it. My proposed | wording would be: (even before this gets an issue number, etc...) This all looks fine to me. Include it in the doc. What's more, if we can get people implementing LL's to actually do this, we may be able to also get them to improve the rest of the networking stacks - there are far too many systems where the drivers simply don't make this kind of state change available to the network stack at all, and if we can contribute to getting that fixed, because of this need for LL address probing, that's a very good thing. kre