From owner-zeroconf@merit.edu Sat Mar 1 18:44:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20802 for ; Sat, 1 Mar 2003 18:44:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BA37A912AA; Sat, 1 Mar 2003 18:46:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC867912EE; Sat, 1 Mar 2003 18:46:27 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 296DB912AA for ; Sat, 1 Mar 2003 18:46:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 45C8D5E011; Sat, 1 Mar 2003 18:45:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by segue.merit.edu (Postfix) with ESMTP id EECC05E010 for ; Sat, 1 Mar 2003 18:45:53 -0500 (EST) Received: from rygar.gpcc.itd.umich.edu (rygar.gpcc.itd.umich.edu [141.211.2.202]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id SAA19702; Sat, 1 Mar 2003 18:45:53 -0500 (EST) Received: from localhost (sgoswami@localhost) by rygar.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id SAA07698; Sat, 1 Mar 2003 18:45:53 -0500 (EST) Date: Sat, 1 Mar 2003 18:45:52 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@rygar.gpcc.itd.umich.edu To: Robert Elz Cc: zeroconf@merit.edu Subject: Re: LL24: Weaken the PRN requirement In-Reply-To: <3443.1046428894@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Well, that was just one example of an alternative algorithm to PRN. There are many such algorithms, some are deterministic versus the probabilistic algorithm inherent in PRN. I am trying to say that leave the choice of selection of the LLv4 address to the implementation. PRN can be the Zeroconf suggested algorithm. Subrata On Fri, 28 Feb 2003, Robert Elz wrote: > Date: Thu, 27 Feb 2003 08:43:15 -0800 > From: "Subrata Goswami" > Message-ID: <004b01c2de7f$537da030$1bc0140a@SGOSWAMIPCL> > > | Actually I am trying to say that if there is a way for a LL nodes to > | determine the other LL nodes' LLv4 addresses, then it does not need > | to use the PRN. > > Even given that there was a way, this doesn't work, as we want 20 or 30 > (or 200 or 300) nodes all running the algorithm at the same time to start > at (mostly) different values - if they all somehow just knew what LL > addresses were assigned currently, and just picked some unallocated one > algorithmically, then they're all likely to pick the same one (given that > most of them will be running the same code on the same kind of processor). > > When that happens, at most one of them can succeed to obtain that address, > after which they all have to start again, now knowing (perhaps) one more > address that has been allocated, and all allocating the next one in their > sequence. > > This just doesn't work. > > What's more .. > > | An alternative algorithm is provided below - although it is somewhat > | extreme it would work. > > Work in the sense that it would find out what is in use, currently, > perhaps yes. Work in that the network would survive such an attack > I doubt ... Up to 64K broadcast packets from every host as it starts > is not something that you'd want to see happening on your net. > > Using random numbers avoids these problems (given a big enough range, > which we have here). It is a common technique, and works well. > What's more, it is enormously cheaper for the node, and the net, than > attempting to find everything that is allocated. There is no reason > to even allow different methods (except perhaps, for real random numbers > instead of PRNs). > > kre > From owner-zeroconf@merit.edu Sun Mar 2 08: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 IAA10858 for ; Sun, 2 Mar 2003 08:06:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AFA2991239; Sun, 2 Mar 2003 08:08:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F87A91250; Sun, 2 Mar 2003 08:08:13 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1AA3391239 for ; Sun, 2 Mar 2003 08:08:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id E51695E0D4; Sun, 2 Mar 2003 08:08:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 7D4F75E09E for ; Sun, 2 Mar 2003 08:08:10 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h22D80O18336; Sun, 2 Mar 2003 20:08:00 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h22D7ko17130; Sun, 2 Mar 2003 20:07:47 +0700 (ICT) From: Robert Elz To: John Schnizlein Cc: zeroconf@merit.edu Subject: Re: LL21 vs LL29 In-Reply-To: <4.3.2.7.2.20030228155032.021a5ad8@wells.cisco.com> References: <4.3.2.7.2.20030228155032.021a5ad8@wells.cisco.com> <4.3.2.7.2.20030228082022.020a23a8@wells.cisco.com> <4.3.2.7.2.20030228082022.020a23a8@wells.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 02 Mar 2003 20:07:46 +0700 Message-ID: <17128.1046610466@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 28 Feb 2003 16:00:06 -0500 From: John Schnizlein Message-ID: <4.3.2.7.2.20030228155032.021a5ad8@wells.cisco.com> | My concern regards legacy routers that proxy for all addresses | outside the subnet for which the interface is configured. A router that does that wouldn't allow LL addresses to be configured on a node in the first place. It would reply to the ARP probe requests, and effectively mark all addresses as "taken". The situation where proxy-arp can hurt, is where a router just proxy-arps for some addresses (not including the LL block) and a node sends from its LL address to something, and the proxy-arp causes the packet to go to such a router, and then get forwarded. That one can happen - but isn't going to happen very often, and does essentially no harm if it does happen to occur. | While I would prefer that hosts get reasonable parameters for | configuration of a default gateway, I consider it rude to cause | these old network configurations that used to be causing no | trouble to start spewing LL traffic out into the Internet. Yes - but once noticed, even an ancient router (or something between it and the internet) can be configured to block such traffic. | Expecting the people who have this old configuration to change | it to "protect the Internet from trash" coming from their subnets | is not reasonable. Why? They do that to protect the internet from lots of other trash. Or they don't, and the internet survives anyway. | Does using TTL=1, which rather blatantly declares "no forwarding" | on link-local traffic have any down side, after adjusted as | Christian proposed for applications that "know better"? It adds unnecessary noise to the spec, and an extra complication for some implementations (which have to meddle in a different part of the IP code, depending upon which addresses happen to be used). The reason I said that I could live with Christian's version of LL29, is that from the outside, you can't tell whether the stack is setting TTL=30 or whether the application using the stack is telling the stack to set TTL=30 - which essentially means that a stack can just ignore the "set TTL=1" by claiming that the application has always told it to use some other TTL - which it could even reasonably do, just by documenting some different default TTL for applications that don't do the appropriate magic to set a specific TTL (so all applications which don't explicitly ask are assumed to be requesting the documented default). So, that statement of the requirement is very weak, and not a lot different from LL21. I'd still prefer to me more honest, and just adopt LL21 though. I don't see any significant harm that it will do. kre From owner-zeroconf@merit.edu Sun Mar 2 08:09: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 IAA10880 for ; Sun, 2 Mar 2003 08:09:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6ED1F91250; Sun, 2 Mar 2003 08:10:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36628912F8; Sun, 2 Mar 2003 08:10:56 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 46C6891250 for ; Sun, 2 Mar 2003 08:10:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C6245E0DB; Sun, 2 Mar 2003 08:10:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id B81985E0D4 for ; Sun, 2 Mar 2003 08:10:53 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h22DAnO18774; Sun, 2 Mar 2003 20:10:49 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h22DAYo17145; Sun, 2 Mar 2003 20:10:34 +0700 (ICT) From: Robert Elz To: "s. goswami" Cc: zeroconf@merit.edu Subject: Re: LL24: Weaken the PRN requirement In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 02 Mar 2003 20:10:34 +0700 Message-ID: <17143.1046610634@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sat, 1 Mar 2003 18:45:52 -0500 (EST) From: "s. goswami" Message-ID: | There are many such algorithms, some are deterministic | versus the probabilistic algorithm inherent in PRN. The problem is that any deterministic algorithm will, in some environments, result in hundreds of nodes running the exact same thing, at the same time, and producing the exact same answers. That produces a mess, which just doesn't work (following the rules of the draft, no nodes would ever get a LL address that way, as they'd all see the other nodes' attempts abandon their own, and move on, in step, to the next chocie). kre From owner-zeroconf@merit.edu Sun Mar 2 10:29:52 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12978 for ; Sun, 2 Mar 2003 10:29:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AF4A791249; Sun, 2 Mar 2003 10:31:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6191691261; Sun, 2 Mar 2003 10:31:36 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AC36091249 for ; Sun, 2 Mar 2003 10:31:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 583205E115; Sun, 2 Mar 2003 10:31:19 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id AF7E35E10F for ; Sun, 2 Mar 2003 10:31:16 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h22FW1aj017225; Sun, 2 Mar 2003 17:32:01 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h22FVwaY017220; Sun, 2 Mar 2003 17:31:59 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: WG Action 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: <1046619116.9862.42.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 02 Mar 2003 17:31:58 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-02-27 at 14:55, Erik Guttman wrote: > Action: Accept Since no-one else dares bite the bullet I have to ask: how does this decision follow the issue resolution process? The camps were about even as far as I could tell. I was expecting to see a compromise proposal on this. I'd like an answer from the WG chair to this. > Dissenting Views (summarized by the WG chair) > Mika Liljeberg: > His basic point is that this is not foolproof. There will > be problems of leakage of identifers, scope selection, > inability to communicate in some cases, etc. and that the > transition cases have not been fully worked out. My view is somewhat misrepresented here. My main concern is that LL23 introduces unnecessary implementation complexity in exchange of new problens and dubious benefits. I spent some considerable effort trying to elicit some proof that LL23 has an actual benefit that justifies the cost. I didn't see such proof. I also agree with the concerns outlined by Ted and Stuart. > Notes: > (1) It must be noted that LL23 is very close if not identical to the > behavior of hosts already supporting IPv4LL configuration today > (MacOS9, Windows98 and onward, etc). That is not a reason to mandate LL23. LL23 merely precludes other implementation choises, which I regard as favoritism in the specification. > We have operational > experience which shows that (a) it is useful, (b) it is not > horribly broken. Statement (a) is questionable. (b) I'm willing to conceed. However, I have a different implementation approach that is not horribly broken either. > (2) We have WG consensus that issues can arise when there are hosts > with more than one scope on the network. This multi-scoped > host will have issues with source address selection and may > forward protocol messages with locators, referrals, redirects > or addresses in-line off-link. The host which only supports > LL will also be effected if (a) it supports a service and > (b) its location is forwarded off link, where the service > cannot be reached. Implication: Mixed scopes *do* present > a problem. There probably is a common understanding that scoped addressing presents some problems. However, this is not an argument for or against LL23. I don't believe LL23 helps solve the problem to any significant degree and it has a cost that is not attractive. > (5) In response to Mika's concern: We realize there are potential > issues when hosts have multiple address scopes configured. This > state with known problems is *bounded* in that hosts will only > experience these problems during transition. This does not address my concerns at all. I spent some considerable time trying to elicit proof that there is a problem in our current implementation approach, now precluded by LL23, and received none. > (6) In response to Stuart's concern: Support for networking in > misconfigured networks is not a work item on the charter. Zero configuration is in the charter. Support of routable addresses is not. Yet the WG went there and created a solution, which prevents zero configuration in some cases. > It > is unfortunate that we cannot offer a solution to this problem, > but to do so would leave the can of worms open for an indefinite > period of time. This statement is completely unfounded. Proponents of LL23 failed to show any real problems with the existing specification. > (7) Accepting LL23 goes a long way toward answering IESG concerns. I truly hope so. At the moment that would be the only upside I can see. Well, enough on LL23 I guess. Let's move on. MikaL From owner-zeroconf@merit.edu Mon Mar 3 13:03:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05544 for ; Mon, 3 Mar 2003 13:03:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6F9DA91284; Mon, 3 Mar 2003 13:04:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 370BC91285; Mon, 3 Mar 2003 13:04:57 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1AEAA91284 for ; Mon, 3 Mar 2003 13:04:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id F195F5DD9C; Mon, 3 Mar 2003 13:04:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id 6D3CE5DD98 for ; Mon, 3 Mar 2003 13:04:30 -0500 (EST) Received: from SGOSWAMIPCL ([63.164.145.161]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id MAA18412; Mon, 3 Mar 2003 12:57:36 -0500 (EST) From: "Subrata Goswami" To: "'Robert Elz'" Cc: Subject: RE: LL24: Weaken the PRN requirement Date: Mon, 3 Mar 2003 09:50:08 -0800 Message-ID: <00df01c2e1ad$74839f10$1bc0140a@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <17143.1046610634@munnari.OZ.AU> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit No, deterministic algorithms can produce unique LLv4 addresses for each node. In a deterministic algorithm, every not does not need to produce the same output - only the algorithm is same, the input to the algorithm are different for each node. "..no nodes would ever get a LL address that way, as they'd all see the other nodes' attempts abandon " On this I would say, it is not relevant. See the first paragraph. ".. result in hundreds of nodes running .." Are LLv4 networks expected to be hundreds of nodes large ? Subrata > -----Original Message----- > From: Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: Sunday, March 02, 2003 5:11 AM > To: s. goswami > Cc: zeroconf@merit.edu > Subject: Re: LL24: Weaken the PRN requirement > > > Date: Sat, 1 Mar 2003 18:45:52 -0500 (EST) > From: "s. goswami" > Message-ID: > > > | There are many such algorithms, some are deterministic > | versus the probabilistic algorithm inherent in PRN. > > The problem is that any deterministic algorithm will, in some > environments, result in hundreds of nodes running the exact > same thing, at the same time, and producing the exact same answers. > > That produces a mess, which just doesn't work (following the > rules of the draft, no nodes would ever get a LL address that > way, as they'd all see the other nodes' attempts abandon > their own, and move on, in step, to the next chocie). > > kre > From owner-zeroconf@merit.edu Mon Mar 3 15:17:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11388 for ; Mon, 3 Mar 2003 15:17:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5644691213; Mon, 3 Mar 2003 15:18:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1FDF49124D; Mon, 3 Mar 2003 15:18:57 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D37A391213 for ; Mon, 3 Mar 2003 15:18:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id C27185DD96; Mon, 3 Mar 2003 15:18:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 2EAB35DD8C for ; Mon, 3 Mar 2003 15:18:55 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h23KCWJ10353; Mon, 3 Mar 2003 14:12:34 -0600 (CST) Date: Mon, 3 Mar 2003 14:16:12 -0600 Subject: Re: LL24: Weaken the PRN requirement Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'Robert Elz'" , To: "Subrata Goswami" From: Ted Lemon In-Reply-To: <00df01c2e1ad$74839f10$1bc0140a@SGOSWAMIPCL> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit A pseudo-random number generator is deterministic. If you use a seed that is unique to a particular device, that device will get the same address every time, unless some other device's seed is the same, in which case they will fight over it and the newcomer will lose. The problem we are arguing about here is not whether or not the algorithm is deterministic, but how likely a collision is, how likely a second collision is after a first collision, and whether the algorithm actually hits all 65534 possible addresses. There are PRNGs that have this quality, and there are PRNGs that do not. So, consider these two algorithms: algorithm 1 is a perfect 16-bit PRNG, seeded with the two least significant bytes of the MAC address of the device (we'll call this 2lsbmac). Algorithm 2 just takes 2lsbmac and uses it as the two least significant bytes of the first IP address it tries. If it gets a collision, it increments the address by one, and tries again. So if you have two nodes on the network that use algorithm 1, both of which get the same value for 2lsbmac, then the first one to connect will get the first IP address it tries for. The second to connect will get the next IP address in the sequence that algorithm 1 produces. Now if a third device connects to the network with the same value for 2lsbmac, it will try the IP address of the first station, then the IP address of the second station, and then it will try a third IP address which has not yet been taken, and acquire that. This is precisely the same behavior that we get with algorithm 2 - the only difference is that the addresses in algorithm 1 will look "random" to a casual observer. But in the case of three stations with three different values for 2lsbmac, both algorithms will produce random-seeming addresses. Now consider a third algorithm. This algorithm uses a perfect 32-bit PRNG seeded with 4lsbmac. The likelihood of a clash with 4lsbmac is much less than a clash with 2lsbmac - probably not 64k times less likely, but certainly significantly less likely. The algorithm simply takes the two least significant bytes of the output of the PRNG and uses those to generate an IP address. This algorithm has the same probability of producing an initial collision as the other two. However, the chances that the second try will also produce a collision are much lower, because there are 16 extra bits of data being fed into the PRNG. If you use a *bad* PRNG in your algorithm, your likelihood of collisions will be quite high even if it's a 32-bit algorithm - there are lots of bad PRNGs out there that don't produce a smooth distribution in their output, and indeed don't even hit most possible output values. A bad PRNG is probably worse than just adding one. So if this draft is going to specify an algorithm, it should probably specifically say what the algorithm is; otherwise we will probably wind up seeing a lot of implementations that do a really bad job of collision avoidance. I am not sure this will matter on the average network, but it might be a bummer for the poor bastard who just happens to wind up with set of nodes that happen to have seed values that interact badly. So if you choose the wrong PRNG-based algorithm, it's no better than just incrementing the IP address by one. However, if you use a good algorithm from the start, it _is_ better. From owner-zeroconf@merit.edu Tue Mar 4 00:25:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24783 for ; Tue, 4 Mar 2003 00:25:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0FC6B9124F; Tue, 4 Mar 2003 00:27:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB74491251; Tue, 4 Mar 2003 00:27:15 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D3C009124F for ; Tue, 4 Mar 2003 00:27:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id B13DA5DE2A; Tue, 4 Mar 2003 00:27:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 489CF5DDD2 for ; Tue, 4 Mar 2003 00:27:14 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.7/8.12.7) with ESMTP id h245RDnR020803 for ; Mon, 3 Mar 2003 21:27:13 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 3 Mar 2003 21:27:10 -0800 Received: from [17.219.194.178] (vpn-scv-x4-178.apple.com [17.219.194.178]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h245RDs17407 for ; Mon, 3 Mar 2003 21:27:13 -0800 (PST) Message-Id: <200303040527.h245RDs17407@scv1.apple.com> Subject: v4LL in the future tense? Date: Mon, 3 Mar 2003 21:27:11 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk On 21st February 2003, Keith Moore wrote: >the introduction of v4LL will break software that currently works. IPv4LL was "introduced" in 1998. Talking about something that happened five years ago in the future tense is misleading to say the least. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 00:25:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24810 for ; Tue, 4 Mar 2003 00:25:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C62E991251; Tue, 4 Mar 2003 00:27:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91BFA91255; Tue, 4 Mar 2003 00:27:35 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9A15291251 for ; Tue, 4 Mar 2003 00:27:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 66C635DE2C; Tue, 4 Mar 2003 00:27:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id E516C5DDD2 for ; Tue, 4 Mar 2003 00:27:33 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.7/8.12.7) with ESMTP id h245RXnR020836 for ; Mon, 3 Mar 2003 21:27:33 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 3 Mar 2003 21:27:30 -0800 Received: from [17.219.194.178] (vpn-scv-x4-178.apple.com [17.219.194.178]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h245RXf19221 for ; Mon, 3 Mar 2003 21:27:33 -0800 (PST) Message-Id: <200303040527.h245RXf19221@scv3.apple.com> Subject: RE: LL1, LL23 Date: Mon, 3 Mar 2003 21:27:31 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Christian Huitema wrote: >Consider now a host using an address passing application, such as >for example VoIP using SIP. The host has just one interface. When >the application wants to set up a VoIP call, it reads the IP >address of the interface, and document it in the SDP payload of a >SIP message; the peer will then send RTP packets to that address. >If the interface has several addresses, the host needs to pick >one; if the application is not LL aware and the interface has both >an LL address and a routable address, the application is likely to >pick at random. The SIP packet will often travel beyond the local >link; if the application placed the LL address in the RTP payload, >the VoIP call will fail. This failure will not happen if the host >did not configure an LL address. I think a lot of these concerns can be easily answered by simply implementing the APIs intelligently. If naive applications ask the OS for its address list and then simply use the first address in the list, then the OS should arrange to give the "best" address first to accomodate these naive applications. Also, this problem is not unique to LL. If a laptop computer has an Ethernet interface with address 157.54.12.81 and a wireless interface with address 10.0.0.2, then there is still the question of which address to put in the SIP packet. This is not a new problem. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 00:26: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 AAA24827 for ; Tue, 4 Mar 2003 00:26:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C154991255; Tue, 4 Mar 2003 00:28:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 971309125A; Tue, 4 Mar 2003 00:28:06 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A781391255 for ; Tue, 4 Mar 2003 00:28:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8C5E35DE2D; Tue, 4 Mar 2003 00:28:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 51C4B5DE2A for ; Tue, 4 Mar 2003 00:28:05 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.7/8.12.7) with ESMTP id h245S4nR020895 for ; Mon, 3 Mar 2003 21:28:05 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 3 Mar 2003 21:28:00 -0800 Received: from [17.219.194.178] (vpn-scv-x4-178.apple.com [17.219.194.178]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h245S2s17677 for ; Mon, 3 Mar 2003 21:28:02 -0800 (PST) Message-Id: <200303040528.h245S2s17677@scv1.apple.com> Subject: Re: LL1, LL23 Date: Mon, 3 Mar 2003 21:28:01 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Mika Liljeberg wrote: >Allowing the installed base based of a work-in-progress to sway >specification of said or other Internet drafts does not seem like a >smart thing to do. It seems likely that Apple will fix these problems >as a matter of course. But I don't know enough about their product, >so I won't say more than that. Perhaps Stuart can offer a view. Mika is right. When there are bugs, and the vendor is able and willing to fix those bugs, then modifying a specification to try to accomodate those bugs is rarely necessary or advisable. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 01:20: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 BAA25646 for ; Tue, 4 Mar 2003 01:20:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2ABE09125A; Tue, 4 Mar 2003 01:22:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E86BF9125C; Tue, 4 Mar 2003 01:22:17 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E28BC9125A for ; Tue, 4 Mar 2003 01:22:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id C482D5DE30; Tue, 4 Mar 2003 01:22:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 896EC5DE0C for ; Tue, 4 Mar 2003 01:22:16 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.7/8.12.7) with ESMTP id h246MGnR029296 for ; Mon, 3 Mar 2003 22:22:16 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 3 Mar 2003 22:22:13 -0800 Received: from [17.219.194.178] (vpn-scv-x4-178.apple.com [17.219.194.178]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h246MFs04441 for ; Mon, 3 Mar 2003 22:22:15 -0800 (PST) Message-Id: <200303040622.h246MFs04441@scv1.apple.com> Subject: Support: LL3 TTL=255 on send, check on receive? Date: Mon, 3 Mar 2003 22:22:14 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk In April 2001 Dave Thaler argued that there was some small but non-zero benefit in TTL=255. I was convinced by his arguments then, and I remain convinced. Summary: TTL=255: incentive for ISPs (etc.) to do the right thing easily detect offenders guard against attack from off-link attackers TTL=1: no incentive for ISPs/router vendors to do the right thing no way to easily detect offenders no protection against attack from off-link attackers >Subject: RE: IPv4 linklocal security >Date: 4 Apr 2001 7:18 pm >From: Dave Thaler, dthaler@Exchange.Microsoft.com >To: Stuart Cheshire, cheshire@apple.com >CC: zeroconf@merit.edu > >However, the discussion of TTL=1 vs TTL=255 basically repeats a >discussion that occurred in the MBoneD WG at IETF 38 (Memphis). >The meeting notes don't say much, but are at >http://www.ietf.org/proceedings/97apr/97apr-final/xrtftr65.htm > >The essence of the discussion is that Ross Finlayson gave a presentation >in which he asked what the best TTL was, for each multicast scope. He >suggested publishing a list of recommended TTLs for each scope. >Van Jacobson and I both argued that TTL=255 should always be used, so >the meeting minutes skip to the conclusion which was "The final >recommendation was to abolish the use of TTL as a boundary mechanism", >and as a result no list of TTLs per scope were published (and any >old lists on web pages were removed). > >One of the arguments that Van and I made was that using TTL=255 >provides two things: >1) an incentive for ISPs to do the right thing >by configuring routers to fix "holes" in scopes (in the zeroconf >context this translates to not forwarding 169.254/16), or even >better, an incentive for router vendors to do this automatically, and >2) (less importantly) a way to easily detect offenders. > >In contrast TTL=1 provides no incentive for ISPs/router vendors to >do the right thing. > >Whether this argument is strong enough to use TTL=255 in the >Zeroconf scenarios is up to this WG to decide, but it was >good enough for the MBoneD WG in 1997. > >The two rules at the top of this email are orthogonal to the >TTL decision. Even with the two rules on address checking, >I'd still prefer TTL=255. > >-Dave From owner-zeroconf@merit.edu Tue Mar 4 01:22:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25729 for ; Tue, 4 Mar 2003 01:22:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3A74A9125C; Tue, 4 Mar 2003 01:24:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 060CF91268; Tue, 4 Mar 2003 01:24:38 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1677A9125C for ; Tue, 4 Mar 2003 01:24:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id F39B05DE30; Tue, 4 Mar 2003 01:24:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id BA6E25DE2F for ; Tue, 4 Mar 2003 01:24:37 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.7/8.12.7) with ESMTP id h246ObnR029635 for ; Mon, 3 Mar 2003 22:24:37 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 3 Mar 2003 22:24:36 -0800 Received: from [17.219.194.178] (vpn-scv-x4-178.apple.com [17.219.194.178]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h246Oaf04626 for ; Mon, 3 Mar 2003 22:24:36 -0800 (PST) Message-Id: <200303040624.h246Oaf04626@scv3.apple.com> Subject: Support (I think): LL7 How do existing hosts respond to broadcast requests? Date: Mon, 3 Mar 2003 22:24:35 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Steve Bellovin wrote: >How do current hosts behave with respect to this: > >All ARP packets (*replies* as well as requests) that contain a >link-local 'sender IP address' MUST be sent using link-level >broadcast instead of link-level unicast. This aids timely >detection of duplicate addresses. An example illustrating how this >helps is given in Section 4. > >(I understand the necessity, but is it done? I suspect not. This >suggests that there be a warning that link-local addresses SHOULD NOT >be manually configured.) 1. It is not *necessary*, but it is useful. 2. Yes, it is done. 3. Yes, it works with today's hosts (and is entirely compatible with the rules specified in RFC 826). >Requested Change: >No change. I support "No change". Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 01:23:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25769 for ; Tue, 4 Mar 2003 01:23:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2D49F91268; Tue, 4 Mar 2003 01:25:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB0D691275; Tue, 4 Mar 2003 01:25:35 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 094CC91268 for ; Tue, 4 Mar 2003 01:25:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF7245DE30; Tue, 4 Mar 2003 01:25:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id A6F705DE2F for ; Tue, 4 Mar 2003 01:25:34 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.7/8.12.7) with ESMTP id h246PYnR029854 for ; Mon, 3 Mar 2003 22:25:34 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 3 Mar 2003 22:25:33 -0800 Received: from [17.219.194.178] (vpn-scv-x4-178.apple.com [17.219.194.178]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h246PXQ14978 for ; Mon, 3 Mar 2003 22:25:33 -0800 (PST) Message-Id: <200303040625.h246PXQ14978@scv2.apple.com> Subject: Support: LL9 Introduction to make it clear this is not a replacement for DHCP Date: Mon, 3 Mar 2003 22:25:31 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Requested Change: > >Link-local communication using link-local addresses is only suitable >for communication with other devices connected to the same physical (or >logical) link. Link-local communication using link-local addresses is >not suitable for communication with devices not directly connected to >the same physical (or logical) link. I think it should be clear to most readers what "link-local" means, but if other people really want more additional text in the document, I am not strongly opposed to this text. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 01:24: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 BAA25820 for ; Tue, 4 Mar 2003 01:24:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B120D91275; Tue, 4 Mar 2003 01:26:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CB909128A; Tue, 4 Mar 2003 01:26:13 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 933A091275 for ; Tue, 4 Mar 2003 01:26:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 840EF5DE30; Tue, 4 Mar 2003 01:26:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 4BBD45DE2F for ; Tue, 4 Mar 2003 01:26:12 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.7/8.12.7) with ESMTP id h246QBnR000010 for ; Mon, 3 Mar 2003 22:26:11 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 3 Mar 2003 22:26:08 -0800 Received: from [17.219.194.178] (vpn-scv-x4-178.apple.com [17.219.194.178]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h246QBf05290 for ; Mon, 3 Mar 2003 22:26:11 -0800 (PST) Message-Id: <200303040626.h246QBf05290@scv3.apple.com> Subject: Support: LL13 If the destination is a global multicast address a host SHOULD use a global source address Date: Mon, 3 Mar 2003 22:26:09 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >If the destination address is the 255.255.255.255 broadcast address >or a link-local multicast address, then the host may use either its >link-local source address or a routable address, as appropriate. If >the destination address is a multicast address with scope larger than >link-local then the host SHOULD use an appropriate routable source >address, if available, or its link-local source address otherwise. I support this text as currently proposed. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 01:25: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 BAA25855 for ; Tue, 4 Mar 2003 01:25:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 435D39128A; Tue, 4 Mar 2003 01:27:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16F939128E; Tue, 4 Mar 2003 01:27:16 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 298FE9128A for ; Tue, 4 Mar 2003 01:27:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1893B5DE0C; Tue, 4 Mar 2003 01:27:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 8732D5DE2F for ; Tue, 4 Mar 2003 01:27:14 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.7/8.12.7) with ESMTP id h246REnR000192 for ; Mon, 3 Mar 2003 22:27:14 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 3 Mar 2003 22:27:11 -0800 Received: from [17.219.194.178] (vpn-scv-x4-178.apple.com [17.219.194.178]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h246RDs06533 for ; Mon, 3 Mar 2003 22:27:13 -0800 (PST) Message-Id: <200303040627.h246RDs06533@scv1.apple.com> Subject: Oppose: LL21 Alternate text for: TTL=255 on send, check on receive? Date: Mon, 3 Mar 2003 22:27:12 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk In April 2001 Dave Thaler argued that there was some small but non-zero benefit in TTL=255. (See LL3.) I was convinced by his arguments then, and I remain convinced. Therefore I support LL3 and oppose LL21. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 01:26: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 BAA25887 for ; Tue, 4 Mar 2003 01:26:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3AC7A9128E; Tue, 4 Mar 2003 01:28:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 127389128F; Tue, 4 Mar 2003 01:28:23 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 270FB9128E for ; Tue, 4 Mar 2003 01:28:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 122C45DE2F; Tue, 4 Mar 2003 01:28:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 990D05DE0C for ; Tue, 4 Mar 2003 01:28:21 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.7/8.12.7) with ESMTP id h246SLYv018340 for ; Mon, 3 Mar 2003 22:28:21 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 3 Mar 2003 22:28:18 -0800 Received: from [17.219.194.178] (vpn-scv-x4-178.apple.com [17.219.194.178]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h246SKs06955 for ; Mon, 3 Mar 2003 22:28:20 -0800 (PST) Message-Id: <200303040628.h246SKs06955@scv1.apple.com> Subject: Oppose: LL24 Weaken the PRN generated address requirement from MUST to MAY Date: Mon, 3 Mar 2003 22:28:19 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk I see no compelling arguments to support LL24. The term "pseudo-random number generator" is already sufficiently vague as to allow implementers significant leeway in what algorithm they choose. The important point, as explained by others, is that different hosts MUST NOT get stuck in lock-step suffering an unending series of conflicts. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 01:27:48 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25920 for ; Tue, 4 Mar 2003 01:27:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1EDB09128F; Tue, 4 Mar 2003 01:29:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E694691290; Tue, 4 Mar 2003 01:29:42 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 030619128F for ; Tue, 4 Mar 2003 01:29:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id E74E45DE30; Tue, 4 Mar 2003 01:29:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id AD7345DE0C for ; Tue, 4 Mar 2003 01:29:41 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.7/8.12.7) with ESMTP id h246TfnR000518 for ; Mon, 3 Mar 2003 22:29:41 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 3 Mar 2003 22:29:38 -0800 Received: from [17.219.194.178] (vpn-scv-x4-178.apple.com [17.219.194.178]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h246Tes07384 for ; Mon, 3 Mar 2003 22:29:40 -0800 (PST) Message-Id: <200303040629.h246Tes07384@scv1.apple.com> Subject: Oppose: LL25 Delete inappropriate "send" requirement on LL nodes Date: Mon, 3 Mar 2003 22:29:39 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk I see no compelling arguments to support LL25. >The nodes on a link should not have the responsibility of determining >whether the router can forward a packet or not. It has been made abundantly clear that when a host sends a packet to a next-hop IP address that is not the same as the packet's destination IP address, the host is sending the packet with the intention that it be forwarded. A host MUST NOT do this with any packet with a link-local source or destination address. This is very clear, and I see no reason to change it. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 01:32:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26071 for ; Tue, 4 Mar 2003 01:32:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DAE7791290; Tue, 4 Mar 2003 01:34:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A464391291; Tue, 4 Mar 2003 01:34:02 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B473091290 for ; Tue, 4 Mar 2003 01:32:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9C7035DE0C; Tue, 4 Mar 2003 01:32:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 31ED35DDD2 for ; Tue, 4 Mar 2003 01:32:14 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.7/8.12.7) with ESMTP id h246WDYv019370 for ; Mon, 3 Mar 2003 22:32:13 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 3 Mar 2003 22:32:07 -0800 Received: from [17.219.194.178] (vpn-scv-x4-178.apple.com [17.219.194.178]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h246W9s08696 for ; Mon, 3 Mar 2003 22:32:09 -0800 (PST) Message-Id: <200303040632.h246W9s08696@scv1.apple.com> Subject: Oppose: LL29 Link-local sources should specify TTL=1 Date: Mon, 3 Mar 2003 22:32:08 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk John Schnizlein wrote: >Specifying that hosts must not send LL traffic to routers, which >appears to be the basis of the assumption that LL traffic does >not go to routers, makes them responsible for something they >do not actually control. Since proxy-ARP gives the host a reply >that appears to be that of the ultimate host, but is a router, >the originating host cannot enforce the requirement. Sorry John, but this is a HUGE red herring. Any router doing indiscriminate proxy-ARP for addresses of which it has no knowledge or authority is going to completely sabotage IPv4LL anyway. For a start, the IPv4LL hosts will be unable to obtain any address because every ARP probe will be answered by the proxy-ARP router, giving the impression that every address is in use. Even supposing that a host does manage to acquire an IPv4LL address, it will be unable to communicate reliably, because every time a peer host sends an ARP request, the indiscriminate proxy-ARP router will answer, thereby stealing the packets away so that they do not go to the right host. If we were having this conversation five years ago, it might have been argued that we could not risk shipping IPv4LL at all, because of the potentially disastrous network meltdown it could cause. (This reminds me of the NASA scientist who claimed -- rightly -- that there was a risk that the Apollo 11 fuel *might* react with the moon rocks, thereby "setting the moon on fire". See .) As luck would have it, we didn't have this conversation five years ago, we did ship IPv4LL, and the moon actually did not catch fire and explode. Even if there were a scenario where IPv4LL hosts are tricked into sending their packets to a device that forwards them, it is unlikely to be a large volume of traffic -- typically just a few unanswered TCP SYNs. Note that since day one, Windows and Mac OS have sent packets with TTLs of 128 and 255 respectively. If this leakage is already happening, are there any reliable figures reporting the scale of the problem? I suspect the volume of IPv4LL leakage is vanishingly insignificant compared to the other "elephants in the room" -- like PTR lookups for Net 10 addresses. Even if there were a real problem, when we have five years of deployed hosts already using TTLs of 128 and 255, trying to change the TTL to 1 for new hosts seems like slamming the door long after the horse has bolted. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 02:35: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 CAA08369 for ; Tue, 4 Mar 2003 02:35:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3F37991291; Tue, 4 Mar 2003 02:37:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 12E2591292; Tue, 4 Mar 2003 02:37:30 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 02E2691291 for ; Tue, 4 Mar 2003 02:37:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id DBCA55DE3E; Tue, 4 Mar 2003 02:37:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 1AECD5DE35 for ; Tue, 4 Mar 2003 02:37:27 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h247bAO02525; Tue, 4 Mar 2003 14:37:17 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h247aeO02858; Tue, 4 Mar 2003 14:36:40 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Support: LL3 TTL=255 on send, check on receive? (also LL21) In-Reply-To: <200303040622.h246MFs04441@scv1.apple.com> References: <200303040622.h246MFs04441@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Mar 2003 14:36:40 +0700 Message-ID: <2856.1046763400@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 3 Mar 2003 22:22:14 -0800 From: Stuart Cheshire Message-ID: <200303040622.h246MFs04441@scv1.apple.com> | In April 2001 Dave Thaler argued that there was some small but non-zero | benefit in TTL=255. | | I was convinced by his arguments then, and I remain convinced. | | Summary: | | TTL=255: incentive for ISPs (etc.) to do the right thing That argument works for multicast (from whence it originated) but is pretty meaningless here. | easily detect offenders I fail to see any difference this makes (before the detection point, the TTL will have been decreased by some arbitrary amount, so the value of the TTL can't be used - there's no difference at all whether a node sent with TTL 255 or 254 or 253 or ...) Simply seeing packets with a LL address in them outside their "home" is enough to note that something is broken, finding the source of the bad packets (when it is the source addr that is LL, which is far and away the most likely case for packets to escape) is not going to be easy in any case (may require the efforts of the itrace people). | guard against attack from off-link attackers This is meaningless without knowing what is to be guarded, or how the TTL helps. What it actually does is allow the node to know that a source is not on the same link - but only if it checks the TTL. None of the proposals (none of LL3, LL21 LL29 or the current words in the draft) suggest that nodes should check the TTL - the strongest is the current draft wording which says that nodes MAY check (LL3 even waters down that one...) If there is some application protocol that can gain from a TTL check (the way ND and stuff use the similar thing in IPv6) then that protocol can specify the TTL that must be used for that application protocol when using LL addresses. But that only works if this doc doesn't specify something which might cause a conflict. Some protocol might want to specify that a TTL of 255 must be used, whereas another protocol (perhaps one using multicast) might want to specify that a TTL of 1 be used. With the specs as you'd have them, how is SLP using LL addresses to be done? As I recall it, SLP likes hosts to use TTL=1 for their first search (especially looking for a DA). On a LL link it really should make no difference - but we'd have colliding specs, and no way to comply with more than one of them. Just leave out the TTL part of this spec, it adds nothing, except complexity. kre From owner-zeroconf@merit.edu Tue Mar 4 02:38:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08403 for ; Tue, 4 Mar 2003 02:38:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4689591292; Tue, 4 Mar 2003 02:40:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1005591293; Tue, 4 Mar 2003 02:40:20 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1457391292 for ; Tue, 4 Mar 2003 02:40:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id F28F35DE45; Tue, 4 Mar 2003 02:40:19 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 5451D5DE35 for ; Tue, 4 Mar 2003 02:40:14 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h247eAO04847; Tue, 4 Mar 2003 14:40:11 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h247dcO02869; Tue, 4 Mar 2003 14:39:38 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 In-Reply-To: <200303040632.h246W9s08696@scv1.apple.com> References: <200303040632.h246W9s08696@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Mar 2003 14:39:38 +0700 Message-ID: <2867.1046763578@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 3 Mar 2003 22:32:08 -0800 From: Stuart Cheshire Message-ID: <200303040632.h246W9s08696@scv1.apple.com> | Even if there were a real problem, when we have five years of deployed | hosts already using TTLs of 128 and 255, trying to change the TTL to 1 | for new hosts seems like slamming the door long after the horse has | bolted. One can, of course, make the same statement about trying to force the TTL to always be 255. There is evidence out there (apparently) that everything works OK using 128 (no great demonstrations of problems being avoided by the hosts that use 255). I can't think of a reason that 64, or 32, or 16, or 192 would be any different (as a general default for the host for apps or protocols that don't specify otherwise). Just allow the implementations to use whatever they like. kre From owner-zeroconf@merit.edu Tue Mar 4 03:26:00 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08912 for ; Tue, 4 Mar 2003 03:25:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4053191296; Tue, 4 Mar 2003 03:27:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 07B9691297; Tue, 4 Mar 2003 03:27:52 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D7A3791296 for ; Tue, 4 Mar 2003 03:27:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id B613C5DE51; Tue, 4 Mar 2003 03:27:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from aditya.pune.gsslco.co.in (unknown [203.129.226.254]) by segue.merit.edu (Postfix) with ESMTP id 461935DE43 for ; Tue, 4 Mar 2003 03:27:49 -0500 (EST) Received: from mailscan.pune.gsslco.co.in (mailscan.pune.gsslco.co.in [203.129.226.242]) by aditya.pune.gsslco.co.in (8.9.3/8.9.3) with SMTP id OAA07122 for ; Tue, 4 Mar 2003 14:00:36 +0530 (IST) Received: FROM gauri BY mailscan.pune.gsslco.co.in ; Tue Mar 04 13:54:59 2003 +0500 Message-ID: <002801c2e228$c081b390$7301010a@bombay.gsslco.co.in> From: "Partha, K V B" To: References: <200303040632.h246W9s08696@scv1.apple.com> <2867.1046763578@munnari.OZ.AU> Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Date: Tue, 4 Mar 2003 14:03:36 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Link local source sending to a link local destination SHOULD specify TTL=1; otherwise, leave it to implementations to specify their own TTLs. - Was this option considered? Any drawbacks in this approach? ----- Original Message ----- From: "Robert Elz" To: "Stuart Cheshire" Cc: Sent: Tuesday, March 04, 2003 1:09 PM Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 > Date: Mon, 3 Mar 2003 22:32:08 -0800 > From: Stuart Cheshire > Message-ID: <200303040632.h246W9s08696@scv1.apple.com> > > | Even if there were a real problem, when we have five years of deployed > | hosts already using TTLs of 128 and 255, trying to change the TTL to 1 > | for new hosts seems like slamming the door long after the horse has > | bolted. > > One can, of course, make the same statement about trying to force the > TTL to always be 255. There is evidence out there (apparently) that > everything works OK using 128 (no great demonstrations of problems being > avoided by the hosts that use 255). I can't think of a reason that > 64, or 32, or 16, or 192 would be any different (as a general default for > the host for apps or protocols that don't specify otherwise). > > Just allow the implementations to use whatever they like. > > kre > From owner-zeroconf@merit.edu Tue Mar 4 04:16: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 EAA09901 for ; Tue, 4 Mar 2003 04:16:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 165C7912F8; Tue, 4 Mar 2003 04:18:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CDAD7912FC; Tue, 4 Mar 2003 04:18:28 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 582E1912D8 for ; Tue, 4 Mar 2003 04:18:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0A9875DE5A; Tue, 4 Mar 2003 04:18:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 1DA8C5DE22 for ; Tue, 4 Mar 2003 04:18:23 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h249IGO14989; Tue, 4 Mar 2003 16:18:16 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h249HsO03408; Tue, 4 Mar 2003 16:18:04 +0700 (ICT) From: Robert Elz To: "Partha, K V B" Cc: zeroconf@merit.edu Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 In-Reply-To: <002801c2e228$c081b390$7301010a@bombay.gsslco.co.in> References: <002801c2e228$c081b390$7301010a@bombay.gsslco.co.in> <200303040632.h246W9s08696@scv1.apple.com> <2867.1046763578@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Mar 2003 16:17:54 +0700 Message-ID: <3406.1046769474@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 4 Mar 2003 14:03:36 +0530 From: "Partha, K V B" Message-ID: <002801c2e228$c081b390$7301010a@bombay.gsslco.co.in> | Link local source sending to a link local destination SHOULD specify TTL=1; | otherwise, leave it to implementations to specify their own TTLs. - Was this | option considered? Any drawbacks in this approach? That option is issue LL21. And no, no drawbacks (just two different sets of imagined pseudo-benefits ignored). kre From owner-zeroconf@merit.edu Tue Mar 4 04:55: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 EAA10807 for ; Tue, 4 Mar 2003 04:55:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D088791299; Tue, 4 Mar 2003 04:57:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A41489129A; Tue, 4 Mar 2003 04:57:08 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A05D491299 for ; Tue, 4 Mar 2003 04:57:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 89F415DE4E; Tue, 4 Mar 2003 04:57:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id 39F8D5DD8C for ; Tue, 4 Mar 2003 04:57:07 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29680; Tue, 4 Mar 2003 02:57:05 -0700 (MST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h249v3l19876; Tue, 4 Mar 2003 10:57:04 +0100 (MET) Date: Tue, 4 Mar 2003 10:57:00 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: Robert Elz Cc: "Partha, K V B" , zeroconf@merit.edu Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 In-Reply-To: <3406.1046769474@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Tue, 4 Mar 2003, Robert Elz wrote: > Date: Tue, 04 Mar 2003 16:17:54 +0700 > From: Robert Elz > To: "Partha, K V B" > Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 > > Date: Tue, 4 Mar 2003 14:03:36 +0530 > From: "Partha, K V B" > Message-ID: <002801c2e228$c081b390$7301010a@bombay.gsslco.co.in> > > | Link local source sending to a link local destination SHOULD specify TTL=1; > | otherwise, leave it to implementations to specify their own TTLs. - Was this > | option considered? Any drawbacks in this approach? > > That option is issue LL21. And no, no drawbacks (just two different sets > of imagined pseudo-benefits ignored). Robert, That is a misleading statement. Here is my summary of the options available at the moment. TTL on SEND TTL on RECEIVE LL3 MUST be 255 in the future, SHOULD discard if !255 LL21 Silent on TTL Silent on TTL processing setting LL21 + MAY be 1 (unicast) Silent on TTL processing Robert* MUST be 1 (multicast) otherwise, as per app. setting. LL29 MUST be 1 Silent on TTL processing LL29 + SHOULD be 1 unless an Silent on TTL processing Christian app sets the TTL ** Includes broadcast and multicast packets. * = Date: Fri, 28 Feb 2003 17:49:09 +0700 Message-Id: <3455.1046429349@munnari.OZ.AU> ** = Date: Thu, 27 Feb 2003 12:00:50 -0800 Message-Id: Partha, If you wish to suggest an alternative, please read the problem statement at www.spybeam.org/ll3.html and subsequent discussion. If you believe that an additional alternative is useful, please state exactly what problems it solves that the others (given above) do not solve and post this to the list. Regards, Erik From owner-zeroconf@merit.edu Tue Mar 4 05:38: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 FAA11612 for ; Tue, 4 Mar 2003 05:38:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E667C9129A; Tue, 4 Mar 2003 05:40:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B1DE09129C; Tue, 4 Mar 2003 05:40:21 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B26F29129A for ; Tue, 4 Mar 2003 05:40:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B4FB5DDFE; Tue, 4 Mar 2003 05:40:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 00BAE5DD8C for ; Tue, 4 Mar 2003 05:40:18 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h24AeEO06445; Tue, 4 Mar 2003 17:40:15 +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 h24Ae6O03931; Tue, 4 Mar 2003 17:40:09 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 04 Mar 2003 17:40:06 +0700 Message-ID: <3929.1046774406@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 4 Mar 2003 10:57:00 +0100 (CET) From: Erik Guttman Message-ID: | That is a misleading statement. Here is my summary of the options | available at the moment. Oh yes, sorry, I misread the suggestion (treating it as two different ones, split at the "otherwise" - because I didn't look at what came before that closely enough). | LL21 + MAY be 1 (unicast) Silent on TTL processing | Robert* MUST be 1 (multicast) | otherwise, as per app. | setting. For what it is worth, even though I suggested that as a possibility, I don't support adding it to this doc, LL21 as it exists on the web page is what I'd prefer (ie: no occurrence of TTL at all in the doc, with the possible exception of mention of current implementations that actually check that TTL==255 on receive). Just saying "MAY be 1" or "MAY be 255" or "MAY be any other value" is meaningless, and doesn't help at all. The MAY magic word is often overused, its only real value is to point out a plausible reasonable exception to a SHOULD or conditional MUST (as in, "vehicles SHOULD be red, but MAY be black if intended as hearses"). kre From owner-zeroconf@merit.edu Tue Mar 4 08:06: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 IAA17966 for ; Tue, 4 Mar 2003 08:06:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6F8ED91249; Tue, 4 Mar 2003 08:08:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3726A91250; Tue, 4 Mar 2003 08:08:49 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0895291249 for ; Tue, 4 Mar 2003 08:08:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id D542B5DE79; Tue, 4 Mar 2003 08:08:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1A3EC5DE70 for ; Tue, 4 Mar 2003 08:08:47 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h24BsWn29461 for ; Tue, 4 Mar 2003 03:54:32 -0800 Date: Tue, 4 Mar 2003 03:54:32 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: The IPv4ll draft updates RFC2131 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Here's what RFC 2131 says (Section 3.1): "If the client receives neither a DHCPACK or a DHCPNAK message after employing the retransmission algorithm, the client MAY choose to use the previously allocated network address and configuration parameters for the remainder of the unexpired lease." Note that the behavior is a MAY, not a SHOULD. Nevertheless, I do think that there is a valid point here -- particularly relating to mobile computing such as hosts that implement IEEE 802.11 or a Mobile IP Mobile Node (MN). On detecting movement at L2, a MN will typically attempt to determine whether it has moved subnets by seeing if it can obtain a Care of Address (CoA). It is possible that the MN did not change subnets (e.g. WLAN roaming), and in that case you want the MN to retain its DHCPv4 address and to do so as quickly as possible. Here is what Section 3.7 of RFC 2131 says: " A client SHOULD use DHCP to reacquire or verify its IP address and network parameters whenever the local network parameters may have changed; e.g., at system boot time or after a disconnection from the local network, as the local network configuration may change without the client's or user's knowledge." The recommended verification should probably occur on *reconnection*, not after a *disconnection*, but the principle is a valid one. After all, a host that is disconnected from the network probably won't be able to obtain a new IP address until it reconnects, and if taken literally, the advice above would result in a failure to obtain an address and possible use of LLv4, inappropriately in my opinion. RFC 2131 continues: " If a client has knowledge of a previous network address and is unable to contact a local DHCP server, the client may continue to use the previous network address until the lease for that address expires. If the lease expires before the client can contact a DHCP server, the client must immediately discontinue use of the previous network address and may inform local users of the problem." So if the lease is still valid then the host MAY continue to use it, absent any reason to change it. If instead the MN were to obtain an LLv4 address (and not continue to configure the DHCPv4 assigned address), then if there is a glitch at L2 (e.g. delay in putting IEEE 802.11 keys in place, for example) then the DHCPv4 address could be (incorrectly) be disabled and a considerable delay (5 minutes by default) will occur between DHCPv4 attempts. This leaves the MN without connectivity for a considerable period when it could have continued to use the existing IPv4 address. That seems wrong to me. Part of the problem may come in defining what "reconnect" means (such as having a fully functional link layer, not just a "link up") but another part of the issue may be that DHCPv4 retransmission time is not actually very long (60 seconds). However, in practice we do see this problem occur quite often with current implementations (in fact, I'd guess that the majority of LLv4 usage occurs due to this problem). Note that there are reasons for a DHCPv4 server not to respond to a DHCPREQUEST even if it is available. For example, RFC 2131, Section 4.3.2 states: " If the network is correct, then the DHCP server should check if the client's notion of its IP address is correct. If not, then the server SHOULD send a DHCPNAK message to the client. If the DHCP server has no record of this client, then it MUST remain silent, and MAY output a warning to the network administrator. This behavior is necessary for peaceful coexistence of non- communicating DHCP servers on the same wire." So if you have two DHCPv4 servers on the same network (for resiliency), and they do not communicate, then if one goes down the other will not respond for it. The last thing you would want in that circumstance would be for hosts to stop using their DHCPv4 address, since that would take away the resiliency that you're attempting to achieve in that configuration. One way out of this might be to continue to use the DHCPv4 address for existing connections, but initiate new connections from LLv4. This is similar to what we talked about doing for the case where a host obtains a DHCPv4 address after initially using LLv4. On the other hand, I think that it doesn't *always* make sense to keep the DHCPv4 address. There are situations in which *really long* lease times can be assigned. For example, at home my DHCP server assigns leases of several days. If I want to set up an adhoc 802.11 network, then I don't want to wait until lease expiration to get going :) In practice there may be reasons for a host to believe that it has moved networks, and that the DHCPv4 assigned address is no longer valid. For example, the host can attempt to ping the router from the DHCPv4 assigned address and fail. Or an 802.11 card can be switched from infrastructure mode to adhoc. Or RS traffic might be heard indicating a change of network. These might be reasons to configure an LLv4 address after a DHCPREQUEST is not answered. In practice, most of the places in which I've used LLv4 successfully (as opposed to all the times where LLv4 addresses were assigned when they shouldn't have been, which is most of the time) fall into the "prior knowledge" category. So in practice, I think we may be able to come up with a workable solution. From owner-zeroconf@merit.edu Tue Mar 4 08:47:25 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20863 for ; Tue, 4 Mar 2003 08:47:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 21BC891251; Tue, 4 Mar 2003 08:49:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB45391252; Tue, 4 Mar 2003 08:49:10 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8086291251 for ; Tue, 4 Mar 2003 08:48:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6192C5DE7E; Tue, 4 Mar 2003 08:48:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 3E0435DE64 for ; Tue, 4 Mar 2003 08:48:01 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h24Dmcaj002329; Tue, 4 Mar 2003 15:48:39 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h24DmZWQ002319; Tue, 4 Mar 2003 15:48:35 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: The IPv4ll draft updates RFC2131 From: Mika Liljeberg To: Bernard Aboba Cc: zeroconf@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046785713.1902.8.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 04 Mar 2003 15:48:34 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Presumably we should be talking about routes here. Configuring and unconfiguring addresses is a side issue. We should probably have something like the following: 169.254/16 --> local link [always on designated LL interface] a.b.c.d/x --> local link [from DHCP] 0.0.0.0/0 --> default GW [from DHCP] 0.0.0.0/0 --> local link [always on designated LL interface] The above routes should be matched in the order they are written. When the default GW is determined to be unreachable, the node would fall back on the on-link default route. MikaL On Tue, 2003-03-04 at 13:54, Bernard Aboba wrote: > Here's what RFC 2131 says (Section 3.1): > > "If the client > receives neither a DHCPACK or a DHCPNAK message after employing > the retransmission algorithm, the client MAY choose to use the > previously allocated network address and configuration parameters > for the remainder of the unexpired lease." > > Note that the behavior is a MAY, not a SHOULD. > > Nevertheless, I do think that there is a valid point here -- particularly > relating to mobile computing such as hosts that implement IEEE 802.11 or > a Mobile IP Mobile Node (MN). > > On detecting movement at L2, a MN will typically attempt to determine > whether it has moved subnets by seeing if it can obtain a Care of Address > (CoA). It is possible that the MN did not change subnets (e.g. WLAN > roaming), and in that case you want the MN to retain its DHCPv4 address > and to do so as quickly as possible. Here is what Section 3.7 of RFC 2131 > says: > > " A client SHOULD use DHCP to reacquire or verify its IP address and > network parameters whenever the local network parameters may have > changed; e.g., at system boot time or after a disconnection from the > local network, as the local network configuration may change without > the client's or user's knowledge." > > The recommended verification should probably occur on *reconnection*, > not after a *disconnection*, but the principle is a valid one. After all, > a host that is disconnected from the network probably won't be able to > obtain a new IP address until it reconnects, and if taken literally, the > advice above would result in a failure to obtain an address and possible > use of LLv4, inappropriately in my opinion. > > RFC 2131 continues: > > " If a client has knowledge of a previous network address and is unable > to contact a local DHCP server, the client may continue to use the > previous network address until the lease for that address expires. > If the lease expires before the client can contact a DHCP server, the > client must immediately discontinue use of the previous network > address and may inform local users of the problem." > > So if the lease is still valid then the host MAY continue to use it, > absent any reason to change it. If instead the MN were to obtain an LLv4 > address (and not continue to configure the DHCPv4 assigned address), then > if there is a glitch at L2 (e.g. delay in putting IEEE 802.11 keys in > place, for example) then the DHCPv4 address could be (incorrectly) > be disabled and a considerable delay (5 minutes by default) will > occur between DHCPv4 attempts. This leaves the MN without connectivity for > a considerable period when it could have continued to use the existing > IPv4 address. That seems wrong to me. Part of the problem may come in > defining what "reconnect" means (such as having a fully functional link > layer, not just a "link up") but another part of the issue may be that > DHCPv4 retransmission time is not actually very long (60 seconds). > However, in practice we do see this problem occur quite often with current > implementations (in fact, I'd guess that the majority of LLv4 usage occurs > due to this problem). > > Note that there are reasons for a DHCPv4 server not to respond to a > DHCPREQUEST even if it is available. For example, RFC 2131, Section 4.3.2 > states: > > " If the network is correct, then the DHCP server should check if > the client's notion of its IP address is correct. If not, then the > server SHOULD send a DHCPNAK message to the client. If the DHCP > server has no record of this client, then it MUST remain silent, > and MAY output a warning to the network administrator. This > behavior is necessary for peaceful coexistence of non- > communicating DHCP servers on the same wire." > > So if you have two DHCPv4 servers on the same network (for resiliency), > and they do not communicate, then if one goes down the other will not > respond for it. The last thing you would want in that circumstance would > be for hosts to stop using their DHCPv4 address, since that would take > away the resiliency that you're attempting to achieve in that > configuration. > > One way out of this might be to continue to use the DHCPv4 address for > existing connections, but initiate new connections from LLv4. This is > similar to what we talked about doing for the case where a host obtains a > DHCPv4 address after initially using LLv4. > > On the other hand, I think that it doesn't *always* make sense to keep the > DHCPv4 address. There are situations in which *really long* lease times > can be assigned. For example, at home my DHCP server assigns leases of > several days. If I want to set up an adhoc 802.11 network, then I > don't want to wait until lease expiration to get going :) > > In practice there may be reasons for a host to believe that it > has moved networks, and that the DHCPv4 assigned address is no longer > valid. For example, the host can attempt to ping the router from the > DHCPv4 assigned address and fail. Or an 802.11 card can be switched from > infrastructure mode to adhoc. Or RS traffic might be heard indicating > a change of network. These might be reasons to configure an LLv4 > address after a DHCPREQUEST is not answered. > > In practice, most of the places in which I've used LLv4 successfully (as > opposed to all the times where LLv4 addresses were assigned when they > shouldn't have been, which is most of the time) fall into the "prior > knowledge" category. So in practice, I think we may be able to come up > with a workable solution. > From owner-zeroconf@merit.edu Tue Mar 4 11:33:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29526 for ; Tue, 4 Mar 2003 11:33:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6E5FE91228; Tue, 4 Mar 2003 11:35:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A6369122A; Tue, 4 Mar 2003 11:35:08 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2BEFD91228 for ; Tue, 4 Mar 2003 11:35:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 08E3A5DEB0; Tue, 4 Mar 2003 11:35:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by segue.merit.edu (Postfix) with ESMTP id D8A1C5DEAD for ; Tue, 4 Mar 2003 11:35:06 -0500 (EST) Received: from user-vcaulg9.dsl.mindspring.com ([216.175.86.9] helo=SGOSWAMIPCL) by heron.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 18qFNg-0005Of-00; Tue, 04 Mar 2003 08:35:04 -0800 From: "Subrata Goswami" To: "'Ted Lemon'" Cc: Subject: RE: LL24: Weaken the PRN requirement Date: Tue, 4 Mar 2003 08:27:42 -0800 Message-ID: <003b01c2e26b$124401a0$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal X-ELNK-Trace: 33bae71ce1aa67f5d780f4a490ca69564776905774d2ac4be79749a8510974aa760c77f1e48871a0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ted, that certainly is a good analysis of the issue. The draft SHOULD certainly suggest a good PRNG algorithm, at the same time it should be flexible enough to include future algorithms. On a general note, the draft as it is now does not really say much more than the following: i) 169.254/16 must not be routed ii) how LLv4 addresses should be chosen. Subrata > -----Original Message----- > From: owner-zeroconf@merit.edu > [mailto:owner-zeroconf@merit.edu] On Behalf Of Ted Lemon > Sent: Monday, March 03, 2003 12:16 PM > To: Subrata Goswami > Cc: 'Robert Elz'; zeroconf@merit.edu > Subject: Re: LL24: Weaken the PRN requirement > > > A pseudo-random number generator is deterministic. If you > use a seed > that is unique to a particular device, that device will get the same > address every time, unless some other device's seed is the same, in > which case they will fight over it and the newcomer will lose. > > The problem we are arguing about here is not whether or not the > algorithm is deterministic, but how likely a collision is, > how likely a > second collision is after a first collision, and whether the > algorithm > actually hits all 65534 possible addresses. There are PRNGs > that have > this quality, and there are PRNGs that do not. > > So, consider these two algorithms: algorithm 1 is a perfect 16-bit > PRNG, seeded with the two least significant bytes of the MAC > address of > the device (we'll call this 2lsbmac). Algorithm 2 just > takes 2lsbmac > and uses it as the two least significant bytes of the first > IP address > it tries. If it gets a collision, it increments the address by one, > and tries again. > > So if you have two nodes on the network that use algorithm 1, both of > which get the same value for 2lsbmac, then the first one to connect > will get the first IP address it tries for. The second to connect > will get the next IP address in the sequence that algorithm 1 > produces. > Now if a third device connects to the network with the > same value for > 2lsbmac, it will try the IP address of the first station, then the IP > address of the second station, and then it will try a third > IP address > which has not yet been taken, and acquire that. > > This is precisely the same behavior that we get with > algorithm 2 - the > only difference is that the addresses in algorithm 1 will > look "random" > to a casual observer. But in the case of three stations with three > different values for 2lsbmac, both algorithms will produce > random-seeming addresses. > > Now consider a third algorithm. This algorithm uses a > perfect 32-bit > PRNG seeded with 4lsbmac. The likelihood of a clash with 4lsbmac is > much less than a clash with 2lsbmac - probably not 64k times less > likely, but certainly significantly less likely. The > algorithm simply > takes the two least significant bytes of the output of the PRNG and > uses those to generate an IP address. This algorithm has the same > probability of producing an initial collision as the other two. > However, the chances that the second try will also produce a > collision > are much lower, because there are 16 extra bits of data being > fed into > the PRNG. > > If you use a *bad* PRNG in your algorithm, your likelihood of > collisions will be quite high even if it's a 32-bit algorithm - there > are lots of bad PRNGs out there that don't produce a smooth > distribution in their output, and indeed don't even hit most possible > output values. A bad PRNG is probably worse than just adding one. > So if this draft is going to specify an algorithm, it should probably > specifically say what the algorithm is; otherwise we will > probably wind > up seeing a lot of implementations that do a really bad job of > collision avoidance. I am not sure this will matter on the average > network, but it might be a bummer for the poor bastard who > just happens > to wind up with set of nodes that happen to have seed values that > interact badly. > > So if you choose the wrong PRNG-based algorithm, it's no better than > just incrementing the IP address by one. However, if you use a good > algorithm from the start, it _is_ better. > From owner-zeroconf@merit.edu Tue Mar 4 11:33:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29543 for ; Tue, 4 Mar 2003 11:33:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC7DB91251; Tue, 4 Mar 2003 11:35:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A451791252; Tue, 4 Mar 2003 11:35:19 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 421E99122A for ; Tue, 4 Mar 2003 11:35:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 24CF55DEA8; Tue, 4 Mar 2003 11:35:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by segue.merit.edu (Postfix) with ESMTP id 03AF85DE55 for ; Tue, 4 Mar 2003 11:35:11 -0500 (EST) Received: from user-vcaulg9.dsl.mindspring.com ([216.175.86.9] helo=SGOSWAMIPCL) by heron.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 18qFNi-0005Of-00; Tue, 04 Mar 2003 08:35:06 -0800 From: "Subrata Goswami" To: "'Stuart Cheshire'" , Subject: RE: Oppose: LL24 Weaken the PRN generated address requirement from MUST to MAY Date: Tue, 4 Mar 2003 08:27:42 -0800 Message-ID: <003c01c2e26b$13571f50$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200303040628.h246SKs06955@scv1.apple.com> Importance: Normal X-ELNK-Trace: 33bae71ce1aa67f5d780f4a490ca69564776905774d2ac4bafb82e2be5a3bd0dd977442ca0f15c88350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Stuart, I think you are right in that the definition of PRN is vague enough to include any algorithm. A sentence to reflect that in the draft would be appropriate, what do you think ? Subrata > -----Original Message----- > From: owner-zeroconf@merit.edu > [mailto:owner-zeroconf@merit.edu] On Behalf Of Stuart Cheshire > Sent: Monday, March 03, 2003 10:28 PM > To: zeroconf@merit.edu > Subject: Oppose: LL24 Weaken the PRN generated address > requirement from MUST to MAY > > > I see no compelling arguments to support LL24. > > The term "pseudo-random number generator" is already > sufficiently vague > as to allow implementers significant leeway in what algorithm > they choose. > > The important point, as explained by others, is that > different hosts MUST > NOT get stuck in lock-step suffering an unending series of conflicts. > > Stuart Cheshire > * Wizard Without Portfolio, Apple Computer, Inc. > * www.stuartcheshire.org > From owner-zeroconf@merit.edu Tue Mar 4 11:33: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 LAA29570 for ; Tue, 4 Mar 2003 11:33:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B69EF91249; Tue, 4 Mar 2003 11:35:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 42BAB9122A; Tue, 4 Mar 2003 11:35:21 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ABB6791249 for ; Tue, 4 Mar 2003 11:35:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 732085DEA8; Tue, 4 Mar 2003 11:35:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by segue.merit.edu (Postfix) with ESMTP id 4F26A5DE55 for ; Tue, 4 Mar 2003 11:35:15 -0500 (EST) Received: from user-vcaulg9.dsl.mindspring.com ([216.175.86.9] helo=SGOSWAMIPCL) by heron.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 18qFNn-0005Of-00; Tue, 04 Mar 2003 08:35:11 -0800 From: "Subrata Goswami" To: "'Stuart Cheshire'" , Subject: LL24: Another (distributed) way to get an LLv4 address. Date: Tue, 4 Mar 2003 08:28:27 -0800 Message-ID: <004301c2e26b$163930a0$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200303040628.h246SKs06955@scv1.apple.com> Importance: Normal X-ELNK-Trace: 33bae71ce1aa67f5d780f4a490ca69564776905774d2ac4b2c64027858e4187ef8de49c396f1cff6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The following is a brief description of another algorithm, distributed, to generate a unique LLv4 address among other things. It makes use of the broadcast address 169.254.0.255. The algorithm goes as follows. 1. Any LL node, LLn1, that wants an LLv4 address sends out an REQUEST packet (exact details of this packet is glossed over at this point) on the link with source/destination address as 0.0.0.0/169.254.0.255. The REQUEST packet contains a request for the receiver to respond with its LLv4 address. 2. All the nodes with LLv4 address on the link that receives the REQUEST packet responds with a RESPONSE packet. The RESPONSE packet has source/destination address as 169.254.x.x/169.254.0.255, where 169.254.x.x is the LLv4 address of the receiving node. 3. The node, LLn1, then picks an LLv4 address that it has not received a response from. The algorithm is skeletal at this point (and also there is the scalability problem we discussed before in a different context). Subrata From owner-zeroconf@merit.edu Tue Mar 4 11:38: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 LAA29743 for ; Tue, 4 Mar 2003 11:38:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 575689122A; Tue, 4 Mar 2003 11:40:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D3AA91252; Tue, 4 Mar 2003 11:40:28 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2521E9122A for ; Tue, 4 Mar 2003 11:40:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BC055DEA8; Tue, 4 Mar 2003 11:40:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from heron.mail.pas.earthlink.net (heron.mail.pas.earthlink.net [207.217.120.189]) by segue.merit.edu (Postfix) with ESMTP id D8FF65DE55 for ; Tue, 4 Mar 2003 11:40:26 -0500 (EST) Received: from user-vcaulg9.dsl.mindspring.com ([216.175.86.9] helo=SGOSWAMIPCL) by heron.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 18qFSp-0006R9-00; Tue, 04 Mar 2003 08:40:23 -0800 From: "Subrata Goswami" To: "'Stuart Cheshire'" , Subject: RE: Oppose: LL24 Weaken the PRN generated address requirement from MUST to MAY Date: Tue, 4 Mar 2003 08:33:39 -0800 Message-ID: <004401c2e26b$d0444bb0$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <200303040628.h246SKs06955@scv1.apple.com> Importance: Normal X-ELNK-Trace: 33bae71ce1aa67f5d780f4a490ca69564776905774d2ac4b1da7d8613ce1302cf90c94c89cc433ab350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Stuart, I think you are right in that the definition of PRN is vague enough to include any algorithm. A sentence to reflect that in the draft would be appropriate, what do you think ? Subrata > -----Original Message----- > From: owner-zeroconf@merit.edu > [mailto:owner-zeroconf@merit.edu] On Behalf Of Stuart Cheshire > Sent: Monday, March 03, 2003 10:28 PM > To: zeroconf@merit.edu > Subject: Oppose: LL24 Weaken the PRN generated address > requirement from MUST to MAY > > > I see no compelling arguments to support LL24. > > The term "pseudo-random number generator" is already > sufficiently vague > as to allow implementers significant leeway in what algorithm > they choose. > > The important point, as explained by others, is that > different hosts MUST > NOT get stuck in lock-step suffering an unending series of conflicts. > > Stuart Cheshire > * Wizard Without Portfolio, Apple Computer, Inc. > * www.stuartcheshire.org > From owner-zeroconf@merit.edu Tue Mar 4 12:54: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 MAA03722 for ; Tue, 4 Mar 2003 12:54:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E2E7291228; Tue, 4 Mar 2003 12:56:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4C449122A; Tue, 4 Mar 2003 12:56:49 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C2F8291228 for ; Tue, 4 Mar 2003 12:56:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id B21F05DEBE; Tue, 4 Mar 2003 12:56:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 30CE45DEB9 for ; Tue, 4 Mar 2003 12:56:48 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27689; Tue, 4 Mar 2003 10:56:46 -0700 (MST) Received: from sun.com (vpn-129-159-0-18.EMEA.Sun.COM [129.159.0.18]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h24Huil10022; Tue, 4 Mar 2003 18:56:44 +0100 (MET) Message-ID: <3E64E871.1050006@sun.com> Date: Tue, 04 Mar 2003 18:54:57 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Subrata Goswami Cc: zeroconf@merit.edu Subject: Re: LL24: Another (distributed) way to get an LLv4 address. References: <004301c2e26b$163930a0$0200a8c0@SGOSWAMIPCL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subrata, A distributed counter algorithm is a 'good idea' (perhaps), but what IESG comment does it address? What burning problem does it solve? Remember - this process of issue resolution is not an avenue to bring new 'good ideas' to the table. The bar is high. It is not enough to show that a new idea may have merit, sort of. You must show that if we do not accept this as a problem, and the suggested text as its solution - we will be asking the IESG to advance a broken protocol specification. You must get something like consensus support for the initiative, too. Erik ------------ Subrata Goswami wrote: > The following is a brief description of another algorithm, distributed, > to generate a unique LLv4 address among other things. It makes use of > the broadcast address 169.254.0.255. The algorithm goes as follows. > > 1. Any LL node, LLn1, that wants an LLv4 address sends out an REQUEST > packet (exact details of this packet is glossed over at this point) on > the link with source/destination address as 0.0.0.0/169.254.0.255. The > REQUEST packet contains a request for the receiver to respond with its > LLv4 address. > > 2. All the nodes with LLv4 address on the link that receives the REQUEST > packet responds with a RESPONSE packet. The RESPONSE packet has > source/destination address as 169.254.x.x/169.254.0.255, where > 169.254.x.x is the LLv4 address of the receiving node. > > 3. The node, LLn1, then picks an LLv4 address that it has not received a > response from. > > The algorithm is skeletal at this point (and also there is the > scalability problem we discussed before in a different context). > > > Subrata > From owner-zeroconf@merit.edu Tue Mar 4 17:14: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 RAA12232 for ; Tue, 4 Mar 2003 17:14:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BAA5791250; Tue, 4 Mar 2003 17:15:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A5C191251; Tue, 4 Mar 2003 17:15:24 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A0D0291250 for ; Tue, 4 Mar 2003 17:15:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7B6C55DE8A; Tue, 4 Mar 2003 17:15:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id C68625DEFC for ; Tue, 4 Mar 2003 17:15:14 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.7/8.12.7) with ESMTP id h24MFEnR022453 for ; Tue, 4 Mar 2003 14:15:14 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 4 Mar 2003 14:15:09 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h24MFCf19378 for ; Tue, 4 Mar 2003 14:15:12 -0800 (PST) Message-Id: <200303042215.h24MFCf19378@scv3.apple.com> Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Date: Tue, 4 Mar 2003 14:15:11 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Robert Elz wrote: >There is evidence out there (apparently) that everything works OK >using 128 >I can't think of a reason that 64, or 32, or 16, or 192 would be any >different Precisely. TTL values from 1 to 254 all work pretty much about the same. The one exception is TTL=255, which allows the receiver to be pretty sure that the packet did in fact originate on-link. Given that we have 254 possible values that work about the same, and one other value that is just as good and also gives marginal additional functionality, I go with the additional functionality. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 17:32:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12787 for ; Tue, 4 Mar 2003 17:32:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7C2A591251; Tue, 4 Mar 2003 17:34:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49D1F91253; Tue, 4 Mar 2003 17:34:23 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 582B991251 for ; Tue, 4 Mar 2003 17:34:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 402B45DEFC; Tue, 4 Mar 2003 17:34:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id C9A3A5DEF5 for ; Tue, 4 Mar 2003 17:34:21 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-408.cisco.com [10.82.241.152]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h24MY182015747; Tue, 4 Mar 2003 14:34:02 -0800 (PST) Message-Id: <4.3.2.7.2.20030304172639.020bfd80@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Mar 2003 17:34:15 -0500 To: Stuart Cheshire From: John Schnizlein Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Cc: In-Reply-To: <200303042215.h24MFCf19378@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk At 05:15 PM 3/4/2003, Stuart Cheshire wrote: >Precisely. TTL values from 1 to 254 all work pretty much about the same. The same in principle, but only one of these causes an ordinary Internet router to drop packets that attempt to get beyond the link of origin. >The one exception is TTL=255, which allows the receiver to be pretty sure >that the packet did in fact originate on-link. > >Given that we have 254 possible values that work about the same, and one >other value that is just as good and also gives marginal additional >functionality, I go with the additional functionality. Your claim that the particular value of TTL=1 that would actually enforce the goal of keeping link-local traffic from being forwarded beyond the link is "about the same" as all the values from 2 through 254 is disingenuous. Your previous fair treatment of opinions that differ from your own leads me to expect a more direct argument from you. John From owner-zeroconf@merit.edu Tue Mar 4 17:47: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 RAA13220 for ; Tue, 4 Mar 2003 17:47:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D08B791253; Tue, 4 Mar 2003 17:49:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9814391258; Tue, 4 Mar 2003 17:49:45 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A266791253 for ; Tue, 4 Mar 2003 17:49:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 816805DF0D; Tue, 4 Mar 2003 17:49:44 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 138D55DEE6 for ; Tue, 4 Mar 2003 17:49:44 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.7/8.12.7) with ESMTP id h24MnhnR029290 for ; Tue, 4 Mar 2003 14:49:43 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 4 Mar 2003 14:49:37 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h24MndQ27114 for ; Tue, 4 Mar 2003 14:49:39 -0800 (PST) Message-Id: <200303042249.h24MndQ27114@scv2.apple.com> Subject: RE: Oppose: LL24 Weaken the PRN generated address requirement from MUST to MAY Date: Tue, 4 Mar 2003 14:49:38 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Stuart, I think you are right in that the definition of PRN is >vague enough to include any algorithm. A sentence to reflect >that in the draft would be appropriate, what do you think? I think that the current text in draft-07 is correct and adequate. The important properly is spelled out very clearly: The pseudo-random number generation algorithm MUST be chosen so that different hosts do not generate the same sequence of numbers. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 17:55: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 RAA13525 for ; Tue, 4 Mar 2003 17:55:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 29CC491258; Tue, 4 Mar 2003 17:57:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED93091259; Tue, 4 Mar 2003 17:57:25 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD48C91258 for ; Tue, 4 Mar 2003 17:57:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id AAE135DEFC; Tue, 4 Mar 2003 17:57:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 40A4C5DEF5 for ; Tue, 4 Mar 2003 17:57:24 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA14285 for ; Tue, 4 Mar 2003 17:57:23 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA28716 for ; Tue, 4 Mar 2003 17:57:23 -0500 (EST) Received: from [192.168.1.101] (cpe-66-189-9-93.ma.charter.com [66.189.9.93]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h24MvLxZ009708 for ; Tue, 4 Mar 2003 17:57:21 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 04 Mar 2003 17:57:18 -0500 Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <4.3.2.7.2.20030304172639.020bfd80@wells.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 03/04/2003 17:34, "John Schnizlein" wrote: > Your claim that the particular value of TTL=1 that would actually enforce the > goal of keeping link-local traffic from being forwarded beyond the link is > "about the same" as all the values from 2 through 254 is disingenuous. Your > previous fair treatment of opinions that differ from your own leads me to > expect a more direct argument from you. How can you ensure that a packet with a TTL of one originated on the local link? 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 Mar 4 18:11:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14709 for ; Tue, 4 Mar 2003 18:11:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 399C291259; Tue, 4 Mar 2003 18:12:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0943B9125A; Tue, 4 Mar 2003 18:12:57 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E740991259 for ; Tue, 4 Mar 2003 18:12:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id C30A25DF15; Tue, 4 Mar 2003 18:12:56 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id BA4245DF13 for ; Tue, 4 Mar 2003 18:12:55 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h24NDeaj010675; Wed, 5 Mar 2003 01:13:41 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h24NDbUk010665; Wed, 5 Mar 2003 01:13:37 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 From: Mika Liljeberg To: "John C. Welch" Cc: Zeroconf In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046819616.8754.19.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 01:13:37 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 00:57, John C. Welch wrote: > How can you ensure that a packet with a TTL of one originated on the local > link? A LL destination address in a packet is already a pretty good indication of local origin. TTL=255 check gives us nothing new. MikaL From owner-zeroconf@merit.edu Tue Mar 4 18:21: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 SAA14952 for ; Tue, 4 Mar 2003 18:21:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5F78A9125A; Tue, 4 Mar 2003 18:22:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D12F9125F; Tue, 4 Mar 2003 18:22:57 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 49AA59125A for ; Tue, 4 Mar 2003 18:22:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2FE775DF15; Tue, 4 Mar 2003 18:22:56 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id B88175DEFC for ; Tue, 4 Mar 2003 18:22:55 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.7/8.12.7) with ESMTP id h24NMtYv007926 for ; Tue, 4 Mar 2003 15:22:55 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 4 Mar 2003 15:22:52 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h24NMss28572 for ; Tue, 4 Mar 2003 15:22:54 -0800 (PST) Message-Id: <200303042322.h24NMss28572@scv1.apple.com> Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Date: Tue, 4 Mar 2003 15:22:53 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Zeroconf" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >How can you ensure that a packet with a TTL of one originated on the local >link? There are two different issues John: TTL=1 stops outgoing packets escaping. TTL=255 lets you *detect* incoming errant packets. The question is (since we can't do both), which is more important? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 18:21:54 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14998 for ; Tue, 4 Mar 2003 18:21:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B6C109125F; Tue, 4 Mar 2003 18:23:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A4A391260; Tue, 4 Mar 2003 18:23:49 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8288E9125F for ; Tue, 4 Mar 2003 18:23:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6F5E55DF18; Tue, 4 Mar 2003 18:23:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 31EA95DF17 for ; Tue, 4 Mar 2003 18:23:48 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.7/8.12.7) with ESMTP id h24NNlYv008138 for ; Tue, 4 Mar 2003 15:23:47 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 4 Mar 2003 15:23:44 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h24NNlQ24441 for ; Tue, 4 Mar 2003 15:23:47 -0800 (PST) Message-Id: <200303042323.h24NNlQ24441@scv2.apple.com> Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Date: Tue, 4 Mar 2003 15:23:46 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Your claim that the particular value of TTL=1 that would actually enforce >the goal of keeping link-local traffic from being forwarded beyond the >link is "about the same" as all the values from 2 through 254 is >disingenuous. Your previous fair treatment of opinions that differ >from your own leads me to expect a more direct argument from you. Fair criticism. I apologize. Let me try again: TTL=1. Should a packet be sent to a router for forwarding, TTL=1 prevents leakage. A packet may be sent to a router for forwarding deliberately (a software bug) or unintentionally (the router is indiscriminately answering every 169.254/16 ARP request). Does not allow recipient to confirm that packet originated on-link. TTL=2...254. Doesn't prevent leakage. Does not allow recipient to confirm that packet originated on-link. TTL=255. Doesn't prevent leakage. Allows recipient to confirm that packet originated on-link. Now that I have stated the properties (I hope) more fairly, let me say why I count the benefit of TTL=1 as being less than the benefit of TTL=255: LL packets should NEVER be sent to a router for forwarding. If it is done deliberately, then that's a bug and should be fixed. If it happens because of a device doing indiscriminate proxy ARP, then that device is (in my opinion) a major headache and should be fixed or removed. If your DHCP server fails and hosts try to use IPv4LL, then the indiscriminate proxy ARP box is going to completely sabotage that and prevent any useful communication. If your DHCP server is a headless box and the only way to connect to it to fix the problem is via IPv4LL, then the indiscriminate proxy ARP box has just painted you into a corner from which you cannot escape. In such a scenario of total network failure, a few failed TCP SYNs leaking out into the wider network is (in my opinion) irrelevant alongside the far greater problem that you have total network failure. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 18:41: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 SAA15579 for ; Tue, 4 Mar 2003 18:41:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3F3BC91260; Tue, 4 Mar 2003 18:43:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 12F1C91264; Tue, 4 Mar 2003 18:43:09 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F0EE291260 for ; Tue, 4 Mar 2003 18:43:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id D3D7A5DF13; Tue, 4 Mar 2003 18:43:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id DF0A05DF03 for ; Tue, 4 Mar 2003 18:43:07 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h24Nhlaj010845; Wed, 5 Mar 2003 01:43:47 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h24NhkuC010841; Wed, 5 Mar 2003 01:43:46 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 From: Mika Liljeberg To: Stuart Cheshire Cc: zeroconf@merit.edu In-Reply-To: <200303042323.h24NNlQ24441@scv2.apple.com> References: <200303042323.h24NNlQ24441@scv2.apple.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046821424.8754.30.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 01:43:45 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 01:23, Stuart Cheshire wrote: > TTL=1. Should a packet be sent to a router for forwarding, TTL=1 prevents > leakage. A packet may be sent to a router for forwarding deliberately (a > software bug) or unintentionally (the router is indiscriminately > answering every 169.254/16 ARP request). Does not allow recipient to > confirm that packet originated on-link. Two points: - Due to recent decisions, a packet intended for the local link might have a mix of routable and LL addresses (any of the 4 combinations). - A proxy ARP router could be configured to recognize 169.254/16 as being on-link. This would allow configuration of LL addresses. The first point alone allows leakage, which TTL=1 would prevent. The second point just shows that there is a legitimate proxy ARP configuration that could cause problems. > TTL=255. Doesn't prevent leakage. Allows recipient to confirm that packet > originated on-link. A LL destination address in a packet is good enough for me. Damned hard to send one from off-link. On the other hand, if the destination address is routable, you shouldn't be basing your security on the TTL value. MikaL From owner-zeroconf@merit.edu Tue Mar 4 18:44: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 SAA15662 for ; Tue, 4 Mar 2003 18:44:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CBE3091275; Tue, 4 Mar 2003 18:46:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92B939126C; Tue, 4 Mar 2003 18:46:16 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8BD5191268 for ; Tue, 4 Mar 2003 18:46:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C4045DF20; Tue, 4 Mar 2003 18:46:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id B44815DF1D for ; Tue, 4 Mar 2003 18:46:08 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA29855 for ; Tue, 4 Mar 2003 18:46:08 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA17890 for ; Tue, 4 Mar 2003 18:46:07 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h24Nk6xZ020005 for ; Tue, 4 Mar 2003 18:46:07 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 04 Mar 2003 18:46:05 -0500 Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <1046819616.8754.19.camel@devil> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 03/04/2003 18:13, "Mika Liljeberg" wrote: >> How can you ensure that a packet with a TTL of one originated on the local >> link? > > A LL destination address in a packet is already a pretty good indication > of local origin. TTL=255 check gives us nothing new. No, it's an indication that it originated in a subnet with that address. Nothing more. A TTL of 255 indicates that the packed hasn't been through a router yet. Nothing more. Both together give you a VERY high probability of local origin. 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 Mar 4 18:47:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15744 for ; Tue, 4 Mar 2003 18:47:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1201B91264; Tue, 4 Mar 2003 18:48:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CFB8E9121D; Tue, 4 Mar 2003 18:48:52 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 23E0A91264 for ; Tue, 4 Mar 2003 18:48:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 679E85DF18; Tue, 4 Mar 2003 18:48:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id ECCAA5DF1C for ; Tue, 4 Mar 2003 18:48:06 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA00584 for ; Tue, 4 Mar 2003 18:48:06 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA05580 for ; Tue, 4 Mar 2003 18:48:06 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h24Nm5xZ020335 for ; Tue, 4 Mar 2003 18:48:05 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 04 Mar 2003 18:48:04 -0500 Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200303042322.h24NMss28572@scv1.apple.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 03/04/2003 18:22, "Stuart Cheshire" wrote: >> How can you ensure that a packet with a TTL of one originated on the local >> link? > > There are two different issues John: > > TTL=1 stops outgoing packets escaping. > > TTL=255 lets you *detect* incoming errant packets. > > The question is (since we can't do both), which is more important? Right. As a network admin, I'm *far* more interested that the data I'm receiving that says "local packet" actually IS a local packet. Oddly enough, I'm not worried about leakage *as much*. But I think TTL needs to be set on send, and checked on receive, and if it's wrong, then dump the packet. 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 Mar 4 18:53:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15896 for ; Tue, 4 Mar 2003 18:53:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF84E9121D; Tue, 4 Mar 2003 18:55:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C161D91268; Tue, 4 Mar 2003 18:55:01 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AF1E99121D for ; Tue, 4 Mar 2003 18:55:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8C7845DF18; Tue, 4 Mar 2003 18:55:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 797DB5DF0B for ; Tue, 4 Mar 2003 18:54:59 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h24Ntjaj010914; Wed, 5 Mar 2003 01:55:46 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h24Nti5p010908; Wed, 5 Mar 2003 01:55:44 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 From: Mika Liljeberg To: "John C. Welch" Cc: Zeroconf In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046822143.8761.37.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 01:55:44 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 01:46, John C. Welch wrote: > > A LL destination address in a packet is already a pretty good indication > > of local origin. TTL=255 check gives us nothing new. > > No, it's an indication that it originated in a subnet with that address. No it doesn't. It just indicates that someone tried to use LL as a destination address. My point is that you won't have much luck trying to get a packet like that routed where you want it. We *are* talking about attacks, right? [If we were only talking about leakage, TTL=1 would clearly be more effective.] MikaL From owner-zeroconf@merit.edu Tue Mar 4 19:03:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16182 for ; Tue, 4 Mar 2003 19:03:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8784F91268; Tue, 4 Mar 2003 19:05:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 574329126C; Tue, 4 Mar 2003 19:05:04 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 44E6D91268 for ; Tue, 4 Mar 2003 19:05:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C2595DF1D; Tue, 4 Mar 2003 19:05:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id B51165DF1C for ; Tue, 4 Mar 2003 19:05:02 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA07272 for ; Tue, 4 Mar 2003 19:05:02 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA19887 for ; Tue, 4 Mar 2003 19:05:02 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h2504vxZ022993 for ; Tue, 4 Mar 2003 19:05:00 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 04 Mar 2003 19:04:56 -0500 Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <1046822143.8761.37.camel@devil> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 03/04/2003 18:55, "Mika Liljeberg" wrote: >> No, it's an indication that it originated in a subnet with that address. > > No it doesn't. It just indicates that someone tried to use LL as a > destination address. > > My point is that you won't have much luck trying to get a packet like > that routed where you want it. We *are* talking about attacks, right? If I'm running an attack, then I'm not going to be able to *guarantee* the ending TTL. But I'll have *far* better luck with 1 than with 255. 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 Mar 4 19:07:09 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16356 for ; Tue, 4 Mar 2003 19:07:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7194D9126C; Tue, 4 Mar 2003 19:09:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D35391284; Tue, 4 Mar 2003 19:09:05 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2D1E49126C for ; Tue, 4 Mar 2003 19:09:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 123815DF1D; Tue, 4 Mar 2003 19:09:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 287DE5DF0B for ; Tue, 4 Mar 2003 19:09:03 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h2509naj011020; Wed, 5 Mar 2003 02:09:49 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h2509lh2011015; Wed, 5 Mar 2003 02:09:47 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 From: Mika Liljeberg To: "John C. Welch" Cc: Zeroconf In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046822987.8760.42.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 02:09:47 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 02:04, John C. Welch wrote: > > My point is that you won't have much luck trying to get a packet like > > that routed where you want it. We *are* talking about attacks, right? > > If I'm running an attack, then I'm not going to be able to *guarantee* the > ending TTL. But I'll have *far* better luck with 1 than with 255. So here's a challenge for you: whip out your hacker toolbox and send me a packet that has a LL destination address. I guarantee you I'll never see it, much less get to check its TTL. MikaL From owner-zeroconf@merit.edu Tue Mar 4 19:09: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 TAA16415 for ; Tue, 4 Mar 2003 19:09:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E92E791284; Tue, 4 Mar 2003 19:10:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4A3F9128A; Tue, 4 Mar 2003 19:10:57 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B6FD391284 for ; Tue, 4 Mar 2003 19:10:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 99ABE5DF1F; Tue, 4 Mar 2003 19:10:56 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 2F4D65DF1D for ; Tue, 4 Mar 2003 19:10:56 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-408.cisco.com [10.82.241.152]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h250Ab82023502; Tue, 4 Mar 2003 16:10:38 -0800 (PST) Message-Id: <4.3.2.7.2.20030304190436.020bfd80@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Mar 2003 19:10:51 -0500 To: Stuart Cheshire From: John Schnizlein Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Cc: "Zeroconf" In-Reply-To: <200303042322.h24NMss28572@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk At 06:22 PM 3/4/2003, Stuart Cheshire wrote: >TTL=1 stops outgoing packets escaping. > >TTL=255 lets you *detect* incoming errant packets. > >The question is (since we can't do both), which is more important? Well-framed question. Since ordinary Internet-compliant routers enforce TTL=1, and only ZeroConf hosts could enforce TTL=255, the mechanism most likely to be in place is TTL=1. And if all hosts (unless they have a particular purpose, as Christian proposed and I agreed) that intend link-local traffic were to set TTL=1, there would be no such traffic "out there" to leak in. With this choice, protecting yourself uses exactly the same mechanism as protecting the rest of the Internet. A specification that puts the interests of protecting yourself at odds with doing the right thing for the Internet would be bad. John From owner-zeroconf@merit.edu Tue Mar 4 19:12: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 TAA16522 for ; Tue, 4 Mar 2003 19:12:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 398039128A; Tue, 4 Mar 2003 19:13:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 070569128B; Tue, 4 Mar 2003 19:13:56 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF4249128A for ; Tue, 4 Mar 2003 19:13:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id D1C625DF1D; Tue, 4 Mar 2003 19:13:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 698235DF1A for ; Tue, 4 Mar 2003 19:13:55 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA14821 for ; Tue, 4 Mar 2003 19:13:54 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA08072 for ; Tue, 4 Mar 2003 19:13:54 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h250DpxZ024345 for ; Tue, 4 Mar 2003 19:13:52 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 04 Mar 2003 19:13:48 -0500 Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <1046822987.8760.42.camel@devil> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 03/04/2003 19:09, "Mika Liljeberg" wrote: >> If I'm running an attack, then I'm not going to be able to *guarantee* the >> ending TTL. But I'll have *far* better luck with 1 than with 255. > > So here's a challenge for you: whip out your hacker toolbox and send me > a packet that has a LL destination address. I guarantee you I'll never > see it, much less get to check its TTL. Um...so there's this thing called "nat".... 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 Mar 4 19:18: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 TAA16747 for ; Tue, 4 Mar 2003 19:18:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D36A29128B; Tue, 4 Mar 2003 19:20:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0E719128C; Tue, 4 Mar 2003 19:20:24 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D2679128B for ; Tue, 4 Mar 2003 19:20:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 823945DF1E; Tue, 4 Mar 2003 19:20:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 9B7CF5DF1D for ; Tue, 4 Mar 2003 19:20:22 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h250L9aj011103; Wed, 5 Mar 2003 02:21:09 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h250L8kB011096; Wed, 5 Mar 2003 02:21:08 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 From: Mika Liljeberg To: "John C. Welch" Cc: Zeroconf In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046823667.8761.45.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 02:21:07 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 02:13, John C. Welch wrote: > > So here's a challenge for you: whip out your hacker toolbox and send me > > a packet that has a LL destination address. I guarantee you I'll never > > see it, much less get to check its TTL. > > Um...so there's this thing called "nat".... I'm all ears. How would that work exactly? MikaL From owner-zeroconf@merit.edu Tue Mar 4 19:18: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 TAA16766 for ; Tue, 4 Mar 2003 19:18:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DDE749128C; Tue, 4 Mar 2003 19:20:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF7429128E; Tue, 4 Mar 2003 19:20:42 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9F8019128C for ; Tue, 4 Mar 2003 19:20:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8C7EA5DF1E; Tue, 4 Mar 2003 19:20:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 221B95DF1D for ; Tue, 4 Mar 2003 19:20:41 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-408.cisco.com [10.82.241.152]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h250KO82000553; Tue, 4 Mar 2003 16:20:25 -0800 (PST) Message-Id: <4.3.2.7.2.20030304191458.021fbec0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Mar 2003 19:20:38 -0500 To: "John C. Welch" From: John Schnizlein Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Cc: Zeroconf In-Reply-To: References: <1046822143.8761.37.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk At 07:04 PM 3/4/2003, John C. Welch wrote: >If I'm running an attack, then I'm not going to be able to *guarantee* the >ending TTL. But I'll have *far* better luck with 1 than with 255. There was a long thread about supposed security benefits of checking TTL=255, with the conclusion that no security claims were valid enough to continue that thread. Since this WG has accepted the position that there is no particular security value to link-local traffic, and there are so many different attacks available on an un-configured subnet, assuming that an attack would employ TTL tricks is dubious. John From owner-zeroconf@merit.edu Tue Mar 4 19:31:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17006 for ; Tue, 4 Mar 2003 19:31:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5C5D79128F; Tue, 4 Mar 2003 19:33:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2FF8491228; Tue, 4 Mar 2003 19:33:19 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D7709128F for ; Tue, 4 Mar 2003 19:31:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 74C875DF1E; Tue, 4 Mar 2003 19:31:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by segue.merit.edu (Postfix) with ESMTP id 0965C5DDF0 for ; Tue, 4 Mar 2003 19:31:53 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h250VoJR015621 for ; Tue, 4 Mar 2003 19:31:51 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn3-223.cisco.com [10.21.64.223]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA16622 for ; Tue, 4 Mar 2003 19:31:50 -0500 (EST) Message-Id: <4.3.2.7.2.20030304192443.036a3ac8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Mar 2003 19:31:47 -0500 To: From: Ralph Droms Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 In-Reply-To: <200303040632.h246W9s08696@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I support LL29. Setting TTL to 255 and checking the TTL on receipt amounts to redefining the TTL field to be a "on this link" field for IP packets that have IPv4LL source and/or destination addresses. This redefinition makes use of the behavior of existing routers but is not conveying the information intended in the original definition of the TTL field. Redefining the TTL field in this way is beyond the scope of the zeroconf WG. Requiring that the TTL be set to 1 is compliant with the definition and use of the TTL field in all other IP packets. - Ralph From owner-zeroconf@merit.edu Tue Mar 4 20:16: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 UAA17818 for ; Tue, 4 Mar 2003 20:16:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 48D1491229; Tue, 4 Mar 2003 20:18:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 030879128E; Tue, 4 Mar 2003 20:18:24 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A27DC91229 for ; Tue, 4 Mar 2003 20:18:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 74B055DF0B; Tue, 4 Mar 2003 20:18:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 00E215DF14 for ; Tue, 4 Mar 2003 20:18:21 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 2E33D1B2251; Tue, 4 Mar 2003 19:14:28 -0600 (CST) Date: Tue, 4 Mar 2003 19:18:19 -0600 Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Zeroconf To: "John C. Welch" From: Ted Lemon In-Reply-To: Message-Id: <59649B08-4EA8-11D7-8AB4-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >>> If I'm running an attack, then I'm not going to be able to >>> *guarantee* the >>> ending TTL. But I'll have *far* better luck with 1 than with 255. >> >> So here's a challenge for you: whip out your hacker toolbox and send >> me >> a packet that has a LL destination address. I guarantee you I'll never >> see it, much less get to check its TTL. > > Um...so there's this thing called "nat".... I've seen you complain when others responded like this. Mika has a point. How can an attacker get a packet with an IP destination address that's an IPv4ll address arrange for a series of routers to convey that packet to your network? Is it even *remotely* possible that this could be done? Can you describe a network configuration where this would be possible? I think we are arguing about how many needles can dance on the head of a pin - I don't see any way for an actual packet addressed to an IPv4ll destination to stray significantly from where it belongs, and I definitely don't see a way to direct such a packet to a particular destination. From owner-zeroconf@merit.edu Tue Mar 4 20:19:58 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17906 for ; Tue, 4 Mar 2003 20:19:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9306C9128E; Tue, 4 Mar 2003 20:21:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5856091290; Tue, 4 Mar 2003 20:21:52 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 487709128E for ; Tue, 4 Mar 2003 20:21:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 25B7E5DF23; Tue, 4 Mar 2003 20:21:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by segue.merit.edu (Postfix) with ESMTP id BFB755DF0B for ; Tue, 4 Mar 2003 20:21:50 -0500 (EST) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Tue, 4 Mar 2003 17:21:49 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 Mar 2003 17:21:49 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 4 Mar 2003 17:21:49 -0800 Received: from WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 4 Mar 2003 17:21:48 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Tue, 4 Mar 2003 17:21:50 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Oppose: LL29 Link-local sources should specify TTL=1 Date: Tue, 4 Mar 2003 17:21:47 -0800 Message-ID: Thread-Topic: Oppose: LL29 Link-local sources should specify TTL=1 Thread-Index: AcLitSkaF55Z8PfVTluHNYCJCbMmEgAAE0MQ From: "Christian Huitema" To: "Ted Lemon" , "John C. Welch" Cc: "Zeroconf" X-OriginalArrivalTime: 05 Mar 2003 01:21:50.0452 (UTC) FILETIME=[990D0340:01C2E2B5] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA17906 > I think we are arguing about how many needles can dance on the head of > a pin - I don't see any way for an actual packet addressed to an IPv4ll > destination to stray significantly from where it belongs, and I > definitely don't see a way to direct such a packet to a particular > destination. Wrong. Source routes and tunnels come to mind easily. From owner-zeroconf@merit.edu Tue Mar 4 21:46:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19689 for ; Tue, 4 Mar 2003 21:46:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 10EC191290; Tue, 4 Mar 2003 21:48:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADB3991291; Tue, 4 Mar 2003 21:48:06 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A806691290 for ; Tue, 4 Mar 2003 21:48:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 800965DF17; Tue, 4 Mar 2003 21:48:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 05F3F5DF0B for ; Tue, 4 Mar 2003 21:48:03 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id C225D1B2259; Tue, 4 Mar 2003 20:44:08 -0600 (CST) Date: Tue, 4 Mar 2003 20:48:00 -0600 Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Zeroconf" , "John C. Welch" To: "Christian Huitema" From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Wrong. Source routes and tunnels come to mind easily. Of course, but I mean in practice, not in theory. Source routing is dangerous. In practice, it's not available, even though it's described in a standard and very widely implemented in various IP stacks. > dra-chi% sysctl -a |fgrep source > net.inet.ip.sourceroute: 0 > net.inet.ip.accept_sourceroute: 0 This is the default configuration for a MacOS X machine. Do Windows machines, Cisco routers, or the like, come with source routing enabled? Unless I am mistaken, in practice there is no way to use source routing to get a packet somewhere it doesn't belong across the Internet. As for tunnels, I didn't say it wasn't possible for an IPv4ll packet to leak *out*. I imagine it could follow default routes quite a ways out from a leaf network before it was stopped by a BGP router with no route for the IPv4ll class B. It's hard to imagine how this could be used to *direct* an IPv4ll packet somewhere it didn't belong. As for tunnels, if you have your laptop configured to do routing, and it has a VPN tunnel into your corporate network, then it's possible that an attacker on your local network could forward a packet through your machine and use it to attack some resource on your corporate network. I would hope that there aren't any VPN clients out there that can easily be configured to work this way. If there are, this is only one of many attacks that is possible. Once again, it's difficult to see how this attack would be useful, since it's unlikely that there'd be a way to get a reply back out through the tunnel, nor out through the corporate firewall, from an IPv4ll node that's not cooperating in the attack. The point is that while this is theoretically a problem, it's not a problem over which we need get our knickers in a twist. From owner-zeroconf@merit.edu Tue Mar 4 22:01:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19953 for ; Tue, 4 Mar 2003 22:01:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 35AF091291; Tue, 4 Mar 2003 22:03:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A913F91292; Tue, 4 Mar 2003 22:03:07 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6ECEC91291 for ; Tue, 4 Mar 2003 22:02:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4C26E5DF35; Tue, 4 Mar 2003 22:02:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id D1BF55DF34 for ; Tue, 4 Mar 2003 22:02:09 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.7/8.12.7) with ESMTP id h25328Yv029510 for ; Tue, 4 Mar 2003 19:02:08 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 4 Mar 2003 19:02:05 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h25327s26928 for ; Tue, 4 Mar 2003 19:02:07 -0800 (PST) Message-Id: <200303050302.h25327s26928@scv1.apple.com> Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Date: Tue, 4 Mar 2003 19:02:07 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Mika Liljeberg wrote: >- Due to recent decisions, a packet intended for the local link might >have a mix of routable and LL addresses (any of the 4 combinations). > >- A proxy ARP router could be configured to recognize 169.254/16 as >being on-link. This would allow configuration of LL addresses. > >The first point alone allows leakage No it doesn't. If you think it does, please describe an exact scenario using LL-compliant hosts. (Any mention of non-compliant hosts here is a red-herring, because we control neither what they do with packets, nor what TTL they set.) >The second point just shows that there is a legitimate proxy ARP >configuration that could cause problems. The meaning of the word "proxy" is very clear: Proxy: A person authorized to act for another; an agent or substitute. The authority to act for another. The written authorization to act in place of another. When an entity is authorized to act on my behalf, it is a proxy. When an entity takes it upon itself to act on my behalf without authority and gets it wrong, that is not a "legitimate proxy". >A LL destination address in a packet is good enough for me. >Damned hard to send one from off-link. Hard, but not impossible. Security includes protecting against attacks that are hard to do (but not necessarily against attacks that are impossible to do). >So here's a challenge for you: whip out your hacker toolbox and send me >a packet that has a LL destination address. I guarantee you I'll never >see it, much less get to check its TTL. Mika, defining a standard for the whole world is about more than what works on YOUR network. The question is not whether YOUR router will let in packets addressed to 169.254/16, but whether ANY routers will advertently let in packets addressed to 169.254/16. Unless you can categorically say no, for every router in the world, there is a risk of attack. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 22:01: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 WAA19981 for ; Tue, 4 Mar 2003 22:01:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A2C5991292; Tue, 4 Mar 2003 22:03:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57F5F91294; Tue, 4 Mar 2003 22:03:50 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6DE591292 for ; Tue, 4 Mar 2003 22:03:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id C43F05DF32; Tue, 4 Mar 2003 22:03:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 365CD5DF31 for ; Tue, 4 Mar 2003 22:03:48 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.7/8.12.7) with ESMTP id h2533lnR027439 for ; Tue, 4 Mar 2003 19:03:47 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 4 Mar 2003 19:03:42 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h2533jf10745 for ; Tue, 4 Mar 2003 19:03:45 -0800 (PST) Message-Id: <200303050303.h2533jf10745@scv3.apple.com> Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Date: Tue, 4 Mar 2003 19:03:44 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Setting TTL to 255 and checking the TTL on receipt amounts >to redefining the TTL field to be a "on this link" field for IP packets >that have IPv4LL source and/or destination addresses. This redefinition >makes use of the behavior of existing routers but is not conveying the >information intended in the original definition of the TTL >field. Unfortunately, other documents like LLMNR also propose requiring TTL=255. If we specify that the TTL is 1 unless specified otherwise by the application (as several people have proposed), I fear we invite more chaos, not less. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 22:02:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20001 for ; Tue, 4 Mar 2003 22:02:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 92D109120D; Tue, 4 Mar 2003 22:04:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5268991294; Tue, 4 Mar 2003 22:04:15 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7166B9120D for ; Tue, 4 Mar 2003 22:04:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 46E1E5DF37; Tue, 4 Mar 2003 22:04:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id BF6675DF36 for ; Tue, 4 Mar 2003 22:04:12 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.7/8.12.7) with ESMTP id h2534CnR027851 for ; Tue, 4 Mar 2003 19:04:12 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 4 Mar 2003 19:04:08 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h2534As28041 for ; Tue, 4 Mar 2003 19:04:11 -0800 (PST) Message-Id: <200303050304.h2534As28041@scv1.apple.com> Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Date: Tue, 4 Mar 2003 19:04:10 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk John Schnizlein wrote: >Since ordinary Internet-compliant routers enforce TTL=1, >and only ZeroConf hosts could enforce TTL=255, the mechanism >most likely to be in place is TTL=1. Since the only devices sending packets according to this spec are those that implement this spec, none of those devices will send packets for forwarding at all, so the point is irrelevant. >And if all hosts (unless they have a particular purpose, as >Christian proposed and I agreed) that intend link-local traffic >were to set TTL=1, there would be no such traffic "out there" >to leak in. Malicious traffic "out there" may still leak in (and may be more successful in doing so, because with a spec that says compliant hosts must set TTL=1, there is less incentive for router vendors to think it necessary put in rules to block incoming spoof LL traffic). >There was a long thread about supposed security benefits of checking >TTL=255, with the conclusion that no security claims were valid enough >to continue that thread. You are mistaken. The (tentative) conclusion was that there were small but non-zero benefits to checking TTL=255. If this conclusion is not agreed, we may need to re-open the debate concerning whether the security benefit is zero or non-zero. I strongly doubt that any debate concerning the precise magnitude of the non-zero security benefit will lead to any consensus. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 22:07: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 WAA20077 for ; Tue, 4 Mar 2003 22:07:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9917891294; Tue, 4 Mar 2003 22:08:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 644C691296; Tue, 4 Mar 2003 22:08:55 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 60CEA91294 for ; Tue, 4 Mar 2003 22:08:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 44F465DF35; Tue, 4 Mar 2003 22:08:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by segue.merit.edu (Postfix) with ESMTP id CFA875DF34 for ; Tue, 4 Mar 2003 22:08:53 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2538pNh016051 for ; Tue, 4 Mar 2003 22:08:51 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn3-223.cisco.com [10.21.64.223]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA24071 for ; Tue, 4 Mar 2003 22:08:50 -0500 (EST) Message-Id: <4.3.2.7.2.20030304220802.036edbd0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 04 Mar 2003 22:08:50 -0500 To: From: Ralph Droms Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 In-Reply-To: <200303050303.h2533jf10745@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk OK, I have the same objection to abusing the TTL field in LLMNR, too. :-) - Ralph At 07:03 PM 3/4/2003 -0800, Stuart Cheshire wrote: > >Setting TTL to 255 and checking the TTL on receipt amounts > >to redefining the TTL field to be a "on this link" field for IP packets > >that have IPv4LL source and/or destination addresses. This redefinition > >makes use of the behavior of existing routers but is not conveying the > >information intended in the original definition of the TTL > >field. > >Unfortunately, other documents like LLMNR also propose requiring TTL=255. > >If we specify that the TTL is 1 unless specified otherwise by the >application (as several people have proposed), I fear we invite more >chaos, not less. > >Stuart Cheshire > * Wizard Without Portfolio, Apple Computer, Inc. > * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 22:16: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 WAA20239 for ; Tue, 4 Mar 2003 22:16:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 19CEC91296; Tue, 4 Mar 2003 22:18:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBFA591299; Tue, 4 Mar 2003 22:18:17 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D684D91296 for ; Tue, 4 Mar 2003 22:17:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id AF7005DEFD; Tue, 4 Mar 2003 22:17:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 381795DDC6 for ; Tue, 4 Mar 2003 22:17:53 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.7/8.12.7) with ESMTP id h253HqYv003653 for ; Tue, 4 Mar 2003 19:17:52 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 4 Mar 2003 19:17:52 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h253Hqf16152 for ; Tue, 4 Mar 2003 19:17:52 -0800 (PST) Message-Id: <200303050317.h253Hqf16152@scv3.apple.com> Subject: Oppose: LL29 Link-local sources should specify TTL=1 Date: Tue, 4 Mar 2003 19:17:51 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk I need to point out that the text of the LL29 proposal contains some language that really encourages foggy thinking. > This requirement enables the normal behavior of Internet routers > to preclude leaking traffic that is supposed to be confined to a > single link out into the Internet when the local link has an > attachment to the Internet that it did not discover. This notion that packets "leak", like water out of a cracked pipe, may seem natural, but not if you actually think about it. Packets do not "leak". Packets are transmitted from host to host, by deliberate protocol action. If the local link has an attachment to the Internet that the local hosts have not discovered, then they cannot send packets to it. Hosts can only send packets to an attachment to the Internet *after* they have discovered it, and having discovered it, compliant hosts will not send any packets for forwarding. The only remaining case is indiscriminate proxy ARP, which may *trick* hosts into sending packets to the wrong place, but these devices cause such serious damage anyway that "leakage" is the least of the users problems when all LL networking has completely failed. Fortunately, these problems have not been widely reported over the last five years. To the extent that these problems may exist, that's very strong argument that we need to publish this RFC soon, stating that indiscriminate proxy ARP boxes should not answer 169.254/16 requests. To the extent that TTL=1 would allow these vendors to assume that there's no problem continuing the current behaviour, IPv4LL scores a huge own-goal. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Mar 4 23:01: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 XAA21365 for ; Tue, 4 Mar 2003 23:01:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4BDB791218; Tue, 4 Mar 2003 23:01:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 042C39121C; Tue, 4 Mar 2003 23:01:15 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8651591218 for ; Tue, 4 Mar 2003 23:01:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6B8185DF39; Tue, 4 Mar 2003 23:00:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id F303C5DF36 for ; Tue, 4 Mar 2003 23:00:29 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA28865 for ; Tue, 4 Mar 2003 23:00:29 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA10115 for ; Tue, 4 Mar 2003 23:00:29 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h253uoxZ027219 for ; Tue, 4 Mar 2003 22:56:50 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 04 Mar 2003 22:56:48 -0500 Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <4.3.2.7.2.20030304191458.021fbec0@wells.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 03/04/2003 19:20, "John Schnizlein" wrote: >> If I'm running an attack, then I'm not going to be able to *guarantee* the >> ending TTL. But I'll have *far* better luck with 1 than with 255. > > There was a long thread about supposed security benefits of checking > TTL=255, with the conclusion that no security claims were valid enough > to continue that thread. Since this WG has accepted the position that > there is no particular security value to link-local traffic, and there > are so many different attacks available on an un-configured subnet, > assuming that an attack would employ TTL tricks is dubious. So is saying that TTL = 1 prevents leakage any more than 255...one prevents leakage out, the other prevents leakage in. zeroes out nicely to me. john -- John C. Welch Consultant III Office Computing Practice (IS) (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Mar 4 23:08:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21463 for ; Tue, 4 Mar 2003 23:08:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1D4359121C; Tue, 4 Mar 2003 23:10:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8BFE9122C; Tue, 4 Mar 2003 23:10:01 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B26A49121C for ; Tue, 4 Mar 2003 23:10:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7B9A25DF39; Tue, 4 Mar 2003 23:10:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 10F145DF34 for ; Tue, 4 Mar 2003 23:10:00 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA02320 for ; Tue, 4 Mar 2003 23:09:59 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA10390 for ; Tue, 4 Mar 2003 23:05:29 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h2542dxZ028087 for ; Tue, 4 Mar 2003 23:02:39 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 04 Mar 2003 23:02:38 -0500 Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <59649B08-4EA8-11D7-8AB4-00039367340A@nominum.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 03/04/2003 20:18, "Ted Lemon" wrote: > I've seen you complain when others responded like this. Mika has a > point. How can an attacker get a packet with an IP destination > address that's an IPv4ll address arrange for a series of routers to > convey that packet to your network? Is it even *remotely* possible > that this could be done? Can you describe a network configuration > where this would be possible? Um..I work in an environment that is very well defined and well known, down to the number of routers. And I never complain about NAT, that's someone else. The point was, there is a way to hide your true IP address from external routers. If you know your network well enough, you can spoof anything. My point is, I don't see any more real advantage to TTL =1 over 255. I can see a *disadvantage* in that out of the two leading users of LL *now*, neither uses 255. Since we all agree that a properly configured router will never pass a LL address *anyway*, leakage isn't a problem. It's a double check really, more because what you *could* have is a router that happens to be talking to two separate LL networks. That's the case where weirdness may happen. And I really don't think that the Internet needs 'protecting' nearly as much as some. It's a pretty flexible thing. Some specific points may be more fragile than others, but let's not get into the mental image of 'saving the Internet'. It constrains your thinking. -- John C. Welch Consultant III Office Computing Practice (IS) (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Mar 5 01:20: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 BAA24150 for ; Wed, 5 Mar 2003 01:20:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4F8209122C; Wed, 5 Mar 2003 01:21:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D47391230; Wed, 5 Mar 2003 01:21:59 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 194239122C for ; Wed, 5 Mar 2003 01:21:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id E9AEC5DF34; Wed, 5 Mar 2003 01:21:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 89BD85DE8B for ; Wed, 5 Mar 2003 01:21:57 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 97B461B225E; Wed, 5 Mar 2003 00:18:01 -0600 (CST) Date: Wed, 5 Mar 2003 00:21:55 -0600 Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Zeroconf To: "John C. Welch" From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> I've seen you complain when others responded like this. > Um..I work in an environment that is very well defined and well known, > down > to the number of routers. And I never complain about NAT, that's > someone > else. Sorry, I mean complain about hypothetical failure scenarios with no actual documented scenario to back up the complaint. > If you know your network well enough, you can spoof > anything. No, you can't spoof anything. If you know your network well, you may be able to do some significant subset of all spoofs that are possible on your network, but that's a much more restricted set of spoofs than "anything." > I can see a *disadvantage* in that out of the two leading users of LL > *now*, neither uses 255. I think Stuart was saying that Apple does use 255. But Microsoft does not. The debate here is over whether to codify Apple's change to the protocol. From owner-zeroconf@merit.edu Wed Mar 5 03: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 DAA21197 for ; Wed, 5 Mar 2003 03:06:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C8DBF91232; Wed, 5 Mar 2003 03:08:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0BDA91230; Wed, 5 Mar 2003 03:08:09 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8F26591230 for ; Wed, 5 Mar 2003 03:03:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5B7235DF3F; Wed, 5 Mar 2003 03:03:35 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 6FF075DE44 for ; Wed, 5 Mar 2003 03:03:34 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h2584Kaj013262; Wed, 5 Mar 2003 10:04:20 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h2584IRu013257; Wed, 5 Mar 2003 10:04:18 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: Oppose: LL29 Link-local sources should specify TTL=1 From: Mika Liljeberg To: Christian Huitema Cc: Ted Lemon , "John C. Welch" , Zeroconf In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046851458.8754.80.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 10:04:18 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 03:21, Christian Huitema wrote: > > I think we are arguing about how many needles can dance on the head of > > a pin - I don't see any way for an actual packet addressed to an > IPv4ll > > destination to stray significantly from where it belongs, and I > > definitely don't see a way to direct such a packet to a particular > > destination. > > Wrong. Source routes and tunnels come to mind easily. Easy to think of and easy to counter. The TTL=255 check doesn't protect against tunnel attacks and everybody who is concerned about security drops source routed packets anyway. MikaL From owner-zeroconf@merit.edu Wed Mar 5 03:42: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 DAA21875 for ; Wed, 5 Mar 2003 03:42:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DE05A91230; Wed, 5 Mar 2003 03:44:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1B3C9123C; Wed, 5 Mar 2003 03:44:13 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5076191230 for ; Wed, 5 Mar 2003 03:44:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 300875DF50; Wed, 5 Mar 2003 03:44:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 51A5E5DF3F for ; Wed, 5 Mar 2003 03:44:11 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h258iraj013395; Wed, 5 Mar 2003 10:44:53 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h258iplO013388; Wed, 5 Mar 2003 10:44:51 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 From: Mika Liljeberg To: Stuart Cheshire Cc: zeroconf@merit.edu In-Reply-To: <200303050302.h25327s26928@scv1.apple.com> References: <200303050302.h25327s26928@scv1.apple.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046853890.8760.121.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 10:44:51 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 05:02, Stuart Cheshire wrote: > Mika Liljeberg wrote: > > >- Due to recent decisions, a packet intended for the local link might > >have a mix of routable and LL addresses (any of the 4 combinations). > > > >- A proxy ARP router could be configured to recognize 169.254/16 as > >being on-link. This would allow configuration of LL addresses. > > > >The first point alone allows leakage > > No it doesn't. If you think it does, please describe an exact scenario > using LL-compliant hosts. (Any mention of non-compliant hosts here is a > red-herring, because we control neither what they do with packets, nor > what TTL they set.) You're right, it's unlikely that compliant nodes would knowingly send a LL packet to a router. A proxy ARP router is the more plausible scenario. I don't claim leakage would be rampant but configuration errors do happen and bugs do crop up. If we have to say something about the TTL (and I'd be quite happy not saying anything at all), setting TTL=1 sounds like the only even marginally useful thing to do. > When an entity is authorized to act on my behalf, it is a proxy. Proxy ARP does not require your authorization. Your point, I guess, is that you can fix your own router. Not everybody can. > >A LL destination address in a packet is good enough for me. > >Damned hard to send one from off-link. > > Hard, but not impossible. Security includes protecting against attacks > that are hard to do (but not necessarily against attacks that are > impossible to do). Sure. I just don't see a TTL=255 check helping any. LL addresses have no value as a secrity measure and people should not be bamboozled to think that they have. > >So here's a challenge for you: whip out your hacker toolbox and send me > >a packet that has a LL destination address. I guarantee you I'll never > >see it, much less get to check its TTL. > > Mika, defining a standard for the whole world is about more than what > works on YOUR network. Stuart, I could throw that comment back in your face, word for word, in the context of a proxy ARP router. I'll spare us that. My network is utterly insignificant, a mere example, but John would still have to cross "the whole world" to get here. > The question is not whether YOUR router will let in packets addressed to > 169.254/16, but whether ANY routers will advertently let in packets > addressed to 169.254/16. Unless you can categorically say no, for every > router in the world, there is a risk of attack. There's a non-zero probability that I will get hit in the head by a meteor but I don't go around wearing a hard hat. The truth of the matter is, we're like two salesmen planning to sell fridges to eskimos and we're arguing whether we should put in an ice box or leave more room for vegetables. MikaL From owner-zeroconf@merit.edu Wed Mar 5 04:47: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 EAA23031 for ; Wed, 5 Mar 2003 04:47:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AD51191241; Wed, 5 Mar 2003 04:49:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 739A691299; Wed, 5 Mar 2003 04:49:36 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0A39D91241 for ; Wed, 5 Mar 2003 04:49:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id ECD7E5DF42; Wed, 5 Mar 2003 04:49:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 9A7BB5DDFC for ; Wed, 5 Mar 2003 04:49:34 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21342 for ; Wed, 5 Mar 2003 02:49:33 -0700 (MST) Received: from sun.com (vpn-129-159-0-196.EMEA.Sun.COM [129.159.0.196]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h259nUl07538 for ; Wed, 5 Mar 2003 10:49:30 +0100 (MET) Message-ID: <3E65C7BD.60100@sun.com> Date: Wed, 05 Mar 2003 10:47:41 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu Subject: [LL29] Link-local sources should specify TTL=1 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 [WG chair hat off] I accept LL29 with Christian's modifications: TTL SHOULD be 1. If an application explicitely sets the TTL to some other value, this should be used. (No mention of processing on the basis of the TTL of received packets is made.) The reasons for my preference of this alternative are (focussing on new arguments, not yet presented on the list): - Applications have the ability to set this value and interpret it for received packets. Since this is available today using standard interfaces, requiring the TTL to be set to 255 would potentially *break* existing applications. Hypocrates said "Do no harm." (This is a reason to reject [LL3]) - The suggestion in LL3 that 'eventually' filtering on the basis of received packets having a TTL=255 cannot be carried out today because of the prevelance of hosts which do not do this. Those hosts which do this filtering are problematic for this reason. There is no provision for when 'eventually' will occur. Thus, the provision complicates the protocol specification but adds no immediate value. (These are reasons to reject [LL3]). - There are scenarios in which a host can have a routable address and receive packets from an on-link host with a link-local address. This host can then forward the location (in a reference, referral, URI, etc) off-link. It is then possible for the off-link host to use this link-local address as a destination address. If the TTL for this is set to 255, the packet will be forwarded along the default path (probably), unless routers have been explicitely configured to not forward packets in the 169.254/16 prefix. Since many such routers exist and will continue to exist, this means that LL traffic with a TTL != 1 will escape off-link. (This is a reason to reject [LL3] and [LL21]). - A packet sent with a TTL=255, link-local source address to a non-link-local multicast address will be forwarded by a router which supports multicast routing and does not know to decline to forward packets with a 169.254/16 source address prefix. This will result in (given the nature of dense-mode multicast routing protocols) a flood of link-local source addressed packets to *all links* in the network, at least for the first such packet trans- mitted. (This is a very good reason to reject LL3 and LL21.) Erik From owner-zeroconf@merit.edu Wed Mar 5 05:09:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23474 for ; Wed, 5 Mar 2003 05:09:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 591819125B; Wed, 5 Mar 2003 05:11:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26AF891299; Wed, 5 Mar 2003 05:11:00 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 392979125B for ; Wed, 5 Mar 2003 05:10:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 29D8B5DE78; Wed, 5 Mar 2003 05:10:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id EED275DDFC for ; Wed, 5 Mar 2003 05:10:58 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 087745991F for ; Wed, 5 Mar 2003 10:11:00 +0000 (GMT) Message-ID: <017b01c2e2ff$83fc40c0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" Subject: LL3, LL21 and potential new issue Date: Wed, 5 Mar 2003 10:10:55 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit One thing that has become clear in discussions of TTL is that Multicast packets are potentially subject to different conditions from unicast in that the sender has no direct control over whether they are routed. This makes arguments for setting TTL=1 stronger for Multicast packets and potentially different rules should apply for multicast. However, there could be other ways around this issue: We could disallow or discourage packets with a LL source address being sent to any multicast destination address outside the 224.0.0/24 link-local scoped multicast prefix. This would seem very much in keeping with the principle of LL. I have been unable in a quick search to find the RFC which defines this scope however it is mentioned in rfc2365 and elsewhere. Philip From owner-zeroconf@merit.edu Wed Mar 5 05:24: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 FAA24061 for ; Wed, 5 Mar 2003 05:24:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7EFA791299; Wed, 5 Mar 2003 05:26:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C6FE9129C; Wed, 5 Mar 2003 05:26:12 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4CCC391299 for ; Wed, 5 Mar 2003 05:26:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 29F8E5DF59; Wed, 5 Mar 2003 05:26:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id EFB3F5DEDB for ; Wed, 5 Mar 2003 05:26:10 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id D10065991F for ; Wed, 5 Mar 2003 10:26:08 +0000 (GMT) Message-ID: <018501c2e301$a1aa24f0$131010ac@aldebaran> From: "Philip Nye" To: References: Subject: LL24 Date: Wed, 5 Mar 2003 10:26:06 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree in an academic sense with Subrata that the requirement is not really that addresses be picked in a Pseudo-Random fashion. The requirement is that hosts pick addresses using an algorithm which minimises the chance of conficts in the first place and which prevents the chance of two hosts moving through the same sequence in lock-step altogether. However, I am not convinced at all by any of the other algorithms presented. Furthermore, in the absence of a demonstrably better algorithm, weakening the requirement is likely to lead to more use of half-baked algoithms which have not been properly analysed. The document describes the issues adequately such that the intent is clear. There is a MUST statement which could be used to reject any "bad" pseudo-random algorithm. And the document could always be updated should a clearly superior algorithm be presented. I therefore reject LL24. Philip From owner-zeroconf@merit.edu Wed Mar 5 05:28: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 FAA24161 for ; Wed, 5 Mar 2003 05:28:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A01689129C; Wed, 5 Mar 2003 05:30:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A5579129D; Wed, 5 Mar 2003 05:30:13 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C802D9129C for ; Wed, 5 Mar 2003 05:30:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF50A5DF65; Wed, 5 Mar 2003 05:30:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 227585DEDB for ; Wed, 5 Mar 2003 05:30:10 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id A25525996E for ; Wed, 5 Mar 2003 10:30:11 +0000 (GMT) Message-ID: <019101c2e302$3260ce40$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" Subject: LL25 Date: Wed, 5 Mar 2003 10:30:09 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I reject LL25. The meaning of sending a packet for forwarding has been extensively discussed. I might accept ammended wording which more explicitly stated that LL packets muts only be sent to their ultimate destination on the link and not to any other address, but I cannot accpet dropping this requirement altogether as this item would do. Philip From owner-zeroconf@merit.edu Wed Mar 5 05:33:59 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24246 for ; Wed, 5 Mar 2003 05:33:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 84C249129D; Wed, 5 Mar 2003 05:35:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 544749129F; Wed, 5 Mar 2003 05:35:55 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 569F09129D for ; Wed, 5 Mar 2003 05:35:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 37D5B5DF67; Wed, 5 Mar 2003 05:35:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 6FE535DF64 for ; Wed, 5 Mar 2003 05:35:44 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h25AZAQ24093; Wed, 5 Mar 2003 17:35: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 h25AYQO09308; Wed, 5 Mar 2003 17:34:27 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: Subrata Goswami , zeroconf@merit.edu Subject: Re: LL24: Another (distributed) way to get an LLv4 address. In-Reply-To: <3E64E871.1050006@sun.com> References: <3E64E871.1050006@sun.com> <004301c2e26b$163930a0$0200a8c0@SGOSWAMIPCL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Mar 2003 17:34:26 +0700 Message-ID: <9306.1046860466@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 04 Mar 2003 18:54:57 +0100 From: Erik Guttman Message-ID: <3E64E871.1050006@sun.com> | A distributed counter algorithm is a 'good idea' (perhaps), but | what IESG comment does it address? What burning problem does | it solve? Erik, I'd suggest abandoning that approach. This doc is clearly getting enough revisions done to it, that it is going to need another WG last call, and then IETF last call (if it got as far as one of those before). While it would, I'm sure, be annoying to simply revisit ever decision that has ever been made, closing off all new suggestions isn't a good thing to do. If someone makes a suggestion, and you rule it out of order, as not being a response to an IESG comment, or not solving something currently considered to be a burning question, you're simply inviting IETF last call arguments. If, at that stage, someone can say "the suggestion X was not considered by the working group" then the IESG should return the doc to the WG to have the suggestion considered. If to that you (the WG) can reply "the suggestion was considered, and rejected" then all is fine. But if the answer is "we didn't want to look at that, it was too late", then the WG will have a problem. It is not yet too late for anything at all. If whatever the issue is isn't considered useful by the WG, then it can quickly be disposed of, without being ruled out of order. kre From owner-zeroconf@merit.edu Wed Mar 5 05:34: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 FAA24269 for ; Wed, 5 Mar 2003 05:34:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A864D9129F; Wed, 5 Mar 2003 05:36:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75DAF912A0; Wed, 5 Mar 2003 05:36:41 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 929509129F for ; Wed, 5 Mar 2003 05:36:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8161A5DF67; Wed, 5 Mar 2003 05:36:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 539D35DF65 for ; Wed, 5 Mar 2003 05:36:40 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id DCD5F5991F for ; Wed, 5 Mar 2003 10:36:41 +0000 (GMT) Message-ID: <019d01c2e303$1af64770$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: Subject: LL7 Date: Wed, 5 Mar 2003 10:36:39 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I am not sure that I understand the issue. However, since the requested change is "no change", I feel I can safely support it. Philip From owner-zeroconf@merit.edu Wed Mar 5 05:39:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24348 for ; Wed, 5 Mar 2003 05:39:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DF7B4912A0; Wed, 5 Mar 2003 05:41:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8E98912A1; Wed, 5 Mar 2003 05:41:17 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B566F912A0 for ; Wed, 5 Mar 2003 05:41:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id A81F65DF6A; Wed, 5 Mar 2003 05:41:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 7ADA45DEDB for ; Wed, 5 Mar 2003 05:41:16 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id EFDA9598BF for ; Wed, 5 Mar 2003 10:41:17 +0000 (GMT) Message-ID: <01a601c2e303$bf82c2a0$131010ac@aldebaran> From: "Philip Nye" To: References: Subject: [LL9] Introduction to make it clear this is not a replacement for a DHCP assigned address Date: Wed, 5 Mar 2003 10:41:15 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have no problem in principle with this issue but it does not indicate where the proposed text is intended to go and whether it is an addition or replacement. I would also suggest making the second sentence stronger and replacing "is not suitable" with "can not work". Philip From owner-zeroconf@merit.edu Wed Mar 5 05:44: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 FAA24526 for ; Wed, 5 Mar 2003 05:44:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AE03E912A1; Wed, 5 Mar 2003 05:46:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8ABC912A3; Wed, 5 Mar 2003 05:46:21 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 597BB912A1 for ; Wed, 5 Mar 2003 05:46:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 778355DF6A; Wed, 5 Mar 2003 05:45:35 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id D9F615DEDB for ; Wed, 5 Mar 2003 05:45:33 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h25AjRQ02141; Wed, 5 Mar 2003 17:45:28 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h25AjHO09498; Wed, 5 Mar 2003 17:45:19 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: "Zeroconf" Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 In-Reply-To: <200303042322.h24NMss28572@scv1.apple.com> References: <200303042322.h24NMss28572@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Mar 2003 17:45:17 +0700 Message-ID: <9496.1046861117@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 4 Mar 2003 15:22:53 -0800 From: Stuart Cheshire Message-ID: <200303042322.h24NMss28572@scv1.apple.com> | TTL=1 stops outgoing packets escaping. | TTL=255 lets you *detect* incoming errant packets. | The question is (since we can't do both), which is more important? No, the question is, is either important. My answer is no, neither one achieves anything worth having. That is, do neither. While it certainly is possible for (from a conforming host) packets to escape the lan, if the TTL starts greater than 1 (assuming routers that know nothing of LL of course, a LL knowledgeable router should block it) the scenarios where this can happen are quite rare, and the harm that actually occurs is infinitesimal, so requiring TTL=1 achieves nothing worth having. I agree with your argument there (though you keep missing the case of a packet sent from 169.254.56.78 to 10.1.2.3 with a router set to proxy-arp for (only) 10/8 in your analysis of the proxy arp case). The ability to detect errant packets is similarly useless in general. You keep on citing that ability as a feature, but you have yet to give a reason how it ever achieves anything (in general). If protocols like LLMR see a benefit in TTL=255, they're free to specify that. That's how it should be, it should not be specified for LL in general. kre From owner-zeroconf@merit.edu Wed Mar 5 06:02: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 GAA24911 for ; Wed, 5 Mar 2003 06:02:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C244E91266; Wed, 5 Mar 2003 06:04:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F26E8912A2; Wed, 5 Mar 2003 06:04:11 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D62FF91266 for ; Wed, 5 Mar 2003 06:04:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id BE1F05DF6C; Wed, 5 Mar 2003 06:04:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 4882A5DF6B for ; Wed, 5 Mar 2003 06:04:09 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h25B3eQ15673; Wed, 5 Mar 2003 18:03:40 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h25B3YO09527; Wed, 5 Mar 2003 18:03:34 +0700 (ICT) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: [LL29] Link-local sources should specify TTL=1 [LL21] In-Reply-To: <3E65C7BD.60100@sun.com> References: <3E65C7BD.60100@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Mar 2003 18:03:34 +0700 Message-ID: <9525.1046862214@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 05 Mar 2003 10:47:41 +0100 From: Erik Guttman Message-ID: <3E65C7BD.60100@sun.com> | Hypocrates said "Do no harm." (This is a reason to reject [LL3]) I don't think we're doing medicine here, but I agree with the reasoning that came before "Hypocrates said". | - The suggestion in LL3 that 'eventually' filtering on the basis And this. | - There are scenarios in which a host can have a routable address | and receive packets from an on-link host with a link-local address. [etc]. That's true, but your scenario for how it would affect anything doesn't make much sense. This can happen, but from conforming hosts, it isn't going to happen often. As Stuart said in a message several days ago, if this was a real problem, we'd have noticed it already - hosts doing LL with a TTL > 1 (much > 1) have been around for years, and yet we're not being deluged by complaints about escaping packets (the complaints about hosts getting LL addresses at all, which the WG has been willing to write off as irrelevant (see LL2), dawrf the complaints about escaped LL packets). But in any case ... | Since | many such routers exist and will continue to exist, this means that | LL traffic with a TTL != 1 will escape off-link. (This is a reason | to reject [LL3] and [LL21]). The "This is a reason" doesn't follow in this case. You have demonstrated a scenario that can happen, rarely, but not demonstrated any reason why we should care if it does. | - A packet sent with a TTL=255, link-local source address to a | non-link-local multicast address will be forwarded by a router | which supports multicast routing and does not know to decline to | forward packets with a 169.254/16 source address prefix. This might happen, but will also be very rare. Remember that multicast is forwarded using reverse path forwarding. There has to be a route to the source address of the packet for the multicast to be forwarded. Unless the router is doing LL addressing (either knowing about the magic of LL, or explicitly configured to have LL addresses on a link) then it cannot have a route to the LL prefix - we have already agreed (or certainly will) that the LL prefix must not be included in routing protocols. If the router is LL aware, then it won't forward the packet anyway. If it isn't, but has been configured with an LL address range for some reason, it might - but if it was configured that way, without also having filtering configured to block LL packets, then we have a badly configured router that should be fixed. To actually do any real harm, we'd need lots of similarly badly configured routers, all connected to each other, with a particularly bizarre set of routes installed. This is not likely enough to bother considering. Hence... | (This is a very good reason to reject LL3 and LL21.) No, it isn't. To reject LL21 you'd really have to show some particular advantage to be gained by all LL traffic by setting a particular TTL value. The only two attempts to do that fail to achieve any detectable benefits. We have both camps here, the TTL=1 and the TTL=255 camps, each demolishing the other's claimed benefits, but neither is willing to accept that their own case is similarly being demolished by the others. Neither is making any real positive arguments that hold up in favour of their proposed solution. kre From owner-zeroconf@merit.edu Wed Mar 5 06:12:39 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25024 for ; Wed, 5 Mar 2003 06:12:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 22B43912A2; Wed, 5 Mar 2003 06:14:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E04F0912A3; Wed, 5 Mar 2003 06:14:34 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC871912A2 for ; Wed, 5 Mar 2003 06:14:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id C34E95DF75; Wed, 5 Mar 2003 06:14:33 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 943D95DF74 for ; Wed, 5 Mar 2003 06:14:33 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 18512598A5 for ; Wed, 5 Mar 2003 11:14:34 +0000 (GMT) Message-ID: <01fb01c2e308$653b3de0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <1046822987.8760.42.camel@devil> Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Date: Wed, 5 Mar 2003 11:14:31 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Mika Liljeberg" > So here's a challenge for you: whip out your hacker toolbox and send me > a packet that has a LL destination address. I guarantee you I'll never > see it, much less get to check its TTL. So here is a scenario: Link A Link B +--------+Gateway-A+--------+Gateway-B+--> to the Internet Gateway-A is the default gateway (for global traffic) on link A Gateway-B ditto for Link B If these gateways are not LL aware they will simply forward LL packets which reach them on towards the Internet. This scenario must be quite common. Now suppose that Link A and Link B have LL hosts on them. The only additional requirement for a malicious host on Link A to send a packet to a LL destination on Link B is that either Gateway-A or Gateway-B has been configured with a route which directs the LL prefix onto Link B. While this might be regarded as a misconfiguration, it is not a huge one and would likely go unnoticed. For example one or other gateway might be a general purpose machine which a user has added a route to precicely so that they can participate in LL exchanges on Link B. Furthermore additional Gateways and networks can be interposed between Link A and Link B without changing the basic principle but making the attack more remote. Philip From owner-zeroconf@merit.edu Wed Mar 5 06:40: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 GAA27186 for ; Wed, 5 Mar 2003 06:40:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 590AA9120D; Wed, 5 Mar 2003 06:41:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26D8391218; Wed, 5 Mar 2003 06:41:57 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1493C9120D for ; Wed, 5 Mar 2003 06:41:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id ECE395DF77; Wed, 5 Mar 2003 06:41:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 39A2E5DF76 for ; Wed, 5 Mar 2003 06:41:55 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h25Bgaaj014084; Wed, 5 Mar 2003 13:42:36 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h25BgX0K014074; Wed, 5 Mar 2003 13:42:33 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 From: Mika Liljeberg To: Philip Nye Cc: Zeroconf Working Group In-Reply-To: <01fb01c2e308$653b3de0$131010ac@aldebaran> References: <1046822987.8760.42.camel@devil> <01fb01c2e308$653b3de0$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046864552.8754.150.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 13:42:33 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 13:14, Philip Nye wrote: > > From: "Mika Liljeberg" > > So here's a challenge for you: whip out your hacker toolbox and send me > > a packet that has a LL destination address. I guarantee you I'll never > > see it, much less get to check its TTL. > > So here is a scenario: > > Link A Link B > +--------+Gateway-A+--------+Gateway-B+--> to the Internet > > > Gateway-A is the default gateway (for global traffic) on link A > Gateway-B ditto for Link B > > If these gateways are not LL aware they will simply forward LL packets which > reach them on towards the Internet. > > This scenario must be quite common. Granted. I could use that same scenario to argue for TTL=1. :) > Now suppose that Link A and Link B have LL hosts on them. > > The only additional requirement for a malicious host on Link A to send a > packet to a LL destination on Link B is that either Gateway-A or Gateway-B > has been configured with a route which directs the LL prefix onto Link B. > > While this might be regarded as a misconfiguration, it is not a huge one and > would likely go unnoticed. For example one or other gateway might be a > general purpose machine which a user has added a route to precicely so that > they can participate in LL exchanges on Link B. Well, it *is* misconfiguration. I don't deny that this could happen but I don't think it very likely. Nodes on Link B should not rely on LL addresses having any security properties any more than they rely on routable addresses. LL addresses don't have, and don't need, any special magic. > > Furthermore additional Gateways and networks can be interposed between Link > A and Link B without changing the basic principle but making the attack more > remote. And also more unlikely. I sincerily doubt my ISP or their carriers would be using LL addresses on their backbone networks, much less misconfigure their routers the way you suggest. MikaL From owner-zeroconf@merit.edu Wed Mar 5 06:57: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 GAA27845 for ; Wed, 5 Mar 2003 06:57:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 96F2391218; Wed, 5 Mar 2003 06:59:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66C6F9121C; Wed, 5 Mar 2003 06:59:09 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 66C6C91218 for ; Wed, 5 Mar 2003 06:59:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4E7F35DF7F; Wed, 5 Mar 2003 06:59:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id C96965DF7E for ; Wed, 5 Mar 2003 06:59:06 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h25BwxQ26412; Wed, 5 Mar 2003 18:58: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 h25BwgO09851; Wed, 5 Mar 2003 18:58:44 +0700 (ICT) From: Robert Elz To: "Philip Nye" Cc: "Zeroconf Working Group" Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 In-Reply-To: <01fb01c2e308$653b3de0$131010ac@aldebaran> References: <01fb01c2e308$653b3de0$131010ac@aldebaran> <1046822987.8760.42.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Mar 2003 18:58:42 +0700 Message-ID: <9849.1046865522@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 5 Mar 2003 11:14:31 -0000 From: "Philip Nye" Message-ID: <01fb01c2e308$653b3de0$131010ac@aldebaran> | The only additional requirement for a malicious host on Link A to send a | packet to a LL destination on Link B is that either Gateway-A or Gateway-B | has been configured with a route which directs the LL prefix onto Link B. Yes, in appropriate circumstances, a malicious host would be able to send a packet like that. Requiring TTL=1 won't help in the slightest, the malicious host will just ignore that requirement (even send with TTL=2 perhaps, so the recipient loots to have received a packet with TTL=1). Requiring TTL=255 allows it to be detected. That's fine. It also means that the target won't be able to interoperate at LL level with the majority of (current) LL hosts that exist. | Furthermore additional Gateways and networks can be interposed between Link | A and Link B without changing the basic principle but making the attack more | remote. What attack? All you have so far is packets from a bogus source address arriving at a host. That the source address, or the address of the target host, might be LL is irrelevant surely? If sending packets to a host is to start to be considered as an attack, then we're all doomed. Even if the source address is something to which no reply can successfully be sent. If you're one of the (very few) people (I hope) who believes that a host ought to be able to be "protected" by having only a LL address, then please forget it - that kind of protection is useless. If a host cannot protect itself (or will not) the only hope it has is to have a (string enough) firewall between it and all possible attack sources (including hosts on its own link - which can mean putting it on a link of its own sometimes). Relying upon some mystical properties of addresses to protect a host is folly, and we should not be doing anything that even hints this can possibly work. kre From owner-zeroconf@merit.edu Wed Mar 5 07:25: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 HAA28448 for ; Wed, 5 Mar 2003 07:25:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 38EFA9121C; Wed, 5 Mar 2003 07:27:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02AE69121D; Wed, 5 Mar 2003 07:27:03 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BC83F9121C for ; Wed, 5 Mar 2003 07:27:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id A72AD5DF81; Wed, 5 Mar 2003 07:27:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by segue.merit.edu (Postfix) with ESMTP id 2B7E05DF76 for ; Wed, 5 Mar 2003 07:27:01 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e32.co.us.ibm.com (8.12.8/8.12.2) with ESMTP id h25CQeaI019616; Wed, 5 Mar 2003 07:26:40 -0500 Received: from cichlid.adsl.duke.edu ([9.65.209.0]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h25CQv49140650; Wed, 5 Mar 2003 05:26:57 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h25COFR02710; Wed, 5 Mar 2003 07:24:15 -0500 Message-Id: <200303051224.h25COFR02710@cichlid.adsl.duke.edu> To: "Philip Nye" Cc: "Zeroconf Working Group" Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 In-Reply-To: Message from philip@engarts.com of "Wed, 05 Mar 2003 11:14:31 GMT." <01fb01c2e308$653b3de0$131010ac@aldebaran> Date: Wed, 05 Mar 2003 07:24:15 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk "Philip Nye" writes: > > From: "Mika Liljeberg" > > So here's a challenge for you: whip out your hacker toolbox and send me > > a packet that has a LL destination address. I guarantee you I'll never > > see it, much less get to check its TTL. > So here is a scenario: > Link A Link B > +--------+Gateway-A+--------+Gateway-B+--> to the Internet > Gateway-A is the default gateway (for global traffic) on link A > Gateway-B ditto for Link B > If these gateways are not LL aware they will simply forward LL > packets which reach them on towards the Internet. Agreed. Packets sent to a LL destination could get sucked up by the default route (of such packets were sent to the router). > This scenario must be quite common. Sure. > Now suppose that Link A and Link B have LL hosts on them. > The only additional requirement for a malicious host on Link A to send a > packet to a LL destination on Link B is that either Gateway-A or Gateway-B > has been configured with a route which directs the LL prefix onto > Link B. This is clearly a broken configuration and will result in LL in general not working. I.e., two nodes, both on Link A, both using LL addresses, won't be able to communicate. The Router will grab their traffic and forward it to the wrong place. Right? > While this might be regarded as a misconfiguration, it is not a huge one and > would likely go unnoticed. Even though normal LL communication also doesn't work? Or are you assuming nodes A & B will send directly to each other because they understand LL? Well, if so, how is the router intercepting traffic between them and forwarding it to the wrongb place? > For example one or other gateway might be a general purpose machine > which a user has added a route to precicely so that they can > participate in LL exchanges on Link B. > Furthermore additional Gateways and networks can be interposed between Link > A and Link B without changing the basic principle but making the attack more > remote. I don't doubt there are pathalogical cases where one can arrange to have packets destined to a LL address forwarded across the internet to a target network. Christian mentions tunneling, for example. Well, tunneling breaks ingress filtering too. Maybe what this document should do is add a section that talks about tunneling and how tunneled packets that contain LL addresses should be not forwarded (ever) and/or even discarded as a bad idea and/or potential security vulnerability. But I think in general, arranging to have packets for LL destinations improperly delivered to links multiple hops away will be hard to do and thus does not open up a significant vulnerability. Or where it does, the vulnerability isn't due to LL, it's with the mechanism that is being exploited, which probably also allows attacks from normal addresses. E.g., source routing can allow packets to be delivered in circumvention of policy for non LL addresses too. So, if folk really think that the TTL=255 check on reciept prevents off-link attacks, please be very specific about how they work, and how these are _new_ vulnerabilities that are somehow different or worse than when non-LL addresses are used. Up to now, I haven't seen a clear example of an attack from off-link senders to a LL address for which the best defense is the TTL=255 check. Thomas From owner-zeroconf@merit.edu Wed Mar 5 07:28:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28516 for ; Wed, 5 Mar 2003 07:28:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 22E7F9121D; Wed, 5 Mar 2003 07:30:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2D1D91229; Wed, 5 Mar 2003 07:29:59 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA7709121D for ; Wed, 5 Mar 2003 07:29:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id A89795DF84; Wed, 5 Mar 2003 07:29:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 2C1D25DF83 for ; Wed, 5 Mar 2003 07:29:57 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h25CTjQ11937; Wed, 5 Mar 2003 19:29:46 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h25CTfO09895; Wed, 5 Mar 2003 19:29:43 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: Bernard Aboba , zeroconf@merit.edu Subject: Re: The IPv4ll draft updates RFC2131 In-Reply-To: <1046785713.1902.8.camel@devil> References: <1046785713.1902.8.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Mar 2003 19:29:41 +0700 Message-ID: <9893.1046867381@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 04 Mar 2003 15:48:34 +0200 From: Mika Liljeberg Message-ID: <1046785713.1902.8.camel@devil> | Presumably we should be talking about routes here. Configuring and | unconfiguring addresses is a side issue. Actually, it isn't, it is the primary issue. Routing, as you showed, isn't difficult to handle, given a suitable address to use, implementations will normally be able to come up with an appropriate way to use it. The complexity all seems to relate to which addresses the host should use, and when. If it abandons a routable address (using LL instead) then in many cases that will needlessly cause connections to fail, and new connections to be unable to be made (despite the rationale of this WG, in the wild, nodes rarely ever want to actually communicate with something on the same link). On the other hand, if a node persists on using a routable address when it shouldn't (say, just because its lease is still valid) then it won't be able to communicate with anyone at all (be even worse than having just an LL address). There is nothing in 2131 that mandates or even recommends that a node fall into either of those traps however - it would be surprising if there were. That some common implementations have gone full bore in one of those directions or the other to me just means lack of thought at the implementation level. I agree with Bernard ... So in practice, I think we may be able to come up with a workable solution. I believe we can - all that's needed is for implementors to be more intelligent when choosing whether to keep using an existing routable address (from a DHCP lease, or otherwise) and when to abandon that and fall back to LL addresses. Neither of the extremes "I might be on a new link, and there is no DHCP server responding to reassure me I'm not" nor "my lease is still valid, no-one is telling me not to use it" are appropriate. What's needed is some rational validation of the efficacy of the lease (which has not expired) before deciding to continue using it. If the address looks like it should still work (which is likely if anyone responds to an ARP request for the default router, and no-one replies to an ARP request for the host's own address - this at least implies that the host is on a LAN with compatible addresses, and isn't usurping someone else's address - even if the address technically belongs elsewhere). On the other hand, if someone else claims the address I think I should be able to use, or nothing is answering at the address I believe is my default gateway, then most likely the host shouldn't be using the address, and should fall back to LL (if there is no default router, it has little to use). The actual mechanisms that the hosts use can be tuned with experience. They don't need to be standardised - no harm comes if different hosts use different methods to work out whether an address is still functional or not. No updates to 2131 are needed for any of this. Updates to some (client) implementations of 2131 may well be, but that's a completely different thing. kre From owner-zeroconf@merit.edu Wed Mar 5 07:31: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 HAA28595 for ; Wed, 5 Mar 2003 07:31:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3CC2291229; Wed, 5 Mar 2003 07:33:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E394991250; Wed, 5 Mar 2003 07:33:15 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 79A8991229 for ; Wed, 5 Mar 2003 07:33:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 581995DF76; Wed, 5 Mar 2003 07:33:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by segue.merit.edu (Postfix) with ESMTP id E32DA5DF6C for ; Wed, 5 Mar 2003 07:32:59 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e35.co.us.ibm.com (8.12.8/8.12.2) with ESMTP id h25CWwJn032138; Wed, 5 Mar 2003 07:32:59 -0500 Received: from cichlid.adsl.duke.edu ([9.65.209.0]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h25CWv49110174; Wed, 5 Mar 2003 05:32:58 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h25CUGk02981; Wed, 5 Mar 2003 07:30:16 -0500 Message-Id: <200303051230.h25CUGk02981@cichlid.adsl.duke.edu> To: "Christian Huitema" Cc: "Zeroconf" Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 In-Reply-To: Message from huitema@windows.microsoft.com of "Tue, 04 Mar 2003 17:21:47 PST." Date: Wed, 05 Mar 2003 07:30:15 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk "Christian Huitema" writes: > > I think we are arguing about how many needles can dance on the head of > > a pin - I don't see any way for an actual packet addressed to an > IPv4ll > > destination to stray significantly from where it belongs, and I > > definitely don't see a way to direct such a packet to a particular > > destination. > Wrong. Source routes and tunnels come to mind easily. What new vulnerabilities occur here that aren't already present with non-LL addresses? If there are specific new vulnerabilities related to LL, we need to at least document them and possibly also try to mitigate them. For tunnels, it seems to be that this document might just want to point out that when LL traffic pops out of a tunnel, normal forwarding rules apply, and they should not be forwarded. We might also want to say that by default, LL traffic should not be tunneled and should be discared on receipt. Thomas From owner-zeroconf@merit.edu Wed Mar 5 07:37: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 HAA28719 for ; Wed, 5 Mar 2003 07:37:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F375E91250; Wed, 5 Mar 2003 07:39:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAFEF91251; Wed, 5 Mar 2003 07:39:36 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BD33E91250 for ; Wed, 5 Mar 2003 07:39:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id A67315DF81; Wed, 5 Mar 2003 07:39:35 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by segue.merit.edu (Postfix) with ESMTP id 2DA275DF76 for ; Wed, 5 Mar 2003 07:39:35 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e33.co.us.ibm.com (8.12.8/8.12.2) with ESMTP id h25CdUGA045950; Wed, 5 Mar 2003 07:39:31 -0500 Received: from cichlid.adsl.duke.edu ([9.65.209.0]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h25CdT49143758; Wed, 5 Mar 2003 05:39:30 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h25Calm02999; Wed, 5 Mar 2003 07:36:48 -0500 Message-Id: <200303051236.h25Calm02999@cichlid.adsl.duke.edu> To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 In-Reply-To: Message from cheshire@apple.com of "Tue, 04 Mar 2003 19:02:07 PST." <200303050302.h25327s26928@scv1.apple.com> Date: Wed, 05 Mar 2003 07:36:47 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Stuart Cheshire writes: > >A LL destination address in a packet is good enough for me. > >Damned hard to send one from off-link. > Hard, but not impossible. Security includes protecting against attacks > that are hard to do (but not necessarily against attacks that are > impossible to do). Security is about risk vs. cost. One protects against attacks where the cost of the protection is a prudent investment compared with the potential damages associated with the attack (and it's likelyhood of being exploited). I am still trying to understand what attacks would be opened up if the TTL=255 check on receipt were not done. So far, I haven't seen a clear example that raises alarm bells in my head. It would be good if folk could provide clear examples, rather than using general arguments and handwaving. Right now, I don't know that there is even agreement in the WG on what the actual risks/vulnerabilities are. Thomas From owner-zeroconf@merit.edu Wed Mar 5 07:41:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28800 for ; Wed, 5 Mar 2003 07:41:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7D6C991251; Wed, 5 Mar 2003 07:42:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D0D091253; Wed, 5 Mar 2003 07:42:59 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 32E0991251 for ; Wed, 5 Mar 2003 07:42:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0DBB35DF83; Wed, 5 Mar 2003 07:42:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 0E1EF5DF82 for ; Wed, 5 Mar 2003 07:42:57 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h25Chdaj015056; Wed, 5 Mar 2003 14:43:39 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h25ChcZF015053; Wed, 5 Mar 2003 14:43:38 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: The IPv4ll draft updates RFC2131 From: Mika Liljeberg To: Robert Elz Cc: Bernard Aboba , zeroconf@merit.edu In-Reply-To: <9893.1046867381@munnari.OZ.AU> References: <1046785713.1902.8.camel@devil> <9893.1046867381@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046868217.14873.15.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 14:43:37 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 14:29, Robert Elz wrote: > Date: 04 Mar 2003 15:48:34 +0200 > From: Mika Liljeberg > Message-ID: <1046785713.1902.8.camel@devil> > > | Presumably we should be talking about routes here. Configuring and > | unconfiguring addresses is a side issue. > > Actually, it isn't, it is the primary issue. > > Routing, as you showed, isn't difficult to handle, given a suitable > address to use, implementations will normally be able to come up with > an appropriate way to use it. > > The complexity all seems to relate to which addresses the host should > use, and when. If it abandons a routable address (using LL instead) > then in many cases that will needlessly cause connections to fail, and > new connections to be unable to be made (despite the rationale of this > WG, in the wild, nodes rarely ever want to actually communicate with > something on the same link). > > On the other hand, if a node persists on using a routable address when > it shouldn't (say, just because its lease is still valid) then it won't > be able to communicate with anyone at all (be even worse than having > just an LL address). I think you missed the main point, which was that the fallback onlink default route kicks in when the default gateway becomes unreachable. With the above routes, a node can just keep its routable address for as long as the lease time says and that same address can be used for all link-local communication. Validation of the address only has to be done on reconnection to a managed network. [I think there was an issue about ARPing for all addresses, but www.spybeam.org is unreachable at the moment, so I can't check.] MikaL From owner-zeroconf@merit.edu Wed Mar 5 07:46: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 HAA28898 for ; Wed, 5 Mar 2003 07:46:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 84BE991253; Wed, 5 Mar 2003 07:47:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E815791258; Wed, 5 Mar 2003 07:47:23 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D4B191253 for ; Wed, 5 Mar 2003 07:46:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4044A5DF85; Wed, 5 Mar 2003 07:46:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by segue.merit.edu (Postfix) with ESMTP id E78C15DF28 for ; Wed, 5 Mar 2003 07:45:59 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e35.co.us.ibm.com (8.12.8/8.12.2) with ESMTP id h25CjtJn049290; Wed, 5 Mar 2003 07:45:55 -0500 Received: from cichlid.adsl.duke.edu ([9.65.209.0]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h25Cjs49150516; Wed, 5 Mar 2003 05:45:54 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h25ChC803018; Wed, 5 Mar 2003 07:43:12 -0500 Message-Id: <200303051243.h25ChC803018@cichlid.adsl.duke.edu> To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 In-Reply-To: Message from cheshire@apple.com of "Tue, 04 Mar 2003 19:04:10 PST." <200303050304.h2534As28041@scv1.apple.com> Date: Wed, 05 Mar 2003 07:43:12 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Stuart Cheshire writes: > >And if all hosts (unless they have a particular purpose, as > >Christian proposed and I agreed) that intend link-local traffic > >were to set TTL=1, there would be no such traffic "out there" > >to leak in. > Malicious traffic "out there" may still leak in (and may be more > successful in doing so, because with a spec that says compliant hosts > must set TTL=1, there is less incentive for router vendors to think it > necessary put in rules to block incoming spoof LL traffic). We need to separate this into two cases. One, where the destination is LL. In those cases, it is not obvious to me how traffic will be routed to a particular remote link. Presumably, the remote link won't be injecting the LL prefix into routing protocols and advertising a route for that prefix... If the case at issue is LL source and non-LL destination, yes, I can see traffic being delivered to a remote link. But return traffic won't go back to the actual sender. This seems very similar to general IP address spoofing, where an intruder sends packets using a false source address. If this is the case, what new vulnerabilities are we introducing with LL and why is it critical that they closed off? (Also, in the case of non-LL and LL addressing being used in communication I don't think we can use the 255 check anyway, so I wonder if this is a Red Herring case?) > >There was a long thread about supposed security benefits of checking > >TTL=255, with the conclusion that no security claims were valid enough > >to continue that thread. > You are mistaken. The (tentative) conclusion was that there were small > but non-zero benefits to checking TTL=255. Some would say "epsilon" benefit, that is, so close to 0 as to not be worth mentioning. > If this conclusion is not agreed, we may need to re-open the debate > concerning whether the security benefit is zero or non-zero. > I strongly doubt that any debate concerning the precise magnitude of the > non-zero security benefit will lead to any consensus. The question that the group needs to answer is whether the benefit is high enough to require something like the TTL=255 check. And the question is not just about security. E.g., we know that implementing it today would result in non-interoperabilty with some deployed platforms. That is also something to be factored into the discussion. Thomas From owner-zeroconf@merit.edu Wed Mar 5 08:01:25 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29141 for ; Wed, 5 Mar 2003 08:01:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E1DC29125A; Wed, 5 Mar 2003 08:03:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 847CD91259; Wed, 5 Mar 2003 08:03:17 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3787B91268 for ; Wed, 5 Mar 2003 08:03:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id A85A25DF28; Wed, 5 Mar 2003 08:03:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 33ACA5DF87 for ; Wed, 5 Mar 2003 08:03:12 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h25BmJT11171; Wed, 5 Mar 2003 03:48:19 -0800 Date: Wed, 5 Mar 2003 03:48:19 -0800 (PST) From: Bernard Aboba To: Mika Liljeberg Cc: Robert Elz , Subject: Re: The IPv4ll draft updates RFC2131 In-Reply-To: <1046868217.14873.15.camel@devil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > With the above routes, a node can just keep its routable address for as > long as the lease time says and that same address can be used for all > link-local communication. Validation of the address only has to be done > on reconnection to a managed network. So how do we know if we're on a "managed network" if the DHCP server doesn't answer, and the previous gateway doesn't respond to an ARP request? If we take this advice, then the host would not obtain a new routable address until the lease time expires. Seems to me that it makes more sense to periodically attempt to obtain a routable address (and at less than 5 minute intervals, please). From owner-zeroconf@merit.edu Wed Mar 5 08:09:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29305 for ; Wed, 5 Mar 2003 08:09:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 194CF91259; Wed, 5 Mar 2003 08:10:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD1909125F; Wed, 5 Mar 2003 08:10:53 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB03091259 for ; Wed, 5 Mar 2003 08:10:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id A48015DF89; Wed, 5 Mar 2003 08:10:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 18B8C5DF84 for ; Wed, 5 Mar 2003 08:10:52 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h25Bp8t11325; Wed, 5 Mar 2003 03:51:08 -0800 Date: Wed, 5 Mar 2003 03:51:08 -0800 (PST) From: Bernard Aboba To: Robert Elz Cc: Mika Liljeberg , Subject: Re: The IPv4ll draft updates RFC2131 In-Reply-To: <9893.1046867381@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > Neither of the extremes "I might be on a new link, and there is no > DHCP server responding to reassure me I'm not" nor "my lease is > still valid, no-one is telling me not to use it" are appropriate. This is very good advice -- so much so that it probably should be in the draft. > What's needed is some rational validation of the efficacy of the > lease (which has not expired) before deciding to continue using it. > If the address looks like it should still work (which is likely if > anyone responds to an ARP request for the default router, and no-one > replies to an ARP request for the host's own address - this at > least implies that the host is on a LAN with compatible addresses, and > isn't usurping someone else's address - even if the address technically > belongs elsewhere). Yes, this seems sensible. > The actual mechanisms that the hosts use can be tuned with experience. > They don't need to be standardised - no harm comes if different hosts > use different methods to work out whether an address is still functional > or not. Given the problems with existing implementations, it seems to me that at least some advice is needed to achieve our goal of "doing no harm". > No updates to 2131 are needed for any of this. Updates to some (client) > implementations of 2131 may well be, but that's a completely different > thing. I agree. From owner-zeroconf@merit.edu Wed Mar 5 08:12:35 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29375 for ; Wed, 5 Mar 2003 08:12:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3C8CD9125F; Wed, 5 Mar 2003 08:14:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0205791260; Wed, 5 Mar 2003 08:14:29 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EA30A9125F for ; Wed, 5 Mar 2003 08:14:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id D81E15DF8B; Wed, 5 Mar 2003 08:14:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id C50475DF8A for ; Wed, 5 Mar 2003 08:14:27 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h25DFAaj015199; Wed, 5 Mar 2003 15:15:10 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h25DF8cN015193; Wed, 5 Mar 2003 15:15:08 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: The IPv4ll draft updates RFC2131 From: Mika Liljeberg To: Bernard Aboba Cc: Robert Elz , zeroconf@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046870108.14873.25.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 15:15:08 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 13:48, Bernard Aboba wrote: > > With the above routes, a node can just keep its routable address for as > > long as the lease time says and that same address can be used for all > > link-local communication. Validation of the address only has to be done > > on reconnection to a managed network. > > So how do we know if we're on a "managed network" if the DHCP server > doesn't answer, and the previous gateway doesn't respond to an ARP > request? If the DHCP server isn't responding, I would just go on using whatever configuration I have at the moment. If the gateway isn't responding, I would mark the default gateway route unreachable and fall back on the link-local default route. > If we take this advice, then the host would not obtain a new routable > address until the lease time expires. I wasn't suggesting this. A node should try to validate its configuration on reconnection (however that is detected). A node could use any number of means to decide when to try to connect to a DHCP server: media sense, sniffing the network, retransmissions every now and then. This is a simpler issue to solve. > Seems to me that it makes more sense to periodically attempt to obtain a > routable address (and at less than 5 minute intervals, please). This would be fine with me. MikaL From owner-zeroconf@merit.edu Wed Mar 5 08:37: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 IAA29910 for ; Wed, 5 Mar 2003 08:37:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 08A9791264; Wed, 5 Mar 2003 08:39:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA65B91268; Wed, 5 Mar 2003 08:39:28 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C27CC91264 for ; Wed, 5 Mar 2003 08:39:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id A19835DF90; Wed, 5 Mar 2003 08:39:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 579A65DF8C for ; Wed, 5 Mar 2003 08:39:27 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id E15845997B for ; Wed, 5 Mar 2003 13:39:25 +0000 (GMT) Message-ID: <001101c2e31c$a1b9e820$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <1046822987.8760.42.camel@devil> <01fb01c2e308$653b3de0$131010ac@aldebaran> <1046864552.8754.150.camel@devil> Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Date: Wed, 5 Mar 2003 13:39:22 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Mika Liljeberg" ... > > So here is a scenario: > > > > Link A Link B > > +--------+Gateway-A+--------+Gateway-B+--> to the Internet ... > Granted. I could use that same scenario to argue for TTL=1. :) I am not (yet) arguing any side of the TTL debate. I was simply pointing out that your assertion that it is hard to get a LL-destination packet onto the link from outside doesn't hold in some quite plausible circumstances. > I don't think it very likely. I disagree - this configuration seems quite likely. > And also more unlikely. I sincerily doubt my ISP or their carriers would > be using LL addresses on their backbone networks, much less misconfigure > their routers the way you suggest. I certainly didn't envisage ISPs doing this but it is just the sort of configuration which could very easily occur in a small organisation which does not have the resources to have a fully qualified geek administering their network. > From: "Robert Elz" > What attack? Attack was a loose term based on the fact that the packet was deliberately ("maliciously") sent in from off-link - I should obviously have used some other term. > From: "Thomas Narten" > This is clearly a broken configuration and will result in LL in > general not working. I.e., two nodes, both on Link A, both using LL > addresses, won't be able to communicate. The Router will grab their > traffic and forward it to the wrong place. Right? Wrong. The routers do not in general grab the traffic because it is not sent to them by properly behaved LL hosts. The issue will arise either if the source is not LL aware and just sends to the default route or if the source maliciously exploits the configuration. I daresay there are other scanarios too where it is very easy to get a packet with a LL destination, in from outside - especially from a nearby network. My point was just that this might not be the rarity that Mika was suggesting. Philip From owner-zeroconf@merit.edu Wed Mar 5 09:09:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00661 for ; Wed, 5 Mar 2003 09:09:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5F46791268; Wed, 5 Mar 2003 09:10:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2CDE39126C; Wed, 5 Mar 2003 09:10:56 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 18C9B91268 for ; Wed, 5 Mar 2003 09:10:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC1415DF98; Wed, 5 Mar 2003 09:10:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id F33265DF8F for ; Wed, 5 Mar 2003 09:10:53 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h25EBaaj015448; Wed, 5 Mar 2003 16:11:37 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h25EBZ7M015441; Wed, 5 Mar 2003 16:11:35 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: The IPv4ll draft updates RFC2131 From: Mika Liljeberg To: Bernard Aboba Cc: Robert Elz , zeroconf@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046873494.14850.36.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 16:11:34 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 13:51, Bernard Aboba wrote: > > Neither of the extremes "I might be on a new link, and there is no > > DHCP server responding to reassure me I'm not" nor "my lease is > > still valid, no-one is telling me not to use it" are appropriate. > > This is very good advice -- so much so that it probably should be in the > draft. So what am I missing? Why exactly is the latter statement not appropriate? Why should we try to second guess the lease time? If the lease is valid, the address is mine. I may not be in the right position in the network topology for it to work but, assuming I can't get a new routable address, why exactly should I stop using the old one? MikaL From owner-zeroconf@merit.edu Wed Mar 5 09:09: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 JAA00689 for ; Wed, 5 Mar 2003 09:09:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 19F1791275; Wed, 5 Mar 2003 09:11:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D9AC291284; Wed, 5 Mar 2003 09:11:14 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A73391275 for ; Wed, 5 Mar 2003 09:11:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5F1695DF9B; Wed, 5 Mar 2003 09:11:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by segue.merit.edu (Postfix) with ESMTP id E503E5DF99 for ; Wed, 5 Mar 2003 09:11:12 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e35.co.us.ibm.com (8.12.8/8.12.2) with ESMTP id h25EB2Jn073570; Wed, 5 Mar 2003 09:11:02 -0500 Received: from cichlid.adsl.duke.edu ([9.65.209.0]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.5) with ESMTP id h25EB15B145440; Wed, 5 Mar 2003 07:11:01 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h25E8IO04641; Wed, 5 Mar 2003 09:08:18 -0500 Message-Id: <200303051408.h25E8IO04641@cichlid.adsl.duke.edu> To: Bernard Aboba Cc: zeroconf@merit.edu Subject: Re: The IPv4ll draft updates RFC2131 In-Reply-To: Message from aboba@internaut.com of "Tue, 04 Mar 2003 03:54:32 PST." Date: Wed, 05 Mar 2003 09:08:18 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Popping up a level. I'm not sure how much detail the LL document should get into with regards to DHC and how to perhaps clarify what a client should do when it disconnects/reconnects to a network. I tend to think that this document should not be updating 2131. I actually suspect that the general topic of connection/disconnection, how to detect this, how to do so quickly, etc., is a general enough topic to warrant a separate document/effort to clarify what clients should do. This may involve clarifying and updating parts of 2131. This topic is not specific to LL addressing. It is a generic DHC issue (one can argue that the guidance in 2131 is insufficient and that we have much more experience today and should collect that experience into a document). Moreover, the same general topic also crops up in mobility, where folk want to be able to learn *very* *quickly* if they have moved to a new link (e.g., do they need a new address? new gateway? additional parameters?). So, some of the mobility documents get into this space too. IMO, this is a generic issue and it would be good to document/address it in one place, with input from all the communities that have concerns with what is done today or the lack of clear guidelines to handle existing concerns. Thoughts? Do others thing that a separate effort is needed in this space? Thomas From owner-zeroconf@merit.edu Wed Mar 5 09:16: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 JAA00948 for ; Wed, 5 Mar 2003 09:16:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 50D1191266; Wed, 5 Mar 2003 09:17:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F22219122C; Wed, 5 Mar 2003 09:17:55 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 72CE19126C for ; Wed, 5 Mar 2003 09:17:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4EC595DF25; Wed, 5 Mar 2003 09:17:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id C74DE5DEF3 for ; Wed, 5 Mar 2003 09:17:38 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h25EHWQ15693; Wed, 5 Mar 2003 21:17:32 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h25EHQO10681; Wed, 5 Mar 2003 21:17:26 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: Bernard Aboba , zeroconf@merit.edu Subject: Re: The IPv4ll draft updates RFC2131 In-Reply-To: <1046868217.14873.15.camel@devil> References: <1046868217.14873.15.camel@devil> <1046785713.1902.8.camel@devil> <9893.1046867381@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Mar 2003 21:17:26 +0700 Message-ID: <10679.1046873846@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 05 Mar 2003 14:43:37 +0200 From: Mika Liljeberg Message-ID: <1046868217.14873.15.camel@devil> | With the above routes, a node can just keep its routable address for as | long as the lease time says and that same address can be used for all | link-local communication. Validation of the address only has to be done | on reconnection to a managed network. No, that doesn't work if the address is an "invalid" one for the net it is connected to. That is, if I take a host that is 10.1.2.3 and move it to a net where the DHCP server either doesn't exist, or is down, but where the address that should be used is 192.168.1.5 then it doesn't help that the node simply ARP's for everything using the fallback default route, as while that would allow its packets to reach its peer, reply packets from the peer are going to go somewhere wild. The address is important, you can't just ignore it. kre From owner-zeroconf@merit.edu Wed Mar 5 09:19: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 JAA01028 for ; Wed, 5 Mar 2003 09:19:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5E35D9121C; Wed, 5 Mar 2003 09:20:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C2C991229; Wed, 5 Mar 2003 09:20:58 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1FD989121C for ; Wed, 5 Mar 2003 09:20:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF1CE5DF99; Wed, 5 Mar 2003 09:20:56 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 616D75DF98 for ; Wed, 5 Mar 2003 09:20:55 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h25EKfQ16677; Wed, 5 Mar 2003 21:20:41 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h25EKWO10695; Wed, 5 Mar 2003 21:20:32 +0700 (ICT) From: Robert Elz To: "Philip Nye" Cc: "Zeroconf Working Group" Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 In-Reply-To: <001101c2e31c$a1b9e820$131010ac@aldebaran> References: <001101c2e31c$a1b9e820$131010ac@aldebaran> <1046822987.8760.42.camel@devil> <01fb01c2e308$653b3de0$131010ac@aldebaran> <1046864552.8754.150.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Mar 2003 21:20:31 +0700 Message-ID: <10693.1046874031@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 5 Mar 2003 13:39:22 -0000 From: "Philip Nye" Message-ID: <001101c2e31c$a1b9e820$131010ac@aldebaran> | Attack was a loose term based [...] please be careful with use of terms like this - if something is an attack, then clearly we should be taking reasonable steps to avoid it. If it isn't an attack, but that was just a convenient word, then perhaps it is just a harmless side effect, that we can ignore. kre From owner-zeroconf@merit.edu Wed Mar 5 09:22:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01137 for ; Wed, 5 Mar 2003 09:22:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3F28891229; Wed, 5 Mar 2003 09:24:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0EFDB9122C; Wed, 5 Mar 2003 09:24:32 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 130CF91229 for ; Wed, 5 Mar 2003 09:24:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id E7C545DF98; Wed, 5 Mar 2003 09:24:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 52D815DF93 for ; Wed, 5 Mar 2003 09:24:30 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h25EOKQ17777; Wed, 5 Mar 2003 21:24:21 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h25EO9O10760; Wed, 5 Mar 2003 21:24:09 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: Bernard Aboba , zeroconf@merit.edu Subject: Re: The IPv4ll draft updates RFC2131 In-Reply-To: <1046873494.14850.36.camel@devil> References: <1046873494.14850.36.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Mar 2003 21:24:08 +0700 Message-ID: <10758.1046874248@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 05 Mar 2003 16:11:34 +0200 From: Mika Liljeberg Message-ID: <1046873494.14850.36.camel@devil> | So what am I missing? Why exactly is the latter statement not | appropriate? Why should we try to second guess the lease time? It depends what exactly "second guess" means. I certainly don't mean that the lease should be abandoned, you never know, the node might move back to a link where the lease still works, and in that case, it is fine to use it again. | If the lease is valid, the address is mine. I may not be in the right | position in the network topology for it to work but, assuming I can't | get a new routable address, why exactly should I stop using the old one? See my more recent mail... kre From owner-zeroconf@merit.edu Wed Mar 5 09:29: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 JAA01338 for ; Wed, 5 Mar 2003 09:29:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 73A7F9122C; Wed, 5 Mar 2003 09:30:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 417B691230; Wed, 5 Mar 2003 09:30:27 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 94FED9122C for ; Wed, 5 Mar 2003 09:30:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4D0CA5DF8F; Wed, 5 Mar 2003 09:30:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 523675DF25 for ; Wed, 5 Mar 2003 09:30:18 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h25DFsp16893; Wed, 5 Mar 2003 05:15:57 -0800 Date: Wed, 5 Mar 2003 05:15:54 -0800 (PST) From: Bernard Aboba To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: The IPv4ll draft updates RFC2131 In-Reply-To: <200303051408.h25E8IO04641@cichlid.adsl.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > I actually suspect that the general topic of connection/disconnection, > how to detect this, how to do so quickly, etc., is a general enough > topic to warrant a separate document/effort to clarify what clients > should do. This may involve clarifying and updating parts of 2131. This seems reasonable. It may also relate to the ACD document. > This topic is not specific to LL addressing. It is a generic DHC issue > (one can argue that the guidance in 2131 is insufficient and that we > have much more experience today and should collect that experience > into a document). Yes, I think a separate document probably is required. At the same time, current implementations of LLv4 are doing some unwise things, so that some guidance is probably appropriate in the LLv4 document, so as to "do no harm". From owner-zeroconf@merit.edu Wed Mar 5 09:31:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01401 for ; Wed, 5 Mar 2003 09:31:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 544B791230; Wed, 5 Mar 2003 09:30:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E09791253; Wed, 5 Mar 2003 09:30:36 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F1B2591230 for ; Wed, 5 Mar 2003 09:30:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id CFCAC5DF8F; Wed, 5 Mar 2003 09:30:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 52D765DF25 for ; Wed, 5 Mar 2003 09:30:24 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h25EV3aj015563; Wed, 5 Mar 2003 16:31:03 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h25EUxwg015556; Wed, 5 Mar 2003 16:30:59 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: The IPv4ll draft updates RFC2131 From: Mika Liljeberg To: Robert Elz Cc: Bernard Aboba , zeroconf@merit.edu In-Reply-To: <10679.1046873846@munnari.OZ.AU> References: <1046868217.14873.15.camel@devil> <1046785713.1902.8.camel@devil> <9893.1046867381@munnari.OZ.AU> <10679.1046873846@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046874657.14873.46.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 05 Mar 2003 16:30:58 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 2003-03-05 at 16:17, Robert Elz wrote: > Date: 05 Mar 2003 14:43:37 +0200 > From: Mika Liljeberg > Message-ID: <1046868217.14873.15.camel@devil> > > | With the above routes, a node can just keep its routable address for as > | long as the lease time says and that same address can be used for all > | link-local communication. Validation of the address only has to be done > | on reconnection to a managed network. > > No, that doesn't work if the address is an "invalid" one for the net > it is connected to. > > That is, if I take a host that is 10.1.2.3 and move it to a net where > the DHCP server either doesn't exist, or is down, but where the > address that should be used is 192.168.1.5 then it doesn't help that > the node simply ARP's for everything using the fallback default route, > as while that would allow its packets to reach its peer, reply packets > from the peer are going to go somewhere wild. So the case you're trying to solve is this [just so I understand]: 1) the DHCP server is down 2) the default GW is up 3) all the other nodes on the link are configured and holding on to their routable addresses 4) my address is from a different subnet Thanks, I see the problem. Do you think this is a common enough situation to worry about? > The address is important, you can't just ignore it. That's why I still think LL23 was a bad idea. :) Our current implementation wouldn't have any problem with the above configuration. LL23 introduced this one. MikaL From owner-zeroconf@merit.edu Wed Mar 5 09:33: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 JAA01504 for ; Wed, 5 Mar 2003 09:33:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 26C5491253; Wed, 5 Mar 2003 09:35:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E27949126C; Wed, 5 Mar 2003 09:35:17 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E097891253 for ; Wed, 5 Mar 2003 09:35:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id BE7CB5DF9F; Wed, 5 Mar 2003 09:35:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 8FCB35DF9D for ; Wed, 5 Mar 2003 09:35:16 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id E8C7F59976 for ; Wed, 5 Mar 2003 14:35:18 +0000 (GMT) Message-ID: <003f01c2e324$7032f230$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <200303051408.h25E8IO04641@cichlid.adsl.duke.edu> Subject: Re: The IPv4ll draft updates RFC2131 Date: Wed, 5 Mar 2003 14:35:15 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Thomas Narten" > > Thoughts? Do others thing that a separate effort is needed in this > space? It has become clear to me that these issues extend well beyond LL - although LL is part of the picture. It has become much more widespread recently, to move a host from one network to another over short timescales and wireless has accelerated this tendency and will continue to do so. Also the success of DHCP has meant that peoples expectations are that things should work without explicit configuration at the host (DHCP is zero-config from most users' viewpoint). So - yes, I think that this would be timely and useful. Philip From owner-zeroconf@merit.edu Wed Mar 5 13:53: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 NAA21595 for ; Wed, 5 Mar 2003 13:53:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 63AE19126C; Wed, 5 Mar 2003 13:55:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3355E91276; Wed, 5 Mar 2003 13:55:34 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E73ED9126C for ; Wed, 5 Mar 2003 13:55:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id D34725DFCC; Wed, 5 Mar 2003 13:55:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 730615DFB4 for ; Wed, 5 Mar 2003 13:55:31 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 327301B2295 for ; Wed, 5 Mar 2003 12:51:30 -0600 (CST) Date: Wed, 5 Mar 2003 12:55:29 -0600 Mime-Version: 1.0 (Apple Message framework v551) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Fwd: The IPv4ll draft updates RFC2131 From: Ted Lemon To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit Message-Id: <08859DB0-4F3C-11D7-93FC-00039367340A@nominum.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit This is the original message that I sent to Erik, Bernard, Ralph and Stuart describing the problem. TBH, I do not think this is something that the zeroconf working group should be discussing - the reason I brought it up is that I think the DHC working group needs to discuss it. The Zeroconf WG has already decided to change IPv4ll in such a way that it updates RFC2131, as I have explained below, so there's no particular reason to continue discussing that here. Begin forwarded message: > From: Ted Lemon > Date: Thu Feb 27, 2003 2:05:38 PM America/Chicago > To: erik.guttman@sun.com, Ralph Droms > Cc: Stuart Cheshire , scanner@nominum.com > Subject: The IPv4ll draft updates RFC2131 > Message-Id: > > Erik, you have asserted that this draft doesn't update RFC2131 because > it does not do so explicitly - it refers to a state where a node has a > configured non-IPv4ll address, and a state where a node does not, but > doesn't say how transitions between these two states occur. > > In a literal reading of both documents, you are correct, but speaking > as someone who understands the DHCP standard pretty well, it is > obvious to me that there is a clear conflict - that IPv4ll requires > DHCP client behavior that is different than what is specified in > RFC2131. I think that this conflict requires that IPv4ll be reviewed > by the DHC working group before advancing. > > RFC2131 states that when a DHCP client has a valid lease but is not > certain that the lease is correct for its network, it can enter the > INIT-REBOOT state to reconfirm the lease (it can also just continue to > use the lease without checking, except on startup). This behavior is > strongly suggested because without it, a DHCP server outage can > disable a network. DHCP clients that don't have stable storage > aren't *required* to implement this behavior, but in general it's > expected that most DHCP clients will implement it. > > Recent changes to the IPv4ll draft establish an interdependency > between IPv4ll and non-IPv4ll addresses - devices that are configured > with non-IPv4ll addresses are supposed to give up their IPv4ll > addresses. Such nodes are supposed to re-initiate IPv4ll address > selection when they lose their non-IPv4ll addresses. In practice, > whenever a DHCP client notices a network state transition, or is > power-cycled, it will enter INIT-REBOOT to check its lease. The > outcome of this, according to RFC2131, is always that it will have a > configured address after entering INIT-REBOOT, either because it gives > up, or because it succeeds in contacting the DHCP server. > > If the DHCP client fails to contact a DHCP server, this can mean one > of two things: either it's no longer on a network managed by DHCP, or > it is still on that network, but the DHCP server is down or > unreachable. If it is still on the same network, the behavior > specified in RFC2131 will work. If it is not, the behavior specified > in RFC2131 will result in the device being unable to benefit from the > use of the IP address it got from DHCP, and also unable to use IPv4ll. > So in practice, I would expect any IPv4ll implementor that cares > about the dependability of IPv4ll to modify their DHCP client so that > if it fails to contact the DHCP server, it stops using its lease. > > I have already seen one implementation of a pre-standard version of > IPv4ll that modifies the DHCP client's behavior in the INIT-REBOOT > state in the way I've described here, and I and one of my co-workers > at Nominum have already seen cases where this breaks IPv4 network > connectivity. Whenever a DHCP client sees a network state transition > or is power cycled and comes up on a network with no DHCP service, the > DHCP client goes into an IPv4ll-only state and gives up its DHCP > lease. As a result of this, existing TCP/IP sessions are > disconnected, even though the TCP connection timeout hasn't happened. > > We have directly observed this problem in two cases - one where the > laptop's connectivity to the base station is intermittent, and the > other where a router was rebooted with the DHCP client plugged > directly into one of its ports. This first case is common in > wireless deployments when, for example, we take our laptops from our > desks to a meeting. The second case is common in home networking > cases, where the router and the hub are frequently the same device. > The same thing will also happen if a network state transition occurs > or the DHCP client is power-cycled while the DHCP server is not > working. > > I'm sorry to have to make a point of this now - I'd thought that I'd > explained the problems with LL23 sufficiently, but the brevity of the > debate meant that the full implications of this only became clear at > the last minute, after I'd already argued against LL23 for a variety > of other reasons. Unfortunately I wasn't able to get across to you > how serious this problem was before the discussion closed. > > I'm not sure how to fix this. One solution would be to make a > specific modification to the draft to specify different behavior in > the case where the global address is being managed by DHCP. Another > way would be to advance a separate draft explaining how DHCP clients > and IPv4ll agents should interact. I do not think it is acceptable > for this draft to advance without some strategy for dealing with this > problem - as has been stated many times by people far more vociferous > than me, IPv4ll should not seriously break existing IP functionality. > From owner-zeroconf@merit.edu Thu Mar 6 03:13:48 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27741 for ; Thu, 6 Mar 2003 03:13:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BC75991203; Thu, 6 Mar 2003 03:04:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A3BD91207; Thu, 6 Mar 2003 03:04:34 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9672C91203 for ; Thu, 6 Mar 2003 03:04:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7A9C45E04F; Thu, 6 Mar 2003 03:04:33 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 2AAC65DFFD for ; Thu, 6 Mar 2003 03:04:33 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA05277; Thu, 6 Mar 2003 01:04:31 -0700 (MST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h2684Tl24571; Thu, 6 Mar 2003 09:04:29 +0100 (MET) Date: Thu, 6 Mar 2003 09:04:28 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Robert Elz Cc: Erik Guttman , Subrata Goswami , zeroconf@merit.edu Subject: Re: LL24: Another (distributed) way to get an LLv4 address. In-Reply-To: <9306.1046860466@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Robert, On Wed, 5 Mar 2003, Robert Elz wrote: > From: Erik Guttman > | A distributed counter algorithm is a 'good idea' (perhaps), but > | what IESG comment does it address? What burning problem does > | it solve? > > If whatever the issue is isn't considered useful by the WG, then it can > quickly be disposed of, without being ruled out of order. What you say is true enough for the charter we currently have for the ZEROCONF WG. I would like to be clear though: At this time we (WG chair, IESG) have no intention in broadening the work items or work load of the ZEROCONF WG. For this reason, I am vigorously pushing back on work items which seem peripheral to our central task. We will discuss and decide what to do as a WG, as you suggest, within the bounds of our inelastic scope. Erik From owner-zeroconf@merit.edu Thu Mar 6 03:35: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 DAA28242 for ; Thu, 6 Mar 2003 03:35:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 06CD891208; Thu, 6 Mar 2003 03:37:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BE0D9120A; Thu, 6 Mar 2003 03:37:27 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C7D1F91208 for ; Thu, 6 Mar 2003 03:37:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id A57FB5E00F; Thu, 6 Mar 2003 03:37:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by segue.merit.edu (Postfix) with ESMTP id 2380D5DF21 for ; Thu, 6 Mar 2003 03:37:25 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h268atws004943; Thu, 6 Mar 2003 03:36:56 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn1-844.cisco.com [10.21.99.76]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id DAA09078; Thu, 6 Mar 2003 03:35:07 -0500 (EST) Message-Id: <4.3.2.7.2.20030306031106.00b17ed0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Mar 2003 03:20:04 -0500 To: Thomas Narten From: Ralph Droms Subject: Re: The IPv4ll draft updates RFC2131 Cc: Bernard Aboba , zeroconf@merit.edu In-Reply-To: <200303051408.h25E8IO04641@cichlid.adsl.duke.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I agree with Thomas that a review (not specific to any protocol) of procedures related to detecting disconnection/connection events would be a worthwhile initiative. As Thomas points out, such a review would likely provide input to at least DHCP, link-local addressing and mobility. The dhc WG has initiated a review of RFC2131; seems like there would be an opportunity for information exchange between that review and the review that Thomas proposes. - Ralph At 09:08 AM 3/5/2003 -0500, Thomas Narten wrote: >[...] >I actually suspect that the general topic of connection/disconnection, >how to detect this, how to do so quickly, etc., is a general enough >topic to warrant a separate document/effort to clarify what clients >should do. This may involve clarifying and updating parts of 2131. > >This topic is not specific to LL addressing. It is a generic DHC issue >(one can argue that the guidance in 2131 is insufficient and that we >have much more experience today and should collect that experience >into a document). > >Moreover, the same general topic also crops up in mobility, where folk >want to be able to learn *very* *quickly* if they have moved to a new >link (e.g., do they need a new address? new gateway? additional >parameters?). So, some of the mobility documents get into this space >too. > >IMO, this is a generic issue and it would be good to document/address >it in one place, with input from all the communities that have >concerns with what is done today or the lack of clear guidelines to >handle existing concerns. > >Thoughts? Do others thing that a separate effort is needed in this >space? > >Thomas From owner-zeroconf@merit.edu Thu Mar 6 03:37: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 DAA28308 for ; Thu, 6 Mar 2003 03:37:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 522A59120A; Thu, 6 Mar 2003 03:39:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18C019120C; Thu, 6 Mar 2003 03:39:07 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BAC9E9120A for ; Thu, 6 Mar 2003 03:39:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id A9BD35E04B; Thu, 6 Mar 2003 03:39:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by segue.merit.edu (Postfix) with ESMTP id 4013C5E04A for ; Thu, 6 Mar 2003 03:39:06 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h268cqws005026; Thu, 6 Mar 2003 03:38:52 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn1-844.cisco.com [10.21.99.76]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id DAA09189; Thu, 6 Mar 2003 03:38:47 -0500 (EST) Message-Id: <4.3.2.7.2.20030306032137.00b64ef0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Mar 2003 03:35:03 -0500 To: zeroconf@merit.edu From: Ralph Droms Subject: Re: The IPv4ll draft updates RFC2131 Cc: Bernard Aboba In-Reply-To: <9893.1046867381@munnari.OZ.AU> References: <1046785713.1902.8.camel@devil> <1046785713.1902.8.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk My comments are in line ... I agree that, because of the specific use of "MAY" that Bernard pointed out in RFC2131, we can likely work out a reasonable solution without updating or revising RFC2131... - Ralph At 07:29 PM 3/5/2003 +0700, Robert Elz wrote: >The complexity all seems to relate to which addresses the host should >use, and when. If it abandons a routable address (using LL instead) >then in many cases that will needlessly cause connections to fail, and >new connections to be unable to be made (despite the rationale of this >WG, in the wild, nodes rarely ever want to actually communicate with >something on the same link). > >On the other hand, if a node persists on using a routable address when >it shouldn't (say, just because its lease is still valid) then it won't >be able to communicate with anyone at all (be even worse than having >just an LL address). > >There is nothing in 2131 that mandates or even recommends that a node >fall into either of those traps however - it would be surprising if >there were. That some common implementations have gone full bore in >one of those directions or the other to me just means lack of thought >at the implementation level. Excellent summary - the situation is complex and can't be readily captured in a single rule like "always continue to use the address obtained through DHCP" or "always immediately configure an LL address". >I agree with Bernard ... > > So in practice, I think we may be able to come up > with a workable solution. > >I believe we can - all that's needed is for implementors to be more >intelligent when choosing whether to keep using an existing routable >address (from a DHCP lease, or otherwise) and when to abandon that >and fall back to LL addresses. I agree completely - the various protocols have to be specified in such a way as to allow a device to make a more intelligent decision, and we should (for example, through an initiative like Thomas suggested) document whatever current wisdom we can agree on to guide device developers and users. The default behavior of my laptop is likely to be different than the default behavior of a light switch; the default behavior I choose for my laptop may well be different from the default behavior you choose for your laptop; the choice I make about the behavior of my laptop might be different if I *know* I'm trying to use an ad hoc network than if I *know* I'm trying to use an overloaded wireless AP. As kre points out, none of this requires any changes to RFC2131, and may provide input to related specifications for LL and mobility. - Ralph From owner-zeroconf@merit.edu Thu Mar 6 06:13:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01871 for ; Thu, 6 Mar 2003 06:13:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 643C591207; Thu, 6 Mar 2003 06:15:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E37669120F; Thu, 6 Mar 2003 06:15:07 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D9E4A91207 for ; Thu, 6 Mar 2003 06:15:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 324665E06E; Thu, 6 Mar 2003 06:15:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 15E9C5E06C for ; Thu, 6 Mar 2003 06:15:03 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h26BEvQ20002; Thu, 6 Mar 2003 18:14:58 +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 h26BEdO19139; Thu, 6 Mar 2003 18:14:39 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: Re: The IPv4ll draft updates RFC2131 In-Reply-To: <1046874657.14873.46.camel@devil> References: <1046874657.14873.46.camel@devil> <1046868217.14873.15.camel@devil> <1046785713.1902.8.camel@devil> <9893.1046867381@munnari.OZ.AU> <10679.1046873846@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Mar 2003 18:14:39 +0700 Message-ID: <19137.1046949279@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 05 Mar 2003 16:30:58 +0200 From: Mika Liljeberg Message-ID: <1046874657.14873.46.camel@devil> | That's why I still think LL23 was a bad idea. :) Our current | implementation wouldn't have any problem with the above configuration. | LL23 introduced this one. For this it makes no difference. If you're able to tell that the routable addr that you had is no longer viable, then (even with LL23) you're supposed to use an LL address (if you can't get a new routable). Without LL23, if you had a routable addr, and weren't able to tell it was non-functional, and you wanted to talk to someone else's routable address (ie, the normal kind of thing) then you're going to use your broken routable addr as the source, and fail exactly the same way. Nodes simply need to be able to tell whether their (old) routable addr is still viable to use or not, and they need that, regardless of LL addressing (LL just provides an alternative addr when there is no available workable routable addr to use). Where LL23 makes a difference is when you have a working routable addr. Which is fine, as having a working routable addr, you need no more. As to how likely this all is - not very likely in most situations these days I suspect, DHCP tends to exist everywhere, and DHCP servers tend to be fairly reliable, so it isn't going to happen often that there will be no server to reply to your address request (the server may ignore your attempt to renew your old addr, but it won't ignore a DISCOVER to start finding a new one usually). In the past, when less nets had DHCP servers, and the code for them wasn't nearly as reliable as now, this was probably more of an issue. Yet, there are still enough windows & macos users who (occasionally) bitch about the way their system works that this clearly isn't something that should simply be ignored as "too unlikely to ever happen". It does happen, occasionally, and nodes need to be aware of it. kre From owner-zeroconf@merit.edu Thu Mar 6 07:09: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 HAA07427 for ; Thu, 6 Mar 2003 07:09:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3CEB29120F; Thu, 6 Mar 2003 07:11:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0092B91210; Thu, 6 Mar 2003 07:11:15 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ADAB69120F for ; Thu, 6 Mar 2003 07:11:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D4EB5E078; Thu, 6 Mar 2003 07:11:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id C58935E077 for ; Thu, 6 Mar 2003 07:11:13 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h26CBxaj029856; Thu, 6 Mar 2003 14:12:00 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h26CBv6h029847; Thu, 6 Mar 2003 14:11:57 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: The IPv4ll draft updates RFC2131 From: Mika Liljeberg To: Robert Elz Cc: zeroconf@merit.edu In-Reply-To: <19137.1046949279@munnari.OZ.AU> References: <1046874657.14873.46.camel@devil> <1046868217.14873.15.camel@devil> <1046785713.1902.8.camel@devil> <9893.1046867381@munnari.OZ.AU> <10679.1046873846@munnari.OZ.AU> <19137.1046949279@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046952716.26795.49.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Mar 2003 14:11:57 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-03-06 at 13:14, Robert Elz wrote: > Date: 05 Mar 2003 16:30:58 +0200 > From: Mika Liljeberg > Message-ID: <1046874657.14873.46.camel@devil> > > | That's why I still think LL23 was a bad idea. :) Our current > | implementation wouldn't have any problem with the above configuration. > | LL23 introduced this one. > > For this it makes no difference. If you're able to tell that the > routable addr that you had is no longer viable, then (even with LL23) > you're supposed to use an LL address (if you can't get a new routable). It does make a difference. With the two-addresses model this would have worked. Let me illustrate with an example: A is visiting B's network. A and B have both LL and routable addresses (the model I was campaining for). B's routable address is in DNS and B is advertising it's LL address via LLMNR. A has the following routes: 169.254.0.0./16 --> local link a.b.c.d/x --> local link [INVALID] 0.0.0.0/0 --> default GW [INVALID, GW UNREACHABLE] Note: A is also using a DNS server from its home network, which it can't reach at the moment. A tries to contact B. First it has to find B's address by resolving its name. The name resolver runs the destination address selection algorithm: 1) It asks DNS to get a routable address for B. This fails, because A does not have a valid route for its DNS server in the home network ==> go to step 3) 2) If A *had* been able to talk to DNS, in this step it would check if there is a valid source address for B's routable address. This would still fail, because there is no matching route. 3) It tries LLMNR and gets B's LL address. 4) It checks if there is a valid source address. This time there is. 5) The resolver returns the LL address to the application and discards the routable address. The application on node A connects to B's LL address and works just fine. The only real hitch is that it takes a little while to mark the gateway route unreachable. The ARP timeouts determine how long that is. Note also that there is no dependency to DHCP whatsover. It just works. If, later on, the DHCP client manages to get the node valid parameters again, the above algorithm will still keep working. > Without LL23, if you had a routable addr, and weren't able to tell it > was non-functional, You can easily tell if an address is unusable: you either have a route for it or you don't. You *do* need proper reachability detection for this to work, though. > and you wanted to talk to someone else's routable > address (ie, the normal kind of thing) then you're going to use your > broken routable addr as the source, and fail exactly the same way. That's why intelligent API implementation is important, for naive applications at least. A smarter application would simply try all destination addresses until it found one that works. MikaL From owner-zeroconf@merit.edu Thu Mar 6 07:20:54 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08118 for ; Thu, 6 Mar 2003 07:20:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 672FD91210; Thu, 6 Mar 2003 07:22:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B15391211; Thu, 6 Mar 2003 07:22:50 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1074891210 for ; Thu, 6 Mar 2003 07:22:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id E6F435E06D; Thu, 6 Mar 2003 07:22:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id E3EFF5E029 for ; Thu, 6 Mar 2003 07:22:47 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h26CNZaj029923; Thu, 6 Mar 2003 14:23:35 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h26CNYGC029918; Thu, 6 Mar 2003 14:23:34 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: The IPv4ll draft updates RFC2131 From: Mika Liljeberg To: Robert Elz Cc: zeroconf@merit.edu In-Reply-To: <1046952716.26795.49.camel@devil> References: <1046874657.14873.46.camel@devil> <1046868217.14873.15.camel@devil> <1046785713.1902.8.camel@devil> <9893.1046867381@munnari.OZ.AU> <10679.1046873846@munnari.OZ.AU> <19137.1046949279@munnari.OZ.AU> <1046952716.26795.49.camel@devil> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046953412.26795.56.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Mar 2003 14:23:33 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-03-06 at 14:11, Mika Liljeberg wrote: Responding to my own mail... > > Without LL23, if you had a routable addr, and weren't able to tell it > > was non-functional, > > You can easily tell if an address is unusable: you either have a route > for it or you don't. You *do* need proper reachability detection for > this to work, though. I didn't say this very well. The right question to ask is: do I have a usable source address for this destination address? A TCPIP stack can answer this question as a matter of course. The key thing is to have reacability detection for gateway routes. Btw, applying LL23 to my example: How would A get B's address? MikaL From owner-zeroconf@merit.edu Thu Mar 6 08:42: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 IAA13884 for ; Thu, 6 Mar 2003 08:42:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6936891211; Thu, 6 Mar 2003 08:44:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3704691217; Thu, 6 Mar 2003 08:44:33 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F23091211 for ; Thu, 6 Mar 2003 08:44:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 281DB5E079; Thu, 6 Mar 2003 08:44:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 6199F5DF9E for ; Thu, 6 Mar 2003 08:44:26 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h26DiJQ11355; Thu, 6 Mar 2003 20:44:19 +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 h26Di0O19831; Thu, 6 Mar 2003 20:44:03 +0700 (ICT) From: Robert Elz To: Mika Liljeberg Cc: zeroconf@merit.edu Subject: Re: The IPv4ll draft updates RFC2131 In-Reply-To: <1046952716.26795.49.camel@devil> References: <1046952716.26795.49.camel@devil> <1046874657.14873.46.camel@devil> <1046868217.14873.15.camel@devil> <1046785713.1902.8.camel@devil> <9893.1046867381@munnari.OZ.AU> <10679.1046873846@munnari.OZ.AU> <19137.1046949279@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Mar 2003 20:44:00 +0700 Message-ID: <19829.1046958240@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: 06 Mar 2003 14:11:57 +0200 From: Mika Liljeberg Message-ID: <1046952716.26795.49.camel@devil> | Note: A is also using a DNS server from its home network, which it can't | reach at the moment. That's an assumption which isn't necessarily true. You can't assume it will work that way. A might have a DNS cache embedded in it, full of addresses whose TTL has not yet expired, all ready to be used, without needing to send any packets. Or A might simply be attempting to contact an IP address. I have no doubt but that there are scenarios when almost anything would work - but to be useful as "the answer" it needs to work in all the scenarios (as well as they allow). Detecting that a routable address has "gone bad" allows that. kre ps this also answers the "btw" question in your followup message. From owner-zeroconf@merit.edu Thu Mar 6 08:53: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 IAA14619 for ; Thu, 6 Mar 2003 08:53:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8C0249120C; Thu, 6 Mar 2003 08:55:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5DDFF9120E; Thu, 6 Mar 2003 08:55:26 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2918F9120C for ; Thu, 6 Mar 2003 08:55:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0C81E5E079; Thu, 6 Mar 2003 08:55:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id EDF4B5DF9E for ; Thu, 6 Mar 2003 08:55:23 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h26Du8aj030380; Thu, 6 Mar 2003 15:56:08 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h26Du6Xm030372; Thu, 6 Mar 2003 15:56:06 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: The IPv4ll draft updates RFC2131 From: Mika Liljeberg To: Robert Elz Cc: zeroconf@merit.edu In-Reply-To: <19829.1046958240@munnari.OZ.AU> References: <1046952716.26795.49.camel@devil> <1046874657.14873.46.camel@devil> <1046868217.14873.15.camel@devil> <1046785713.1902.8.camel@devil> <9893.1046867381@munnari.OZ.AU> <10679.1046873846@munnari.OZ.AU> <19137.1046949279@munnari.OZ.AU> <19829.1046958240@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046958964.26789.66.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Mar 2003 15:56:05 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-03-06 at 15:44, Robert Elz wrote: > Date: 06 Mar 2003 14:11:57 +0200 > From: Mika Liljeberg > Message-ID: <1046952716.26795.49.camel@devil> > > | Note: A is also using a DNS server from its home network, which it can't > | reach at the moment. > > That's an assumption which isn't necessarily true. You can't assume > it will work that way. A might have a DNS cache embedded in it, full > of addresses whose TTL has not yet expired, all ready to be used, without > needing to send any packets. That's why I put in step 2). This doesn't change a thing. > Or A might simply be attempting to contact > an IP address. That is a corner case. We can compare the corner cases when you can show a solution for the common case with LL23. > I have no doubt but that there are scenarios when almost anything would > work - but to be useful as "the answer" it needs to work in all the > scenarios (as well as they allow). > > Detecting that a routable address has "gone bad" allows that. Sure. I showed how to do that with my model. How do you do it with LL23? Question for you: Do you accept that the example I showed is correct and that it works even if A has a manually configured address+netmask and no DHCP client implementation at all (which LL23 also breaks)? MikaL From owner-zeroconf@merit.edu Thu Mar 6 09:07: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 JAA15186 for ; Thu, 6 Mar 2003 09:07:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9BC8D91217; Thu, 6 Mar 2003 09:07:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 406D79121F; Thu, 6 Mar 2003 09:07:51 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0C64D91217 for ; Thu, 6 Mar 2003 09:07:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id E62BA5E079; Thu, 6 Mar 2003 09:07:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 6E8855DF9E for ; Thu, 6 Mar 2003 09:07:45 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h26CpHY30055; Thu, 6 Mar 2003 04:51:17 -0800 Date: Thu, 6 Mar 2003 04:51:17 -0800 (PST) From: Bernard Aboba To: Ralph Droms Cc: zeroconf@merit.edu Subject: Re: The IPv4ll draft updates RFC2131 In-Reply-To: <4.3.2.7.2.20030306032137.00b64ef0@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > The default behavior of my > laptop is likely to be different than the default behavior of > a light switch; Yes. Presumably the light switch is not mobile and therefore there is less downside to it keeping a DHCPV4 assigned address in the absence of a response to a DHCPREQUEST. There also might be a difference in behavior for a wired Ethernet interface (where the L2 indications are likely to be reliable) versus an 802.11 interface (where they can be quite unreliable). > the default behavior I choose for my laptop > may well be different from the default behavior you choose for > your laptop; I'm curious why you think this might be the case, assuming that they both have the same interface types (say, 802.11). From owner-zeroconf@merit.edu Thu Mar 6 09:12: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 JAA15463 for ; Thu, 6 Mar 2003 09:12:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0DD3F91218; Thu, 6 Mar 2003 09:13:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB75D9121C; Thu, 6 Mar 2003 09:13:56 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B10CD91218 for ; Thu, 6 Mar 2003 09:13:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 97E805E090; Thu, 6 Mar 2003 09:13:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by segue.merit.edu (Postfix) with ESMTP id 2E4CD5E088 for ; Thu, 6 Mar 2003 09:13:55 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h26EDjkD010445; Thu, 6 Mar 2003 09:13:46 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-945.cisco.com [10.82.243.177]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA22071; Thu, 6 Mar 2003 09:13:39 -0500 (EST) Message-Id: <4.3.2.7.2.20030306091021.00b6cdd8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Mar 2003 09:13:33 -0500 To: Bernard Aboba From: Ralph Droms Subject: Re: The IPv4ll draft updates RFC2131 Cc: zeroconf@merit.edu In-Reply-To: References: <4.3.2.7.2.20030306032137.00b64ef0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Regarding default behavior for a laptop - I might use IPv4ll so infrequently that I always want my laptop to pop up a dialog box to let me control the use of IP4ll, while you might use IPv4ll more frequently so that you want your laptop to choose silently IPv4ll any time you reconnect to a network and can't get a response from a DHCP server. - Ralph At 04:51 AM 3/6/2003 -0800, Bernard Aboba wrote: > > The default behavior of my > > laptop is likely to be different than the default behavior of > > a light switch; > >Yes. Presumably the light switch is not mobile and therefore there is >less downside to it keeping a DHCPV4 assigned address in the absence >of a response to a DHCPREQUEST. > >There also might be a difference in behavior for a wired Ethernet >interface (where the L2 indications are likely to be reliable) versus an >802.11 interface (where they can be quite unreliable). > > > the default behavior I choose for my laptop > > may well be different from the default behavior you choose for > > your laptop; > >I'm curious why you think this might be the case, assuming that they both >have the same interface types (say, 802.11). From owner-zeroconf@merit.edu Thu Mar 6 09:12: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 JAA15486 for ; Thu, 6 Mar 2003 09:12:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9206B9121C; Thu, 6 Mar 2003 09:14:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5DDC89121D; Thu, 6 Mar 2003 09:14:18 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 22EE59121C for ; Thu, 6 Mar 2003 09:14:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 06C645E091; Thu, 6 Mar 2003 09:14:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 22CFB5E090 for ; Thu, 6 Mar 2003 09:14:15 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h26EExaj030482; Thu, 6 Mar 2003 16:15:01 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h26EEuKN030475; Thu, 6 Mar 2003 16:14:56 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Fwd: The IPv4ll draft updates RFC2131 From: Mika Liljeberg To: Ted Lemon Cc: zeroconf@merit.edu In-Reply-To: <08859DB0-4F3C-11D7-93FC-00039367340A@nominum.com> References: <08859DB0-4F3C-11D7-93FC-00039367340A@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046960095.26794.70.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Mar 2003 16:14:55 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ted, I agree that reviewing/updating RFC2131 is not within the scope of zeroconf. However, we can and we should study the problem in the case where a node has a manually configured routable address. Solving that case would go a long way towards solving the other problems as well. MikaL On Wed, 2003-03-05 at 20:55, Ted Lemon wrote: > This is the original message that I sent to Erik, Bernard, Ralph and > Stuart describing the problem. TBH, I do not think this is something > that the zeroconf working group should be discussing - the reason I > brought it up is that I think the DHC working group needs to discuss > it. The Zeroconf WG has already decided to change IPv4ll in such a > way that it updates RFC2131, as I have explained below, so there's no > particular reason to continue discussing that here. > > Begin forwarded message: > > > From: Ted Lemon > > Date: Thu Feb 27, 2003 2:05:38 PM America/Chicago > > To: erik.guttman@sun.com, Ralph Droms > > Cc: Stuart Cheshire , scanner@nominum.com > > Subject: The IPv4ll draft updates RFC2131 > > Message-Id: > > > > Erik, you have asserted that this draft doesn't update RFC2131 because > > it does not do so explicitly - it refers to a state where a node has a > > configured non-IPv4ll address, and a state where a node does not, but > > doesn't say how transitions between these two states occur. > > > > In a literal reading of both documents, you are correct, but speaking > > as someone who understands the DHCP standard pretty well, it is > > obvious to me that there is a clear conflict - that IPv4ll requires > > DHCP client behavior that is different than what is specified in > > RFC2131. I think that this conflict requires that IPv4ll be reviewed > > by the DHC working group before advancing. > > > > RFC2131 states that when a DHCP client has a valid lease but is not > > certain that the lease is correct for its network, it can enter the > > INIT-REBOOT state to reconfirm the lease (it can also just continue to > > use the lease without checking, except on startup). This behavior is > > strongly suggested because without it, a DHCP server outage can > > disable a network. DHCP clients that don't have stable storage > > aren't *required* to implement this behavior, but in general it's > > expected that most DHCP clients will implement it. > > > > Recent changes to the IPv4ll draft establish an interdependency > > between IPv4ll and non-IPv4ll addresses - devices that are configured > > with non-IPv4ll addresses are supposed to give up their IPv4ll > > addresses. Such nodes are supposed to re-initiate IPv4ll address > > selection when they lose their non-IPv4ll addresses. In practice, > > whenever a DHCP client notices a network state transition, or is > > power-cycled, it will enter INIT-REBOOT to check its lease. The > > outcome of this, according to RFC2131, is always that it will have a > > configured address after entering INIT-REBOOT, either because it gives > > up, or because it succeeds in contacting the DHCP server. > > > > If the DHCP client fails to contact a DHCP server, this can mean one > > of two things: either it's no longer on a network managed by DHCP, or > > it is still on that network, but the DHCP server is down or > > unreachable. If it is still on the same network, the behavior > > specified in RFC2131 will work. If it is not, the behavior specified > > in RFC2131 will result in the device being unable to benefit from the > > use of the IP address it got from DHCP, and also unable to use IPv4ll. > > So in practice, I would expect any IPv4ll implementor that cares > > about the dependability of IPv4ll to modify their DHCP client so that > > if it fails to contact the DHCP server, it stops using its lease. > > > > I have already seen one implementation of a pre-standard version of > > IPv4ll that modifies the DHCP client's behavior in the INIT-REBOOT > > state in the way I've described here, and I and one of my co-workers > > at Nominum have already seen cases where this breaks IPv4 network > > connectivity. Whenever a DHCP client sees a network state transition > > or is power cycled and comes up on a network with no DHCP service, the > > DHCP client goes into an IPv4ll-only state and gives up its DHCP > > lease. As a result of this, existing TCP/IP sessions are > > disconnected, even though the TCP connection timeout hasn't happened. > > > > We have directly observed this problem in two cases - one where the > > laptop's connectivity to the base station is intermittent, and the > > other where a router was rebooted with the DHCP client plugged > > directly into one of its ports. This first case is common in > > wireless deployments when, for example, we take our laptops from our > > desks to a meeting. The second case is common in home networking > > cases, where the router and the hub are frequently the same device. > > The same thing will also happen if a network state transition occurs > > or the DHCP client is power-cycled while the DHCP server is not > > working. > > > > I'm sorry to have to make a point of this now - I'd thought that I'd > > explained the problems with LL23 sufficiently, but the brevity of the > > debate meant that the full implications of this only became clear at > > the last minute, after I'd already argued against LL23 for a variety > > of other reasons. Unfortunately I wasn't able to get across to you > > how serious this problem was before the discussion closed. > > > > I'm not sure how to fix this. One solution would be to make a > > specific modification to the draft to specify different behavior in > > the case where the global address is being managed by DHCP. Another > > way would be to advance a separate draft explaining how DHCP clients > > and IPv4ll agents should interact. I do not think it is acceptable > > for this draft to advance without some strategy for dealing with this > > problem - as has been stated many times by people far more vociferous > > than me, IPv4ll should not seriously break existing IP functionality. > > > From owner-zeroconf@merit.edu Thu Mar 6 11:00:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22506 for ; Thu, 6 Mar 2003 11:00:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DF7819120F; Thu, 6 Mar 2003 11:02:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B35CF9121F; Thu, 6 Mar 2003 11:02:26 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 358119120F for ; Thu, 6 Mar 2003 11:02:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0E75A5E0AF; Thu, 6 Mar 2003 11:02:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 2FDFB5E0AB for ; Thu, 6 Mar 2003 11:02:24 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h1AKIJak030941 for ; Thu, 6 Mar 2003 18:03:11 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h26G392D030933 for zeroconf@merit.edu; Thu, 6 Mar 2003 18:03:09 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: New issue: When to configure a LL address From: Mika Liljeberg To: zeroconf@merit.edu Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046966587.26794.80.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Mar 2003 18:03:08 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Description of issue: When to configure a LL address Comment type: 'T'echnical Priority: 'S' Must fix Section: 1.5 Rationale/Explanation of issue: A node with a manually configured address is unable to communicate if taken outside its home link. It is also prohibited from configuring a link-local address. Lengthy description of problem: If a node having a manually configured routable address and netmask is connected to a link where other nodes have a different netmask, it will be unable to communicate with those nodes. The node is also prohibited from configuring itself a LL address, because it already has an address configured. The above also applies to scenarios, where a node has configured an address using DHCP, or any other such mechanism, and fails to detect that the address has become unusable in the current context. The following text in section 1.5 is inaccurate, as it does not consider the configured netmask: "A node with any address assigned for a link can communicate with all other devices on that link, whether those other devices use link-local addresses, or routable addresses." Requested change: Delete the current text in section 1.5 and replace it with: "Having addresses of multiple different scopes assigned to an interface with no adequate way to determine in what circumstances each address should be used leads to complexity for applications and confusion for users. For this reason, a host that obtains, or is configured with, a valid routable address on an interface, should not attempt to configure a link-local address on the same interface. Determining whether an address is valid is problematic, as this cannot be deduced from the scope of the address. The presence of a valid default gateway, however, is a good indication that the node is connected to a routed network and has the appropriate network configuration. A default gateway address is determined to be valid if a) the address matches the netmask of the interface, and b) the gateway is determined to be reachable on the local link. A gateway is determined to be reachable if it responds to ARP on the local link. Other means of determining gateway reachability may also be employed. Where an address and a valid default gateway are configured on an interface, a host SHOULD NOT attempt to configure a link-local address on the same interface. Where a valid default gateway is not configured on an interface, or the configured gateway becomes unreachable, the host SHOULD configure a link-local address on the same interface and it SHOULD advertise that link-local address on the local link in place of any other addresses it may have. Where a link-local address has been configured on an interface, and a valid default gateway is later configured on the same interface, or becomes reachable, the host SHOULD always use the routable address when initiating new communications, and SHOULD cease advertising the availability of the link-local address through whatever mechanisms that address had been made known to others. A host SHOULD continue to use the link-local address for communications underway when the routable address was configured, and MAY continue to accept new communications addressed to the link-local address." From owner-zeroconf@merit.edu Thu Mar 6 12:16: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 MAA00076 for ; Thu, 6 Mar 2003 12:16:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 387C29121F; Thu, 6 Mar 2003 12:18:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A68691221; Thu, 6 Mar 2003 12:18:34 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0A5CB9121F for ; Thu, 6 Mar 2003 12:18:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id EA7045E0BE; Thu, 6 Mar 2003 12:18:33 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id ADC7E5E0BD for ; Thu, 6 Mar 2003 12:18:33 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 33F93599BB for ; Thu, 6 Mar 2003 17:18:36 +0000 (GMT) Message-ID: <006501c2e404$6a88fd80$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: Subject: Re: The IPv4ll draft updates RFC2131 Date: Thu, 6 Mar 2003 17:18:33 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Bernard Aboba" > > > The default behavior of my > > laptop is likely to be different than the default behavior of > > a light switch; > > Yes. Presumably the light switch is not mobile... Its a bit off topic, but this presumption is not correct. While many light switches are not mobile, some of the most volatile networks around occur in entertainment lighting (and audio special effects etc.) where networks with hundreds or thousands of nodes are regularly taken down, shipped across the country and rebuilt in different configurations for the next night's show. This is an area where I am engaged in trying to push forward and develop the use of IP and where automatic configuration has huge potential. Philip From owner-zeroconf@merit.edu Thu Mar 6 12:25:59 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01001 for ; Thu, 6 Mar 2003 12:25:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7D3AE91221; Thu, 6 Mar 2003 12:27:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D11791223; Thu, 6 Mar 2003 12:27:55 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2EA0B91221 for ; Thu, 6 Mar 2003 12:27:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 120C95E0BC; Thu, 6 Mar 2003 12:27:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id A3E115E0A4 for ; Thu, 6 Mar 2003 12:27:53 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id D7BB91B209C; Thu, 6 Mar 2003 11:23:42 -0600 (CST) Date: Thu, 6 Mar 2003 11:27:50 -0600 Subject: Re: The IPv4ll draft updates RFC2131 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Mika Liljeberg , zeroconf@merit.edu To: Robert Elz From: Ted Lemon In-Reply-To: <19137.1046949279@munnari.OZ.AU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > As to how likely this all is - not very likely in most situations these > days I suspect, DHCP tends to exist everywhere, and DHCP servers tend > to > be fairly reliable, so it isn't going to happen often that there will > be > no server to reply to your address request (the server may ignore your > attempt to renew your old addr, but it won't ignore a DISCOVER to start > finding a new one usually). In the past, when less nets had DHCP > servers, > and the code for them wasn't nearly as reliable as now, this was > probably more of an issue. The place where this is going to break, and break frequently, is in ad-hoc and home networking environments. You're right that it's never going to happen on your network. I just find the idea of defining a protocol that is most likely to break in the situation where the end-user is least likely to be prepared to handle it, well, kind of unfortunate. From owner-zeroconf@merit.edu Thu Mar 6 12:32:54 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01591 for ; Thu, 6 Mar 2003 12:32:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6614591230; Thu, 6 Mar 2003 12:32:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4181091227; Thu, 6 Mar 2003 12:32:47 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5306191226 for ; Thu, 6 Mar 2003 12:32:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 200EB5E0A4; Thu, 6 Mar 2003 12:32:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 5D1665E0BC for ; Thu, 6 Mar 2003 12:32:38 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id D06BC1B2082; Thu, 6 Mar 2003 11:28:27 -0600 (CST) Date: Thu, 6 Mar 2003 11:32:35 -0600 Subject: Re: New issue: When to configure a LL address Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Mika Liljeberg From: Ted Lemon In-Reply-To: <1046966587.26794.80.camel@devil> Message-Id: <9E3D3A60-4FF9-11D7-93FC-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The problem with your proposed text, Mika, is that it means that whenever I reboot my airport base station, all my connections break, because my airport base station is both the router and the DHCP server, and rebooting it causes my network connection to make the up-to-down and down-to-up transition. From owner-zeroconf@merit.edu Thu Mar 6 12:48: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 MAA02817 for ; Thu, 6 Mar 2003 12:48:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C9B091227; Thu, 6 Mar 2003 12:50:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F08D49122C; Thu, 6 Mar 2003 12:50:48 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D630F91227 for ; Thu, 6 Mar 2003 12:50:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id C4F9C5E0C3; Thu, 6 Mar 2003 12:50:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 8C0C35E0BD for ; Thu, 6 Mar 2003 12:50:46 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h26HpXaj031481; Thu, 6 Mar 2003 19:51:33 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h26HpVOK031471; Thu, 6 Mar 2003 19:51:31 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: New issue: When to configure a LL address From: Mika Liljeberg To: Ted Lemon Cc: zeroconf@merit.edu In-Reply-To: <9E3D3A60-4FF9-11D7-93FC-00039367340A@nominum.com> References: <9E3D3A60-4FF9-11D7-93FC-00039367340A@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046973090.26794.93.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Mar 2003 19:51:31 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-03-06 at 19:32, Ted Lemon wrote: > The problem with your proposed text, Mika, is that it means that > whenever I reboot my airport base station, all my connections break, > because my airport base station is both the router and the DHCP server, > and rebooting it causes my network connection to make the up-to-down > and down-to-up transition. Hmm, I'm not sure which part of the proposed text you mean. Can you be more specific? The text I added basically gives the node a permission to configure a LL address in certain situations but does not suggest that it should unconfigure its routable address. The other constraints come from the LL23, painful as they are. Whether you lose your connections booting your base station depends on how fast it reboots and how quickly your applications time out. TCP keeps on plugging for quite a while, so that should not be a problem. MikaL From owner-zeroconf@merit.edu Thu Mar 6 13:12:35 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04198 for ; Thu, 6 Mar 2003 13:12:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 58FE99122C; Thu, 6 Mar 2003 13:14:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22CC89122F; Thu, 6 Mar 2003 13:14:31 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 107AA9122C for ; Thu, 6 Mar 2003 13:14:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id EDAA75E0B2; Thu, 6 Mar 2003 13:14:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 8B79F5E0C5 for ; Thu, 6 Mar 2003 13:14:29 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id A44831B208F; Thu, 6 Mar 2003 12:10:18 -0600 (CST) Date: Thu, 6 Mar 2003 12:14:26 -0600 Subject: Re: New issue: When to configure a LL address Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Mika Liljeberg From: Ted Lemon In-Reply-To: <1046973090.26794.93.camel@devil> Message-Id: <776BDEEE-4FFF-11D7-93FC-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > The text I added basically gives the node a permission to configure a > LL > address in certain situations but does not suggest that it should > unconfigure its routable address. The other constraints come from the > LL23, painful as they are. Hm, I didn't get that from reading your text - sorry. I should have read more carefully. Unfortunately I don't think this solves the problem, because with the current changes to IPv4ll, it's unlikely that it will work correctly in the case that a host has both an IPv4ll address and an address acquired from DHCP. > Whether you lose your connections booting your base station depends on > how fast it reboots and how quickly your applications time out. TCP > keeps on plugging for quite a while, so that should not be a problem. As long as you never unconfigure your DHCP-acquired address, this is probably true. However, once you unconfigure it, all bets are off - if you're lucky nothing will happen; if you're not, your TCB will be pointing at a dangling route, and even after you get your address back you won't be able to use it. From owner-zeroconf@merit.edu Thu Mar 6 13:29: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 NAA04943 for ; Thu, 6 Mar 2003 13:29:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B55A491232; Thu, 6 Mar 2003 13:30:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8120391235; Thu, 6 Mar 2003 13:30:44 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E5FEB91232 for ; Thu, 6 Mar 2003 13:30:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id ACE1B5E0C8; Thu, 6 Mar 2003 13:30:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 534EB5E0C1 for ; Thu, 6 Mar 2003 13:30:33 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h26IVKaj031699; Thu, 6 Mar 2003 20:31:20 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h26IVIUb031691; Thu, 6 Mar 2003 20:31:18 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: New issue: When to configure a LL address From: Mika Liljeberg To: Ted Lemon Cc: zeroconf@merit.edu In-Reply-To: <776BDEEE-4FFF-11D7-93FC-00039367340A@nominum.com> References: <776BDEEE-4FFF-11D7-93FC-00039367340A@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046975477.26795.122.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Mar 2003 20:31:17 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-03-06 at 20:14, Ted Lemon wrote: > Hm, I didn't get that from reading your text - sorry. I should have > read more carefully. I was trying to keep DHCP out of it. Unconfiguring the address is, IMHO, always the responsiblity of the mechanism that configured it in the first place. > Unfortunately I don't think this solves the > problem, because with the current changes to IPv4ll, it's unlikely that > it will work correctly in the case that a host has both an IPv4ll > address and an address acquired from DHCP. Yes, it's a mess. We would need to say something more about source address selection as well. Any suggestion regarding the text would be welcome. I put this proposal out to kick off some discussion. I don't think ignoring the problem in zeroconf is the right thing to do. This is not only about DHCP. > > Whether you lose your connections booting your base station depends on > > how fast it reboots and how quickly your applications time out. TCP > > keeps on plugging for quite a while, so that should not be a problem. > > As long as you never unconfigure your DHCP-acquired address, this is > probably true. However, once you unconfigure it, all bets are off - > if you're lucky nothing will happen; if you're not, your TCB will be > pointing at a dangling route, and even after you get your address back > you won't be able to use it. Agreed, although I guess a good DHCP server will still try to give you the same address you had before? But anyway, this one *is* a DHCP specific problem. MikaL From owner-zeroconf@merit.edu Thu Mar 6 14:42: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 OAA08397 for ; Thu, 6 Mar 2003 14:42:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 37E3891236; Thu, 6 Mar 2003 14:44:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09C0191237; Thu, 6 Mar 2003 14:44:33 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EDA8091236 for ; Thu, 6 Mar 2003 14:44:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id D56E75DD91; Thu, 6 Mar 2003 14:44:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id B427D5DD8C for ; Thu, 6 Mar 2003 14:44:32 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 187A91B208F; Thu, 6 Mar 2003 13:40:21 -0600 (CST) Date: Thu, 6 Mar 2003 13:44:30 -0600 Subject: Re: New issue: When to configure a LL address Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Mika Liljeberg From: Ted Lemon In-Reply-To: <1046975477.26795.122.camel@devil> Message-Id: <0C468555-500C-11D7-93FC-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I was trying to keep DHCP out of it. Unconfiguring the address is, > IMHO, > always the responsiblity of the mechanism that configured it in the > first place. BTW, I don't think you *can* keep DHCP out of it and get anything remotely resembling reliable behavior. Even if you bring DHCP into it, you still don't get wonderful behavior, but my point is that like it or not, correct DHCP behavior *is* being constrained by the new changes to IPv4ll. From owner-zeroconf@merit.edu Thu Mar 6 15:15: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 PAA10924 for ; Thu, 6 Mar 2003 15:15:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CB01C91237; Thu, 6 Mar 2003 15:17:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2FE091238; Thu, 6 Mar 2003 15:17:29 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D3A591237 for ; Thu, 6 Mar 2003 15:17:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 941885DDA8; Thu, 6 Mar 2003 15:17:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 8B09B5DDA7 for ; Thu, 6 Mar 2003 15:17:26 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h26KIDaj032532; Thu, 6 Mar 2003 22:18:13 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h26KIBT5032528; Thu, 6 Mar 2003 22:18:11 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: New issue: When to configure a LL address From: Mika Liljeberg To: Ted Lemon Cc: zeroconf@merit.edu In-Reply-To: <0C468555-500C-11D7-93FC-00039367340A@nominum.com> References: <0C468555-500C-11D7-93FC-00039367340A@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046981890.32401.14.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 06 Mar 2003 22:18:11 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-03-06 at 21:44, Ted Lemon wrote: > > I was trying to keep DHCP out of it. Unconfiguring the address is, > > IMHO, > > always the responsiblity of the mechanism that configured it in the > > first place. > > BTW, I don't think you *can* keep DHCP out of it and get anything > remotely resembling reliable behavior. Even if you bring DHCP into > it, you still don't get wonderful behavior, but my point is that like > it or not, correct DHCP behavior *is* being constrained by the new > changes to IPv4ll. Oh I agree, the DHCP case needs to be solved but I want a solution for manually configured addresses as well. That's what I wanted to explore. Unfortunately, the DHC WG won't solve manual configuration for us. If we have to discuss DHCP as well to get a good solution, let's do it. MikaL From owner-zeroconf@merit.edu Thu Mar 6 16:49: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 QAA14667 for ; Thu, 6 Mar 2003 16:49:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DEC759123E; Thu, 6 Mar 2003 16:51:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AEA539123F; Thu, 6 Mar 2003 16:51:18 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9C5479123E for ; Thu, 6 Mar 2003 16:51:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F2865DDBF; Thu, 6 Mar 2003 16:51:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 5DEF05DD92 for ; Thu, 6 Mar 2003 16:51:17 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id C131E1B208F; Thu, 6 Mar 2003 15:47:04 -0600 (CST) Date: Thu, 6 Mar 2003 15:51:15 -0600 Subject: Re: New issue: When to configure a LL address Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Mika Liljeberg From: Ted Lemon In-Reply-To: <1046981890.32401.14.camel@devil> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Oh I agree, the DHCP case needs to be solved but I want a solution for > manually configured addresses as well. That's what I wanted to explore. > Unfortunately, the DHC WG won't solve manual configuration for us. It seems like in the manual case, it's not such a big problem, because there the user is actively engaged in the configuration process, so s/he is not going to be surprised if some manual adjustment is required when changing networks. From owner-zeroconf@merit.edu Thu Mar 6 17:03: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 RAA15203 for ; Thu, 6 Mar 2003 17:03:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AD90E9123F; Thu, 6 Mar 2003 17:05:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 734E691240; Thu, 6 Mar 2003 17:05:42 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4EB679123F for ; Thu, 6 Mar 2003 17:05:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 323B35DDB8; Thu, 6 Mar 2003 17:05:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 2F43D5DDAE for ; Thu, 6 Mar 2003 17:05:40 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h26M6Raj000565; Fri, 7 Mar 2003 00:06:27 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h26M6Pij000559; Fri, 7 Mar 2003 00:06:25 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: New issue: When to configure a LL address From: Mika Liljeberg To: Ted Lemon Cc: zeroconf@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046988384.32398.49.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2003 00:06:24 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thu, 2003-03-06 at 23:51, Ted Lemon wrote: > > Oh I agree, the DHCP case needs to be solved but I want a solution for > > manually configured addresses as well. That's what I wanted to explore. > > Unfortunately, the DHC WG won't solve manual configuration for us. > > It seems like in the manual case, it's not such a big problem, because > there the user is actively engaged in the configuration process, so > s/he is not going to be surprised if some manual adjustment is required > when changing networks. I disagree. A mobile device could easily have a static manually configured address and the user might not have the administrator rights for it, or might not have the technical skills to change the configuration. MikaL From owner-zeroconf@merit.edu Thu Mar 6 17:33: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 RAA16052 for ; Thu, 6 Mar 2003 17:33:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8536591240; Thu, 6 Mar 2003 17:35:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 54DEB91241; Thu, 6 Mar 2003 17:35:32 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 40BFF91240 for ; Thu, 6 Mar 2003 17:35:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 22F9D5DDC3; Thu, 6 Mar 2003 17:35:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 019355DDB9 for ; Thu, 6 Mar 2003 17:35:31 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 4FEFF1B20C6; Thu, 6 Mar 2003 16:31:18 -0600 (CST) Date: Thu, 6 Mar 2003 16:35:29 -0600 Subject: Re: New issue: When to configure a LL address Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Mika Liljeberg From: Ted Lemon In-Reply-To: <1046988384.32398.49.camel@devil> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I disagree. A mobile device could easily have a static manually > configured address and the user might not have the administrator rights > for it, or might not have the technical skills to change the > configuration. Eek. But what's the failure scenario there? If it's got a static IP address, and is doing IPv4ll with that address, why is it a problem to communicate with it? From owner-zeroconf@merit.edu Thu Mar 6 17:35:59 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16085 for ; Thu, 6 Mar 2003 17:35:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 19DAF91241; Thu, 6 Mar 2003 17:37:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D997A91244; Thu, 6 Mar 2003 17:37:54 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BD5AA91241 for ; Thu, 6 Mar 2003 17:37:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9CCA75DDC3; Thu, 6 Mar 2003 17:37:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id BF6465DDB9 for ; Thu, 6 Mar 2003 17:37:52 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h26Mceaj000746; Fri, 7 Mar 2003 00:38:40 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h26Mcd4T000739; Fri, 7 Mar 2003 00:38:39 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: New issue: When to configure a LL address From: Mika Liljeberg To: Ted Lemon Cc: zeroconf@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046990318.32397.57.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2003 00:38:39 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-03-07 at 00:35, Ted Lemon wrote: > > I disagree. A mobile device could easily have a static manually > > configured address and the user might not have the administrator rights > > for it, or might not have the technical skills to change the > > configuration. > > Eek. But what's the failure scenario there? If it's got a static IP > address, and is doing IPv4ll with that address, why is it a problem to > communicate with it? Same as with DHCP. Wrong netmask. MikaL From owner-zeroconf@merit.edu Thu Mar 6 17:59:33 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16718 for ; Thu, 6 Mar 2003 17:59:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 960F391245; Thu, 6 Mar 2003 18:01:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 619FD91246; Thu, 6 Mar 2003 18:01:28 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 415C891245 for ; Thu, 6 Mar 2003 18:01:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 27DF55DDC3; Thu, 6 Mar 2003 18:01:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 01BB65DDC0 for ; Thu, 6 Mar 2003 18:01:26 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id F10331B20C6; Thu, 6 Mar 2003 16:57:13 -0600 (CST) Date: Thu, 6 Mar 2003 17:01:25 -0600 Subject: Re: New issue: When to configure a LL address Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Mika Liljeberg From: Ted Lemon In-Reply-To: <1046990318.32397.57.camel@devil> Message-Id: <8E3487CD-5027-11D7-93FC-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Same as with DHCP. Wrong netmask. I'm still not getting it. Why would a device that's manually configured and not user-configurable move to a new network? How would it be the case that it had the wrong netmask to communicate with some device on the local network? From owner-zeroconf@merit.edu Thu Mar 6 18:15:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17990 for ; Thu, 6 Mar 2003 18:15:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5309B91246; Thu, 6 Mar 2003 18:17:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81A0691247; Thu, 6 Mar 2003 18:17:14 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0383A91246 for ; Thu, 6 Mar 2003 18:16:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id C63DB5DDD3; Thu, 6 Mar 2003 18:16:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id B92285DDC3 for ; Thu, 6 Mar 2003 18:16:51 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h26NHdaj000965; Fri, 7 Mar 2003 01:17:39 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h26NHcLS000960; Fri, 7 Mar 2003 01:17:38 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: New issue: When to configure a LL address From: Mika Liljeberg To: Ted Lemon Cc: zeroconf@merit.edu In-Reply-To: <8E3487CD-5027-11D7-93FC-00039367340A@nominum.com> References: <8E3487CD-5027-11D7-93FC-00039367340A@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046992655.32392.80.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2003 01:17:38 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-03-07 at 01:01, Ted Lemon wrote: > > Same as with DHCP. Wrong netmask. > > I'm still not getting it. Why would a device that's manually > configured and not user-configurable move to a new network? It could simply be a laptop with a manually configured address. Or a mobile handset that takes its IP address from the SIM card. Either way, chances are that it was configured by the by the local computer support person and that the user is not a nerd. > How would > it be the case that it had the wrong netmask to communicate with some > device on the local network? Your own example: the user meets somebody over lucnh and they plug their devices together with a cross-over cable [Nah, they'll probably just use Bluetooh or WLAN]. The netmasks don't match ==> no connectivity. MikaL From owner-zeroconf@merit.edu Thu Mar 6 18:33: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 SAA18523 for ; Thu, 6 Mar 2003 18:33:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CF1DF91247; Thu, 6 Mar 2003 18:35:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 988D091248; Thu, 6 Mar 2003 18:35:14 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8081891247 for ; Thu, 6 Mar 2003 18:35:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6786C5DDB3; Thu, 6 Mar 2003 18:35:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 070915DD8D for ; Thu, 6 Mar 2003 18:35:13 -0500 (EST) Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id AF0E31B208F; Thu, 6 Mar 2003 17:30:59 -0600 (CST) Date: Thu, 6 Mar 2003 17:35:11 -0600 Subject: Re: New issue: When to configure a LL address Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Mika Liljeberg From: Ted Lemon In-Reply-To: <1046992655.32392.80.camel@devil> Message-Id: <45D99A35-502C-11D7-93FC-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> I'm still not getting it. Why would a device that's manually >> configured and not user-configurable move to a new network? > > It could simply be a laptop with a manually configured address. Or a > mobile handset that takes its IP address from the SIM card. Either way, > chances are that it was configured by the by the local computer support > person and that the user is not a nerd. > >> How would >> it be the case that it had the wrong netmask to communicate with some >> device on the local network? > > Your own example: the user meets somebody over lucnh and they plug > their > devices together with a cross-over cable [Nah, they'll probably just > use > Bluetooh or WLAN]. The netmasks don't match ==> no connectivity. This seems like severe pilot error to me, not a protocol issue. I don't think we can armor this protocol against malicious behavior on the part of knowledgeable admins. A mobile handset with an IP address in a SIM card is just broken - that makes no sense at all for a mobile device. Likewise a laptop with an address hard-coded by an admin - is the admin stupid, or just looking for a new job? From owner-zeroconf@merit.edu Thu Mar 6 19:00:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20092 for ; Thu, 6 Mar 2003 19:00:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4EA1D91248; Thu, 6 Mar 2003 19:02:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2058E9124A; Thu, 6 Mar 2003 19:02:23 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DBCE991248 for ; Thu, 6 Mar 2003 19:02:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id BD1CA5DDD9; Thu, 6 Mar 2003 19:02:21 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id B5C495DDA0 for ; Thu, 6 Mar 2003 19:02:20 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h27037aj001198; Fri, 7 Mar 2003 02:03:08 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h270365c001193; Fri, 7 Mar 2003 02:03:06 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: New issue: When to configure a LL address From: Mika Liljeberg To: Ted Lemon Cc: zeroconf@merit.edu In-Reply-To: <45D99A35-502C-11D7-93FC-00039367340A@nominum.com> References: <45D99A35-502C-11D7-93FC-00039367340A@nominum.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1046995385.32398.103.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2003 02:03:06 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-03-07 at 01:35, Ted Lemon wrote: > > Your own example: the user meets somebody over lucnh and they plug > > their > > devices together with a cross-over cable [Nah, they'll probably just > > use > > Bluetooh or WLAN]. The netmasks don't match ==> no connectivity. > > This seems like severe pilot error to me, not a protocol issue. I > don't think we can armor this protocol against malicious behavior on > the part of knowledgeable admins. If I've bought a few static IP addresses from my ISP, that's what I'll use. I'd still like my laptop to be able use a LL address when necessary. Preferably without manual intervention. > A mobile handset with an IP address > in a SIM card is just broken - that makes no sense at all for a mobile > device. It does make sense if the device normally uses it as the home address with MIP, or if the network handles mobility below the IP layer. > Likewise a laptop with an address hard-coded by an admin - is > the admin stupid, or just looking for a new job? If the company has a small single site network, the administrator might as well go with manual addressing. There's no particular reason to set up a DHCP server. The point is, we can't assume that everyone configures their routable addresses using DHCP. MikaL From owner-zeroconf@merit.edu Fri Mar 7 04:22: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 EAA15574 for ; Fri, 7 Mar 2003 04:22:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C870991210; Fri, 7 Mar 2003 04:24:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9436A91211; Fri, 7 Mar 2003 04:24:16 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9432F91210 for ; Fri, 7 Mar 2003 04:24:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 77BFF5DE6E; Fri, 7 Mar 2003 04:24:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 4870D5DE2E for ; Fri, 7 Mar 2003 04:24:15 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 1FACC599B4; Fri, 7 Mar 2003 09:24:16 +0000 (GMT) Message-ID: <004201c2e48b$5178bf10$131010ac@aldebaran> From: "Philip Nye" To: "Mika Liljeberg" , "Ted Lemon" Cc: References: Subject: Re: New issue: When to configure a LL address Date: Fri, 7 Mar 2003 09:24:13 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Ted Lemon" > > It seems like in the manual case, it's not such a big problem, because > there the user is actively engaged in the configuration process, so > s/he is not going to be surprised if some manual adjustment is required > when changing networks. I can only partially agree with this. I know of plenty of people who have their laptops configured for them - in a surprising number of cases with static addresses - by some comopany sys-admin, but who would like very much to be able to do zero-config stuff too. The point here is that there is active configuration, but not necessarily by the user. Philip From owner-zeroconf@merit.edu Fri Mar 7 04:42: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 EAA16440 for ; Fri, 7 Mar 2003 04:42:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 506D791211; Fri, 7 Mar 2003 04:44:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E32E91217; Fri, 7 Mar 2003 04:44:46 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EFDFB91211 for ; Fri, 7 Mar 2003 04:44:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id D75285DE6E; Fri, 7 Mar 2003 04:44:44 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id A9D2D5DE2E for ; Fri, 7 Mar 2003 04:44:44 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id B02B2599B2 for ; Fri, 7 Mar 2003 09:44:45 +0000 (GMT) Message-ID: <008101c2e48e$2e4aacd0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <9E3D3A60-4FF9-11D7-93FC-00039367340A@nominum.com> Subject: Re: New issue: When to configure a LL address Date: Fri, 7 Mar 2003 09:44:42 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Ted Lemon" > The problem with your proposed text, Mika, is that it means that > whenever I reboot my airport base station, all my connections break, > because my airport base station is both the router and the DHCP server, > and rebooting it causes my network connection to make the up-to-down > and down-to-up transition. I would think that whether this is the desired behaviour or not depends on how long your base station is down for. If that is a long time (whatever that means) this is probably the desired behaviour. This begs other questions like why do you need to reboot the base station anyway? Wouldn't you expect connections to be broken when you are rebooting your router? What Mika is rightly looking for is a sensible indication of when to decide that a routable address is "not working". This would seem easy enough at first sight but is actually quite difficult. Perhaps active testing of the available connectivity (ARPing the gateway, pinging the DHCP server etc) should only take place if no unicast packets from other hosts (possibly just routable addresses) are received for some idle time. This would mean that if existing connections are up and running, then the host isn't going to suddenly reconfigure, but on start-up or after sleep etc, the interface will have been idle for a while and testing can proceed immediately. Philip From owner-zeroconf@merit.edu Fri Mar 7 07:35: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 HAA26518 for ; Fri, 7 Mar 2003 07:35:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 425DE91218; Fri, 7 Mar 2003 07:37:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 102B49121F; Fri, 7 Mar 2003 07:37:05 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB7E991218 for ; Fri, 7 Mar 2003 07:37:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id AB99C5DEDC; Fri, 7 Mar 2003 07:37:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id F2BE55DE9E for ; Fri, 7 Mar 2003 07:37:03 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h27Cbjaj004448; Fri, 7 Mar 2003 14:37:47 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h27CbgqO004439; Fri, 7 Mar 2003 14:37:42 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: New issue: When to configure a LL address From: Mika Liljeberg To: Philip Nye Cc: Zeroconf Working Group In-Reply-To: <008101c2e48e$2e4aacd0$131010ac@aldebaran> References: <9E3D3A60-4FF9-11D7-93FC-00039367340A@nominum.com> <008101c2e48e$2e4aacd0$131010ac@aldebaran> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1047040659.2473.39.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2003 14:37:42 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-03-07 at 11:44, Philip Nye wrote: > What Mika is rightly looking for is a sensible indication of when to decide > that a routable address is "not working". This would seem easy enough at > first sight but is actually quite difficult. It is. This is basically a movement detection problem and I don't think it is possible to do this reliably with existing protocols. As Thomas suggested, movement detection probably deserves a work item of its own [Or maybe we should just give up and go with IPv6 :-)]. Meanwhile, we need something sensible to make things work at all. My view is that, whenever the validity of the routable address is in doubt, a host should be allowed to have both routable and LL addresses configured at the same time. If I had my way, I would just do that all the time but it has become clear that others violently disagree with that approach. > Perhaps active testing of the available connectivity (ARPing the gateway, > pinging the DHCP server etc) should only take place if no unicast packets > from other hosts (possibly just routable addresses) are received for some > idle time. For outgoing packets, gateway reachability is normally tested only when trying to send packets to the gateway. If the ARP entry for they gateway times out and cannot be renewed, the gateway is unreachable. Having all configured gateways suddenly become unreachable is, to my mind, a pretty good indication that the host is not in the topological position it s What you're proposing is something different. Doing active probing of the gateway while the node is otherwise idle does not make any sense to me. [Active probing of a DHCP server might make sense but figuring that part out is something I'd rather leave to the DHC WG. When to configure or unconfigure a routable address is not really up to this WG to decide]. > This would mean that if existing connections are up and running, > then the host isn't going to suddenly reconfigure, but on start-up or after > sleep etc, the interface will have been idle for a while and testing can > proceed immediately. I agree with the sentiment. We need to be very careful to not force a node to suddenly unconfigure the routable address. I'm more interested in a model that lets use configure a LL address on the side, when one may be needed. MikaL From owner-zeroconf@merit.edu Fri Mar 7 07:42: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 HAA27236 for ; Fri, 7 Mar 2003 07:42:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 73BE99121F; Fri, 7 Mar 2003 07:44:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B2FD91221; Fri, 7 Mar 2003 07:44:32 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0CC9A9121F for ; Fri, 7 Mar 2003 07:44:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id E830D5DEE1; Fri, 7 Mar 2003 07:44:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by segue.merit.edu (Postfix) with ESMTP id 7F32E5DE9E for ; Fri, 7 Mar 2003 07:44:30 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h27CiSKO001672 for ; Fri, 7 Mar 2003 07:44:28 -0500 (EST) Received: from rdroms-w2k.cisco.com (sjc-vpn1-248.cisco.com [10.21.96.248]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA14454 for ; Fri, 7 Mar 2003 07:44:26 -0500 (EST) Message-Id: <4.3.2.7.2.20030306214946.03398e30@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Mar 2003 22:04:30 -0500 To: zeroconf@merit.edu From: Ralph Droms Subject: Re: New issue: When to configure a LL address In-Reply-To: <1046966587.26794.80.camel@devil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk After reading the discussion about this new issue, I've come to the conclusion that the IPv4ll specification simply can't say anything more about when to configure various types of addresses than to proscribe situations in which IPv4ll addresses cause applications to fail or cause the failure of other nodes to communicate on a link. As an example, at present I don't ever want my laptop to configure an IPv4ll address. I have no way to make sensible use of IPv4ll addresses, and any attempt by my laptop to configure an IPv4ll address is wrong and will cause me to spend cycles trying to debug a network problem. And I know what to look for in my interface configuration to figure out that I've been "helped out" with an IPv4ll address. Please correct me if I'm wrong, but I imagine there are many users who can't use a network, know enough to check the interface configuration and see a non-zero IP address, and go looking elsewhere to solve the problem. I don't claim this should be everyone's preference for using IPv4ll addresses. And that's exactly my point. I have yet to see any set of requirements or recommendations that won't cause trouble for someone. I am annoyed enough at the times when my laptop decides to configure an IPv4ll address now. I *certainly* don't want some stronger recommendation that will cause my laptop to be *more* likely to configure an IPv4ll address. I want to turn off IPv4ll until I decide I have a reason to use IPv4ll addresses. I'm not trying to dictate how every device uses IPv4ll. If you have a good reason to try IPv4ll aggressively, that's fine. Don't make me do it. - Ralph From owner-zeroconf@merit.edu Fri Mar 7 07:55: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 HAA28095 for ; Fri, 7 Mar 2003 07:55:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1E64491221; Fri, 7 Mar 2003 07:57:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D83AE91227; Fri, 7 Mar 2003 07:57:21 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B5BE991221 for ; Fri, 7 Mar 2003 07:57:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 950855DEED; Fri, 7 Mar 2003 07:57:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from devil.pp.htv.fi (cs78149057.pp.htv.fi [62.78.149.57]) by segue.merit.edu (Postfix) with ESMTP id 823EF5DEE7 for ; Fri, 7 Mar 2003 07:57:19 -0500 (EST) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) with ESMTP id h27Cvkaj004578; Fri, 7 Mar 2003 14:57:47 +0200 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.7/8.12.7/Debian-2) id h27CvjUf004570; Fri, 7 Mar 2003 14:57:45 +0200 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: New issue: When to configure a LL address From: Mika Liljeberg To: Ralph Droms Cc: zeroconf@merit.edu In-Reply-To: <4.3.2.7.2.20030306214946.03398e30@funnel.cisco.com> References: <4.3.2.7.2.20030306214946.03398e30@funnel.cisco.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1047041862.2469.45.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Date: 07 Mar 2003 14:57:44 +0200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 2003-03-07 at 05:04, Ralph Droms wrote: > After reading the discussion about this new issue, I've come to the > conclusion that the IPv4ll specification simply can't say anything more > about when to configure various types of addresses than to proscribe > situations in which IPv4ll addresses cause applications to fail or cause > the failure of other nodes to communicate on a link. I would go with that! > And I know what to look for in my interface configuration to figure out > that I've been "helped out" with an IPv4ll address. Please correct me if > I'm wrong, but I imagine there are many users who can't use a network, know > enough to check the interface configuration and see a non-zero IP address, > and go looking elsewhere to solve the problem. True enough, although that's a usability issue that has nothing to do with the protocol itself. If the OS gave the user better feedback, such confusion wouldn't arise. > I'm not trying to dictate how every device uses IPv4ll. If you have a good > reason to try IPv4ll aggressively, that's fine. Don't make me do it. I fully agree. If you don't want v4LL, you should have a way to disable it completely. On the other hand, if I choose to enable it, I want it to "just work". MikaL From owner-zeroconf@merit.edu Fri Mar 7 20:55: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 UAA29665 for ; Fri, 7 Mar 2003 20:55:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ABC6491261; Fri, 7 Mar 2003 20:57:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7356E91262; Fri, 7 Mar 2003 20:57:33 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6755391261 for ; Fri, 7 Mar 2003 20:57:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4EAB75E05A; Fri, 7 Mar 2003 20:57:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id D34C05E056 for ; Fri, 7 Mar 2003 20:57:31 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h280gwt19337 for ; Fri, 7 Mar 2003 16:42:58 -0800 Date: Fri, 7 Mar 2003 16:42:57 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: LLMNR Issues List Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk In order to better track LLMNR issues, and ready the LLMNR draft for DNSEXT WG last call, we have created an LLMNR issues list: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html The LLMNR editors would like to encourage those who have not yet read the LLMNR draft to do so ASAP, and email your issues in the format described on the Issues list, to namedroppers@ops.ietf.org, with a CC: to lmnr-editors@internaut.com. The latest LLMNR draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-13.txt From owner-zeroconf@merit.edu Sun Mar 9 20:16: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 UAA19988 for ; Sun, 9 Mar 2003 20:16:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CC1C291228; Sun, 9 Mar 2003 20:18:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6707391297; Sun, 9 Mar 2003 20:18:35 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B779791228 for ; Sun, 9 Mar 2003 20:17:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0591B5E05D; Sun, 9 Mar 2003 20:16:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id D9E565E045 for ; Sun, 9 Mar 2003 20:16:45 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2A1Hdn7025216 for ; Sun, 9 Mar 2003 18:17:39 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id SAA22293 for ; Sun, 9 Mar 2003 18:16:43 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.8/8.12.8) with ESMTP id h2A1Gg7g025618 for ; Mon, 10 Mar 2003 12:16:42 +1100 (EST) Message-ID: <3E6BE77A.5050606@motorola.com> Date: Mon, 10 Mar 2003 12:16:42 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Re: LL24: Weaken the PRN requirement 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 Bernard Aboba wrote: > I would urge this one be rejected. The issue is not whether a single > address conflict can be detected. The issue is whether two conflicting > hosts could then move to another conflicting address. Weakening the PRN > requirement would make this more likely. > Agreed. LL24 should be rejected. - aidan From owner-zeroconf@merit.edu Sun Mar 9 20:32:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22885 for ; Sun, 9 Mar 2003 20:32:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0502491297; Sun, 9 Mar 2003 20:34:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8C9A91299; Sun, 9 Mar 2003 20:34:08 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C2E5091297 for ; Sun, 9 Mar 2003 20:34:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id A90625DEFF; Sun, 9 Mar 2003 20:34:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 4FC8A5DDA6 for ; Sun, 9 Mar 2003 20:34:07 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h2A1Y7i4005248 for ; Sun, 9 Mar 2003 18:34:07 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id SAA25468 for ; Sun, 9 Mar 2003 18:34:05 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.8/8.12.8) with ESMTP id h2A1Y37g026475 for ; Mon, 10 Mar 2003 12:34:03 +1100 (EST) Message-ID: <3E6BEB8B.7070102@motorola.com> Date: Mon, 10 Mar 2003 12:34:03 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Support: LL21 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 don't think the TTL=255 check adds anything significant from a security point of view, or from an "incentive" p.o.v. TTL=1 isn't going to prevent leakage in my opinion since leakage will occur with packets that do *not* have TTL=1, because leakage comes from hosts that don't understand IPv4-LL. I accept that setting TTL=255 "for now" in an attempt to help with compatibilty problems is not a useful long term solution. I agree with Robert Elz that the whole TTL thing should just be deleted. Hand in hand with my position goes: Reject: LL3 Reject: LL21 From owner-zeroconf@merit.edu Sun Mar 9 20:40:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24403 for ; Sun, 9 Mar 2003 20:40:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7810B91299; Sun, 9 Mar 2003 20:42:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47B549129B; Sun, 9 Mar 2003 20:42:26 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4BF6B91299 for ; Sun, 9 Mar 2003 20:42:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2BEF65DDBC; Sun, 9 Mar 2003 20:42:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id 9A1525DDA6 for ; Sun, 9 Mar 2003 20:42:24 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h2A1gKBA012148 for ; Sun, 9 Mar 2003 18:42:20 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id SAA15861 for ; Sun, 9 Mar 2003 18:40:25 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.8/8.12.8) with ESMTP id h2A1gA7g026959 for ; Mon, 10 Mar 2003 12:42:10 +1100 (EST) Message-ID: <3E6BED72.9080402@motorola.com> Date: Mon, 10 Mar 2003 12:42:10 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Accept: LL9 Introduction to make it clear this is not a replacement for a DHCP assigned address Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have no problem with this. - aidan From owner-zeroconf@merit.edu Sun Mar 9 20:46:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25555 for ; Sun, 9 Mar 2003 20:46:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2FCC89129B; Sun, 9 Mar 2003 20:48:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E47089129C; Sun, 9 Mar 2003 20:48:34 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A77959129B for ; Sun, 9 Mar 2003 20:48:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8A4085E149; Sun, 9 Mar 2003 20:48:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by segue.merit.edu (Postfix) with ESMTP id 0C7385DDA6 for ; Sun, 9 Mar 2003 20:48:12 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h2A1ldc3006271 for ; Sun, 9 Mar 2003 18:47:39 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id SAA28874 for ; Sun, 9 Mar 2003 18:48:09 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.8/8.12.8) with ESMTP id h2A1m77g027262 for ; Mon, 10 Mar 2003 12:48:07 +1100 (EST) Message-ID: <3E6BEED7.4000905@motorola.com> Date: Mon, 10 Mar 2003 12:48:07 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Reject: LL25 Delete inappropriate "send" requirement on LL nodes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit This is a definitional thing. Hosts that correctly implement IPv4-LL will not forward packets to routers. - aidan From owner-zeroconf@merit.edu Sun Mar 9 20:52:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26739 for ; Sun, 9 Mar 2003 20:52:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A1FAA9129C; Sun, 9 Mar 2003 20:54:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 677909129E; Sun, 9 Mar 2003 20:54:53 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 639C89129C for ; Sun, 9 Mar 2003 20:54:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4D0D25DF9C; Sun, 9 Mar 2003 20:54:52 -0500 (EST) 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 F0F135DE16 for ; Sun, 9 Mar 2003 20:54:51 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h2A1sJ05019565 for ; Sun, 9 Mar 2003 18:54:19 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id SAA00069 for ; Sun, 9 Mar 2003 18:54:17 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.8/8.12.8) with ESMTP id h2A1sF7g027574 for ; Mon, 10 Mar 2003 12:54:15 +1100 (EST) Message-ID: <3E6BF047.3020001@motorola.com> Date: Mon, 10 Mar 2003 12:54:15 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Re: Support: LL21 References: <3E6BEB8B.7070102@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Aidan Williams wrote: > Reject: LL21 Oops. That should be "Reject: LL29" - aidan From owner-zeroconf@merit.edu Wed Mar 12 16:01: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 QAA22478 for ; Wed, 12 Mar 2003 16:01:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6370691214; Wed, 12 Mar 2003 16:03:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D8BC9121F; Wed, 12 Mar 2003 16:03:52 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1CEC291214 for ; Wed, 12 Mar 2003 16:03:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D1345E490; Wed, 12 Mar 2003 16:02:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 24EB85E491 for ; Wed, 12 Mar 2003 16:02:26 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.7/8.12.7) with ESMTP id h2CL2PnR013180 for ; Wed, 12 Mar 2003 13:02:25 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 12 Mar 2003 13:02:20 -0800 Received: from [17.202.44.119] (chesh7.apple.com [17.202.44.119]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h2CL2P016122 for ; Wed, 12 Mar 2003 13:02:25 -0800 (PST) Message-Id: <200303122102.h2CL2P016122@scv1.apple.com> Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Date: Wed, 12 Mar 2003 13:02:25 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Zeroconf" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk John C. Welch wrote: >I can see a *disadvantage* in that out of the two leading users of LL >*now*, neither uses 255. I think you meant "neither uses 1". Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Mar 12 16:48:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24732 for ; Wed, 12 Mar 2003 16:48:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D333191241; Wed, 12 Mar 2003 16:50:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98B0891245; Wed, 12 Mar 2003 16:50:19 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 620D891241 for ; Wed, 12 Mar 2003 16:50:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 46A005DEA0; Wed, 12 Mar 2003 16:50:18 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id CD4875DD93 for ; Wed, 12 Mar 2003 16:50:17 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA00761 for ; Wed, 12 Mar 2003 16:50:17 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA03015 for ; Wed, 12 Mar 2003 16:46:54 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h2CLkV0x025492 for ; Wed, 12 Mar 2003 16:46:32 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 12 Mar 2003 16:46:25 -0500 Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200303122102.h2CL2P016122@scv1.apple.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 03/12/2003 16:02, "Stuart Cheshire" wrote: >> I can see a *disadvantage* in that out of the two leading users of LL >> *now*, neither uses 255. > > I think you meant "neither uses 1". Right...neither uses 1. Not that it's anything but academic at this point. john -- John C. Welch Consultant III Office Computing Practice (IS) (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Mar 13 02:18:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22353 for ; Thu, 13 Mar 2003 02:18:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6B53C9135D; Thu, 13 Mar 2003 02:19:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 262179126C; Thu, 13 Mar 2003 02:19:12 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC1F89135B for ; Thu, 13 Mar 2003 02:19:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id DAACD5E48A; Thu, 13 Mar 2003 02:17:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 628685E487 for ; Thu, 13 Mar 2003 02:17:01 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.8/8.12.8) with ESMTP id h2D7H093029597 for ; Wed, 12 Mar 2003 23:17:00 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 12 Mar 2003 23:16:56 -0800 Received: from [17.219.195.31] ([17.219.195.31]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h2D7H0429070 for ; Wed, 12 Mar 2003 23:17:00 -0800 (PST) Message-Id: <200303130717.h2D7H0429070@scv1.apple.com> Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Date: Wed, 12 Mar 2003 23:17:00 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Mika Liljeberg wrote: >Proxy ARP does not require your authorization. Your point, I guess, is >that you can fix your own router. Not everybody can. No, that was not my point. My point was just that to use the term "proxy ARP" in a meaningful way, one needs to know what the word "proxy" means. An entity that gives correct answers on my behalf may be called a "proxy". An entity that gives incorrect answers on my behalf (that disagree with the answers I'm trying to give at the same time) is not a "proxy", it is an "impostor". When a device indiscriminately answers ARP requests for addresses of which it actually has no knowledge, calling that entity a "proxy" imbues it with an air of legitimacy to which it is not entitled. Lets just try to use clear terminology: When a device gives correct ARP responses for addresses it knows about, we can call that "proxy ARP". When a device presumes to make up ARP responses for addresses it knows nothing about, we should use "indiscriminate ARP", or some similar term to indicate that the device is giving answers that it is not qualified to give. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Mar 13 02:18: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 CAA22389 for ; Thu, 13 Mar 2003 02:18:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C19B99135B; Thu, 13 Mar 2003 02:20:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 924FD9126C; Thu, 13 Mar 2003 02:20:16 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8233A91268 for ; Thu, 13 Mar 2003 02:20:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 48C775E0A7; Thu, 13 Mar 2003 02:19:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 0C1E85E0A5 for ; Thu, 13 Mar 2003 02:19:23 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.8/8.12.8) with ESMTP id h2D7JMX6029748 for ; Wed, 12 Mar 2003 23:19:22 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 12 Mar 2003 23:19:17 -0800 Received: from [17.219.195.31] ([17.219.195.31]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h2D7JL429544 for ; Wed, 12 Mar 2003 23:19:21 -0800 (PST) Message-Id: <200303130719.h2D7JL429544@scv1.apple.com> Subject: Re: [LL29] Link-local sources should specify TTL=1 Date: Wed, 12 Mar 2003 23:19:21 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Erik Guttman wrote: >TTL SHOULD be 1. If an application explicitely sets the TTL to >some other value, this should be used. (No mention of processing >on the basis of the TTL of received packets is made.) > >The reasons for my preference of this alternative are (focussing >on new arguments, not yet presented on the list): > > - Applications have the ability to set this value and interpret > it for received packets. Since this is available today using > standard interfaces, requiring the TTL to be set to 255 would > potentially *break* existing applications. Hypocrates said > "Do no harm." (This is a reason to reject [LL3]) I think "potentially" is a weak argument here. Mac OS 9 and X have both set the TTL to 255 for years, and I've never heard of any application having a problem. > - The suggestion in LL3 that 'eventually' filtering on the basis > of received packets having a TTL=255 cannot be carried out today > because of the prevelance of hosts which do not do this. Those > hosts which do this filtering are problematic for this reason. > There is no provision for when 'eventually' will occur. Thus, > the provision complicates the protocol specification but adds > no immediate value. (These are reasons to reject [LL3]). I wholeheartedly agree that if the document specifies what the TTL should be, but no one is checking the TTL, then there's a risk that implementations will get it wrong, which diminishes the value of specifying what it should be in the first place. It is for exactly this reason that the Rendezvous Conformance Test, which vendors have to pass to license the Apple Rendezvous logo for their products, checks that the device both sets the IP TTL to 255, and also checks whether the device ignores packets sent with a TTL other than 255. A partial list of vendors with Rendezvous products can be seen at . > - There are scenarios in which a host can have a routable address > and receive packets from an on-link host with a link-local address. > This host can then forward the location (in a reference, referral, > URI, etc) off-link. It is then possible for the off-link host to > use this link-local address as a destination address. If the TTL > for this is set to 255, the packet will be forwarded along the > default path (probably), unless routers have been explicitely > configured to not forward packets in the 169.254/16 prefix. Since > many such routers exist and will continue to exist, this means that > LL traffic with a TTL != 1 will escape off-link. (This is a reason > to reject [LL3] and [LL21]). This argument does not hold water. Does this hypothetical "off-link host" implement IPv4LL or not? If yes, then it will never send an LL packet to a router for forwarding. If no, then changing this spec to require TTL=1 is pointless because the "off-link host" doesn't implement this spec. I'm sorry to have to say this, but the arguments supporting TTL=1 are notable for their quantity rather than their quality. Many people have spoken in support of TTL=1, but none of the arguments given hold up under scrutiny. I fear that we risk declaring consensus here based on the volume of arguments offered, despite the fact that when prodded with a little scrutiny, those arguments are discovered to have the durability of soap bubbles. > - A packet sent with a TTL=255, link-local source address to a > non-link-local multicast address will be forwarded by a router > which supports multicast routing and does not know to decline to > forward packets with a 169.254/16 source address prefix. This > will result in (given the nature of dense-mode multicast routing > protocols) a flood of link-local source addressed packets to *all > links* in the network, at least for the first such packet trans- > mitted. (This is a very good reason to reject LL3 and LL21.) Given that Mac OS and Windows have been sending packets with TTL >> 1 for five years, how many documented instances of this problem have been reported? For this problem to happen, you need a network with multicast routing enabled. Sad to say, but such networks are rare, even today. In addition, you need the DHCP server on that network to fail. You need some application that's sending to a non-link-local multicast destination. Finally, you need IP routers that don't know they're not supposed to forward LL packets. When this confluence of events occurs together, what happens? Does the sky fall? No, all that happens is that, until the DHCP server is fixed, some packets go out with source addresses such that the receivers can't reply to them. Does this destroy any hardware? Does this melt down the network? Does this impede the ability of users to use the network? No. Those are packets that would have gone out anyway -- albeit with a different source address -- so that traffic would have existed on the network anyway. If we'd published this spec five years ago, then by now there would be a chance that multicast-capable routers would know not to forward packets with LL source addresses. I submit that the sooner we publish a spec, the sooner router vendors will start shipping products that don't forward LL packets. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Mar 13 02:18: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 CAA22443 for ; Thu, 13 Mar 2003 02:18:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C9A4291268; Thu, 13 Mar 2003 02:20:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 356F99135E; Thu, 13 Mar 2003 02:20:45 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E3A2091268 for ; Thu, 13 Mar 2003 02:20:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id D02A65E09C; Thu, 13 Mar 2003 02:20:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 627975E08A for ; Thu, 13 Mar 2003 02:20:42 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.12.8/8.12.8) with ESMTP id h2D7Kf93000270 for ; Wed, 12 Mar 2003 23:20:41 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 12 Mar 2003 23:20:41 -0800 Received: from [17.219.195.31] ([17.219.195.31]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h2D7Kf026273 for ; Wed, 12 Mar 2003 23:20:41 -0800 (PST) Message-Id: <200303130720.h2D7Kf026273@scv2.apple.com> Subject: Re: LL3, LL21 and potential new issue Date: Wed, 12 Mar 2003 23:20:41 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Zeroconf Working Group" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Philip Nye wrote: >However, there could be other ways around this issue: We could disallow >or discourage packets with a LL source address being sent to any multicast >destination address outside the 224.0.0/24 link-local scoped multicast >prefix. This would seem very much in keeping with the principle of LL. Nice idea, but there *aren't* any SSM multicast addresses in the 224.0.0/24 prefix. There *aren't* any dynamically assigned multicast addresses in the 224.0.0/24 prefix. This restriction effectively says that LL hosts can't use multicast, except for a few IANA-assigned well-known addresses in 224.0.0/24. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Mar 13 02:19: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 CAA22543 for ; Thu, 13 Mar 2003 02:19:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 885289135E; Thu, 13 Mar 2003 02:21:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 555CB91361; Thu, 13 Mar 2003 02:21:28 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A0DCA9135E for ; Thu, 13 Mar 2003 02:21:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E6385E09D; Thu, 13 Mar 2003 02:21:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id F33415E08A for ; Thu, 13 Mar 2003 02:21:23 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.8/8.12.8) with ESMTP id h2D7LN93000386 for ; Wed, 12 Mar 2003 23:21:23 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 12 Mar 2003 23:21:18 -0800 Received: from [17.219.195.31] ([17.219.195.31]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h2D7LM429996 for ; Wed, 12 Mar 2003 23:21:23 -0800 (PST) Message-Id: <200303130721.h2D7LM429996@scv1.apple.com> Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Date: Wed, 12 Mar 2003 23:21:23 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Zeroconf Working Group" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Thomas Narten wrote: >This is clearly a broken configuration and will result in LL in >general not working. I.e., two nodes, both on Link A, both using LL >addresses, won't be able to communicate. The Router will grab their >traffic and forward it to the wrong place. Right? No, Router A is not "grabbing" traffic. A malicious attacker on Link A is deliberately sending traffic to Router A to exploit its misconfiguration in order to print offensive material on the LL printer on Link B. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Mar 13 02:19:41 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22564 for ; Thu, 13 Mar 2003 02:19:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A97D09126C; Thu, 13 Mar 2003 02:21:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C9B79135E; Thu, 13 Mar 2003 02:21:18 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B75F9126C for ; Thu, 13 Mar 2003 02:21:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 479835E09C; Thu, 13 Mar 2003 02:21:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 9DA525E08A for ; Thu, 13 Mar 2003 02:21:14 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.8/8.12.8) with ESMTP id h2D7LD93000370 for ; Wed, 12 Mar 2003 23:21:13 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 12 Mar 2003 23:21:09 -0800 Received: from [17.219.195.31] ([17.219.195.31]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h2D7LD429988 for ; Wed, 12 Mar 2003 23:21:13 -0800 (PST) Message-Id: <200303130721.h2D7LD429988@scv1.apple.com> Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Date: Wed, 12 Mar 2003 23:21:13 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Zeroconf Working Group" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Philip Nye wrote: >So here is a scenario: > > Link A Link B >+--------+Gateway-A+--------+Gateway-B+--> to the Internet > > >Gateway-A is the default gateway (for global traffic) on link A >Gateway-B ditto for Link B > >If these gateways are not LL aware they will simply forward LL packets >which reach them on towards the Internet. > >This scenario must be quite common. > >Now suppose that Link A and Link B have LL hosts on them. > >The only additional requirement for a malicious host on Link A to send a >packet to a LL destination on Link B is that either Gateway-A or Gateway-B >has been configured with a route which directs the LL prefix onto Link B. > >While this might be regarded as a misconfiguration, it is not a huge one >and would likely go unnoticed. For example one or other gateway might be a >general purpose machine which a user has added a route to precicely so that >they can participate in LL exchanges on Link B. > >Furthermore additional Gateways and networks can be interposed between Link >A and Link B without changing the basic principle but making the attack >more remote. > >Philip Philip, you didn't say so explicitly, but I assume you're giving this as an example of a situation where the TTL=255 check would give devices on Link B an assurance that the packets originated locally, in spite of bad behaviour by the routers serving Link B. Mika Liljeberg wrote: >Granted. I could use that same scenario to argue for TTL=1. :) No, you can't. You can't assume that a remote hacker will neatly conform with what you request, in order to make their attack not work. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Mar 13 02:21:36 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22688 for ; Thu, 13 Mar 2003 02:21:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4427D91361; Thu, 13 Mar 2003 02:23:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B18F91364; Thu, 13 Mar 2003 02:23:29 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CF46791361 for ; Thu, 13 Mar 2003 02:23:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id BAD7A5E08B; Thu, 13 Mar 2003 02:23:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 524045E08A for ; Thu, 13 Mar 2003 02:23:28 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.8/8.12.8) with ESMTP id h2D7NRX6000307 for ; Wed, 12 Mar 2003 23:23:27 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 12 Mar 2003 23:23:23 -0800 Received: from [17.219.195.31] ([17.219.195.31]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h2D7NRj07496 for ; Wed, 12 Mar 2003 23:23:27 -0800 (PST) Message-Id: <200303130723.h2D7NRj07496@scv3.apple.com> Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Date: Wed, 12 Mar 2003 23:23:27 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Zeroconf" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Robert Elz wrote: >The ability to detect errant packets is similarly useless in general. >You keep on citing that ability as a feature, but you have yet to give >a reason how it ever achieves anything (in general). Mika Liljeberg wrote: >Sure. I just don't see a TTL=255 check helping any. LL addresses have no >value as a secrity measure and people should not be bamboozled to think >that they have. This is IETF political correctness, and I do not believe it is helpful. In the IETF fantasy parallel universe, there are no firewalls, and everyone uses strong end-to-end security all the time. I make the following statement will full knowledge that it is IETF heresy: In the world I live in, firewalls are common, and people see real value in reducing the population of potential attackers by such methods. I personally do not like firewalls because they contribute to the famous "fog on the Internet", so I do not run one at my house. I also run an open 802.11 network with no WEP. Unfortunately not all of the devices in my house have strong end-to-end security. For example, my network printer supports LPR, but has NO access control of any kind. How do I stop it being abused? You can lecture me, and I can lecture the printer vendor about end-to-end security, and in the IETF fantasy parallel universe they send me new firmware the next day, but here in the real world, that doesn't solve my problem. Here in the real world I solve my problem by arranging for the printer to have only a link-local address. I could achieve a similar effect by installing a firewall, but that is just one more piece of hardware to buy and install and configure and maintain. This precaution I take prevents the printer from being directly accessed by any device outside the local link, thereby reducing the population of potential attackers from the entire planet to just people within range of my wireless base stations. This is a level of risk I am willing to accept. If anyone really wants to take time out from IETF meetings next week drive to my house and abuse my printer, I won't really be annoyed. In fact, I'll probably be amused that someone who is gainfully employed has time to waste on such stupidity. On the other hand, if I got junk pages spewing out of my printer at the same rate that spam email shows up in my email account (continuously, all day, every day) then I would get very annoyed very quickly. I do not understand the people who refuse to see the benefit in reducing the population of potential attackers from the entire planet to just people within close physical proximity. I fully agree that I would love to have strong end-to-end security all the time, but here in the real world you can't always have what you want, and in the absence of perfect security, a mechanism for knowing that a packet originated on the local link is one very useful tool in the networking toolbox. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Mar 13 02:22: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 CAA22704 for ; Thu, 13 Mar 2003 02:22:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EDF5591364; Thu, 13 Mar 2003 02:24:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6FF191363; Thu, 13 Mar 2003 02:24:05 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8F08091364 for ; Thu, 13 Mar 2003 02:24:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 718FE5E0A5; Thu, 13 Mar 2003 02:24:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 33BF55E08A for ; Thu, 13 Mar 2003 02:24:04 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.8/8.12.8) with ESMTP id h2D7O3X6000417 for ; Wed, 12 Mar 2003 23:24:03 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 12 Mar 2003 23:24:03 -0800 Received: from [17.219.195.31] ([17.219.195.31]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h2D7O3026841 for ; Wed, 12 Mar 2003 23:24:03 -0800 (PST) Message-Id: <200303130724.h2D7O3026841@scv2.apple.com> Subject: Re: New issue: When to configure a LL address Date: Wed, 12 Mar 2003 23:24:03 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Ralph Droms wrote: >As an example, at present I don't ever want my laptop to configure an >IPv4ll address. I have no way to make sensible use of IPv4ll addresses, >and any attempt by my laptop to configure an IPv4ll address is wrong and >will cause me to spend cycles trying to debug a network problem. I think you need to think further ahead. Today, if you have no other devices that can use IPv4LL addresses, then I agree that your laptop can't make much use of them. However, try to think a year from now. Your laptop does IPv4LL. Your printer does IPv4LL. You are giving a presentation in ten minutes and you need to print your notes to hand out. Your DHCP server's power supply has overheated and burned out, and you don't have time to fix it. Are you really going to complain if the printer and laptop configure IPv4LL addresses and you are able to print and get to your meeting on time? You are right that it would be good to have your laptop display an alert saying, "Your computer has lost Internet connectivity. Only communication with local devices will be possible." I think that's a great idea, and we should do it on OS X, but let's not confuse user-interface design with protocol design. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Mar 13 02:23:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22753 for ; Thu, 13 Mar 2003 02:23:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D2EBB91363; Thu, 13 Mar 2003 02:25:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9BEE191365; Thu, 13 Mar 2003 02:25:21 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A8DD491363 for ; Thu, 13 Mar 2003 02:25:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 905AF5E08B; Thu, 13 Mar 2003 02:25:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 22A375DF33 for ; Thu, 13 Mar 2003 02:25:20 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.12.8/8.12.8) with ESMTP id h2D7PJX6000609 for ; Wed, 12 Mar 2003 23:25:19 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 12 Mar 2003 23:25:19 -0800 Received: from [17.219.195.31] ([17.219.195.31]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h2D7PJ027070 for ; Wed, 12 Mar 2003 23:25:19 -0800 (PST) Message-Id: <200303130725.h2D7PJ027070@scv2.apple.com> Subject: Re: New issue: When to configure a LL address Date: Wed, 12 Mar 2003 23:25:19 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Zeroconf Working Group" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Philip Nye wrote: >This begs other questions like why do you need to reboot the >base station anyway? Wouldn't you expect connections to be >broken when you are rebooting your router? Philip, you have made many smart comments in the past, which makes this one all the more surprising. I am sorry to have to say that I am shocked and horrified to see this comment on an IETF mailing list. If one were giving an introductory networking lecture and had to describe the single most important feature of the Internet that distinguished it from its predecessors, it is this: The Internet uses stateless connectionless packet switching. The whole point of the Internet is that all the connection state is at the endpoints; you can reboot (or even replace) intermediate nodes without breaking all the connections going through those nodes. Arguably the most famous research paper in the history of networking is "End-To-End Arguments In System Design" by Saltzer, Reed and Clark. Anyone who has not read it, should. [Aside: This is one of the (many) reasons to dislike NAT: NAT introduces a point of failure for Internet connections where previously there was none.] Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Mar 13 02:24: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 CAA22784 for ; Thu, 13 Mar 2003 02:24:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7346B91366; Thu, 13 Mar 2003 02:26:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A58A91365; Thu, 13 Mar 2003 02:26:40 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 30D3F91367 for ; Thu, 13 Mar 2003 02:26:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0A38C5E0A7; Thu, 13 Mar 2003 02:26:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 93E9B5E08A for ; Thu, 13 Mar 2003 02:26:38 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.12.8/8.12.8) with ESMTP id h2D7QcX6000784 for ; Wed, 12 Mar 2003 23:26:38 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 12 Mar 2003 23:26:33 -0800 Received: from [17.219.195.31] ([17.219.195.31]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h2D7Qb400982 for ; Wed, 12 Mar 2003 23:26:37 -0800 (PST) Message-Id: <200303130726.h2D7Qb400982@scv1.apple.com> Subject: Re: New issue: When to configure a LL address Date: Wed, 12 Mar 2003 23:26:37 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Zeroconf Working Group" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Philip Nye wrote: >What Mika is rightly looking for is a sensible indication of >when to decide that a routable address is "not working". This >would seem easy enough at first sight but is actually quite >difficult. No argument there. >Perhaps active testing of the available connectivity (ARPing the >gateway, pinging the DHCP server etc) should only take place if >no unicast packets from other hosts (possibly just routable >addresses) are received for some idle time. This would mean that >if existing connections are up and running, then the host isn't >going to suddenly reconfigure, but on start-up or after sleep >etc, the interface will have been idle for a while and testing >can proceed immediately. Those of us who have spent years thinking about this problem all seem eventually to come to the same conclusion: The one-and-only truly accurate way to determine whether operation A will succeed is to try doing operation A, and see if it succeeds. (Those with a formal computer science background will recognize this as a trivial re-statement of the halting problem.) Any attempt to determine whether operation A (e.g. connect to www.amazon.com) will succeed by first performing some different operation B (e.g. ping the DHCP server) is plagued by false positives and false negatives. False positive: Just because the DHCP server responds doesn't mean you have a path all the way to www.amazon.com and back. False negative: Just because the DHCP server doesn't respond doesn't mean you *don't* have a path all the way to www.amazon.com and back. Therefore, the best and simplest test to see whether a routable address will work is to try it, and if it does not work, to try an alternative instead. Another corollary of the halting problem is that in general you can't prove that something won't succeed eventually, if you wait long enough. Therefore, you can't try the alternatives serially, waiting for one to fail before you try the next. You have to be able to try them in parallel, and take the first success you get (they don't have to start simultaneously, but additional attempts do have to be able to run concurrently in the event that the first attempt does not yield a quick result). The conclusion to all this is that *if* you want to make a truly reliable system, then it has to be willing to have both a routable and an LL address at the same time, and advertise both to its peers, and its peers have to be willing to try both -- possibly concurrently -- in order to determine which, if either, will work. Note that I said "*if*" in the sentence above. The constraints imposed by existing deployed software may make this solution hard to do in practice, but if the goal were to make truly reliable systems, this is the way to do it. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Mar 13 07:42:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28429 for ; Thu, 13 Mar 2003 07:42:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1E51491367; Thu, 13 Mar 2003 07:44:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E17F891366; Thu, 13 Mar 2003 07:44:47 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 709BC91367 for ; Thu, 13 Mar 2003 07:44:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5B7925E0FC; Thu, 13 Mar 2003 07:44:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id E18705E0F9 for ; Thu, 13 Mar 2003 07:44:45 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id HAA12320 for ; Thu, 13 Mar 2003 07:44:45 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id HAA02325 for ; Thu, 13 Mar 2003 07:39:38 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h2DCdb0x007082 for ; Thu, 13 Mar 2003 07:39:38 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 13 Mar 2003 07:39:36 -0500 Subject: Re: New issue: When to configure a LL address From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200303130724.h2D7O3026841@scv2.apple.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 03/13/2003 02:24, "Stuart Cheshire" wrote: > Today, if you have no other devices that can use IPv4LL addresses, then I > agree that your laptop can't make much use of them. > > However, try to think a year from now. How about months from now? Benetton is implementing short range RF tagging for inventory control. Bet they aren't using IP. Why? Because without a v4LL standard they have to build a dhcp client into a chip in your underwear, that has a range of about 1.5 meters and is a 1K eeprom. This is the *perfect* situation for LL. There is NO earthly, sane reason for clothing to have a routable address. Besides, in a week, Benetton would eat the v4 space alive anyway. All you need is a unique address and a chip GUID. The ip address only has to be unique for the truck, the shop, etc, and then *only* when it's in range of a reader, so that it can establish a connection for the reader. And it's not just clothing. Food chains are looking at this *very* seriously, as are retail merchants of all stripes. Wouldn't it be nice if they could just use a standard transport mechanism, instead of rolling their own? john -- John C. Welch Consultant III Office Computing Practice (IS) (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Mar 13 08:08: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 IAA29103 for ; Thu, 13 Mar 2003 08:08:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1C03A91367; Thu, 13 Mar 2003 08:10:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D922C9136B; Thu, 13 Mar 2003 08:10:39 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B971C91367 for ; Thu, 13 Mar 2003 08:10:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9C2EC5E10D; Thu, 13 Mar 2003 08:10:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 5806E5E104 for ; Thu, 13 Mar 2003 08:10:38 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h2DDAbpY017959 for ; Thu, 13 Mar 2003 05:10:37 -0800 (PST) Date: Thu, 13 Mar 2003 08:10:37 -0500 (EST) From: Ralph Droms To: Zeroconf Subject: Re: New issue: When to configure a LL address In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I don't doubt that months from now or a year from now *someone* will want to use IPv4LL addresses. *I* don't use IPv4LL addresses today. I will be happy to use them at a time that's appropriate for me. Until I start using IPv4LL addresses, I don't want a protocol spec or other devices using IPv4LL addresses or IPv4 implementations to have a negative impact on my use of globally routed addresses. Furthermore, I'm sure there are a lot of IP users (most of whom don't know they are even using IP) who are in the same situation. Stuart mentioned that we should keep the protocol and the user interface separate. OK, but current implementations of IPv4LL have had the same inadequate user interface for a number of years, and I see no indication that future implementations will have a better interface. So, knowing that existing IPv4LL implementations have a negative impact on my use of routable addresses, and seeing that there is the potential for the IPv4LL specs to have an impact on the use of DHCP for address assignment, we need to be very careful that anything we do here doesn't cause additional problems with the use of routable addresses. - Ralph On Thu, 13 Mar 2003, John C. Welch wrote: > On 03/13/2003 02:24, "Stuart Cheshire" wrote: > > > Today, if you have no other devices that can use IPv4LL addresses, then I > > agree that your laptop can't make much use of them. > > > > However, try to think a year from now. > > How about months from now? Benetton is implementing short range RF tagging > for inventory control. Bet they aren't using IP. Why? Because without a v4LL > standard they have to build a dhcp client into a chip in your underwear, > that has a range of about 1.5 meters and is a 1K eeprom. > > This is the *perfect* situation for LL. There is NO earthly, sane reason for > clothing to have a routable address. Besides, in a week, Benetton would eat > the v4 space alive anyway. All you need is a unique address and a chip GUID. > The ip address only has to be unique for the truck, the shop, etc, and then > *only* when it's in range of a reader, so that it can establish a connection > for the reader. > > And it's not just clothing. Food chains are looking at this *very* > seriously, as are retail merchants of all stripes. Wouldn't it be nice if > they could just use a standard transport mechanism, instead of rolling their > own? > > john > > -- > John C. Welch > Consultant III > Office Computing Practice (IS) > (617) 253 - 1368 work > (508) 579 - 7380 cell > bynkii2 AIM > > > From owner-zeroconf@merit.edu Thu Mar 13 08:20: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 IAA29579 for ; Thu, 13 Mar 2003 08:20:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E16CA9136B; Thu, 13 Mar 2003 08:20:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A23839136F; Thu, 13 Mar 2003 08:20:40 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3FB579136B for ; Thu, 13 Mar 2003 08:20:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 573CE5E4D3; Thu, 13 Mar 2003 08:20:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 42B7B5E127 for ; Thu, 13 Mar 2003 08:20:23 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA22913 for ; Thu, 13 Mar 2003 08:20:23 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA04849 for ; Thu, 13 Mar 2003 08:20:23 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h2DDKK0x011781 for ; Thu, 13 Mar 2003 08:20:21 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 13 Mar 2003 08:20:18 -0500 Subject: Re: New issue: When to configure a LL address From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 03/13/2003 08:10, "Ralph Droms" wrote: > So, knowing that existing IPv4LL implementations have a negative impact on > my use of routable addresses, and seeing that there is the potential for > the IPv4LL specs to have an impact on the use of DHCP for address > assignment, we need to be very careful that anything we do here doesn't > cause additional problems with the use of routable addresses. Because why? Stuart pointed out, and quite correctly, that IPv4LL has been around for years, and the internet hasn't melted down. What, the internet suddenly got fragile? john -- John C. Welch Consultant III Office Computing Practice (IS) (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Mar 13 08:57:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00597 for ; Thu, 13 Mar 2003 08:57:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 970299136F; Thu, 13 Mar 2003 08:59:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6824191370; Thu, 13 Mar 2003 08:59:31 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5AA909136F for ; Thu, 13 Mar 2003 08:59:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 48FEE5E0B2; Thu, 13 Mar 2003 08:59:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by segue.merit.edu (Postfix) with ESMTP id D10E85E090 for ; Thu, 13 Mar 2003 08:59:29 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2DDxRvD003995 for ; Thu, 13 Mar 2003 08:59:27 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-248.cisco.com [161.44.149.248]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA29507 for ; Thu, 13 Mar 2003 08:59:26 -0500 (EST) Message-Id: <4.3.2.7.2.20030313085201.00b9fed8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 08:59:27 -0500 To: Zeroconf From: Ralph Droms Subject: Re: New issue: When to configure a LL address In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk The impact I'm talking about is on the unannounced use of IPv4LL addresses by my laptop, which causes loss of network connectivity with no associated indication of why connectivity has been lost. The Internet hasn't melted down, but *I've* come damn close to melting down several times after wasting time trying to diagnose and fix the problem. The requirement to look at the device's assigned IP address and then deduce that it is an IPv4LL address because I remember the prefix for IPv4LL addresses or because I click a "More Info" button and happen to see the "Auto-Configuration Active" box checked is unacceptable. Although, as Stuart said, this problem is an interface problem and not a protocol problem, either way it is an implementation problem that negatively impacts my usual use of routable addresses. - Ralph At 08:20 AM 3/13/2003 -0500, John C. Welch wrote: >On 03/13/2003 08:10, "Ralph Droms" wrote: > > > So, knowing that existing IPv4LL implementations have a negative impact on > > my use of routable addresses, and seeing that there is the potential for > > the IPv4LL specs to have an impact on the use of DHCP for address > > assignment, we need to be very careful that anything we do here doesn't > > cause additional problems with the use of routable addresses. > >Because why? Stuart pointed out, and quite correctly, that IPv4LL has been >around for years, and the internet hasn't melted down. What, the internet >suddenly got fragile? > >john > >-- >John C. Welch >Consultant III >Office Computing Practice (IS) >(617) 253 - 1368 work >(508) 579 - 7380 cell >bynkii2 AIM From owner-zeroconf@merit.edu Thu Mar 13 09:18: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 JAA01279 for ; Thu, 13 Mar 2003 09:18:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B3A6191370; Thu, 13 Mar 2003 09:19:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E75D19121A; Thu, 13 Mar 2003 09:19:34 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 686A591370 for ; Thu, 13 Mar 2003 09:19:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 60D7D5E12A; Thu, 13 Mar 2003 09:18:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id C43A15E084 for ; Thu, 13 Mar 2003 09:18:38 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h2DEIRA25206; Thu, 13 Mar 2003 21:18:28 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h2DEI7T09647; Thu, 13 Mar 2003 21:18:08 +0700 (ICT) From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: [LL29] Link-local sources should specify TTL=1 [LL21] In-Reply-To: <200303130719.h2D7JL429544@scv1.apple.com> References: <200303130719.h2D7JL429544@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Mar 2003 21:18:07 +0700 Message-ID: <9645.1047565087@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 12 Mar 2003 23:19:21 -0800 From: Stuart Cheshire Message-ID: <200303130719.h2D7JL429544@scv1.apple.com> | I'm sorry to have to say this, but the arguments supporting TTL=1 are | notable for their quantity rather than their quality. Many people have | spoken in support of TTL=1, but none of the arguments given hold up under | scrutiny. I agree with that. But the arguments for TTL=255 are just as lame. The problem is that neither side is willing to admit that their arguments really have no merit, each believes they do, regardless of how many counter-arguments the other side make. At various stages in the early parts of this discussion (for me anyway, last year) I was swayed towards the TTL=255 case (seemed to be reasonable enough) and then to the TTL=1 case (sounded convincing). Upon scrutiny, neither made much sense. That's why I proposed LL21 - that we just drop mention of TTLs. If some application that uses LL addresses (rendezvous can be one for example) wants to specify that the TTL must be N, then let it do so. What's more, that specification would work whether LL addresses are being used by the protocol, or whether some other addresses are. If the protocol finds it useful to know for sure that packets originated on the local link (and so wants to test TTL==255) then surely that should work regardless of what addresses happen to be being used. On the other hand, if a protocol wants to ensure that its packets remain on the local link, then it can specify TTL=1 as a requirement, which, once again, works regardless of the addresses (LL or others). Specifying a particular TTL for all uses of one particular address type would prevent at least one of the above from working. There's no meaningful benefit to be obtained by a general specification, so let's just drop it. Support LL21 kre From owner-zeroconf@merit.edu Thu Mar 13 09:24: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 JAA01508 for ; Thu, 13 Mar 2003 09:24:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF2B59121A; Thu, 13 Mar 2003 09:26:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD00B91371; Thu, 13 Mar 2003 09:26:33 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9E83F9121A for ; Thu, 13 Mar 2003 09:26:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 81FF35E11A; Thu, 13 Mar 2003 09:26:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by segue.merit.edu (Postfix) with ESMTP id 1792D5E084 for ; Thu, 13 Mar 2003 09:26:32 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2DEQTvD006288 for ; Thu, 13 Mar 2003 09:26:30 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-248.cisco.com [161.44.149.248]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA01489 for ; Thu, 13 Mar 2003 09:26:29 -0500 (EST) Message-Id: <4.3.2.7.2.20030313092243.01f9bef8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 09:26:30 -0500 To: zeroconf@merit.edu From: Ralph Droms Subject: Re: [LL29] Link-local sources should specify TTL=1 [LL21] In-Reply-To: <9645.1047565087@munnari.OZ.AU> References: <200303130719.h2D7JL429544@scv1.apple.com> <200303130719.h2D7JL429544@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Given a lack of convincing arguments about the advantage of using the TTL field for specific advantage in IPv4LL, I strongly believe we should retain its current definition as a TTL value. Still calling it "TTL" while using it as "source not on link" doesn't change the fact the IPv4LL would be making a fundamental change to the definition of the IP header for use when an IPv4LL address header happens to contain an IPv4LL address. - Ralph At 09:18 PM 3/13/2003 +0700, Robert Elz wrote: > Date: Wed, 12 Mar 2003 23:19:21 -0800 > From: Stuart Cheshire > Message-ID: <200303130719.h2D7JL429544@scv1.apple.com> > > | I'm sorry to have to say this, but the arguments supporting TTL=1 are > | notable for their quantity rather than their quality. Many people have > | spoken in support of TTL=1, but none of the arguments given hold up > under > | scrutiny. > >I agree with that. > >But the arguments for TTL=255 are just as lame. > >The problem is that neither side is willing to admit that their >arguments really have no merit, each believes they do, regardless >of how many counter-arguments the other side make. > >At various stages in the early parts of this discussion (for me anyway, >last year) I was swayed towards the TTL=255 case (seemed to be reasonable >enough) and then to the TTL=1 case (sounded convincing). Upon scrutiny, >neither made much sense. > >That's why I proposed LL21 - that we just drop mention of TTLs. > >If some application that uses LL addresses (rendezvous can be one for >example) wants to specify that the TTL must be N, then let it do so. >What's more, that specification would work whether LL addresses are being >used by the protocol, or whether some other addresses are. If the >protocol finds it useful to know for sure that packets originated on the >local link (and so wants to test TTL==255) then surely that should work >regardless of what addresses happen to be being used. > >On the other hand, if a protocol wants to ensure that its packets remain >on the local link, then it can specify TTL=1 as a requirement, which, once >again, works regardless of the addresses (LL or others). > >Specifying a particular TTL for all uses of one particular address type >would prevent at least one of the above from working. There's no meaningful >benefit to be obtained by a general specification, so let's just drop it. > >Support LL21 > >kre From owner-zeroconf@merit.edu Thu Mar 13 09:25: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 JAA01538 for ; Thu, 13 Mar 2003 09:25:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9078B91371; Thu, 13 Mar 2003 09:27:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5784091372; Thu, 13 Mar 2003 09:27:25 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A75B91371 for ; Thu, 13 Mar 2003 09:27:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 581CF5E084; Thu, 13 Mar 2003 09:27:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id CCDF45E055 for ; Thu, 13 Mar 2003 09:27:23 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16113 for ; Thu, 13 Mar 2003 07:27:22 -0700 (MST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h2DERLj07078 for ; Thu, 13 Mar 2003 15:27:21 +0100 (MET) Date: Thu, 13 Mar 2003 15:27:18 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: WG Action ACCEPT [LL7] How do existing hosts respond to broadcast requests? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Decision: Accept Action: None There was little discussion of this point except in support of it. Steve did not get back to us. If he has further issues he can raise them. Erik From owner-zeroconf@merit.edu Thu Mar 13 09:32:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01860 for ; Thu, 13 Mar 2003 09:32:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 95A0091374; Thu, 13 Mar 2003 09:31:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99FBE91375; Thu, 13 Mar 2003 09:31:03 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CCB8A91374 for ; Thu, 13 Mar 2003 09:30:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 665E15E0B2; Thu, 13 Mar 2003 09:30:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 706E55E084 for ; Thu, 13 Mar 2003 09:30:45 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01192 for ; Thu, 13 Mar 2003 06:30:44 -0800 (PST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h2DEUgj07278 for ; Thu, 13 Mar 2003 15:30:42 +0100 (MET) Date: Thu, 13 Mar 2003 15:30:40 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG Action ACCEPT [LL9] Introduction to make it clear this is not a replacement for a DHCP assigned address Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Decision: Accept Action: Add the following to the Abstract Link-local communication using link-local addresses is only suitable for communication with other devices connected to the same physical (or logical) link. Link-local communication using link-local addresses is not suitable for communication with devices not directly connected to the same physical (or logical) link. There was WG consensus support for accepting this issue. Erik From owner-zeroconf@merit.edu Thu Mar 13 09:33: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 JAA01888 for ; Thu, 13 Mar 2003 09:33:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4360B91372; Thu, 13 Mar 2003 09:34:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9AFF191376; Thu, 13 Mar 2003 09:34:35 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 02DF391372 for ; Thu, 13 Mar 2003 09:34:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 121005E38C; Thu, 13 Mar 2003 09:34:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id AEDD05DE96 for ; Thu, 13 Mar 2003 09:34:03 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20077 for ; Thu, 13 Mar 2003 07:34:02 -0700 (MST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h2DEY0j07349 for ; Thu, 13 Mar 2003 15:34:01 +0100 (MET) Date: Thu, 13 Mar 2003 15:33:58 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: zeroconf@merit.edu Subject: WG Action ACCEPT [LL13] If the destination is a global multicast address a host SHOULD use a global source address Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Decision: Accept Action: Add to section 2.6 If the destination address is the 255.255.255.255 broadcast address or a link-local multicast address, then the host may use either its link-local source address or a routable address, as appropriate. If the destination address is a multicast address with scope larger than link-local then the host SHOULD use an appropriate routable source address, if available, or its link-local source address otherwise. Note: This may not be necessary after the resolution of LL23. We leave this to the document editor's discretion. Those that commented on this issue supported excepting it. Erik From owner-zeroconf@merit.edu Thu Mar 13 09:33: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 JAA01908 for ; Thu, 13 Mar 2003 09:33:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1747E91375; Thu, 13 Mar 2003 09:35:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F408591376; Thu, 13 Mar 2003 09:35:41 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 27AD791375 for ; Thu, 13 Mar 2003 09:35:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 005875E084; Thu, 13 Mar 2003 09:35:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 6DFB75DE96 for ; Thu, 13 Mar 2003 09:35:39 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07037 for ; Thu, 13 Mar 2003 07:35:38 -0700 (MST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h2DEZaj07399 for ; Thu, 13 Mar 2003 15:35:36 +0100 (MET) Date: Thu, 13 Mar 2003 15:35:34 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: WG Action REJECT [LL24] Weaken the PRN generated address requirement from MUST to MAY Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Decision: Reject Action: None This item provoked some discussion but found no support beyond the submitter of the issue. The WG consensus was that the current wording is good enough. Erik From owner-zeroconf@merit.edu Thu Mar 13 09:35: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 JAA02005 for ; Thu, 13 Mar 2003 09:35:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 25F8691376; Thu, 13 Mar 2003 09:37:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8F8991378; Thu, 13 Mar 2003 09:37:41 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E9E8291376 for ; Thu, 13 Mar 2003 09:37:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id C54625E055; Thu, 13 Mar 2003 09:37:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 197265DE96 for ; Thu, 13 Mar 2003 09:37:40 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08286 for ; Thu, 13 Mar 2003 07:37:38 -0700 (MST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h2DEbbj07462 for ; Thu, 13 Mar 2003 15:37:37 +0100 (MET) Date: Thu, 13 Mar 2003 15:37:35 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: WG Action REJECT [LL25]: Delete inappropriate "send" requirement on LL nodes. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Decision: Reject Action: None The WG consensus was to reject this issue. The proposed change to remove the restriction against sending packets to routers for forwarding was not acceptable to any on the list. Erik From owner-zeroconf@merit.edu Thu Mar 13 09:48: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 JAA02422 for ; Thu, 13 Mar 2003 09:48:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A9A2B91378; Thu, 13 Mar 2003 09:50:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76BCE91379; Thu, 13 Mar 2003 09:50:22 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 05BB391378 for ; Thu, 13 Mar 2003 09:50:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 63B8C5E4C6; Thu, 13 Mar 2003 09:50:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by segue.merit.edu (Postfix) with ESMTP id E51785DE94 for ; Thu, 13 Mar 2003 09:50:07 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e34.co.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2DEnn64171522; Thu, 13 Mar 2003 09:49:49 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-221-180.mts.ibm.com [9.65.221.180]) by westrelay01.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2DEnf3p037682; Thu, 13 Mar 2003 07:49:49 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id h2DEkKM04173; Thu, 13 Mar 2003 09:46:20 -0500 Message-Id: <200303131446.h2DEkKM04173@cichlid.adsl.duke.edu> To: Stuart Cheshire Cc: "Zeroconf Working Group" Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 In-Reply-To: Message from cheshire@apple.com of "Wed, 12 Mar 2003 23:21:23 PST." <200303130721.h2D7LM429996@scv1.apple.com> Date: Thu, 13 Mar 2003 09:46:20 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Stuart Cheshire writes: > Thomas Narten wrote: > > > Now suppose that Link A and Link B have LL hosts on them. > > > > > The only additional requirement for a malicious host on Link A to send a > > > packet to a LL destination on Link B is that either Gateway-A or Gateway-B > > > has been configured with a route which directs the LL prefix onto > > > Link B. > >This is clearly a broken configuration and will result in LL in > >general not working. I.e., two nodes, both on Link A, both using LL > >addresses, won't be able to communicate. The Router will grab their > >traffic and forward it to the wrong place. Right? > No, Router A is not "grabbing" traffic. > A malicious attacker on Link A is deliberately sending traffic to Router > A to exploit its misconfiguration in order to print offensive material on > the LL printer on Link B. OK. But its still a misconfiguration (and one that doesn't seem all that likely to me, since its really an odd configuration). However, if one looks at the specific vulnerability, it's not IMO huge. Specifically, it allows an attacker on a link one hop away from the target network to (incorrectly) cause a LL packet to be delivered to a network behind a neighboring router. Yes, this is a vulnerability compared to the router not forwarding the packet at all. But iIt is also not equivalent to opening a gaping hole that allows an arbitrary attacker anywhere on the internet from sending LL traffic to some target network. Is it a big enough vulnerabiliy that it needs to be prevented in all cases (e.g, by using something like the TTL = 255 on reciept)? I personally have a hard time seeing that. Thomas From owner-zeroconf@merit.edu Thu Mar 13 09:49: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 JAA02492 for ; Thu, 13 Mar 2003 09:49:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A2E749121E; Thu, 13 Mar 2003 09:51:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 365649137A; Thu, 13 Mar 2003 09:51:10 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2C3919121E for ; Thu, 13 Mar 2003 09:51:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0DDD05DE07; Thu, 13 Mar 2003 09:51:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by segue.merit.edu (Postfix) with ESMTP id 886525DE94 for ; Thu, 13 Mar 2003 09:51:07 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e32.co.us.ibm.com (8.12.8/8.12.2) with ESMTP id h2DEoTaI101442; Thu, 13 Mar 2003 09:50:29 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-221-180.mts.ibm.com [9.65.221.180]) by westrelay01.boulder.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h2DEnf3n037682; Thu, 13 Mar 2003 07:49:46 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id h2DEQ4W04109; Thu, 13 Mar 2003 09:26:04 -0500 Message-Id: <200303131426.h2DEQ4W04109@cichlid.adsl.duke.edu> To: Stuart Cheshire Cc: "Zeroconf" Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 In-Reply-To: Message from cheshire@apple.com of "Wed, 12 Mar 2003 23:23:27 PST." <200303130723.h2D7NRj07496@scv3.apple.com> Date: Thu, 13 Mar 2003 09:26:04 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Stuart, > In the IETF fantasy parallel universe, there are no firewalls, and > everyone uses strong end-to-end security all the time. And the IETF as far as I know isn't denying the presence of firewall or thinking they are useless and have no value. Heck, there is even a BOF scheduled for SF that very much assumes firewalls. > In the world I live in, firewalls are common, and people see real value > in reducing the population of potential attackers by such methods. I suspect most people here would agree. But bringing this up is a Red Herring. > I do not understand the people who refuse to see the benefit in reducing > the population of potential attackers from the entire planet to just > people within close physical proximity. I see the value, and I suspect most people do. That is not the issue being debated here. The specific issue is whether the 255 check on reciept provides enough additional benefit compared to the "security" you already get from just using LLs in the first place. By using LL addresses (and because routers won't generally forward them, etc.) you already have cut off a huge avenue of vulnerabilities from off-link attackers. This is independent of the 255 check. The specific question is whether the 255 check provides sufficient additional advantage to justify its downsides. Thomas From owner-zeroconf@merit.edu Thu Mar 13 09:50:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02538 for ; Thu, 13 Mar 2003 09:50:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7A7C291379; Thu, 13 Mar 2003 09:52:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 479DF9137A; Thu, 13 Mar 2003 09:52:44 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 23CEF91379 for ; Thu, 13 Mar 2003 09:52:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE9C15E11F; Thu, 13 Mar 2003 09:52:43 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 82C595DE07 for ; Thu, 13 Mar 2003 09:52:42 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA14395 for ; Thu, 13 Mar 2003 09:52:41 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA22107 for ; Thu, 13 Mar 2003 09:52:41 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h2DEqd0x009250 for ; Thu, 13 Mar 2003 09:52:40 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 13 Mar 2003 09:52:38 -0500 Subject: Re: New issue: When to configure a LL address From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <4.3.2.7.2.20030313085201.00b9fed8@funnel.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 03/13/2003 08:59, "Ralph Droms" wrote: > The impact I'm talking about is on the unannounced use of IPv4LL > addresses by my laptop, which causes loss of network connectivity > with no associated indication of why connectivity has been lost. > What OS are you running? OS X ties it's config to a configured address if one exists. > The Internet hasn't melted down, but *I've* come damn close to melting > down several times after wasting time trying to diagnose and fix the > problem. The requirement to look at the device's assigned IP address > and then deduce that it is an IPv4LL address because I remember the > prefix for IPv4LL addresses or because I click a "More Info" button > and happen to see the "Auto-Configuration Active" box checked is > unacceptable. That's a vendor implementation bug, not a v4LL bug. They're not implementing LL correctly, and it sounds like they aren't handling single-link multihoming even *close* to correctly. No standard can make up for a lazy/poor implementation(NFS anyone? FTP?). That requires the people with the checkbooks to scream. john -- John C. Welch Consultant III Office Computing Practice (IS) (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Mar 13 09:55: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 JAA02975 for ; Thu, 13 Mar 2003 09:55:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A23419137A; Thu, 13 Mar 2003 09:57:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 33D749137C; Thu, 13 Mar 2003 09:57:25 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 03D059137A for ; Thu, 13 Mar 2003 09:57:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id E8D355E124; Thu, 13 Mar 2003 09:57:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 713B55E11F for ; Thu, 13 Mar 2003 09:57:23 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA16867 for ; Thu, 13 Mar 2003 09:57:22 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA22964 for ; Thu, 13 Mar 2003 09:57:22 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h2DEvK0x010941 for ; Thu, 13 Mar 2003 09:57:21 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 13 Mar 2003 09:57:19 -0500 Subject: Re: [LL29] Link-local sources should specify TTL=1 [LL21] From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <9645.1047565087@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 03/13/2003 09:18, "Robert Elz" wrote: > If some application that uses LL addresses (rendezvous can be one for > example) wants to specify that the TTL must be N, then let it do so. > What's more, that specification would work whether LL addresses are being > used by the protocol, or whether some other addresses are. If the > protocol finds it useful to know for sure that packets originated on the > local link (and so wants to test TTL==255) then surely that should work > regardless of what addresses happen to be being used. > > On the other hand, if a protocol wants to ensure that its packets remain > on the local link, then it can specify TTL=1 as a requirement, which, once > again, works regardless of the addresses (LL or others). > > Specifying a particular TTL for all uses of one particular address type > would prevent at least one of the above from working. There's no meaningful > benefit to be obtained by a general specification, so let's just drop it. And you now have to test the TTL usage for *every single vendor* to use products from different vendors to make sure that the TTL handling is compatible. Which of course means that a v4LL 'standard' is now as much of an oxymoron as jumbo shrimp. Now, if you're a major network vendor, the ability to comply with a standard and lock your customers into your? stuff and out of anyone else's stuff is brilliant. Someone else compatible? Not for long, just 'adjust' your TTL handling until their stuff doesn't work with yours, then tell your customers that they have to remove their stuff, buy more of your stuff and life will be perfect again. I thought we had left the IBM of the 60s and 70s behind long ago. john -- John C. Welch Consultant III Office Computing Practice (IS) (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Mar 13 10:02:54 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03238 for ; Thu, 13 Mar 2003 10:02:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 434D49137B; Thu, 13 Mar 2003 10:04:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2FB19137C; Thu, 13 Mar 2003 10:04:37 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F1E79137B for ; Thu, 13 Mar 2003 10:04:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id F16375E12F; Thu, 13 Mar 2003 10:04:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 6D1815E11F for ; Thu, 13 Mar 2003 10:04:01 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26447 for ; Thu, 13 Mar 2003 08:04:00 -0700 (MST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with SMTP id h2DF3wj08112 for ; Thu, 13 Mar 2003 16:03:58 +0100 (MET) Date: Thu, 13 Mar 2003 16:03:56 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Subject: Resolution of TTL issues and new issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I have been extremely busy and am not able to reach a conclusion about LL3, LL21 and LL29 given the volume of discussion. I hope to have an answer on these issues by the weekend. Sorry for the delay. Since the IETF meeting is coming up, I will not initiate any new issue last calls till the week following (Mar 24-28). While at the IETF, I will meet with IESG members who have outstanding issues to get suggested resolutions. Best regards, Erik ZEROCONF WG chair From owner-zeroconf@merit.edu Thu Mar 13 10:04: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 KAA03419 for ; Thu, 13 Mar 2003 10:04:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 931E39137C; Thu, 13 Mar 2003 10:06:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 353D79137D; Thu, 13 Mar 2003 10:06:19 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C16C89137C for ; Thu, 13 Mar 2003 10:06:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id AB4425E10C; Thu, 13 Mar 2003 10:06:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by segue.merit.edu (Postfix) with ESMTP id 412AE5DE07 for ; Thu, 13 Mar 2003 10:06:16 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h2DF6EvD009912 for ; Thu, 13 Mar 2003 10:06:14 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-248.cisco.com [161.44.149.248]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA04727 for ; Thu, 13 Mar 2003 10:06:13 -0500 (EST) Message-Id: <4.3.2.7.2.20030313100250.02053580@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 10:06:14 -0500 To: Zeroconf From: Ralph Droms Subject: Re: New issue: When to configure a LL address In-Reply-To: References: <4.3.2.7.2.20030313085201.00b9fed8@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk John - did you read all of my message (you didn't quote it all). I explicitly wrote: Although, as Stuart said, this problem is an interface problem and not a protocol problem, either way it is an implementation problem that negatively impacts my usual use of routable addresses. I know I'm referring to an interface problem; I've said so at least three times now. Regardless, it's still an implementation problem and it has had a negative impact on my use of the network. I've experienced this interface problem behavior with Windows 95 (if I remember correctly), Windows 98 and Windows 2000. I believe Stuart said it's also a problem in some flavors of MacOS. - Ralph At 09:52 AM 3/13/2003 -0500, John C. Welch wrote: >On 03/13/2003 08:59, "Ralph Droms" wrote: > > > The impact I'm talking about is on the unannounced use of IPv4LL > > addresses by my laptop, which causes loss of network connectivity > > with no associated indication of why connectivity has been lost. > > > >What OS are you running? OS X ties it's config to a configured address if >one exists. > > > The Internet hasn't melted down, but *I've* come damn close to melting > > down several times after wasting time trying to diagnose and fix the > > problem. The requirement to look at the device's assigned IP address > > and then deduce that it is an IPv4LL address because I remember the > > prefix for IPv4LL addresses or because I click a "More Info" button > > and happen to see the "Auto-Configuration Active" box checked is > > unacceptable. > >That's a vendor implementation bug, not a v4LL bug. They're not implementing >LL correctly, and it sounds like they aren't handling single-link >multihoming even *close* to correctly. No standard can make up for a >lazy/poor implementation(NFS anyone? FTP?). That requires the people with >the checkbooks to scream. > >john > >-- >John C. Welch >Consultant III >Office Computing Practice (IS) >(617) 253 - 1368 work >(508) 579 - 7380 cell >bynkii2 AIM From owner-zeroconf@merit.edu Thu Mar 13 11:20:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07521 for ; Thu, 13 Mar 2003 11:20:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2988E9137D; Thu, 13 Mar 2003 11:21:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E00E91234; Thu, 13 Mar 2003 11:21:34 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 22FAC9137D for ; Thu, 13 Mar 2003 11:21:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id DB0545E13C; Thu, 13 Mar 2003 11:21:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 705255E12A for ; Thu, 13 Mar 2003 11:21:28 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA29129 for ; Thu, 13 Mar 2003 11:21:28 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA10426 for ; Thu, 13 Mar 2003 11:16:32 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h2DGGU0x012799 for ; Thu, 13 Mar 2003 11:16:30 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 13 Mar 2003 11:16:29 -0500 Subject: Re: New issue: When to configure a LL address From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <4.3.2.7.2.20030313100250.02053580@funnel.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 03/13/2003 10:06, "Ralph Droms" wrote: > I know I'm referring to an interface problem; I've said so > at least three times now. Regardless, it's still an implementation > problem and it has had a negative impact on my use of the network. > > I've experienced this interface problem behavior with Windows 95 > (if I remember correctly), Windows 98 and Windows 2000. I believe > Stuart said it's also a problem in some flavors of MacOS. Right. But it's how LL is implemented on those systems, not LL itself that is causing the problem. Implementation is a vendor, not a standards problem. It's not the LL address that's making your day suck, it's how the OS is implementing LL. We can't force implementations, unless you want a standard that is longer than every other standard combined. john -- John C. Welch Consultant III Office Computing Practice (IS) (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Mar 13 12:33:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09784 for ; Thu, 13 Mar 2003 12:33:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 60F9D91380; Thu, 13 Mar 2003 12:35:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 158C89137F; Thu, 13 Mar 2003 12:35:43 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7B43E91265 for ; Thu, 13 Mar 2003 12:35:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 524E05E151; Thu, 13 Mar 2003 12:35:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by segue.merit.edu (Postfix) with ESMTP id 2FF575E14E for ; Thu, 13 Mar 2003 12:35:40 -0500 (EST) Received: from user-vcaulg9.dsl.mindspring.com ([216.175.86.9] helo=SGOSWAMIPCL) by stork.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 18tWcF-0007Co-00 for zeroconf@merit.edu; Thu, 13 Mar 2003 09:35:39 -0800 From: "Subrata Goswami" To: "'Zeroconf'" Subject: RE: Oppose: LL29 Link-local sources should specify TTL=1 Date: Thu, 13 Mar 2003 09:28:35 -0800 Message-ID: <008701c2e985$fa1a1250$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <200303130723.h2D7NRj07496@scv3.apple.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-ELNK-Trace: 33bae71ce1aa67f5d780f4a490ca69564776905774d2ac4b329c69fc6093b7b58c2d3852835f5417350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I guess a better explanation of the TTL=255 choice would be good for the list. As far as I can tell, the following is the normal interpretation of different TTL values (please correct me I am wrong). TTL=1 implies the packet probably originated in this link. TTL=255 implies the packet can live for another 254 hops. I addition I believe the LLv4 draft is restrictive enough so that the particular TTL value is a non-issue. 1. Section 2.6 Source Address Selection "... The host MUST NOT send the packet to any router for forwarding. " 2. 2.7 Link-Local Packets Are Not Forwarded "An IPv4 packet whose source and/or destination address is in the 169.254/16 prefix MUST NOT be sent to any router for forwarding, and any network device receiving such a packet MUST NOT forward it, regardless of the TTL in the IP header." Subrata > -----Original Message----- > From: owner-zeroconf@merit.edu > [mailto:owner-zeroconf@merit.edu] On Behalf Of Stuart Cheshire > Sent: Wednesday, March 12, 2003 11:23 PM > To: Zeroconf > Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 > > > Robert Elz wrote: > >The ability to detect errant packets is similarly useless in > general. > >You keep on citing that ability as a feature, but you have > yet to give > >a reason how it ever achieves anything (in general). > > Mika Liljeberg wrote: > >Sure. I just don't see a TTL=255 check helping any. LL > addresses have > >no value as a secrity measure and people should not be bamboozled to > >think that they have. > > This is IETF political correctness, and I do not believe it > is helpful. > > In the IETF fantasy parallel universe, there are no firewalls, and > everyone uses strong end-to-end security all the time. > > I make the following statement will full knowledge that it is > IETF heresy: > > In the world I live in, firewalls are common, and people see > real value > in reducing the population of potential attackers by such methods. > > I personally do not like firewalls because they contribute to > the famous > "fog on the Internet", so I do not run one at my house. I also run an > open 802.11 network with no WEP. Unfortunately not all of the > devices in > my house have strong end-to-end security. For example, my > network printer > supports LPR, but has NO access control of any kind. How do I stop it > being abused? You can lecture me, and I can lecture the > printer vendor > about end-to-end security, and in the IETF fantasy parallel > universe they > send me new firmware the next day, but here in the real world, that > doesn't solve my problem. Here in the real world I solve my > problem by > arranging for the printer to have only a link-local address. I could > achieve a similar effect by installing a firewall, but that > is just one > more piece of hardware to buy and install and configure and maintain. > This precaution I take prevents the printer from being > directly accessed > by any device outside the local link, thereby reducing the > population of > potential attackers from the entire planet to just people > within range of > my wireless base stations. This is a level of risk I am willing to > accept. If anyone really wants to take time out from IETF > meetings next > week drive to my house and abuse my printer, I won't really > be annoyed. > In fact, I'll probably be amused that someone who is > gainfully employed > has time to waste on such stupidity. On the other hand, if I got junk > pages spewing out of my printer at the same rate that spam > email shows up > in my email account (continuously, all day, every day) then I > would get > very annoyed very quickly. > > I do not understand the people who refuse to see the benefit > in reducing > the population of potential attackers from the entire planet to just > people within close physical proximity. > > I fully agree that I would love to have strong end-to-end > security all > the time, but here in the real world you can't always have > what you want, > and in the absence of perfect security, a mechanism for > knowing that a > packet originated on the local link is one very useful tool in the > networking toolbox. > > Stuart Cheshire > * Wizard Without Portfolio, Apple Computer, Inc. > * www.stuartcheshire.org > From owner-zeroconf@merit.edu Thu Mar 13 12:50:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10384 for ; Thu, 13 Mar 2003 12:50:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D37969137E; Thu, 13 Mar 2003 12:49:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DBFB91381; Thu, 13 Mar 2003 12:49:39 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D10BA9137E for ; Thu, 13 Mar 2003 12:49:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id E27335E161; Thu, 13 Mar 2003 12:48:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by segue.merit.edu (Postfix) with ESMTP id 5F2165E154 for ; Thu, 13 Mar 2003 12:48:14 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-483.cisco.com [10.82.241.227]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h2DHmBSd000564; Thu, 13 Mar 2003 12:48:12 -0500 (EST) Message-Id: <4.3.2.7.2.20030313124149.03c26b08@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Mar 2003 12:48:10 -0500 To: "Subrata Goswami" From: John Schnizlein Subject: RE: Oppose: LL29 Link-local sources should specify TTL=1 Cc: "'Zeroconf'" In-Reply-To: <008701c2e985$fa1a1250$0200a8c0@SGOSWAMIPCL> References: <200303130723.h2D7NRj07496@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk At 12:28 PM 3/13/2003, Subrata Goswami wrote: >... explanation of the TTL=255 choice would be good for the list. >As far as I can tell, the following is the normal interpretation >of different TTL values (please correct me I am wrong). > >TTL=1 implies the packet probably originated in this link. Actually, just that if Link-Local hosts set TTL=1, normal router behavior will enforce the requirement that these packets not be forwarded to other links. >TTL=255 implies the packet can live for another 254 hops. > >I addition I believe the LLv4 draft is restrictive enough so that the >particular TTL value is a non-issue. The problem with relying on the following is that 1) hosts cannot tell if the response to an ARP came from a router, and 2) it is not reasonable to expect the whole Internet to comply with the new requirement to check for this 169.254/16 prefix. >1. Section 2.6 Source Address Selection > "... The host MUST NOT send the packet to any router for forwarding. " > >2. 2.7 Link-Local Packets Are Not Forwarded > "An IPv4 packet whose source and/or destination address is in the > 169.254/16 prefix MUST NOT be sent to any router for forwarding, and > any network device receiving such a packet MUST NOT forward it, > regardless of the TTL in the IP header." From owner-zeroconf@merit.edu Thu Mar 13 13:34:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12051 for ; Thu, 13 Mar 2003 13:34:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9DF129126A; Thu, 13 Mar 2003 13:36:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F80F9126E; Thu, 13 Mar 2003 13:36:47 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4730B9126A for ; Thu, 13 Mar 2003 13:36:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 31E565E0D7; Thu, 13 Mar 2003 13:36:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by segue.merit.edu (Postfix) with ESMTP id 106BE5DE87 for ; Thu, 13 Mar 2003 13:36:46 -0500 (EST) Received: from user-vcaulg9.dsl.mindspring.com ([216.175.86.9] helo=SGOSWAMIPCL) by stork.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 18tXVh-0002xF-00; Thu, 13 Mar 2003 10:32:57 -0800 From: "Subrata Goswami" To: "'John Schnizlein'" Cc: "'Zeroconf'" Subject: RE: Oppose: LL29 Link-local sources should specify TTL=1 Date: Thu, 13 Mar 2003 10:25:53 -0800 Message-ID: <000e01c2e98d$fb24f900$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <4.3.2.7.2.20030313124149.03c26b08@wells.cisco.com> X-ELNK-Trace: 33bae71ce1aa67f5d780f4a490ca69564776905774d2ac4bc8a9728c1ec6106c28e6637b7fded666350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree on the view that the whole "Internet" does not need to be adjusted to handle LLv4. In that sense, TTL=1 , seems to me to be a logical choice. Subrata > -----Original Message----- > From: John Schnizlein [mailto:jschnizl@cisco.com] > Sent: Thursday, March 13, 2003 9:48 AM > To: Subrata Goswami > Cc: 'Zeroconf' > Subject: RE: Oppose: LL29 Link-local sources should specify TTL=1 > > > At 12:28 PM 3/13/2003, Subrata Goswami wrote: > >... explanation of the TTL=255 choice would be good for the list. As > >far as I can tell, the following is the normal interpretation of > >different TTL values (please correct me I am wrong). > > > >TTL=1 implies the packet probably originated in this link. > > Actually, just that if Link-Local hosts set TTL=1, normal router > behavior will enforce the requirement that these packets not > be forwarded to other links. > > >TTL=255 implies the packet can live for another 254 hops. > > > >I addition I believe the LLv4 draft is restrictive enough so > that the > >particular TTL value is a non-issue. > > The problem with relying on the following is that > 1) hosts cannot tell if the response to an ARP came from a router, and > 2) it is not reasonable to expect the whole Internet to comply with > the new requirement to check for this 169.254/16 prefix. > > >1. Section 2.6 Source Address Selection > > "... The host MUST NOT send the packet to any router for > >forwarding. " > > > >2. 2.7 Link-Local Packets Are Not Forwarded > > "An IPv4 packet whose source and/or destination address is in the > > 169.254/16 prefix MUST NOT be sent to any router for > forwarding, and > > any network device receiving such a packet MUST NOT forward it, > > regardless of the TTL in the IP header." > From owner-zeroconf@merit.edu Thu Mar 13 13:37:21 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12122 for ; Thu, 13 Mar 2003 13:37:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F31A49126F; Thu, 13 Mar 2003 13:39:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C26239126E; Thu, 13 Mar 2003 13:39:21 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2CB389126F for ; Thu, 13 Mar 2003 13:39:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 147685E142; Thu, 13 Mar 2003 13:39:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 955B85E136 for ; Thu, 13 Mar 2003 13:39:19 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.12.8/8.12.8) with ESMTP id h2DIdJ93022251 for ; Thu, 13 Mar 2003 10:39:19 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 13 Mar 2003 10:39:06 -0800 Received: from apple.com (lubet1.apple.com [17.202.40.146]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id h2DIdA427307; Thu, 13 Mar 2003 10:39:10 -0800 (PST) Date: Thu, 13 Mar 2003 10:40:13 -0800 Subject: Re: Oppose: LL29 Link-local sources should specify TTL=1 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'Zeroconf'" To: Subrata Goswami From: Vincent Lubet In-Reply-To: <008701c2e985$fa1a1250$0200a8c0@SGOSWAMIPCL> Message-Id: <3A684F24-5583-11D7-A7F8-000393DB76DA@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, March 13, 2003, at 09:28 AM, Subrata Goswami wrote: > I guess a better explanation of the TTL=255 choice would be good for > the > list. > As far as I can tell, the following is the normal interpretation of > different > TTL values (please correct me I am wrong). > > TTL=1 implies the packet probably originated in this link. Not at all, the packet may have come from up to 254 hops away! > TTL=255 implies the packet can live for another 254 hops. More importantly, if TTL=255 on reception, you are sure the packet originated from this link. Vincent From owner-zeroconf@merit.edu Thu Mar 13 15:48: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 PAA18554 for ; Thu, 13 Mar 2003 15:48:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1584791274; Thu, 13 Mar 2003 15:50:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C35A591273; Thu, 13 Mar 2003 15:50:43 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1B32B91274 for ; Thu, 13 Mar 2003 15:50:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0A4FF5DE14; Thu, 13 Mar 2003 15:50:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by segue.merit.edu (Postfix) with ESMTP id DCE295DD9B for ; Thu, 13 Mar 2003 15:50:40 -0500 (EST) Received: from user-vcaulg9.dsl.mindspring.com ([216.175.86.9] helo=SGOSWAMIPCL) by stork.mail.pas.earthlink.net with asmtp (Exim 3.33 #1) id 18tZey-0005gU-00 for zeroconf@merit.edu; Thu, 13 Mar 2003 12:50:40 -0800 From: "Subrata Goswami" To: "'Zeroconf'" Subject: Accept: LL29 Link-local sources should specify TTL=1 Date: Thu, 13 Mar 2003 12:43:35 -0800 Message-ID: <002d01c2e9a1$37a371a0$0200a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-ELNK-Trace: 33bae71ce1aa67f5d780f4a490ca69564776905774d2ac4b5188ccca40dabe46218264a1eb948950350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit After looking at arguments from both sides (TTL=1 and TTL=255), I would say both sides have fairly strong points in favor. At this point I think at TTL=255 represents a more accurate representation of where the packet originated. A TTL=1 represents a packet which possibly might have gone through 254 hops (assuming no fowl play), whereas a TTL=255 makes sure that the packet has not gone through any router/hops hence originated in that link. A TTL=1 represents the spirit of LL better as any router would not let the packet get out of the link. This holds true for any router, existing (there are an awful lot of those) and future. Hence this choice offers a better backward compatibility. The TTL=255 folks forward the argument that by prohibiting any HOST to not forward traffic to a router ( a big change in the IP stack) or replacing all deployed routers to be LL aware (a big check is required here) should take care of the compatibility issue. No wonder issue LL25 was not popular with them. My vote is for TTL=1 Subrata From owner-zeroconf@merit.edu Fri Mar 14 07:17:33 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23603 for ; Fri, 14 Mar 2003 07:17:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F401C91275; Fri, 14 Mar 2003 07:18:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47A569127C; Fri, 14 Mar 2003 07:18:45 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E910391275 for ; Fri, 14 Mar 2003 07:18:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4D4005E168; Fri, 14 Mar 2003 07:16:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id C9AC25DE54 for ; Fri, 14 Mar 2003 07:16:48 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 9915659909; Fri, 14 Mar 2003 12:16:44 +0000 (GMT) Message-ID: <01a501c2ea23$91a01e60$131010ac@aldebaran> From: "Philip Nye" To: "Stuart Cheshire" , "Zeroconf Working Group" References: <200303130725.h2D7PJ027070@scv2.apple.com> Subject: Re: New issue: When to configure a LL address Date: Fri, 14 Mar 2003 12:16:40 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Stuart Cheshire" > > Philip Nye wrote: > >This begs other questions like why do you need to reboot the > >base station anyway? Wouldn't you expect connections to be > >broken when you are rebooting your router? > > Philip, you have made many smart comments in the past, which makes this > one all the more surprising. ... > > The whole point of the Internet is that all the connection state is at > the endpoints; you can reboot (or even replace) intermediate nodes > without breaking all the connections going through those nodes. I stand humbled! I obviously should have said "while you are rebooting.." for clarity. Once the router is up and running again, then of course the connections will operate (as they will if you have multiple routes etc.) However, the fact that the station is booting and the time to do so are not known to the host - the connection simply stops working and the host does not know how long to wait before concluding that it should take an alternative action (if one is available). Philip From owner-zeroconf@merit.edu Tue Mar 25 15:00: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 PAA28694 for ; Tue, 25 Mar 2003 15:00:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9556F9126E; Tue, 25 Mar 2003 15:03:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DEB279126F; Tue, 25 Mar 2003 15:03:01 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC8A29126E for ; Tue, 25 Mar 2003 15:03:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id B3C185E147; Tue, 25 Mar 2003 15:03:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id F39E25E13F for ; Tue, 25 Mar 2003 15:02:59 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h2PIkmq27522 for ; Tue, 25 Mar 2003 10:46:49 -0800 Date: Tue, 25 Mar 2003 10:46:48 -0800 (PST) From: Bernard Aboba To: zeroconf@merit.edu Subject: LLMNR issue summary (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk A summary of the currently open LLMNR issues follows. Please post responses to the namedroppers list at namedroppers@ops.iet.org. The LLMNR issues list is available at: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html ---------- Forwarded message ---------- Date: Tue, 25 Mar 2003 10:42:00 -0800 (PST) From: Bernard Aboba To: namedroppers@ops.ietf.org Subject: LLMNR issue summary There are currently 7 open LLMNR Issues: Issue 2: TTL=255 on Send, Check on Receive? Issue 3: Unsafe queries Issue 6: IPv6 Multicast Groups Issue 21: PTR queries Issue 28: Addressing Issue 29: Valid Responses Issue 30: Why is Dynamic Updated Needed? Issue 2 At IETF 56, the discussion seemed to indicate that sending with TTL=255 and checking on receipt would "do no harm" so that it was ok. The major issues encountered in Zeroconf WG with IPv4LL don't seem to apply here, since there are no legacy LLMNR implementations out there that set TTL to something other than 255, so we have a clean slate. Also, even if the IPv4LL draft doesn't specify setting or checking of TTL, an application can still do so. So I'd like to recommend that we keep the existing -14 text that mandates setting TTL=255 and checking it. Issue 3 The discussion at IETF 56 centered on how this would impact a typical use case: two users, one with machine bernarda.microsoft.com and another with randy.psg.com attempting to communicate over an adhoc network. The proposed change would not allow these two machines to resolve each other's name, since neither host exists within the other's "default domain". One possible solution to this would be for the two machines to answer queries for "bernarda" and "randy", rather than only answering queries for the FQDN. If this would work, then the proposed rule is ok as is. What do people think? Issue 21 Back of the envelope calculations seem to indicate to me that bogus PTR queries can be a significant problem in some cases. Measurements show that a significant fraction of DNS queries are not answered, and this is particularly true with PTR queries. So we can have a substantial amount of bogus LLMNR PTR query traffic. I am particularly worried about wireless networks with lots of people like at IETF 56. 5 queries a second from 3000 people would end up eating up a significant fraction of the total bandwidth of an 802.11 network, particularly if there are lots of folks who have to step down to lower rates (1,2,5 Mbps). So there is some reason for concern. In the discussion at IETF 56, there was concern that it might not be possible for a host to know all the networks it was connected to. The question then arises as to whether it is ok not to send a PTR query for addresses on networks the host doesn't know about. It was pointed out that if the host doesn't have a route for that address, then it will route the packet to the gateway, which might not have a route for it either. The question also arose as to why we *ever* want to send IPv6 PTR queries via LLMNR. After all, the ICMP node information query accomplishes the same thing and its use isn't restricted to linklocal. Why not use that instead? So I would like to request feedback from DNSEXT WG on whether: a. We need to send PTR queries at all via LLMNR. If we do, is this just for IPv4? Both IPv4 and IPv6? b. If we need to send them, does it make sense to restrict them to networks on-link? c. If we do send them even for networks off-link, how do you propose to deal with the ensuing bogus traffic? Issue 6 At IETF 56, the sentiment seemed to be for reducing the number of multicast groups used for IPv6. The proposed text uses multiple groups for A/AAAA queries, but a single group for all other queries. This would result in a host with a single name, but multiple addresses listening on only one multicast group for all the PTR RRs it has. One question is whether the scalability benefits of multiple groups is worth the complexity. In my mind, multiple groups do provide some scaling benefits, but only if the overall traffic load is low. If the problem outlined in Issue 21 isn't addressed, I think we will have a scaling problem for multiple groups or a single group. Opinions solicited. Issues 28 and 29 This is similar to Issue 21, in that it is proposed that the receiver check for an "on-link" address in the source address field of LLMNR queries and responses. As with Issue 21, this causes queries or responses sent from networks the host doesn't know about to be dropped. Is this corner case something we need to worry about? Issue 30 This issue claims that there is no benefit to doing a dynamic update with pre-requisite NXRRSET in order to detect duplicate UNIQUE RRs. Instead, why not just send an RR query? Perhaps someone can explain what the benefit is -- and why it outweighs the additional complexity. Personally, I do not see the benefit of dynamic update, but am willing to be convinced otherwise.