From owner-zeroconf@merit.edu Sun Dec 1 20:55:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19961 for ; Sun, 1 Dec 2002 20:55:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 64ED691225; Sun, 1 Dec 2002 20:58:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30B4791249; Sun, 1 Dec 2002 20:58: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 0A24B91225 for ; Sun, 1 Dec 2002 20:58:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id E185B5E04A; Sun, 1 Dec 2002 20:58:34 -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 C590E5DEFD for ; Sun, 1 Dec 2002 20:58:34 -0500 (EST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gB21wV29005069; Sun, 1 Dec 2002 18:58:31 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id SAA27659; Sun, 1 Dec 2002 18:58:28 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gB21wM7C028346; Mon, 2 Dec 2002 12:58:23 +1100 (EST) Message-ID: <3DEABE3F.50209@motorola.com> Date: Mon, 02 Dec 2002 12:58:23 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten Cc: Stuart Cheshire , zeroconf@merit.edu, Dave Thaler Subject: Re: Where did this TTL=255 idea come from? References: <200211292120.gATLKYO15731@cichlid.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thomas Narten wrote: > The way I understand the issues: > > Enforcing the 255-on-receipt check is non-backwards > compatable. Indeed, it occurred to me today that its non-backwards > compatable with nodes that don't even implement LL > addressing. Consider a node A, on the same link with B. A has a global > address, B has a LL address. If A attempts to communicate with B, but > B notices that the dest address is LL, and then checks for a TTL of > 255 (following the recommendation in the current ID), communication > will likely fail. So here we have a case where two nodes with valid > addresses can't communicate for non-obvious reasons. Neither > implementation is violating a Standard. Note the A has not implemented > LL at all, so it can't be violating any LL standard. > The same thing occurred to me today, however I applied it to the "TTL=1 stops leakage" case. Non-LL-aware nodes responding to LL source addresses will set their TTL to whatever the OS default is. If they further use their default route (as they are likely to do), the packets get delivered to a router. TTL=1 doesn't save us at this point. Also, the responses going to a default router won't return to the initiating LL node, so communication is likely to be broken regardless of what the TTL is set to. I think we have to assume that non-LL-aware nodes responding to LL source addresses will use their default route and will set a TTL on those packets other than 1 or 255. > Is this not a potential interoperability problem that we shouldn't > knowingly encourage? Assuming that we want to support LL communication with nodes that are not LL-aware. At the moment I don't think it is worth the effort to interoperate with non-LL-aware nodes. ( The text in Section 1.7 and 2.6 seems to imply that the nodes mixing LL and non-LL addresses are to some extent aware of the address differences and can make a decision about when to ARP directly for the destination (ie ARP for LL when I am non-LL-only, and ARP for non-LL when I am LL-only). Nodes behaving like this are to some extent LL-aware. ) > However, now that Apple does this check, setting the TTL to anything > other than 255 is also problematic. > > That might argue for setting it to 255 (and explaining in the document > why), but also saying SHOULD NOT or MUST NOT do the check on receipt > since we know it also causes problems with existing implementations > that don't set the TTL this way. (Note we could say that the test > might be changed in a future standard once the deployed base is > upgraded/junked, but it is too early to say that today if one wants to > avoid interoperability problems today). > Not checking TTL=255 on receipt is a statement that assurances about non-forwarding are no longer important. If that is the case, I'm fine with setting TTL=255 and not checking as a way of minimising problems. It would be nice to hear from Dave Thaler on this. I believe he proposed the TTL=255 change, and he might have some comments regarding the importance of interoperability with Windows systems that don't currently behave this way. > But setting the TTL to 255 (rather than 1) also will lead to more LL > packets going off link then if the TTL is set to 1. Sure, hosts aren't > *supposed* to forward them to routers, but some leakage will > inevitably happen as a result of misconfigurations, and other things > that are "not supposed to happen". This may cause operational > problems. How much? Hard to say. Depends on how many (and which) > routers do filtering. I don't believe we need 100% compliance here in > order to get enough filtering in practice to keep LL traffic from > leaking in horrible ways. For a home site, for example, does it care > if its LL traffic goes off link? Probably not. What it cares about is > that it doesn't go across the DSL link to its ISP (or that packets > from the ISP come in with LL addresses). But that is something the ISP > probably cares about enough to ensure that filters are fairly likely > to get put at that boundary. Etc. > I argued above that TTL=1 makes no difference for non-LL-aware nodes. They'll do whatever they do today and packets will leak with TTL=64 (or whatever) and follow the default route up to an ISP filter. LL-aware nodes sending LL requests (or LL responses) to a default router (ie leaking) will fail to communicate since the router will either forward along the default route, or will drop the packets. Implementation bugs causing leakage are therefore very likely to cause outright communication failure. Hence I believe we're unlikely to see leakage from LL-aware nodes (it causes communication failure). So, I don't find the TTL=1 leakage argument compelling. Setting the TTL=1 has a certain aesthetic appeal because it fits with my conception of link-local. We should certainly not *prevent* applications using LL communication and wanting assurances about packet forwarding from setting TTL=255 and checking. regards aidan ____ :wq! From owner-zeroconf@merit.edu Sun Dec 1 21:22:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20311 for ; Sun, 1 Dec 2002 21:22:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D592D9124B; Sun, 1 Dec 2002 21:25:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D1BB9124C; Sun, 1 Dec 2002 21:25: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 932669124B for ; Sun, 1 Dec 2002 21:25:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6DB8D5E03F; Sun, 1 Dec 2002 21:25:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by segue.merit.edu (Postfix) with ESMTP id 0BE225DFC6 for ; Sun, 1 Dec 2002 21:25:07 -0500 (EST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1B08C4B23; Mon, 2 Dec 2002 11:25:05 +0900 (JST) To: Stuart Cheshire Cc: zeroconf@merit.edu In-reply-to: cheshire's message of Fri, 29 Nov 2002 12:24:04 PST. <200211292023.gATKNv913784@scv3.apple.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Responses so far From: itojun@iijlab.net Date: Mon, 02 Dec 2002 11:25:05 +0900 Message-Id: <20021202022505.1B08C4B23@coconut.itojun.org> Sender: owner-zeroconf@merit.edu Precedence: bulk >It's Thanksgiving, so most people are off work, but here is a summary of >the responses I've received so far: > >People willing to argue in support of Option 2 >(Set TTL=1 on transmit, check TTL==1 on receipt) >RJ Atkinson > >If your name is not listed, and you feel you have a technical opinion >you'd be willing to support, please send mail to the list or to me >privately. Please try to keep your email short and to-the-point. For >example, Keith Moore has written a great volume of email, but I can't >tell which of these positions (if any) he is advocating. i'd support option 2, since IPv4 link local address appeared later in the IPv4 deployment, so routers do not implement any special rules for avoiding off-ilnk forwarding of packets with IPv4 link local address. therefore, with TTL=255 packet might leak off-link, to very distant location (in the way of default route, or whatever). the situation is quite different from IPv6 link local address case. itojun From owner-zeroconf@merit.edu Mon Dec 2 20:08:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20310 for ; Mon, 2 Dec 2002 20:08:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4C64991235; Mon, 2 Dec 2002 20:11:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A32891236; Mon, 2 Dec 2002 20:11:31 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1621891235 for ; Mon, 2 Dec 2002 20:11:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 067A35E021; Mon, 2 Dec 2002 20:11:30 -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 AE0485DF3C for ; Mon, 2 Dec 2002 20:11:29 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id gB31BTaf004775 for ; Mon, 2 Dec 2002 18:11:29 -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 SAA10238 for ; Mon, 2 Dec 2002 18:11:27 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gB31BP7C028053 for ; Tue, 3 Dec 2002 12:11:25 +1100 (EST) Message-ID: <3DEC04BD.3030002@motorola.com> Date: Tue, 03 Dec 2002 12:11:25 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: zeroconf Subject: TTL=255 on xmit, no check on receipt please Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi there, I wrote a message yesterday that was a bit tortuous so I thought I would summarise/try-again after having a sleep. First, TTL and security. I thought we had come to the consensus that checking the TTL had no particular security value. I agree with this point of view. Any security value that checking the TTL=255 in my home network comes from the environment. If I do the same check whilst connected to the IETF network I don't get much assurance of anything.. Second, how does leakage occur? Leakage occurs when a node sends a packet to a 169.254/16 address to a router, which forwards the packet off the link. The vast majority of deployed IPv4 routers will follow their default route as they don't treat 169.254/16 as special. There are two possible leakers: LL-aware nodes, and non-LL aware nodes. LL-aware nodes that forward 169.254/16 packets to their local router are broken. So broken that their LL communication will plainly not work. Therefore the implementation flaw where they send LL-destined packets to a router is pretty unlikely. Non-LL-aware nodes on the other hand are quite likely to send 169.254/16 destined traffic to their default router. They don't have a route table entry to tell them not to. If they receive packets with 169.254/16 source addresses they will respond by sending packets to their default router (examples are TCP connections, broadcast packets, etc). When they send these packets they will use TTL=64 (or whatever the OS default is). A statement in the IPv4 LL document requiring TTL=1 won't be honoured by Non-LL-aware nodes, which are the main leakage vector. Hence a TTL=1 statement will have little effect on leakage. Thirdly, there are non-interoperable implmentations today. We should try hard not to break those implementations. Requiring TTL=255 on send avoids breaking the MacOS implementation. Allowing the TTL check to be ignored helps with Windows. This change won't make life worse for existing implementations and it won't make existing implementations interoperate any better than they do today. Given that the actual TTL value has very little effect on the actual likelihood of leakage, setting the TTL=255 on send and dropping the receipt check is a good compromise. regards aidan ____ :wq! From owner-zeroconf@merit.edu Mon Dec 2 21:31:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22546 for ; Mon, 2 Dec 2002 21:31:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4859A91280; Mon, 2 Dec 2002 21:34:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A10291281; Mon, 2 Dec 2002 21:34: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 0A8F491280 for ; Mon, 2 Dec 2002 21:34:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id E50A75DFDB; Mon, 2 Dec 2002 21:34:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [208.254.46.17]) by segue.merit.edu (Postfix) with ESMTP id 6C9365DDB3 for ; Mon, 2 Dec 2002 21:34:25 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.91.81.100]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id gB32YNQ25027 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 2 Dec 2002 21:34:24 -0500 Message-Id: <5.2.0.9.2.20021202211449.029bf360@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 02 Dec 2002 21:30:11 -0500 To: zeroconf From: Daniel Senie Subject: Re: TTL=255 on xmit, no check on receipt please In-Reply-To: <3DEC04BD.3030002@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 08:11 PM 12/2/2002, Aidan Williams wrote: >Hi there, > >I wrote a message yesterday that was a bit tortuous so I >thought I would summarise/try-again after having a sleep. > >First, TTL and security. I thought we had come to the consensus >that checking the TTL had no particular security value. No. The comment made was that we wouldn't discuss security, and whether the TTL value has security merit. There was no consensus that I saw to actually conclude whether there were any security advantages. >I agree >with this point of view. Any security value that checking the >TTL=255 in my home network comes from the environment. If I >do the same check whilst connected to the IETF network I don't >get much assurance of anything.. The question is whether there is merit in ensuring, now and in the future, that link local traffic stay on the local link. >Second, how does leakage occur? Leakage occurs when a node sends >a packet to a 169.254/16 address to a router, which forwards the >packet off the link. The vast majority of deployed IPv4 routers >will follow their default route as they don't treat 169.254/16 as >special. In the examples you and I discussed separately, I pointed out that the traffic would never get anywhere. A packet from another node on a local link MAY wind up going out through default gateway IF the node responding does not recognize LL. The default router may leak this response packet. However, the packet will at some point hit a router in the default-free-zone, and the expectation is no backbone or ISP will advertise 169.254/16 in the DFZ. Packets coming from outside a network into the LL network, with spoofed source addresses would have to originate nearby, be source routed, or otherwise find ways to bypass the routing table contents. Again, there seem to be other means to deflect such attacks. 169.254/16 is NOT globally routed, and so reaching in to a LL network is less easy than you let on in your analysis. >There are two possible leakers: > LL-aware nodes, and non-LL aware nodes. > >LL-aware nodes that forward 169.254/16 packets to their local >router are broken. So broken that their LL communication will >plainly not work. Therefore the implementation flaw where they >send LL-destined packets to a router is pretty unlikely. > >Non-LL-aware nodes on the other hand are quite likely to send >169.254/16 destined traffic to their default router. >They don't have a route table entry to tell them not to. >If they receive packets with 169.254/16 source addresses >they will respond by sending packets to their default router >(examples are TCP connections, broadcast packets, etc). >When they send these packets they will use TTL=64 >(or whatever the OS default is). > >A statement in the IPv4 LL document requiring TTL=1 won't >be honoured by Non-LL-aware nodes, which are the main >leakage vector. Hence a TTL=1 statement will have little >effect on leakage. > >Thirdly, there are non-interoperable implmentations today. >We should try hard not to break those implementations. >Requiring TTL=255 on send avoids breaking the MacOS >implementation. Allowing the TTL check to be ignored >helps with Windows. This change won't make life worse >for existing implementations and it won't make existing >implementations interoperate any better than they do today. In examining the Windows XP machine I'm typing on, I find no evidence of the LAN interface retaining its LL address. It would appear Microsoft uses the same behavior as it has for some time, releasing the LL address at the point at which DHCP succeeds. As such, the only issue I see with interoperability is with putting Mac and Win machines on the same network with no DHCP server present. It could be argued Apple was a bit premature with its switch to require TTL=255 (vs. just setting it), and should have waited until this I-D was published as an RFC. This is not the first time an I-D has been used as justification for a change in behaviour, with questionable results (a case with an I-D altering DVMRP requirements on the MBONE many years ago has some similarity). That said, I believe the TTL=255 on transmit is the right way to go, and a timeline of 1 or 2 years following the publication of the I-D as an RFC would be prudent as a grace period to impose a MUST on checking the TTL=255. >Given that the actual TTL value has very little effect on >the actual likelihood of leakage, setting the TTL=255 on >send and dropping the receipt check is a good compromise. While you're worried about leakage, there's another consideration to the TTL=255 issue. The claim and defend mechanism for LL addresses requires nodes to be within a single ARP domain. A router (not aware of LL, but configured for 169.254/something) could wreak havoc if connected between two LL segments. The TTL=255 is there, to my way of thinking, to help ensure routers CANNOT be present within a LL network. Providing a grace period after publication would permit router vendors and host vendors time to release updated software which understands LL, providing a productive path forward. From owner-zeroconf@merit.edu Mon Dec 2 22:33:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24424 for ; Mon, 2 Dec 2002 22:33:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6FC6291282; Mon, 2 Dec 2002 22:36:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 352C091284; Mon, 2 Dec 2002 22:36:24 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1D18291282 for ; Mon, 2 Dec 2002 22:36:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id F334C5DDF9; Mon, 2 Dec 2002 22:36:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by segue.merit.edu (Postfix) with ESMTP id 8D0FC5DD9A for ; Mon, 2 Dec 2002 22:36:22 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gB33aLrb058164; Mon, 2 Dec 2002 22:36:21 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-194-165.mts.ibm.com [9.65.194.165]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gB33aIUE016198; Mon, 2 Dec 2002 22:36:18 -0500 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id gB33ZcO04252; Mon, 2 Dec 2002 22:35:38 -0500 Message-Id: <200212030335.gB33ZcO04252@cichlid.adsl.duke.edu> To: Daniel Senie Cc: zeroconf Subject: Re: TTL=255 on xmit, no check on receipt please In-Reply-To: Message from Daniel Senie of "Mon, 02 Dec 2002 21:30:11 EST." <5.2.0.9.2.20021202211449.029bf360@mail.amaranth.net> Date: Mon, 02 Dec 2002 22:35:37 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Daniel Senie writes: > The question is whether there is merit in ensuring, now and in the future, > that link local traffic stay on the local link. This point could use a bit more clarification. Is the goal just that well-behaved nodes that implement LL not generate traffic that leaves the link? Or is it to prevent as much as possible that LL traffic (regardless of the souce) doesn't leave the link, even when implementations screw up somewhat, or LL addresses are used by implementations that don't actually implement LL addressing? Seems like using a TTL of 1 as much as possible will help keep traffic local, since such traffic, regardless of how it is sent, just won't go far. In contrast, setting the TTL to 255, would be about the worst choice, if the most important criteria is to keep LL traffic on link. Given your statement above, I'm confused about the later conclusion that the TTL should be set to 255. Am I the only one who thinks setting the TTL to 255 on send will make it harder to keep LL traffic on the local link? > >Second, how does leakage occur? Leakage occurs when a node sends > >a packet to a 169.254/16 address to a router, which forwards the > >packet off the link. The vast majority of deployed IPv4 routers > >will follow their default route as they don't treat 169.254/16 as > >special. > In the examples you and I discussed separately, I pointed out that the > traffic would never get anywhere. A packet from another node on a local > link MAY wind up going out through default gateway IF the node responding > does not recognize LL. The default router may leak this response packet. > However, the packet will at some point hit a router in the > default-free-zone, and the expectation is no backbone or ISP will advertise > 169.254/16 in the DFZ. > Packets coming from outside a network into the LL network, with spoofed > source addresses would have to originate nearby, be source routed, or > otherwise find ways to bypass the routing table contents. Again, there seem > to be other means to deflect such attacks. > 169.254/16 is NOT globally routed, and so reaching in to a LL network is > less easy than you let on in your analysis. What you seem to be aruging is that there will in general be enough routers that filter LL traffic. Thus leaking LL traffic won't be a problem in general, even if not every router actually does the filtering. It's not important that *every* router filter LL traffic, just the key ones. This seems a useful line of analysis. At what routers does LL filtering need to happen in order to minimize problems? Are there sufficient economic incentives to ensure that filtering will be enabled on those routers? I guess one place there will be problems if packets from one link reach another, and there are address collisions on the two links. Then the traffic doens't just go nowhere, it gets sent to nodes that might get confused. > That said, I believe the TTL=255 on transmit is the right way to go, > and a timeline of 1 or 2 years following the publication of the I-D > as an RFC would be prudent as a grace period to impose a MUST on > checking the TTL=255. How does a node implementing LL interoperate with a node not implementing LL addressing at all (i.e, that only uses a global address)? The node not implementing LL won't set the TTL to 255. Those nodes will never set the TTL to 255, as they don't plan on ever implementing LL addressing. Will the TTL==255 check on receipt ever be a reasonable thing to do then? > Providing a grace period after publication would permit router vendors and > host vendors time to release updated software which understands LL, > providing a productive path forward. Will all nodes/routers be required to implement LL addressing in the future? I had assumed it would be an optional standard, one only those nodes planning on assigning LL addresses to their interfaces would need to implement. Thomas From owner-zeroconf@merit.edu Mon Dec 2 23:32:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25722 for ; Mon, 2 Dec 2002 23:32:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5F0939128F; Mon, 2 Dec 2002 23:34:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 119909128B; Mon, 2 Dec 2002 23:34: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 7AB189128F for ; Mon, 2 Dec 2002 23:34:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6415D5DD9A; Mon, 2 Dec 2002 23:34:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [208.254.46.17]) by segue.merit.edu (Postfix) with ESMTP id E72AC5DE1C for ; Mon, 2 Dec 2002 23:34:41 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.91.81.100]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id gB34YeQ28327 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 2 Dec 2002 23:34:41 -0500 Message-Id: <5.2.0.9.2.20021202230120.00b7f618@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 02 Dec 2002 23:32:35 -0500 To: zeroconf From: Daniel Senie Subject: Re: TTL=255 on xmit, no check on receipt please In-Reply-To: <200212030335.gB33ZcO04252@cichlid.adsl.duke.edu> References: <5.2.0.9.2.20021202211449.029bf360@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 10:35 PM 12/2/2002, Thomas Narten wrote: >Daniel Senie writes: > > > The question is whether there is merit in ensuring, now and in the future, > > that link local traffic stay on the local link. > >This point could use a bit more clarification. > >Is the goal just that well-behaved nodes that implement LL not >generate traffic that leaves the link? Or is it to prevent as much as >possible that LL traffic (regardless of the souce) doesn't leave the >link, even when implementations screw up somewhat, or LL addresses are >used by implementations that don't actually implement LL addressing? > >Seems like using a TTL of 1 as much as possible will help keep traffic >local, since such traffic, regardless of how it is sent, just won't go >far. In contrast, setting the TTL to 255, would be about the worst >choice, if the most important criteria is to keep LL traffic on link. > >Given your statement above, I'm confused about the later conclusion >that the TTL should be set to 255. Am I the only one who thinks >setting the TTL to 255 on send will make it harder to keep LL traffic >on the local link? Setting TTL=255 permits stations that know to do so, the ability to know if packets have traversed routers. Knowing this, it is possible to squelch traffic originating beyond a router (even if that router knows about 169.254/16 addresses). Clearly in the short term setting TTL=255 leads to a greater possibility of a router being willing to transmit traffic beyond the local link, but this is mitigated by the fact that implementations which do set TTL=255 will also be new implementations, which we would hope do not screw up and send packets via default route that have a source IP address in 169.254/16. In other words, if the node is compliant and aware of LL rules, it should NEVER send a TTL=255 packet to a router. > > >Second, how does leakage occur? Leakage occurs when a node sends > > >a packet to a 169.254/16 address to a router, which forwards the > > >packet off the link. The vast majority of deployed IPv4 routers > > >will follow their default route as they don't treat 169.254/16 as > > >special. > > > In the examples you and I discussed separately, I pointed out that the > > traffic would never get anywhere. A packet from another node on a local > > link MAY wind up going out through default gateway IF the node responding > > does not recognize LL. The default router may leak this response packet. > > However, the packet will at some point hit a router in the > > default-free-zone, and the expectation is no backbone or ISP will > advertise > > 169.254/16 in the DFZ. > > > Packets coming from outside a network into the LL network, with spoofed > > source addresses would have to originate nearby, be source routed, or > > otherwise find ways to bypass the routing table contents. Again, there > seem > > to be other means to deflect such attacks. > > > 169.254/16 is NOT globally routed, and so reaching in to a LL network is > > less easy than you let on in your analysis. > >What you seem to be aruging is that there will in general be enough >routers that filter LL traffic. Thus leaking LL traffic won't be a >problem in general, even if not every router actually does the >filtering. It's not important that *every* router filter LL traffic, >just the key ones. I'm arguing there would be significant effort involved in generating an attack against a LinkLocal network in a house/enterprise/etc. across the public network using normal routing, since we expect 169.254/16, which has been identified as special use for some years, to NOT be in the default-free-zone. Unless the attacker has access to the routing gear that connects the site via some means, it will be hard to get such packets forwarded to that LAN segment. >This seems a useful line of analysis. At what routers does LL >filtering need to happen in order to minimize problems? Are there >sufficient economic incentives to ensure that filtering will be >enabled on those routers? The question for you is whether you want to consider the lack of a route in the DFZ routing table a "filter?" I would argue it'd be useful and helpful if routers were required to route 169.254/16 to a null device, and drop packets with a 169.254/16 source address. >I guess one place there will be problems if packets from one link >reach another, and there are address collisions on the two links. Then >the traffic doens't just go nowhere, it gets sent to nodes that might >get confused. This I allude to below. It breaks the claim-and-defend model of selecting addresses to permit routing between such segments. > > That said, I believe the TTL=255 on transmit is the right way to go, > > and a timeline of 1 or 2 years following the publication of the I-D > > as an RFC would be prudent as a grace period to impose a MUST on > > checking the TTL=255. > >How does a node implementing LL interoperate with a node not >implementing LL addressing at all (i.e, that only uses a global >address)? The question I'd ask is, why does it need to? I work with the assumption that there will be NO communication between LL and global address spaces. If you have an application which requires talking to devices that only operate on LL, then the application needs to be on a node that has both a LL address and a global address. In other words, you need an application level entity (which could be an application level gateway). > The node not implementing LL won't set the TTL to 255. Those >nodes will never set the TTL to 255, as they don't plan on ever >implementing LL addressing. Will the TTL==255 check on receipt ever be >a reasonable thing to do then? My argument above effectively gives my answer on this. > > Providing a grace period after publication would permit router vendors and > > host vendors time to release updated software which understands LL, > > providing a productive path forward. > >Will all nodes/routers be required to implement LL addressing in the >future? Only those which wish to talk to other nodes using LL addressing. > I had assumed it would be an optional standard, one only those >nodes planning on assigning LL addresses to their interfaces would >need to implement. I have been working on the assumption that only those nodes which want to talk to other nodes using LL would need to implement it. Devices which are designed to permanently operate only on LL addressing would only be accessible from nodes which themselves have an LL address. Any attempt to communicate further would be blocked by the TTL rule in the present draft. The question is whether this is a good thing? At this point, I think it is. See section 1.5 in the Zeroconf requirements I-D. I think this backs up what I'm saying here. The implication is that link local addressing is, well, local to the link. This implies no passage through routers. checking TTL=255 ensures packets have not passed through a router (where router is defined in RFC 1812, certainly any piece of equipment can be altered to do non-standard things). It may be helpful to think of Link Local addresses as being handled in similar fashion to Limited Broadcast (255.255.255.255, see RFC 1812 section 5.3.5.1) in terms of how a router can and should respond to such addresses. As I stated in another message, it may be worthwhile to follow the I-D under discussion (assuming it reaches RFC status) with a second standards-track document which specifically updates RFC 1812 in terms of how to deal with Link Local addressing. From owner-zeroconf@merit.edu Tue Dec 3 00:18:15 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26881 for ; Tue, 3 Dec 2002 00:18:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D38889128D; Tue, 3 Dec 2002 00:18:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4BD5C9128B; Tue, 3 Dec 2002 00:18: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 DC6F49128D for ; Tue, 3 Dec 2002 00:18:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id C49745DDF9; Tue, 3 Dec 2002 00:18:32 -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 7A2BB5DDDB for ; Tue, 3 Dec 2002 00:18:32 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id gB35IFrj007785; Mon, 2 Dec 2002 22:18:15 -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 WAA03789; Mon, 2 Dec 2002 22:13:57 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gB35IR7C009510; Tue, 3 Dec 2002 16:18:27 +1100 (EST) Message-ID: <3DEC3EA4.30706@motorola.com> Date: Tue, 03 Dec 2002 16:18:28 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Senie Cc: zeroconf Subject: Re: TTL=255 on xmit, no check on receipt please References: <5.2.0.9.2.20021202211449.029bf360@mail.amaranth.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Daniel Senie wrote: >> Second, how does leakage occur? Leakage occurs when a node sends >> a packet to a 169.254/16 address to a router, which forwards the >> packet off the link. The vast majority of deployed IPv4 routers >> will follow their default route as they don't treat 169.254/16 as >> special. > > In the examples you and I discussed separately, I pointed out that the > traffic would never get anywhere. A packet from another node on a local > link MAY wind up going out through default gateway IF the node > responding does not recognize LL. The default router may leak this > response packet. However, the packet will at some point hit a router in > the default-free-zone, and the expectation is no backbone or ISP will > advertise 169.254/16 in the DFZ. > I agree -- when I have talked about packets following the default route I mean up to the DFZ where they (hopefully) get dropped. I disagree that this is "never get anywhere". I think of this as leakage, and the packets get somewhere. In the networks I use, "somewhere" is at least 6 hops away. > Packets coming from outside a network into the LL network, with spoofed > source addresses would have to originate nearby, be source routed, or > otherwise find ways to bypass the routing table contents. Again, there > seem to be other means to deflect such attacks. > > 169.254/16 is NOT globally routed, and so reaching in to a LL network > is less easy than you let on in your analysis. > My analysis is concerned with how packets leak *out*. Perhaps a more useful example is an LL-only host attempting to communicate with a local non-LL-aware host (this is explicitly allowed in the draft). The packets received by the non-LL-aware host will have a LL source address and a global destination. When the non-LL-aware host replies, where do the packets go? Answer: out the default route and up to the DFZ. Packets with spoofed LL source addresses don't need to originate nearby and don't need stuff like source routes to get them through since they are routed purely on the destination address. OTOH, Getting packets with LL destinations delivered through the internet is as you rightly point out, hard. > In examining the Windows XP machine I'm typing on, I find no evidence of > the LAN interface retaining its LL address. It would appear Microsoft > uses the same behavior as it has for some time, releasing the LL address > at the point at which DHCP succeeds. As such, the only issue I see with > interoperability is with putting Mac and Win machines on the same > network with no DHCP server present. Fair point. Still, it would be nice if the standard let them work in that circumstance. > While you're worried about leakage, there's another consideration to the > TTL=255 issue. The claim and defend mechanism for LL addresses requires > nodes to be within a single ARP domain. A router (not aware of LL, but > configured for 169.254/something) could wreak havoc if connected between > two LL segments. The TTL=255 is there, to my way of thinking, to help > ensure routers CANNOT be present within a LL network. > Hmmm. Thinking about this, I don't think ARP has a TTL. Were you thinking that the TTL check should be applied to IP packets forwarded or to ARP proxies (somehow)? - aidan From owner-zeroconf@merit.edu Tue Dec 3 01:10:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28756 for ; Tue, 3 Dec 2002 01:10:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 277FC9128B; Tue, 3 Dec 2002 01:12:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EEE739128E; Tue, 3 Dec 2002 01:12: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 B870F9128B for ; Tue, 3 Dec 2002 01:12:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B5245DE79; Tue, 3 Dec 2002 01:12:55 -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 514BB5DE41 for ; Tue, 3 Dec 2002 01:12:55 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gB36CseW004868; Mon, 2 Dec 2002 23:12:54 -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 XAA19299; Mon, 2 Dec 2002 23:08:20 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gB36Cm7C012251; Tue, 3 Dec 2002 17:12:48 +1100 (EST) Message-ID: <3DEC4B61.5060603@motorola.com> Date: Tue, 03 Dec 2002 17:12:49 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten Cc: Daniel Senie , zeroconf Subject: Re: TTL=255 on xmit, no check on receipt please References: <200212030335.gB33ZcO04252@cichlid.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thomas Narten wrote: > Is the goal just that well-behaved nodes that implement LL not > generate traffic that leaves the link? Or is it to prevent as much as > possible that LL traffic (regardless of the souce) doesn't leave the > link, even when implementations screw up somewhat, or LL addresses are > used by implementations that don't actually implement LL addressing? > > Seems like using a TTL of 1 as much as possible will help keep traffic > local, since such traffic, regardless of how it is sent, just won't go > far. In contrast, setting the TTL to 255, would be about the worst > choice, if the most important criteria is to keep LL traffic on link. > We should be looking at minimising (or at least understanding and documenting) all sources of leakage we can think of. > Am I the only one who thinks > setting the TTL to 255 on send will make it harder to keep LL traffic > on the local link? > The right answer would *seem* to be obvious.. ;-) However... I think the main cause of leakage will be from nodes that don't understand 169.254/16. They'll use whatever TTL they normally use (which won't be 1 and won't be 255). These packets will head up the default route and get dropped at the same place the TTL=255 packets will be dropped at. (TTL=255 packets will last longer in routing loops, but I don't think this is something we should be concerned about.) If we are *not* worried about interoperability (I thought this was how we got into this discussion in the first place) then a choice of TTL=1 for LL-aware implementations would make people feel better but (IMO) wouldn't make much difference to the actual amount of leakage. > This seems a useful line of analysis. At what routers does LL > filtering need to happen in order to minimize problems? Are there > sufficient economic incentives to ensure that filtering will be > enabled on those routers? > My best guess is: probably. In Australia the main cost is in overseas transmission. Various key routers can be configured with an ACL that drops 169.254/16 traffic easily enough before burning dollars going overseas. > I guess one place there will be problems if packets from one link > reach another, and there are address collisions on the two links. Then > the traffic doens't just go nowhere, it gets sent to nodes that might > get confused. > This is an interesting thing to think about. Routers forwarding link-local along some path won't consider themselves connected to a 169.254/16 subnet, so they won't ARP for LL IP addresses (they'll be ARPing for router next hops) and hence the LL traffic will pass over those links as a ship in the night. If someone chose to forward 169.254/16 to a particular link, then yes, all hell breaks loose on that link from an address conflict point of view as the router ARPs for random 169.254 addresses as it tries to deliver packets. > How does a node implementing LL interoperate with a node not > implementing LL addressing at all (i.e, that only uses a global > address)? The node not implementing LL won't set the TTL to 255. Those > nodes will never set the TTL to 255, as they don't plan on ever > implementing LL addressing. Will the TTL==255 check on receipt ever be > a reasonable thing to do then? > Exactly. No, I don't think the TTL=255 makes sense in this case. But that isn't all. Harping on a theme: for the whole thing to work, the non-LL-aware host has to know to send the responses to the local link rather than off to the default router. Not going to happen.... hence leakage. > Will all nodes/routers be required to implement LL addressing in the > future? I had assumed it would be an optional standard, one only those > nodes planning on assigning LL addresses to their interfaces would > need to implement. > Optional. - aidan From owner-zeroconf@merit.edu Tue Dec 3 01:22:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28992 for ; Tue, 3 Dec 2002 01:22:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B2B069128E; Tue, 3 Dec 2002 01:25:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A4C491290; Tue, 3 Dec 2002 01:25: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 8080A9128E for ; Tue, 3 Dec 2002 01:25:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 663715DDCA; Tue, 3 Dec 2002 01:25:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from broadviewnet.net (ols.broadviewnet.net [64.115.0.8]) by segue.merit.edu (Postfix) with SMTP id E65855DD9A for ; Tue, 3 Dec 2002 01:25:11 -0500 (EST) Received: (qmail 6385 invoked from network); 3 Dec 2002 06:24:55 -0000 Received: from unknown (HELO kabilla) (66.219.68.108) by smtp.broadviewnet.net with SMTP; 3 Dec 2002 06:24:55 -0000 Message-ID: <007001c29a94$bb97cbc0$6401a8c0@kabilla> From: "Bill Rees" To: "Aidan Williams" , "Thomas Narten" Cc: "Daniel Senie" , "zeroconf" References: <200212030335.gB33ZcO04252@cichlid.adsl.duke.edu> <3DEC4B61.5060603@motorola.com> Subject: Re: TTL=255 on xmit, no check on receipt please Date: Mon, 2 Dec 2002 22:25:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Aidan Williams" To: "Thomas Narten" Cc: "Daniel Senie" ; "zeroconf" Sent: Monday, December 02, 2002 10:12 PM Subject: Re: TTL=255 on xmit, no check on receipt please > Thomas Narten wrote: > > Is the goal just that well-behaved nodes that implement LL not > > generate traffic that leaves the link? Or is it to prevent as much as > > possible that LL traffic (regardless of the souce) doesn't leave the > > link, even when implementations screw up somewhat, or LL addresses are > > used by implementations that don't actually implement LL addressing? > > > > Seems like using a TTL of 1 as much as possible will help keep traffic > > local, since such traffic, regardless of how it is sent, just won't go > > far. In contrast, setting the TTL to 255, would be about the worst > > choice, if the most important criteria is to keep LL traffic on link. > > > > We should be looking at minimising (or at least understanding > and documenting) all sources of leakage we can think of. > So the idea is to isolate LL nets from the rest of the world? How does traffic move between LL and non LL nets then? From owner-zeroconf@merit.edu Tue Dec 3 01:33:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29273 for ; Tue, 3 Dec 2002 01:33:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AA87991290; Tue, 3 Dec 2002 01:36:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73EE291291; Tue, 3 Dec 2002 01:36: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 7650391290 for ; Tue, 3 Dec 2002 01:36:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5F0A55DE79; Tue, 3 Dec 2002 01:36:28 -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 471C65DE41 for ; Tue, 3 Dec 2002 01:36:28 -0500 (EST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gB36aVNr012894; Mon, 2 Dec 2002 23:36:32 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id XAA21855; Mon, 2 Dec 2002 23:36:24 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gB36aL7C013326; Tue, 3 Dec 2002 17:36:21 +1100 (EST) Message-ID: <3DEC50E6.6000202@motorola.com> Date: Tue, 03 Dec 2002 17:36:22 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Senie Cc: zeroconf Subject: Re: TTL=255 on xmit, no check on receipt please References: <5.2.0.9.2.20021202211449.029bf360@mail.amaranth.net> <5.2.0.9.2.20021202230120.00b7f618@mail.amaranth.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Daniel Senie wrote: >> I guess one place there will be problems if packets from one link >> reach another, and there are address collisions on the two links. Then >> the traffic doens't just go nowhere, it gets sent to nodes that might >> get confused. > > This I allude to below. It breaks the claim-and-defend model of > selecting addresses to permit routing between such segments. > Doesn't claim and defend get broken purely because the router ARPs repeatedly for 169.254 addresses? (Section 2.5, IPv4-LL) There isn't a TTL to check in the ARP packet which would allow a host to ignore "ARPs resulting from non-local packets". One could perhaps try to identify the router and ignore ARPs from it, but that seems really flaky. - aidan From owner-zeroconf@merit.edu Tue Dec 3 09:02:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20476 for ; Tue, 3 Dec 2002 09:02:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 188C791296; Tue, 3 Dec 2002 09:04:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA2D991298; Tue, 3 Dec 2002 09:04:39 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F2D7791296 for ; Tue, 3 Dec 2002 09:04:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id E022B5DE3B; Tue, 3 Dec 2002 09:04:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [208.254.46.17]) by segue.merit.edu (Postfix) with ESMTP id 73ADF5DE0C for ; Tue, 3 Dec 2002 09:04:38 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.91.81.100]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id gB3E4NS10583 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Tue, 3 Dec 2002 09:04:25 -0500 Message-Id: <5.2.0.9.2.20021203085618.02ed4c60@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 03 Dec 2002 09:01:34 -0500 To: Aidan Williams From: Daniel Senie Subject: Re: TTL=255 on xmit, no check on receipt please Cc: zeroconf In-Reply-To: <3DEC50E6.6000202@motorola.com> References: <5.2.0.9.2.20021202211449.029bf360@mail.amaranth.net> <5.2.0.9.2.20021202230120.00b7f618@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 01:36 AM 12/3/2002, Aidan Williams wrote: >Daniel Senie wrote: >>>I guess one place there will be problems if packets from one link >>>reach another, and there are address collisions on the two links. Then >>>the traffic doens't just go nowhere, it gets sent to nodes that might >>>get confused. >>This I allude to below. It breaks the claim-and-defend model of selecting >>addresses to permit routing between such segments. > >Doesn't claim and defend get broken purely because the router >ARPs repeatedly for 169.254 addresses? (Section 2.5, IPv4-LL) To defend, a station ARPs its own address to see if someone else responds. Unless proxy-arping, a router has no business answering for addresses that are not its own. >There isn't a TTL to check in the ARP packet which would allow >a host to ignore "ARPs resulting from non-local packets". I think you're missing the point. >One could perhaps try to identify the router and ignore ARPs >from it, but that seems really flaky. The router's ARPs will be (assuming it's configured to know about 169.254/16) for other stations. Stations claiming and defending an address will ARP for the address they already are using themselves. These two are different in terms of actions taken. From owner-zeroconf@merit.edu Tue Dec 3 09:51:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23211 for ; Tue, 3 Dec 2002 09:51:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF17F91211; Tue, 3 Dec 2002 09:54:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90F4C91299; Tue, 3 Dec 2002 09:54:12 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D1F891211 for ; Tue, 3 Dec 2002 09:54:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F4CA5E0BE; Tue, 3 Dec 2002 09:54: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 62AE75E0BD for ; Tue, 3 Dec 2002 09:54:11 -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 6748159882 for ; Tue, 3 Dec 2002 14:54:12 +0000 (GMT) Message-ID: <009201c29adb$d54465a0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <200212030335.gB33ZcO04252@cichlid.adsl.duke.edu> Subject: Re: TTL=255 on xmit, no check on receipt please Date: Tue, 3 Dec 2002 14:54:07 -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" > ... > Am I the only one who thinks > setting the TTL to 255 on send will make it harder to keep LL traffic > on the local link? In crude terms yes. However, the use of Set/check TTL=255 will ensure that LL addressing only works between LL aware hosts (note. a host can use a routable address and still be LL aware). As such it is restrictive since it means that these will be completely unable to communicate with non LL aware hosts (including some legacy LL implementations) but this very fact is likely to lead to less leakage since communication with a Non-LL aware host (which might send packets to a router) will die almost immediately. Use of Set/No-check TTL=255 brings the dubious benefit of greatest potential for interoperability between compliant and non-compliant or partially compliant hosts but at the expense of greatest potential for hard to track issues with leakage and odd address conflicts. The third alternative of TTL=1 is more or less the same except that it excludes interoperability with some Apple implementations. note: The view that TTL=1 will restrict leakage is almost completely wrong, The only leakage it will stop is from hosts which stick to the spec well enough to set TTL to 1 but not well enough to avoid sending the packet to a router. Philip Nye From owner-zeroconf@merit.edu Tue Dec 3 10:58:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28920 for ; Tue, 3 Dec 2002 10:58:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2A57F912A4; Tue, 3 Dec 2002 11:00:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EDFF8912A5; Tue, 3 Dec 2002 11:00: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 32B00912A4 for ; Tue, 3 Dec 2002 11:00:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9989F5DF81; Tue, 3 Dec 2002 11:00:21 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id A3B175DED5 for ; Tue, 3 Dec 2002 11:00:20 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB3G0Gj24117 for ; Tue, 3 Dec 2002 11:00:17 -0500 (EST) Message-Id: <200212031600.gB3G0Gj24117@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Zeroconf Working Group" Subject: random things In-reply-to: (Your message of "Tue, 03 Dec 2002 14:54:07 GMT.") <009201c29adb$d54465a0$131010ac@aldebaran> Date: Tue, 03 Dec 2002 11:00:16 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk okay, I'm convinced that having LL-aware hosts set TTL=1 (rather than 255 or some other value) isn't of much use. I'm also convinced that checking for TTL==whatever isn't of much use. yes with the check your apps will ignore packets originating from off-link, and that will reduce replies and reduce the load on systems. but it doesn't do anything to stop LL traffic from getting through routers. to do that, you actually have to configure those routers to not forward such traffic. I'm curious, has anyone actually tried to see what it would take to get a non-LL-aware host to communicate with an LL-only host? From owner-zeroconf@merit.edu Tue Dec 3 13:45:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09305 for ; Tue, 3 Dec 2002 13:45:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B21E4912A9; Tue, 3 Dec 2002 13:47:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95181912AC; Tue, 3 Dec 2002 13:47:03 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 79316912A9 for ; Tue, 3 Dec 2002 13:46:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 503235DDD3; Tue, 3 Dec 2002 13:46:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 065B95DDA3 for ; Tue, 3 Dec 2002 13:46:30 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gB3IkTw14244 for ; Tue, 3 Dec 2002 10:46:29 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 3 Dec 2002 10:46:07 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id gB3IkT903231; Tue, 3 Dec 2002 10:46:29 -0800 (PST) Date: Tue, 3 Dec 2002 10:46:29 -0800 Subject: Re: TTL=255 on xmit, no check on receipt please Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: zeroconf To: Bill Rees From: Joshua Graessley In-Reply-To: <007001c29a94$bb97cbc0$6401a8c0@kabilla> Message-Id: <8920475A-06EF-11D7-8095-000393760260@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, December 2, 2002, at 10:25 PM, Bill Rees wrote: > So the idea is to isolate LL nets from the rest of the world? How does > traffic move between LL and non LL nets then? The idea is to let devices on the same link communicate even when other infrastructure, such as a DHCP server and gateway is broken or non-existent. Devices using LL addresses may coexist on a network with devices using global addresses. The LL devices may communicate with the devices that have a global address if both devices are aware of LL. The trick is that the device with the global address has to know to arp for the LL addresses instead of sending the packets through the default gateway. -josh From owner-zeroconf@merit.edu Tue Dec 3 15:00:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13749 for ; Tue, 3 Dec 2002 15:00:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CEA7291228; Tue, 3 Dec 2002 15:03:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 862EF912AB; Tue, 3 Dec 2002 15:03: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 6DC0B91228 for ; Tue, 3 Dec 2002 15:03:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4D52F5DF90; Tue, 3 Dec 2002 15:03:19 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [208.254.46.17]) by segue.merit.edu (Postfix) with ESMTP id 085025DDA3 for ; Tue, 3 Dec 2002 15:03:19 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.91.81.100]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id gB3K3HS26179 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 3 Dec 2002 15:03:18 -0500 Message-Id: <5.2.0.9.2.20021203150111.02a63828@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 03 Dec 2002 15:03:14 -0500 To: zeroconf From: Daniel Senie Subject: Re: TTL=255 on xmit, no check on receipt please In-Reply-To: <8920475A-06EF-11D7-8095-000393760260@apple.com> References: <007001c29a94$bb97cbc0$6401a8c0@kabilla> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 01:46 PM 12/3/2002, Joshua Graessley wrote: >On Monday, December 2, 2002, at 10:25 PM, Bill Rees wrote: > >>So the idea is to isolate LL nets from the rest of the world? How does >>traffic move between LL and non LL nets then? > >The idea is to let devices on the same link communicate even when other >infrastructure, such as a DHCP server and gateway is broken or >non-existent. Devices using LL addresses may coexist on a network with >devices using global addresses. The LL devices may communicate with the >devices that have a global address if both devices are aware of LL. The >trick is that the device with the global address has to know to arp for >the LL addresses instead of sending the packets through the default gateway. Right. Succinctly, all stations that want to use LL have to know about LL. So there's NO requirement that LL stations be able to communicate with stations not participating in LL. I think some of the wording in the draft could be tightened a bit, based on my reading last evening. Might cut down on confusion over this point. Dan From owner-zeroconf@merit.edu Tue Dec 3 19:06:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26190 for ; Tue, 3 Dec 2002 19:06:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3E8FB912B0; Tue, 3 Dec 2002 19:09:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E2AE912B1; Tue, 3 Dec 2002 19:09:22 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EC341912B0 for ; Tue, 3 Dec 2002 19:09:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id D15BD5E063; Tue, 3 Dec 2002 19:09:21 -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 8575E5DDF1 for ; Tue, 3 Dec 2002 19:09:21 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id gB409Qbo011697 for ; Tue, 3 Dec 2002 17:09:26 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id RAA27855 for ; Tue, 3 Dec 2002 17:09:19 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gB409F7C025131; Wed, 4 Dec 2002 11:09:16 +1100 (EST) Message-ID: <3DED47AD.8050309@motorola.com> Date: Wed, 04 Dec 2002 11:09:17 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Senie Cc: zeroconf Subject: Re: TTL=255 on xmit, no check on receipt please References: <5.2.0.9.2.20021202211449.029bf360@mail.amaranth.net> <5.2.0.9.2.20021202230120.00b7f618@mail.amaranth.net> <5.2.0.9.2.20021203085618.02ed4c60@mail.amaranth.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Daniel Senie wrote: >> Doesn't claim and defend get broken purely because the router >> ARPs repeatedly for 169.254 addresses? (Section 2.5, IPv4-LL) > > To defend, a station ARPs its own address to see if someone else > responds. Unless proxy-arping, a router has no business answering for > addresses that are not its own. > The router is just asking, not answering. Anyway, I was confused about the collision thing. Reflecting a bit more I don't think claim/collide gets broken. Any node using the address just answers the ARPs and the packets get (uselessly) delivered to it. Doing a TTL=255 check would allow the node ignore this traffic. Stepping back a bit, the TTL check allows ingres LL traffic to be ignored. Makes no difference to egress LL traffic. If you buy my contention that most egress LL traffic will come from non-LL-aware hosts, specifying TTL=1 won't help either. So in the end I think we are left with: - compatibilty of existing implementations versus - being able to reject ingres LL traffic. You made the point recently that most windows implementations disable LL whenever DHCP is around. This would tend to limit the potential interoperability problems quite nicely.. ;-) However, the two implementations will fail for the "two strangers on a train" case today. Do we care? Personally, I can't see much chance of ingress LL traffic arriving on a link (ie traffic coming in destined to 169.254/16). So the TTL=255 check seems a bit like a solution in search of a problem. I could live with either. regards aidan ____ :wq! From owner-zeroconf@merit.edu Tue Dec 3 22:44:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01891 for ; Tue, 3 Dec 2002 22:44:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B10D1912B4; Tue, 3 Dec 2002 22:45:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 722A8912B5; Tue, 3 Dec 2002 22:45: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 60276912B4 for ; Tue, 3 Dec 2002 22:45:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0EF995E0C2; Tue, 3 Dec 2002 22:45:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [208.254.46.17]) by segue.merit.edu (Postfix) with ESMTP id 68CEC5E0BB for ; Tue, 3 Dec 2002 22:45:53 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.91.81.100]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id gB43jqI06807 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 3 Dec 2002 22:45:52 -0500 Message-Id: <5.2.0.9.2.20021203222554.02a2a958@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 03 Dec 2002 22:40:43 -0500 To: zeroconf From: Daniel Senie Subject: Re: TTL=255 on xmit, no check on receipt please In-Reply-To: <3DED47AD.8050309@motorola.com> References: <5.2.0.9.2.20021202211449.029bf360@mail.amaranth.net> <5.2.0.9.2.20021202230120.00b7f618@mail.amaranth.net> <5.2.0.9.2.20021203085618.02ed4c60@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 07:09 PM 12/3/2002, you wrote: >Daniel Senie wrote: > >> Doesn't claim and defend get broken purely because the router > >> ARPs repeatedly for 169.254 addresses? (Section 2.5, IPv4-LL) > > > > To defend, a station ARPs its own address to see if someone else > > responds. Unless proxy-arping, a router has no business answering for > > addresses that are not its own. > > > >The router is just asking, not answering. Exactly. >Anyway, I was confused about the collision thing. OK. >Reflecting a bit more I don't think claim/collide gets broken. And to make this work, nodes ARP for their own address to ensure they keep it, and answer any arps for their address from others. Since a node trying to find an address to use will ARP for the proposed address, and select it if there is no response from another station, it is able to know it's OK to use that address. For this to work, the two stations need to be within the same ARP domain, i.e. same segment. >Any node using the address just answers the ARPs and the packets get >(uselessly) delivered to it. Doing a TTL=255 check would allow the >node ignore this traffic. A misconfigured router which is handling a sub-piece of the 169.254/16 space (for example if someone set up a router to handle 169.254.20/24) could create real problems but would also decrement the TTL. In this way, the TTL helps limit such damage. I would hope nobody would ever try to configure such a thing, but... >Stepping back a bit, the TTL check allows ingres LL traffic to be >ignored. You agree this is a good thing? > Makes no difference to egress LL traffic. If you buy my >contention that most egress LL traffic will come from non-LL-aware >hosts, specifying TTL=1 won't help either. On egress, a LL-aware node should never be sending an LL-sourced packet to a router. A non-LL-aware device might try to send a packet with a 169.254/16 destination, if it got something from a LL-aware node that it tried to answer. Arguably, altering the I-D to specify LL-aware nodes which have a routable address and want to talk to another LL-node MUST use their LL address would simplify things and probably eliminate a lot of confusion. The only case where an LL-aware node can successfully talk to another node on the local link such that the sender uses LL address and the destination address is routeable would be a case where the recipient node is also LL-aware. If they're both LL-aware, why not restrict them to using the LL addresses on both sides? I suspect the reason to allow this at all would have something to do with results from name resolution, but would like to hear if that is correct, or if there is some other reason. >So in the end I think we are left with: > - compatibilty of existing implementations >versus > - being able to reject ingres LL traffic. > >You made the point recently that most windows implementations disable >LL whenever DHCP is around. This would tend to limit the potential >interoperability problems quite nicely.. ;-) However, the two >implementations will fail for the "two strangers on a train" case >today. Do we care? I suggested we put a grace period into the document (based on publication date of the document) to resolve this. It's something Microsoft could adjust in a service pack without serious interoperability problems with their existing nodes. First service pack would be to set TTL=255, but not do the receive check, some time later, a service pack would add the TTL=255 check. >Personally, I can't see much chance of ingress LL traffic arriving on >a link (ie traffic coming in destined to 169.254/16). So the TTL=255 >check seems a bit like a solution in search of a problem. I guess I'm most concerned at this point with the placement of a router within a LL network and having that router answer ARPs for a subset of the addresses. Or a router configured for Proxy-arp. Either way, the TTL=255 check seems a prudent measure to ensure such configurations will NOT function, thereby avoiding unfortunate circumstances. >I could live with either. At this point I'd really like to see the TTL=255 language remain, though as I said adding an implementation timeline to ensure transition would seem a good idea as well. The "strangers meet on a train" issue already exists between Mac OS X 10.2 (current release) and Windows machines, if I understand what the folks from Apple have said. If the resultant RFC says what the draft presently says, it would be in Microsoft's interest to at least add the TTL=255 on transmit as soon as practical. From owner-zeroconf@merit.edu Wed Dec 4 00:12:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03803 for ; Wed, 4 Dec 2002 00:12:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9B33B912B5; Wed, 4 Dec 2002 00:14:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 68B12912B7; Wed, 4 Dec 2002 00:14: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 6D0FE912B5 for ; Wed, 4 Dec 2002 00:14:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 553C15E0C0; Wed, 4 Dec 2002 00:14:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by segue.merit.edu (Postfix) with ESMTP id 0D0D55E0A4 for ; Wed, 4 Dec 2002 00:14:50 -0500 (EST) Received: from delta.cs.mu.OZ.AU ([128.250.38.50]) by munnari.OZ.AU (8.11.6/8.11.6) with ESMTP id gB45EiL10522; Wed, 4 Dec 2002 16:14:44 +1100 (EST) 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 gB45Bf817737; Wed, 4 Dec 2002 16:11:41 +1100 (EST) From: Robert Elz To: Daniel Senie Cc: zeroconf Subject: Re: TTL=255 on xmit, no check on receipt please In-Reply-To: <5.2.0.9.2.20021203222554.02a2a958@mail.amaranth.net> References: <5.2.0.9.2.20021203222554.02a2a958@mail.amaranth.net> <5.2.0.9.2.20021202211449.029bf360@mail.amaranth.net> <5.2.0.9.2.20021202230120.00b7f618@mail.amaranth.net> <5.2.0.9.2.20021203085618.02ed4c60@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Dec 2002 16:11:41 +1100 Message-ID: <17735.1038978701@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 03 Dec 2002 22:40:43 -0500 From: Daniel Senie Message-ID: <5.2.0.9.2.20021203222554.02a2a958@mail.amaranth.net> | I guess I'm most concerned at this point with the placement of a router | within a LL network and having that router answer ARPs for a subset of the | addresses. Or a router configured for Proxy-arp. Forget the TTL issue - if a router is configured to proxy arp (and don't most come that way by default?) then it will answer all ARP requests for the LL addresses - which would mean that no LL addresses could ever get assigned, wouldn't it? That is, the router sees an ARP for an address that it doesn't believe is on the local interface, it has a route (default route almost certainly) to where the packet should go, so it answers the ARP - packets for that address come to me. If the ARP was from some node attempting to assign an address, it will just go on and try another - with the same result. Most low end routers in particular are likely to act like that, as it avoids (works around) all kinds of configuration problems on end hosts (who cares what the netmask gets set to, ...) If you can convince yourselves that this isn't going to be any kind of real problem, then I doubt that anything that is done with TTLs matters. Certainly using the IPv6 "TTL must be 255" (where that applies) as a justification for anything is meaningless here. The (as reported here anyway) mboned WG justification would still apply, if you wanted to go that way (that is, to try and "encourage" upgrades). But here I doubt that anything breaks which should work if no upgrade is done, and no real harm is done if there's no upgrade, so I doubt that it would work. TTL==1 achieves nothing. Just remove all text about TTL setting (and particularly checking), it achieves nothing, but creates lots of noise. kre From owner-zeroconf@merit.edu Wed Dec 4 05:53:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05774 for ; Wed, 4 Dec 2002 05:53:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E0E4E9122A; Wed, 4 Dec 2002 05:56:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ACC239123A; Wed, 4 Dec 2002 05:56:24 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A69229122A for ; Wed, 4 Dec 2002 05:56:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F37F5E0C7; Wed, 4 Dec 2002 05:56:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id 2BFBA5E0C5 for ; Wed, 4 Dec 2002 05:56: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 DAA14306; Wed, 4 Dec 2002 03:56:20 -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 gB4AuIl11660; Wed, 4 Dec 2002 11:56:18 +0100 (MET) Date: Wed, 4 Dec 2002 11:56:16 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Daniel Senie Cc: zeroconf Subject: Re: TTL=255 on xmit, no check on receipt please In-Reply-To: <5.2.0.9.2.20021203222554.02a2a958@mail.amaranth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Dan, On Tue, 3 Dec 2002, Daniel Senie wrote: > Arguably, altering the I-D to specify LL-aware nodes which > have a routable address and want to talk to another LL-node MUST use their > LL address would simplify things and probably eliminate a lot of confusion. Its not simplicity and confusion we want to address, but the failure mode in which a v4LL-unaware host forwards a datagram with a v4LL destination to a router. > The only case where an LL-aware node can successfully talk to another node > on the local link such that the sender uses LL address and the destination > address is routeable would be a case where the recipient node is also > LL-aware. I think this is right, but please see below for an analysis. > If they're both LL-aware, why not restrict them to using the LL > addresses on both sides? I suspect the reason to allow this at all would > have something to do with results from name resolution, but would like to > hear if that is correct, or if there is some other reason. I do not follow this last sentence. --- If a host which is not v4LL-aware receives a datagram from a LL address, it will respond by forwarding to a router, right? I am not aware of any host implementations which will use ARP to attempt to forward a packet which is not in the same subnet as the host. Are there any which do this by default? (Is it even a good idea?) If I'm right, v4LL to v4LL-unaware also fails the strangers on a train test for this reason. There are additional problems if non-v4LL aware hosts do ARP for v4LL addresses: - For a multi-homed host, which interface should they perform ARP on to resolve a v4LL address? - Application protocols will fail when (if) addresses change, which will be unexpected. In short, much of the complexity of v4LL would be exposed to a v4LL unaware host if they attempted to communicate from a source global to a destination v4LL address. I think there is great merit in your suggestion that v4LL configured hosts should only communicate with v4LL destinations. In this case, no host would forward a datagram with a v4LL destination to a router. This change does not limit interoperability with existing implementations, either. Erik From owner-zeroconf@merit.edu Wed Dec 4 12:43:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24627 for ; Wed, 4 Dec 2002 12:43:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C826191234; Wed, 4 Dec 2002 12:46:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BDA2912BC; Wed, 4 Dec 2002 12:46: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 B7F9D91234 for ; Wed, 4 Dec 2002 12:46:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 92CBB5E0D3; Wed, 4 Dec 2002 12:46:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from staff2.cso.uiuc.edu (staff2.cso.uiuc.edu [128.174.5.53]) by segue.merit.edu (Postfix) with ESMTP id 4040A5DDF7 for ; Wed, 4 Dec 2002 12:46:04 -0500 (EST) Received: from arrakis.cso.uiuc.edu (arrakis.cso.uiuc.edu [130.126.113.7]) by staff2.cso.uiuc.edu (8.11.0/8.11.0) with ESMTP id gB4Hk3U00623; Wed, 4 Dec 2002 11:46:03 -0600 (CST) Received: (from jak@localhost) by arrakis.cso.uiuc.edu (8.11.2/8.10.2) id gB4Hk2k28580; Wed, 4 Dec 2002 11:46:02 -0600 (CST) Date: Wed, 4 Dec 2002 11:46:02 -0600 From: "Jay A. Kreibich" To: Robert Elz Cc: Daniel Senie , zeroconf Subject: Re: TTL=255 on xmit, no check on receipt please Message-ID: <20021204174602.GA27932@uiuc.edu> Reply-To: jak@uiuc.edu References: <5.2.0.9.2.20021203222554.02a2a958@mail.amaranth.net> <5.2.0.9.2.20021202211449.029bf360@mail.amaranth.net> <5.2.0.9.2.20021202230120.00b7f618@mail.amaranth.net> <5.2.0.9.2.20021203085618.02ed4c60@mail.amaranth.net> <17735.1038978701@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17735.1038978701@munnari.OZ.AU> User-Agent: Mutt/1.4i X-Editor: vi, and proud of it X-URL: http://www.uiuc.edu/~jak (includes PGP key) Sender: owner-zeroconf@merit.edu Precedence: bulk On Wed, Dec 04, 2002 at 04:11:41PM +1100, Robert Elz scratched on the wall: > Certainly using the IPv6 "TTL must be 255" (where that applies) as a > justification for anything is meaningless here. Using it for *justification* (as in "they are doing it so we should too") is somewhat meaningless. That isn't good design or good engineering. BUT, the fact that IPv6 uses this TTL check to solve what is more or less an identical problem** provides very strong precedence for the validity of the check. The IPv6 working group felt that it was the correct solution to the problem. While IPv6 networks aren't exactly common, there are numerous implementations and many many research networks in both education and industry that have put the protocol under a microscope from top to bottom. What does that mean to Zeroconf? Not a lot. I think it means that the TTL=255 check is just one possible solution to one particular type of problem. It is one more tool in our bag of tricks, design principals, and basic constructs used in protocol design. The fact that IPv6 Neighbor Discovery uses this same solution doesn't really change any of this, except in how much one might trust or respect the idea. The only reason I originally posted to this list the fact that IPv6 also uses the TTL=255 check currently in the Zeroconf draft standard is to point out that this is *not* a "new and radical" idea. that just came out of thin air. It is not some never-before-seen gimmick dreamed up just for this working group. It is an established and accepted design component in the networking protocol design field. Does that mean Zeroconf should use it? Not necessarily-- a strong history by itself is, as you have pointed out, not justification in and of itself. So while doing something just to do it isn't good design, using "off the shelf" systems and components (perhaps with minor modifications) to solve extremely similar problems *is* good design. I think there is a problem in this component of the Zeroconf standard that needs to be solved, and I happen to think the TTL=255 check is the correct solution. Others may disagree, but I haven't seen any better solutions proposed. **-- The problem I see in IPv4 LL addresses and the problem that is being solved with IPv6 Neighbor Discovery is the question of protocol robustness in the face of a non-compliant node (e.g. one that is broken or hostile). IPv6 ND absolutely depends on the idea that packets are from/to local link neighbors-- you don't have to trust your neighbors, but you have to be sure the nodes you are talking to really are your neighbors. IPv4 LL addressing also makes the assertion that this is true (link-local really is link-local), although the actual dependence on this is up to the higher layer protocols. That said, I think the IPv4 LL spec should make every effort to insure that any packet delivered up the stack to higher-level protocols is really from a link-local neighbor. We, as the lower-layer protocol, cannot make any assumptions about how this data is used or how the conditions of the protocol are being used (wise or not). We have stated the this protocol is used to deliver to link-local traffic and ONLY link-local traffic, so we should design a protocol that does exactly that, even in the face of nodes and routers that are attempting to use LL addresses outside the LL spec (which we can assume to be common, given the retro-fit nature of this spec). I feel setting the TTL to 1 is of very limited value. The spec says hosts should not send LL traffic to a router for forwarding. Any host sending a packet to a router for forwarding is already in violation of the standard, so having the standard require a specific TTL seems redundant. I admit that "don't send to routers" isn't always the easiest thing to get right, and we should assume that hosts (even those trying to follow the standard) will sometimes get it wrong. But, as others have pointed out, where exactly this packet will be routed is very questionable. It isn't likely to be accepted by any ISP, so the only network you are likely to effect is the local site network. Even this can be prevented with proper ACLs or other filters. Setting the TTL to any value other then one is pointless (in solving the problem at hand) unless the value is checked when the packet is received, before it is handed up the stack. Checking for any value other then 255 is pointless because it can be faked fairly trivially by just sending all possible values. So the question is, should we have a TTL=255 check at all, or should we just ignore the TTL issue all together. I would be happy to ignore the TTL issue all together if someone was able to come up with a system that would enforce the "link-local is link-local" condition put forth by the protocol and higher-layer protocols/applications can assume to always be true (for whatever reason or wisdom). I haven't seen any other way to make sure this condition stays true, so I'm strongly in favor of the TTL=255 check. -j -- Jay A. Kreibich | Integration & Software Eng. jak@uiuc.edu | Campus IT & Edu. Svcs. | University of Illinois at U/C From owner-zeroconf@merit.edu Wed Dec 4 14:10:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28869 for ; Wed, 4 Dec 2002 14:10:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 223C6912BE; Wed, 4 Dec 2002 14:13:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3A45912BF; Wed, 4 Dec 2002 14:13: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 CD972912BE for ; Wed, 4 Dec 2002 14:13:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id B4CAA5DE20; Wed, 4 Dec 2002 14:13:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 5712C5DE1F for ; Wed, 4 Dec 2002 14:13:14 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB4J9Hj05955; Wed, 4 Dec 2002 14:09:17 -0500 (EST) Message-Id: <200212041909.gB4J9Hj05955@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: jak@uiuc.edu Cc: Robert Elz , Daniel Senie , zeroconf Subject: Re: TTL=255 on xmit, no check on receipt please In-reply-to: (Your message of "Wed, 04 Dec 2002 11:46:02 CST.") <20021204174602.GA27932@uiuc.edu> Date: Wed, 04 Dec 2002 14:09:17 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > IPv4 LL addressing also makes the assertion that this is true > (link-local really is link-local), although the actual dependence > on this is up to the higher layer protocols. Nowhere in the charter of this WG is any approval to develop a service that is defined to only work on the local link. regardless of whether a TTL check is imposed, I strongly object to : - the idea that LL guarantees that the packet came from the local link (since tunneling is always a potential threat), and - the idea that a higher layer protocol can reasonably treat a packet that comes from a local link differently than a packet that comes from elsewhere. Keith From owner-zeroconf@merit.edu Wed Dec 4 16:20:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04374 for ; Wed, 4 Dec 2002 16:20:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 07DE491233; Wed, 4 Dec 2002 16:23:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CBE069123B; Wed, 4 Dec 2002 16:23: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 C3B8991233 for ; Wed, 4 Dec 2002 16:23:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id A9A3A5E0D7; Wed, 4 Dec 2002 16:23:21 -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 60D675DE3F for ; Wed, 4 Dec 2002 16:23:21 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 12C57598DE for ; Wed, 4 Dec 2002 21:23:25 +0000 (GMT) Message-ID: <002001c29bdb$5e4a83c0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <5.2.0.9.2.20021202211449.029bf360@mail.amaranth.net> <5.2.0.9.2.20021202230120.00b7f618@mail.amaranth.net> <5.2.0.9.2.20021203085618.02ed4c60@mail.amaranth.net> <5.2.0.9.2.20021203222554.02a2a958@mail.amaranth.net> Subject: Re: TTL=255 on xmit, no check on receipt please Date: Wed, 4 Dec 2002 21:23:19 -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: "Daniel Senie" > ... > Arguably, altering the I-D to specify LL-aware nodes which > have a routable address and want to talk to another LL-node MUST use their > LL address would simplify things and probably eliminate a lot of confusion. > The only case where an LL-aware node can successfully talk to another node > on the local link such that the sender uses LL address and the destination > address is routeable would be a case where the recipient node is also > LL-aware. If they're both LL-aware, why not restrict them to using the LL > addresses on both sides? I suspect the reason to allow this at all would > have something to do with results from name resolution, but would like to > hear if that is correct, or if there is some other reason. The justification given in the I-D is that there are hosts around which have great difficulty supporting two concurrent addresses on the same interface - some stacks would need major revision. I think this is valid and I don't think it hurts so long as hosts with routable addresses don't turn off their LL logic. There has been quite a bit of confusion in this discussion between hosts which have a routable address but are nevertheless LL aware, and those which are simply not LL aware. The latter just can't communicate with LL devices. There is a grey area in between occupied by hosts which have some manual configuration or earlier LL implementation (mainly Windows and Mac), which might or might not interoperate depending on TTL values. For example, when Windows finds a DHCP server and switches off it's LL address, does it also turn off all LL aware processing? The issue of whether to set and or check TTL=255 or not comes down to issues of partial interoperability in this greay area. Personally, I am in favour of setting and checking as I think this will be more robust and cause rejection of dodgy traffic at an earlier point. > The "strangers meet on a train" issue already exists > between Mac OS X 10.2 (current release) and Windows machines, if I > understand what the folks from Apple have said. If the resultant RFC says > what the draft presently says, it would be in Microsoft's interest to at > least add the TTL=255 on transmit as soon as practical. Agreed. Philip nye From owner-zeroconf@merit.edu Wed Dec 4 23:06:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18860 for ; Wed, 4 Dec 2002 23:06:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 75B52912C4; Wed, 4 Dec 2002 23:08:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 450FE912C6; Wed, 4 Dec 2002 23:08: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 3755D912C4 for ; Wed, 4 Dec 2002 23:08:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 12A5E5E102; Wed, 4 Dec 2002 23:08:53 -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 89DB45E0ED for ; Wed, 4 Dec 2002 23:08:52 -0500 (EST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id gB548pfw007777 for ; Wed, 4 Dec 2002 21:08:51 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id VAA18004 for ; Wed, 4 Dec 2002 21:08:49 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gB541F7C010738; Thu, 5 Dec 2002 15:01:16 +1100 (EST) Message-ID: <3DEECF8C.7000101@motorola.com> Date: Thu, 05 Dec 2002 15:01:16 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Guttman Cc: Daniel Senie , zeroconf Subject: Re: TTL=255 on xmit, no check on receipt please 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 Erik Guttman wrote: > I think there is great merit in your suggestion that v4LL configured > hosts should only communicate with v4LL destinations. In this case, > no host would forward a datagram with a v4LL destination to a router. > This is probably prudent. Now that we allow hosts to run zeroconf protocols at the same time as non-zeroconf protocols (ie we dropped the "transition" idea) I think it is reasonable to insist that hosts wanting to speak to an IPv4-LL address have one themselves. Re "no host would forward": Never say never? I think there is still the possibility that LL broadcast or multicast packets with IPv4LL unicast source addresses could get picked up by non-ll-aware hosts which then respond with a packet along a default route.. - aidan From owner-zeroconf@merit.edu Thu Dec 5 12:38:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21003 for ; Thu, 5 Dec 2002 12:38:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 55CBB9120E; Thu, 5 Dec 2002 12:41:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BC0391212; Thu, 5 Dec 2002 12:41: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 015939120E for ; Thu, 5 Dec 2002 12:41:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id DCC645E136; Thu, 5 Dec 2002 12:41:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ux10.cso.uiuc.edu (ux10.cso.uiuc.edu [128.174.5.79]) by segue.merit.edu (Postfix) with ESMTP id 8B5A45DE94 for ; Thu, 5 Dec 2002 12:41:14 -0500 (EST) Received: from arrakis.cso.uiuc.edu (arrakis.cso.uiuc.edu [130.126.113.7]) by ux10.cso.uiuc.edu (8.11.0/8.11.0) with ESMTP id gB5HfD301399; Thu, 5 Dec 2002 11:41:13 -0600 (CST) Received: (from jak@localhost) by arrakis.cso.uiuc.edu (8.11.2/8.10.2) id gB5HfDt01353; Thu, 5 Dec 2002 11:41:13 -0600 (CST) Date: Thu, 5 Dec 2002 11:41:13 -0600 From: "Jay A. Kreibich" To: Aidan Williams Cc: Erik Guttman , Daniel Senie , zeroconf Subject: Re: TTL=255 on xmit, no check on receipt please Message-ID: <20021205174112.GA1203@uiuc.edu> Reply-To: jak@uiuc.edu References: <3DEECF8C.7000101@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DEECF8C.7000101@motorola.com> User-Agent: Mutt/1.4i X-Editor: vi, and proud of it X-URL: http://www.uiuc.edu/~jak (includes PGP key) Sender: owner-zeroconf@merit.edu Precedence: bulk On Thu, Dec 05, 2002 at 03:01:16PM +1100, Aidan Williams scratched on the wall: > Erik Guttman wrote: > > I think there is great merit in your suggestion that v4LL configured > > hosts should only communicate with v4LL destinations. In this case, > > no host would forward a datagram with a v4LL destination to a router. > > > > This is probably prudent. Now that we allow hosts to run zeroconf > protocols at the same time as non-zeroconf protocols (ie we dropped > the "transition" idea) I think it is reasonable to insist that hosts > wanting to speak to an IPv4-LL address have one themselves. Of course this just means that many routers will now have LL addresses on one or more interfaces since one of the key markets for Zeroconf (besides printers) is web config tools for lower-end routers (such as DSL gateways and cable "modems"). This is part of the reason I keep saying "a LL host should not send packets to a router *for forwarding*", since clearly a host should be able to send packets to a router using LL addressing (one one side or the other) if it is sending them to the address assigned to the router's interface on the local link (e.g. talking *to* the router, not *thru* the router). You also have the problem that devices with embedded network stacks, like printers, now need two addresses (one to service GR addressed hosts and one to service LL addressed hosts). While more then one IP per interface is available in many (but far from all) host IP stacks, this is much *much* less true of embedded devices and their less robust stacks. Allowing multiple addresses per interface, and the internal routing logic for them, isn't exactly a trivial change. > Never say never? I think there is still the possibility that LL > broadcast or multicast packets with IPv4LL unicast source addresses > could get picked up by non-ll-aware hosts which then respond > with a packet along a default route.. That's a good point, and for multicast would even take that further to wonder if the packet would be forwarded into the global multicast space by a router that does not understand LL addresses. Requiring that all LL multicast use link-local addresses only, but that could still cause a great deal of traffic to "leak". Something like the TTL check would prevent it from being acted upon, but unlike packets addressed to the LL address space which is likely to hit a "default free zone" router soon enough and get dropped, the limiting bad multicast traffic would require very aware routers. Of course, the same could be said of 10.x.x.x source addresses, or any other private space. The problem is not unique to the LL address pool. I think limiting LL communications to LL addresses on both sides does solve many tricky problems, such as the ones you point out. It comes at a much higher cost to the device developer, however, and I'm not sure the price is worth it. -j -- Jay A. Kreibich | Integration & Software Eng. jak@uiuc.edu | Campus IT & Edu. Svcs. | University of Illinois at U/C From owner-zeroconf@merit.edu Thu Dec 5 13:17:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22111 for ; Thu, 5 Dec 2002 13:17:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7496191212; Thu, 5 Dec 2002 13:20:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E170912CE; Thu, 5 Dec 2002 13:20: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 0374791212 for ; Thu, 5 Dec 2002 13:20:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id E036E5DE5F; Thu, 5 Dec 2002 13:20:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from staff3.cso.uiuc.edu (staff3.cso.uiuc.edu [128.174.5.54]) by segue.merit.edu (Postfix) with ESMTP id 88F475DE5E for ; Thu, 5 Dec 2002 13:20:10 -0500 (EST) Received: from arrakis.cso.uiuc.edu (arrakis.cso.uiuc.edu [130.126.113.7]) by staff3.cso.uiuc.edu (8.11.0/8.11.0) with ESMTP id gB5IK9019932; Thu, 5 Dec 2002 12:20:09 -0600 (CST) Received: (from jak@localhost) by arrakis.cso.uiuc.edu (8.11.2/8.10.2) id gB5IK9P01518; Thu, 5 Dec 2002 12:20:09 -0600 (CST) Date: Thu, 5 Dec 2002 12:20:09 -0600 From: "Jay A. Kreibich" To: Keith Moore Cc: Robert Elz , Daniel Senie , zeroconf Subject: Re: TTL=255 on xmit, no check on receipt please Message-ID: <20021205182009.GB1203@uiuc.edu> Reply-To: jak@uiuc.edu References: <20021204174602.GA27932@uiuc.edu> <200212041909.gB4J9Hj05955@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200212041909.gB4J9Hj05955@astro.cs.utk.edu> User-Agent: Mutt/1.4i X-Editor: vi, and proud of it X-URL: http://www.uiuc.edu/~jak (includes PGP key) Sender: owner-zeroconf@merit.edu Precedence: bulk On Wed, Dec 04, 2002 at 02:09:17PM -0500, Keith Moore scratched on the wall: > > IPv4 LL addressing also makes the assertion that this is true > > (link-local really is link-local), although the actual dependence > > on this is up to the higher layer protocols. > > Nowhere in the charter of this WG is any approval to develop a service > that is defined to only work on the local link. True. However, the path Zeroconf WG has chosen to go down under that charter has brought us to using link-local addresses, and *that* does define the constraint of link local addresses only working on the local-link. If they didn't, they wouldn't be called "link-local addresses." Other schemes exist to solve the "zero configuration problem" (such as a model similar in concept to IPv6 "site-local" addresses), but that's not the path we've chosen to go down (personally, I think this is a good thing, as such systems are usually orders of magnitude more complex). > regardless of whether a TTL check is imposed, I strongly object to : > > - the idea that LL guarantees that the packet came from the local link > (since tunneling is always a potential threat), and If the tunneling was done at layer-3, the tunnel end-point would be acting as a gateway, and the tunnel wouldn't be effected by link-local addresses (at least, not any differently then any other gateway). If the tunneling was done at layer-2, any devices "thru" the tunnel would still be "link-local" and using LL addresses would not be outside the protocol. This "threat" is no different then someone running at cat5 cable down the hall, putting an live jack in your lobby, or a wireless AP next to the parking lot. You're mixing the idea of physical security and control with the layered networking model. The "link-local" is only defined by "no layer 3 transport devices", not any kind of physical topology. If someone puts in a layer-2 tunnel on a network, that is no different then a switch, repeater, "hub", bridge, or multi-port transceiver passing traffic over Ethernet, FDDI, wireless, lasers, or tin-cans-and-string-- or a tunnel. Just as ARP has a "local link scope", if you setup a layer-2 tunnel you would expect (and actually require) ARP to work correctly across it, or the tunnel would be worthless. This is not any kind of suprise-- this is the protocol working exactly as advertised. The only time the concept of "threat" enters into this is if you are making higher layer data-security or connectivity-security related decisions based off required physical constraints perceived from the lower networking layers. In the general case, this is a really Bad Idea. Anyone that assumes link-local provides local control when they don't have control over *all* of the machines on that link doesn't understand how networking works. That's almost as bad as thinking a switched network gives you better local-link sniffing "security." But none of these issues are new. It is just as true for existing network designs-- we find dorm kids running layer-3 tunnels over HTTP through our firewalls all the time as we control the network, but not the hosts. It pays to know exactly what that gives (or does not give) you. > - the idea that a higher layer protocol can reasonably treat a packet that > comes from a local link differently than a packet that comes from elsewhere. This is not for us to decide and is totally outside of the scope of this working group. I happen to agree that this would be *highly* questionable for most application security models when dealing with connection ACLs or authentication systems, but that isn't for us to decide-- it is up to those designing the higher layer protocols or application level security model. We might offer suggestions as a lower-layer protocol (although I question even this in the actual standards document), but we are in no position to dictate how the protocol is layered, except in the conditions and assumptions of our own protocol-- and one of those conditions that the protocol makes and should do its best to enforce is "link-local is really link-local." If you change the question from "treating a link local packet differently" to "treating a layer-2 only delivered packet differently", I think we get closer to the idea at hand. There are a handful of protocols that, in order to function correctly, are required to make the assumption that traffic is link-local (or to be more specific, the protocol logic could be totally screwed up by a node outside of the domain of the protocol if non-link-local traffic was accepted), yet do not put inherent "trust" in link-local nodes. Admittedly, all of the protocols that are coming to mind have to deal with routing and figuring out the difference between paths that will cross layer-2 only or layer-2 and layer-3 devices, but such examples do exist. Regardless, I think we would be presuming too much to think we, as a working group, can think of every possible future use for a well integrated Zeroconf and/or LL network, and that we can see the future well enough to say there will *never* be an appropriate (according to best practices) use for link-local "only" communications. But I still agree with you that the net-admin that thinks they don't need to wrapper LL addresses just as tightly (if not more so!) as any other address needs to have a little talking to. This is the same kind of netadmin that has an open wireless AP in their office next to the parking lot. -j -- Jay A. Kreibich | Integration & Software Eng. jak@uiuc.edu | Campus IT & Edu. Svcs. | University of Illinois at U/C From owner-zeroconf@merit.edu Thu Dec 5 13:35:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22817 for ; Thu, 5 Dec 2002 13:35:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7E07F912CF; Thu, 5 Dec 2002 13:37:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 494C8912D0; Thu, 5 Dec 2002 13:37: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 3B970912CF for ; Thu, 5 Dec 2002 13:37:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 22B895DEEA; Thu, 5 Dec 2002 13:37:44 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id B78625DEC7 for ; Thu, 5 Dec 2002 13:37:43 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB5IWpj16686; Thu, 5 Dec 2002 13:32:51 -0500 (EST) Message-Id: <200212051832.gB5IWpj16686@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: jak@uiuc.edu Cc: Keith Moore , Robert Elz , Daniel Senie , zeroconf Subject: Re: TTL=255 on xmit, no check on receipt please In-reply-to: (Your message of "Thu, 05 Dec 2002 12:20:09 CST.") <20021205182009.GB1203@uiuc.edu> Date: Thu, 05 Dec 2002 13:32:51 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > - the idea that a higher layer protocol can reasonably treat a packet that > > comes from a local link differently than a packet that comes from > > elsewhere. > > This is not for us to decide and is totally outside of the scope of > this working group. wow...this working group has done many things that are *way* outside its charter, and yet you are claiming that debunking a common false assumption about LL that has been explicitly stated by many participants of this WG (so we can't pretend that the meme isn't out there) is out of scope. the mind boggles. Keith From owner-zeroconf@merit.edu Thu Dec 5 13:41:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23021 for ; Thu, 5 Dec 2002 13:41:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9D733912D1; Thu, 5 Dec 2002 13:43:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64B05912D2; Thu, 5 Dec 2002 13:43:54 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 53295912D1 for ; Thu, 5 Dec 2002 13:43:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 318605DEC7; Thu, 5 Dec 2002 13:43:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from staff1.cso.uiuc.edu (staff1.cso.uiuc.edu [128.174.5.59]) by segue.merit.edu (Postfix) with ESMTP id D2B285DE5E for ; Thu, 5 Dec 2002 13:43:52 -0500 (EST) Received: from arrakis.cso.uiuc.edu (arrakis.cso.uiuc.edu [130.126.113.7]) by staff1.cso.uiuc.edu (8.11.0/8.11.0) with ESMTP id gB5Ihlb14310; Thu, 5 Dec 2002 12:43:47 -0600 (CST) Received: (from jak@localhost) by arrakis.cso.uiuc.edu (8.11.2/8.10.2) id gB5Ihln01645; Thu, 5 Dec 2002 12:43:47 -0600 (CST) Date: Thu, 5 Dec 2002 12:43:47 -0600 From: "Jay A. Kreibich" To: Keith Moore Cc: Robert Elz , Daniel Senie , zeroconf Subject: Re: TTL=255 on xmit, no check on receipt please Message-ID: <20021205184347.GA1590@uiuc.edu> Reply-To: jak@uiuc.edu References: <20021205182009.GB1203@uiuc.edu> <200212051832.gB5IWpj16686@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200212051832.gB5IWpj16686@astro.cs.utk.edu> User-Agent: Mutt/1.4i X-Editor: vi, and proud of it X-URL: http://www.uiuc.edu/~jak (includes PGP key) Sender: owner-zeroconf@merit.edu Precedence: bulk On Thu, Dec 05, 2002 at 01:32:51PM -0500, Keith Moore scratched on the wall: > > > - the idea that a higher layer protocol can reasonably treat a packet that > > > comes from a local link differently than a packet that comes from > > > elsewhere. > > > > This is not for us to decide and is totally outside of the scope of > > this working group. > > wow...this working group has done many things that are *way* outside > its charter, And you seem to be one of the first people to point out relations to the charter and IETF policies and procedures. What's your point? > and yet you are claiming that debunking a common false > assumption about LL that has been explicitly stated by many participants > of this WG (so we can't pretend that the meme isn't out there) is out > of scope. No, I tried to say that changing the standard to match common misconceptions is not the correct solution. Elsewhere in this preivious message (in parts that you trimmed) I did say that we might want to include clarifiaction of this point since it *is* a common misconception, but that I wasn't sure such text or clarification actually belonged in the standards document itself. An appendix or a totally different "best pratices" document makes more sense to me, as this is not, in the purest sense, a technical issue. -j -- Jay A. Kreibich | Integration & Software Eng. jak@uiuc.edu | Campus IT & Edu. Svcs. | University of Illinois at U/C From owner-zeroconf@merit.edu Thu Dec 5 13:55:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23627 for ; Thu, 5 Dec 2002 13:55:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 69938912D2; Thu, 5 Dec 2002 13:58:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36EF7912D3; Thu, 5 Dec 2002 13:58:28 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1CFC3912D2 for ; Thu, 5 Dec 2002 13:58:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE8075E129; Thu, 5 Dec 2002 13:58:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 902F55E127 for ; Thu, 5 Dec 2002 13:58:26 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB5IsZj16843; Thu, 5 Dec 2002 13:54:35 -0500 (EST) Message-Id: <200212051854.gB5IsZj16843@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: jak@uiuc.edu Cc: Keith Moore , Robert Elz , Daniel Senie , zeroconf Subject: Re: TTL=255 on xmit, no check on receipt please In-reply-to: (Your message of "Thu, 05 Dec 2002 12:43:47 CST.") <20021205184347.GA1590@uiuc.edu> Date: Thu, 05 Dec 2002 13:54:35 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > wow...this working group has done many things that are *way* outside > its charter, And you seem to be one of the first people to point out relations to the charter and IETF policies and procedures. What's your point? there are a number of features in the current specification that are problematic and cannot be justified by the group's charter. I am hoping that they will get fixed. Keith From owner-zeroconf@merit.edu Fri Dec 6 02:49:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27927 for ; Fri, 6 Dec 2002 02:49:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA75491216; Fri, 6 Dec 2002 02:52:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A84339123D; Fri, 6 Dec 2002 02:52: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 A431D91216 for ; Fri, 6 Dec 2002 02:52:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8C5485DF8A; Fri, 6 Dec 2002 02:52:05 -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 13E2A5DD92 for ; Fri, 6 Dec 2002 02:52:05 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA21005; Thu, 5 Dec 2002 23:52:02 -0800 (PST) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gB67pwH24018; Fri, 6 Dec 2002 08:51:58 +0100 (MET) Date: Fri, 6 Dec 2002 08:48:38 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: TTL=255 on xmit, no check on receipt please To: jak@uiuc.edu Cc: Robert Elz , Daniel Senie , zeroconf Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > BUT, the fact that IPv6 uses this TTL check to solve what is more or > less an identical problem** provides very strong precedence for the > validity of the check. The IPv6 working group felt that it was the > correct solution to the problem. While IPv6 networks aren't exactly > common, there are numerous implementations and many many research > networks in both education and industry that have put the protocol > under a microscope from top to bottom. > **-- The problem I see in IPv4 LL addresses and the problem that > is being solved with IPv6 Neighbor Discovery is the question of > protocol robustness in the face of a non-compliant node (e.g. one > that is broken or hostile). IPv6 ND absolutely depends on the idea > that packets are from/to local link neighbors-- you don't have to > trust your neighbors, but you have to be sure the nodes you are > talking to really are your neighbors. AFAIK the problem is far from identical. In v4LL the problem applies to packets which have at least one LL address (either the source, dest, or both are LL). In RFC 2461 the problem includes packets (such as Neighbor Solicitation and Neighbor Advertisement) where neither the source or the destination might be link-local. In fact, in common use the addresses are the (global) addresses that the upper layers use to communicate. When there is at least one LL address in the packets the routers can filter the packet. But in the RFC 2461 this is not the case (unless the routers take the performance hit of filtering on the ICMP type instead of just the addresses). Hence RFC 2461 uses ttl=255 for a different reason that v4LL. Erik From owner-zeroconf@merit.edu Fri Dec 6 07:15:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03128 for ; Fri, 6 Dec 2002 07:15:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2EFB79123F; Fri, 6 Dec 2002 07:18:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EEF3E91240; Fri, 6 Dec 2002 07:18: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 032269123F for ; Fri, 6 Dec 2002 07:17:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id D594E5DF8D; Fri, 6 Dec 2002 07:17:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mailman.cisco.com (halt-in.cisco.com [171.70.144.185]) by segue.merit.edu (Postfix) with ESMTP id 99DBA5DD90 for ; Fri, 6 Dec 2002 07:17:59 -0500 (EST) Received: from [10.82.241.43] by mailman.cisco.com (171.70.144.185) with ESMTP; 05 Dec 2002 21:38:04 +0000 Message-Id: <4.3.2.7.2.20021206065421.01ed32c8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Dec 2002 07:17:57 -0500 To: "Zero Configuration WG" From: John Schnizlein Subject: Re: TTL=255 on xmit, no check on receipt please In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk Could we have a simple summary of the reasons that the intuitive solution of TTL=1 to keep link-local (LL) traffic from being forwarded off the link is bad, please? One of the persuasive arguments on this thread is to maintain as much compatibility with existing deployments as possible during the deployment of LL addressing. Another is keeping LL traffic local. The analysis should consider the common (but not pretty) configuration of a router's local interface for proxy-ARP, in which it responds to ARP requests for any IP address with its own MAC address. How does the LL-only host guarantee that it does not send LL traffic to the proxy-ARP router? John From owner-zeroconf@merit.edu Fri Dec 6 08:22:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05084 for ; Fri, 6 Dec 2002 08:22:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC12E91241; Fri, 6 Dec 2002 08:24:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6375A91242; Fri, 6 Dec 2002 08:24:43 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0015891241 for ; Fri, 6 Dec 2002 08:24:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA7EA5DF9F; Fri, 6 Dec 2002 08:24:41 -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 6E1025DF8E for ; Fri, 6 Dec 2002 08:24:41 -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 GAA28893; Fri, 6 Dec 2002 06:24:39 -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 gB6DOYl12321; Fri, 6 Dec 2002 14:24:35 +0100 (MET) Date: Fri, 6 Dec 2002 14:24:32 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Erik Nordmark Cc: Erik Guttman , Thomas Narten , zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Erik, While the debate continues on the TTL setting on send and handling on receive, I will try to make progress on your other issues. For each of the suggested changes, I mark off a section with '-' bars and show the original and modified text, with change bars in the left column to aid in comparision. I hope that I have also addressed some of Keith's concerns (in the applicability statement and section 7). ----------------------------------------------------------------------- On Fri, 29 Nov 2002, Erik Nordmark wrote: > > > In the applicability section it would make sense to add explicit > > > warnings about issues for applications. One issue is the addresses > > > are of limited scope which might cause problems for multi-party > > > applications that pass IP addresses between parties. > > > The other issue is that these addresses might have much shorter and > > > unpredictable lifetime, which would have an impact on applications > > > using them on the link. (This is true especially given the > > > suggestions in section 2.5 to pick a new address when a conflict is > > > detected after the address has been used for a while.) > > > > Are Sections 7. 1 and 7.2 insufficient? > > Three issues with those: > - They don't explicitly mention that the stability of the addresses is > affected by late collisions i.e. when the address has been in use for > a while OK. I clarify section 7.1 with this point. From draft-ietf-zeroconf-ipv4-linklocal-07.txt: 7.1 Address Changes, Failure and Recovery IPv4 link-local addresses used by an application may change over time. Some application software encountering an address change will completely fail. For example, client TCP connections will fail, servers whose addresses change will have to be rediscovered, blocked reads and writes will exit with an error condition, and so on. To: 7.1 Address Changes, Failure and Recovery IPv4 link-local addresses used by an application may change over time. Some application software encountering an address change will completely fail. For example, client TCP connections will fail, servers whose addresses change will have to be rediscovered, blocked reads and writes will exit with an error condition, and so on. | Note well that address changes may occur at any time. A host | attempting to establish a TCP connection with a peer using an | address which worked previously may not work subsequently, as | the peer's address may have changed. An existing TCP connection | which has been in use for some time may fail, as one or both of | the communicating peers has been forced to change its address. ------------------------------------------------------------------------ > - They are written as "all applications SHOULD be fixed to be usable in > this environment" - it is more realistic for people deploying this > technology to turn this around and instead issue a warning that > link-locals should not be used unless all applications used in the > network are known to not depend on X, Y, Z. Revise Section 7. From draft-ietf-zeroconf-ipv4-linklocal-07.txt: 7. Application Programming Considerations Use of IPv4 link-local autoconfigured addresses presents additional challenges to writers of applications and may result in existing application software failing. To: 7. Application Programming Considerations Use of IPv4 link-local autoconfigured addresses presents additional challenges to writers of applications and may result in existing | application software failing. Operational problems will arise if | the following considerations are not addressed by application | software. It is therefore RECOMMENDED that IPv4 link-local | autoconfiguration support be deployed only with application software | which is robust to address changes, does not forward IPv4 link-local | addresses and avoids address ambiguity problems, as described below. ------------------------------------------------------------------------ > - Warnings about limitations of the applicability makes sense up > front in the document - not towards the end. I agree. I add a forward reference and applicability warning to Section 1.2. From draft-ietf-zeroconf-ipv4-linklocal-07.txt: 1.2. Applicability The specifications in this document apply to any IEEE 802 media [802] including Ethernet [802.3], and other similar link-layer network technologies that operate at data rates of at least 1Mb/s, have a round-trip latency of at most one second, and support ARP [RFC 826]. Wherever this document uses the term "Ethernet", the text applies equally to any of these network technologies. To: 1.2. Applicability | IPv4 link-local addresses and their dynamic configuration have | profound implications upon applications which use them. This is | discussed in Section 7. Existing applications fundamentally | assume addresses of communicating peers are routable, relatively | unchanging and unique. These assumptions no longer hold with IPv4 | link-local addresses. IPv4 link-local addresses are therefore | applicable for those existing applications which can either | accomodate these differences or for those applications which are | modified to account for dynamic addresses, their limited scope and | their potential ambiguity. The specifications in this document apply to any IEEE 802 media [802] including Ethernet [802.3], and other similar link-layer network technologies that operate at data rates of at least 1Mb/s, have a round-trip latency of at most one second, and support ARP [RFC 826]. Wherever this document uses the term "Ethernet", the text applies equally to any of these network technologies. ---------------------------------------------------------------------- > > add -> > > > > It would also be possible for an on-link attacker to spoof ARP > > packets which would cause a host to break all its connections by > > switching to a new address. > > OK, but you need to point out that this is a new threat added > by link-local - and not just bundle if with the current "arp is insecure" > threats. > > > which use global addresses. An on-link attacker could spoof ARP > > packets which would cause a packets destined for a host to be > > redirected to the attacker, who could discard them, etc. > > That is a different threat - MiTM can be done with current ARP vs. the new > "IP address invalidation" attack with is possible with this draft. > RFC 826 isn't subject to a threat were an on-link attacker can get > a host to change its address thereby, as a result of receiving a single ARP > packet, will break all its existing communication. > This distinction should be made clear. A revised security considerations section follows: From draft-ietf-zeroconf-ipv4-linklocal-07.txt: 5. Security Considerations The use of IPv4 Link-Local Addresses may open a network host to new attacks. In particular, a host that previously did not have an IP address, and no IP stack running, was not susceptible to IP-based attacks. By configuring a working address, the host may now be vulnerable to IP-based attacks. The ARP protocol [RFC 826] is insecure. A malicious host may send fraudulent ARP packets on the network, interfering with the correct operation of other hosts. For example, it is easy for a host to answer all ARP requests with replies giving its own hardware address, thereby claiming ownership of every address on the network. Implementers are advised that the Internet Protocol architecture expects every networked device or host must implement security which is adequate to protect the resources to which the device or host has access, including the network itself, against known or credible threats. Even though use of link-local addresses may reduce the number of threats to which a device is exposed, implementers of devices supporting the Internet Protocol must not assume that a customer's local network is free from security risks. While there may be particular kinds of devices, or particular environments, for which the security provided by the network is adequate to protect the resources that are accessible by the device, it would be misleading to make a general statement to the effect that the requirement to provide security is reduced for devices using link-local addresses as a sole means of access. In all cases, whether or not link-local addresses are used, it is necessary for implementers of devices supporting the Internet Protocol to analyze the known and credible threats to which a specific host or device might be subjected, and to the extent that it is feasible, to provide security mechanisms which ameliorate or reduce the risks associated with such threats. To: 5. Security Considerations The use of IPv4 Link-Local Addresses may open a network host to new attacks. In particular, a host that previously did not have an IP address, and no IP stack running, was not susceptible to IP-based attacks. By configuring a working address, the host may now be vulnerable to IP-based attacks. The ARP protocol [RFC 826] is insecure. A malicious host may send fraudulent ARP packets on the network, interfering with the correct operation of other hosts. For example, it is easy for a host to answer all ARP requests with replies giving its own hardware address, thereby claiming ownership of every address on the network. | A host implementing IPv4 link-local configuration has the additional | vulnerability to selective reconfiguration and disruption. It is | possible for an on-link attacker to issue ARP packets which would | cause a host to break all its connections by switching to a new | address. The attacker could force the host implementing IPv4 | link-local configuration to select certain addresses, or prevent it | from ever completing address selection. This is a distinct threat | from that posed by fraudulent ARPs, described in the preceding | paragraph. Implementers are advised that the Internet Protocol architecture expects every networked device or host must implement security which is adequate to protect the resources to which the device or host has access, including the network itself, against known or credible threats. Even though use of link-local addresses may reduce the number of threats to which a device is exposed, implementers of devices supporting the Internet Protocol must not assume that a customer's local network is free from security risks. While there may be particular kinds of devices, or particular environments, for which the security provided by the network is adequate to protect the resources that are accessible by the device, it would be misleading to make a general statement to the effect that the requirement to provide security is reduced for devices using link-local addresses as a sole means of access. In all cases, whether or not link-local addresses are used, it is necessary for implementers of devices supporting the Internet Protocol to analyze the known and credible threats to which a specific host or device might be subjected, and to the extent that it is feasible, to provide security mechanisms which ameliorate or reduce the risks associated with such threats. --------------------------------------------------------------- > > > FWIW when 802.1d is enabled on the port I plug in my laptop at the > > > office, the delay before the switch starts forwarding packets is 45 > > > seconds. (I think the 802.1d spec indicates a default time of around > > > 30 seconds.) So 10 seconds don't seem to do much good. > > > > 2.3 Shorter Timeouts on Appropriate Network Technologies > > > > The time values specified above are intended for use on technologies > > such as Ethernet, where switches that implement Spanning Tree > > [802.1d] often silently discard all packets for several seconds. The > > time values specified above result in a delay of 8-10 seconds before > > a chosen IP address may be used. > > > > add --> > > > > In some cases, the delay can be considerably longer due to other > > networking infrastructure. > > > > The purpose of this section is to give some guidance to implementors > > to set appropriate values for their timers, not to definitively answer > > what those settings should be. > > Thanks for the attempt, but I think this addition is insufficient. > > Deleting text might be a better approach. Here is a revised section 2.3 which removes the questionable text and adds an explanation of why shorter timeouts may not be such a great idea. From draft-ietf-zeroconf-ipv4-linklocal-07.txt: 2.3 Shorter Timeouts on Appropriate Network Technologies The time values specified above are intended for use on technologies such as Ethernet, where switches that implement Spanning Tree [802.1d] often silently discard all packets for several seconds. The time values specified above result in a delay of 8-10 seconds before a chosen IP address may be used. For a desktop machine on Ethernet, this may not be a great problem, but for other types of device, particularly portable hand-held wireless devices, a ten-second delay before networking services becomes available may not be acceptable. For this reason, shorter time values may be used on network technologies that allow the device to determine when the link has become active and can be reasonably trusted to deliver packets reliably. On these network technologies the recommended time values are: The host should first wait for a random time interval selected uniformly in the range 0-200 milliseconds, and then send four probe packets, waiting 200 milliseconds after each probe, making a total delay of 800-1000 milliseconds before a chosen IP address may be used. Should future versions of the IEEE Spanning Tree Protocol be enhanced to inform clients when the link is ready to begin forwarding packets, then the shorter time values may be used on these networks too. To: 2.3 Shorter Timeouts on Appropriate Network Technologies | The time values specified above result in a delay of 8-10 seconds | before a chosen IP address may be used. The time values specified above are intended for use on technologies such as Ethernet, where switches that implement Spanning Tree | [802.1d] often silently discard all packets for several seconds. | There may be additional delays before a host is able to send and | receive datagrams on a link. Some switches may only forward packets | after several seconds. Implementors should exercise some restraint, | therefore, in setting timers to short, aggressive values. If hosts | configure IPv4 link-local addresses before these addresses can be | defended, there is an increased risk of collision once the host is | able to send and receive datagrams on the link. | Shorter time values MAY be used on network technologies that allow the device to determine when the link has become active and can be reasonably trusted to deliver packets reliably. On these network technologies the recommended time values are: The host should first wait for a random time interval selected uniformly in the range 0-200 milliseconds, and then send four probe packets, waiting 200 milliseconds after each probe, making a total delay of 800-1000 milliseconds before a chosen IP address may be used. | --------------------------------------------------------- > > (a) The paragraph must be augmented with the following: > > Host must consider the case where more than one interface is > > connected to the same link. Say the list of link-layer addresses > > for a given host is L. The claim-defend algorithm MUST consider > > the case when arp sender link-layer address is in L. In this case, > > the IP sender address field in the arp message *does not* constitute > > a conflict necessitating the host to select another address for any > > interface in the list L. > > Wouldn't this result in the two (or more) interfaces attached to the same > link on the node to have the same v4LL address? While it might be possible > to get such a configuration to work, I suspect it requires additional things. > > > > > (b) Each interface should be assigned a different v4LL address and > > can then operate independently. > > > > (b)... > Which of the two b's? :-) Format error! Shame on me. (a) and (b) above are alternatives. The paragraph below is an assessment of the alternatives. (b) is simpler, and as you state above, it is less instable due to address reconfiguration events and has fewer security consequences. Further, (a) relies upon all link-layer addresses being unique, which is not necessarily true and not required for (b). Proposal: (b) Until there is further discussion on this point, I will not suggest text. ------------------------------------------------------------------------ Erik From owner-zeroconf@merit.edu Fri Dec 6 09:10:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06710 for ; Fri, 6 Dec 2002 09:10:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 30F6A91242; Fri, 6 Dec 2002 09:12:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EEB3091243; Fri, 6 Dec 2002 09:12: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 B604691242 for ; Fri, 6 Dec 2002 09:12:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 94BCC5DFA5; Fri, 6 Dec 2002 09:12:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 376875DE67 for ; Fri, 6 Dec 2002 09:12:53 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB6ECnj04861; Fri, 6 Dec 2002 09:12:50 -0500 (EST) Message-Id: <200212061412.gB6ECnj04861@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Guttman Cc: Erik Nordmark , Thomas Narten , zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Fri, 06 Dec 2002 14:24:32 +0100.") Date: Fri, 06 Dec 2002 09:12:49 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Revise Section 7. > > From draft-ietf-zeroconf-ipv4-linklocal-07.txt: > > 7. Application Programming Considerations > > Use of IPv4 link-local autoconfigured addresses presents additional > challenges to writers of applications and may result in existing > application software failing. > > To: > > 7. Application Programming Considerations > > Use of IPv4 link-local autoconfigured addresses presents additional > challenges to writers of applications and may result in existing > | application software failing. Operational problems will arise if > | the following considerations are not addressed by application > | software. It is therefore RECOMMENDED that IPv4 link-local > | autoconfiguration support be deployed only with application software > | which is robust to address changes, does not forward IPv4 link-local > | addresses and avoids address ambiguity problems, as described below. that sounds reasonable. however, with the current proposal LL is enabled by default on all platforms that support it, and there is no defined way to disable it. how are users/networks to avoid deploying LL (say, if they're running apps that don't meet the above conditions) without a mechanism to disable it? Keith From owner-zeroconf@merit.edu Fri Dec 6 09:34:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07719 for ; Fri, 6 Dec 2002 09:34:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 84BFD91243; Fri, 6 Dec 2002 09:36:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5467A91245; Fri, 6 Dec 2002 09:36: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 4250291243 for ; Fri, 6 Dec 2002 09:36:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 228B75DDE2; Fri, 6 Dec 2002 09:36:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id CF2A15DDB7 for ; Fri, 6 Dec 2002 09:36:40 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19879; Fri, 6 Dec 2002 06:36:38 -0800 (PST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gB6Eaal14710; Fri, 6 Dec 2002 15:36:36 +0100 (MET) Date: Fri, 6 Dec 2002 15:36:34 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Keith Moore Cc: Erik Guttman , Erik Nordmark , Thomas Narten , zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: <200212061412.gB6ECnj04861@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Fri, 6 Dec 2002, Keith Moore wrote: > > Revise Section 7. > > > > From draft-ietf-zeroconf-ipv4-linklocal-07.txt: > > > > 7. Application Programming Considerations > > > > Use of IPv4 link-local autoconfigured addresses presents additional > > challenges to writers of applications and may result in existing > > application software failing. > > > > To: > > > > 7. Application Programming Considerations > > > > Use of IPv4 link-local autoconfigured addresses presents additional > > challenges to writers of applications and may result in existing > > | application software failing. Operational problems will arise if > > | the following considerations are not addressed by application > > | software. It is therefore RECOMMENDED that IPv4 link-local > > | autoconfiguration support be deployed only with application software > > | which is robust to address changes, does not forward IPv4 link-local > > | addresses and avoids address ambiguity problems, as described below. > > that sounds reasonable. however, with the current proposal LL is enabled > by default on all platforms that support it, and there is no defined way > to disable it. how are users/networks to avoid deploying LL (say, if they're > running apps that don't meet the above conditions) without a mechanism to > disable it? First, This protocol is an elective standard. No one has to implement or deploy it. Should vendors choose to implement it, and customers choose to buy their equipment, there are several ways in which the recommendation will have an impact. a) Proper app support before inclusion of IPv4LL support - closed platform Example: A device vendor which offers, say, a print server or file server with no human interface. Such devices already exist. These servers are currently written in a fashion which is brittle wrt v4LL. The vendor should harden the server code so that it will not break, panic, etc if its own address changes. The vendor should think twice about supporting v4LL on more than one interface. If the vendor does, the server will have to be sophisticated enough to keep address/interfaces separate so that if a request comes from interface A, address A it is distinct from a request which comes from interface B, address A. Finally, the server will have to be very carefully written so that it does not forward locators. For example - a web server generating dynamic content will have to use names instead of addresses in links if possible (where names can be resolved using LLMNR, etc). b) Proper platform support before inclusion of IPv4LL support Example: I understand Microsoft includes a system level 'address changed' exception which IP services are supposed to catch. This is part of their IPv6 developer environment. Microsoft has modified their own server software to accomodate address changes and has notified their developers to do the same. This could be done for IPv4 LL as well. Example: Pending new and improved APIs for dealing with address ambiguity on separate interfaces, vendors could include v4LL on only one interface. This would eliminate one of the three identified issues for applications using v4LL addresses. Example: Platform can offer late binding service discovery and name resolution protocols (SLP, LLNMR, Rendezvous, UPnP, etc) so that clients can discover services even if the server's address changes. Vendors can work hard to inform developers on their platforms of the problem and the solution. Example: A vendor can offer an 'off switch', where users who are not getting results they want with v4LL can turn it off. Erik From owner-zeroconf@merit.edu Fri Dec 6 09:55:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08610 for ; Fri, 6 Dec 2002 09:55:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 99F5991245; Fri, 6 Dec 2002 09:58:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4537B91246; Fri, 6 Dec 2002 09:58: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 0051091245 for ; Fri, 6 Dec 2002 09:58:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id DC5C95DF66; Fri, 6 Dec 2002 09:58:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id AF3205DEF4 for ; Fri, 6 Dec 2002 09:58:12 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB6Ew9j05058; Fri, 6 Dec 2002 09:58:09 -0500 (EST) Message-Id: <200212061458.gB6Ew9j05058@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Guttman Cc: Keith Moore , Erik Nordmark , Thomas Narten , zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Fri, 06 Dec 2002 15:36:34 +0100.") Date: Fri, 06 Dec 2002 09:58:09 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > that sounds reasonable. however, with the current proposal LL is enabled > > by default on all platforms that support it, and there is no defined way > > to disable it. how are users/networks to avoid deploying LL (say, if they're > > running apps that don't meet the above conditions) without a mechanism to > > disable it? > > First, This protocol is an elective standard. No one has to implement > or deploy it. get real. we both know that this is going to be deployed on both of the general-purpose platforms that make up 99% of the installed base of those platforms, and customers have little choice about whether to buy one of those platforms. saying it is an elective standard is meaningful for special-purpose devices, perhaps, but not for general purpose platforms. so the "it's not our fault if it's broken because nobody has to implement it argument" is pure hogwash. > b) Proper platform support before inclusion of IPv4LL support > > Example: I understand Microsoft includes a system level 'address > changed' exception which IP services are supposed to catch. This > is part of their IPv6 developer environment. Microsoft has > modified their own server software to accomodate address changes > and has notified their developers to do the same. This could be > done for IPv4 LL as well. it doesn't solve the problem. few application protocols are able to recover from an unanticipated address change; this essentially requires that (a) they implement acks at layer 7 (b) that each sender buffer every message sent until it receives an ack for that messages (c) that there be a uniform and stable naming system within the app to take the place of IP (and it's not reasonable to assume that DNS is used for this purpose) > Example: Pending new and improved APIs for dealing with address > ambiguity on separate interfaces, vendors could include v4LL on > only one interface. This would eliminate one of the three > identified issues for applications using v4LL addresses. even the APIs don't solve the problem, as they require increased complexity of applications which is not always feasible. > Example: Platform can offer late binding service discovery and > name resolution protocols (SLP, LLNMR, Rendezvous, UPnP, etc) > so that clients can discover services even if the server's > address changes. Vendors can work hard to inform developers > on their platforms of the problem and the solution. those protocols don't solve the problem either - what they mainly serve to do is to make life more complex and to increase the diversity of operating environments that apps have to cope with. > Example: A vendor can offer an 'off switch', where users who > are not getting results they want with v4LL can turn it off. this is by far the simplest and most reliable solution. there needs to be a way to do this from the network (at least as much as for any other knob that people want to control via DHCP) and it needs to be part of the standard. Keith From owner-zeroconf@merit.edu Fri Dec 6 10:00:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08924 for ; Fri, 6 Dec 2002 10:00:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ED2089122D; Fri, 6 Dec 2002 10:03:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6D679123D; Fri, 6 Dec 2002 10:03: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 B6E4B9122D for ; Fri, 6 Dec 2002 10:02:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 92D185DF71; Fri, 6 Dec 2002 10:02:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 260635DF66 for ; Fri, 6 Dec 2002 10:02:41 -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 KAA26335 for ; Fri, 6 Dec 2002 10:02:40 -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 KAA02675 for ; Fri, 6 Dec 2002 10:02:39 -0500 (EST) Received: from [18.18.3.76] (WINDEL1.MIT.EDU [18.18.3.76]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA23042 for ; Fri, 6 Dec 2002 10:02:39 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 06 Dec 2002 10:02:34 -0500 Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212061458.gB6Ew9j05058@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/06/2002 09:58, "Keith Moore" wrote: >> Example: A vendor can offer an 'off switch', where users who >> are not getting results they want with v4LL can turn it off. > > this is by far the simplest and most reliable solution. there needs to be > a way to do this from the network (at least as much as for any other knob > that people want to control via DHCP) and it needs to be part of the standard. If you are going to advocate a new, easier way to remotely change configuration on machines, then I personally will scream bloody murder unless it's tied into a known, tested, and reliable, cross platform authentication and encryption system *by default*. There are enough ways to modify stuff remotely *now*, we do NOT need another method, and it is a hideously *bad* idea to make one part of the standard john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Dec 6 10:01:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08971 for ; Fri, 6 Dec 2002 10:01:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A73C09123D; Fri, 6 Dec 2002 10:04:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7720B91246; Fri, 6 Dec 2002 10:04:30 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CEB59123D for ; Fri, 6 Dec 2002 10:04:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 51E755DF66; Fri, 6 Dec 2002 10:04:29 -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 DAB725DEF4 for ; Fri, 6 Dec 2002 10:04: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 KAA24596 for ; Fri, 6 Dec 2002 10:04: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 KAA27532 for ; Fri, 6 Dec 2002 10:04:28 -0500 (EST) Received: from [18.18.3.76] (WINDEL1.MIT.EDU [18.18.3.76]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA23844 for ; Fri, 6 Dec 2002 10:04:27 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 06 Dec 2002 10:04:22 -0500 Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212061458.gB6Ew9j05058@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/06/2002 09:58, "Keith Moore" wrote: >> b) Proper platform support before inclusion of IPv4LL support >> >> Example: I understand Microsoft includes a system level 'address >> changed' exception which IP services are supposed to catch. This >> is part of their IPv6 developer environment. Microsoft has >> modified their own server software to accomodate address changes >> and has notified their developers to do the same. This could be >> done for IPv4 LL as well. > > it doesn't solve the problem. few application protocols are able to > recover from an unanticipated address change; this essentially requires > that (a) they implement acks at layer 7 (b) that each sender buffer every > message sent until it receives an ack for that messages (c) that there > be a uniform and stable naming system within the app to take the place of > IP (and it's not reasonable to assume that DNS is used for this purpose) Good point. But for now, DNS is all we have, so we should use it. Let's not delay stuff for another decade waiting for YAMS. (yet another magic standard). john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Dec 6 10:05:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09183 for ; Fri, 6 Dec 2002 10:05:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 88C4391246; Fri, 6 Dec 2002 10:08:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 504D49124A; Fri, 6 Dec 2002 10:08: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 444AF91246 for ; Fri, 6 Dec 2002 10:08:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 30BDF5DF71; Fri, 6 Dec 2002 10:08:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id D9A995DE97 for ; Fri, 6 Dec 2002 10:08:22 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09294; Fri, 6 Dec 2002 07:08:21 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gB6F8DH26163; Fri, 6 Dec 2002 16:08:13 +0100 (MET) Date: Fri, 6 Dec 2002 16:04:55 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt To: Erik Guttman Cc: Erik Nordmark , Thomas Narten , zeroconf@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > | IPv4 link-local addresses and their dynamic configuration have > | profound implications upon applications which use them. This is > | discussed in Section 7. Existing applications fundamentally > | assume addresses of communicating peers are routable, relatively > | unchanging and unique. These assumptions no longer hold with IPv4 > | link-local addresses. IPv4 link-local addresses are therefore > | applicable for those existing applications which can either > | accomodate these differences or for those applications which are > | modified to account for dynamic addresses, their limited scope and > | their potential ambiguity. Instead of "for those existing applications ..." it might make more sense to say "if it is either known that all applications that are used can accomondate this change in the properties of the IP addresses, or all applications that are used have been modified to account for dynamic addresses, their limited scope and their potential ambiguity. > Here is a revised section 2.3 which removes the questionable text and > adds an explanation of why shorter timeouts may not be such a great > idea. > The time values specified above are intended for use on technologies > such as Ethernet, where switches that implement Spanning Tree > | [802.1d] often silently discard all packets for several seconds. Still doesn't make sense if the discard time is 30-45 seconds. If we talk about the protocol and not the text, I know of two interesting cases on IEEE 802 media: 1. No spanning tree on the port to which you connect, or the port has been enabled for a long time before the address claim is done. In this case it probably makes sense to have slightly shorter timers i.e. a few packets over a few seconds might suffice. Thus 3 seconds instead of 8. 2. Spanning tree on the port to which you connect. If the address claim is done immediately after bringing up the link the host might as well wait for 45 seconds before sending any packet. I don't know if the host can tell the difference between #1 and #2 - or if it can "ask" (at the Ethernet layer) if the switch is running STP. With RSTP I think the problem goes away and the approach used in #1 can be used. Erik From owner-zeroconf@merit.edu Fri Dec 6 11:00:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11721 for ; Fri, 6 Dec 2002 11:00:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0C37891291; Fri, 6 Dec 2002 11:03:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CBD9C912C5; Fri, 6 Dec 2002 11:03: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 7761C91291 for ; Fri, 6 Dec 2002 11:03:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4B1B65DE6B; Fri, 6 Dec 2002 11:03:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id F0BDD5DDB7 for ; Fri, 6 Dec 2002 11:03:09 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28989; Fri, 6 Dec 2002 09:03:08 -0700 (MST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gB6G37l17543; Fri, 6 Dec 2002 17:03:07 +0100 (MET) Date: Fri, 6 Dec 2002 17:03:05 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: Harald Alvestrand Cc: zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Harald, You sent a comment that we should add examples. I suggested a few and got no response. I am trying again, with specific text. This could be added in section 1 (introduction), say as a subsection to 1.2 Applicability, or in Section 7 on application considerations X.Y Examples: Applications Using Link-Local Addresses Several applications are particularly well suited for use in a link-local environment. These applications have been enjoyed for years by users of AppleTalk and SMB protocols, but have not been available for use on networks using the Internet protocol suite alone due to the lack of automatic address configuration. The primary applications which users expect are file sharing and printer sharing. File sharing could be achieved using FTP [RFC959], and NFSv4 [RFC3010] clients and servers. Print sharing can be done by using LPD [RFC1179] or IPP [RFC2910] protocols. These protocols will behave as expected if a) neither the client nor the server is forced to change its link-local address after a protocol connection has been established b) neither the client nor the server are multihomed hosts using link-local on more than one interface c) both client and server have a v4LL address Existing clients can cope with (a) by reestablishing a connection. Connection failures are common enough that clients typically are able to easily restart a session. Clients may and servers likely will need to be changed so as to always use their *current* address for communication, instead of the address they had at the time the program started. It would be best if vendors avoided support for (b) unless they offer new interfaces and mechanisms to resolve potential problems with address ambiguity, as discussed in Section 3. c) concerns hosts which forward messages including link-local addresses off of the local link. Protocols listed above can contain addresses (FTP, NFSv4, IPP). Section 2 specifies that a datagram with a link-local source or destination address MUST not be sent to a router for forwarding. There are only a limited number of ways in which a datagram with a link-local identifier can then be forwarded off the local link. 1. A host not compliant with this specification may send a message to a link-local destination address to a router for forwarding. The router, if it is not compliant with this specification, will forward the message. Result 1.1. A host which receives this message will not be able to respond, as hosts which comply with this specification do not forward from a link-local source address. Response to 1.1. Configure routers not to forward to link-local destinations. Result 1.2. A host which forwards a message to a link-local destination instead of using ARP to resolve the address locally will not be able to communicat with hosts configured with link-local addresses, on their local link. Response to 1.2: Configure routers not to forward to link-local address destinations. Upgrade hosts to support this specification if one wants to effectively communicate with hosts using link-local addresses. 2. If a host sends a datagram to a global multicast address from a link-local source address, a router may forward the message. Result 2.1: Messages will leave a local link which have a source address to which it is impossible to send a reply. Or if one does send a reply and it happens to reach the sender, the sender will not be able to reply (see Result 1.1). Response to 2.1: Configure routers not to forward messages with link-local source addresses. 3. A host with a global address could act as a proxy for a device with a link-local address. The proxy could forward a request for a client with only a link-local address off the link. The proxy could also forward a reqest from off the link to a server with only a link-local address. Result 3.1: Link-local addresses in NFSv4, IPP and FTP (passive mode) will not result in the receiver of these locators being able to respond to their senders. This has the same properties as network address translation (NAT). [RFC2663] Response to 3.1: For communication off the local link, the best thing to do is configure the client or server with a global address. If that is not possible, see [RFC2663] for how to proxy and gateway applications across an address scope boundary. How does this look? Erik On Wed, 27 Nov 2002, Erik Guttman wrote: > On Fri, 4 Oct 2002, Thomas Narten wrote: > > The IESG discussed this document recently, and has the following > > comments. > > > > DISCUSS: > > ======== > > Harald: > > > > Three objections, based on a quick scan: > > > > 1) > > > > The document gives no (zero) examples of applications that can > > successfully and safely be used with link-local addresses. I think a > > list of applications would serve two purposes: > > > > - document the motivation for this feature > > - serve as target for people arguing that this application has > > serious failure modes when used with link-local addresses > > Application examples: > > Tha classic peer to peer applications are > 'File sharing' - NFS and ONC RPC based protocols, SMB > 'Local printing' - LPD > > Let's add > 'Local web browsing' - FTP, HTTP > 'Local administration' - telnet > > Caveats: > > General - > This does not describe how a link-local address is configured with the > application. This could be done using LLMNR, SLP, etc. This implies > that 'link-local locators' (names and addresses that have only link- > local significance) can obtained service queries (SLP), or name > lookups (LLMNR), etc. > > Since link local addresses may change over time (unlikely, but > possible), it is best to obtain them dynamically (using SLP or LLMNR, > etc.) > > Link-local local locators which are forwarded off-link are worthless. > Therefore, some protocols, such as conferencing or those which build > session based directories to forward locators would fail. > > An example of how a protocol which supports forwarding of locators can > be made to work in a scoped address environment is in RFC 3111, SLP > modifications for IPv6. The only trick is to keep information which > is received using a scoped address separate, and to only forward it > to others in the same scope as it was received. > > The following comments apply equally to any use of these protocols > in scoped or private address spaces. > > HTTP - > Redirects [RFC 2616, Section 10.3] and the Content-Location header > in general [RFC 2616, Section 14.14] will have to be link-local > locators in order for a client configured with a link-local > address to make use of it. > > HTML - > URIs refered to in anchors, etc. must be link-local locators in > order for a a client configured with a link-local address to make > use of it. > > > The following set of protocols: > > > > - FTP > > - DNS > > - NFS > > - IPSEC using IPv4 as an identifier > > - BGP > > - OSPF > > - RTP/RTCP > > <<>> > > > > will fail if applications use a link-local address instead of a > > globally unique address when sending the address of its interface in > > a protocol packet. > > In the case of IPSEC using IPv4 as an id, BGP, OSPF: OK. > > Why is this the case with FTP, DNS, NFS, RTP/RTCP? > If the sender and receiver are both on the same link these protocols > should work fine, I believe. From owner-zeroconf@merit.edu Fri Dec 6 11:24:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12588 for ; Fri, 6 Dec 2002 11:24:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F30C49121B; Fri, 6 Dec 2002 11:27:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2E25912C5; Fri, 6 Dec 2002 11: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 902599121B for ; Fri, 6 Dec 2002 11:27:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 69F515DF61; Fri, 6 Dec 2002 11:27:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from arrakis.cso.uiuc.edu (arrakis.cso.uiuc.edu [130.126.113.7]) by segue.merit.edu (Postfix) with ESMTP id 17E935DF5C for ; Fri, 6 Dec 2002 11:27:24 -0500 (EST) Received: from arrakis.cso.uiuc.edu (localhost [127.0.0.1]) by arrakis.cso.uiuc.edu (8.12.4/8.12.4) with ESMTP id gB6GRNXN004665; Fri, 6 Dec 2002 10:27:23 -0600 (CST) Received: (from jak@localhost) by arrakis.cso.uiuc.edu (8.12.4/8.12.4/Submit) id gB6GRN6F004664; Fri, 6 Dec 2002 10:27:23 -0600 (CST) Date: Fri, 6 Dec 2002 10:27:23 -0600 From: "Jay A. Kreibich" To: Erik Nordmark Cc: zeroconf Subject: Re: TTL=255 on xmit, no check on receipt please Message-ID: <20021206162723.GA4506@uiuc.edu> Reply-To: jak@uiuc.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Editor: vi, and proud of it X-URL: http://www.uiuc.edu/~jak (includes PGP key) Sender: owner-zeroconf@merit.edu Precedence: bulk On Fri, Dec 06, 2002 at 08:48:38AM +0100, Erik Nordmark scratched on the wall: > > BUT, the fact that IPv6 uses this TTL check to solve what is more or > > less an identical problem** provides very strong precedence for the > > validity of the check. The IPv6 working group felt that it was the > > correct solution to the problem. While IPv6 networks aren't exactly > > common, there are numerous implementations and many many research > > networks in both education and industry that have put the protocol > > under a microscope from top to bottom. > > > **-- The problem I see in IPv4 LL addresses and the problem that > > is being solved with IPv6 Neighbor Discovery is the question of > > protocol robustness in the face of a non-compliant node (e.g. one > > that is broken or hostile). IPv6 ND absolutely depends on the idea > > that packets are from/to local link neighbors-- you don't have to > > trust your neighbors, but you have to be sure the nodes you are > > talking to really are your neighbors. > > AFAIK the problem is far from identical. The *problem* is identical: ARP, IPv4 LL traffic, IPv6 LL traffic, IPv6 ND, and other protocols all suffer from the same "weakness," which is a problem to be solved: if protocol traffic is allowed to "leak" across link boundaries (i.e. across a layer-3 gateway) the protocol degrades and becomes unusable in the face of a non-compliant node (e.g. a hostile node). There are a number of different solutions to this problem-- the TTL=255 check is just one of them. The *environment* this problem has to be solved in for each protocol is quite different, but in the case of IPv6 ND and IPv4 LL, I would argue the environment and motivations for a specific solution aren't even all that different. ARP solves this problem with simple network layer isolation, running directly at layer-2, which makes it impossible to cross a layer-3 gateway. IPv6 LL traffic solves the problem by making all layer-3 devices filter traffic based on LL IP addresses. This can be done because this condition was in the standard from day one so *all* IPv6 gateways should correctly filter this traffic. This solution has the added benefit of isolating any "out of spec" traffic to the local link network it was sourced from. As it has been pointed out several times on this list, IPv6 ND can't filter on LL IP addresses since the protocol is often used between globally routable addresses on the same link. Thus, IPv6 ND uses a different solution and checks TTL=255 so hosts can verify packets originated on the local-link. Nodes can discard questionable packets before processing those packets and handing them up to high layers in the stack. This prevents the protocol logic from being attacked by "out of spec" packets, but it does not prevent those bad packets from being delivered to the end host and consuming resources (bandwidth) on all the transient networks. Which brings us back to IPv4. Obviously IP is a layer-3 protocol, so the solution ARP uses is out. That leaves us with address filtering and TTL checks. If we had a blank slate to work with, clearly address filtering at the gateways is the way to go, just as IPv6 LL traffic does. It is simple, straight forward, and has the added bonus of isolating traffic (and resource usage) to the local network. But putting the words in the standard does not instantly change the hundreds of thousands of deployed IPv4 routers-- and with both Apple and Microsoft showing some level of interest in this standard, it is reasonable to assume that it will be deployed on a sizable fraction of the world's networks in a moderately short period of time. There is no reason we can't ask for address filters on the gateways, we just can't *depend* on them in a "real world" environment. The *reasons* we can't depend on the gateways are different for IPv6 ND and IPv4 LL are different, but the end result is the same: we cannot depend on the gateways to do this for us-- the hosts must be able to determine the origin of the traffic themselves. That means IPv4LL needs a back-up plan to solve this problem, which brings us back to the TTL check of setting and checking specific TTL values. As has been discussed previously on the list, no matter what the TTL is set to, the only TTL value worth checking is 255-- just as IPv6 ND does. > Hence RFC 2461 uses ttl=255 for a different reason that v4LL. In my previous message I didn't mean to there was only one solution to the link-local traffic isolation problem, nor to say the motivations for a specific solution to the problem are the same in these protocols, only that the problem was the same: the need to isolate link-local traffic. But I would go further and say that the "reason" IPv6 ND (RFC 2461) uses TTL is because it can't depend on the routers to do the filtering (due to the lack of known addresses to filter) and the "reason" I think IPv4LL should use the TTL check is because we can't depend on the routers to do the filtering (due to standards deployment problems). So in my opinion even the reasons and motivations for the TTL=255 solution to this common problem aren't all that different, even if the environmental conditions and limitations that bring those reasons about is different. -j -- Jay A. Kreibich | Integration & Software Eng. jak@uiuc.edu | Campus IT & Edu. Svcs. | University of Illinois at U/C From owner-zeroconf@merit.edu Fri Dec 6 11:27:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12625 for ; Fri, 6 Dec 2002 11:27:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B9898912C5; Fri, 6 Dec 2002 11:29:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84D6A912C8; Fri, 6 Dec 2002 11:29: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 8140D912C5 for ; Fri, 6 Dec 2002 11:29:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 668935DF80; Fri, 6 Dec 2002 11:29:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id DD1295DF5C for ; Fri, 6 Dec 2002 11:29:46 -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 JAA15216; Fri, 6 Dec 2002 09:29:45 -0700 (MST) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gB6GThl18535; Fri, 6 Dec 2002 17:29:43 +0100 (MET) Date: Fri, 6 Dec 2002 17:29:41 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Keith Moore Cc: Erik Guttman , Erik Nordmark , Thomas Narten , zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: <200212061458.gB6Ew9j05058@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Fri, 6 Dec 2002, Keith Moore wrote: > > > that sounds reasonable. however, with the current proposal LL is enabled > > > by default on all platforms that support it, and there is no defined way > > > to disable it. how are users/networks to avoid deploying LL (say, if they're > > > running apps that don't meet the above conditions) without a mechanism to > > > disable it? > > > > First, This protocol is an elective standard. No one has to implement > > or deploy it. > > get real. we both know that this is going to be deployed on both of the > general-purpose platforms that make up 99% of the installed base of those > platforms, and customers have little choice about whether to buy > one of those platforms. saying it is an elective standard is meaningful for > special-purpose devices, perhaps, but not for general purpose platforms. > > so the "it's not our fault if it's broken because nobody has to implement > it argument" is pure hogwash. Arguing about this is fruitless. The protocol is out there. We need to publish a specification which explains how it works and how to use it safely. > > b) Proper platform support before inclusion of IPv4LL support > > > > Example: I understand Microsoft includes a system level 'address > > changed' exception which IP services are supposed to catch. This > > is part of their IPv6 developer environment. Microsoft has > > modified their own server software to accomodate address changes > > and has notified their developers to do the same. This could be > > done for IPv4 LL as well. > > it doesn't solve the problem. few application protocols are able to > recover from an unanticipated address change; this essentially requires > that (a) they implement acks at layer 7 (b) that each sender buffer every > message sent until it receives an ack for that messages (c) that there > be a uniform and stable naming system within the app to take the place of > IP (and it's not reasonable to assume that DNS is used for this purpose) Applications can be made to recover from unanticipated address change without protocol level support. Stateful protocols will lose their state and have to rebuild sessions. That is not what I am suggesting. > > Example: Pending new and improved APIs for dealing with address > > ambiguity on separate interfaces, vendors could include v4LL on > > only one interface. This would eliminate one of the three > > identified issues for applications using v4LL addresses. > > even the APIs don't solve the problem, as they require increased complexity > of applications which is not always feasible. I am not suggesting we have this debate in the text above. > > Example: Platform can offer late binding service discovery and > > name resolution protocols (SLP, LLNMR, Rendezvous, UPnP, etc) > > so that clients can discover services even if the server's > > address changes. Vendors can work hard to inform developers > > on their platforms of the problem and the solution. > > those protocols don't solve the problem either - what they mainly serve > to do is to make life more complex and to increase the diversity of > operating environments that apps have to cope with. Appletalk proves you are wrong. > > Example: A vendor can offer an 'off switch', where users who > > are not getting results they want with v4LL can turn it off. > this is by far the simplest and most reliable solution. there needs > to be a way to do this from the network (at least as much as for any > other knob that people want to control via DHCP) and it needs to be > part of the standard. We have been through this in 3 WG last calls and 2 IETF last calls. Your opinion is the rough part of the consensus here. I bring up the off switch only because there is nothing preventing a vendor from offering this. Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n Solaris Installation and Provisioning phone: +49 6227 356 202 Sun Microsystems cell: +49 172 865 5497 (140 char max) pager: 01728655497@d2-message.de From owner-zeroconf@merit.edu Fri Dec 6 13:05:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17050 for ; Fri, 6 Dec 2002 13:05:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 48191912E0; Fri, 6 Dec 2002 13:08:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 197FA912E1; Fri, 6 Dec 2002 13:08: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 D340F912E0 for ; Fri, 6 Dec 2002 13:08:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id BDA1B5DF8D; Fri, 6 Dec 2002 13:08:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 9033B5DE9E for ; Fri, 6 Dec 2002 13:08:23 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB6I7sj05865; Fri, 6 Dec 2002 13:07:54 -0500 (EST) Message-Id: <200212061807.gB6I7sj05865@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Guttman Cc: Keith Moore , Erik Nordmark , Thomas Narten , zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Fri, 06 Dec 2002 17:29:41 +0100.") Date: Fri, 06 Dec 2002 13:07:54 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Arguing about this is fruitless. The protocol is out there. We need to > publish a specification which explains how it works and how to use it > safely. documenting existing practice is generally a good idea. assessing the effect of an existing practice is also useful. if the document were just a description of existing practice, I'd fully its publication as an Informational RFC. but that's not what this document is trying to do. it is trying to recommend a variant of existing practice even though that variant is obviously harmful to some networks and applications, and it's trying to do so without recommending any effective measures for limiting that harm. and it's trying to get IETF's endorsement of these practices. > > it doesn't solve the problem. few application protocols are able to > > recover from an unanticipated address change; this essentially requires > > that (a) they implement acks at layer 7 (b) that each sender buffer every > > message sent until it receives an ack for that messages (c) that there > > be a uniform and stable naming system within the app to take the place of > > IP (and it's not reasonable to assume that DNS is used for this purpose) > > Applications can be made to recover from unanticipated address change > without protocol level support. Wow. that's an extraordinary statement. would you care to explain how that can be done? > > > Example: Platform can offer late binding service discovery and > > > name resolution protocols (SLP, LLNMR, Rendezvous, UPnP, etc) > > > so that clients can discover services even if the server's > > > address changes. Vendors can work hard to inform developers > > > on their platforms of the problem and the solution. > > > > those protocols don't solve the problem either - what they mainly serve > > to do is to make life more complex and to increase the diversity of > > operating environments that apps have to cope with. > > Appletalk proves you are wrong. actually, appletalk is a good illustration of the phenomenon. it results in either having appletalk-only apps or having apps that try to deal with a mixture of appletalk and DNS. we either get different apps for the LAN vs. the WAN or apps that work differently in different environments. > > > Example: A vendor can offer an 'off switch', where users who > > > are not getting results they want with v4LL can turn it off. > > > > this is by far the simplest and most reliable solution. there needs > > to be a way to do this from the network (at least as much as for any > > other knob that people want to control via DHCP) and it needs to be > > part of the standard. > > We have been through this in 3 WG last calls and 2 IETF last calls. > Your opinion is the rough part of the consensus here. why do you keep trying to justify a lack of technical soundness by appeals to consensus? consensus within the working group does not make up for a failure of the document to meet the basic standards of 2026. Keith From owner-zeroconf@merit.edu Fri Dec 6 13:11:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17305 for ; Fri, 6 Dec 2002 13:11:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3CFDA912E1; Fri, 6 Dec 2002 13:14:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A0FC912E2; Fri, 6 Dec 2002 13:14: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 EAA2B912E1 for ; Fri, 6 Dec 2002 13:14:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id D188D5DE9E; Fri, 6 Dec 2002 13:14:18 -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 57A515DDB7 for ; Fri, 6 Dec 2002 13:14:18 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gB6IEHw28219 for ; Fri, 6 Dec 2002 10:14:17 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 6 Dec 2002 10:14:17 -0800 Received: from apple.com (lubet1.apple.com [17.202.40.146]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id gB6IEGp00663 for ; Fri, 6 Dec 2002 10:14:16 -0800 (PST) Date: Fri, 6 Dec 2002 10:14:26 -0800 Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) From: Vincent Lubet To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <200212061458.gB6Ew9j05058@astro.cs.utk.edu> Message-Id: <8E3CD216-0946-11D7-AFE2-0003937AD75C@apple.com> X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, December 6, 2002, at 06:58 AM, Keith Moore wrote: >> b) Proper platform support before inclusion of IPv4LL support >> >> Example: I understand Microsoft includes a system level 'address >> changed' exception which IP services are supposed to catch. This >> is part of their IPv6 developer environment. Microsoft has >> modified their own server software to accomodate address changes >> and has notified their developers to do the same. This could be >> done for IPv4 LL as well. > > it doesn't solve the problem. few application protocols are able to > recover from an unanticipated address change; this essentially requires > that (a) they implement acks at layer 7 (b) that each sender buffer > every > message sent until it receives an ack for that messages (c) that there > be a uniform and stable naming system within the app to take the place > of > IP (and it's not reasonable to assume that DNS is used for this > purpose) This problem of unanticipated address change is not new to the Internet and not specific to IPv4 LL. This has been a reality that we have faced for many years since the days DHCP and PPP have been used by ISPs. The days of static IP address and permanent links are long gone. Now the majority of hosts on the Internet are either mobile or have addresses assigned temporarily. My point is that platforms that support dynamic address assignment with DHCP or PPP should have no problem supporting IPv4 LL. Vincent From owner-zeroconf@merit.edu Fri Dec 6 13:39:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18663 for ; Fri, 6 Dec 2002 13:39:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 95032912E4; Fri, 6 Dec 2002 13:42:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DC9F912E5; Fri, 6 Dec 2002 13:42: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 10235912E4 for ; Fri, 6 Dec 2002 13:42:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id E02A55DF9A; Fri, 6 Dec 2002 13:42:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 922AC5DE6B for ; Fri, 6 Dec 2002 13:42:10 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27445; Fri, 6 Dec 2002 10:42:08 -0800 (PST) Received: from track (track [129.157.142.2]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gB6Ig6l27098; Fri, 6 Dec 2002 19:42:06 +0100 (MET) Date: Fri, 6 Dec 2002 19:43:45 +0100 (MET) From: Erik Guttman X-Sender: erikg@track To: Keith Moore Cc: Erik Guttman , Erik Nordmark , Thomas Narten , zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: <200212061807.gB6I7sj05865@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Fri, 6 Dec 2002, Keith Moore wrote: > > Applications can be made to recover from unanticipated address change > > without protocol level support. > > Wow. that's an extraordinary statement. would you care to explain how > that can be done? A server can bind to its address, accept connections and process requests as it does now. If there is a socket failure of any kind, check to see if the address has changed. If so start reading this paragraph again. A client can bind to its address, make a connection and send a request. If for any reason it fails and the user wants to try again, start reading this paragraph again. This is of course easier if the OS can signal the client or server to change its address. In this case, the client or server knows exactly what to do. Sorry if this is turning into a pedantic thread. > > > this is by far the simplest and most reliable solution. there needs > > > to be a way to do this from the network (at least as much as for any > > > other knob that people want to control via DHCP) and it needs to be > > > part of the standard. > > > > We have been through this in 3 WG last calls and 2 IETF last calls. > > Your opinion is the rough part of the consensus here. > > why do you keep trying to justify a lack of technical soundness > by appeals to consensus? consensus within the working group > does not make up for a failure of the document to meet the > basic standards of 2026. The output of the WG to the IESG is that link-level configuration is not dependent upon DHCP. We make no mention of RFC 2563 intentionally, though a vendor is of course free to implement it. The IESG understands this position by now, and your dissenting view. Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n Solaris Installation and Provisioning phone: +49 6227 356 202 Sun Microsystems cell: +49 172 865 5497 (140 char max) pager: 01728655497@d2-message.de From owner-zeroconf@merit.edu Fri Dec 6 14:03:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19811 for ; Fri, 6 Dec 2002 14:03:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E9C37912E8; Fri, 6 Dec 2002 14:03:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AEE0F912EA; Fri, 6 Dec 2002 14:03: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 63FBF912E8 for ; Fri, 6 Dec 2002 14:03:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F0005DE8B; Fri, 6 Dec 2002 14:03:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 157035DF61 for ; Fri, 6 Dec 2002 14:03:53 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB6J3ij06398; Fri, 6 Dec 2002 14:03:44 -0500 (EST) Message-Id: <200212061903.gB6J3ij06398@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Guttman Cc: Keith Moore , Erik Nordmark , Thomas Narten , zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Fri, 06 Dec 2002 19:43:45 +0100.") Date: Fri, 06 Dec 2002 14:03:44 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > On Fri, 6 Dec 2002, Keith Moore wrote: > > > Applications can be made to recover from unanticipated address change > > > without protocol level support. > > > > Wow. that's an extraordinary statement. would you care to explain how > > that can be done? > > A server can bind to its address, accept connections and process > requests as it does now. If there is a socket failure of any kind, > check to see if the address has changed. If so start reading this > paragraph again. > > A client can bind to its address, make a connection and send a request. > If for any reason it fails and the user wants to try again, start > reading this paragraph again. And how do the client and server know that they're connected to the same parties as before? How do they reconcile the fact that they don't know how much of their previous transmissions got through? How can they efficiently recover from the loss of connection integrity? Say for the sake of example that this is a protocol that transfers potentially-large files over potentially-slow links. Are you really claiming that an acceptable mode of recovery from a broken connection is to reconnect and start transfering those files over again? > This is of course easier if the OS can signal the client or server to > change its address. In this case, the client or server knows exactly > what to do. That's simply false, and frankly I have a hard time believing that you don't have the technical expertise to understand that it's false. > Sorry if this is turning into a pedantic thread. It might be pedantic in tone, but it's not instructive. And you haven't justified your extraordinary statement in the slightest. > > why do you keep trying to justify a lack of technical soundness > > by appeals to consensus? consensus within the working group > > does not make up for a failure of the document to meet the > > basic standards of 2026. > > The output of the WG to the IESG is that link-level configuration > is not dependent upon DHCP. The specific mechanism is not at issue here. The lack of any mechanism to address the problem is. Keith From owner-zeroconf@merit.edu Fri Dec 6 14:18:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20395 for ; Fri, 6 Dec 2002 14:18:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9924F912ED; Fri, 6 Dec 2002 14:20:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6269A912EE; Fri, 6 Dec 2002 14:20:35 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6D3FB912ED for ; Fri, 6 Dec 2002 14:20:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5808C5DE95; Fri, 6 Dec 2002 14:20: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 CD0965DE8B for ; Fri, 6 Dec 2002 14:20: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 MAA09881; Fri, 6 Dec 2002 12:20:32 -0700 (MST) Received: from track (track [129.157.142.2]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gB6JKUl28425; Fri, 6 Dec 2002 20:20:30 +0100 (MET) Date: Fri, 6 Dec 2002 20:22:08 +0100 (MET) From: Erik Guttman X-Sender: erikg@track To: Keith Moore Cc: Erik Guttman , Erik Nordmark , Thomas Narten , zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-Reply-To: <200212061903.gB6J3ij06398@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Fri, 6 Dec 2002, Keith Moore wrote: > > On Fri, 6 Dec 2002, Keith Moore wrote: > > > > Applications can be made to recover from unanticipated address change > > > > without protocol level support. > > > > > > Wow. that's an extraordinary statement. would you care to explain how > > > that can be done? > > > > A server can bind to its address, accept connections and process > > requests as it does now. If there is a socket failure of any kind, > > check to see if the address has changed. If so start reading this > > paragraph again. > > > > A client can bind to its address, make a connection and send a request. > > If for any reason it fails and the user wants to try again, start > > reading this paragraph again. > > And how do the client and server know that they're connected to the same > parties as before? Use a service discovery protocol, or LLMNR or appletalk to find the party we want to talk to, not an address. > How do they reconcile the fact that they don't know > how much of their previous transmissions got through? I did not claim that it was easy to reconstruct session state, or even possible. > How can they efficiently recover from the loss of connection integrity? Leaving efficency aside, most apps work fine if the connection goes down and comes back up. Just start a new session. Services that I am familiar with work fine in these environments, too. Software can obtain new addresses and start over, instead of crashing. Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n Solaris Installation and Provisioning phone: +49 6227 356 202 Sun Microsystems cell: +49 172 865 5497 (140 char max) pager: 01728655497@d2-message.de From owner-zeroconf@merit.edu Fri Dec 6 14:20:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20491 for ; Fri, 6 Dec 2002 14:20:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 180D9912EE; Fri, 6 Dec 2002 14:23:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD94A912EF; Fri, 6 Dec 2002 14:23: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 BB8F0912EE for ; Fri, 6 Dec 2002 14:23:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id A04B45DFA6; Fri, 6 Dec 2002 14:23:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 73CA55DDC8 for ; Fri, 6 Dec 2002 14:23:04 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB6JMxj06469; Fri, 6 Dec 2002 14:23:00 -0500 (EST) Message-Id: <200212061923.gB6JMxj06469@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Vincent Lubet Cc: zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Fri, 06 Dec 2002 10:14:26 PST.") <8E3CD216-0946-11D7-AFE2-0003937AD75C@apple.com> Date: Fri, 06 Dec 2002 14:22:59 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > This problem of unanticipated address change is not new to the Internet > and not specific to IPv4 LL. This has been a reality that we have faced > for many years since the days DHCP and PPP have been used by ISPs. False. Properly-configured DHCP servers do not change addresses at a whim. PPP service can also be set up to use static IP, and users that need that level of stability will buy it. What you are trying to assert is that because some networks have misconfigured their DHCP servers and ISPs tend to provide dynamic IP service by default for dialup connections, that all applications running on all IP networks should already have to deal with transient addresses. That's simply not the case. In fact there are few applications that can operate reliably with transient addresses on both ends. > The days of static IP address and permanent links are long gone. (why do so many people in this group make blatently false statements?) essentially every service on the net relies on static IP and "permanent" links. more and more ISPs are selling static IP addresses and always-on connections for residential and small business use. a few years ago I could find one provider that would sell me service to my home with static IPs at a reasonable price; when I recently started looking for a new ISP I was able to find a few large ISPs who specifically advertised this as a feature - because more and more customers want it. > Now the majority of hosts on the Internet are either mobile or have > addresses assigned temporarily. perhaps, but "the majority of hosts" doesn't indicate anything about the importance of the services that the net can support, nor does it say anything about future trends. > My point is that platforms that support dynamic address assignment with > DHCP or PPP should have no problem supporting IPv4 LL. that conclusion is not warranted. DHCP doesn't break things if configured properly; and when it does break things, there's a way to fix it. dynamic assignment with PPP is generally only an issue when the connection is inherently intermittent (as in a dialup line rather than a nailed-up connection) - but people quite reasonably have lowered expectations in that environment and they don't expect as many applications to work. the same platform that is used with PPP on a dialup line is also used with Ethernet on a nailed-up line, but that doesn't mean that people have the same expectations of each environment. Keith From owner-zeroconf@merit.edu Fri Dec 6 14:22:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20567 for ; Fri, 6 Dec 2002 14:22:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 24B99912EF; Fri, 6 Dec 2002 14:25:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC40B912F0; Fri, 6 Dec 2002 14:25:03 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D057A912EF for ; Fri, 6 Dec 2002 14:25:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id B25A95DFB6; Fri, 6 Dec 2002 14:25:02 -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 34B135DFB1 for ; Fri, 6 Dec 2002 14:25:02 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gB6JP1I04150 for ; Fri, 6 Dec 2002 11:25:01 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Dec 2002 11:24:38 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id gB6JP1911876; Fri, 6 Dec 2002 11:25:01 -0800 (PST) Date: Fri, 6 Dec 2002 11:24:59 -0800 Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Erik Guttman , Erik Nordmark , Thomas Narten , zeroconf@merit.edu To: Keith Moore From: Joshua Graessley In-Reply-To: <200212061903.gB6J3ij06398@astro.cs.utk.edu> Message-Id: <68E3BE86-0950-11D7-AE67-000393760260@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, December 6, 2002, at 11:03 AM, Keith Moore wrote: >> On Fri, 6 Dec 2002, Keith Moore wrote: >>>> Applications can be made to recover from unanticipated address >>>> change >>>> without protocol level support. >>> >>> Wow. that's an extraordinary statement. would you care to explain >>> how >>> that can be done? >> >> A server can bind to its address, accept connections and process >> requests as it does now. If there is a socket failure of any kind, >> check to see if the address has changed. If so start reading this >> paragraph again. >> >> A client can bind to its address, make a connection and send a >> request. >> If for any reason it fails and the user wants to try again, start >> reading this paragraph again. > > And how do the client and server know that they're connected to the > same > parties as before? How do they reconcile the fact that they don't know > how much of their previous transmissions got through? How can they > efficiently recover from the loss of connection integrity? The client can use the same method as used originally to find the other party, whether it be DNS or a service discovery protocol. Any network protocol should be designed in such a way that recovery is possible in case connectivity breaks down. Leased lines go down, modems drop connections, people trip over power cords to switches, equipment fails. An application can not assume that a TCP session will not die, except in very special circumstances. Recovery may not be efficient, the important thing is that it is possible. > Say for the sake of example that this is a protocol that transfers > potentially-large files over potentially-slow links. Are you really > claiming that an acceptable mode of recovery from a broken connection > is to reconnect and start transfering those files over again? This is why FTP and HTTP have added extensions to effectively resume a file transfer. Many people still use modems. Those people lose their connections quite often and they end up with a different address. The applications they use must be able to recover when this happens. Many applications may contend with protocols that don't support an efficient way to recovery, but the application can usually work around this problem. This is not a problem that did not exist before IPv4LL and for the most part, this is not a problem that can only be solved in the protocol. >> This is of course easier if the OS can signal the client or server to >> change its address. In this case, the client or server knows exactly >> what to do. > > That's simply false, and frankly I have a hard time believing that you > don't have the technical expertise to understand that it's false. This is not false. If an application knows when IP addresses changes, such as when I unplug my laptop from the wired network and connect to the wireless one, the application can be much quicker to respond instead of waiting for the TCP session to timeout. -josh From owner-zeroconf@merit.edu Fri Dec 6 14:27:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20764 for ; Fri, 6 Dec 2002 14:27:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4E916912F0; Fri, 6 Dec 2002 14:29:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1FF49912F1; Fri, 6 Dec 2002 14:29: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 F2108912F0 for ; Fri, 6 Dec 2002 14:29:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id D52D15DFC1; Fri, 6 Dec 2002 14:29:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id A650B5DFBF for ; Fri, 6 Dec 2002 14:29:38 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB6JTXj06494; Fri, 6 Dec 2002 14:29:33 -0500 (EST) Message-Id: <200212061929.gB6JTXj06494@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Erik Guttman Cc: Keith Moore , Erik Nordmark , Thomas Narten , zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Fri, 06 Dec 2002 20:22:08 +0100.") Date: Fri, 06 Dec 2002 14:29:33 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > > A server can bind to its address, accept connections and process > > > requests as it does now. If there is a socket failure of any kind, > > > check to see if the address has changed. If so start reading this > > > paragraph again. > > > > > > A client can bind to its address, make a connection and send a request. > > > If for any reason it fails and the user wants to try again, start > > > reading this paragraph again. > > > > And how do the client and server know that they're connected to the same > > parties as before? > > Use a service discovery protocol, or LLMNR or appletalk to find the > party we want to talk to, not an address. a) existing apps don't do this, so you're not talking about existing apps b) LLMNR at least doesn't solve the problem because it suffers from the same naming ambiguities that DNS does. I can't speak for the other protocols. > > How can they efficiently recover from the loss of connection integrity? > > Leaving efficency aside, most apps work fine if the connection goes down > and comes back up. Just start a new session. It's really odd to describe a failure condition as "working fine". If a long email message is sent from point A to point B and the connection dies after the client sends ".CRLF", and before the client receives a 2xx reply, the sender will resend the message and the recipient will get a duplicate. Would you really call that "working fine"? > Services that I am familiar with work fine in these environments, too. it appears you aren't very familiar with many services. > Software can obtain new addresses and start over, instead of crashing. yes they can often start over. some even do. whether this is an acceptable means of recovering is highly dependent on the application. Keith From owner-zeroconf@merit.edu Fri Dec 6 14:35:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21285 for ; Fri, 6 Dec 2002 14:35:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F3B64912F2; Fri, 6 Dec 2002 14:36:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A5FB912F4; Fri, 6 Dec 2002 14:36:35 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7BD82912F2 for ; Fri, 6 Dec 2002 14:36:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F9F45DFA6; Fri, 6 Dec 2002 14:36:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 504005DDC8 for ; Fri, 6 Dec 2002 14:36:27 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB6Ja8j06516; Fri, 6 Dec 2002 14:36:08 -0500 (EST) Message-Id: <200212061936.gB6Ja8j06516@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Keith Moore , Erik Guttman , Erik Nordmark , Thomas Narten , zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Fri, 06 Dec 2002 11:24:59 PST.") <68E3BE86-0950-11D7-AE67-000393760260@apple.com> Date: Fri, 06 Dec 2002 14:36:08 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > The client can use the same method as used originally to find the other > party, whether it be DNS or a service discovery protocol. it doesn't work in general, because it doesn't guarantee that it reached the same party as before. > Any network > protocol should be designed in such a way that recovery is possible in > case connectivity breaks down. it's really kind of you to redefine the Internet architecture for us in one blanket assertion. don't be surprised if not everyone else goes along with it. indeed, IP is designed to allow recovery from those kinds of failures, and higher level apps make use of this. but IP assumes that IP addresses are stable across those failures; that's fundamental to how IP works. what you are asserting it's that it's okay to take away this property of IP and still expect applications to recover. > An application can not assume that a TCP session will not die, except > in very special circumstances. no, but it's reasonable to assume that sessions of a particular duration have a low probability of failure, and in many cases it's reasonable to assume that it's okay to simply accept that failure rate. zeroconf is asserting that it's okay to increase that failure rate, and that any problems it causes by doing so are somebody else's to deal with. > > Say for the sake of example that this is a protocol that transfers > > potentially-large files over potentially-slow links. Are you really > > claiming that an acceptable mode of recovery from a broken connection > > is to reconnect and start transfering those files over again? > > This is why FTP and HTTP have added extensions to effectively resume a > file transfer. right, but what you're saying is that even more apps will need to do this in order to accomodate zeroconf's increased failures. > >> This is of course easier if the OS can signal the client or server to > >> change its address. In this case, the client or server knows exactly > >> what to do. > > > > That's simply false, and frankly I have a hard time believing that you > > don't have the technical expertise to understand that it's false. > > This is not false. If an application knows when IP addresses changes, > such as when I unplug my laptop from the wired network and connect to > the wireless one, the application can be much quicker to respond > instead of waiting for the TCP session to timeout. a quick response isn't very helpful if the app doesn't have an effective means of recovering from the response. Keith From owner-zeroconf@merit.edu Fri Dec 6 16:01:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24217 for ; Fri, 6 Dec 2002 16:01:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DB67A912FD; Fri, 6 Dec 2002 16:03:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 413DE91306; Fri, 6 Dec 2002 16:03: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 DF549912FD for ; Fri, 6 Dec 2002 16:01:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id CA97B5DFC1; Fri, 6 Dec 2002 16:01:24 -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 4DFB05DE84 for ; Fri, 6 Dec 2002 16:01:24 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gB6L1NI26594 for ; Fri, 6 Dec 2002 13:01:23 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 6 Dec 2002 13:01:20 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id gB6L1Kp25677; Fri, 6 Dec 2002 13:01:20 -0800 (PST) Date: Fri, 6 Dec 2002 13:01:19 -0800 Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Erik Guttman , Erik Nordmark , Thomas Narten , zeroconf@merit.edu To: Keith Moore From: Joshua Graessley In-Reply-To: <200212061936.gB6Ja8j06516@astro.cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, December 6, 2002, at 11:36 AM, Keith Moore wrote: >> Any network >> protocol should be designed in such a way that recovery is possible in >> case connectivity breaks down. > > it's really kind of you to redefine the Internet architecture for us > in one blanket assertion. don't be surprised if not everyone else > goes along with it. > > indeed, IP is designed to allow recovery from those kinds of failures, > and higher level apps make use of this. but IP assumes that IP > addresses are stable across those failures; that's fundamental to > how IP works. what you are asserting it's that it's okay to take away > this property of IP and still expect applications to recover. I'm not redefining anything, just observing that application and protocol developers have to contend with failure cases already. Modem connections are a common example of this. Anyone that is developing a protocol that may be used over a modem link should consider the possibility that the link may go down and a new address may be acquired. Yes, some people pay more for static IP addresses with dial-up. If you're designing a protocol for general use, you have to accept that not everyone does pay for a static address so you may not be able to rely on such a luxury. >> An application can not assume that a TCP session will not die, except >> in very special circumstances. > > no, but it's reasonable to assume that sessions of a particular > duration > have a low probability of failure, and in many cases it's reasonable to > assume that it's okay to simply accept that failure rate. zeroconf > is asserting that it's okay to increase that failure rate, and that > any problems it causes by doing so are somebody else's to deal with. There is no evidence that link-local addresses increase the failure rate. AppleTalk uses a similar addressing scheme. AppleTalk addresses did not change often, only when conflicts arose. If the nodes on the network properly implement the protocol and the number of nodes does not exceed the number of addresses available, then the IPv4LL addresses will probably be very stable. Others have pointed out that DHCP can lead to addresses that change often. You have argued that only happens when something is misconfigured or not operating correctly. In the case of IPv4LL addresses, the same applies, only it there isn't any configuration (other than the number of nodes on a link), so IPv4LLs will only be unstable when the nodes are not operating correctly. >>> Say for the sake of example that this is a protocol that transfers >>> potentially-large files over potentially-slow links. Are you really >>> claiming that an acceptable mode of recovery from a broken connection >>> is to reconnect and start transfering those files over again? >> >> This is why FTP and HTTP have added extensions to effectively resume a >> file transfer. > > right, but what you're saying is that even more apps will need to do > this > in order to accomodate zeroconf's increased failures. Why do you think that IPv4 will increase the number of failures? It's not like the spec requires the nodes to change addresses every 2 minutes. The address only needs to change when there is a conflict. > a quick response isn't very helpful if the app doesn't have an > effective > means of recovering from the response. Your assertion that applications are incapable of dealing with failures on the network is one that I do not agree with. Your assertion that IPv4LL addresses are so unstable they will increase the incident of failures on the network is also something I disagree with. -josh From owner-zeroconf@merit.edu Fri Dec 6 16:55:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26430 for ; Fri, 6 Dec 2002 16:55:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 656E59130B; Fri, 6 Dec 2002 16:55:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2546E9132F; Fri, 6 Dec 2002 16:55: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 06AFE9130B for ; Fri, 6 Dec 2002 16:54:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id E88F35DFAB; Fri, 6 Dec 2002 16:54: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 6B1565DEED for ; Fri, 6 Dec 2002 16:54:00 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA25571 for ; Fri, 6 Dec 2002 16:53:59 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA23845 for ; Fri, 6 Dec 2002 16:48:34 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA07116 for ; Fri, 6 Dec 2002 16:48:32 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 06 Dec 2002 15:26:34 -0500 Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212061903.gB6J3ij06398@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/06/2002 14:03, "Keith Moore" wrote: >> A client can bind to its address, make a connection and send a request. >> If for any reason it fails and the user wants to try again, start >> reading this paragraph again. > > And how do the client and server know that they're connected to the same > parties as before? How do you know this now? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Dec 6 17:11:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27106 for ; Fri, 6 Dec 2002 17:11:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9956891307; Fri, 6 Dec 2002 17:13:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6682791308; Fri, 6 Dec 2002 17:13: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 5F0A691307 for ; Fri, 6 Dec 2002 17:13:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 434915DFAB; Fri, 6 Dec 2002 17:13:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id BB6AF5DE95 for ; Fri, 6 Dec 2002 17:13:41 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gB6MDfI12488 for ; Fri, 6 Dec 2002 14:13:41 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Dec 2002 14:13:18 -0800 Received: from apple.com (lubet1.apple.com [17.202.40.146]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id gB6MDe914952; Fri, 6 Dec 2002 14:13:40 -0800 (PST) Date: Fri, 6 Dec 2002 14:13:50 -0800 Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: zeroconf@merit.edu To: Keith Moore From: Vincent Lubet In-Reply-To: <200212061923.gB6JMxj06469@astro.cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, December 6, 2002, at 11:22 AM, Keith Moore wrote: > (why do so many people in this group make blatently false statements?) Why are you making such an offensive statement and not concentrate on the technical merit of the commennt? Vincent From owner-zeroconf@merit.edu Fri Dec 6 20:01:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03918 for ; Fri, 6 Dec 2002 20:01:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3E51391221; Fri, 6 Dec 2002 20:04:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 021849130D; Fri, 6 Dec 2002 20:04: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 5F15991221 for ; Fri, 6 Dec 2002 20:04:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 42DBB5DFD8; Fri, 6 Dec 2002 20:04:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id CC00B5DFCB for ; Fri, 6 Dec 2002 20:04:10 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB713xj07193; Fri, 6 Dec 2002 20:03:59 -0500 (EST) Message-Id: <200212070103.gB713xj07193@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Keith Moore , Erik Guttman , Erik Nordmark , Thomas Narten , zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Fri, 06 Dec 2002 13:01:19 PST.") Date: Fri, 06 Dec 2002 20:03:59 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > it's really kind of you to redefine the Internet architecture for us > > in one blanket assertion. don't be surprised if not everyone else > > goes along with it. > > > > indeed, IP is designed to allow recovery from those kinds of failures, > > and higher level apps make use of this. but IP assumes that IP > > addresses are stable across those failures; that's fundamental to > > how IP works. what you are asserting it's that it's okay to take away > > this property of IP and still expect applications to recover. > > I'm not redefining anything, just observing that application and > protocol developers have to contend with failure cases already. I think you're exaggerating the degree to which this happens. Most apps that I'm aware of do not recover from these failures. People are always challenging me for real world examples - perhaps you'd like to name some apps that transparently recover from address changes? (SMTP qualifies IMHO, so there's at least one) > Modem connections are a common example of this. Anyone that is developing a > protocol that may be used over a modem link should consider the > possibility that the link may go down and a new address may be > acquired. Based on what assumption? You can't rely on the DNS name being bound to the thing you're talking to; a good deal of the time the DNS name is either ambiguous or it's bound to the address rather than to the host. > If you're designing a protocol for general use, you have to > accept that not everyone does pay for a static address so you may not > be able to rely on such a luxury. Yes, sometimes this happens. What this tends to mean is that these protocols need their own network infrastructure in the form of proxies and/or dedicated central servers, and the clients are expected to connect "out" to those central servers. But not all protocols can be made to work this way, at least not efficiently; and not all networks constrain protocols to work this way. So you do have protocols that will only run in parts of the network that provide stable addresses. But LL doesn't just cause problems for networks that are running misconfigured DHCP servers and users with temporary connections and dynamic IP assignment. It will also cause problems for those networks that have well-behaved DHCP servers and stable IP addresses. > > no, but it's reasonable to assume that sessions of a particular > > duration > > have a low probability of failure, and in many cases it's reasonable to > > assume that it's okay to simply accept that failure rate. zeroconf > > is asserting that it's okay to increase that failure rate, and that > > any problems it causes by doing so are somebody else's to deal with. > > There is no evidence that link-local addresses increase the failure > rate. actually it would be fairly easy to model the change rate of LL addresses - you could plot it on a graph of average # of hosts on one axis and churn rate (frequency at which a new host joins the network) on the other, and the plots would be lines showing the set of points on that graph with a particular mean time between address change. this would be a useful exercise. I'll see if I can find time to work it up, or perhaps someone else can do it. > Others have pointed out that DHCP can > lead to addresses that change often. You have argued that only happens > when something is misconfigured or not operating correctly. In the case > of IPv4LL addresses, the same applies, only it there isn't any > configuration (other than the number of nodes on a link), so IPv4LLs > will only be unstable when the nodes are not operating correctly. I believe v4LLs will be unstable under certain combinations of network population and churn. But I suspect we would agree that real numbers would be better than intuitive speculation. Keith From owner-zeroconf@merit.edu Fri Dec 6 20:11:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04171 for ; Fri, 6 Dec 2002 20:11:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1425391248; Fri, 6 Dec 2002 20:14:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7F099130D; Fri, 6 Dec 2002 20:14: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 C1C7C91248 for ; Fri, 6 Dec 2002 20:14:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD63F5DFD8; Fri, 6 Dec 2002 20:14:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 504C85DDD8 for ; Fri, 6 Dec 2002 20:14:26 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB71EMj07253; Fri, 6 Dec 2002 20:14:22 -0500 (EST) Message-Id: <200212070114.gB71EMj07253@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Vincent Lubet Cc: Keith Moore , zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Fri, 06 Dec 2002 14:13:50 PST.") Date: Fri, 06 Dec 2002 20:14:22 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > (why do so many people in this group make blatently false statements?) > > Why are you making such an offensive statement and not concentrate on > the technical merit of the commennt? Because I can't see the technical merit in the statement. In most of the technical discussions in which I participate, when somebody makes a statement that sounds bizarre or indefensible, usually I can at least guess at an interpretation of a statement that somebody else said, that makes sense according to my own experience. That's a lot rarer in this working group. In this discussion there are a large number of statements for which the best (and most charitable) interpretation I can come up with is "this person is in serious denial". and it's hard to not assume worse. I get the strong impression that people are assuming that this stuff will only affect small networks and corner cases, and that it will only be used with a dozen or so applications with which most people are familiar, so there's no need to think about how it will work on large networks or with a wide variety of apps. But despite the fact that we know it will break some networks and some apps, people are still insisting that it's okay for LL to be on every host on the network and that we don't need a way to turn it off. Is there a better explanation of this than some combination of "denial" and "irresponsibility"? Keith From owner-zeroconf@merit.edu Fri Dec 6 20:16:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04327 for ; Fri, 6 Dec 2002 20:16:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5AE7091310; Fri, 6 Dec 2002 20:19:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A32791311; Fri, 6 Dec 2002 20:19: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 5B54591310 for ; Fri, 6 Dec 2002 20:17:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3717C5DFD8; Fri, 6 Dec 2002 20:17:31 -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 C1A1B5DFA7 for ; Fri, 6 Dec 2002 20:17:30 -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 UAA20357 for ; Fri, 6 Dec 2002 20:17:30 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA10649 for ; Fri, 6 Dec 2002 20:17:29 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id UAA18551 for ; Fri, 6 Dec 2002 20:17:29 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 06 Dec 2002 20:17:28 -0500 Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212070103.gB713xj07193@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/06/2002 20:03, "Keith Moore" wrote: >> I'm not redefining anything, just observing that application and >> protocol developers have to contend with failure cases already. > > I think you're exaggerating the degree to which this happens. > Most apps that I'm aware of do not recover from these failures. > People are always challenging me for real world examples - > perhaps you'd like to name some apps that transparently recover > from address changes? (SMTP qualifies IMHO, so there's at least one) Anything with a stable name using DyDNS. > >> Modem connections are a common example of this. Anyone that is developing a >> protocol that may be used over a modem link should consider the >> possibility that the link may go down and a new address may be >> acquired. > > Based on what assumption? You can't rely on the DNS name being bound > to the thing you're talking to; a good deal of the time the DNS name > is either ambiguous or it's bound to the address rather than to the host. Um...based on the reality that Modem connections are unstable, and drop for all sorts of reasons, including call - waiting. So modem connections are unreliable for anything but *very* small transfers, and the *vast* majority of PPP users *don't* have static IP addresses. That problem is real, and yet it gets handled every day. Kind of detracts from "The sky will fall if your address changes" theory. People with laptops and wireless networks with DHCP have their address change regularly. Mine does 5-6 times a day at MIT. Yet everything still works. > >> If you're designing a protocol for general use, you have to >> accept that not everyone does pay for a static address so you may not >> be able to rely on such a luxury. > > Yes, sometimes this happens. What this tends to mean is that these > protocols need their own network infrastructure in the form of > proxies and/or dedicated central servers, and the clients are expected > to connect "out" to those central servers. > > But not all protocols can be made to work this way, at least not > efficiently; and not all networks constrain protocols to work > this way. So you do have protocols that will only run in parts > of the network that provide stable addresses. > > But LL doesn't just cause problems for networks that are running > misconfigured DHCP servers and users with temporary connections and > dynamic IP assignment. It will also cause problems for those networks > that have well-behaved DHCP servers and stable IP addresses. Nonsense. LL and Rendezvous are in use *now* at MIT, every day, and it causes zero problems, and the Netops folks there are *very* fast to clamp down on problems. Not only that, we use a combination of static IPs, (Ethernet) and DHCP (Wireless), yet no problems with Zeroconf Implementations. So real world evidence indicates that that any problems are quite minimal. Unnoticeable even. >> There is no evidence that link-local addresses increase the failure >> rate. > > actually it would be fairly easy to model the change rate of LL addresses - > you could plot it on a graph of average # of hosts on one axis and churn > rate (frequency at which a new host joins the network) on the other, and > the plots would be lines showing the set of points on that graph with a > particular mean time between address change. > > this would be a useful exercise. I'll see if I can find time to work it up, > or perhaps someone else can do it. Why yes...how about some real data. Because according to the spec, the only time an existing address in use should change is when it has to defend against another node trying to claim that address and the other node won't change it's address. This is *not* going to happen often, unless you are regularly joining subnets, or running defective equipment. > >> Others have pointed out that DHCP can >> lead to addresses that change often. You have argued that only happens >> when something is misconfigured or not operating correctly. In the case >> of IPv4LL addresses, the same applies, only it there isn't any >> configuration (other than the number of nodes on a link), so IPv4LLs >> will only be unstable when the nodes are not operating correctly. > > I believe v4LLs will be unstable under certain combinations of network > population and churn. But I suspect we would agree that real numbers > would be better than intuitive speculation. Um...yes. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Dec 6 20:19:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04378 for ; Fri, 6 Dec 2002 20:19:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF42091311; Fri, 6 Dec 2002 20:20:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C29891317; Fri, 6 Dec 2002 20:20: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 E8E9F91311 for ; Fri, 6 Dec 2002 20:20:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id CFDF75DEEF; Fri, 6 Dec 2002 20:20:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 675FB5DDD8 for ; Fri, 6 Dec 2002 20:20:31 -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 UAA04353 for ; Fri, 6 Dec 2002 20:20:30 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id UAA10756 for ; Fri, 6 Dec 2002 20:20:30 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id UAA18801 for ; Fri, 6 Dec 2002 20:20:29 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 06 Dec 2002 20:20:28 -0500 Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212070114.gB71EMj07253@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/06/2002 20:14, "Keith Moore" wrote: >>> (why do so many people in this group make blatently false statements?) >> >> Why are you making such an offensive statement and not concentrate on >> the technical merit of the commennt? > > Because I can't see the technical merit in the statement. > > In most of the technical discussions in which I participate, when somebody > makes a statement that sounds bizarre or indefensible, usually I can at > least guess at an interpretation of a statement that somebody else said, > that makes sense according to my own experience. > > That's a lot rarer in this working group. In this discussion there > are a large number of statements for which the best (and most > charitable) interpretation I can come up with is "this person is in > serious denial". and it's hard to not assume worse. > > I get the strong impression that people are assuming that this stuff > will only affect small networks and corner cases, and that it will only > be used with a dozen or so applications with which most people are > familiar, so there's no need to think about how it will work on large > networks or with a wide variety of apps. But despite the fact that > we know it will break some networks and some apps, people are still > insisting that it's okay for LL to be on every host on the network > and that we don't need a way to turn it off. > > Is there a better explanation of this than some combination of > "denial" and "irresponsibility"? I see no examples of deliberate attempts to lie by anyone. (Let's be blunt...blatantly false equals lying, and that's what you are, by that statement, accusing people of.) I see people *disagreeing* with your baseless, (in the sense of having *no* supporting data) conclusions of massive harm to existing infrastructure, and my real world experience indicates that your conclusions are at best, exaggerated. Just because someone disagrees with your conclusions and views does not make them a liar. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Dec 6 21:53:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06475 for ; Fri, 6 Dec 2002 21:53:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD2089124B; Fri, 6 Dec 2002 21:55:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8C5F91249; Fri, 6 Dec 2002 21:55: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 2183D9124C for ; Fri, 6 Dec 2002 21:55:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 079205DDD9; Fri, 6 Dec 2002 21:55:55 -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 7FEAA5DDD8 for ; Fri, 6 Dec 2002 21:55:54 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gB72tsI00244 for ; Fri, 6 Dec 2002 18:55:54 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Dec 2002 18:55:31 -0800 Received: from apple.com ([17.112.76.134]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id gB72tqs28409; Fri, 6 Dec 2002 18:55:52 -0800 (PST) Date: Fri, 6 Dec 2002 18:56:02 -0800 Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: zeroconf@merit.edu To: Keith Moore From: Vincent Lubet In-Reply-To: <200212061923.gB6JMxj06469@astro.cs.utk.edu> Message-Id: <6BE4AD36-098F-11D7-AFE2-0003937AD75C@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, December 6, 2002, at 11:22 AM, Keith Moore wrote: > What you are trying to assert is that because some networks have > misconfigured their DHCP servers and ISPs tend to provide dynamic IP > service by default for dialup connections, that all applications > running on all IP networks should already have to deal with transient > addresses. That's simply not the case. In fact there are few > applications that can operate reliably with transient addresses on > both ends. Applications and protocols should be designed to adapt to change and be able to deal with unlikely events (see RFC 1122 and 1123). IP address change is such a low-probability events. This does not mean that the applications are not be affected by change of IP address, rather that they have to be prepared to such events. It's useful to remember that change of IP addresses is a low propability. This does not constantly happen from datagram to datagram. > more and more ISPs are selling static IP addresses and always-on > connections > for residential and small business use. a few years ago I could find > one > provider that would sell me service to my home with static IPs at a > reasonable price; when I recently started looking for a new ISP I was > able to find a few large ISPs who specifically advertised this as a > feature - > because more and more customers want it. A lot of people pay for Dynamic DNS services so they are not tied to a particular IP address. This is especially valuable because many applications use the domain names to identify peers and not IP address. > perhaps, but "the majority of hosts" doesn't indicate anything about > the importance of the services that the net can support, nor does it > say anything about future trends. We should not limit our reasoning to servers that can afford a static IP address. If the Internet was not limited by NAT, more hosts would be directly reachable and those hosts would make their services available. What is important for those hosts with transient address is the services they make available can be reached. This is easily done by using DNS and very difficult with IP address -- see below. > that conclusion is not warranted. DHCP doesn't break things if > configured > properly; and when it does break things, there's a way to fix it. > dynamic assignment with PPP is generally only an issue when the > connection > is inherently intermittent (as in a dialup line rather than a nailed-up > connection) - but people quite reasonably have lowered expectations in > that > environment and they don't expect as many applications to work. > > the same platform that is used with PPP on a dialup line is also used > with Ethernet on a nailed-up line, but that doesn't mean that people > have > the same expectations of each environment. The problem is an IPv4 address does not identify a host on the Internet -- let's hope we will get provider independent IPv6 addresses but I won't hold me breath for it. With IPv4, the address belongs to a network owned by an ISP, a company, an Internet cafe or other organization. Even if DHCP is "properly configured" in each of the many networks the system gets attached to, a mobile system gets a different IP address from the network it is attached to. This means the IP address is not a constant that a system can rely to make its services available. The DNS is a much better anchor to make services available. Vincent From owner-zeroconf@merit.edu Sat Dec 7 00:13:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09431 for ; Sat, 7 Dec 2002 00:13:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7854A9124D; Sat, 7 Dec 2002 00:15:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A01E9124E; Sat, 7 Dec 2002 00:15: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 4C3499124D for ; Sat, 7 Dec 2002 00:15:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 26BCE5DE25; Sat, 7 Dec 2002 00:15:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta04ps.bigpond.com (mta04ps.bigpond.com [144.135.25.136]) by segue.merit.edu (Postfix) with ESMTP id 61D0A5DE08 for ; Sat, 7 Dec 2002 00:15:32 -0500 (EST) Received: from pc-00206 ([144.135.25.72]) by mta04ps.bigpond.com (Netscape Messaging Server 4.15 mta04ps Jul 16 2002 22:47:55) with SMTP id H6QH9T00.DYU; Sat, 7 Dec 2002 15:15:29 +1000 Received: from CPE-203-51-24-113.nsw.bigpond.net.au ([203.51.24.113]) by PSMAM02.mailsvc.email.bigpond.com(MailRouter V3.0n 80/6095953); 07 Dec 2002 15:15:29 From: Brad Hards To: John Schnizlein , "Zero Configuration WG" Subject: Re: TTL=255 on xmit, no check on receipt please Date: Sat, 7 Dec 2002 16:04:11 +1100 User-Agent: KMail/1.4.5 References: <4.3.2.7.2.20021206065421.01ed32c8@wells.cisco.com> In-Reply-To: <4.3.2.7.2.20021206065421.01ed32c8@wells.cisco.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200212071604.11809.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 6 Dec 2002 23:17, John Schnizlein wrote: > Could we have a simple summary of the reasons that the intuitive > solution of TTL=1 to keep link-local (LL) traffic from being forwarded > off the link is bad, please? There are two problems - keeping LL traffic from being forwarded, and telling if the datagram you have came from the local link. TTL=1 mostly solves the first problem. TTL=1 solves the second problem, only if _every_ machine implements it. Setting 255, and checking 255 solves the second problem. You might discard packets from the local link. Setting 255 also ensures compatibility with one implementation (MacOS 10.2) that is shipping. The concept of local link is inherently ambiguous, because people have all kinds of weird bridge-filtering. LLv4 only works reliably if the ARP packets and every packet with a 169.254/16 address reach the same machines. Don't forget that setting 128 or 255 clearly doesn't cause problems in reality, because there are a _lot_ of deployed examples. Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE98YFLW6pHgIdAuOMRAusbAKDEkCMaXwFE4JQedDmaDJ9VvTkJ5gCgkYEh 1o/UpzLC7/mwJejhSjGBJ3M= =mt6d -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Sat Dec 7 00:46:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10171 for ; Sat, 7 Dec 2002 00:46:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7CC5B9124E; Sat, 7 Dec 2002 00:49:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E74891317; Sat, 7 Dec 2002 00:49: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 363129124E for ; Sat, 7 Dec 2002 00:48:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id BEEF45DE41; Sat, 7 Dec 2002 00:48:22 -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 43FDF5DE3B for ; Sat, 7 Dec 2002 00:48:22 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gB75mLI16800 for ; Fri, 6 Dec 2002 21:48:21 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 6 Dec 2002 21:47:58 -0800 Received: from apple.com ([17.112.76.134]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id gB75mLf28372; Fri, 6 Dec 2002 21:48:21 -0800 (PST) Date: Fri, 6 Dec 2002 21:48:30 -0800 Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: zeroconf@merit.edu To: Keith Moore From: Vincent Lubet In-Reply-To: <200212070114.gB71EMj07253@astro.cs.utk.edu> Message-Id: <83E13374-09A7-11D7-AFE2-0003937AD75C@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, December 6, 2002, at 05:14 PM, Keith Moore wrote: > Because I can't see the technical merit in the statement. > > In most of the technical discussions in which I participate, when > somebody > makes a statement that sounds bizarre or indefensible, usually I can at > least guess at an interpretation of a statement that somebody else > said, > that makes sense according to my own experience. > > That's a lot rarer in this working group. In this discussion there > are a large number of statements for which the best (and most > charitable) interpretation I can come up with is "this person is in > serious denial". and it's hard to not assume worse. > > I get the strong impression that people are assuming that this stuff > will only affect small networks and corner cases, and that it will only > be used with a dozen or so applications with which most people are > familiar, so there's no need to think about how it will work on large > networks or with a wide variety of apps. But despite the fact that > we know it will break some networks and some apps, people are still > insisting that it's okay for LL to be on every host on the network > and that we don't need a way to turn it off. > > Is there a better explanation of this than some combination of > "denial" and "irresponsibility"? Yes, you should pay more consideration and attention to other people's point of view. The point I was making is that many platforms already cope with change of IP addresses so IPv4 LL does add any special burden. Vincent From owner-zeroconf@merit.edu Sat Dec 7 02:14:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20752 for ; Sat, 7 Dec 2002 02:14:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E9B2491220; Sat, 7 Dec 2002 02:16:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B583291227; Sat, 7 Dec 2002 02:16:45 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6AAB691220 for ; Sat, 7 Dec 2002 02:16:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 52C175DDEB; Sat, 7 Dec 2002 02:16:44 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id E21C45DD8F for ; Sat, 7 Dec 2002 02:16:43 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB77Gej08926; Sat, 7 Dec 2002 02:16:40 -0500 (EST) Message-Id: <200212070716.gB77Gej08926@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Vincent Lubet Cc: Keith Moore , zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Fri, 06 Dec 2002 18:56:02 PST.") <6BE4AD36-098F-11D7-AFE2-0003937AD75C@apple.com> Date: Sat, 07 Dec 2002 02:16:40 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > What you are trying to assert is that because some networks have > > misconfigured their DHCP servers and ISPs tend to provide dynamic IP > > service by default for dialup connections, that all applications > > running on all IP networks should already have to deal with transient > > addresses. That's simply not the case. In fact there are few > > applications that can operate reliably with transient addresses on > > both ends. > > Applications and protocols should be designed to adapt to change and be > able to deal with unlikely events (see RFC 1122 and 1123). Please cite specific sections. I don't find this in 1123 at all; and 1122 is not about applications. And frankly I don't believe that address change was ever anticipated as an event that apps should deal with at the time 1123 was written. The original purpose of the IP address was to provide an identifier for hosts which was stable across changes in the network topology. The idea that IP addresses could change without the underlying topology changing was never part of the architecture; it emerged as an unintended consequence of DHCP. > This does not mean that the applications are not be affected by change > of IP address, rather that they have to be prepared to such events. What you suggest is technically unsound, and neither I nor anyone else recognizes your authority or the authority of this WG to change the Internet architecture. > A lot of people pay for Dynamic DNS services so they are not tied to a > particular IP address. What kind of kool-aid are you drinking? The only people who claim this is a feature are marketing people - i.e. people who tell lies for a living. Even the casual users I know get pissed when their modem connection breaks, the computer redials, and their applications either fail (conferencing, games, telephony) or have to be restarted (file transfers). > This is especially valuable because many > applications use the domain names to identify peers and not IP address. Some apps use domain names; but these are not reliable peer identifiers. They work for some use cases and with some configurations, not in general. > > perhaps, but "the majority of hosts" doesn't indicate anything about > > the importance of the services that the net can support, nor does it > > say anything about future trends. > > We should not limit our reasoning to servers that can afford a static > IP address. And you should not pretend that all networks suffer the same limitations as those which have misconfigured DHCP servers or dynamic IP assignment, nor should you justify imposing similar limitations on every network that has a host which supports LL. > If the Internet was not limited by NAT, more hosts would be directly > reachable and those hosts would make their services available. What is > important for those hosts with transient address is the services they > make available can be reached. This is easily done by using DNS and > very difficult with IP address -- see below. This working group is supposed to be solving problems related to ad hoc networks - trying to make hosts with transient addresses accessible from elsewhere on the net is not in scope. > The problem is an IPv4 address does not identify a host on the Internet > -- let's hope we will get provider independent IPv6 addresses but I > won't hold me breath for it. With IPv4, the address belongs to a > network owned by an ISP, a company, an Internet cafe or other > organization. In practice a certain level of stability of the address-to-host binding is always needed, because neither TCP or apps can deal with frequent changes in those bindings. Furthermore, we don't have a stable and unambiguous identifier that can reliably replace an IP address. At least an IP address has a consistent meaning as an identifier for a location in the network topology - DNS names can name almost anything. > Even if DHCP is "properly configured" in each of the many networks the > system gets attached to, a mobile system gets a different IP address > from the network it is attached to. > > This means the IP address is not a constant that a system can rely to > make its services available. The DNS is a much better anchor to make > services available. DNS works better for some cases, worse for others. It's not suitable for all apps - it's too unreliable, too slow, and the names are too ambiguous. Keith From owner-zeroconf@merit.edu Sat Dec 7 02:23:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21632 for ; Sat, 7 Dec 2002 02:23:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C89B691227; Sat, 7 Dec 2002 02:25:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 941FC91229; Sat, 7 Dec 2002 02:25: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 4D98A91227 for ; Sat, 7 Dec 2002 02:25:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 347F45DE44; Sat, 7 Dec 2002 02:25:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id CC0805DE03 for ; Sat, 7 Dec 2002 02:25:45 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB77Pdj09037; Sat, 7 Dec 2002 02:25:39 -0500 (EST) Message-Id: <200212070725.gB77Pdj09037@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Vincent Lubet Cc: Keith Moore , zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Fri, 06 Dec 2002 21:48:30 PST.") <83E13374-09A7-11D7-AFE2-0003937AD75C@apple.com> Date: Sat, 07 Dec 2002 02:25:39 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > Is there a better explanation of this than some combination of > > "denial" and "irresponsibility"? > > Yes, you should pay more consideration and attention to other people's > point of view. I've tried really hard to do so. The problem is that those people don't give a damn about how many problems they are causing for others. If apps break because of link locals, that's somebody else's problem. Those apps will just have to adapt because we're going to insist that this feature be imposed on all networks - not because it's technically sound to do so, just because we think it's a good idea, and because we're already shipping it in product. Never mind that there are less disruptive ways of solving the problem that this group was chartered to solve - we've got our own agenda here. If this causes operational problems for networks or security problems for hosts, again, that's not our problem. Screw everyone else, and we know what's good for everyone anyway. Yes, I've considered this point of view, and I don't believe it deserves a shred of respect. > The point I was making is that many platforms already cope with change > of IP addresses so IPv4 LL does add any special burden. And screw everything for which it does add a special burden - including large numbers of apps that don't run on dysfunctional networks. Keith From owner-zeroconf@merit.edu Sat Dec 7 02:31:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21820 for ; Sat, 7 Dec 2002 02:31:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 29D4891229; Sat, 7 Dec 2002 02:34:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E10991318; Sat, 7 Dec 2002 02:33:59 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 29D5D91229 for ; Sat, 7 Dec 2002 02:32:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id F02225DE55; Sat, 7 Dec 2002 02:32:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id EAEF75DE02 for ; Sat, 7 Dec 2002 02:32:06 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB77Vtj09198; Sat, 7 Dec 2002 02:31:55 -0500 (EST) Message-Id: <200212070731.gB77Vtj09198@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brad Hards Cc: John Schnizlein , "Zero Configuration WG" Subject: Re: TTL=255 on xmit, no check on receipt please In-reply-to: (Your message of "Sat, 07 Dec 2002 16:04:11 +1100.") <200212071604.11809.bhards@bigpond.net.au> Date: Sat, 07 Dec 2002 02:31:55 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > There are two problems - keeping LL traffic from being forwarded, and telling > if the datagram you have came from the local link. please explain again why the app needs to know if the datagram came from the local link? how does this relate to the group's charter? From owner-zeroconf@merit.edu Sat Dec 7 02:39:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22025 for ; Sat, 7 Dec 2002 02:39:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EFA4A91317; Sat, 7 Dec 2002 02:42:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAC9591318; Sat, 7 Dec 2002 02:42: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 B34A991317 for ; Sat, 7 Dec 2002 02:42:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B9865DE55; Sat, 7 Dec 2002 02:42:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta03ps.bigpond.com (mta03ps.bigpond.com [144.135.25.135]) by segue.merit.edu (Postfix) with ESMTP id 34D795DE02 for ; Sat, 7 Dec 2002 02:42:37 -0500 (EST) Received: from pc-00206 ([144.135.25.78]) by mta03ps.bigpond.com (Netscape Messaging Server 4.15 mta03ps Jul 16 2002 22:47:55) with SMTP id H6QO2Y00.ELR; Sat, 7 Dec 2002 17:42:34 +1000 Received: from CPE-203-51-24-113.nsw.bigpond.net.au ([203.51.24.113]) by PSMAM04.mailsvc.email.bigpond.com(MailRouter V3.0n 98/6216072); 07 Dec 2002 17:42:34 From: Brad Hards To: Keith Moore Subject: Re: TTL=255 on xmit, no check on receipt please Date: Sat, 7 Dec 2002 18:31:09 +1100 User-Agent: KMail/1.4.5 Cc: John Schnizlein , "Zero Configuration WG" References: <200212070731.gB77Vtj09198@astro.cs.utk.edu> In-Reply-To: <200212070731.gB77Vtj09198@astro.cs.utk.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200212071831.09307.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 7 Dec 2002 18:31, Keith Moore wrote: > > There are two problems - keeping LL traffic from being forwarded, and > > telling if the datagram you have came from the local link. > > please explain again why the app needs to know if the datagram came from > the local link? how does this relate to the group's charter? I never mentioned "app", so you can relax - I'm not intruding on your turf :-) This is not to say that some applications may not need to know if the IP is link-local, but I was working on the network layer dropping packets, based on some local policy decision. As for charter, I won't buy into any more pointless arguments. Brad BTW: I'm ready to implement whatever the RFC (if it ever gets released) says for Linux - the technical stuff for TTL is trivial for setting, and I'm happy to add checking for TTL. - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE98aO9W6pHgIdAuOMRAgK8AJ9B+B8RYQSJg5I0kah8lhv4JsKAoACdGN/b UsQmZD/3L8ImFM5jg3whycU= =iS1u -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Sat Dec 7 03:07:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22562 for ; Sat, 7 Dec 2002 03:07:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 882A39131C; Sat, 7 Dec 2002 03:09:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E9AC91318; Sat, 7 Dec 2002 03:09: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 5F15B91318 for ; Sat, 7 Dec 2002 03:04:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 252E45DE53; Sat, 7 Dec 2002 03:04:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id BBD495DE02 for ; Sat, 7 Dec 2002 03:04:08 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB7843j09298; Sat, 7 Dec 2002 03:04:03 -0500 (EST) Message-Id: <200212070804.gB7843j09298@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brad Hards Cc: Keith Moore , John Schnizlein , "Zero Configuration WG" Subject: Re: TTL=255 on xmit, no check on receipt please In-reply-to: (Your message of "Sat, 07 Dec 2002 18:31:09 +1100.") <200212071831.09307.bhards@bigpond.net.au> Date: Sat, 07 Dec 2002 03:04:03 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > On Sat, 7 Dec 2002 18:31, Keith Moore wrote: > > > There are two problems - keeping LL traffic from being forwarded, and > > > telling if the datagram you have came from the local link. > > > > please explain again why the app needs to know if the datagram came from > > the local link? how does this relate to the group's charter? > I never mentioned "app", so you can relax - I'm not intruding on your turf :-) I'm not concerned about turf. Let me phrase the question differently - why is it important that the destination host enforce the restriction that the packet came from the local link? > BTW: I'm ready to implement whatever the RFC (if it ever gets released) says > for Linux Linux might be better off without it. Keith From owner-zeroconf@merit.edu Sat Dec 7 03:50:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23411 for ; Sat, 7 Dec 2002 03:50:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5600591318; Sat, 7 Dec 2002 03:52:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 252D89131A; Sat, 7 Dec 2002 03:52: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 AE64B91318 for ; Sat, 7 Dec 2002 03:52:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8C6D15DDCB; Sat, 7 Dec 2002 03:52:44 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta02bw.bigpond.com (unknown [144.135.24.138]) by segue.merit.edu (Postfix) with ESMTP id 217695DD96 for ; Sat, 7 Dec 2002 03:52:43 -0500 (EST) Received: from pc-00206 ([144.135.24.75]) by mta02bw.bigpond.com (Netscape Messaging Server 4.15 mta02bw Jul 16 2002 22:47:55) with SMTP id H6QRBT00.BZC; Sat, 7 Dec 2002 18:52:41 +1000 Received: from CPE-203-51-24-113.nsw.bigpond.net.au ([203.51.24.113]) by bwmam03.mailsvc.email.bigpond.com(MailRouter V3.0n 26/27156344); 07 Dec 2002 18:52:41 From: Brad Hards To: Keith Moore Subject: Re: TTL=255 on xmit, no check on receipt please Date: Sat, 7 Dec 2002 19:41:22 +1100 User-Agent: KMail/1.4.5 Cc: Keith Moore , John Schnizlein , "Zero Configuration WG" References: <200212070804.gB7843j09298@astro.cs.utk.edu> In-Reply-To: <200212070804.gB7843j09298@astro.cs.utk.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200212071941.23090.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 7 Dec 2002 19:04, Keith Moore wrote: > > On Sat, 7 Dec 2002 18:31, Keith Moore wrote: > > > > There are two problems - keeping LL traffic from being forwarded, and > > > > telling if the datagram you have came from the local link. > > > > > > please explain again why the app needs to know if the datagram came > > > from the local link? how does this relate to the group's charter? > > > > I never mentioned "app", so you can relax - I'm not intruding on your > > turf :-) > > I'm not concerned about turf. Let me phrase the question differently - > why is it important that the destination host enforce the restriction > that the packet came from the local link? The normal excuse has been "operational sanity". I'm not sure I understand what this means. We are talking about the case where routers are doing things that a router shouldn't, and I'd prefer to not have to deal with packets from a host that I may not be able to reach. That is worth avoiding. > > BTW: I'm ready to implement whatever the RFC (if it ever gets released) > > says for Linux > > Linux might be better off without it. I'll do the "set 255" part, if nothing else (unless the RFC says something else). Interoperability with OS 10.2 is important, as Aidan pointed out in the Original Post on this thread. Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE98bQzW6pHgIdAuOMRApLsAKCyTRHrY3p0dFXgsXb1I8aKSJqf6ACgpqMr 69haXcJFr8oU9YdDMMwjxcE= =8vwX -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Sat Dec 7 09:49:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29013 for ; Sat, 7 Dec 2002 09:49:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B91CD9122C; Sat, 7 Dec 2002 09:52:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 80CA79122E; Sat, 7 Dec 2002 09:52: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 6A8079122C for ; Sat, 7 Dec 2002 09:52:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4C9425DEE3; Sat, 7 Dec 2002 09:52:21 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id D67C65DEC3 for ; Sat, 7 Dec 2002 09:52:20 -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 JAA06077 for ; Sat, 7 Dec 2002 09:52:20 -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 JAA22010 for ; Sat, 7 Dec 2002 09:52:19 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id JAA00645 for ; Sat, 7 Dec 2002 09:52:18 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 07 Dec 2002 09:52:16 -0500 Subject: Somebody make a decision already From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212071941.23090.bhards@bigpond.net.au> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/07/2002 03:41, "Brad Hards" wrote: >>> BTW: I'm ready to implement whatever the RFC (if it ever gets released) >>> says for Linux >> >> Linux might be better off without it. > I'll do the "set 255" part, if nothing else (unless the RFC says something > else). Interoperability with OS 10.2 is important, as Aidan pointed out in > the Original Post on this thread. Folks...Keith's unveiled insults to anyone working for a company that makes money aside...there is a real time limit on how long this debate can last before the standard becomes irrelevant. There are apps about to be released that use current implementations of Zeroconf. Why would they not wait for the standard? Well, if they read this list, they may have come to the conclusion that they'll be lucky to get the LL part of Zeroconf standardized in this *decade*. But people need to get work done *now*. Not whenever insults and debates stop flying. But *now*. *Today*. Standards are *only* valuable when they are used. If they are not used, or unusable due to excessive domain-defending, and empire-guarding, then they become a "who cares" sort of thing. That's a shame, and in the long term, not very logical. But the world simply cannot delay implementations and work for some random time waiting for a bunch of poindexters to argue previously settled trivia. MIT is dropping AppleTalk zones, and we need something to replace them. Zeroconf, and DNS-SD are ideal, and I only hope that MS and Sun have implementations in place so we can move to that type of functionality across the board. But we *cannot* sit with our thumbs up our keisters for n years waiting for standards group to get done yelling at each other. If the idea that the world is not going to wait for this group is somehow insulting, or is perceived as evil corporate entities sullying the purity of the Internet, then I suggest those attitudes be re-examined. BBN was always a profit-making enterprise, as was IBM. We need this standard, but we need it in time to be relevant. If the IEEE took this much time for Ethernet, we'd still all be using 1MB dreaming of a 10MB standard. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sat Dec 7 09:52:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29065 for ; Sat, 7 Dec 2002 09:52:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E347A9122E; Sat, 7 Dec 2002 09:55:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF06591250; Sat, 7 Dec 2002 09:55: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 92A119122E for ; Sat, 7 Dec 2002 09:55:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C0F95DEE3; Sat, 7 Dec 2002 09:55:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 1FFED5DEC3 for ; Sat, 7 Dec 2002 09:55:06 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB7Esuj12820; Sat, 7 Dec 2002 09:54:56 -0500 (EST) Message-Id: <200212071454.gB7Esuj12820@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brad Hards Cc: Keith Moore , John Schnizlein , "Zero Configuration WG" Subject: Re: TTL=255 on xmit, no check on receipt please In-reply-to: (Your message of "Sat, 07 Dec 2002 19:41:22 +1100.") <200212071941.23090.bhards@bigpond.net.au> Date: Sat, 07 Dec 2002 09:54:56 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > I'm not concerned about turf. Let me phrase the question differently - > > why is it important that the destination host enforce the restriction > > that the packet came from the local link? > The normal excuse has been "operational sanity". I'm not sure I understand > what this means. > We are talking about the case where routers are doing things that a router > shouldn't, and I'd prefer to not have to deal with packets from a host that I > may not be able to reach. That is worth avoiding. I think it is worth avoiding, if you can make a case that the TTL check is a good indication of whether the reply will reach the host that sent the packet. > > > BTW: I'm ready to implement whatever the RFC (if it ever gets released) > > > says for Linux > > > > Linux might be better off without it. > I'll do the "set 255" part, if nothing else (unless the RFC says something > else). Interoperability with OS 10.2 is important, as Aidan pointed out in > the Original Post on this thread. actually I think the WG's job (or any WG's job) is to define what works well rather than trying to insist on compatibility with what is already deployed. Keith From owner-zeroconf@merit.edu Sat Dec 7 10:03:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29298 for ; Sat, 7 Dec 2002 10:03:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 885AD91250; Sat, 7 Dec 2002 10:05:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53FB791251; Sat, 7 Dec 2002 10:05: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 3BC4491250 for ; Sat, 7 Dec 2002 10:05:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2781E5DECC; Sat, 7 Dec 2002 10:05:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id BDD625DDDA for ; Sat, 7 Dec 2002 10:05:49 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB7F5gj13332; Sat, 7 Dec 2002 10:05:42 -0500 (EST) Message-Id: <200212071505.gB7F5gj13332@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brad Hards Cc: Keith Moore , "Zero Configuration WG" Subject: Re: TTL=255 on xmit, no check on receipt please In-reply-to: (Your message of "Sat, 07 Dec 2002 19:41:22 +1100.") <200212071941.23090.bhards@bigpond.net.au> Date: Sat, 07 Dec 2002 10:05:42 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk [second reply] > > why is it important that the destination host enforce the restriction > > that the packet came from the local link? > The normal excuse has been "operational sanity". I'm not sure I understand > what this means. okay, I might actually have figured out what it means. if you see a packet from another link, then it will not have seen ARPs from the local link, and it might therefore be coming from a source address that is used by a host on the local link. so the response to the packet might end up at a different host than the one that sent the first packet. so the assumption is that the scope of a broadcast packet (hence an ARP) is the same as the scope of a packet with constant TTL. it's probably valid most of the time, though it seems risky to make assumptions about the relationship of scopes in L2 and L3. Keith From owner-zeroconf@merit.edu Sat Dec 7 13:12:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03369 for ; Sat, 7 Dec 2002 13:12:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9EEE191206; Sat, 7 Dec 2002 13:15:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B6DE9122F; Sat, 7 Dec 2002 13:15: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 E45FC91206 for ; Sat, 7 Dec 2002 13:15:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D4E85DF2C; Sat, 7 Dec 2002 13:15:04 -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 0C1C35DF24 for ; Sat, 7 Dec 2002 13:15:04 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gB7IF3w27685 for ; Sat, 7 Dec 2002 10:15:03 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Sat, 7 Dec 2002 10:15:03 -0800 Received: from apple.com ([17.112.76.135]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id gB7IF2f12556; Sat, 7 Dec 2002 10:15:02 -0800 (PST) Date: Sat, 7 Dec 2002 10:15:12 -0800 Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: zeroconf@merit.edu To: Keith Moore From: Vincent Lubet In-Reply-To: <200212070716.gB77Gej08926@astro.cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, December 6, 2002, at 11:16 PM, Keith Moore wrote: >> Applications and protocols should be designed to adapt to change and >> be >> able to deal with unlikely events (see RFC 1122 and 1123). > > Please cite specific sections. I don't find this in 1123 at all; > and 1122 is not about applications. Here is the section for RFC 1122: 1.2.2 Robustness Principle At every layer of the protocols, there is a general rule whose application can lead to enormous benefits in robustness and interoperability [IP:1]: "Be liberal in what you accept, and conservative in what you send" Software should be written to deal with every conceivable error, no matter how unlikely; sooner or later a packet will come in with that particular combination of errors and attributes, and unless the software is prepared, chaos can ensue. In general, it is best to assume that the network is filled with malevolent entities that will send in packets designed to have the worst possible effect. This assumption will lead to suitable protective design, although the most serious problems in the Internet have been caused by unenvisaged mechanisms triggered by low-probability events; mere human malice would never have taken so devious a course! Adaptability to change must be designed into all levels of Internet host software. As a simple example, consider a protocol specification that contains an enumeration of values for a particular header field -- e.g., a type field, a port number, or an error code; this enumeration must be assumed to be incomplete. Thus, if a protocol specification defines four possible error codes, the software must not break when a fifth code shows up. An undefined code might be logged (see below), but it must not cause a failure. The second part of the principle is almost as important: software on other hosts may contain deficiencies that make it unwise to exploit legal but obscure protocol features. It is unwise to stray far from the obvious and simple, lest untoward effects result elsewhere. A corollary of this is "watch out for misbehaving hosts"; host software should be prepared, not just to survive other misbehaving hosts, but also to cooperate to limit the amount of disruption such hosts can cause to the shared communication facility. From owner-zeroconf@merit.edu Sat Dec 7 13:43:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04144 for ; Sat, 7 Dec 2002 13:43:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4FB9F91254; Sat, 7 Dec 2002 13:45:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D2D991255; Sat, 7 Dec 2002 13:45: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 44A2E91254 for ; Sat, 7 Dec 2002 13:45:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 94D845DEE1; Sat, 7 Dec 2002 13:45:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id CAE065DEB2 for ; Sat, 7 Dec 2002 13:45:25 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gB7IjLj16710; Sat, 7 Dec 2002 13:45:21 -0500 (EST) Message-Id: <200212071845.gB7IjLj16710@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Vincent Lubet Cc: Keith Moore , zeroconf@merit.edu Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt In-reply-to: (Your message of "Sat, 07 Dec 2002 10:15:12 PST.") Date: Sat, 07 Dec 2002 13:45:21 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Here is the section for RFC 1122: Maybe this group should apply the robustness principle to its own output, rather than insisting that existing applications change to accomodate zeroconf. A reasonable interpretion of "be conservative in what you send" would be "don't use IPv4 link local addresses except when you are sure they will not cause problems." Keith From owner-zeroconf@merit.edu Sat Dec 7 15:52:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06956 for ; Sat, 7 Dec 2002 15:52:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 635A891252; Sat, 7 Dec 2002 15:55:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 28DF291253; Sat, 7 Dec 2002 15:55:18 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 18CDA91252 for ; Sat, 7 Dec 2002 15:55:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id ED57D5DF74; Sat, 7 Dec 2002 15:55:16 -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 839D15DF6C for ; Sat, 7 Dec 2002 15:55:16 -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 PAA18815 for ; Sat, 7 Dec 2002 15:55:15 -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 PAA12178 for ; Sat, 7 Dec 2002 15:55:14 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA15997 for ; Sat, 7 Dec 2002 15:55:03 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 07 Dec 2002 15:47:30 -0500 Subject: Re: IESG comments on draft-ietf-zeroconf-ipv4-linklocal-07.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212071845.gB7IjLj16710@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/07/2002 13:45, "Keith Moore" wrote: >> Here is the section for RFC 1122: > > Maybe this group should apply the robustness principle to its own > output, rather than insisting that existing applications change to > accomodate zeroconf. A reasonable interpretion of "be conservative > in what you send" would be "don't use IPv4 link local addresses > except when you are sure they will not cause problems." Ah...so now the WG needs to predict every possible action of every possible packet before sending this packet. That should lead to really good throughput and usablility. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sat Dec 7 19:01:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10494 for ; Sat, 7 Dec 2002 19:01:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E455F9120A; Sat, 7 Dec 2002 19:03:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C3D69121F; Sat, 7 Dec 2002 19:03: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 4973A9120A for ; Sat, 7 Dec 2002 19:03:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 325485DDE3; Sat, 7 Dec 2002 19:03:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta01bw.bigpond.com (mta01bw.bigpond.com [139.134.6.78]) by segue.merit.edu (Postfix) with ESMTP id 502F75DED7 for ; Sat, 7 Dec 2002 19:02:58 -0500 (EST) Received: from pc-00206 ([144.135.24.75]) by mta01bw.bigpond.com (Netscape Messaging Server 4.15 mta01bw Jul 16 2002 22:47:55) with SMTP id H6RXGU00.4ZQ; Sun, 8 Dec 2002 10:02:54 +1000 Received: from CPE-203-51-24-113.nsw.bigpond.net.au ([203.51.24.113]) by bwmam03.mailsvc.email.bigpond.com(MailRouter V3.0n 26/27891646); 08 Dec 2002 10:02:55 From: Brad Hards To: Keith Moore Subject: Re: TTL=255 on xmit, no check on receipt please Date: Sun, 8 Dec 2002 10:51:34 +1100 User-Agent: KMail/1.4.5 Cc: "Zero Configuration WG" References: <200212071505.gB7F5gj13332@astro.cs.utk.edu> In-Reply-To: <200212071505.gB7F5gj13332@astro.cs.utk.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200212081051.34450.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 8 Dec 2002 02:05, Keith Moore wrote: > > The normal excuse has been "operational sanity". I'm not sure I > > understand what this means. > > okay, I might actually have figured out what it means. > > if you see a packet from another link, then it will not have seen ARPs > from the local link, and it might therefore be coming from a source > address that is used by a host on the local link. so the response to the > packet might end up at a different host than the one that sent the first > packet. Or it might not be reachable (hence you get a lot of re-transmissions). This is what I assumed it meant, but wasn't sure, because the term is so ambiguous. > so the assumption is that the scope of a broadcast packet (hence an ARP) > is the same as the scope of a packet with constant TTL. it's probably > valid most of the time, though it seems risky to make assumptions about > the relationship of scopes in L2 and L3. There is no assurance, but it is fairly reliable in practice. We do have some deployed experience to verify that. You can build a system that breaks the L2/L3 relationship (bridge-walling), but unless we build an application layer IP allocation system, then there aren't any alternatives. Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE98omGW6pHgIdAuOMRAuGMAKCCyRsWIlOCcuOcRSJNrDRw5VbAvgCffSAo c2RiIKJdlyfdtTLyL69dWPI= =oLiH -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Mon Dec 9 00:56:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18925 for ; Mon, 9 Dec 2002 00:56:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E76AE91239; Mon, 9 Dec 2002 00:59:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B53F991253; Mon, 9 Dec 2002 00:59: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 92B2891239 for ; Mon, 9 Dec 2002 00:59:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7842E5E038; Mon, 9 Dec 2002 00:59:28 -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 2A8C65E030 for ; Mon, 9 Dec 2002 00:59:28 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gB95xO7D009940; Sun, 8 Dec 2002 22:59:25 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id WAA05095; Sun, 8 Dec 2002 22:59:21 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gB95xH7C029911; Mon, 9 Dec 2002 16:59:17 +1100 (EST) Message-ID: <3DF43137.4000001@motorola.com> Date: Mon, 09 Dec 2002 16:59:19 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Schnizlein Cc: Zero Configuration WG Subject: Re: TTL=255 on xmit, no check on receipt please References: <4.3.2.7.2.20021206065421.01ed32c8@wells.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit John Schnizlein wrote: > Could we have a simple summary of the reasons that the intuitive > solution of TTL=1 to keep link-local (LL) traffic from being forwarded > off the link is bad, please? > Not bad, just not particularly useful. LL traffic generated by LL-aware hosts will be delivered by ARPing locally on the link. Hosts that don't do this fail to communicate at all using LL protocols. These host don't produce leakage. Non-LL-aware hosts responding to LL traffic will forward via a default route. They will *not* use TTL=1. This will be the majority of leakage traffic. > One of the persuasive arguments on this thread is to maintain as > much compatibility with existing deployments as possible during the > deployment of LL addressing. Another is keeping LL traffic local. > I buy the compatibility argument. Keeping LL traffic local with a TTL=1 doesn't seem to gain us much. > The analysis should consider the common (but not pretty) configuration > of a router's local interface for proxy-ARP, in which it responds to > ARP requests for any IP address with its own MAC address. How does the > LL-only host guarantee that it does not send LL traffic to the proxy-ARP > router? > *Any* IP address? Would that router behaviour break the address assignment process used by IPv4-LL anyway? Or is it only answering ARPs for addresses not deemed on the local net? - aidan From owner-zeroconf@merit.edu Mon Dec 9 19:05:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09354 for ; Mon, 9 Dec 2002 19:05:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ECD2D9123B; Mon, 9 Dec 2002 19:08:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B290291278; Mon, 9 Dec 2002 19:08:03 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C4C3B9123B for ; Mon, 9 Dec 2002 19:08:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id B493E5DE7F; Mon, 9 Dec 2002 19:08:02 -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 676E95DDC6 for ; Mon, 9 Dec 2002 19:08:02 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gBA081w03178 for ; Mon, 9 Dec 2002 16:08:01 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 9 Dec 2002 16:07:54 -0800 Received: from [17.202.45.250] (il0204a-dhcp122.apple.com [17.202.45.250]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id gBA07s904546; Mon, 9 Dec 2002 16:07:54 -0800 (PST) Message-Id: <200212100007.gBA07s904546@scv2.apple.com> Subject: Re: TTL=255 on xmit, no check on receipt please Date: Mon, 9 Dec 2002 16:07:42 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Daniel Senie" , "zeroconf" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >>First, TTL and security. I thought we had come to the consensus >>that checking the TTL had no particular security value. > >No. The comment made was that we wouldn't discuss security, and >whether the TTL value has security merit. There was no consensus that >I saw to actually conclude whether there were any security advantages. Yes, Dan is correct. My point was that there is some security benefit to knowing that the packet originated locally, but trying to quantify that benefit is a religious argument that will never be settled by discussion in this Working Group. The simple argument why there is a non-zero security benefit (without trying to quantify exactly how large the benefit is) is by analogy to firewalls: Assertion: Link-local provides a security benefit strictly stronger than the benefit provided by a corporate firewall: 1. A corporate firewall limits the population of potential attacker hosts to devices that are attached to any one of the set of logical (link-layer or "layer 2") links that are deemed 'inside' the firewall. 2. At a large company, there may be many logical links in this set. 3. Checking TTL=255 on link-local packets limits the population of potential attacker hosts to just one link. 4. Therefore, if a corporate firewall limits the population of potential attacker hosts, then checking TTL=255 on link-local packets limits the attacker population at least as much, and usually more. Therefore, if there is some benefit to limiting the population of potential attacker hosts (and clearly the majority of the world thinks there is), then there is benefit to enforcing that link-local packets actually originated on the local link. Ignoring for a moment the question of what deployed systems do today, let's consider ideal behaviour: 1. Link-local packets are intended for use only on the local link, (we have DHCP servers, routers, etc., for off-link communication) 2. There is no mechanism (and no intention of creating a mechanism) for using link-local addresses to communicate with hosts not directly attached to a common link (that would be duplicating existing functionality) 3. Therefore: any link-local packet arriving from outside the local link can have no legitimate valid purpose, and should be discarded. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Mon Dec 9 19:05:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09374 for ; Mon, 9 Dec 2002 19:05:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F2CB69127B; Mon, 9 Dec 2002 19:08:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE04A91279; Mon, 9 Dec 2002 19:08: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 B379091278 for ; Mon, 9 Dec 2002 19:08:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9953C5E010; Mon, 9 Dec 2002 19:08:08 -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 229F45DDC6 for ; Mon, 9 Dec 2002 19:08:08 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gBA087w03226 for ; Mon, 9 Dec 2002 16:08:07 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Dec 2002 16:07:44 -0800 Received: from [17.202.45.250] (il0204a-dhcp122.apple.com [17.202.45.250]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id gBA087f09908; Mon, 9 Dec 2002 16:08:07 -0800 (PST) Message-Id: <200212100008.gBA087f09908@scv3.apple.com> Subject: Re: random things Date: Mon, 9 Dec 2002 16:07:55 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Keith Moore" , "Zeroconf Working Group" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >I'm curious, has anyone actually tried to see what it would take >to get a non-LL-aware host to communicate with an LL-only host? Make the non-LL-aware host aware of LL. See Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Mon Dec 9 19:09:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09611 for ; Mon, 9 Dec 2002 19:09:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 05E5C91278; Mon, 9 Dec 2002 19:12:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD83991279; Mon, 9 Dec 2002 19:12: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 C3CA191278 for ; Mon, 9 Dec 2002 19:12:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id A9A905E077; Mon, 9 Dec 2002 19:12:32 -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 616EB5E010 for ; Mon, 9 Dec 2002 19:12:32 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gBA0CVw03965 for ; Mon, 9 Dec 2002 16:12:31 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 9 Dec 2002 16:12:08 -0800 Received: from [17.202.45.250] (il0204a-dhcp122.apple.com [17.202.45.250]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id gBA0CVs23595; Mon, 9 Dec 2002 16:12:31 -0800 (PST) Message-Id: <200212100012.gBA0CVs23595@scv1.apple.com> Subject: Re: TTL=255 on xmit, no check on receipt please Date: Mon, 9 Dec 2002 16:12:20 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "John Schnizlein" , "Zero Configuration WG" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Could we have a simple summary of the reasons that the intuitive >solution of TTL=1 to keep link-local (LL) traffic from being forwarded >off the link is bad, please? Below is the mail from Dave Thaler which originally carried the debate back in April 2001. Summary: TTL=255: incentive for ISPs to do the right thing easily detect offenders TTL=1: no incentive for ISPs/router vendors to do the right thing no way to easily detect offenders >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 Mon Dec 9 19:25:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10196 for ; Mon, 9 Dec 2002 19:25:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9F1E09127D; Mon, 9 Dec 2002 19:27:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6EC6D9127F; Mon, 9 Dec 2002 19: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 589EE9127D for ; Mon, 9 Dec 2002 19:27:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 455E45E06F; Mon, 9 Dec 2002 19:27:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id DD6535DD94 for ; Mon, 9 Dec 2002 19:27:50 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBA0Rkj04261; Mon, 9 Dec 2002 19:27:46 -0500 (EST) Message-Id: <200212100027.gBA0Rkj04261@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: "Keith Moore" , "Zeroconf Working Group" Subject: Re: random things In-reply-to: (Your message of "Mon, 09 Dec 2002 16:07:55 PST.") <200212100008.gBA087f09908@scv3.apple.com> Date: Mon, 09 Dec 2002 19:27:46 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > See thanks, I'll try that out. I'm not sure whether the 'route' command on most unixen can explicitly specify an interface. From owner-zeroconf@merit.edu Mon Dec 9 20:04:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11955 for ; Mon, 9 Dec 2002 20:04:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 764889127F; Mon, 9 Dec 2002 20:07:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3FCD891280; Mon, 9 Dec 2002 20:07: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 1B7AB9127F for ; Mon, 9 Dec 2002 20:06:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 034D55E07F; Mon, 9 Dec 2002 20:06:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id CAD015DDBE for ; Mon, 9 Dec 2002 20:06:58 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBA16sj04368; Mon, 9 Dec 2002 20:06:54 -0500 (EST) Message-Id: <200212100106.gBA16sj04368@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: "Daniel Senie" , "zeroconf" Subject: Re: TTL=255 on xmit, no check on receipt please In-reply-to: (Your message of "Mon, 09 Dec 2002 16:07:42 PST.") <200212100007.gBA07s904546@scv2.apple.com> Date: Mon, 09 Dec 2002 20:06:54 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > >>First, TTL and security. I thought we had come to the consensus > >>that checking the TTL had no particular security value. > > > >No. The comment made was that we wouldn't discuss security, and > >whether the TTL value has security merit. There was no consensus that > >I saw to actually conclude whether there were any security advantages. > > Yes, > > Dan is correct. My point was that there is some security benefit to > knowing that the packet originated locally, but trying to quantify that > benefit is a religious argument that will never be settled by discussion > in this Working Group. actually it seems that you would rather not discuss security benefits than to have the weaknesses of such arguments exposed. > The simple argument why there is a non-zero security benefit (without > trying to quantify exactly how large the benefit is) is by analogy to > firewalls: the principal security benefit in firewalls is that they make it easier to analyze the network for threats by reducing the number of potential threats that need to be considered. to repeat - firewalls don't necessarily reduce the actual number of threats to any significant degree - they only makes the analysis easier. this is a good thing, but it shouldn't be oversold. there are several reasons this benefit doesn't automagically extend to LL - one is that LL is less compatible than firewalls with many apps - another is that it's one thing for a site to analyze its security risks in the presence of firewalls, given knowledge of its own network, the apps that it runs, the assets it must protect, and so on. It's quite another thing for a code or hardware vendor to make assumptions about the customer's environment and the degree to which threats are reduced by use of LL. - a third is that while LL may prevent some off-link traffic from getting to a host, it may also provide new paths by which unauthorized traffic can reach a host - fourth, the additional measures that apps need to use to function in the presence of LL may themselves introduce security holes. > Ignoring for a moment the question of what deployed systems do today, > let's consider ideal behaviour: > > 1. Link-local packets are intended for use only on the local link, > (we have DHCP servers, routers, etc., for off-link communication) > 2. There is no mechanism (and no intention of creating a mechanism) > for using link-local addresses to communicate with hosts > not directly attached to a common link > (that would be duplicating existing functionality) > 3. Therefore: any link-local packet arriving from outside the local > link can have no legitimate valid purpose, and should be discarded. Why is this ideal behavior? What does it have to do with the group's goals as stated in its charter? Keith From owner-zeroconf@merit.edu Wed Dec 11 15:09:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18895 for ; Wed, 11 Dec 2002 15:09:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4370591247; Wed, 11 Dec 2002 15:12:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D1E99124A; Wed, 11 Dec 2002 15:12: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 8990591247 for ; Wed, 11 Dec 2002 15:12:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5DBEF5E0D6; Wed, 11 Dec 2002 15:12:32 -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 D539A5E0D5 for ; Wed, 11 Dec 2002 15:12:31 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gBBKCVw03698 for ; Wed, 11 Dec 2002 12:12:31 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 11 Dec 2002 12:12:29 -0800 Received: from [17.219.193.14] (vpn-scv-x1-14.apple.com [17.219.193.14]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id gBBKCTf25046 for ; Wed, 11 Dec 2002 12:12:29 -0800 (PST) Message-Id: <200212112012.gBBKCTf25046@scv3.apple.com> Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Date: Wed, 11 Dec 2002 12:12: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 At Erik Nordmark's request, I am sending this response to the list for review and possible discussion. An updated draft has been sent to the Internet Drafts directory. You can also view it at: >Hi Stuart. > >There were some Last Call comments on this document, which you've been >sent. I'm still waiting on an reply on those. > >Here are some more comments, courtesy of the IESG review. > >At this point, I consider the ball back in your court on next steps >for this document. Thanks. James Carlson suggested the following text. It has been added. >2.6 Historical Note > > A widely-known, but ineffective, duplicate address detection > technique called "gratuitous ARP" is found in many deployed systems > [Ste94]. This traditional gratuitous ARP implementation sends only > an ARP Announcement per section 1.2.2 of this document when an > interface is first configured. The result is that the victim (the > existing address holder) logs an error, and the offender continues > operation, often without even detecting the problem. The > administrator is expected to note the log message on the victim and > repair the damage after the fact. > > Implementors of this draft should be aware that this flaw is, as of > this writing, very widely deployed, and should take steps as > described in sections 2.4 and 2.5 to mitigate the problem. > >[...] > [Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The > Protocols", Addison-Wesley, 1994. Ralph Droms suggested the following change. It has been done. >One minor editorial comment: the details of an "ARP probe" are given in >both the third paragraph of section 1.1 and the second paragraph of section >2.1. I suggest the text that refers to ARP cache pollution be moved from >section 2.1 to section 1.1, and then that remaining text describing an ARP >probe in section 2.1 be replaced by a reference to section 1.1. > >- Ralph My answers to the IESG comments are below. I will consider the ball back in your court until I hear further instructions. >Randy: > >Section 1.2.1 et seq refer to "the widely-used natural interpretation >of" a particular kind of ARP packet not explictly described in the ARP >specification (NB: I have not verified that this packet isn't >described in the ARP spec, I'm taking the author's word on this point >for the moment). Alarm bells here, there are enough independent ARP >implementations that this is almost certainly a statement of the >author's opinion rather than a testable fact. Does this play well >with, eg, the ARP code in your PDA? The boot ROM in your cable modem? 1. Every Mac sold for the last five years has done address conflict detection as described here, so I think we have good confidence that it works (or if it doesn't work in 100% of cases, at least that it causes no harm). 2. These are not newly proposed ARP functions, they are the same old ARP functions: When you want to send an IP packet to IP address X on your link, you send an ARP request for IP address X. If you get an answer, you know which hardware address has IP address X. If you get no answer, you conclude that IP address X is not currently in use on that link. If there were devices that indiscriminately answered every ARP request, you couldn't reliably communicate with any other host on your link because the other device would keep answering. 3. Finally, the DHCP specification (RFC 2131) already requires this behaviour; it just doesn't specify it very well. >Section 1.2.3 suggests that broadcasting ARP responses is a good >thing. I have always viewed it as a necessary evil used primarily to >kludge around implementation issues for programs like DHCP servers on >operating systems that lack a mechanism by which the DHCP server can >stuff the ARP cache prior to responding when allocating an address. >Anything that encourages more broadcasts without a damned good reason >makes me nervous. I could be wrong, of course, but paranoia about >broadcast has served me well in the past (I was pretty sure that the >default setting required by RFC 1812 5.3.5.2 was a bad idea long >before Smurf attacks justified my paranoia). Section 1.2.3 says that broadcast ARP replies are "not needed in most situations". Section 2.5 says, "This is not recommended for general use." I believe the motivation for when you might prefer to use broadcast ARP replies, and why, is well explained in this section: This is not recommended for general use, but "Dynamic Configuration of IPv4 Link-Local Addresses" [v4LL] makes use of this optional capability, since in that case, detection of address conflicts using ARP is not merely a backup precaution to detect failures of some other configuration mechanism; detection of address conflicts using ARP is the sole configuration mechanism. >I see no mention of DHCP relays anywhere in the document. Not >particularly relevant to the author's presumed main purpose (conflict >detection for IPv4 link local addresses), but since the document >mentions DHCP extensively it probably ought to mention that DHCP is >sometimes used in ways for which this mechanism won't help much. The DHCP specification already requires this behaviour; it just doesn't specify it very well. This mechanism works in the presence of DHCP relays, and that is precisely why the DHCP specification requires this behaviour. I don't know of any examples where, "this mechanism won't help much." >I have not figured out yet whether the timing parameters in section >2.1 make this mechanism prone to synchronized broadcast storms. The >use of fixed length intervals after the initial random wait will keep >probes in step if they start out in step, the question is whether the >initial random wait is enough to avoid syncronized probes. To be >fair, if assume that the initial random wait is not sufficient, we may >be saying that we don't trust the random number generator being used >by the machines performing the probes, in which case the usual >solution (add some random jitter each time) may not help. So maybe >this is just a requirement that implementations had damned well better >be able to do the initial random wait properly (which may beg the >question of seed material on deeply embedded devices). The concept of synchronized broadcast storms applies to an ongoing unbounded repeating process. A protocol that sends four packets and then stops is not an ongoing unbounded repeating process. In any case, I don't believe that four packets constitutes a "storm". A "storm" usually refers to some unlimited feedback effect that produces an unbounded number of packets without limit until the problem is fixed. >In view of my misgivings about section 2.1, the suggestion of much >shorter fixed timeout intervalss on wireless networks in section 2.2 >does not improve my comfort level. Again, I don't think four packets constitutes a "storm". DHCP DISCOVER/OFFER/REQUEST/ACK is four packets, and many (or most?) hosts do that when they connect to the network today. On the subject of time delay, we live in a world of gigabit Ethernet and gigahertz processors. The days when people were willing to wait 30 seconds for their television set to "warm up" are behind us. We need to provide computers and networking that can meet the customer's expectations. >I have a vague memory that the step described in section 2.3 >(so-called "gratuitous ARP") was considered somewhat controversial at >one point, but I no longer remember why unless it's just dislike of >the mandatory delay. This does not impose any delay on use of the address. The purpose of the ARP announcements is to make sure that other hosts on the link do not have stale ARP cache entries left over from some other host that may previously have been using the same address. Without ARP announcements to update peer caches, DHCP clients suffer irreproducible intermittent failures. The DHCP specification (RFC 2131) already requires this behaviour: The client SHOULD broadcast an ARP reply to announce the client's new IP address and clear any outdated ARP cache entries in hosts on the client's subnet. >Section 2.4 doesn't worry me as much as the earlier sections. The >proposed mechanism for active defense seems like a fairly reasonable >way of handling a situation that is already demonstrably broken. >Note, however, that in pathological cases this mechanism could be used >as a means of triggering broadcast storms (trick a bunch of machines >into using the same address, then broadcast a packet that will make >them all try to defend it at once). I don't think this is a serious >risk, but something about it probably belongs in the security >considerations section. Please propose specific text. If an attacker has a way to trick all your machines into using the same address, I think you have bigger problems to worry about than a few ARP packets. >Section 2.5 is more of the same optimism about broadcast ARP replies. >I've already commented on that, so I won't belabor the point. Okay. >Security Considerations section seems anemic. Aside from the specific >minor issue mentioned above, there's the general issue that this is a >mechanism by which an attacker can send packets via an unsecurable >protocol that will provoke a host to respond in predictable ways. >This is always a bit of a concern, and it's more of a concern with >broadcast protocols. I am willing to accept specific text. I should say that I believe that the spoof ARP attack is not a new vulnerability. This document just says that hosts should detect it and recover. As a real-world example, at the most recent IETF meeting in Atlanta, one of the networking guys had to come in to the meeting room and yank the power cord on the wireless base station to reset it. I asked him why? He told me that someone had manually set their IP address to be the same as the wireless base station, rendering the wireless base station useless. He had to come in and manually yank the power cord to power-cycle it so it would get a new DHCP address. Clinging to your IP address in the face of ARP conflicts doesn't make your device more reliable -- it just means that it is now useless for longer, and requires a physical visit from a technician to fix it. >Erik: > > Issues with draft-cheshire-ipv4-acd-02.txt > > High-order bit: the probing and annoucement part seems like very > useful things to standardize. Good. > But the ongoing conflict detection (causing > IP address change when a conflict appears) and broadcast replies looks > more like a useful experiment to me. It has been a five-year experiment by Apple. Concerning ongoing conflict detection, I refer you to the previous example of the wireless base station at the IETF meeting. > Also, the timeouts claim to be related to IEEE 802.1D behavior doesn't > match IEEE 802.1D reality. (See below) > > > Specfic comments: > The document is written as if it updates RFC 826 and DHCP (RFC 2132) but > it doesn't explicitly say this. I am willing to accept specific text. > > 3. Rate-limiting in the case of an excessive number of repeated > > conflicts. > > Would be helpful to say what is rate limited; the attempt to use > a different address (and not e.g. the rate at which some packet is sent) New text: 3. Rate-limiting of address acquisition attempts in the case of an excessive number of repeated conflicts. > > This document standardizes the widely-used natural interpretation of > > an ARP Request where the Target Protocol Address is non-zero but the > > While this might be natural, I have no idea whether or not it is > widely used. Wants me want to ask for the survey results of 50 ARP > implementations and how they do this. This is the interpretation required by DHCP (RFC 2131), so I would hope it is widely used, at least to the extent that DHCP clients are widely used. > > This document standardizes the widely-used natural interpretation of > > an ARP Request where the Sender and Target Protocol Address fields > > contain the same address, namely that it is an assertion without an > > associated question (an "ARP Announcement"). > > Same general question as above, except that there is another > natural case - that an ARP Reply where the sender and targer > are the same. Given that ARP is widely implemented it would be > useful to understand 1) to what extent implementations do > announcements using requests or replies, and depending on that answer > 2) whether the protocol could allow both forms of annoucements i.e. > any packet with equal sender protocol address and target protocol address > would be an announcement. This is the interpretation described in Stevens (TCP/IP Illustrated, 1994) under the name "Gratuitous ARP" and described as being widely used at that time. It is also required by RFC 2131. > > "Dynamic Configuration of IPv4 Link-Local Addresses" [v4LL] can > > benefit from this optional capability. > > The "can benefit" is odd since it looks like a suggestion to > fix v4LL to do this, when in fact it already does. The full sentence is: This is not needed in most situations, but certain specialized uses of Address Conflict Detection such as "Dynamic Configuration of IPv4 Link-Local Addresses" [v4LL] can benefit from this optional capability. Delete the "such as" clause and the sentence reads: This is not needed in most situations, but certain specialized uses of Address Conflict Detection can benefit from this optional capability. I hope that is clear. > It is perhaps better to have some statement up front that this > protocol is a subset of the address conflict detection of v4LL. I would rather the merits of this document be considered alone, without normative reference to other unpublished specifications. However, I think the relationship goes the other way: v4LL uses a proper subset of the conflict detection mechanisms outlined in this document. > > RFC 826 implies that replies to ARP requests are usually delivered > > using unicast, but it is also acceptable to deliver ARP replies using > > broadcast. The "Packet Reception" rules in RFC 826 specify that the > > content of the "ar$spa" field should be processed *before* examining > > the "ar$op" field, so any host that correctly implements the Packet > > Reception algorithm specified in RFC 826 will correctly handle ARP > > replies delivered via link-layer broadcast. > > I think there are implementations of RFC 826 which do not follow > the pseudo-code in RFC 826. What do we know about the effect > of broadcast arp replies on them? > For example, I looked at the Solaris ARP code and it treats > a broadcast arp reply as an ARP announcement which, due to the structure > of the implementation, incurs more processing overhead than a ARP > packet which is not considered to be an announcement. > I wouldn't be surprised if there are other surprising behaviors related > to broadcast ARP replies. Section 1.2.3 says that broadcast ARP replies are "not needed in most situations". Section 2.5 says, "This is not recommended for general use." I believe the motivation for when you might prefer to use broadcast ARP replies, and why, is well explained in this section. > > server, etc.) that the proposed address is not acceptable. In > > addition, if during this period the host receives any ARP probe where > > the packet's 'target IP address' is the address being probed for, and > > the packet's 'sender hardware address' is not the hardware address of > > any of the host's interfaces, then the host MUST similarly treat this > > as an address conflict and signal an error to the configuring agent > > as above. This can occur if two (or more) hosts have, for whatever > > The above is the only place where multihoming comes into the spec by > mentioning "any of the host's interfaces". No, it is also mentioned in 2.4: Address conflict detection should not be limited to only the time of initial interface configuration, when a host is sending ARP probes. Address conflict detection is an ongoing process that is in effect for as long as a host is using an address. At any time, if a host receives an ARP packet (request *or* reply) where the 'sender IP address' is the host's own IP address, but the 'sender hardware address' does not match any of the host's own interface addresses, then this is a conflicting ARP packet, indicating some other host also thinks it is validly using this address. This is necessary for the case when a host has two interfaces (say wireless and Ethernet) on the same link. > I would assume that ACD can > operate independently for each interface even though v4LL has some > extra stuff related to multi-interface nodes. No, the specification needs to deal with the case when a host has two interfaces (say wireless and Ethernet) on the same link. > Section 2.2 on timeouts seems to not work. > The 802.1d standard suggests default timers which result in it > taking about 30 seconds until a switch port passes traffic after > it has been enabled. I've personally observed more like 45 seconds > when my office Ethernet drop has had spanning tree protocol enabled. We live in a world of gigabit Ethernet and gigahertz processors. The days when people were willing to wait 30 seconds for their television set to "warm up" are behind us. We need to provide computers and network devices that can meet the same customer expectations. > But in most cases this isn't needed. When DHCP is used (whether it is > a desktop machine or some portable handheld wireless device) then > no DHCP will happen until the switch starts forwarding packets. > And the link-local case is handled in the v4LL specification. > This leaves manually configured addresses. > If you take into account that IEEE 802.1 is rapidly moving to > obsolete spanning tree protocol in favour of the rapid spanning tree > protocol, I don't see benefit in making the DHCP clients take 30-45 > seconds longer to initialize the stack just because that might be > the conservative number for manually configured IP addresses until > RSTP is deployed. > And this calls into question the 4 packets spaced 2 seconds apart - > perhaps 1 or 2 packets are sufficient if you assume that the L2 is > forwarding frames by the time the ACD protocol runs. Most network operators today, with good reason, set their port blocking time to five seconds. The eight-second delay was determined empircally from customer feedback gathered over the last five years. I am also working with the IEEE 802 committees on an update to rapid spanning tree that allows a host to reliably determine when link connectivity has been established, within 2.5 seconds of connection. When a Mac determines that it is connected to one of these newer switches, and confirms that proper link connectivity has been established, it will then start probing using the shorter timeouts given in Section 2.2. With increasing use of portable devices, fast network connectivity is important. People want to plug in, complete the task at hand, and move on. USB and FireWire have extablished an upper limit on how long people are willing to wait between connecting a storage device and having it show up on the desktop read to read and write. About 3-5 seconds is a good goal. Quicker would be better, but sadly the need to be aware of spanning tree (and rapid spanning tree) makes that impossible. > > (c) If a host has been configured such that it should not give up its > > address under any circumstances, perhaps because it is an important > > company server with a well-known IP address, then it MAY elect to > > company vs. university vs. home server presumably doesn't matter. > s/company// > It isn't "well-known" (as in potentially hard-coded in applications) > that matter. Instead it is the assumption that the address be > temporarely stable because of long running connections and/or it being > in the DNS with a longish DNS TTL, that matters here. I have changed the text: (c) If a host has been configured such that it should not give up its address under any circumstances (perhaps because it is the kind of device that needs to have a well-known stable IP address, such as a link's default router, or a DNS server) then it MAY elect to defend its address indefinitely. The examples in parenteses are informative, not exhaustive. > Section 2.5 on broadcast arp replies > has a MAY and goes it to say that they should not be used universally. > I think the MAY refers to MAY implement. In order to be able to > operationally control the use I suspect it needs to be more strict > and e.g. say "MAY be implemented. When implemented, there MUST be a > knob to enable the use of broadcast arp replies, and this knob MUST > default to false" or something similar that gives control on the *use* > of this. I don't want to use language that may in future paint v4LL into a corner. A Zero Configuration device may want to make use of address conflict detection. If address conflict detection requires a mandatory user-configuration option, then that means that Zero Configuration devices require mandatory user-configuration options, a self-contradiction. I am willing to accept suggested text that doesn't require mandatory user-configuration options, but removing the burden of manual configuration is the whole point of Zero Configuration networking in the first place, so I am reluctant to compromise on that. > Finally, references should be split between normative and non-normative > per rfc-editor policy. Done. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Dec 11 16:04:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20912 for ; Wed, 11 Dec 2002 16:04:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E39EE912C8; Wed, 11 Dec 2002 16:07:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E5D9912DB; Wed, 11 Dec 2002 16:07: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 1D4FB912DC for ; Wed, 11 Dec 2002 16:05:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 02B935E0E1; Wed, 11 Dec 2002 16:05:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 9A75F5E0DF for ; Wed, 11 Dec 2002 16:05:57 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBBL5oj20201; Wed, 11 Dec 2002 16:05:53 -0500 (EST) Message-Id: <200212112105.gBBL5oj20201@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Wed, 11 Dec 2002 12:12:19 PST.") <200212112012.gBBKCTf25046@scv3.apple.com> Date: Wed, 11 Dec 2002 16:05:50 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > Section 2.5 on broadcast arp replies > > has a MAY and goes it to say that they should not be used universally. > > I think the MAY refers to MAY implement. In order to be able to > > operationally control the use I suspect it needs to be more strict > > and e.g. say "MAY be implemented. When implemented, there MUST be a > > knob to enable the use of broadcast arp replies, and this knob MUST > > default to false" or something similar that gives control on the *use* > > of this. > > I don't want to use language that may in future paint v4LL into a corner. > > A Zero Configuration device may want to make use of address conflict > detection. If address conflict detection requires a mandatory > user-configuration option, then that means that Zero Configuration > devices require mandatory user-configuration options, a > self-contradiction. actually, this is the biggest single problem with v4LL. zero configuration is a misnomer. the set of devices that can practically be used with zero configuration is approximately the null set. for instance, almost any networked device needs some kind of authentication, and this inevitably requires some sort of configuration - either in the device itself, or the clients that are authorized to use that device, or both. I quote from this group's charter: > ZEROCONF requirements will make networking as easy as possible, but no > easier. In some cases other considerations may dominate ease of use. For > example, network security requires some configuration which may not be > as easy as the unacceptable alternative of 'no security.' it's high time that this group stopped ignoring this. Keith From owner-zeroconf@merit.edu Wed Dec 11 16:38:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21945 for ; Wed, 11 Dec 2002 16:38:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 25151912DB; Wed, 11 Dec 2002 16:40:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E654F912DC; Wed, 11 Dec 2002 16:40:10 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CE6AE912DB for ; Wed, 11 Dec 2002 16:40:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id AEFF45E0E0; Wed, 11 Dec 2002 16:40: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 38BBE5DE84 for ; Wed, 11 Dec 2002 16:40:09 -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 QAA10947 for ; Wed, 11 Dec 2002 16:40:08 -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 QAA18343 for ; Wed, 11 Dec 2002 16:37:31 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA23130 for ; Wed, 11 Dec 2002 16:37:31 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 11 Dec 2002 16:37:29 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212112105.gBBL5oj20201@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/11/2002 16:05, "Keith Moore" wrote: > actually, this is the biggest single problem with v4LL. > > zero configuration is a misnomer. the set of devices that can > practically be used with zero configuration is approximately the > null set. for instance, almost any networked device needs some kind > of authentication, and this inevitably requires some sort of > configuration - either in the device itself, or the clients > that are authorized to use that device, or both. Um...in home networks and ad hoc networks that only need to exist for a few minutes, there is no authentication needed. Many, and perhaps most small business networks don't require authentication either. This isn't good or bad, but just a simple fact. The authentication you see in .edu and large business domains is not the norm across the board. For the people who don't need authentication, then Zeroconf is not a misnomer. > > I quote from this group's charter: > >> ZEROCONF requirements will make networking as easy as possible, but no >> easier. In some cases other considerations may dominate ease of use. For >> example, network security requires some configuration which may not be >> as easy as the unacceptable alternative of 'no security.' > > it's high time that this group stopped ignoring this. Well, if you want to be pedantic, literal Zeroconf is a physical impossibility, but we're not including installing the NIC, connecting the cables, etc. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Dec 11 16:55:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22586 for ; Wed, 11 Dec 2002 16:55:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BFB05912DC; Wed, 11 Dec 2002 16:58:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8AFCB912DD; Wed, 11 Dec 2002 16:58: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 731A7912DC for ; Wed, 11 Dec 2002 16:58:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 608365E0D4; Wed, 11 Dec 2002 16:58:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 00EC55DFC8 for ; Wed, 11 Dec 2002 16:58:21 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBBLwLj20528; Wed, 11 Dec 2002 16:58:21 -0500 (EST) Message-Id: <200212112158.gBBLwLj20528@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: zeroconf@merit.edu Subject: rare reply to one of John Welch's messages Cc: moore@cs.utk.edu From: Keith Moore Date: Wed, 11 Dec 2002 16:58:21 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk I'm taking an exception to reply to one of John Welch's messages, because I believe he's echoing a common misconception: > Um...in home networks and ad hoc networks that only need to exist for a few > minutes, there is no authentication needed. that is demonstrably untrue; there are threats that are *specific* to ad hoc networks. if hosts in ad hoc networks don't require authentication you can be sure that there will be attackers on ad hoc networks. (just as there are those that attack IP addresses that are known to be assigned to dialup lines, those who run ssh mitm attacks at IETF's, etc.) as for home and small business networks, if there are resources to protect, there is still a need for authentication. some may trust their firewalls to provide sufficient protection, but that's like saying "I live in a gated community so I don't need to lock my doors" (it's one thing if people are naive enough to assume that a firewall gives them security; it's even worse if the gated community insists that none of the houses within need to have locks on their doors). Keith From owner-zeroconf@merit.edu Wed Dec 11 17:53:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24127 for ; Wed, 11 Dec 2002 17:53:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DC0B0912DD; Wed, 11 Dec 2002 17:55:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A75D5912DF; Wed, 11 Dec 2002 17:55: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 6D389912DD for ; Wed, 11 Dec 2002 17:55:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 539DF5E0DA; Wed, 11 Dec 2002 17:55:45 -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 DD9145DFB3 for ; Wed, 11 Dec 2002 17:55:44 -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 RAA21797 for ; Wed, 11 Dec 2002 17:55:44 -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 RAA01182 for ; Wed, 11 Dec 2002 17:55:44 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA27717 for ; Wed, 11 Dec 2002 17:55:43 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 11 Dec 2002 17:55:41 -0500 Subject: Re: rare reply to one of John Welch's messages From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212112158.gBBLwLj20528@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/11/2002 16:58, "Keith Moore" wrote: > I'm taking an exception to reply to one of John Welch's messages, > because I believe he's echoing a common misconception: I'm whelmed...more under than over, but definitely whelmed. > >> Um...in home networks and ad hoc networks that only need to exist for a few >> minutes, there is no authentication needed. > > that is demonstrably untrue; there are threats that are *specific* to > ad hoc networks. if hosts in ad hoc networks don't require authentication > you can be sure that there will be attackers on ad hoc networks. > (just as there are those that attack IP addresses that are known to be > assigned to dialup lines, those who run ssh mitm attacks at IETF's, etc.) If you are going to interpret what I say, do it right. I never said there are NO threats to ad hoc networks. But, in an airport, two laptops that are using a FireWire/USB/Crossover ethernet cable to transfer a file aren't going to have to deal with many attacks. The same goes for any network that comes up and goes down in less than a half - hour. For an attack to work, there has to be adequate opportunity and time, and many ad hoc networks provide neither. Trying to attack such a network, is not going to be worth the effort in most cases. Now, if we are talking about an ad hoc network that is up for a number of hours or longer, then you have the time. But again, you have to find the network, determine that they are using Zeroconf to set it up, and insert yourself on the network. That does not take zero time. For example, at the upcoming MacWorld Expo in January, between 5 January and 10 January 2003, I will probably participate in around 50 different ad hoc networks. The theoretical chance to crack them is 100%, the real-world chance to crack them approaches zero. > > as for home and small business networks, if there are resources to > protect, there is still a need for authentication. some may trust > their firewalls to provide sufficient protection, but that's like > saying "I live in a gated community so I don't need to lock my doors" > > (it's one thing if people are naive enough to assume that a firewall > gives them security; it's even worse if the gated community insists > that none of the houses within need to have locks on their doors). Maybe. A properly configured firewall can be quite secure. In addition, in a business consisting of ten computers, the need for authentication beyond basic firewall and login security may be quite small indeed. If you live in an area with a near zero crime rate, and a well-armed populace, you may not ever need to lock your doors. In any case, to say that you will always need authentication, or even close to that as you did: " the set of devices that can practically be used with zero configuration is approximately the null set. for instance, almost any networked device needs some kind of authentication, and this inevitably requires some sort of configuration - either in the device itself, or the clients that are authorized to use that device, or both." Is simply not correct in the real world, with regard to Zeroconf. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Dec 11 20:36:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28480 for ; Wed, 11 Dec 2002 20:36:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9F69491213; Wed, 11 Dec 2002 20:38:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10A0591221; Wed, 11 Dec 2002 20:38: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 146C291213 for ; Wed, 11 Dec 2002 20:38:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC3485DFAB; Wed, 11 Dec 2002 20:38:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtpout.mac.com (A17-250-248-87.apple.com [17.250.248.87]) by segue.merit.edu (Postfix) with ESMTP id 7C1D35DE09 for ; Wed, 11 Dec 2002 20:38:45 -0500 (EST) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id gBC1ciba016145 for ; Wed, 11 Dec 2002 17:38:44 -0800 (PST) Received: from mac.com ([200.67.16.63]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id H6ZGKK00.QL8 for ; Wed, 11 Dec 2002 17:38:44 -0800 Date: Wed, 11 Dec 2002 19:38:21 -0600 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: irod@mac.com To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <200212112105.gBBL5oj20201@astro.cs.utk.edu> Message-Id: <65D4A0A6-0D72-11D7-966F-003065A87BBE@mac.com> X-Mailer: Apple Mail (2.546) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, December 11, 2002, at 03:05 PM, Keith Moore wrote: > zero configuration is a misnomer. the set of devices that can > practically be used with zero configuration is approximately the > null set. We network and use USB and Firewire printers, scanners, hard drives and cameras all the time with zero configuration. Not to mention computers and printers using technologies like Appletalk. -Rod Lopez From owner-zeroconf@merit.edu Thu Dec 12 00:56:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04218 for ; Thu, 12 Dec 2002 00:56:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5ACBE91225; Thu, 12 Dec 2002 00:59:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2AB7F91248; Thu, 12 Dec 2002 00:59: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 0743291225 for ; Thu, 12 Dec 2002 00:59:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id DBBF65DE08; Thu, 12 Dec 2002 00:59:21 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 7F4005DDCC for ; Thu, 12 Dec 2002 00:59:21 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBC5xFj22516; Thu, 12 Dec 2002 00:59:16 -0500 (EST) Message-Id: <200212120559.gBC5xFj22516@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: irod@mac.com Cc: zeroconf@merit.edu Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Wed, 11 Dec 2002 19:38:21 CST.") <65D4A0A6-0D72-11D7-966F-003065A87BBE@mac.com> Date: Thu, 12 Dec 2002 00:59:15 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > zero configuration is a misnomer. the set of devices that can > > practically be used with zero configuration is approximately the > > null set. > > We network and use USB and Firewire printers, scanners, hard drives and > cameras all the time with zero configuration. USB and Firewire are not the same as IP. For instance, how frequently do you have multiple devices on USB or Firewire that are accessible from anywhere in the Internet, are potentially compromised, and can be used to launch attacks on other devices on those buses? Also, it's somewhat more reasonable for a USB or Firewire device to not need authentication, because you're not going to find many USB or Firewire networks with hundreds or more devices that have external Internet access. L2-switched IP subnets with that many devices are quite common. Keith From owner-zeroconf@merit.edu Thu Dec 12 11:14:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29362 for ; Thu, 12 Dec 2002 11:14:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7956C91223; Thu, 12 Dec 2002 11:15:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D32B91229; Thu, 12 Dec 2002 11: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 E610591223 for ; Thu, 12 Dec 2002 11:15:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4FD655E07E; Thu, 12 Dec 2002 11:15:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from arrakis.cso.uiuc.edu (arrakis.cso.uiuc.edu [130.126.113.7]) by segue.merit.edu (Postfix) with ESMTP id 6199B5DF0B for ; Thu, 12 Dec 2002 11:15:19 -0500 (EST) Received: from arrakis.cso.uiuc.edu (localhost [127.0.0.1]) by arrakis.cso.uiuc.edu (8.12.4/8.12.4) with ESMTP id gBCGFAXN020486; Thu, 12 Dec 2002 10:15:10 -0600 (CST) Received: (from jak@localhost) by arrakis.cso.uiuc.edu (8.12.4/8.12.4/Submit) id gBCGFAlN020485; Thu, 12 Dec 2002 10:15:10 -0600 (CST) Date: Thu, 12 Dec 2002 10:15:10 -0600 From: "Jay A. Kreibich" To: Keith Moore Cc: irod@mac.com, zeroconf@merit.edu Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Message-ID: <20021212161510.GB20458@uiuc.edu> Reply-To: jak@uiuc.edu References: <65D4A0A6-0D72-11D7-966F-003065A87BBE@mac.com> <200212120559.gBC5xFj22516@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200212120559.gBC5xFj22516@astro.cs.utk.edu> User-Agent: Mutt/1.4i X-Editor: vi, and proud of it X-URL: http://www.uiuc.edu/~jak (includes PGP key) Sender: owner-zeroconf@merit.edu Precedence: bulk On Thu, Dec 12, 2002 at 12:59:15AM -0500, Keith Moore scratched on the wall: > > > zero configuration is a misnomer. the set of devices that can > > > practically be used with zero configuration is approximately the > > > null set. > > > > We network and use USB and Firewire printers, scanners, hard drives and > > cameras all the time with zero configuration. > > USB and Firewire are not the same as IP. For instance, how frequently > do you have multiple devices on USB or Firewire that are accessible > from anywhere in the Internet, are potentially compromised, and can > be used to launch attacks on other devices on those buses? And how many LL networks are accessible from anywhere in the Internet? As soon as you set a non-LL address, your addressing scheme is outside of what zeroconf can provide, and it isn't really our problem (although *finding* the device with services like mDNS is still pretty useful). > Also, it's somewhat more reasonable for a USB or Firewire device to not > need authentication, because you're not going to find many USB or Firewire > networks with hundreds or more devices that have external Internet access. > L2-switched IP subnets with that many devices are quite common. No, but for YEARS new printers, new consumer-level routers, new wireless access points, new VoIP phones, new video conference gear and many other embedded networking devices have all shipped with a 192.* address. You put them on the network, point your browser at them, spend five minutes reconfiguring the network settings and you get on with life. The risk is not zero, but it is very very small, and it sure beats trying to type in IP addresses and netmasks with the three buttons on the front of the device. -j -- Jay A. Kreibich | Integration & Software Eng. jak@uiuc.edu | Campus IT & Edu. Svcs. | University of Illinois at U/C From owner-zeroconf@merit.edu Thu Dec 12 11:21:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29737 for ; Thu, 12 Dec 2002 11:21:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A3CDB91229; Thu, 12 Dec 2002 11:24:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6793C9122B; Thu, 12 Dec 2002 11:24: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 30A2F91229 for ; Thu, 12 Dec 2002 11:24:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1F78F5DEE0; Thu, 12 Dec 2002 11:24:43 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id E61795DD96 for ; Thu, 12 Dec 2002 11:24:42 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBCGOYj27877; Thu, 12 Dec 2002 11:24:34 -0500 (EST) Message-Id: <200212121624.gBCGOYj27877@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: jak@uiuc.edu Cc: Keith Moore , irod@mac.com, zeroconf@merit.edu Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Thu, 12 Dec 2002 10:15:10 CST.") <20021212161510.GB20458@uiuc.edu> Date: Thu, 12 Dec 2002 11:24:34 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > > > zero configuration is a misnomer. the set of devices that can > > > > practically be used with zero configuration is approximately the > > > > null set. > > > > > > We network and use USB and Firewire printers, scanners, hard drives and > > > cameras all the time with zero configuration. > > > > USB and Firewire are not the same as IP. For instance, how frequently > > do you have multiple devices on USB or Firewire that are accessible > > from anywhere in the Internet, are potentially compromised, and can > > be used to launch attacks on other devices on those buses? > > And how many LL networks are accessible from anywhere in the Internet? "LL network" is a misnomer. LL will be imposed on essentially all IP networks. The hosts on those networks will still be as vulnerable to compromise from existing sources as they are now, and LL adds new vulnerabilities. > > Also, it's somewhat more reasonable for a USB or Firewire device to not > > need authentication, because you're not going to find many USB or Firewire > > networks with hundreds or more devices that have external Internet access. > > L2-switched IP subnets with that many devices are quite common. > > No, but for YEARS new printers, new consumer-level routers, new > wireless access points, new VoIP phones, new video conference gear > and many other embedded networking devices have all shipped with > a 192.* address. You put them on the network, point your browser at > them, spend five minutes reconfiguring the network settings and you > get on with life. The risk is not zero, but it is very very small, > and it sure beats trying to type in IP addresses and netmasks with > the three buttons on the front of the device. Initial configuration is a different story. At least if the initial configuration is done over a wired interface you can hook up the device to a network consisting of that device and another computer for the sake of initial configuration. No, it's not safe to do this on a production network. I've seen an attack which relied on an OS being installed over the network with no initial root password (because the OS let you set that after installation) - the attacker could tell when you were finished installing the OS (from one of the mirror servers) and could compromise your computer before you got a password set. Keith From owner-zeroconf@merit.edu Thu Dec 12 12:42:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03887 for ; Thu, 12 Dec 2002 12:42:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9338C9122C; Thu, 12 Dec 2002 12:22:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 612179122E; Thu, 12 Dec 2002 12:22: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 4AB389122C for ; Thu, 12 Dec 2002 12:22:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1ADB75DEE0; Thu, 12 Dec 2002 12:22:42 -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 9C9775DD96 for ; Thu, 12 Dec 2002 12:22:41 -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 MAA05231 for ; Thu, 12 Dec 2002 12:22:39 -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 MAA26100 for ; Thu, 12 Dec 2002 12:22:39 -0500 (EST) Received: from [18.18.3.76] (WINDEL1.MIT.EDU [18.18.3.76]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA17334 for ; Thu, 12 Dec 2002 12:22:39 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 12 Dec 2002 12:22:38 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212121624.gBCGOYj27877@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/12/2002 11:24, "Keith Moore" wrote: >> And how many LL networks are accessible from anywhere in the Internet? > > "LL network" is a misnomer. LL will be imposed on essentially all > IP networks. The hosts on those networks will still be as vulnerable > to compromise from existing sources as they are now, and LL adds new > vulnerabilities. Please, because I'm really curious. On an ad hoc network with 3 hosts(two laptops and a printer) and a small hub, with no external connection, and no wireless running, exactly *how* vulnerable are they in the real world? > >>> Also, it's somewhat more reasonable for a USB or Firewire device to not >>> need authentication, because you're not going to find many USB or Firewire >>> networks with hundreds or more devices that have external Internet access. >>> L2-switched IP subnets with that many devices are quite common. >> >> No, but for YEARS new printers, new consumer-level routers, new >> wireless access points, new VoIP phones, new video conference gear >> and many other embedded networking devices have all shipped with >> a 192.* address. You put them on the network, point your browser at >> them, spend five minutes reconfiguring the network settings and you >> get on with life. The risk is not zero, but it is very very small, >> and it sure beats trying to type in IP addresses and netmasks with >> the three buttons on the front of the device. > > Initial configuration is a different story. At least if the initial > configuration is done over a wired interface you can hook up the > device to a network consisting of that device and another computer > for the sake of initial configuration. Direct connects describe a fair chunk of ad hoc networks. > > No, it's not safe to do this on a production network. I've seen an > attack which relied on an OS being installed over the network with > no initial root password (because the OS let you set that after > installation) - the attacker could tell when you were finished installing > the OS (from one of the mirror servers) and could compromise your > computer before you got a password set. Um...how many devices require a complete OS Install over a network prior to initial network/user configuration? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Dec 12 13:59:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07226 for ; Thu, 12 Dec 2002 13:59:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 518A491206; Thu, 12 Dec 2002 14:02:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8F8D9122F; Thu, 12 Dec 2002 14:02: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 D07DE91206 for ; Thu, 12 Dec 2002 14:02:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id AE6735DF44; Thu, 12 Dec 2002 14:02:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by segue.merit.edu (Postfix) with ESMTP id 7AE4A5DEE1 for ; Thu, 12 Dec 2002 14:01:59 -0500 (EST) Received: from SERVER.ACM.org ([63.199.7.253]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with ESMTP id <0H70000JKSTAKV@mta5.snfc21.pbi.net> for ZeroConf@Merit.edu; Thu, 12 Dec 2002 11:00:47 -0800 (PST) Date: Thu, 12 Dec 2002 11:00:21 -0800 From: Peter Johansson Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: <200212120559.gBC5xFj22516@astro.cs.utk.edu> X-Sender: Celeborn@PostOffice.PacBell.net To: Zero Configuration Message-id: <5.1.0.14.2.20021212105241.03c816e0@PostOffice.PacBell.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <" <65D4A0A6-0D72-11D7-966F-003065A87BBE"@mac.com> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT At 12:59 AM 12/12/2002 -0500, Keith Moore wrote: >USB and Firewire are not the same as IP. For instance, how frequently do >you have multiple devices on USB or Firewire that are accessible from >anywhere in the Internet, are potentially compromised, and can be used to >launch attacks on other devices on those buses? IEEE 1394, when hosts implement RFC 2734, is the same thing as IP. Windows XP incorporates "bridging" capabilities that make IP/1394 and IP/Ethernet appear to be on the same subnet as each other even though their link layers differ. If either the Ethernet segment or the IEEE 1394 segment is connected to something with routing capability to the Internet (cable modem, DSL, PPP with connection sharing, etc.) these devices meet all of your criteria above, Keith. I think this configuration exists more often than you believe and is growing. >Also, it's somewhat more reasonable for a USB or Firewire device to not >need authentication, because you're not going to find many USB or Firewire >networks with hundreds or more devices that have external Internet access. >L2-switched IP subnets with that many devices are quite common. IEEE 1394 is a serious answer for home networking solutions since it BOTH supports IP and offers quality of service (lacking in Ethernet) appropriate to video applications. To the extent that it is adopted as a solution, you will have networks with many devices that have Internet connectivity. Enough to warrant consideration. Regards, Peter Johansson Congruent Software, Inc. 98 Colorado Avenue Berkeley, CA 94707 (510) 527-3926 (510) 527-3856 FAX PJohansson@ACM.org From owner-zeroconf@merit.edu Thu Dec 12 14:59:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10197 for ; Thu, 12 Dec 2002 14:58:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 39A759122F; Thu, 12 Dec 2002 15:01:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EEF4291230; Thu, 12 Dec 2002 15:01:36 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 60CCD9122F for ; Thu, 12 Dec 2002 15:01:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 404A55DE86; Thu, 12 Dec 2002 15:01:35 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id D467D5DDEC for ; Thu, 12 Dec 2002 15:01:34 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBCK1Xj29144; Thu, 12 Dec 2002 15:01:33 -0500 (EST) Message-Id: <200212122001.gBCK1Xj29144@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Peter Johansson Cc: Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Thu, 12 Dec 2002 11:00:21 PST.") <5.1.0.14.2.20021212105241.03c816e0@PostOffice.PacBell.net> Date: Thu, 12 Dec 2002 15:01:33 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > >USB and Firewire are not the same as IP. For instance, how frequently do > >you have multiple devices on USB or Firewire that are accessible from > >anywhere in the Internet, are potentially compromised, and can be used to > >launch attacks on other devices on those buses? > > IEEE 1394, when hosts implement RFC 2734, is the same thing as IP. Windows > XP incorporates "bridging" capabilities that make IP/1394 and IP/Ethernet > appear to be on the same subnet as each other even though their link layers > differ. If either the Ethernet segment or the IEEE 1394 segment is > connected to something with routing capability to the Internet (cable > modem, DSL, PPP with connection sharing, etc.) these devices meet all of > your criteria above, Keith. I think this configuration exists more often > than you believe and is growing. Perhaps. But that doesn't reduce the need for LL devices to implement security; rather, it increases the need for firewire devices to implement security. Keith From owner-zeroconf@merit.edu Thu Dec 12 16:20:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13331 for ; Thu, 12 Dec 2002 16:20:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D217191250; Thu, 12 Dec 2002 16:23:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9188D91251; Thu, 12 Dec 2002 16:23: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 344B091250 for ; Thu, 12 Dec 2002 16:23:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 18E2A5DF2C; Thu, 12 Dec 2002 16:23:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by segue.merit.edu (Postfix) with ESMTP id D97C65DF18 for ; Thu, 12 Dec 2002 16:23:10 -0500 (EST) Received: from upstairs ([63.202.21.176]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with SMTP id <0H70001IZZELF8@mta6.snfc21.pbi.net> for zeroconf@merit.edu; Thu, 12 Dec 2002 13:23:10 -0800 (PST) Date: Thu, 12 Dec 2002 13:19:50 -0800 From: Jim Busse Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt To: "John C. Welch" , Zeroconf Message-id: <008f01c2a224$3706a560$6701a8c0@upstairs> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT John: A real-world scenario is that one host could be diseased, and that disease could be transmitted. That disease might not show up in the LL ad-hoc network, but might show up when the newly diseased host is connected to a non-LL net. If the machines and the app for transmission were authenticated, the risk would be reduced. If this authenticated app is the only app that can transmit, then the user must select the disease for transmission (the disease couldn't transmit itself, it would lack the authentication credentials necessary). Once the user has selected the disease and transmitted it, the disease is easily contained and now quickly locatable with a disease elimination device or software. If the disease is permitted to propagate itself, it could end up anywhere on the un-diseased host, making the scan more difficult and probably more time-consuming. A tightly-configured firewall won't protect you, because the disease might be inside a dll, and you probably enabled dlls to run as an app because many software programs require it, thus giving the disease access to the network (whether LL or not). Best regards, Jim ----- Original Message ----- From: "John C. Welch" To: "Zeroconf" Sent: Thursday, December 12, 2002 9:22 AM Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt > On 12/12/2002 11:24, "Keith Moore" wrote: > > >> And how many LL networks are accessible from anywhere in the Internet? > > > > "LL network" is a misnomer. LL will be imposed on essentially all > > IP networks. The hosts on those networks will still be as vulnerable > > to compromise from existing sources as they are now, and LL adds new > > vulnerabilities. > > Please, because I'm really curious. On an ad hoc network with 3 hosts(two > laptops and a printer) and a small hub, with no external connection, and no > wireless running, exactly *how* vulnerable are they in the real world? > > > > >>> Also, it's somewhat more reasonable for a USB or Firewire device to not > >>> need authentication, because you're not going to find many USB or Firewire > >>> networks with hundreds or more devices that have external Internet access. > >>> L2-switched IP subnets with that many devices are quite common. > >> > >> No, but for YEARS new printers, new consumer-level routers, new > >> wireless access points, new VoIP phones, new video conference gear > >> and many other embedded networking devices have all shipped with > >> a 192.* address. You put them on the network, point your browser at > >> them, spend five minutes reconfiguring the network settings and you > >> get on with life. The risk is not zero, but it is very very small, > >> and it sure beats trying to type in IP addresses and netmasks with > >> the three buttons on the front of the device. > > > > Initial configuration is a different story. At least if the initial > > configuration is done over a wired interface you can hook up the > > device to a network consisting of that device and another computer > > for the sake of initial configuration. > > Direct connects describe a fair chunk of ad hoc networks. > > > > > No, it's not safe to do this on a production network. I've seen an > > attack which relied on an OS being installed over the network with > > no initial root password (because the OS let you set that after > > installation) - the attacker could tell when you were finished installing > > the OS (from one of the mirror servers) and could compromise your > > computer before you got a password set. > > Um...how many devices require a complete OS Install over a network prior to > initial network/user configuration? > > john > > -- > John C. Welch > Consultant III > Administrative Computing > (617) 253 - 1368 work > (508) 579 - 7380 cell > bynkii2 AIM > > From owner-zeroconf@merit.edu Thu Dec 12 16:41:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13895 for ; Thu, 12 Dec 2002 16:41:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5754391251; Thu, 12 Dec 2002 16:44:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CE5191252; Thu, 12 Dec 2002 16:44:06 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E686D91251 for ; Thu, 12 Dec 2002 16:44:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id C632A5DF18; Thu, 12 Dec 2002 16:44:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by segue.merit.edu (Postfix) with ESMTP id A69425DEC5 for ; Thu, 12 Dec 2002 16:44:04 -0500 (EST) Received: from upstairs ([63.202.21.150]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with SMTP id <0H7100BTD0DFQG@mta6.snfc21.pbi.net> for ZeroConf@merit.edu; Thu, 12 Dec 2002 13:44:04 -0800 (PST) Date: Thu, 12 Dec 2002 13:40:44 -0800 From: Jim Busse Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt To: Keith Moore , Peter Johansson Cc: Zero Configuration Message-id: <00a201c2a227$221c4ee0$6701a8c0@upstairs> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200212122001.gBCK1Xj29144@astro.cs.utk.edu> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT From: "Keith Moore" > Perhaps. But that doesn't reduce the need for LL devices to implement > security; rather, it increases the need for firewire devices to implement > security. Keith is absolutely correct. Think about it: you connect a diseased device to your 400mbit firewire, and with the bridging to 100mbit ethernet, you will never notice the 400mbit throughput degradation while the diseased device could easily be saturating the 100mbit ethernet. Please consider the arguments in rfc3365 "Strong Security Requirements". I understand this is for Standard Protocols. The probable wide adoption of Zeroconf will make it pervasive, even if it is not a Standard Protocol, and we should take steps to add the strong security to it. I made the same argument earlier, but the author of Zeroconf requirements document was unwilling to specify the security measures necessary. Jim ----- Original Message ----- From: "Keith Moore" To: "Peter Johansson" Cc: "Zero Configuration" Sent: Thursday, December 12, 2002 12:01 PM Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt > > >USB and Firewire are not the same as IP. For instance, how frequently do > > >you have multiple devices on USB or Firewire that are accessible from > > >anywhere in the Internet, are potentially compromised, and can be used to > > >launch attacks on other devices on those buses? > > > > IEEE 1394, when hosts implement RFC 2734, is the same thing as IP. Windows > > XP incorporates "bridging" capabilities that make IP/1394 and IP/Ethernet > > appear to be on the same subnet as each other even though their link layers > > differ. If either the Ethernet segment or the IEEE 1394 segment is > > connected to something with routing capability to the Internet (cable > > modem, DSL, PPP with connection sharing, etc.) these devices meet all of > > your criteria above, Keith. I think this configuration exists more often > > than you believe and is growing. > > Perhaps. But that doesn't reduce the need for LL devices to implement > security; rather, it increases the need for firewire devices to implement > security. > > Keith From owner-zeroconf@merit.edu Thu Dec 12 17:01:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14761 for ; Thu, 12 Dec 2002 17:01:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EFDDE91254; Thu, 12 Dec 2002 17:04:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7866912E0; Thu, 12 Dec 2002 17:04: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 CE2D191254 for ; Thu, 12 Dec 2002 17:02:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9FF245DE3C; Thu, 12 Dec 2002 17:02:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 294525DE39 for ; Thu, 12 Dec 2002 17:02:38 -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 RAA04877 for ; Thu, 12 Dec 2002 17:02:37 -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 RAA03239 for ; Thu, 12 Dec 2002 17:00:33 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA00875 for ; Thu, 12 Dec 2002 16:57:25 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 12 Dec 2002 16:57:22 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <008f01c2a224$3706a560$6701a8c0@upstairs> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA14761 On 12/12/2002 16:19, "Jim Busse" wrote: > A real-world scenario is that one host could be diseased, and that disease > could be transmitted. That disease might not show up in the LL ad-hoc > network, but might show up when the newly diseased host is connected to a > non-LL net. Authentication isn't going to prevent Viral issues. You'll just have a virus from an authenticated host. Also, in my ad hoc scenario, exactly what would you be authenticating *to*? > > If the machines and the app for transmission were authenticated, the risk > would be reduced. No it wouldn't at all. Bad guys can be authenticated just like good guys. It's called lying, and bad people do it all the time. > If this authenticated app is the only app that can > transmit, then the user must select the disease for transmission (the > disease couldn't transmit itself, it would lack the authentication > credentials necessary). This is only valid if ONLY good apps can be authenticated. This is a naïve and dangerous assumption. > Once the user has selected the disease and > transmitted it, the disease is easily contained and now quickly locatable > with a disease elimination device or software. If the disease is permitted > to propagate itself, it could end up anywhere on the un-diseased host, > making the scan more difficult and probably more time-consuming. Again, authentication won't keep this from happening. > > A tightly-configured firewall won't protect you, because the disease might > be inside a dll, and you probably enabled dlls to run as an app because many > software programs require it, thus giving the disease access to the network > (whether LL or not). Well, there are firewalls that scan for virii. So it just might. But again, authentication won't do a thing to prevent viral infections. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Dec 12 17:06:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14887 for ; Thu, 12 Dec 2002 17:06:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 221DD912E0; Thu, 12 Dec 2002 17:09:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5A53912E1; Thu, 12 Dec 2002 17:09: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 C9A92912E0 for ; Thu, 12 Dec 2002 17:09:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id B1B655DDD2; Thu, 12 Dec 2002 17:09:27 -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 45A4E5DD8C for ; Thu, 12 Dec 2002 17:09:27 -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 RAA08005 for ; Thu, 12 Dec 2002 17:09:26 -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 RAA01232 for ; Thu, 12 Dec 2002 17:05:21 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA01331 for ; Thu, 12 Dec 2002 16:58:31 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 12 Dec 2002 16:58:29 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <00a201c2a227$221c4ee0$6701a8c0@upstairs> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/12/2002 16:40, "Jim Busse" wrote: > I made the same argument earlier, but the author of Zeroconf requirements > document was unwilling to specify the security measures necessary. How do you propose to specify a security mechanism that works correctly, and easily across every platform that can run Zeroconf protocols inside of ten years? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Dec 12 17:46:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16249 for ; Thu, 12 Dec 2002 17:46:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4AD04912E2; Thu, 12 Dec 2002 17:49:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 13F1091252; Thu, 12 Dec 2002 17:49: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 C5799912E2 for ; Thu, 12 Dec 2002 17:49:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D9C15DDEC; Thu, 12 Dec 2002 17:49:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by segue.merit.edu (Postfix) with ESMTP id 7ECE15DDD2 for ; Thu, 12 Dec 2002 17:49:20 -0500 (EST) Received: from upstairs ([63.205.65.178]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with SMTP id <0H7100MLI3E70M@mta6.snfc21.pbi.net> for zeroconf@merit.edu; Thu, 12 Dec 2002 14:49:20 -0800 (PST) Date: Thu, 12 Dec 2002 14:45:58 -0800 From: Jim Busse Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt To: "John C. Welch" , Zeroconf Message-id: <00c201c2a230$3f8e1040$6701a8c0@upstairs> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8BIT Thanks for your thoughts, John. I would like to reply to several: 1. >Authentication isn't going to prevent Viral issues. True, by itself. Please take the suggestions in RFC3365 as considerations to provide a more complete security implementation. Authentication is simply one of them. 2. > what would you be authenticating *to*? Authentication protocols are already available. I would suggest that one be selected (a very political thing, I'm sure) and that Zeroconf not pretend to invent yet another authentication protocol. However, after evaluating the different protocols, it may become obvious that a "zeroconfiguration" version is necessary. Since that investigation isn't done yet, this is just conjecture. 3. >It's called lying, and bad people do it all the time. Yeah, I know. I was just swindled on ebay. But in that scenario, neither the seller nor the buyer were authenticated. I'm sure I would not have been swindled if there was a security procedure for the seller. He might have lied in the authentication, but I might have caught him in one of the other protocols. In any case, if there were strong security measures in place, I'm srue I wouldn't have been swindled. Jim. ----- Original Message ----- From: "John C. Welch" To: "Zeroconf" Sent: Thursday, December 12, 2002 1:57 PM Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt On 12/12/2002 16:19, "Jim Busse" wrote: > A real-world scenario is that one host could be diseased, and that disease > could be transmitted. That disease might not show up in the LL ad-hoc > network, but might show up when the newly diseased host is connected to a > non-LL net. Authentication isn't going to prevent Viral issues. You'll just have a virus from an authenticated host. Also, in my ad hoc scenario, exactly what would you be authenticating *to*? > > If the machines and the app for transmission were authenticated, the risk > would be reduced. No it wouldn't at all. Bad guys can be authenticated just like good guys. It's called lying, and bad people do it all the time. > If this authenticated app is the only app that can > transmit, then the user must select the disease for transmission (the > disease couldn't transmit itself, it would lack the authentication > credentials necessary). This is only valid if ONLY good apps can be authenticated. This is a naïve and dangerous assumption. > Once the user has selected the disease and > transmitted it, the disease is easily contained and now quickly locatable > with a disease elimination device or software. If the disease is permitted > to propagate itself, it could end up anywhere on the un-diseased host, > making the scan more difficult and probably more time-consuming. Again, authentication won't keep this from happening. > > A tightly-configured firewall won't protect you, because the disease might > be inside a dll, and you probably enabled dlls to run as an app because many > software programs require it, thus giving the disease access to the network > (whether LL or not). Well, there are firewalls that scan for virii. So it just might. But again, authentication won't do a thing to prevent viral infections. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Dec 12 18:13:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17056 for ; Thu, 12 Dec 2002 18:13:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C22C2912E6; Thu, 12 Dec 2002 18:16:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85681912E7; Thu, 12 Dec 2002 18:16: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 B70D2912E6 for ; Thu, 12 Dec 2002 18:16:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7CCEF5DF24; Thu, 12 Dec 2002 18:16: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 10E6C5DDFA for ; Thu, 12 Dec 2002 18:16:18 -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 SAA24462 for ; Thu, 12 Dec 2002 18:16: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 SAA10012 for ; Thu, 12 Dec 2002 18:16:17 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id SAA25328 for ; Thu, 12 Dec 2002 18:16:16 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 12 Dec 2002 18:16:14 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <00c201c2a230$3f8e1040$6701a8c0@upstairs> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/12/2002 17:45, "Jim Busse" wrote: > 2. > what would you be authenticating *to*? > > Authentication protocols are already available. I would suggest that one be > selected (a very political thing, I'm sure) and that Zeroconf not pretend to > invent yet another authentication protocol. However, after evaluating the > different protocols, it may become obvious that a "zeroconfiguration" > version is necessary. Since that investigation isn't done yet, this is just > conjecture. You still need a trustable authentication authority, or you are authenticating to an untrusted host, and the process is then worse then useless, since you feel safe, even though you are not. > > 3. >It's called lying, and bad people do it all the time. > > Yeah, I know. I was just swindled on ebay. But in that scenario, neither > the seller nor the buyer were authenticated. I'm sure I would not have been > swindled if there was a security procedure for the seller. He might have > lied in the authentication, but I might have caught him in one of the other > protocols. In any case, if there were strong security measures in place, > I'm srue I wouldn't have been swindled. How would a bogus authentication prevent you from being swindled? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Dec 12 18:20:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17282 for ; Thu, 12 Dec 2002 18:20:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2D1A1912E8; Thu, 12 Dec 2002 18:23:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E21A8912E9; Thu, 12 Dec 2002 18:23:37 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BC07D912E8 for ; Thu, 12 Dec 2002 18:23:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id A97145DDFA; Thu, 12 Dec 2002 18:23:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by segue.merit.edu (Postfix) with ESMTP id 8AFC75DDAB for ; Thu, 12 Dec 2002 18:23:36 -0500 (EST) Received: from upstairs ([63.205.65.167]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with SMTP id <0H710014Q4ZB44@mta6.snfc21.pbi.net> for zeroconf@merit.edu; Thu, 12 Dec 2002 15:23:36 -0800 (PST) Date: Thu, 12 Dec 2002 15:20:18 -0800 From: Jim Busse Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt To: "John C. Welch" , Zeroconf Message-id: <00c901c2a235$0923c220$6701a8c0@upstairs> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT John: I think RFC3365 suggests a mechanism to define security requirements: from section 5, reprinted here without permission, it says: "designers really need to look at the threats to their own protocol and design appropriate counter-measures. The purpose of the "Security Considerations" Section required to be present in an RFC on the Internet Standards Track is to provide a place for protocol designers to document the threats and explain the logic to their security design." So since I agree, I think that the threats should be identified, and measures be put in place to counteract those threats, or not, depending what the designers identify as appropriate counter-measures. Probably 10 years isn't enough, because new threats may appear that need to be addressed. Therefore, I think this is kind of like your firewall with virus scan, it needs periodic updates to address new threats. Jim ----- Original Message ----- From: "John C. Welch" To: "Zeroconf" Sent: Thursday, December 12, 2002 1:58 PM Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt > On 12/12/2002 16:40, "Jim Busse" wrote: > > > I made the same argument earlier, but the author of Zeroconf requirements > > document was unwilling to specify the security measures necessary. > > How do you propose to specify a security mechanism that works correctly, and > easily across every platform that can run Zeroconf protocols inside of ten > years? > > john > > -- > John C. Welch > Consultant III > Administrative Computing > (617) 253 - 1368 work > (508) 579 - 7380 cell > bynkii2 AIM > > From owner-zeroconf@merit.edu Thu Dec 12 19:17:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18556 for ; Thu, 12 Dec 2002 19:17:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1673D9120A; Thu, 12 Dec 2002 19:20:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA7C8912E9; Thu, 12 Dec 2002 19:20: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 C20E89120A for ; Thu, 12 Dec 2002 19:20:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id B0E595DE39; Thu, 12 Dec 2002 19:20:13 -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 472555DDE3 for ; Thu, 12 Dec 2002 19:20:13 -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 TAA17576 for ; Thu, 12 Dec 2002 19:20:12 -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 TAA19987 for ; Thu, 12 Dec 2002 19:20:12 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id TAA07420 for ; Thu, 12 Dec 2002 19:20:12 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 12 Dec 2002 19:20:10 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <00c901c2a235$0923c220$6701a8c0@upstairs> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/12/2002 18:20, "Jim Busse" wrote: > So since I agree, I think that the threats should be identified, and > measures be put in place to counteract those threats, or not, depending what > the designers identify as appropriate counter-measures. > > Probably 10 years isn't enough, because new threats may appear that need to > be addressed. Therefore, I think this is kind of like your firewall with > virus scan, it needs periodic updates to address new threats. But now you are talking about permanently delaying a standard for a target that will NEVER be hit. The only logical thing is to have many warnings about security, and leave it up to the people applying and using the standard to deal with the specific implementation of security. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Dec 12 21:35:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21302 for ; Thu, 12 Dec 2002 21:35:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C5C2F91201; Thu, 12 Dec 2002 21:38:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F891912E9; Thu, 12 Dec 2002 21:38: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 4669991201 for ; Thu, 12 Dec 2002 21:38:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 21CC85DF6F; Thu, 12 Dec 2002 21:38:05 -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 987765DD93 for ; Thu, 12 Dec 2002 21:38:04 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07468; Thu, 12 Dec 2002 19:38:03 -0700 (MST) Received: from localhost (d-usca03-225-243.SFBay.Sun.COM [129.145.225.243]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id gBD2c1H09891; Fri, 13 Dec 2002 03:38:01 +0100 (MET) Date: Fri, 13 Dec 2002 03:34:40 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt To: Stuart Cheshire Cc: zeroconf@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > But the ongoing conflict detection (causing > > IP address change when a conflict appears) and broadcast replies looks > > more like a useful experiment to me. > > It has been a five-year experiment by Apple. Do you have a pointer to the data that has been collected as part of that experiment? > > The document is written as if it updates RFC 826 and DHCP (RFC 2132) but > > it doesn't explicitly say this. > > I am willing to accept specific text. How about adding This document updates RFC 826 and RFC 2132. at the end of the abstract and the end of the introduction. > > > This document standardizes the widely-used natural interpretation of > > > an ARP Request where the Target Protocol Address is non-zero but the > > > > While this might be natural, I have no idea whether or not it is > > widely used. Wants me want to ask for the survey results of 50 ARP > > implementations and how they do this. > > This is the interpretation required by DHCP (RFC 2131), so I would hope > it is widely used, at least to the extent that DHCP clients are widely > used. You're right. Thanks. > > Same general question as above, except that there is another > > natural case - that an ARP Reply where the sender and targer > > are the same. Given that ARP is widely implemented it would be > > useful to understand 1) to what extent implementations do > > announcements using requests or replies, and depending on that answer > > 2) whether the protocol could allow both forms of annoucements i.e. > > any packet with equal sender protocol address and target protocol address > > would be an announcement. > > This is the interpretation described in Stevens (TCP/IP Illustrated, > 1994) under the name "Gratuitous ARP" and described as being widely used > at that time. > > It is also required by RFC 2131. RFC 2131 actually talks about an ARP reply and not the ARP request with sender=target. See section 4.4.1 in RFC 2131. So you don't seem to be consistent with RFC 2131. > > It is perhaps better to have some statement up front that this > > protocol is a subset of the address conflict detection of v4LL. > > I would rather the merits of this document be considered alone, without > normative reference to other unpublished specifications. I wasn't suggesting a normative reference; that isn't needed since the document is self-contained. But pointing out the relationship using a non-normative reference to draft-ietf-zeroconf-ipv6-link-local would be useful for the implementors that are going to implement both. > > The above is the only place where multihoming comes into the spec by > > mentioning "any of the host's interfaces". > > No, it is also mentioned in 2.4: > > Address conflict detection should not be limited to only the time of > initial interface configuration, when a host is sending ARP probes. > Address conflict detection is an ongoing process that is in effect > for as long as a host is using an address. At any time, if a host > receives an ARP packet (request *or* reply) where the 'sender IP > address' is the host's own IP address, but the 'sender hardware > address' does not match any of the host's own interface addresses, > then this is a conflicting ARP packet, indicating some other host > also thinks it is validly using this address. I fail to find the word "multihoming" or any explicit mention of multiple interfaces in the above text. > > I would assume that ACD can > > operate independently for each interface even though v4LL has some > > extra stuff related to multi-interface nodes. > > No, the specification needs to deal with the case when a host has two > interfaces (say wireless and Ethernet) on the same link. And you claim you can't do that by having the interfaces be configured independently of eachother? > > Section 2.2 on timeouts seems to not work. > > The 802.1d standard suggests default timers which result in it > > taking about 30 seconds until a switch port passes traffic after > > it has been enabled. I've personally observed more like 45 seconds > > when my office Ethernet drop has had spanning tree protocol enabled. > > We live in a world of gigabit Ethernet and gigahertz processors. The days > when people were willing to wait 30 seconds for their television set to > "warm up" are behind us. We need to provide computers and network devices > that can meet the same customer expectations. I think my conclusion was that the time should be shorter than 8 seconds and not longer. 8 seconds is a useless compromise as far as I can tell since it is unecessarily long when STP isn't triggered and too short when STP is triggered (with out of the box bridge configurations.) Thus 2 or 3 seconds should be fine. > Most network operators today, with good reason, set their port blocking > time to five seconds. Doesn't match my experience. And doesn't match the IEEE 802.1D recommendation. > I am also working with the IEEE 802 committees on an update to rapid > spanning tree that allows a host to reliably determine when link > connectivity has been established, within 2.5 seconds of connection. When > a Mac determines that it is connected to one of these newer switches, and > confirms that proper link connectivity has been established, it will then > start probing using the shorter timeouts given in Section 2.2. Is there a way for the host to reliably detect whether the switches run RSTP instead of STP? > A Zero Configuration device may want to make use of address conflict > detection. If address conflict detection requires a mandatory > user-configuration option, then that means that Zero Configuration > devices require mandatory user-configuration options, a > self-contradiction. I'd understand that comment if it was about draft-ietf-zeroconf-ipv4-link-local but not about the ACD document. Since the addresses are configured either manually or by DHCP (or some other provisioning protocol) it is possible to add a knob in the manual config or in DHCP, respectively. So I don't understand the issue your are concerned about. Erik From owner-zeroconf@merit.edu Thu Dec 12 22:46:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27087 for ; Thu, 12 Dec 2002 22:46:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 862E1912EB; Thu, 12 Dec 2002 22:49:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E9D3912EC; Thu, 12 Dec 2002 22:49: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 14DEC912EB for ; Thu, 12 Dec 2002 22:48:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id F07C15DE55; Thu, 12 Dec 2002 22:48:55 -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 729A25DEC5 for ; Thu, 12 Dec 2002 22:48:55 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id gBD3mOPw011205; Thu, 12 Dec 2002 20:48:24 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id UAA11272; Thu, 12 Dec 2002 20:48:48 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gBD3mh7C024158; Fri, 13 Dec 2002 14:48:45 +1100 (EST) Message-ID: <3DF9589F.1030608@motorola.com> Date: Fri, 13 Dec 2002 14:48:47 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Busse Cc: Keith Moore , Peter Johansson , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt References: <200212122001.gBCK1Xj29144@astro.cs.utk.edu> <00a201c2a227$221c4ee0$6701a8c0@upstairs> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jim Busse wrote: > Please consider the arguments in rfc3365 "Strong Security Requirements". I > understand this is for Standard Protocols. The probable wide adoption of > Zeroconf will make it pervasive, even if it is not a Standard Protocol, and > we should take steps to add the strong security to it. > I for one would benefit from any concrete suggestions you might have as to specific security mechanisms that could be added to IPv4-LL. > I made the same argument earlier, but the author of Zeroconf requirements > document was unwilling to specify the security measures necessary. > I'm not sure I understand what you mean. I can see how a protocol document might specify the security mechanisms/measures to counter specific threats but I don't understand what mechanisms you are wanting to see in the requirements document. Again, a specific suggestion (feel free to knock up some text) would be appreciated. Perhaps a paragraph citing RFC3365 would suffice? - aidan From owner-zeroconf@merit.edu Fri Dec 13 01:20:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06300 for ; Fri, 13 Dec 2002 01:20:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9AFA0912EC; Fri, 13 Dec 2002 01:23:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6A1BE912ED; Fri, 13 Dec 2002 01:23: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 278E8912EC for ; Fri, 13 Dec 2002 01:23:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 15EAD5DF83; Fri, 13 Dec 2002 01:23:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by segue.merit.edu (Postfix) with ESMTP id EA8155DE2B for ; Fri, 13 Dec 2002 01:23:39 -0500 (EST) Received: from upstairs ([63.202.23.159]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 HotFix 1.6 (built Oct 18 2002)) with SMTP id <0H71009E2OFEFM@mta6.snfc21.pbi.net> for ZeroConf@merit.edu; Thu, 12 Dec 2002 22:23:39 -0800 (PST) Date: Thu, 12 Dec 2002 22:19:18 -0800 From: Jim Busse Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt To: Aidan Williams Cc: Keith Moore , Peter Johansson , Zero Configuration Message-id: <00f201c2a26f$91bf5420$6701a8c0@upstairs> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <200212122001.gBCK1Xj29144@astro.cs.utk.edu> <00a201c2a227$221c4ee0$6701a8c0@upstairs> <3DF9589F.1030608@motorola.com> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT Aidan: Thank you for responding. On 5/5/30 2002, at 4:01PM, I wrote to you: "....securing of a Zeroconf Network. Please consider these comments: "...the risks need to be identified, with the methods clarified in the requirements and protocol drafts to secure against these risks. Where there's no security methods identified, , then, or where it's external to the Zeroconf requirements or link-local drafts, will be obvious to the implementers, and not implied. I think, although requirements draft 10 says "implications", the "implication" to my device or implementation may not be clear. Also, just to say "messages...are authenticated" again is not sufficient. I think we should say how they are authenticated. "I know it's a big job, but I think it's time the IETF protocol developers start considering as many of the security aspects of their work as possible". I was very very pleased when I read RFC3365. In that 5/5 email, I went on to try to identify the attack categorization, which I really haven't thought about since then, because of your feedback, ("I am reticent to include what could amount to an entire textbook of network security into the requirements draft") and the lack of responses from any of the other cc'd individuals. Based on your email below, I would like to pursue this issue further. Even though I have architected and helped implement a remotely-configurable firewall, been involved with the development of voice and fingerprint authentication for PC clients, and with Intel's IPAA implementation, I am no "security expert", and probably can't do a sufficient job. With your agreement, I would like to take the issue up with the IETF Security Area working group, and probably specifically with the IP Security Remote Access sub-group, to see if we can come up with some wording for both the LL and Zeroconf requirements drafts. Best Regards Jim ----- Original Message ----- From: "Aidan Williams" To: "Jim Busse" Cc: "Keith Moore" ; "Peter Johansson" ; "Zero Configuration" Sent: Thursday, December 12, 2002 7:48 PM Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt > Jim Busse wrote: > > Please consider the arguments in rfc3365 "Strong Security Requirements". I > > understand this is for Standard Protocols. The probable wide adoption of > > Zeroconf will make it pervasive, even if it is not a Standard Protocol, and > > we should take steps to add the strong security to it. > > > > I for one would benefit from any concrete suggestions you might have > as to specific security mechanisms that could be added to IPv4-LL. > > > I made the same argument earlier, but the author of Zeroconf requirements > > document was unwilling to specify the security measures necessary. > > > > I'm not sure I understand what you mean. I can see how a protocol > document might specify the security mechanisms/measures to counter > specific threats but I don't understand what mechanisms you are > wanting to see in the requirements document. Again, a specific > suggestion (feel free to knock up some text) would be appreciated. > Perhaps a paragraph citing RFC3365 would suffice? > > - aidan > From owner-zeroconf@merit.edu Fri Dec 13 01:43:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06681 for ; Fri, 13 Dec 2002 01:43:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1A079912ED; Fri, 13 Dec 2002 01:45:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85AED912EE; Fri, 13 Dec 2002 01:45: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 E0096912ED for ; Fri, 13 Dec 2002 01:45:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 764025DF95; Fri, 13 Dec 2002 01:45:18 -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 ABE8D5DE2B for ; Fri, 13 Dec 2002 01:45:17 -0500 (EST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id gBD6ilPw003237; Thu, 12 Dec 2002 23:44:47 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id XAA22072; Thu, 12 Dec 2002 23:45:11 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gBD6j97C002991; Fri, 13 Dec 2002 17:45:10 +1100 (EST) Message-ID: <3DF981F9.9040002@motorola.com> Date: Fri, 13 Dec 2002 17:45:13 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Busse Cc: Keith Moore , Peter Johansson , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt References: <200212122001.gBCK1Xj29144@astro.cs.utk.edu> <00a201c2a227$221c4ee0$6701a8c0@upstairs> <3DF9589F.1030608@motorola.com> <00f201c2a26f$91bf5420$6701a8c0@upstairs> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jim Busse wrote: > In that 5/5 email, I went on to try to identify the attack categorization, > which I really haven't thought about since then, because of your feedback, > ("I am reticent to include what could amount to an entire textbook of > network security into the requirements draft") and the lack of responses > from any of the other cc'd individuals. Based on your email below, I would > like to pursue this issue further. > To quote more fully from my response: | What aspects of these categories change when a network | starts using zeroconf protocols? | | I'm reticent to include what could amount to an entire | textbook of network security information into the | requirements draft. | | On the other hand, I don't want to miss any gotchas. I would again encourage consideration of the security aspects that are specific to or introduced by zeroconf protocols. If you think there is a need for general security guidance (ie security issues that are not specific to zeroconf protocols) then I think we can cover that with references to books or RFCs in the area. Suggestions are welcome. > I would like to take the issue up with the IETF Security Area > working group, and probably specifically with the IP Security Remote Access > sub-group, to see if we can come up with some wording for both the LL and > Zeroconf requirements drafts. > Input from people willing to improve or develop security requirements for zeroconf protocols would be most welcome. Perhaps you could say more about how ipsra would be relevant. - aidan From owner-zeroconf@merit.edu Fri Dec 13 11:59:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28376 for ; Fri, 13 Dec 2002 11:59:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C7D9891218; Fri, 13 Dec 2002 12:01:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5DB79121D; Fri, 13 Dec 2002 12:01: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 D4B9991218 for ; Fri, 13 Dec 2002 12:01:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id D51BE5DF6D; Fri, 13 Dec 2002 12:01:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 72EDC5DF4A for ; Fri, 13 Dec 2002 12:01:29 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBDH1Fj04978; Fri, 13 Dec 2002 12:01:22 -0500 (EST) Message-Id: <200212131701.gBDH1Fj04978@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Aidan Williams Cc: Jim Busse , Keith Moore , Peter Johansson , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Fri, 13 Dec 2002 14:48:47 +1100.") <3DF9589F.1030608@motorola.com> Date: Fri, 13 Dec 2002 12:01:15 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > Please consider the arguments in rfc3365 "Strong Security Requirements". I > > understand this is for Standard Protocols. The probable wide adoption of > > Zeroconf will make it pervasive, even if it is not a Standard Protocol, and > > we should take steps to add the strong security to it. > > I for one would benefit from any concrete suggestions you might have > as to specific security mechanisms that could be added to IPv4-LL. the simplest suggestion is the one that is consistently overlooked - to not impose v4LL by default, on hosts or networks that don't want to use it. then you can really start thinking of the risks of v4LL in terms of "ad hoc IPv4 networks" rather than in terms of "all IPv4 networks" Keith From owner-zeroconf@merit.edu Fri Dec 13 12:19:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28835 for ; Fri, 13 Dec 2002 12:19:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7EE599121D; Fri, 13 Dec 2002 12:21:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 46A2E9121F; Fri, 13 Dec 2002 12:21: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 4CAEF9121D for ; Fri, 13 Dec 2002 12:21:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2AD7A5DF6D; Fri, 13 Dec 2002 12:21:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id A026B5DF6C for ; Fri, 13 Dec 2002 12:21:45 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gBDHLiw22277 for ; Fri, 13 Dec 2002 09:21:44 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Dec 2002 09:21:20 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id gBDHLhs29221; Fri, 13 Dec 2002 09:21:43 -0800 (PST) Date: Fri, 13 Dec 2002 09:21:40 -0800 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Zero Configuration To: Keith Moore From: Joshua Graessley In-Reply-To: <200212131701.gBDH1Fj04978@astro.cs.utk.edu> Message-Id: <580569FC-0EBF-11D7-9497-000393760260@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, December 13, 2002, at 09:01 AM, Keith Moore wrote: >>> Please consider the arguments in rfc3365 "Strong Security >>> Requirements". I >>> understand this is for Standard Protocols. The probable wide >>> adoption of >>> Zeroconf will make it pervasive, even if it is not a Standard >>> Protocol, and >>> we should take steps to add the strong security to it. >> >> I for one would benefit from any concrete suggestions you might have >> as to specific security mechanisms that could be added to IPv4-LL. > > the simplest suggestion is the one that is consistently overlooked - > to not impose v4LL by default, on hosts or networks that > don't want to use it. > > then you can really start thinking of the risks of v4LL in terms of > "ad hoc IPv4 networks" rather than in terms of "all IPv4 networks" I'm not really sure how IPv4LL security issues relates to Stuart's address conflict detection draft, perhaps the subject needs to be changed. I don't see how "not impos[ing] v4LL by default, on hosts or network that don't want to use it" will change the scope of security issues. This won't limit the use of IPv4LL addresses to just ad hoc networks. IPv4LL is useful on all IPv4 networks especially for initially configuring a device and for devices that simply don't need global addresses. IPv4LL is a way for devices to acquire addresses for communication on the local-link in the absence of configured addresses. As Aidan Williams suggested, I think any security discussion should focus on the issues that are specific to or introduced by IPv4LL addresses. -josh From owner-zeroconf@merit.edu Fri Dec 13 12:27:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29058 for ; Fri, 13 Dec 2002 12:27:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A452191224; Fri, 13 Dec 2002 12:30:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D302912EE; Fri, 13 Dec 2002 12:30: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 A708691224 for ; Fri, 13 Dec 2002 12:30:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD3015DF4A; Fri, 13 Dec 2002 12:30:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id C9C2B5DEFD for ; Fri, 13 Dec 2002 12:30:04 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBDHTwj05884; Fri, 13 Dec 2002 12:29:58 -0500 (EST) Message-Id: <200212131729.gBDHTwj05884@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Keith Moore , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Fri, 13 Dec 2002 09:21:40 PST.") <580569FC-0EBF-11D7-9497-000393760260@apple.com> Date: Fri, 13 Dec 2002 12:29:58 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > I don't see how "not impos[ing] v4LL by default, on hosts or network > that don't want to use it" will change the scope of security issues. > This won't limit the use of IPv4LL addresses to just ad hoc networks. okay, fine. but you either need to limit v4LL to ad hoc networks, or you need to figure out how to introduce v4LL to all IP networks without compromising the security of those networks. and no, you can't reasonably assume that all or even most of the threats are not on the local link. at least if v4LL were easily disabled then networks would have an effective countermeasure to those additional threats. Keith From owner-zeroconf@merit.edu Fri Dec 13 12:46:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29535 for ; Fri, 13 Dec 2002 12:46:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DE6E7912EE; Fri, 13 Dec 2002 12:49:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1B2D912EF; Fri, 13 Dec 2002 12:49:01 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 796BD912EE for ; Fri, 13 Dec 2002 12:47:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4D2465DDE0; Fri, 13 Dec 2002 12:47:08 -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 D63625DDB2 for ; Fri, 13 Dec 2002 12:47:07 -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 MAA08473 for ; Fri, 13 Dec 2002 12:47:07 -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 MAA03634 for ; Fri, 13 Dec 2002 12:47:07 -0500 (EST) Received: from [18.18.3.76] (WINDEL1.MIT.EDU [18.18.3.76]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA08602 for ; Fri, 13 Dec 2002 12:47:05 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 Dec 2002 12:47:04 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212131729.gBDHTwj05884@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/13/2002 12:29, "Keith Moore" wrote: >> I don't see how "not impos[ing] v4LL by default, on hosts or network >> that don't want to use it" will change the scope of security issues. >> This won't limit the use of IPv4LL addresses to just ad hoc networks. > > okay, fine. but you either need to limit v4LL to ad hoc networks, > or you need to figure out how to introduce v4LL to all IP networks > without compromising the security of those networks. and no, you > can't reasonably assume that all or even most of the threats are not > on the local link. > > at least if v4LL were easily disabled then networks would have an > effective countermeasure to those additional threats. Um...and how do you propose to enforce this? You can't, you aren't, and it won't happen. If you are going to require that LL be disabled by default, or turn itself off and require manual reactivation in the presence of other configuration methods, then why bother with it at all. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Dec 13 14:16:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02320 for ; Fri, 13 Dec 2002 14:16:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E3F11912F3; Fri, 13 Dec 2002 14:19:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF129912F4; Fri, 13 Dec 2002 14:19: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 B738A912F3 for ; Fri, 13 Dec 2002 14:18:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 97C145DF04; Fri, 13 Dec 2002 14:18: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 1CC4C5DEB9 for ; Fri, 13 Dec 2002 14:18:15 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gBDJIAI19081 for ; Fri, 13 Dec 2002 11:18:10 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Dec 2002 11:17:45 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id gBDJI9f07634; Fri, 13 Dec 2002 11:18:09 -0800 (PST) Date: Fri, 13 Dec 2002 11:18:09 -0800 Subject: IPv4LL security threats? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Zero Configuration To: Keith Moore From: Joshua Graessley In-Reply-To: <200212131729.gBDHTwj05884@astro.cs.utk.edu> Message-Id: <9D9134B8-0ECF-11D7-9497-000393760260@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, December 13, 2002, at 09:29 AM, Keith Moore wrote: >> I don't see how "not impos[ing] v4LL by default, on hosts or network >> that don't want to use it" will change the scope of security issues. >> This won't limit the use of IPv4LL addresses to just ad hoc networks. > > okay, fine. but you either need to limit v4LL to ad hoc networks, > or you need to figure out how to introduce v4LL to all IP networks > without compromising the security of those networks. and no, you > can't reasonably assume that all or even most of the threats are not > on the local link. Are there specific security issues you are referring to? > at least if v4LL were easily disabled then networks would have an > effective countermeasure to those additional threats. What threats? The Security Considerations section lists two threats: 1) IPv4LL addresses may open a network host to attacks by giving it an IP address where it may not have had an IP address before. 2) ARP is insecure so a host using IPv4 may be unable to allocate an address if a misbehaved/malicious host claims all addresses. In both of these cases, the threats are to hosts that are actually acquiring an IPv4LL address. The first is really only applicable to a host that would not otherwise have an IP address and is just a general warning that connectivity comes with risks. The second threat is a case that may render a host unable to acquire an IPv4LL address. In what way does introducing IPv4LL addresses compromise the security of a network? -josh From owner-zeroconf@merit.edu Fri Dec 13 14:17:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02468 for ; Fri, 13 Dec 2002 14:17:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 44057912F4; Fri, 13 Dec 2002 14:20:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F50A912F5; Fri, 13 Dec 2002 14:20:17 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D5393912F4 for ; Fri, 13 Dec 2002 14:20:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id BD5F45DF04; Fri, 13 Dec 2002 14:20:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 5EF915DEB9 for ; Fri, 13 Dec 2002 14:20:16 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBDJK0j06071; Fri, 13 Dec 2002 14:20:00 -0500 (EST) Message-Id: <200212131920.gBDJK0j06071@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Keith Moore , Zero Configuration Subject: Re: IPv4LL security threats? In-reply-to: (Your message of "Fri, 13 Dec 2002 11:18:09 PST.") <9D9134B8-0ECF-11D7-9497-000393760260@apple.com> Date: Fri, 13 Dec 2002 14:20:00 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > > okay, fine. but you either need to limit v4LL to ad hoc networks, > > or you need to figure out how to introduce v4LL to all IP networks > > without compromising the security of those networks. and no, you > > can't reasonably assume that all or even most of the threats are not > > on the local link. > > Are there specific security issues you are referring to? yes. do you really expect me to list them all again? Keith From owner-zeroconf@merit.edu Fri Dec 13 15:58:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05056 for ; Fri, 13 Dec 2002 15:58:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD8FD912F9; Fri, 13 Dec 2002 16:00:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 651E2912FA; Fri, 13 Dec 2002 16:00: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 4C96C912F9 for ; Fri, 13 Dec 2002 16:00:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 65D205E00C; Fri, 13 Dec 2002 16:00:18 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by segue.merit.edu (Postfix) with ESMTP id 2A71C5E000 for ; Fri, 13 Dec 2002 16:00:17 -0500 (EST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 13 Dec 2002 13:00:13 -0800 Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 13 Dec 2002 13:00:16 -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); Fri, 13 Dec 2002 13:00:16 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 13 Dec 2002 13:00:15 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Fri, 13 Dec 2002 13:00:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IESG draft-cheshire-ipv4-acd-02.txt Date: Fri, 13 Dec 2002 13:00:13 -0800 Message-ID: Thread-Topic: IESG draft-cheshire-ipv4-acd-02.txt Thread-Index: AcKizCyQsx4Cucj1Q52QaXceq84wAwAHaoLQ From: "Christian Huitema" To: "Joshua Graessley" , "Keith Moore" Cc: "Zero Configuration" X-OriginalArrivalTime: 13 Dec 2002 21:00:12.0879 (UTC) FILETIME=[A11BB5F0:01C2A2EA] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA05056 > I don't see how "not impos[ing] v4LL by default, on hosts or network > that don't want to use it" will change the scope of security issues. > This won't limit the use of IPv4LL addresses to just ad hoc networks. > IPv4LL is useful on all IPv4 networks especially for initially > configuring a device and for devices that simply don't need global > addresses. I very much doubt that. We already have IPv6 link local, which provides you with a solid "on link" solution, without having to rely on short random numbers and error-prone collision detection. The classic argument against relying on IPv6 is that the infrastructure is not ready; but in the case of link-local, there is no infrastructure. So, if you want new features, you can just use IPv6. The real argument for IPv4 link-local cannot be to provide hosts with new features -- we have IPv6 for that. The only argument is some form of compatibility with legacy IPv4 only devices. But if you focus on legacy, then you don't want to deal with stuff that the legacy cannot handle well, e.g. having multiple addresses per interface, or having multiple subnets on the same link. (Or, for that matter, playing game with the TTL value.) -- Christian Huitema From owner-zeroconf@merit.edu Fri Dec 13 17:55:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08182 for ; Fri, 13 Dec 2002 17:55:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CB71E91240; Fri, 13 Dec 2002 17:58:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93026912E1; Fri, 13 Dec 2002 17:58: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 76BB091240 for ; Fri, 13 Dec 2002 17:58:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5A0105DEBD; Fri, 13 Dec 2002 17:58: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 D44D95DE0B for ; Fri, 13 Dec 2002 17:58:00 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gBDMw0w08577 for ; Fri, 13 Dec 2002 14:58:00 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 13 Dec 2002 14:57:35 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id gBDMvxs25997 for ; Fri, 13 Dec 2002 14:57:59 -0800 (PST) Date: Fri, 13 Dec 2002 14:57:58 -0800 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) From: Joshua Graessley To: Zero Configuration Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <52B1CB4E-0EEE-11D7-BCE9-000393760260@apple.com> X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, December 13, 2002, at 01:00 PM, Christian Huitema wrote: >> I don't see how "not impos[ing] v4LL by default, on hosts or network >> that don't want to use it" will change the scope of security issues. >> This won't limit the use of IPv4LL addresses to just ad hoc networks. >> IPv4LL is useful on all IPv4 networks especially for initially >> configuring a device and for devices that simply don't need global >> addresses. > > I very much doubt that. We already have IPv6 link local, which provides > you with a solid "on link" solution, without having to rely on short > random numbers and error-prone collision detection. The classic > argument > against relying on IPv6 is that the infrastructure is not ready; but in > the case of link-local, there is no infrastructure. So, if you want new > features, you can just use IPv6. The amount of work required to support IPv4LL on a device that already implements IPv4 is trivial compared to the amount of work required to support IPv6. On the other hand, the IPv6 APIs give developers scope IDs so link-local can be supported on more than one interface without the nightmare of a link-local address being ambiguous on a multi-homed host. > The real argument for IPv4 link-local cannot be to provide hosts with > new features -- we have IPv6 for that. The only argument is some form > of > compatibility with legacy IPv4 only devices. But if you focus on > legacy, > then you don't want to deal with stuff that the legacy cannot handle > well, e.g. having multiple addresses per interface, or having multiple > subnets on the same link. (Or, for that matter, playing game with the > TTL value.) IPv6LL is great. Unfortunately, IPv6 stacks are not that common. IPv4LL gives us a solution with just a little work while people go through the huge effort required to write an IPv6 stack or while they wait for IPv6 support in the embedded OS of their choice. In addition, many IPv4 application will work with IPv4LL addresses without modification, despite arguments to the contrary from Keith Moore. To take advantage of IPv6LL, an application must be rewritten. The IPv6 APIs have the notion of a scope id. This is important for IPv6LL addresses. Unfortunately, there doesn't appear to be a good way to discover an IPv6LL address with it's scope id. IPv6LL addresses probably shouldn't appear in unicast DNS packets. Most service discovery protocols resolve services in to URLs which usually don't contain scope ids. This leaves us with the option of manually entering IPv6LL addresses, which isn't much fun. Until this is addressed, IPv6LL addresses probably won't be as useful as they ought to be, IMHO. -josh From owner-zeroconf@merit.edu Fri Dec 13 19:03:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10696 for ; Fri, 13 Dec 2002 19:03:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8ED9A912E1; Fri, 13 Dec 2002 19:06:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 540DB912FE; Fri, 13 Dec 2002 19:06: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 2FF83912E1 for ; Fri, 13 Dec 2002 19:06:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 12BDD5E016; Fri, 13 Dec 2002 19:06:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id A869E5E018 for ; Fri, 13 Dec 2002 19:06:13 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBE069j06517; Fri, 13 Dec 2002 19:06:09 -0500 (EST) Message-Id: <200212140006.gBE069j06517@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Fri, 13 Dec 2002 14:57:58 PST.") <52B1CB4E-0EEE-11D7-BCE9-000393760260@apple.com> Date: Fri, 13 Dec 2002 19:06:09 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > IPv6LL is great. Unfortunately, IPv6 stacks are not that common. every major OS vendor except Palm is shipping them. >IPv4LL gives us a solution with just a little work just a little work for the IPv4 stack. LOTS of work to keep v4LL from causing problems for applicaitions and networks. but of course that's "somebody else's problem". > In addition, many IPv4 > application will work with IPv4LL addresses without modification, > despite arguments to the contrary from Keith Moore. you're misstating my argument. just because "many" apps will work doesn't mean that v4LL won't cause lots of problems. > To take advantage > of IPv6LL, an application must be rewritten. and to avoid having v4LL cause problems, many applications need at least the same amount of rewriting. > The IPv6 APIs have the notion of a scope id. This is important for > IPv6LL addresses. Unfortunately, there doesn't appear to be a good way > to discover an IPv6LL address with it's scope id. IPv6LL addresses > probably shouldn't appear in unicast DNS packets. for that matter, neither should v4LL addresses. another nice thing about v6LL's is that v6 folks don't pretend they're suitable for all or even most applications. Keith From owner-zeroconf@merit.edu Fri Dec 13 19:18:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10956 for ; Fri, 13 Dec 2002 19:18:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9E833912FE; Fri, 13 Dec 2002 19:21:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 69D8B912FF; Fri, 13 Dec 2002 19:21:11 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C900912FE for ; Fri, 13 Dec 2002 19:21:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4EF1E5E016; Fri, 13 Dec 2002 19:21:10 -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 CA9FD5E013 for ; Fri, 13 Dec 2002 19:21:09 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gBE0L9I21576 for ; Fri, 13 Dec 2002 16:21:09 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 13 Dec 2002 16:21:07 -0800 Received: from [17.202.45.246] (il0204a-dhcp118.apple.com [17.202.45.246]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id gBE0L7f12982; Fri, 13 Dec 2002 16:21:07 -0800 (PST) Message-Id: <200212140021.gBE0L7f12982@scv3.apple.com> Subject: RE: IPv4 link-local (was unrelated subject line) Date: Fri, 13 Dec 2002 16:20:58 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Christian Huitema" , "Zero Configuration" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >I very much doubt that. We already have IPv6 link local, which >provides you with a solid "on link" solution, without having to >rely on short random numbers and error-prone collision detection. >The classic argument against relying on IPv6 is that the >infrastructure is not ready; but in the case of link-local, there >is no infrastructure. So, if you want new features, you can just >use IPv6. Your classic argument is not the only argument. The other factor which affects all this is that we are trying to convince makers of all sorts of USB devices to make Ethernet devices instead. The $49 ink-jet printer is the common example, but not the only example. I'm sure many people on this list would like to be able to buy a networked printer for $49 instead of the $300-$500 it costs today. We are having a lot of success, but with these vendors trying to convince them of the benefit of IP at all is sometimes a battle; convincing them to adopt the unfamiliar (to them) IPv6 is that much harder battle. Consequently, while Macs and Wintel PCs have IPv6 already, a lot of the devices we want to connect to do not have IPv6 today, and probably will not have IPv6 for a year or two. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Dec 13 19:22:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11002 for ; Fri, 13 Dec 2002 19:22:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C91DD912FF; Fri, 13 Dec 2002 19:25:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9059591300; Fri, 13 Dec 2002 19:25: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 96E8F912FF for ; Fri, 13 Dec 2002 19:25:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 74E805E00C; Fri, 13 Dec 2002 19:25:32 -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 ECE455DDE0 for ; Fri, 13 Dec 2002 19:25:31 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gBE0PVw25647 for ; Fri, 13 Dec 2002 16:25:31 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 13 Dec 2002 16:25:06 -0800 Received: from [17.202.45.246] (il0204a-dhcp118.apple.com [17.202.45.246]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id gBE0PUs00982; Fri, 13 Dec 2002 16:25:30 -0800 (PST) Message-Id: <200212140025.gBE0PUs00982@scv1.apple.com> Subject: RE: IPv4 link-local (was unrelated subject line) Date: Fri, 13 Dec 2002 16:25:21 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Christian Huitema" Cc: "Zero Configuration" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >The real argument for IPv4 link-local cannot be to provide hosts >with new features -- we have IPv6 for that. The only argument is >some form of compatibility with legacy IPv4 only devices. But if >you focus on legacy, then you don't want to deal with stuff that >the legacy cannot handle well, e.g. having multiple addresses per >interface, or having multiple subnets on the same link. (Or, for >that matter, playing game with the TTL value.) I don't know any current mainstream OS that can't handle two addresses on an interface. I don't know any current mainstream OS that can't handle two subnets on the same physical link. I don't know any current mainstream OS that can't set the IP TTL to 255. The point of networking is not just to talk to other copies of your own product (that part is easy), but to talk to all the other products out there. If we only cared about Macs talking to other Macs, then IPv6LL on every interface would be fine, but Macs need to talk to a whole bunch of much simpler devices too, so that's why we need v4LL too. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Dec 13 19:43:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11548 for ; Fri, 13 Dec 2002 19:43:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E43DA9121F; Fri, 13 Dec 2002 19:46:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DC6D912F0; Fri, 13 Dec 2002 19:46: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 13AF29121F for ; Fri, 13 Dec 2002 19:46:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id E380D5E016; Fri, 13 Dec 2002 19:46:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 85D045E015 for ; Fri, 13 Dec 2002 19:46:32 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBE0kRj06685; Fri, 13 Dec 2002 19:46:27 -0500 (EST) Message-Id: <200212140046.gBE0kRj06685@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: "Christian Huitema" , "Zero Configuration" Subject: Re: IPv4 link-local (was unrelated subject line) In-reply-to: (Your message of "Fri, 13 Dec 2002 16:25:21 PST.") <200212140025.gBE0PUs00982@scv1.apple.com> Date: Fri, 13 Dec 2002 19:46:27 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > If we only cared about Macs talking to other Macs, then IPv6LL on > every interface would be fine, but Macs need to talk to a whole bunch of > much simpler devices too, so that's why we need v4LL too. if you're optimizing for simpler devices, v6LL is even simpler to implement than v4LL. more generally, v6 autoconfiguration is simpler to implement than v4 DHCP. Keith From owner-zeroconf@merit.edu Fri Dec 13 19:46:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11579 for ; Fri, 13 Dec 2002 19:46:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AD51891300; Fri, 13 Dec 2002 19:49:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C67D1912F0; Fri, 13 Dec 2002 19:49: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 6B6BE91300 for ; Fri, 13 Dec 2002 19:49:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 52AE85DF39; Fri, 13 Dec 2002 19:49:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id EA00A5DDD4 for ; Fri, 13 Dec 2002 19:49:00 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBE0muj06705; Fri, 13 Dec 2002 19:48:56 -0500 (EST) Message-Id: <200212140048.gBE0muj06705@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: "Christian Huitema" , "Zero Configuration" Subject: Re: IPv4 link-local (was unrelated subject line) In-reply-to: (Your message of "Fri, 13 Dec 2002 16:20:58 PST.") <200212140021.gBE0L7f12982@scv3.apple.com> Date: Fri, 13 Dec 2002 19:48:56 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > The other factor which affects all this is that we are trying to convince > makers of all sorts of USB devices to make Ethernet devices instead. The > $49 ink-jet printer is the common example, but not the only example. I'm > sure many people on this list would like to be able to buy a networked > printer for $49 instead of the $300-$500 it costs today. > > We are having a lot of success, but with these vendors trying to convince > them of the benefit of IP at all is sometimes a battle; convincing them > to adopt the unfamiliar (to them) IPv6 is that much harder battle. well, if you're trying to convince those vendors that it's acceptable to implement Ethernet/IP/LL instead of USB and that they don't have to deal with security when they do so, I wish you'd stop. similarly, if you're trying to get them to adopt a version of IP that is fast becoming obsolete, I wish you'd stop that too. Keith From owner-zeroconf@merit.edu Fri Dec 13 19:52:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11731 for ; Fri, 13 Dec 2002 19:52:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B7543912F0; Fri, 13 Dec 2002 19:55:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84AEC91301; Fri, 13 Dec 2002 19:55: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 6CC0E912F0 for ; Fri, 13 Dec 2002 19:55:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 545425DE2F; Fri, 13 Dec 2002 19:55: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 DFAC85DDD4 for ; Fri, 13 Dec 2002 19:55:22 -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 TAA14525 for ; Fri, 13 Dec 2002 19:55: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 TAA12961 for ; Fri, 13 Dec 2002 19:55:21 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id TAA07213 for ; Fri, 13 Dec 2002 19:51:36 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 Dec 2002 19:51:35 -0500 Subject: Re: IPv4 link-local (was unrelated subject line) From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212140046.gBE0kRj06685@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/13/2002 19:46, "Keith Moore" wrote: >> If we only cared about Macs talking to other Macs, then IPv6LL on >> every interface would be fine, but Macs need to talk to a whole bunch of >> much simpler devices too, so that's why we need v4LL too. > > if you're optimizing for simpler devices, v6LL is even simpler to > implement than v4LL. > > more generally, v6 autoconfiguration is simpler to implement than v4 > DHCP. > You're missing a point of market reality. There is no home commercial IPv6 market. None. Period. In five years, this will not be the case. But if you wait five years to make Ethernet start replacing Usb for things like low end printers, then it's another two years to get stuff in hand. IPv4 gets cheap networkable stuff out there NOW, so that upgrading to IPv6 really IS trivial. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Dec 13 19:54:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11780 for ; Fri, 13 Dec 2002 19:54:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 28C2B91301; Fri, 13 Dec 2002 19:57:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5F4791302; Fri, 13 Dec 2002 19:57: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 D86E891301 for ; Fri, 13 Dec 2002 19:57:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id BB6705DE2F; Fri, 13 Dec 2002 19:57:36 -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 530235DDD4 for ; Fri, 13 Dec 2002 19:57:36 -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 TAA25766 for ; Fri, 13 Dec 2002 19:57:35 -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 TAA12958 for ; Fri, 13 Dec 2002 19:55:21 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id TAA06929 for ; Fri, 13 Dec 2002 19:48:55 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 13 Dec 2002 19:48:53 -0500 Subject: Re: IPv4 link-local (was unrelated subject line) From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212140025.gBE0PUs00982@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 12/13/2002 19:25, "Stuart Cheshire" wrote: >> The real argument for IPv4 link-local cannot be to provide hosts >> with new features -- we have IPv6 for that. The only argument is >> some form of compatibility with legacy IPv4 only devices. But if >> you focus on legacy, then you don't want to deal with stuff that >> the legacy cannot handle well, e.g. having multiple addresses per >> interface, or having multiple subnets on the same link. (Or, for >> that matter, playing game with the TTL value.) > > I don't know any current mainstream OS that can't handle two addresses on > an interface. There are too many v4 web servers using single link multihoming to take Keith's argument seriously here. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Dec 13 21:43:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14177 for ; Fri, 13 Dec 2002 21:43:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A9F1C91228; Fri, 13 Dec 2002 21:46:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 658FF91302; Fri, 13 Dec 2002 21:46:33 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0BED291228 for ; Fri, 13 Dec 2002 21:46:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id F35E55DED9; Fri, 13 Dec 2002 21:45:47 -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 2E3705DE60 for ; Fri, 13 Dec 2002 21:45:47 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gBE2jkI11216 for ; Fri, 13 Dec 2002 18:45:46 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 13 Dec 2002 18:45:35 -0800 Received: from [17.202.45.246] (il0204a-dhcp118.apple.com [17.202.45.246]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id gBE2jZf08650; Fri, 13 Dec 2002 18:45:35 -0800 (PST) Message-Id: <200212140245.gBE2jZf08650@scv3.apple.com> Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Date: Fri, 13 Dec 2002 18:45:26 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Erik Nordmark" Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk At last, a reply that actually relates to the subject line. >> > But the ongoing conflict detection (causing >> > IP address change when a conflict appears) and broadcast replies looks >> > more like a useful experiment to me. >> >> It has been a five-year experiment by Apple. > >Do you have a pointer to the data that has been collected as part of >that experiment? There is no data. That's the point. After shipping millions of machines per year for five years, the number of reported problems is zero. >How about adding > This document updates RFC 826 and RFC 2132. I added a header line that says "Updates: 826, 2132" >RFC 2131 actually talks about an ARP reply and not the ARP request >with sender=target. See section 4.4.1 in RFC 2131. >So you don't seem to be consistent with RFC 2131. Stevens describes using ARP request. BSD broadcasts an ARP request to announce its address. Mac OS 9 broadcasts an ARP request to announce its address. Mac OS X broadcasts an ARP request to announce its address. Windows broadcasts an ARP request to announce its address. RFC 2131 describes broadcasting an ARP reply, but like many things in RFC 2131, this is probably a typo. As has been pointed out many times by many people, broadcasting an ARP reply is unconventional, and best avoided where not necessary. Therefore I avoided it and followed the behaviour described by Stevens (and implemented on Mac, Windows, Unix, etc.) instead. In any case, the "Packet Reception" rules of RFC 826 are exceedingly clear that checking the packet opcode is the *last* check that is done, after all other packet processing has been completed. Do you have a technical opinion to offer about which you think is best? >I wasn't suggesting a normative reference; that isn't needed since the >document is self-contained. But pointing out the relationship using a >non-normative reference to draft-ietf-zeroconf-ipv6-link-local would be >useful for the implementors that are going to implement both. There is already a non-normative reference to the v4ll draft. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> At any time, if a host >> receives an ARP packet (request *or* reply) where the 'sender IP >> address' is the host's own IP address, but the 'sender hardware >> address' does not match any of the host's own interface addresses, >> then this is a conflicting ARP packet > >I fail to find the word "multihoming" or any explicit mention of >multiple interfaces in the above text. The phrase, "any of the host's own interface addresses" is a mention of multiple interfaces. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> > I would assume that ACD can >> > operate independently for each interface even though v4LL has some >> > extra stuff related to multi-interface nodes. >> >> No, the specification needs to deal with the case when a host has two >> interfaces (say wireless and Ethernet) on the same link. > >And you claim you can't do that by having the interfaces be configured >independently of eachother? If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >I think my conclusion was that the time should be shorter >than 8 seconds and not longer. 8 seconds is a useless compromise >as far as I can tell since it is unecessarily long when STP isn't triggered >and too short when STP is triggered (with out of the box bridge >configurations.) Thus 2 or 3 seconds should be fine. The document already has specific text allowing shorter timeouts in cases where the implementer has reason to believe that is a wise design choice. The document already has specific text describing how the individual choice of timeout doesn't have any impact on interoperability with other devices. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> Most network operators today, with good reason, set their port blocking >> time to five seconds. > >Doesn't match my experience. And doesn't match the IEEE 802.1D >recommendation. If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >Is there a way for the host to reliably detect whether the switches run >RSTP instead of STP? Quoting from Mick Seaman: "Yes, the driver can easily tell the difference between an RSTP and an STP BPDU, they are different 'BPDU types', a type field being defined in the BPDU format." If there is specific text you'd like to see in the draft, I'd be happy to consider any suggestions you wish to offer. >> A Zero Configuration device may want to make use of address conflict >> detection. If address conflict detection requires a mandatory >> user-configuration option, then that means that Zero Configuration >> devices require mandatory user-configuration options, a >> self-contradiction. > >I'd understand that comment if it was about >draft-ietf-zeroconf-ipv4-link-local >but not about the ACD document. Since the addresses are configured either >manually or by DHCP (or some other provisioning protocol) it is possible to >add a knob in the manual config or in DHCP, respectively. So I don't >understand the issue your are concerned about. I don't understand why you think there is a problem. DHCP clients have done address conflict detection for years, and no one has asked for an option to disable address conflict detection there. Macs have done address conflict detection for manual addresses for years, and no one has asked for an option to disable that either. Even Windows tells you if you manually set your IP address to an address that's already in use. If you've ever struggled with a network where two machines were set to the same IP address, you'd think it insane to ever think you'd NOT want to get all the help you can to diagnose and fix that problem. I don't understand why now, after all these years of successful address conflict detection that no one ever complained about, there's suddenly a feeling that we need manual configuration options to disable it. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Dec 13 23:51:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16239 for ; Fri, 13 Dec 2002 23:51:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D509D91235; Fri, 13 Dec 2002 23:54:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C77691236; Fri, 13 Dec 2002 23:54:00 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 79EF091235 for ; Fri, 13 Dec 2002 23:53:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5A0885DF09; Fri, 13 Dec 2002 23:53:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 2DD7B5DE2E for ; Fri, 13 Dec 2002 23:53:59 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBE4rsj07805; Fri, 13 Dec 2002 23:53:54 -0500 (EST) Message-Id: <200212140453.gBE4rsj07805@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: "Erik Nordmark" , zeroconf@merit.edu, iesg@ietf.org Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Fri, 13 Dec 2002 18:45:26 PST.") <200212140245.gBE2jZf08650@scv3.apple.com> Date: Fri, 13 Dec 2002 23:53:54 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk I don't have any inherent problems with the idea of using ARP for address conflict detection; as Stuart indicates, this has been widespread practice for years and few problems have been noted. I don't even see a need to have an option to disable conflict *detection*. However some of the actions recommended in the draft for dealing with conflict detection should definitely NOT be enabled by default. However this draft's recommendations go somewhat beyond widespread practice, or at least such practice as I've observed: - Broadcast ARP replies. I agree that the ARP spec is fairly clear about handling of ARP replies, so I think the potential for this confusing host stacks is small. My concern is that broadcasts add extra network traffic and load on hosts, especially if some hosts periodically ARP for their own addresses (for a variety of reasons: perhaps they do this each time they renew a DHCP lease, perhaps the host is periodically rebooted, perhaps the implementor thought that periodic active address defense was a good idea) I recommend that unicast ARP replies SHOULD be the default. broadcast ARP replies SHOULD be optional to implement, and if implemented, SHOULD require explicit configuration to be enabled. - The idea that a host may give up its address, and that it needs a good reason to keep that address, is a significant departure from longstanding practice. Many protocols layered on top of IP (and not just those using TCP) expect IP address-to-host bindings to be reasonably stable. The current text seems to encourage hosts to treat addresses as temporary unless explicitly configured to treat them as permanent. This would be a significant departure from the IP architecture and an extremely harmful change; so I strongly urge that this text be reworded. Documenting and standardizing use of ACD seems like a good idea. However this document seems to suffer from trying to justify design decisions made for the link local proposal. IMHO it would be more constructive to treat use of ACD for v4LL as an exception to the normal behavior than to treat it as an example of normal behavior. Keith From owner-zeroconf@merit.edu Sat Dec 14 11:26:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04198 for ; Sat, 14 Dec 2002 11:26:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C843F91237; Sat, 14 Dec 2002 11:28:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E08791238; Sat, 14 Dec 2002 11:28: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 59B4691237 for ; Sat, 14 Dec 2002 11:28:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3ECED5DEA6; Sat, 14 Dec 2002 11:28:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id C79D15DE38 for ; Sat, 14 Dec 2002 11:28:50 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA15134 for ; Sat, 14 Dec 2002 11:28:50 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA28197 for ; Sat, 14 Dec 2002 11:28:49 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA02505 for ; Sat, 14 Dec 2002 11:28:49 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 14 Dec 2002 11:28:47 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212140453.gBE4rsj07805@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/13/2002 23:53, "Keith Moore" wrote: > - The idea that a host may give up its address, and that it needs > a good reason to keep that address, is a significant departure > from longstanding practice. Many protocols layered on top of > IP (and not just those using TCP) expect IP address-to-host bindings > to be reasonably stable. > > The current text seems to encourage hosts to treat addresses as > temporary unless explicitly configured to treat them as > permanent. This would be a significant departure from the IP > architecture and an extremely harmful change; so I strongly urge that > this text be reworded. Um...having had to deal with a statically configured network when a small device went insane, and started grabbing other IP addresses, and neither side gave up on the fight, the option for the 'elder' device to cede to the 'younger' device in the event that the younger device won't give up on its insane quest for the one address is *a good thing*...that way, you only have one device with a temporary problem, not many with a problem that isn't fixable on its own. Also, as is noted, you may have cases where previously separate links become joined, via a bridge. At that point, you have multiple address conflicts between multiple devices, all with the same level of seniority. Without a procedure that handles this gracefully, then you have multiple machines that will require a manual reset of some sort. This of course, would be *a bad thing*. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sat Dec 14 12:30:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05877 for ; Sat, 14 Dec 2002 12:30:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1C07591238; Sat, 14 Dec 2002 12:32:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CEDC991239; Sat, 14 Dec 2002 12:32:02 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1BE6E91238 for ; Sat, 14 Dec 2002 12:31:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 86ED15E044; Sat, 14 Dec 2002 12:31:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from arrakis.cso.uiuc.edu (arrakis.cso.uiuc.edu [130.126.113.7]) by segue.merit.edu (Postfix) with ESMTP id 3625E5E02C for ; Sat, 14 Dec 2002 12:31:03 -0500 (EST) Received: from arrakis.cso.uiuc.edu (localhost [127.0.0.1]) by arrakis.cso.uiuc.edu (8.12.4/8.12.4) with ESMTP id gBEHUuXN027618; Sat, 14 Dec 2002 11:30:56 -0600 (CST) Received: (from jak@localhost) by arrakis.cso.uiuc.edu (8.12.4/8.12.4/Submit) id gBEHUutH027617; Sat, 14 Dec 2002 11:30:56 -0600 (CST) Date: Sat, 14 Dec 2002 11:30:56 -0600 From: "Jay A. Kreibich" To: Keith Moore Cc: Joshua Graessley , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Message-ID: <20021214173056.GB27597@uiuc.edu> Reply-To: jak@uiuc.edu References: <52B1CB4E-0EEE-11D7-BCE9-000393760260@apple.com> <200212140006.gBE069j06517@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200212140006.gBE069j06517@astro.cs.utk.edu> User-Agent: Mutt/1.4i X-Editor: vi, and proud of it X-URL: http://www.uiuc.edu/~jak (includes PGP key) Sender: owner-zeroconf@merit.edu Precedence: bulk On Fri, Dec 13, 2002 at 07:06:09PM -0500, Keith Moore scratched on the wall: > > IPv6LL is great. Unfortunately, IPv6 stacks are not that common. > > every major OS vendor except Palm is shipping them. Really? My new HP printer and LinkSys wireless AP have IPv6 in them? These are the devices I want to see zeroconf on. And IPv6 may be simpler in the bigger picture, but IPv4 is already there. -j -- Jay A. Kreibich | Integration & Software Eng. jak@uiuc.edu | Campus IT & Edu. Svcs. | University of Illinois at U/C From owner-zeroconf@merit.edu Sat Dec 14 12:36:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05979 for ; Sat, 14 Dec 2002 12:36:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0656591239; Sat, 14 Dec 2002 12:39:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C85789123A; Sat, 14 Dec 2002 12:39: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 A813F91239 for ; Sat, 14 Dec 2002 12:39:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 858D65E05C; Sat, 14 Dec 2002 12:39:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 27E2D5E05A for ; Sat, 14 Dec 2002 12:39:22 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBEHdBj13563; Sat, 14 Dec 2002 12:39:11 -0500 (EST) Message-Id: <200212141739.gBEHdBj13563@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: jak@uiuc.edu Cc: Keith Moore , Joshua Graessley , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Sat, 14 Dec 2002 11:30:56 CST.") <20021214173056.GB27597@uiuc.edu> Date: Sat, 14 Dec 2002 12:39:11 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > > IPv6LL is great. Unfortunately, IPv6 stacks are not that common. > > > > every major OS vendor except Palm is shipping them. > > Really? My new HP printer and LinkSys wireless AP have IPv6 in them? admittedly I don't know about v6 support in popular embedded device kernels. but I'd be surprised if these kernels supported v4LL either. > And IPv6 may be simpler in the bigger picture, but IPv4 is already there. that's the same kind of argument that the IPP folks gave for insisting on layering everything over HTTP - and it turned out to be a huge mess. Keith From owner-zeroconf@merit.edu Sat Dec 14 12:41:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06182 for ; Sat, 14 Dec 2002 12:41:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 08ABF9123A; Sat, 14 Dec 2002 12:43:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C496491244; Sat, 14 Dec 2002 12:43:54 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B856B9123A for ; Sat, 14 Dec 2002 12:43:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id A06B05E05A; Sat, 14 Dec 2002 12:43:53 -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 3584F5E051 for ; Sat, 14 Dec 2002 12:43:53 -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 MAA02551 for ; Sat, 14 Dec 2002 12:43:52 -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 MAA02724 for ; Sat, 14 Dec 2002 12:43:52 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA13375 for ; Sat, 14 Dec 2002 12:43:51 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 14 Dec 2002 12:43:50 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212141739.gBEHdBj13563@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/14/2002 12:39, "Keith Moore" wrote: >> And IPv6 may be simpler in the bigger picture, but IPv4 is already there. > > that's the same kind of argument that the IPP folks gave for insisting on > layering everything over HTTP - and it turned out to be a huge mess. Gee...and I thought I was doing so well printing with it. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sat Dec 14 12:51:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06355 for ; Sat, 14 Dec 2002 12:51:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 73AC391244; Sat, 14 Dec 2002 12:54:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F54091253; Sat, 14 Dec 2002 12:54: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 20FDA91244 for ; Sat, 14 Dec 2002 12:54:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC6725E046; Sat, 14 Dec 2002 12:54:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from arrakis.cso.uiuc.edu (arrakis.cso.uiuc.edu [130.126.113.7]) by segue.merit.edu (Postfix) with ESMTP id 9E8635E041 for ; Sat, 14 Dec 2002 12:54:09 -0500 (EST) Received: from arrakis.cso.uiuc.edu (localhost [127.0.0.1]) by arrakis.cso.uiuc.edu (8.12.4/8.12.4) with ESMTP id gBEHs5XN027745; Sat, 14 Dec 2002 11:54:05 -0600 (CST) Received: (from jak@localhost) by arrakis.cso.uiuc.edu (8.12.4/8.12.4/Submit) id gBEHs5K8027744; Sat, 14 Dec 2002 11:54:05 -0600 (CST) Date: Sat, 14 Dec 2002 11:54:05 -0600 From: "Jay A. Kreibich" To: Keith Moore Cc: Joshua Graessley , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Message-ID: <20021214175405.GA27688@uiuc.edu> Reply-To: jak@uiuc.edu References: <20021214173056.GB27597@uiuc.edu> <200212141739.gBEHdBj13563@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200212141739.gBEHdBj13563@astro.cs.utk.edu> User-Agent: Mutt/1.4i X-Editor: vi, and proud of it X-URL: http://www.uiuc.edu/~jak (includes PGP key) Sender: owner-zeroconf@merit.edu Precedence: bulk On Sat, Dec 14, 2002 at 12:39:11PM -0500, Keith Moore scratched on the wall: > > > > IPv6LL is great. Unfortunately, IPv6 stacks are not that common. > > > > > > every major OS vendor except Palm is shipping them. > > > > Really? My new HP printer and LinkSys wireless AP have IPv6 in them? > > admittedly I don't know about v6 support in popular embedded device kernels. > but I'd be surprised if these kernels supported v4LL either. I doubt it either, but to get out the next firmware update that does, which upgrade (IP4LL or IPv6) requires more work, time, money, effort, flash space, etc.? It isn't like you can swap the IPv4 stack out for an IPv6 stack-- it will need to support both. People build, sell, buy and use products in the real world. > > And IPv6 may be simpler in the bigger picture, but IPv4 is already there. > > that's the same kind of argument that the IPP folks gave for insisting on > layering everything over HTTP - and it turned out to be a huge mess. Most of IPv4 is a huge mess. It is UGLY. But it is already there. And when IPv6 comes and makes its mark it will all go away. The question is not "will IPv4LL replace IPv6LL", it is only a question of holding off until IPv6 becomes common place and saves the world "in two or three years", just like the IPv6 people have been telling us for the last 5 years. While far from 100% true, there is a great deal of truth in the old saying "A good solution today is better then the ideal solution tomorrow." -j -- Jay A. Kreibich | Integration & Software Eng. jak@uiuc.edu | Campus IT & Edu. Svcs. | University of Illinois at U/C From owner-zeroconf@merit.edu Sat Dec 14 12:55:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06410 for ; Sat, 14 Dec 2002 12:55:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C2DF891253; Sat, 14 Dec 2002 12:57:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E87A91255; Sat, 14 Dec 2002 12:57: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 827A391253 for ; Sat, 14 Dec 2002 12:57:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 694995E046; Sat, 14 Dec 2002 12:57:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 0D4295E041 for ; Sat, 14 Dec 2002 12:57:53 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBEHvnj13674; Sat, 14 Dec 2002 12:57:49 -0500 (EST) Message-Id: <200212141757.gBEHvnj13674@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: jak@uiuc.edu Cc: Keith Moore , Joshua Graessley , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Sat, 14 Dec 2002 11:54:05 CST.") <20021214175405.GA27688@uiuc.edu> Date: Sat, 14 Dec 2002 12:57:49 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > admittedly I don't know about v6 support in popular embedded device kernels. > > but I'd be surprised if these kernels supported v4LL either. > > I doubt it either, but to get out the next firmware update that does, > which upgrade (IP4LL or IPv6) requires more work, time, money, effort, > flash space, etc.? I honestly don't know - it's not at all clear that just because an existing stack supports vanilla IPv4 that addition of v4LL is a slam-dunk. Keith From owner-zeroconf@merit.edu Sat Dec 14 13:01:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06538 for ; Sat, 14 Dec 2002 13:01:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8576391234; Sat, 14 Dec 2002 13:03:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4725A91255; Sat, 14 Dec 2002 13: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 32C6091234 for ; Sat, 14 Dec 2002 13:03:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1D6FC5DF4C; Sat, 14 Dec 2002 13:03:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from arrakis.cso.uiuc.edu (arrakis.cso.uiuc.edu [130.126.113.7]) by segue.merit.edu (Postfix) with ESMTP id C16DB5DD9C for ; Sat, 14 Dec 2002 13:03:50 -0500 (EST) Received: from arrakis.cso.uiuc.edu (localhost [127.0.0.1]) by arrakis.cso.uiuc.edu (8.12.4/8.12.4) with ESMTP id gBEI3kXN027802; Sat, 14 Dec 2002 12:03:46 -0600 (CST) Received: (from jak@localhost) by arrakis.cso.uiuc.edu (8.12.4/8.12.4/Submit) id gBEI3keS027801; Sat, 14 Dec 2002 12:03:46 -0600 (CST) Date: Sat, 14 Dec 2002 12:03:46 -0600 From: "Jay A. Kreibich" To: Keith Moore Cc: Joshua Graessley , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Message-ID: <20021214180346.GB27688@uiuc.edu> Reply-To: jak@uiuc.edu References: <20021214175405.GA27688@uiuc.edu> <200212141757.gBEHvnj13674@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200212141757.gBEHvnj13674@astro.cs.utk.edu> User-Agent: Mutt/1.4i X-Editor: vi, and proud of it X-URL: http://www.uiuc.edu/~jak (includes PGP key) Sender: owner-zeroconf@merit.edu Precedence: bulk On Sat, Dec 14, 2002 at 12:57:49PM -0500, Keith Moore scratched on the wall: > > > admittedly I don't know about v6 support in popular embedded device kernels. > > > but I'd be surprised if these kernels supported v4LL either. > > > > I doubt it either, but to get out the next firmware update that does, > > which upgrade (IP4LL or IPv6) requires more work, time, money, effort, > > flash space, etc.? > > I honestly don't know - it's not at all clear that just because an existing > stack supports vanilla IPv4 that addition of v4LL is a slam-dunk. Fair enough. I agree that until a few more products go through this development cycle we won't have a really solid idea. Desktop systems and embedded devices are very different beasts. That said, if I was a business manager, I know where I would put my money and development team's efforts. -j -- Jay A. Kreibich | Integration & Software Eng. jak@uiuc.edu | Campus IT & Edu. Svcs. | University of Illinois at U/C From owner-zeroconf@merit.edu Sat Dec 14 13:05:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06585 for ; Sat, 14 Dec 2002 13:05:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 14CE591255; Sat, 14 Dec 2002 13:08:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D49A691256; Sat, 14 Dec 2002 13:08: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 B84B591255 for ; Sat, 14 Dec 2002 13:08:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 85DF55DF4C; Sat, 14 Dec 2002 13:08:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 2A3DB5DD9C for ; Sat, 14 Dec 2002 13:08:17 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBEI8Cj13710; Sat, 14 Dec 2002 13:08:12 -0500 (EST) Message-Id: <200212141808.gBEI8Cj13710@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: jak@uiuc.edu Cc: Keith Moore , Joshua Graessley , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Sat, 14 Dec 2002 12:03:46 CST.") <20021214180346.GB27688@uiuc.edu> Date: Sat, 14 Dec 2002 13:08:12 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > That said, if I was a business manager, I know where I would put my > money and development team's efforts. well, most business managers would probably believe that the standard solution is the one most likely to be worth investing in. the question for IETF is different - it's which solution is the best one to ask people to invest in? Keith From owner-zeroconf@merit.edu Sat Dec 14 13:09:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06683 for ; Sat, 14 Dec 2002 13:09:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0F99091256; Sat, 14 Dec 2002 13:11:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D383291257; Sat, 14 Dec 2002 13:11: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 E7DBF91256 for ; Sat, 14 Dec 2002 13:11:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id D7F305E02C; Sat, 14 Dec 2002 13:11:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from home.karahalios.org (dsl093-162-009.tus1.dsl.speakeasy.net [66.93.162.9]) by segue.merit.edu (Postfix) with ESMTP id 0328A5DF4C for ; Sat, 14 Dec 2002 13:11:55 -0500 (EST) Received: from Outersoft.com (usr2.Karahalios.org [192.168.2.2]) by home.karahalios.org (8.11.1/8.10.1) with ESMTP id gBEIBrg05900 for ; Sat, 14 Dec 2002 11:11:54 -0700 Date: Sat, 14 Dec 2002 11:11:53 -0700 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Alex Karahalios To: Zero Configuration Content-Transfer-Encoding: 7bit In-Reply-To: <200212141757.gBEHvnj13674@astro.cs.utk.edu> Message-Id: <85DD4F55-0F8F-11D7-B123-00039377AD70@Outersoft.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Keith, Just as an example. I am finishing an embedded controller project which implements v4LL (and mDNS). The code size for LL is 412 bytes with 28 bytes used for initialization. Implementation time took about 1 week. LL is actually not that useful in my case without mDNS - but that is another topic ;) Alex Karahalios On Saturday, December 14, 2002, at 10:57 AM, Keith Moore wrote: > I honestly don't know - it's not at all clear that just because an > existing > stack supports vanilla IPv4 that addition of v4LL is a slam-dunk. > From owner-zeroconf@merit.edu Sat Dec 14 13:36:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07215 for ; Sat, 14 Dec 2002 13:36:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7A04391257; Sat, 14 Dec 2002 13:39:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3772D91258; Sat, 14 Dec 2002 13:39: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 399AF91257 for ; Sat, 14 Dec 2002 13:39:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 226DA5E041; Sat, 14 Dec 2002 13:39:37 -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 9D0DB5DEBC for ; Sat, 14 Dec 2002 13:39:36 -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 NAA00257 for ; Sat, 14 Dec 2002 13:39:35 -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 NAA05419 for ; Sat, 14 Dec 2002 13:37:00 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id NAA19443 for ; Sat, 14 Dec 2002 13:36:59 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 14 Dec 2002 13:36:58 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212141808.gBEI8Cj13710@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/14/2002 13:08, "Keith Moore" wrote: >> That said, if I was a business manager, I know where I would put my >> money and development team's efforts. > > well, most business managers would probably believe that the standard > solution is the one most likely to be worth investing in. Actually, that's an incorrect assumption. It's more along the lines of which solution will serve customers best now, and for a little while longer. If there is a standard available, and the business can use the standard easily, they will. But if there is customer demand now, and the standard is still in argument stage, then they'll cross their fingers, use what they have and make money, hoping they can upgrade later. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sat Dec 14 13:39:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07258 for ; Sat, 14 Dec 2002 13:39:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DF19191258; Sat, 14 Dec 2002 13:42:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AED0A91259; Sat, 14 Dec 2002 13:42: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 9EAF191258 for ; Sat, 14 Dec 2002 13:42:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 800925E041; Sat, 14 Dec 2002 13:42:44 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 22FD85DEBC for ; Sat, 14 Dec 2002 13:42:44 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBEIgXj13908; Sat, 14 Dec 2002 13:42:37 -0500 (EST) Message-Id: <200212141842.gBEIgXj13908@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Alex Karahalios Cc: Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Sat, 14 Dec 2002 11:11:53 MST.") <85DD4F55-0F8F-11D7-B123-00039377AD70@Outersoft.com> Date: Sat, 14 Dec 2002 13:42:33 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > LL is actually not that useful in my case without mDNS indeed - and mDNS seems a lot less likely to be standardized than v4LL. From owner-zeroconf@merit.edu Sat Dec 14 14:40:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08646 for ; Sat, 14 Dec 2002 14:40:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B4ADF91259; Sat, 14 Dec 2002 14:43:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E4DB9125A; Sat, 14 Dec 2002 14:43: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 6409091259 for ; Sat, 14 Dec 2002 14:43:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 472245DEBC; Sat, 14 Dec 2002 14:43:18 -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 D19DA5DD9C for ; Sat, 14 Dec 2002 14:43:17 -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 OAA13478 for ; Sat, 14 Dec 2002 14:43:17 -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 OAA16778 for ; Sat, 14 Dec 2002 14:43:16 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA27506 for ; Sat, 14 Dec 2002 14:43:16 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 14 Dec 2002 14:43:14 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212141842.gBEIgXj13908@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/14/2002 13:42, "Keith Moore" wrote: >> LL is actually not that useful in my case without mDNS > > indeed - and mDNS seems a lot less likely to be standardized than v4LL. That's pretty sad, since I'll put even money that we'll never see a v4LL standard. Yet another really useful idea in the roundfile. I really think that in the end, the vendors will create a defacto standard that will get formalized. Zeroconf is too much of a no-brainer to sit on ones hands for the years it will take for the standards to be finished. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sat Dec 14 20:54:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15534 for ; Sat, 14 Dec 2002 20:54:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1946791233; Sat, 14 Dec 2002 20:57:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD49D9123B; Sat, 14 Dec 2002 20:57: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 C8F1A91233 for ; Sat, 14 Dec 2002 20:57:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id B098A5E0ED; Sat, 14 Dec 2002 20:57:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from broadviewnet.net (unix6.broadviewnet.net [64.115.0.116]) by segue.merit.edu (Postfix) with SMTP id 4C8285E09B for ; Sat, 14 Dec 2002 20:57:05 -0500 (EST) Received: (qmail 7834 invoked from network); 15 Dec 2002 01:57:04 -0000 Received: from unknown (HELO kabilla) (66.219.68.108) by smtp.broadviewnet.net with SMTP; 15 Dec 2002 01:57:04 -0000 Message-ID: <001f01c2a3dd$442aa2e0$6401a8c0@kabilla> From: "Bill Rees" To: "John C. Welch" , "Zeroconf" References: Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Date: Sat, 14 Dec 2002 17:57:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "John C. Welch" > On 12/14/2002 13:42, "Keith Moore" wrote: > > >> LL is actually not that useful in my case without mDNS > > > > indeed - and mDNS seems a lot less likely to be standardized than v4LL. > > That's pretty sad, since I'll put even money that we'll never see a v4LL > standard. Yet another really useful idea in the roundfile. > > I really think that in the end, the vendors will create a defacto standard > that will get formalized. Zeroconf is too much of a no-brainer to sit on > ones hands for the years it will take for the standards to be finished. > > john > > -- > John C. Welch > Consultant III > Administrative Computing > (617) 253 - 1368 work > (508) 579 - 7380 cell > bynkii2 AIM > > > Ahhh, this is the heart of the matter. The arguments everyone pushes seems to really revolve around whether zeroconf is a good idea (along with mDNS) as presently defined/specified. Security issues, v4LL versus v6LL, mDNS or not, all revolve around whether or not auto-dynamic configuration with the, emphasis on automatic (i.e. without interactive intervention), is a good idea or not. bill From owner-zeroconf@merit.edu Sat Dec 14 22:49:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17468 for ; Sat, 14 Dec 2002 22:49:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8477191205; Sat, 14 Dec 2002 22:52:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 524BD9123B; Sat, 14 Dec 2002 22:52: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 4A21291205 for ; Sat, 14 Dec 2002 22:52:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 321685DE56; Sat, 14 Dec 2002 22:52:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id B5E7A5DDC6 for ; Sat, 14 Dec 2002 22:52:37 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id WAA21828 for ; Sat, 14 Dec 2002 22:52:36 -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 WAA29999 for ; Sat, 14 Dec 2002 22:49: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.9.2/8.9.2) with ESMTP id WAA16271 for ; Sat, 14 Dec 2002 22:49:22 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 14 Dec 2002 22:49:20 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <001f01c2a3dd$442aa2e0$6401a8c0@kabilla> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/14/2002 20:57, "Bill Rees" wrote: > Ahhh, this is the heart of the matter. The arguments everyone pushes seems > to really revolve around whether zeroconf is a good idea (along with mDNS) > as presently defined/specified. Security issues, v4LL versus v6LL, mDNS or > not, all revolve around whether or not auto-dynamic configuration with the, > emphasis on automatic (i.e. without interactive intervention), is a good > idea or not. To the people who just want to use computers it is. They don't want to care how it works. They don't have to with their playstations, so why should they with their home computers? As the people who *do* know how and why the things work, we have a responsibility to make sure that the people who don't need to know can just get work done. I'm not in the business of supplying monkey work for IT, and I hate doing consulting on this kind of mindless configuration idiocy. If we aren't going to get it in gear, then get out of the way so that someone who WILL make this easy can do so. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Dec 16 13:36:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13570 for ; Mon, 16 Dec 2002 13:36:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CD7BE9126A; Mon, 16 Dec 2002 13:39:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94E2D9126B; Mon, 16 Dec 2002 13:39: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 9B49C9126A for ; Mon, 16 Dec 2002 13:39:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7963B5DE5E; Mon, 16 Dec 2002 13:39:31 -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 013125DE50 for ; Mon, 16 Dec 2002 13:39:30 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gBGIdUI24425 for ; Mon, 16 Dec 2002 10:39:30 -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, 16 Dec 2002 10:39:29 -0800 Received: from [17.219.192.140] (vpn-scv-x0-140.apple.com [17.219.192.140]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id gBGIdTf05981 for ; Mon, 16 Dec 2002 10:39:29 -0800 (PST) Message-Id: <200212161839.gBGIdTf05981@scv3.apple.com> Subject: Configuration Smog Date: Mon, 16 Dec 2002 10:39:23 -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 Despite the formidable opposition the Zeroconf Working Group faces, the problem we are seeking to solve remains supremely important. The unfortunate industry trend is that as technology products become more capable, they also become inexorably more complicated and hard to use. If we don't find a way to reverse this self-destructive trend, those of us who have an interest (financial or otherwise) in making products that the general public can actually use are going to have a disappointing future. The hardest battle we're fighting here is not the technical debate about how to achieve our goal of reducing the configuration burden on end-users, but a semi-religious disagreement about whether that goal is even desirable. The computer industry seems unable to add any new feature without also adding one or more configuration options to go with it, because they (we) don't have the guts to make the hard decisions, so we punt them to the end user, and force the end user to make the final decisions about how the product should work. The end result is that the end users are dying the death of a thousand configuration options. This nightmare is the cumulative result of all of them taken together, but there's no one single thing alone that you can blame for the mess. It's like car pollution in third-world countries. No one vehicle alone is responsible, but together they make the air unbreathable. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Mon Dec 16 15:29:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16731 for ; Mon, 16 Dec 2002 15:29:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2820A91247; Mon, 16 Dec 2002 15:32:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3CD49126B; Mon, 16 Dec 2002 15:32: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 A91C991247 for ; Mon, 16 Dec 2002 15:32:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6250A5DF7F; Mon, 16 Dec 2002 15:32:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id A71F55DFA5 for ; Mon, 16 Dec 2002 15:32:28 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBGKWKj01741; Mon, 16 Dec 2002 15:32:21 -0500 (EST) Message-Id: <200212162032.gBGKWKj01741@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Configuration Smog In-reply-to: (Your message of "Mon, 16 Dec 2002 10:39:23 PST.") <200212161839.gBGIdTf05981@scv3.apple.com> Date: Mon, 16 Dec 2002 15:32:20 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Despite the formidable opposition the Zeroconf Working Group faces, the > problem we are seeking to solve remains supremely important. The > unfortunate industry trend is that as technology products become more > capable, they also become inexorably more complicated and hard to use. If > we don't find a way to reverse this self-destructive trend, those of us > who have an interest (financial or otherwise) in making products that the > general public can actually use are going to have a disappointing future. > > The hardest battle we're fighting here is not the technical debate about > how to achieve our goal of reducing the configuration burden on > end-users, but a semi-religious disagreement about whether that goal is > even desirable. I think that's a gross miscatagorization, but it's one that might illuminate the real differences that exist here. IMHO there is a optimum level of configuration, which is neither "zero" nor "lots". Ease of configuration needs to be balanced with other considerations like security. The right balance is different for different devices and different users (depending on their needs, their level of sophistication, and the threats they face), but the same products have to support a wide range of users' needs. So the optimum level of configurability for a product (or a standard) requires more knobs than the optimum level of configurability for a user. I don't think it's appropriate to dismiss the technical concerns of those who see the larger picture as "semi-religious". Particularly when the group's charter (remember the charter?) specifically says > In some cases other considerations may dominate ease of use. For example, > network security requires some configuration which may not be as easy as > the unacceptable alternative of 'no security.' Keith From owner-zeroconf@merit.edu Mon Dec 16 17:21:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20176 for ; Mon, 16 Dec 2002 17:21:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CE86D9126F; Mon, 16 Dec 2002 17:23:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A1F591270; Mon, 16 Dec 2002 17:23: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 9845B9126F for ; Mon, 16 Dec 2002 17:23:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 80DDF5E037; Mon, 16 Dec 2002 17:23: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 158125DFF2 for ; Mon, 16 Dec 2002 17:23: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 RAA19408 for ; Mon, 16 Dec 2002 17:23: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 RAA07174 for ; Mon, 16 Dec 2002 17:23:53 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA08378 for ; Mon, 16 Dec 2002 17:23:52 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 16 Dec 2002 17:23:51 -0500 Subject: Re: Configuration Smog From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212162032.gBGKWKj01741@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/16/2002 15:32, "Keith Moore" wrote: > IMHO there is a optimum level of configuration, which is neither > "zero" nor "lots". Ease of configuration needs to be balanced with > other considerations like security. The right balance is different > for different devices and different users (depending on their needs, > their level of sophistication, and the threats they face), but the > same products have to support a wide range of users' needs. > So the optimum level of configurability for a product (or a standard) > requires more knobs than the optimum level of configurability for a user. If this requires more work of the user than plugging in a cable, and making sure TCP/IP is turned on, then we've failed. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Dec 16 18:31:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21559 for ; Mon, 16 Dec 2002 18:31:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2104991272; Mon, 16 Dec 2002 18:33:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5276591274; Mon, 16 Dec 2002 18:33: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 402CE91272 for ; Mon, 16 Dec 2002 18:33:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 287405DE39; Mon, 16 Dec 2002 18:33:13 -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 CA6A75DDB7 for ; Mon, 16 Dec 2002 18:33:12 -0500 (EST) Received: from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (Motorola/Motgate) with ESMTP id gBGNX1PQ027912; Mon, 16 Dec 2002 16:33:01 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id QAA13157; Mon, 16 Dec 2002 16:32:58 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gBGNWp7C028963; Tue, 17 Dec 2002 10:32:53 +1100 (EST) Message-ID: <3DFE62A7.6070503@motorola.com> Date: Tue, 17 Dec 2002 10:32:55 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Cc: Alex Karahalios , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt References: <200212141842.gBEIgXj13908@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: >>LL is actually not that useful in my case without mDNS > > indeed - and mDNS seems a lot less likely to be standardized than v4LL. The presence or abscence of a standard with the IETF imprimatur may not have much to do with whether people build products using these protocols. - aidan From owner-zeroconf@merit.edu Mon Dec 16 18:50:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21912 for ; Mon, 16 Dec 2002 18:50:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 28CF591274; Mon, 16 Dec 2002 18:53:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECA9191275; Mon, 16 Dec 2002 18:53: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 D261E91274 for ; Mon, 16 Dec 2002 18:53:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id C23725DDEF; Mon, 16 Dec 2002 18:53:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 64BA45DDA3 for ; Mon, 16 Dec 2002 18:53:14 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBGNqrj03071; Mon, 16 Dec 2002 18:52:54 -0500 (EST) Message-Id: <200212162352.gBGNqrj03071@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Aidan Williams Cc: Keith Moore , Alex Karahalios , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Tue, 17 Dec 2002 10:32:55 +1100.") <3DFE62A7.6070503@motorola.com> Date: Mon, 16 Dec 2002 18:52:53 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > >>LL is actually not that useful in my case without mDNS > > > > indeed - and mDNS seems a lot less likely to be standardized than v4LL. > > The presence or abscence of a standard with the IETF imprimatur may > not have much to do with whether people build products using these > protocols. sometimes it does; sometimes it doesn't. but IETF's imprimatur wouldn't mean anything if IETF didn't insist that its (quite reasonable) technical criteria for standardization were followed. repeated attempts to try to get IETF to endorse bad practices (whether or not they're in shipping code) are just wasting time. Keith From owner-zeroconf@merit.edu Mon Dec 16 19:02:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22110 for ; Mon, 16 Dec 2002 19:02:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 88BB291275; Mon, 16 Dec 2002 19:05:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5044891276; Mon, 16 Dec 2002 19:05: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 4E69891275 for ; Mon, 16 Dec 2002 19:05:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 36AD85DED4; Mon, 16 Dec 2002 19:05:39 -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 DD9EA5DEB9 for ; Mon, 16 Dec 2002 19:05:38 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id gBH05bq5005757; Mon, 16 Dec 2002 17:05:37 -0700 (MST) Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id RAA11579; Mon, 16 Dec 2002 17:05:34 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id gBH05W7C000425; Tue, 17 Dec 2002 11:05:32 +1100 (EST) Message-ID: <3DFE6A51.8040303@motorola.com> Date: Tue, 17 Dec 2002 11:05:37 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Cc: Alex Karahalios , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt References: <200212162352.gBGNqrj03071@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Keith Moore wrote: > repeated attempts to try to get IETF to endorse bad practices > (whether or not they're in shipping code) are just wasting time. > Inability of participants in a standards forum to reach a compromise is also a waste of everyone's time. - aidan From owner-zeroconf@merit.edu Mon Dec 16 19:13:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22329 for ; Mon, 16 Dec 2002 19:13:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 80EA891265; Mon, 16 Dec 2002 19:16:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D59D91276; Mon, 16 Dec 2002 19:16: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 F0F2491265 for ; Mon, 16 Dec 2002 19:16:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B87C5DE50; Mon, 16 Dec 2002 19:16:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 2CC8B5DDA3 for ; Mon, 16 Dec 2002 19:16:08 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBH0F0j03133; Mon, 16 Dec 2002 19:15:00 -0500 (EST) Message-Id: <200212170015.gBH0F0j03133@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Aidan Williams Cc: Keith Moore , Alex Karahalios , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Tue, 17 Dec 2002 11:05:37 +1100.") <3DFE6A51.8040303@motorola.com> Date: Mon, 16 Dec 2002 19:15:00 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > repeated attempts to try to get IETF to endorse bad practices > > (whether or not they're in shipping code) are just wasting time. > > Inability of participants in a standards forum to reach a > compromise is also a waste of everyone's time. indeed. but when when that inability is caused by a refusal of some participants to even consider making changes to the protocol to address known and well-documented technical problems (some of which were identified even before the group was formed) accusations of "wasting time" by those parties ring hollow. I suspect we agree that wasting time benefits nobody. Keith From owner-zeroconf@merit.edu Mon Dec 16 19:29:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22512 for ; Mon, 16 Dec 2002 19:29:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8B1B591279; Mon, 16 Dec 2002 19:29:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 54AA59127A; Mon, 16 Dec 2002 19:29:26 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1CBA891279 for ; Mon, 16 Dec 2002 19:29:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id EA3BB5DEB9; Mon, 16 Dec 2002 19:29:19 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from home.karahalios.org (dsl093-162-009.tus1.dsl.speakeasy.net [66.93.162.9]) by segue.merit.edu (Postfix) with ESMTP id F20385DDA3 for ; Mon, 16 Dec 2002 19:29:18 -0500 (EST) Received: from Outersoft.com (usr2.Karahalios.org [192.168.2.2]) by home.karahalios.org (8.11.1/8.10.1) with ESMTP id gBH0TIg29742 for ; Mon, 16 Dec 2002 17:29:18 -0700 Date: Mon, 16 Dec 2002 17:29:18 -0700 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Alex Karahalios To: Zero Configuration Content-Transfer-Encoding: 7bit In-Reply-To: <200212170015.gBH0F0j03133@astro.cs.utk.edu> Message-Id: <943CD6EC-1156-11D7-AC0E-00039377AD70@Outersoft.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Keith, Exactly what protocol changed are you referring to? It seems that I have lost track with all these other "discussions" exactly what you were suggesting needed changing. I mean this sincerely because this effects me directly in my LL implementation. Thanks, Alex Karahalios On Monday, December 16, 2002, at 05:15 PM, Keith Moore wrote: > but when when that inability is caused by a refusal of > some participants to even consider making changes to the protocol > to address known and well-documented technical problems (some > of which were identified even before the group was formed) > accusations of "wasting time" by those parties ring hollow. From owner-zeroconf@merit.edu Mon Dec 16 19:44:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22694 for ; Mon, 16 Dec 2002 19:44:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7FF7F9127B; Mon, 16 Dec 2002 19:47:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B9709127C; Mon, 16 Dec 2002 19:47: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 08BEA9127B for ; Mon, 16 Dec 2002 19:47:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id D052A5DDA3; Mon, 16 Dec 2002 19:47:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 5D44B5DED4 for ; Mon, 16 Dec 2002 19:47:22 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBH0lIj03447; Mon, 16 Dec 2002 19:47:19 -0500 (EST) Message-Id: <200212170047.gBH0lIj03447@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Alex Karahalios Cc: Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Mon, 16 Dec 2002 17:29:18 MST.") <943CD6EC-1156-11D7-AC0E-00039377AD70@Outersoft.com> Date: Mon, 16 Dec 2002 19:47:18 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Exactly what protocol changed are you referring to? It seems that I > have lost track with all these other "discussions" exactly what you > were suggesting needed changing. I mean this sincerely because this > effects me directly in my LL implementation. I suppose we should ask Stuart what he thinks is holding things up, since he and I may have different ideas about that also (we seem to have different ideas about everything else) As for the changes that I think are necessary, my intention is to take the review I did of the protocol and publish it as an Internet-draft. If I try to summarize them off the top of my head I'll probably leave something out. But from memory, the main thing I thought was needed was a standard way for the network to be able to disable hosts' use of v4LL. Keith From owner-zeroconf@merit.edu Mon Dec 16 19:46:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22725 for ; Mon, 16 Dec 2002 19:46:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7BC719127C; Mon, 16 Dec 2002 19:48:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D7E69127D; Mon, 16 Dec 2002 19:48: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 499339127C for ; Mon, 16 Dec 2002 19:48:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2B9065DF35; Mon, 16 Dec 2002 19:48:58 -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 AB3245DED4 for ; Mon, 16 Dec 2002 19:48:57 -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 TAA29800 for ; Mon, 16 Dec 2002 19:48:57 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA25005 for ; Mon, 16 Dec 2002 19:48:56 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id TAA08900 for ; Mon, 16 Dec 2002 19:48:55 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 16 Dec 2002 19:48:53 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212170015.gBH0F0j03133@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/16/2002 19:15, "Keith Moore" wrote: > indeed. but when when that inability is caused by a refusal of > some participants to even consider making changes to the protocol > to address known and well-documented technical problems (some > of which were identified even before the group was formed) > accusations of "wasting time" by those parties ring hollow. > > I suspect we agree that wasting time benefits nobody. Oh I dunno...this has been a fascinating insight that has answered a lot of questions on how the IETF does, or as the case may be, doesn't get things done, and why. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Dec 16 20:22:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23175 for ; Mon, 16 Dec 2002 20:22:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BD7E39127D; Mon, 16 Dec 2002 20:25:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F3D59127E; Mon, 16 Dec 2002 20:25: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 977A79127D for ; Mon, 16 Dec 2002 20:25:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7CEBE5DFA5; Mon, 16 Dec 2002 20:25:17 -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 042D15DF68 for ; Mon, 16 Dec 2002 20:25:16 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gBH1PGw21650 for ; Mon, 16 Dec 2002 17:25:16 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 16 Dec 2002 17:24:51 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id gBH1PGf20937; Mon, 16 Dec 2002 17:25:16 -0800 (PST) Date: Mon, 16 Dec 2002 17:25:14 -0800 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Alex Karahalios , Zero Configuration To: Keith Moore From: Joshua Graessley In-Reply-To: <200212170047.gBH0lIj03447@astro.cs.utk.edu> Message-Id: <64DC694F-115E-11D7-9E56-000393760260@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, December 16, 2002, at 04:47 PM, Keith Moore wrote: >> Exactly what protocol changed are you referring to? It seems that I >> have lost track with all these other "discussions" exactly what you >> were suggesting needed changing. I mean this sincerely because this >> effects me directly in my LL implementation. > > I suppose we should ask Stuart what he thinks is holding things up, > since he and I may have different ideas about that also > (we seem to have different ideas about everything else) > > As for the changes that I think are necessary, my intention is to > take the review I did of the protocol and publish it as an > Internet-draft. > If I try to summarize them off the top of my head I'll probably leave > something out. But from memory, the main thing I thought was needed > was a standard way for the network to be able to disable hosts' use of > v4LL. You still haven't, in my opinion, presented a good argument for this. Should the network also have a way to disable AppleTalk? What about DHCP? Or maybe IPX and IPv6 while we're at it? You claim that IPv4LL exposes clients, even those not self-assigning IPv4LL addresses, to increased security threats. When asked about specific threats you just blew off the question by asking if I really expected you to list them again, as if they were so obvious I should all be aware of the threats already. I'll ask again, what are the specific threats introduced by nodes on the network using IPv4LL addresses? -josh From owner-zeroconf@merit.edu Mon Dec 16 23:07:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25819 for ; Mon, 16 Dec 2002 23:07:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2B61C91283; Mon, 16 Dec 2002 23:10:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0E4391286; Mon, 16 Dec 2002 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 CCD8F91283 for ; Mon, 16 Dec 2002 23:10:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id B500D5DE50; Mon, 16 Dec 2002 23:10:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 596435DE17 for ; Mon, 16 Dec 2002 23:10:00 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBH49oj03812; Mon, 16 Dec 2002 23:09:50 -0500 (EST) Message-Id: <200212170409.gBH49oj03812@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Keith Moore , Alex Karahalios , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Mon, 16 Dec 2002 17:25:14 PST.") <64DC694F-115E-11D7-9E56-000393760260@apple.com> Date: Mon, 16 Dec 2002 23:09:50 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > You still haven't, in my opinion, presented a good argument for this. > Should the network also have a way to disable AppleTalk? AppleTalk is not an IETF standard, thus not in scope for IETF. And AFAIK it doesn't affect apps that aren't written with AppleTalk in mind, so some of the issues with v4LL don't apply to AppleTalk. > What about DHCP? It's easy for a network to disable DHCP - just turn the server off. > Or maybe IPX and IPv6 while we're at it? Again, IPX isn't an IETF protocol; and IPv6 doesn't have the same set of issues as retro-fitting LL into IPv4. That's not to say that there are no issues associated with running IPv6 on a network, but the ipv6 working group and its predecessors have generally been willing to discuss those issues and look for workarounds, rather than pretending that they don't exist. > You claim that IPv4LL exposes clients, even those not self-assigning > IPv4LL addresses, to increased security threats. The threats to hosts (not just "clients") that don't use v4LL exist when other hosts on the network can be compromised because they are using v4LLs; the compromised hosts can then be used as a platform from which to mount additional attacks on non-LL-aware hosts. Networks can also be attacked in this manner (e.g. broadcast pings). Keith From owner-zeroconf@merit.edu Tue Dec 17 01:16:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27336 for ; Tue, 17 Dec 2002 01:16:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 387899128E; Tue, 17 Dec 2002 01:19:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9AAE9128F; Tue, 17 Dec 2002 01:19:31 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 22FEF9128E for ; Tue, 17 Dec 2002 01:19:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id F21955DDA3; Tue, 17 Dec 2002 01:19:29 -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 88C1E5DD99 for ; Tue, 17 Dec 2002 01:19:29 -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 BAA12663 for ; Tue, 17 Dec 2002 01:19:28 -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 BAA12712 for ; Tue, 17 Dec 2002 01:19:28 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id BAA27465 for ; Tue, 17 Dec 2002 01:19:27 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 17 Dec 2002 01:19:26 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212170409.gBH49oj03812@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/16/2002 23:09, "Keith Moore" wrote: >> You still haven't, in my opinion, presented a good argument for this. >> Should the network also have a way to disable AppleTalk? > > AppleTalk is not an IETF standard, thus not in scope for IETF. > And AFAIK it doesn't affect apps that aren't written with AppleTalk > in mind, so some of the issues with v4LL don't apply to AppleTalk. Dodge the point... > >> What about DHCP? > > It's easy for a network to disable DHCP - just turn the server off. No...that disables the ability to USE the DHCP server. You would still have clients trying to connect. > >> Or maybe IPX and IPv6 while we're at it? > > Again, IPX isn't an IETF protocol; and IPv6 doesn't have the same > set of issues as retro-fitting LL into IPv4. That's not to say that > there are no issues associated with running IPv6 on a network, but > the ipv6 working group and its predecessors have generally been willing > to discuss those issues and look for workarounds, rather than pretending > that they don't exist. Maybe they decided that getting something accomplished besides arguing was important. But then, since IPv6 is about as widely used as SNA, it doesn't really matter right now. > >> You claim that IPv4LL exposes clients, even those not self-assigning >> IPv4LL addresses, to increased security threats. > > The threats to hosts (not just "clients") that don't use v4LL exist when > other hosts on the network can be compromised because they are using > v4LLs; the compromised hosts can then be used as a platform from which > to mount additional attacks on non-LL-aware hosts. Networks can also > be attacked in this manner (e.g. broadcast pings). That's vague enough to apply to every IPv4 system on every network everywhere in a not-off condition. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Dec 17 02:06:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07154 for ; Tue, 17 Dec 2002 02:06:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4BCF79124C; Tue, 17 Dec 2002 02:09:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 136799128F; Tue, 17 Dec 2002 02:09:39 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E1A279124C for ; Tue, 17 Dec 2002 02:09:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id CDF195DF6F; Tue, 17 Dec 2002 02:09:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 7C1B05DE4E for ; Tue, 17 Dec 2002 02:09:36 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gBH79aw20299 for ; Mon, 16 Dec 2002 23:09:36 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 16 Dec 2002 23:09:27 -0800 Received: from apple.com (vpn-gh-47.apple.com [17.254.136.46]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id gBH79QQ01942; Mon, 16 Dec 2002 23:09:26 -0800 (PST) Date: Mon, 16 Dec 2002 23:09:27 -0800 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Zero Configuration To: Keith Moore From: Joshua Graessley In-Reply-To: <200212170409.gBH49oj03812@astro.cs.utk.edu> Message-Id: <7AE10465-118E-11D7-AC67-000393760260@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, December 16, 2002, at 08:09 PM, Keith Moore wrote: >> What about DHCP? > > It's easy for a network to disable DHCP - just turn the server off. Anyone can run a DHCP server. There isn't a way for the network to disable DHCP servers or to keep clients from using DHCP. >> You claim that IPv4LL exposes clients, even those not self-assigning >> IPv4LL addresses, to increased security threats. > > The threats to hosts (not just "clients") that don't use v4LL exist > when > other hosts on the network can be compromised because they are using > v4LLs; the compromised hosts can then be used as a platform from which > to mount additional attacks on non-LL-aware hosts. Networks can also > be attacked in this manner (e.g. broadcast pings). This is true of any host, whether it's using an IPv4LL address or an address acquired through some other means. Is there something about this scenario that makes nodes with IPv4LL addresses more susceptible? -josh From owner-zeroconf@merit.edu Tue Dec 17 07:41:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12733 for ; Tue, 17 Dec 2002 07:41:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 54D019129A; Tue, 17 Dec 2002 07:44:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 12F509129C; Tue, 17 Dec 2002 07:44: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 5DD029129A for ; Tue, 17 Dec 2002 07:44:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3D2315DE19; Tue, 17 Dec 2002 07:44:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 0C6C25DE81 for ; Tue, 17 Dec 2002 07:44:24 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 2988F598DE for ; Tue, 17 Dec 2002 12:44:30 +0000 (GMT) Message-ID: <00b901c2a5ca$06a74ec0$131010ac@aldebaran> From: "Philip Nye" To: References: <200212161839.gBGIdTf05981@scv3.apple.com> Subject: Re: Configuration Smog Date: Tue, 17 Dec 2002 12:44:22 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Stuart Cheshire" > ... > It's like car pollution in third-world countries. No one vehicle > alone is responsible, but together they make the air unbreathable. Lets not blame the third world for pollution - a staggering 25% of the worlds CO2 is produced by the USA. And yes the goal of minimising configuration is highly desirable. Unfortunately the word "zero" in the name leads to an all or nothing mentality rather than a drive to minimise configuration burdens right up the scale. Philip Nye From owner-zeroconf@merit.edu Tue Dec 17 08:33:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13655 for ; Tue, 17 Dec 2002 08:33:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 10E0B9121C; Tue, 17 Dec 2002 08:36:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCCB09129D; Tue, 17 Dec 2002 08:36: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 A83259121C for ; Tue, 17 Dec 2002 08:36:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E2A45DF68; Tue, 17 Dec 2002 08:36:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 2A1755DF57 for ; Tue, 17 Dec 2002 08:36:16 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBHDaBj09200; Tue, 17 Dec 2002 08:36:11 -0500 (EST) Message-Id: <200212171336.gBHDaBj09200@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Keith Moore , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Mon, 16 Dec 2002 23:09:27 PST.") <7AE10465-118E-11D7-AC67-000393760260@apple.com> Date: Tue, 17 Dec 2002 08:36:11 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > >> What about DHCP? > > > > It's easy for a network to disable DHCP - just turn the server off. > > Anyone can run a DHCP server. There isn't a way for the network to > disable DHCP servers or to keep clients from using DHCP. hosts don't ship with DHCP servers installed and enabled by default. the occasional rogue DHCP server can be identified and tracked down. by contrast, a network with one or two hosts running v4LL is not likely to cause many problems (and they can probably be tracked down also and the v4LL turned off if there's a way to do that), but a network full of hosts running v4LL because they shipped that way is a different question. > > The threats to hosts (not just "clients") that don't use v4LL exist > > when other hosts on the network can be compromised because they are using > > v4LLs; the compromised hosts can then be used as a platform from which > > to mount additional attacks on non-LL-aware hosts. Networks can also > > be attacked in this manner (e.g. broadcast pings). > > This is true of any host, whether it's using an IPv4LL address or an > address acquired through some other means. Is there something about > this scenario that makes nodes with IPv4LL addresses more susceptible? v4LL can provide alternate access paths to hosts which are not protected by firewalls. this is particularly true with wireless interfaces. (there is also a risk that v4LL addresses will be trusted more than other v4 addresses, and thus attacks via v4LL will be easier than attacks via v4 routable addresses. but this is not a protocol problem, it's a perception problem, and the only thing that can be done about it is to document the problem and try to educate implementors and administrators.) Keith From owner-zeroconf@merit.edu Tue Dec 17 09:42:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14773 for ; Tue, 17 Dec 2002 09:42:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 96A9C9129E; Tue, 17 Dec 2002 09:44:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 684CA9129F; Tue, 17 Dec 2002 09:44: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 3C28D9129E for ; Tue, 17 Dec 2002 09:44:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 225435DFD6; Tue, 17 Dec 2002 09:44: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 AD5865DDC8 for ; Tue, 17 Dec 2002 09:44:54 -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 JAA10587 for ; Tue, 17 Dec 2002 09:44: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 JAA03844 for ; Tue, 17 Dec 2002 09:44:53 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id JAA17733 for ; Tue, 17 Dec 2002 09:44:53 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 17 Dec 2002 09:44:52 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212171336.gBHDaBj09200@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/17/2002 08:36, "Keith Moore" wrote: >> Anyone can run a DHCP server. There isn't a way for the network to >> disable DHCP servers or to keep clients from using DHCP. > > hosts don't ship with DHCP servers installed and enabled by default. > the occasional rogue DHCP server can be identified and tracked down. Enabled? No. Installed? Well, many unix/linux distros do ship with this capability. However, manually having to detect and track down a rogue DHCP server is not any more secure than a random LL box, and in fact is LESS secure, because DHCP can allow *any* machine to not only get on the network, but also then act as a bridge to the Internet with ease. So I find it rather odd that you support DHCP, considering it's obvious shipping security flaws. > > by contrast, a network with one or two hosts running v4LL is not > likely to cause many problems (and they can probably be tracked > down also and the v4LL turned off if there's a way to do that), > but a network full of hosts running v4LL because they shipped > that way is a different question. A network full of machines running DHCP servers is just as bad. And before you say "That's not how they ship", I have an XP laptop that will prove you wrong...internet connection sharing is a default option. And you have yet to show specifically how v4LL will be a security hole *greater* than any other v4 machine beyond the standard vague warnings of doom. >> This is true of any host, whether it's using an IPv4LL address or an >> address acquired through some other means. Is there something about >> this scenario that makes nodes with IPv4LL addresses more susceptible? > > v4LL can provide alternate access paths to hosts which are not > protected by firewalls. this is particularly true with wireless > interfaces. Um...that's true of wireless interfaces WITHOUT v4LL. Wireless has problems with this far and above LL. As well, on most modern Uis, Internet connection sharing is either a wizard default, (XP) or takes about three seconds to set up, (OS X), and now, you're a rogue DHCP server. So v4 !LL provides even MORE paths to do the damage you are talking about. Again, provide specific cases that can be dealt with, or stop with the Chicken Little. > > (there is also a risk that v4LL addresses will be trusted more than > other v4 addresses, and thus attacks via v4LL will be easier than > attacks via v4 routable addresses. but this is not a protocol > problem, it's a perception problem, and the only thing that can be > done about it is to document the problem and try to educate implementors > and administrators.) Nonsense. Any IP address that belongs on the network is equally trusted, and it's FAR more likely that non LL addresses will be trusted. LL makes for a pretty sad staging point for attacks, when you can tap wireless so easily and get a non-LL trusted address. LL doesn't automatically mean that you are connected to the non-LL net in a given network. That requires bridging. And since you can set up bridging for DHCP with *exactly* as much effort as you can with LL, and DHCP will give a *far* better staging point for attacks than LL, it would seem that you really need to deal with the default DHCP option security issues more than LL. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Dec 17 12:39:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18623 for ; Tue, 17 Dec 2002 12:39:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 14AE791223; Tue, 17 Dec 2002 12:42:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE98E91229; Tue, 17 Dec 2002 12:42:32 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE46B91223 for ; Tue, 17 Dec 2002 12:42:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id A9E745DECF; Tue, 17 Dec 2002 12:42:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 31EB35DE69 for ; Tue, 17 Dec 2002 12:42:31 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gBHHgUw20794 for ; Tue, 17 Dec 2002 09:42:30 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 17 Dec 2002 09:42:30 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id gBHHgTQ14542 for ; Tue, 17 Dec 2002 09:42:29 -0800 (PST) Date: Tue, 17 Dec 2002 09:42:28 -0800 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) From: Joshua Graessley To: Zero Configuration Content-Transfer-Encoding: 7bit In-Reply-To: <200212171336.gBHDaBj09200@astro.cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, December 17, 2002, at 05:36 AM, Keith Moore wrote: >>>> What about DHCP? >>> >>> It's easy for a network to disable DHCP - just turn the server off. >> >> Anyone can run a DHCP server. There isn't a way for the network to >> disable DHCP servers or to keep clients from using DHCP. > > hosts don't ship with DHCP servers installed and enabled by default. > the occasional rogue DHCP server can be identified and tracked down. Hosts do ship with DHCP servers installed, and they are very easy to enable. Most hosts also ship with DHCP clients and the DHCP clients are often enabled by default. > by contrast, a network with one or two hosts running v4LL is not > likely to cause many problems (and they can probably be tracked > down also and the v4LL turned off if there's a way to do that), > but a network full of hosts running v4LL because they shipped > that way is a different question. You have made it clear that you're concerned that IPv4LL will wreck havoc on your network. Is your fear justification for a requirement that there be some way to disable IPv4LL on all hosts on a network? How can a host verify that the person that really owns the network is the person trying to disable IPv4LL? What's to keep some evil ISP from disabling it so I have to pay the ISP for extra addresses or drop in a NAT? IPv4LL should work when nothing else does, why should we add a way to break it intentionally. One that may be difficult for someone without a lot of savvy to track down? >>> The threats to hosts (not just "clients") that don't use v4LL exist >>> when other hosts on the network can be compromised because they are >>> using >>> v4LLs; the compromised hosts can then be used as a platform from >>> which >>> to mount additional attacks on non-LL-aware hosts. Networks can >>> also >>> be attacked in this manner (e.g. broadcast pings). >> >> This is true of any host, whether it's using an IPv4LL address or an >> address acquired through some other means. Is there something about >> this scenario that makes nodes with IPv4LL addresses more susceptible? > > v4LL can provide alternate access paths to hosts which are not > protected by firewalls. this is particularly true with wireless > interfaces. I don't follow. IPv4LL addresses only have a scope of the local link. Firewalls usually block traffic between the outside world and the local link. The check for TTL 255 which I seem to recall you opposing, would allow hosts to verify that IPv4LL traffic is not originating from off of the local link. Yes, a malicious host could setup a tunnel and not decrement the TTL. The same malicious host could create a similar tunnel through the firewall for non-IPv4LL addresses. Ultimately, to get to the host from somewhere off the local link, the traffic will have to pass through the firewall. I don't see how IPv4LL makes wireless any less secure either. Are there some specific examples perhaps? -josh From owner-zeroconf@merit.edu Tue Dec 17 12:58:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19011 for ; Tue, 17 Dec 2002 12:58:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A445F91229; Tue, 17 Dec 2002 13:01:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C03D9122B; Tue, 17 Dec 2002 13: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 3154F91229 for ; Tue, 17 Dec 2002 13:01:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 047665DFB6; Tue, 17 Dec 2002 13:01:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id CA8625DECF for ; Tue, 17 Dec 2002 13:01:14 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBHI1Bj11781; Tue, 17 Dec 2002 13:01:11 -0500 (EST) Message-Id: <200212171801.gBHI1Bj11781@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Tue, 17 Dec 2002 09:42:28 PST.") Date: Tue, 17 Dec 2002 13:01:11 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > >>>> What about DHCP? > >>> > >>> It's easy for a network to disable DHCP - just turn the server off. > >> > >> Anyone can run a DHCP server. There isn't a way for the network to > >> disable DHCP servers or to keep clients from using DHCP. > > > > hosts don't ship with DHCP servers installed and enabled by default. > > the occasional rogue DHCP server can be identified and tracked down. > > Hosts do ship with DHCP servers installed, and they are very easy to > enable. yes, but this has to be done manually. if you want to make it so that LL has to be enabled manually I would have no problems with it. > Most hosts also ship with DHCP clients and the DHCP clients are often > enabled by default. having DHCP clients be enabled by default mostly makes them vulnerable to attacks from rogue DHCP servers. > > by contrast, a network with one or two hosts running v4LL is not > > likely to cause many problems (and they can probably be tracked > > down also and the v4LL turned off if there's a way to do that), > > but a network full of hosts running v4LL because they shipped > > that way is a different question. > > You have made it clear that you're concerned that IPv4LL will wreck > havoc on your network. no, I'm concerned that v4LL will cause problems for numerous networks and applications. these concerns are not "fears" as you try to dismiss them, they were supported by extensive analysis. the burden in on the working group to show that this proposal meets the requirements of RFC 2026. so far it has refused to do so. > > v4LL can provide alternate access paths to hosts which are not > > protected by firewalls. this is particularly true with wireless > > interfaces. > > I don't follow. IPv4LL addresses only have a scope of the local link. > Firewalls usually block traffic between the outside world and the local > link. what planet are you from anyway? this is complete garbage. you're wasting my time. Keith From owner-zeroconf@merit.edu Tue Dec 17 13:07:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19268 for ; Tue, 17 Dec 2002 13:07:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DFD239122B; Tue, 17 Dec 2002 13:10:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABAE29122C; Tue, 17 Dec 2002 13:10: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 8B19E9122B for ; Tue, 17 Dec 2002 13:10:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 773505DECF; Tue, 17 Dec 2002 13:10:13 -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 0CE7C5DE2A for ; Tue, 17 Dec 2002 13:10:13 -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 NAA22234 for ; Tue, 17 Dec 2002 13:10:12 -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 NAA17050 for ; Tue, 17 Dec 2002 13:10:12 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id NAA23060 for ; Tue, 17 Dec 2002 13:10:11 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 17 Dec 2002 13:10:10 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212171801.gBHI1Bj11781@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/17/2002 13:01, "Keith Moore" wrote: >>> hosts don't ship with DHCP servers installed and enabled by default. >>> the occasional rogue DHCP server can be identified and tracked down. >> >> Hosts do ship with DHCP servers installed, and they are very easy to >> enable. > > yes, but this has to be done manually. if you want to make it so > that LL has to be enabled manually I would have no problems with it. Incorrect. The Windows XP port wizard will enable a DHCP server without explicitly telling you this as the default action when you have wireless and wired connections enabled. > >> Most hosts also ship with DHCP clients and the DHCP clients are often >> enabled by default. > > having DHCP clients be enabled by default mostly makes them vulnerable > to attacks from rogue DHCP servers. Which is a huge security risk, because then the clients assume they are talking to a trusted host. The only authentication used is MAC address lists, and a chimpanzee can figure out how to fake that. Heck, I have an Asante router that will do this at the click of a button. Seems to me that DHCP, and not LL is the real security risk here. >> >> You have made it clear that you're concerned that IPv4LL will wreck >> havoc on your network. > > no, I'm concerned that v4LL will cause problems for numerous networks > and applications. these concerns are not "fears" as you try to dismiss > them, they were supported by extensive analysis. To quote a really bad movie, "Show me the money". Give this list one single example of a v4LL - unique security hole that can ONLY be fixed by disabling v4LL. So far, you haven't done this, and seem to be raising these endless, and from what can be seen, baseless accusations in what can reasonably seen as an effort to torpedo the standard entirely, or make it just as hard to use as DHCP, thereby making it redundant, and ensuring that nothing will happen to improve this situation until IPv6 is ubiquitous, sometime after 2010. > > the burden in on the working group to show that this proposal meets > the requirements of RFC 2026. so far it has refused to do so. By your standards, DHCP is far worse. >> >> I don't follow. IPv4LL addresses only have a scope of the local link. >> Firewalls usually block traffic between the outside world and the local >> link. > > what planet are you from anyway? this is complete garbage. > you're wasting my time. No Keith. You're wasting our time, and unless you can come up with specific, technically verifiable facts, I'm going to ask that you lay off this entire windmill-tilt of yours, so the people interested in getting work done can do so. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Dec 17 13:17:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19536 for ; Tue, 17 Dec 2002 13:17:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 114719122C; Tue, 17 Dec 2002 13:20:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D559A9122E; Tue, 17 Dec 2002 13:20: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 E16DC9122C for ; Tue, 17 Dec 2002 13:20:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id C9D825DE6C; Tue, 17 Dec 2002 13:20:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 7DBE15DE31 for ; Tue, 17 Dec 2002 13:20:42 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gBHIKfI20541 for ; Tue, 17 Dec 2002 10:20:42 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 17 Dec 2002 10:20:16 -0800 Received: from apple.com (graejo.apple.com [17.202.40.111]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id gBHIKes09808; Tue, 17 Dec 2002 10:20:40 -0800 (PST) Date: Tue, 17 Dec 2002 10:20:41 -0800 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: Zero Configuration To: Keith Moore From: Joshua Graessley In-Reply-To: <200212171801.gBHI1Bj11781@astro.cs.utk.edu> Message-Id: <4033BE06-11EC-11D7-9B80-000393760260@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, December 17, 2002, at 10:01 AM, Keith Moore wrote: >> I don't follow. IPv4LL addresses only have a scope of the local link. >> Firewalls usually block traffic between the outside world and the >> local >> link. > > what planet are you from anyway? this is complete garbage. > you're wasting my time. Is there a reason that you have to resort to insulting me instead of sticking to a technical argument? My point is that a firewalls main function is to insulate a network. Whether the protected network has subnets on different links or not is irrelevant. -josh From owner-zeroconf@merit.edu Tue Dec 17 13:43:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19968 for ; Tue, 17 Dec 2002 13:43:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 327AF9122E; Tue, 17 Dec 2002 13:46:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0370491248; Tue, 17 Dec 2002 13:46: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 B47D19122E for ; Tue, 17 Dec 2002 13:46:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id BFF105DEEF; Tue, 17 Dec 2002 13:45: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 0A1D75DECC for ; Tue, 17 Dec 2002 13:45: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 NAA14991; Tue, 17 Dec 2002 13:45:53 -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 NAA21495; Tue, 17 Dec 2002 13:38: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.9.2/8.9.2) with ESMTP id NAA04685; Tue, 17 Dec 2002 13:38:40 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 17 Dec 2002 13:38:38 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf , Keith Moore Message-ID: In-Reply-To: <4033BE06-11EC-11D7-9B80-000393760260@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 12/17/2002 13:20, "Joshua Graessley" wrote: >> what planet are you from anyway? this is complete garbage. >> you're wasting my time. > > Is there a reason that you have to resort to insulting me instead of > sticking to a technical argument? > > My point is that a firewalls main function is to insulate a network. > Whether the protected network has subnets on different links or not is > irrelevant. I'll bet you lunch at MacWorld that his next reply to you calls you a corporate tool, and says that you shouldn't be listened to because you are only parroting the desires of your evil corporate masters. ;-) john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Dec 17 13:52:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20164 for ; Tue, 17 Dec 2002 13:52:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 224D791248; Tue, 17 Dec 2002 13:55:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E628A9124B; Tue, 17 Dec 2002 13:55: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 C035C91248 for ; Tue, 17 Dec 2002 13:55:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id ACA9A5DECC; Tue, 17 Dec 2002 13:55:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by segue.merit.edu (Postfix) with ESMTP id 4C85F5DE2A for ; Tue, 17 Dec 2002 13:55:31 -0500 (EST) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gBHItRjk093080; Tue, 17 Dec 2002 13:55:27 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gBHItPl8031376; Tue, 17 Dec 2002 13:55:25 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gBHIqec19933; Tue, 17 Dec 2002 13:52:40 -0500 Message-Id: <200212171852.gBHIqec19933@rotala.raleigh.ibm.com> To: Stuart Cheshire Cc: "Daniel Senie" , "zeroconf" Subject: Re: TTL=255 on xmit, no check on receipt please In-Reply-To: Message from Stuart Cheshire of "Mon, 09 Dec 2002 16:07:42 PST." <200212100007.gBA07s904546@scv2.apple.com> Date: Tue, 17 Dec 2002 13:52:40 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Stuart Cheshire writes: > Dan is correct. My point was that there is some security benefit to > knowing that the packet originated locally, but trying to quantify that > benefit is a religious argument that will never be settled by discussion > in this Working Group. But saying that because we can't quantify it or can't get agreement means we need to drop discussion of the topic misses the point. One has to weigh the potential benefits (including security, if any) when deciding whether the benefits of a TTL=255 check are high enough to out weight the negatives (like reduced interoperability). Thomas From owner-zeroconf@merit.edu Tue Dec 17 13:56:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20289 for ; Tue, 17 Dec 2002 13:56:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6C5FC9124B; Tue, 17 Dec 2002 13:59:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C1D691299; Tue, 17 Dec 2002 13:59:10 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 17A679124B for ; Tue, 17 Dec 2002 13:59:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id E76965DF03; Tue, 17 Dec 2002 13:59:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 8A0975DEEF for ; Tue, 17 Dec 2002 13:59:08 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBHIx3j11837; Tue, 17 Dec 2002 13:59:03 -0500 (EST) Message-Id: <200212171859.gBHIx3j11837@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: Keith Moore , Zero Configuration Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-reply-to: (Your message of "Tue, 17 Dec 2002 10:20:41 PST.") <4033BE06-11EC-11D7-9B80-000393760260@apple.com> Date: Tue, 17 Dec 2002 13:59:03 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Is there a reason that you have to resort to insulting me instead of > sticking to a technical argument? I've been making technical arguments for months. I'm fed up with having to respond to completely bogus assertions like >> Firewalls usually block traffic between the outside world and the >> local link. Keith From owner-zeroconf@merit.edu Tue Dec 17 14:08:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20540 for ; Tue, 17 Dec 2002 14:08:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5A41091299; Tue, 17 Dec 2002 14:11:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 23B58912A2; Tue, 17 Dec 2002 14:11: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 17CA991299 for ; Tue, 17 Dec 2002 14:11:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id F40FE5DED3; Tue, 17 Dec 2002 14:11:35 -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 868575DE2A for ; Tue, 17 Dec 2002 14:11:35 -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 OAA29859 for ; Tue, 17 Dec 2002 14:11:34 -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 OAA26296 for ; Tue, 17 Dec 2002 14:11:34 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA18049 for ; Tue, 17 Dec 2002 14:11:34 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 17 Dec 2002 14:11:32 -0500 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212171859.gBHIx3j11837@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/17/2002 13:59, "Keith Moore" wrote: >> Is there a reason that you have to resort to insulting me instead of >> sticking to a technical argument? > > I've been making technical arguments for months. I'm fed up with > having to respond to completely bogus assertions like > >>> Firewalls usually block traffic between the outside world and the >>> local link. Whoa...there's nothing completely bogus about it. One of the reasons you get a firewall is to keep your stuff away from their stuff. You've haven't shown one single verifiable v4LL - unique problem yet. You've insinutated, and predicted, but you have yet to show us proof, and if the problem is *that* great and immediate, then you should be able to do so easily. Your inability to do this points to your arguments having little non-emotional substance. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Dec 17 14:15:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20735 for ; Tue, 17 Dec 2002 14:15:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 132F991206; Tue, 17 Dec 2002 14:18:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3258912A2; Tue, 17 Dec 2002 14:18: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 CCF8691206 for ; Tue, 17 Dec 2002 14:18:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id B26C45DE2A; Tue, 17 Dec 2002 14:18:21 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 29C1D5DE19 for ; Tue, 17 Dec 2002 14:18:21 -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 OAA04451 for ; Tue, 17 Dec 2002 14:18:19 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA27276 for ; Tue, 17 Dec 2002 14:15: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.9.2/8.9.2) with ESMTP id OAA17028 for ; Tue, 17 Dec 2002 14:09:03 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 17 Dec 2002 14:09:01 -0500 Subject: Re: TTL=255 on xmit, no check on receipt please From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212171852.gBHIqec19933@rotala.raleigh.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/17/2002 13:52, "Thomas Narten" wrote: > One has to weigh the potential benefits (including security, if any) > when deciding whether the benefits of a TTL=255 check are high enough > to out weight the negatives (like reduced interoperability). While there are very few true security benefits, the ability to easily discard routed LL packets is an operational benefit that should be implemented. The interoperability issues with non 255 packets can be fixed via update mechanisms easily enough. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Dec 17 15:15:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22376 for ; Tue, 17 Dec 2002 15:15:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 71AF491203; Tue, 17 Dec 2002 15:17:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 41A1D9122F; Tue, 17 Dec 2002 15:17: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 34C9491203 for ; Tue, 17 Dec 2002 15:17:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BC2D5DEE0; Tue, 17 Dec 2002 15:17:21 -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 6C8735DEEF for ; Tue, 17 Dec 2002 15:17:20 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gBHKHJI19951 for ; Tue, 17 Dec 2002 12:17:19 -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, 17 Dec 2002 12:17:19 -0800 Received: from [17.219.192.140] (vpn-scv-x0-140.apple.com [17.219.192.140]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id gBHKHJf07370 for ; Tue, 17 Dec 2002 12:17:19 -0800 (PST) Message-Id: <200212172017.gBHKHJf07370@scv3.apple.com> Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Date: Tue, 17 Dec 2002 12:17:06 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Zero Configuration" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >I've been making technical arguments for months. I'm fed up with >having to respond to completely bogus assertions like Keith, I'm willing to give you the benefit of the doubt, and assume that you do have some valid technical point(s) to make, but the fact is that you have been unable to present them in a way that is comprehensible to anyone else. We need to resolve this problem. What I suggest is that you think about the technical suggestions you have, pick the one that you feel is most important, and create an email describing that suggestion. Give the email a descriptive subject line. Keep the email short and to the point. Avoid rhetoric and name-calling. Avoid making unsubstantiated assertions, or expressions of subjective personal opinion that will immediately be shot down or disputed by others on the list. The group will then discuss the suggestion that you have made, and arrive at a consensus about it. When that is done, you can make your next point, and we will repeat until all your points have been discussed, or the working group decides that this course of action is not yielding productive results. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Dec 18 00:03:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02419 for ; Wed, 18 Dec 2002 00:03:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5508591250; Wed, 18 Dec 2002 00:06:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C97591251; Wed, 18 Dec 2002 00:06: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 D801791250 for ; Wed, 18 Dec 2002 00:06:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id BBCB85DDB8; Wed, 18 Dec 2002 00:06:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtpout.mac.com (A17-250-248-97.apple.com [17.250.248.97]) by segue.merit.edu (Postfix) with ESMTP id 541A85DE40 for ; Wed, 18 Dec 2002 00:05:48 -0500 (EST) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id gBI55U7E016721 for ; Tue, 17 Dec 2002 21:05:30 -0800 (PST) Received: from [192.168.0.119] ([12.232.144.158]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id H7AU5500.6OA; Tue, 17 Dec 2002 21:05:29 -0800 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 17 Dec 2002 21:05:25 -0800 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: Alf Watt To: Keith Moore Cc: ZeroConf WG , Joshua Graessley Message-ID: In-Reply-To: <200212171801.gBHI1Bj11781@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/17/02 10:01 AM, "Keith Moore" wrote: >> You have made it clear that you're concerned that IPv4LL will wreck >> havoc on your network. > > no, I'm concerned that v4LL will cause problems for numerous networks > and applications. these concerns are not "fears" as you try to dismiss > them, they were supported by extensive analysis. > > the burden in on the working group to show that this proposal meets > the requirements of RFC 2026. so far it has refused to do so. Interestingly, RFC 2026 contains mention of deployment into 'disruption sensitive environments' as well as instructions for dealing with disputes of this nature. Unfortunately it doesn't cover disruption of standards forum environments. See sections 4.1.2 and 6.5 for the complete text, here are two relevant quotes: 4.1.2 Draft Standard ... A Draft Standard is normally considered to be a final specification, and changes are likely to be made only to solve specific problems encountered. In most circumstances, it is reasonable for vendors to deploy implementations of Draft Standards into a disruption sensitive environment. 6.5.1 Working Group Disputes An individual (whether a participant in the relevant Working Group or not) may disagree with a Working Group recommendation based on his or her belief that either (a) his or her own views have not been adequately considered by the Working Group, or (b) the Working Group has made an incorrect technical choice which places the quality and/or integrity of the Working Group's product(s) in significant jeopardy. The first issue is a difficulty with Working Group process; the latter is an assertion of technical error. These two types of disagreement are quite different, but both are handled by the same process of review. A person who disagrees with a Working Group recommendation shall always first discuss the matter with the Working Group's chair(s), who may involve other members of the Working Group (or the Working Group as a whole) in the discussion. If the disagreement cannot be resolved in this way, any of the parties involved may bring it to the attention of the Area Director(s) for the area in which the Working Group is chartered. The Area Director(s) shall attempt to resolve the dispute. If the disagreement cannot be resolved by the Area Director(s) any of the parties involved may then appeal to the IESG as a whole. The IESG shall then review the situation and attempt to resolve it in a manner of its own choosing. As someone who is regularly using ipv4LL addresses, mDNS and other standards provided this working group and has not observed a serious threat in practice or theory. Carefully consider whether your analysis warrants the vehemence we've observed or if a review of your thinking about the problem is in order. Best, Alf From owner-zeroconf@merit.edu Fri Dec 20 13:43:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05944 for ; Fri, 20 Dec 2002 13:43:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 398C9912E1; Fri, 20 Dec 2002 13:46:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0765912E2; Fri, 20 Dec 2002 13:46: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 AC10E912E1 for ; Fri, 20 Dec 2002 13:46:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id A80685DFF9; Fri, 20 Dec 2002 13:46:18 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by segue.merit.edu (Postfix) with ESMTP id 1B7615DD97 for ; Fri, 20 Dec 2002 13:46:18 -0500 (EST) Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id gBKIkH2n000830 for ; Fri, 20 Dec 2002 10:46:17 -0800 (PST) Received: from [192.168.0.119] ([12.232.144.158]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id H7FLH500.D2I for ; Fri, 20 Dec 2002 10:46:17 -0800 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Fri, 20 Dec 2002 10:46:12 -0800 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: Alf Watt To: ZeroConf WG 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 There are a couple of corrections I should make to the sentence below, at the suggestion of a careful reader: "As someone who regularly uses ipV4LL addresses and mDNS, which I hope this working group will adopt as standards, I have not observed a serious threat in practice or theory." Best, Alf On 12/17/02 9:05 PM, "Alf Watt" wrote: > As someone who is regularly using ipv4LL addresses, mDNS and other standards > provided this working group and has not observed a serious threat in practice > or theory. From owner-zeroconf@merit.edu Thu Dec 26 19:38:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17992 for ; Thu, 26 Dec 2002 19:38:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5C65691241; Thu, 26 Dec 2002 19:41:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27FD891244; Thu, 26 Dec 2002 19:41: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 0DC6A91241 for ; Thu, 26 Dec 2002 19:41:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id E4C3B5DDE0; Thu, 26 Dec 2002 19:41:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by segue.merit.edu (Postfix) with ESMTP id 98C8A5DD9C for ; Thu, 26 Dec 2002 19:41:52 -0500 (EST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 26 Dec 2002 16:41:52 -0800 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 26 Dec 2002 16:41:51 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 26 Dec 2002 16:41:51 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Thu, 26 Dec 2002 16:41:51 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Thu, 26 Dec 2002 16:41:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TTL=255 on xmit, no check on receipt please Date: Thu, 26 Dec 2002 16:41:50 -0800 Message-ID: Thread-Topic: TTL=255 on xmit, no check on receipt please Thread-Index: AcKmATwU6l6LpXw7TUCzkAhRrfAHzwHPenTg From: "Christian Huitema" To: "John C. Welch" , "Zeroconf" X-OriginalArrivalTime: 27 Dec 2002 00:41:51.0017 (UTC) FILETIME=[BEC94990:01C2AD40] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA17992 > > One has to weigh the potential benefits (including security, if any) > > when deciding whether the benefits of a TTL=255 check are high enough > > to out weight the negatives (like reduced interoperability). > > While there are very few true security benefits, the ability to easily > discard routed LL packets is an operational benefit that should be > implemented. The interoperability issues with non 255 packets can be fixed > via update mechanisms easily enough. I don't think so. I really believe that all this is a trade off. If what you want is a properly architected link local "zeroconf" service, then you should use IPv6. If you insist on IPv4, it must be for compatibility with existing implementations etc. That means that the zeroconf IPv4 should be designed to maximize interoperability with existing IPv4 service that were not necessarily zeroconf aware. If you consider interoperability, the TTL 255 requirement for IPv4 addresses is not very productive. There is a wide body of deployed implementations that use the auto-configured IPv4 address and set the initial TTL to a value other than 255, which means that implementations will not in practice require a check to the value 255 for a very long time. So you will be left with a "set 255, don't check" implementation, which means that you won't get any protection, and also means that if your packet is somehow swallowed by a mis-configured router, it will travel all the way to the Internet core. On the other hand, if you set TTL=1, you will actually be able to interoperate with existing IPv4 implementations, and also to be robust in the presence of non-zeroconf aware router. You will not have a guarantee that you will never receive a UDP packet, but TCP's 3-ways handshake will effectively guarantee that you never set a connection with an off-link node. That seems like a much better engineering trade-off. And you should use IPv6 anyhow. -- Christian Huitema From owner-zeroconf@merit.edu Thu Dec 26 20:10:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18286 for ; Thu, 26 Dec 2002 20:10:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AB52E91244; Thu, 26 Dec 2002 20:13:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F02591253; Thu, 26 Dec 2002 20:13: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 6EFC291244 for ; Thu, 26 Dec 2002 20:13:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 533AD5DE95; Thu, 26 Dec 2002 20:13:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [208.254.46.17]) by segue.merit.edu (Postfix) with ESMTP id DE64A5DDDB for ; Thu, 26 Dec 2002 20:13:47 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.91.81.100]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id gBR1DkL31108 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Thu, 26 Dec 2002 20:13:47 -0500 Message-Id: <5.2.0.9.2.20021226200234.00bb7e60@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 26 Dec 2002 20:13:41 -0500 To: "Zeroconf" From: Daniel Senie Subject: RE: TTL=255 on xmit, no check on receipt please In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 07:41 PM 12/26/2002, Christian Huitema wrote: > > > One has to weigh the potential benefits (including security, if any) > > > when deciding whether the benefits of a TTL=255 check are high >enough > > > to out weight the negatives (like reduced interoperability). > > > > While there are very few true security benefits, the ability to easily > > discard routed LL packets is an operational benefit that should be > > implemented. The interoperability issues with non 255 packets can be >fixed > > via update mechanisms easily enough. > >I don't think so. I really believe that all this is a trade off. If what >you want is a properly architected link local "zeroconf" service, then >you should use IPv6. Let us avoid the prospects of IPv6 deployment in this discussion. IPv6 will be deployed, or not, independent of whether zeroconf is well implemented on IPv4. > If you insist on IPv4, it must be for compatibility >with existing implementations etc. That means that the zeroconf IPv4 >should be designed to maximize interoperability with existing IPv4 >service that were not necessarily zeroconf aware. > >If you consider interoperability, the TTL 255 requirement for IPv4 >addresses is not very productive. There is a wide body of deployed >implementations that use the auto-configured IPv4 address and set the >initial TTL to a value other than 255, which means that implementations >will not in practice require a check to the value 255 for a very long >time. So you will be left with a "set 255, don't check" implementation, >which means that you won't get any protection, and also means that if >your packet is somehow swallowed by a mis-configured router, it will >travel all the way to the Internet core. > >On the other hand, if you set TTL=1, you will actually be able to >interoperate with existing IPv4 implementations, and also to be robust >in the presence of non-zeroconf aware router. Two problems with that argument: 1. There's an existing implementation, deployed, which sets TTL=255. 2. We've established through discussion that zeroconf stations would not send to a router regardless, since they would not have a default route anyway. The only real path for getting packets from a zeroconf station to a router would be via another station on the network that's not aware. Even if the router tried to be that local station, the packet would be addressed to that router, and not to a station beyond, negating the TTL=1 as a useful way to preclude leakage. Given what I've heard from the Microsoft folk, it appears it'll take a while to get TTL=255 on transmit deployed. That is, though, the right answer in my opinion. Checking of TTL=255 will have to wait a while. The best compromise at this stage appears to be to set TTL=255 on transmit for the best possible compatability with the deployed Apple Mac OS implementation, but not implement the TTL=255 check on receipt unless a user explicitly asks for it or after a significant period of time. I suggest we settle on 3 or 5 years as the timeline for requiring TTL=255 on receipt (time to be measured from publication date of the LL document). Regardless, I believe TTL=1 provides no value in the zeroconf environment, and we should remove it from the discussion. From owner-zeroconf@merit.edu Fri Dec 27 02:25:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02954 for ; Fri, 27 Dec 2002 02:25:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1D51A91222; Fri, 27 Dec 2002 02:28:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E762A9123F; Fri, 27 Dec 2002 02:28: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 E14AC91222 for ; Fri, 27 Dec 2002 02:28:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id CF0D65DE67; Fri, 27 Dec 2002 02:28:10 -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 6608B5DD99 for ; Fri, 27 Dec 2002 02:28:10 -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 CAA11637 for ; Fri, 27 Dec 2002 02:28:09 -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 CAA01012 for ; Fri, 27 Dec 2002 02:28:09 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id CAA09655 for ; Fri, 27 Dec 2002 02:28:09 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 27 Dec 2002 02:28:07 -0500 Subject: Re: TTL=255 on xmit, no check on receipt please 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 12/26/2002 19:41, "Christian Huitema" wrote: > If you consider interoperability, the TTL 255 requirement for IPv4 > addresses is not very productive. There is a wide body of deployed > implementations that use the auto-configured IPv4 address and set the > initial TTL to a value other than 255, which means that implementations > will not in practice require a check to the value 255 for a very long > time. So you will be left with a "set 255, don't check" implementation, > which means that you won't get any protection, and also means that if > your packet is somehow swallowed by a mis-configured router, it will > travel all the way to the Internet core. > > On the other hand, if you set TTL=1, you will actually be able to > interoperate with existing IPv4 implementations, and also to be robust > in the presence of non-zeroconf aware router. You will not have a > guarantee that you will never receive a UDP packet, but TCP's 3-ways > handshake will effectively guarantee that you never set a connection > with an off-link node. That seems like a much better engineering > trade-off. There is no guarantee that that TTL = 1 packet didn't come through 200 other routers. The 255 doesn't guarantee that either, but it has a much higher probability of correct behavior. > > And you should use IPv6 anyhow. Yes, but we can't wait 7 years for this to be ubiquitous enough...some of use need to get work done *now* as well. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Dec 27 12:14:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11446 for ; Fri, 27 Dec 2002 12:14:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B8CA191242; Fri, 27 Dec 2002 12:17:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 826AC91247; Fri, 27 Dec 2002 12:17: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 BD24791242 for ; Fri, 27 Dec 2002 12:17:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9245C5DE11; Fri, 27 Dec 2002 12:17:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by segue.merit.edu (Postfix) with ESMTP id 45C375DD8F for ; Fri, 27 Dec 2002 12:17:32 -0500 (EST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 27 Dec 2002 09:17:31 -0800 Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Dec 2002 09:17:31 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Fri, 27 Dec 2002 09:17:32 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 27 Dec 2002 09:17:30 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Fri, 27 Dec 2002 09:17:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: TTL=255 on xmit, no check on receipt please Date: Fri, 27 Dec 2002 09:17:29 -0800 Message-ID: Thread-Topic: TTL=255 on xmit, no check on receipt please Thread-Index: AcKteZO9mL79RVvmRi226cFFOWurLwAUR146 From: "Christian Huitema" To: "John C. Welch" , "Zeroconf" X-OriginalArrivalTime: 27 Dec 2002 17:17:30.0635 (UTC) FILETIME=[D65F95B0:01C2ADCB] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA11446 >> And you should use IPv6 anyhow. > > Yes, but we can't wait 7 years for this to be ubiquitous enough...some of > use need to get work done *now* as well. There is absolutely zero barrier to deployment of IPv6 in a zeroconf scenario. We are speaking of communication between 2 computers on the same link, so the only requirement is agreement between these two computers on which software to use. The 7 years argument is plain bogus: we can make it work right now. Using IPv6 does require a software upgrade on those computers that don't have an IPv6 stack, but deploying a new IPv4 feature like auto-IP on those computers that don't support it yet also requires a software upgrade. Different parties may argue that one is easier or more productive than the other, and different parties will in fact argue different side of this argument. The truth is that we are speaking about shades of gray. The other strong argument is that using IPv6 link local is a better solution than what zeroconf attempts to do with the IPv4 hack: at least, you get addresses that are for all practical purposes globally unique, and thus are not affected by events such as link split or intermittent connectivity. -- Christian Huitema From owner-zeroconf@merit.edu Fri Dec 27 12:37:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11782 for ; Fri, 27 Dec 2002 12:37:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E8A3B91247; Fri, 27 Dec 2002 12:39:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B23C091253; Fri, 27 Dec 2002 12:39:58 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C8B5791247 for ; Fri, 27 Dec 2002 12:39:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id B1D105DF3B; Fri, 27 Dec 2002 12:39:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from garlic.amaranth.net (garlic.amaranth.net [208.254.46.17]) by segue.merit.edu (Postfix) with ESMTP id 45E7F5DECE for ; Fri, 27 Dec 2002 12:39:57 -0500 (EST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.91.81.100]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.6/8.11.6) with ESMTP id gBRHduL20275 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Fri, 27 Dec 2002 12:39:56 -0500 Message-Id: <5.2.0.9.2.20021227123444.02728d90@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 27 Dec 2002 12:39:20 -0500 To: "Zeroconf" From: Daniel Senie Subject: RE: TTL=255 on xmit, no check on receipt please In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 12:17 PM 12/27/2002, Christian Huitema wrote: > >> And you should use IPv6 anyhow. > > > > Yes, but we can't wait 7 years for this to be ubiquitous enough...some of > > use need to get work done *now* as well. > >There is absolutely zero barrier to deployment of IPv6 in a zeroconf >scenario. We are speaking of communication between 2 computers on the same >link, so the only requirement is agreement between these two computers on >which software to use. The 7 years argument is plain bogus: we can make it >work right now. If the software stacks were pre-installed, perhaps. Vendors seem to still be a distance from this. There are some in the zeroconf group who hope to also add embedded devices to zeroconf networks. The embedded space is a long way from being ready for IPv6, from what I've seen. > >Using IPv6 does require a software upgrade on those computers that don't >have an IPv6 stack, but deploying a new IPv4 feature like auto-IP on those >computers that don't support it yet also requires a software upgrade. Except that for the most part we're talking about something which MOST host platforms PRESENTLY support. LinkLocal has been shipped by Microsoft for many years (win98), has been in Mac OS for some time and I believe it's in the Linux distributions. >Different parties may argue that one is easier or more productive than the >other, and different parties will in fact argue different side of this >argument. The truth is that we are speaking about shades of gray. > >The other strong argument is that using IPv6 link local is a better >solution than what zeroconf attempts to do with the IPv4 hack: at least, >you get addresses that are for all practical purposes globally unique, and >thus are not affected by events such as link split or intermittent >connectivity. Since the document under review is specifically an IPv4 document, is there any chance we can limit the discussion? As I said in a previous email, there's a lot of controversy over whether IPv6 is ready to be deployed, and what it'll take to get it out. However, this document is about an IPv4 solution which to a large degree is already deployed, and would benefit from standardization. From owner-zeroconf@merit.edu Fri Dec 27 14:28:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13372 for ; Fri, 27 Dec 2002 14:28:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E16EE91223; Fri, 27 Dec 2002 14:31:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74E8C91253; Fri, 27 Dec 2002 14:31:30 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1E1F391223 for ; Fri, 27 Dec 2002 14:31:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 014695DECF; Fri, 27 Dec 2002 14:31:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 861115DEAE for ; Fri, 27 Dec 2002 14:31:28 -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 OAA27198 for ; Fri, 27 Dec 2002 14:31:27 -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 OAA01469 for ; Fri, 27 Dec 2002 14:31:27 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA17785 for ; Fri, 27 Dec 2002 14:31:27 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 27 Dec 2002 14:31:25 -0500 Subject: Re: TTL=255 on xmit, no check on receipt please 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 12/27/2002 12:17, "Christian Huitema" wrote: >>> And you should use IPv6 anyhow. >> >> Yes, but we can't wait 7 years for this to be ubiquitous enough...some of >> use need to get work done *now* as well. > > There is absolutely zero barrier to deployment of IPv6 in a zeroconf scenario. > We are speaking of communication between 2 computers on the same link, so the > only requirement is agreement between these two computers on which software to > use. The 7 years argument is plain bogus: we can make it work right now. Since you insist on dragging IPv6 into an IPv5 argument, name right now, all shipping printer models with full IPv6 implementations, all applications that can use IPv6 addressing and features. > > Using IPv6 does require a software upgrade on those computers that don't have > an IPv6 stack, but deploying a new IPv4 feature like auto-IP on those > computers that don't support it yet also requires a software upgrade. > Different parties may argue that one is easier or more productive than the > other, and different parties will in fact argue different side of this > argument. The truth is that we are speaking about shades of gray. No, we are speaking about two different protocols. IPv6 support in the OS is NOT the same as IPv6 being ubiquitous across a network, and we all know this. OS X has full IPv6 support, but that's about it. Oh joy, how useful. > > The other strong argument is that using IPv6 link local is a better solution > than what zeroconf attempts to do with the IPv4 hack: at least, you get > addresses that are for all practical purposes globally unique, and thus are > not affected by events such as link split or intermittent connectivity. IPv6 addressing has nothing to do with this. This entire argument is about making IPv4 easier to use *now*, not in the magical future when IPv6 has finally taken over. Can we attempt to stay on topic? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Dec 27 14:36:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13494 for ; Fri, 27 Dec 2002 14:36:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EEB0291253; Fri, 27 Dec 2002 14:39:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B638A91256; Fri, 27 Dec 2002 14:39: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 95EA191253 for ; Fri, 27 Dec 2002 14:38:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 651CB5DF3B; Fri, 27 Dec 2002 14:38:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id E53105DE84 for ; Fri, 27 Dec 2002 14:38:58 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBRJcRj12510; Fri, 27 Dec 2002 14:38:32 -0500 (EST) Message-Id: <200212271938.gBRJcRj12510@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Christian Huitema" Cc: "Zeroconf" Subject: Re: TTL=255 on xmit, no check on receipt please In-reply-to: (Your message of "Thu, 26 Dec 2002 16:41:50 PST.") Date: Fri, 27 Dec 2002 14:38:27 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > If you insist on IPv4, it must be for compatibility > with existing implementations etc. That means that the zeroconf IPv4 > should be designed to maximize interoperability with existing IPv4 > service that were not necessarily zeroconf aware. Having compatibility with non-zeroconf-aware hosts is of little value if the applications on those hosts aren't zeroconf aware. And the set of applications that can run transparently with link local addresses is relatively small. However I agree that it would be better to use IPv6, because IPv4 is becoming obsolete. Keith From owner-zeroconf@merit.edu Fri Dec 27 17:44:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15799 for ; Fri, 27 Dec 2002 17:44:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF2BE91256; Fri, 27 Dec 2002 17:47:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA03A91258; Fri, 27 Dec 2002 17:47: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 0F4F791256 for ; Fri, 27 Dec 2002 17:47:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE5645DEC2; Fri, 27 Dec 2002 17:47: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 4DEA45DF80 for ; Fri, 27 Dec 2002 17:47:22 -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 RAA11507 for ; Fri, 27 Dec 2002 17:47:21 -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 RAA17624 for ; Fri, 27 Dec 2002 17:47:21 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA10819 for ; Fri, 27 Dec 2002 17:47:20 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 27 Dec 2002 17:47:19 -0500 Subject: Re: TTL=255 on xmit, no check on receipt please From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212271938.gBRJcRj12510@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/27/2002 14:38, "Keith Moore" wrote: > > Having compatibility with non-zeroconf-aware hosts is of little value if > the applications on those hosts aren't zeroconf aware. And the set of > applications that can run transparently with link local addresses is > relatively small. > > However I agree that it would be better to use IPv6, because IPv4 > is becoming obsolete. Why yes, in only 5-7 years, it will be a dominantly IPv6 world, and in ten or so, IPv4 will be almost entirely gone. Why couldn't I see before, We should all just sit on our hands and wait for IPv6 to make it all better. All you IPv4 people, stop coding now! IPv6 is coming. There, now that we've gotten that out of our system, can we please get on with the task at hand? Yes, IPv6 will fix many of the problems with networking, but it isn't the panacea that some would like us to believe it is. It is not in wide spread implementation yet, and there will, not may, but will be bugs in it that will need to be dealt with. That is unless someone has gotten that pragma invoke deity option to work. Stopping all efforts to make IPv4 work better because is coming is just silly. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Dec 27 18:37:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16387 for ; Fri, 27 Dec 2002 18:37:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8F6FE91257; Fri, 27 Dec 2002 18:40:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D07F91258; Fri, 27 Dec 2002 18:40: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 7BAEE91257 for ; Fri, 27 Dec 2002 18:40:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 674EC5DF80; Fri, 27 Dec 2002 18:40:08 -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 593965DED3 for ; Fri, 27 Dec 2002 18:40:03 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gBRNe2w00183 for ; Fri, 27 Dec 2002 15:40:02 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 27 Dec 2002 15:39:35 -0800 Received: from [17.219.194.170] (vpn-scv-x4-170.apple.com [17.219.194.170]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id gBRNe2f00009; Fri, 27 Dec 2002 15:40:02 -0800 (PST) Message-Id: <200212272340.gBRNe2f00009@scv3.apple.com> Subject: RE: TTL=255 on xmit, no check on receipt please Date: Fri, 27 Dec 2002 15:40:01 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Christian Huitema" , "Zeroconf" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >I don't think so. I really believe that all this is a trade off. >If what you want is a properly architected link local "zeroconf" >service, then you should use IPv6. If you insist on IPv4, it must >be for compatibility with existing implementations etc. Christian, the reason that IPv4 link-local is useful is because it is relatively easy to add to an existing IPv4 stack, whereas adding IPv6 is more work. Do you disagree with this? Microsoft shipped IPv4 link-local in Windows 98 four years ago, and not IPv6. There must have been a reason for that. >If you consider interoperability, the TTL 255 requirement for IPv4 >addresses is not very productive. There is a wide body of deployed >implementations that use the auto-configured IPv4 address and set >the initial TTL to a value other than 255, which means that >implementations will not in practice require a check to the value >255 for a very long time. So you will be left with a "set 255, >don't check" implementation, which means that you won't get any >protection, and also means that if your packet is somehow >swallowed by a mis-configured router, it will travel all the way >to the Internet core. I quote from Dave Thaler , in the arguments he gave which convinced the working group to adopt TTL=255: >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. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Dec 27 19:11:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16771 for ; Fri, 27 Dec 2002 19:11:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7E94491258; Fri, 27 Dec 2002 19:14:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFB1A9125A; Fri, 27 Dec 2002 19:14:11 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 05E0091258 for ; Fri, 27 Dec 2002 19:14:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id E30955DF38; Fri, 27 Dec 2002 19:14:10 -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 9B7F95DDFE for ; Fri, 27 Dec 2002 19:14:10 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gBS0EAI09517 for ; Fri, 27 Dec 2002 16:14:10 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 27 Dec 2002 16:13:43 -0800 Received: from [17.219.194.170] (vpn-scv-x4-170.apple.com [17.219.194.170]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id gBS0E9f07318; Fri, 27 Dec 2002 16:14:09 -0800 (PST) Message-Id: <200212280014.gBS0E9f07318@scv3.apple.com> Subject: Application software needs to be "zeroconf-aware"? Date: Fri, 27 Dec 2002 16:14:09 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Keith Moore" , "Christian Huitema" Cc: "Zeroconf" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Having compatibility with non-zeroconf-aware hosts is of little value if >the applications on those hosts aren't zeroconf aware. And the set of >applications that can run transparently with link local addresses is >relatively small. Keith, I know you just bought yourself a Titanium PowerBook G4. Mac OS X 10.2 comes with a bunch of network software (ftp, ssh, AppleShare, LPR/IPP printing, Web browser, iChat, etc.) If you connect your Mac directly to another Mac (or a Windows machine) with an Ethernet cable, and let them both acquire IPv4 link-local addresses, then can you tell me what network software *doesn't* work? Can the AppleShare client connect to an AppleShare server on the other machine? Can an ftp client connect to an ftp server on the other machine? Can a web browser fetch pages from a web server running on the other machine? Don't bother telling us that you tried to buy a book from Amazon and it didn't work, or that you tried to send email to someone in another country and it didn't work. We know the worldwide Internet is really useful. No one working on Zeroconf has argued that it isn't. The point of Zeroconf is not that we don't need a worldwide Internet. The point of Zeroconf is that it would be useful to be able to use that same IP software when you're not connected to the Internet. You can use a web browser for on-line shopping. It is beneficial to be able to use that same familiar web browser software also to check the status page of your directly-attached printer when you want to check its ink levels. None of the applications on your Mac have been modified to be specially aware of IPv4 link-local addresses, yet they all seem to function well enough for people to get useful work done. How many of those unmodified applications work today using IPv6 link-local addresses? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Dec 27 19:18:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16984 for ; Fri, 27 Dec 2002 19:18:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 75E439125B; Fri, 27 Dec 2002 19:21:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 478C89125C; Fri, 27 Dec 2002 19:21: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 6223D9125B for ; Fri, 27 Dec 2002 19:21:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 470715DE31; Fri, 27 Dec 2002 19:21:04 -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 A82735DDFE for ; Fri, 27 Dec 2002 19:21:03 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id gBS0L3w04488 for ; Fri, 27 Dec 2002 16:21:03 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 27 Dec 2002 16:20:36 -0800 Received: from [17.219.194.170] (vpn-scv-x4-170.apple.com [17.219.194.170]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id gBS0L2f08537; Fri, 27 Dec 2002 16:21:03 -0800 (PST) Message-Id: <200212280021.gBS0L2f08537@scv3.apple.com> Subject: Should people still be making IPv4 products? Date: Fri, 27 Dec 2002 16:21:02 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Christian Huitema" , "Zeroconf" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Christian Huitema wrote: >The other strong argument is that using IPv6 link local is a >better solution than what zeroconf attempts to do with the IPv4 >hack: at least, you get addresses that are for all practical >purposes globally unique, and thus are not affected by events >such as link split or intermittent connectivity. I haven't seen anyone on this list argue that IPv6 is a bad idea. I think most people would agree that IPv6 is a good idea, and when it is ubiquitous we'll be happy. However, the fact is that IPv4 is useful for products today. Mac OS and Windows have done IPv4LL for years. Other vendors want to make IPv4LL products too, and they want a standard to follow. There appears to be a small community of people who think that indefinite stalling of this document will somehow contribute to faster adoption of IPv6. The sad irony here is that the unending stalling of IPv4LL has just served to keep it in the spotlight, whereas if it had been published a year or two ago, it would be largely forgotten by now. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Dec 27 19:42:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17272 for ; Fri, 27 Dec 2002 19:42:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 873239125F; Fri, 27 Dec 2002 19:45:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 205D491260; Fri, 27 Dec 2002 19:45: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 1120C9125F for ; Fri, 27 Dec 2002 19:45:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 181015DF38; Fri, 27 Dec 2002 19:45:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 88B625DEA5 for ; Fri, 27 Dec 2002 19:45:07 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gBS0j7I12817 for ; Fri, 27 Dec 2002 16:45:07 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 27 Dec 2002 16:45:07 -0800 Received: from [17.219.194.170] (vpn-scv-x4-170.apple.com [17.219.194.170]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id gBS0j4f13214 for ; Fri, 27 Dec 2002 16:45:04 -0800 (PST) Message-Id: <200212280045.gBS0j4f13214@scv3.apple.com> Subject: Updated Rendezvous drafts are available Date: Fri, 27 Dec 2002 16:45:05 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Updated Rendezvous drafts are available: "Requirements for the Replacement of AppleTalk Name Binding Protocol" "Performing DNS queries via IP Multicast" "DNS-Based Service Discovery" Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Dec 27 20:08:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17565 for ; Fri, 27 Dec 2002 20:08:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 919C99122B; Fri, 27 Dec 2002 20:11:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6172C91261; Fri, 27 Dec 2002 20:11: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 4D24C9122B for ; Fri, 27 Dec 2002 20:11:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id F1F785DF88; Fri, 27 Dec 2002 20:11:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 94F705DF81 for ; Fri, 27 Dec 2002 20:11:22 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBS1ANj19057; Fri, 27 Dec 2002 20:10:38 -0500 (EST) Message-Id: <200212280110.gBS1ANj19057@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: "Keith Moore" , "Christian Huitema" , "Zeroconf" Subject: Re: Application software needs to be "zeroconf-aware"? In-reply-to: (Your message of "Fri, 27 Dec 2002 16:14:09 PST.") <200212280014.gBS0E9f07318@scv3.apple.com> Date: Fri, 27 Dec 2002 20:10:23 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Keith, I know you just bought yourself a Titanium PowerBook G4. > > Mac OS X 10.2 comes with a bunch of network software (ftp, ssh, > AppleShare, LPR/IPP printing, Web browser, iChat, etc.) > > If you connect your Mac directly to another Mac (or a Windows machine) > with an Ethernet cable, and let them both acquire IPv4 link-local > addresses, then can you tell me what network software *doesn't* work? your question constrains the answer in a way that would make the answer misleading. most apps that would work on an isolated network with only two hosts and statically-assigned IP address literals would work as well with v4LLs. so if the only apps you care about are those that only need to work between two hosts on an isolated network, LL is great for you. but many other apps will fail in the presence of v4LL. pretending that those apps don't exist, or are not important, isn't helpful. > The point of > Zeroconf is not that we don't need a worldwide Internet. The point of > Zeroconf is that it would be useful to be able to use that same IP > software when you're not connected to the Internet. then please fix v4LL so that it's disabled whenever you are connected to a larger network. that way it won't break anything that already works. Keith From owner-zeroconf@merit.edu Fri Dec 27 20:24:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17692 for ; Fri, 27 Dec 2002 20:24:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C822291263; Fri, 27 Dec 2002 20:27:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93C9C91264; Fri, 27 Dec 2002 20:27:05 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9C03191263 for ; Fri, 27 Dec 2002 20:27:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 82D455DF81; Fri, 27 Dec 2002 20:27:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from home.karahalios.org (dsl093-162-009.tus1.dsl.speakeasy.net [66.93.162.9]) by segue.merit.edu (Postfix) with ESMTP id B41AD5DF80 for ; Fri, 27 Dec 2002 20:27:03 -0500 (EST) Received: from Outersoft.com (usr2.Karahalios.org [192.168.2.2]) by home.karahalios.org (8.11.1/8.10.1) with ESMTP id gBS1R2g15423 for ; Fri, 27 Dec 2002 18:27:02 -0700 Date: Fri, 27 Dec 2002 18:27:02 -0700 Subject: Re: Application software needs to be "zeroconf-aware"? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Alex Karahalios To: "Zeroconf" Content-Transfer-Encoding: 7bit In-Reply-To: <200212280110.gBS1ANj19057@astro.cs.utk.edu> Message-Id: <77CBD406-1A03-11D7-8B04-00039377AD70@Outersoft.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Keith, Could you give us some examples of what specific apps would fail and how they would fail? Thanks, Alex Karahalios On Friday, December 27, 2002, at 06:10 PM, Keith Moore wrote: > but many other apps will fail in the presence of v4LL. > From owner-zeroconf@merit.edu Fri Dec 27 21:18:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18277 for ; Fri, 27 Dec 2002 21:18:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C2D129122C; Fri, 27 Dec 2002 21:21:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92A6991264; Fri, 27 Dec 2002 21:21: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 A0DB29122C for ; Fri, 27 Dec 2002 21:21:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 80F215DF00; Fri, 27 Dec 2002 21:21: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 0923A5DEC2 for ; Fri, 27 Dec 2002 21:21:44 -0500 (EST) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id gBS2LhI21909 for ; Fri, 27 Dec 2002 18:21:43 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 27 Dec 2002 18:21:16 -0800 Received: from [17.219.194.170] (vpn-scv-x4-170.apple.com [17.219.194.170]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id gBS2Lgs03335; Fri, 27 Dec 2002 18:21:42 -0800 (PST) Message-Id: <200212280221.gBS2Lgs03335@scv1.apple.com> Subject: Re: Application software needs to be "zeroconf-aware"? Date: Fri, 27 Dec 2002 18:21:44 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Keith Moore" Cc: "Christian Huitema" , "Zeroconf" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >> The point of >> Zeroconf is not that we don't need a worldwide Internet. The point of >> Zeroconf is that it would be useful to be able to use that same IP >> software when you're not connected to the Internet. > >then please fix v4LL so that it's disabled whenever you are connected to >a larger network. that way it won't break anything that already works. The problem is how a device with no screen and no keyboard can detect with absolute certainty that it is "connected to a larger network" AND that it is correctly configured for that network. If the device is ever wrong, then you get into the situation where it can't communicate because it is configured wrong, and it thinks it's configured right so it's disabled v4LL, so now you can't communicate with it to fix the incorrect configuration. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Dec 27 21:20:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18303 for ; Fri, 27 Dec 2002 21:20:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 48E4291264; Fri, 27 Dec 2002 21:23:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 188B391265; Fri, 27 Dec 2002 21:23:37 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0672991264 for ; Fri, 27 Dec 2002 21:23:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id E62FA5DEC2; Fri, 27 Dec 2002 21:23:35 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 89EFC5DDE8 for ; Fri, 27 Dec 2002 21:23:35 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBS2N4j19495; Fri, 27 Dec 2002 21:23:14 -0500 (EST) Message-Id: <200212280223.gBS2N4j19495@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Alex Karahalios Cc: "Zeroconf" Subject: Re: Application software needs to be "zeroconf-aware"? In-reply-to: (Your message of "Fri, 27 Dec 2002 18:27:02 MST.") <77CBD406-1A03-11D7-8B04-00039377AD70@Outersoft.com> Date: Fri, 27 Dec 2002 21:23:04 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Could you give us some examples of what specific apps would fail and > how they would fail? I've done this many times. distributed apps will fail; examples include gnutella (and friends), apps based on globus, pvm, netsolve; apps that use sip. also some distributed games, some conferencing software, but since I don't use these I can't name specific instances of these. apps that expect to be able to associate DNS names with hosts will also fail since LL addresses should not be advertised in DNS. or if they are advertised in DNS, they will fail if the scope of the app is beyond the local link. Keith From owner-zeroconf@merit.edu Fri Dec 27 21:21:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18318 for ; Fri, 27 Dec 2002 21:21:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A925C91265; Fri, 27 Dec 2002 21:24:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 78DCC91266; Fri, 27 Dec 2002 21:24: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 6AC8791265 for ; Fri, 27 Dec 2002 21:24:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 512B15DEC2; Fri, 27 Dec 2002 21:24:19 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id E49FE5DE98 for ; Fri, 27 Dec 2002 21:24:18 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBS2Nej19513; Fri, 27 Dec 2002 21:23:50 -0500 (EST) Message-Id: <200212280223.gBS2Nej19513@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Updated Rendezvous drafts are available In-reply-to: (Your message of "Fri, 27 Dec 2002 16:45:05 PST.") <200212280045.gBS0j4f13214@scv3.apple.com> Date: Fri, 27 Dec 2002 21:23:40 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Updated Rendezvous drafts are available: I take it these are being published via the Internet-Drafts mechanism? From owner-zeroconf@merit.edu Fri Dec 27 21:28:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18383 for ; Fri, 27 Dec 2002 21:28:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9628091266; Fri, 27 Dec 2002 21:30:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61C1691267; Fri, 27 Dec 2002 21:30: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 3B5C091266 for ; Fri, 27 Dec 2002 21:30:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 23B675DDD2; Fri, 27 Dec 2002 21:30:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id A696F5DE8F for ; Fri, 27 Dec 2002 21:30:49 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBS2Tsj19553; Fri, 27 Dec 2002 21:30:05 -0500 (EST) Message-Id: <200212280230.gBS2Tsj19553@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: "Keith Moore" , "Christian Huitema" , "Zeroconf" Subject: Re: Application software needs to be "zeroconf-aware"? In-reply-to: (Your message of "Fri, 27 Dec 2002 18:21:44 PST.") <200212280221.gBS2Lgs03335@scv1.apple.com> Date: Fri, 27 Dec 2002 21:29:54 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > >then please fix v4LL so that it's disabled whenever you are connected to > >a larger network. that way it won't break anything that already works. > > The problem is how a device with no screen and no keyboard can detect > with absolute certainty that it is "connected to a larger network" AND > that it is correctly configured for that network. if a host is explicitly configured to have any external routes, OR any routes to other prefixes are discovered by the host through DHCP, RIP, or any other mechanism supported by the host and enabled on that host, it's connected to a larger network. yes there can be rogue DHCP servers or RIP advertisements, but trying to detect errors in the configuration of managed networks should not be in scope for zeroconf. Keith From owner-zeroconf@merit.edu Fri Dec 27 23:28:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20107 for ; Fri, 27 Dec 2002 23:28:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 46B699126A; Fri, 27 Dec 2002 23:30:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE2C39126B; Fri, 27 Dec 2002 23:30: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 675B49126A for ; Fri, 27 Dec 2002 23:30:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 970615DDFE; Fri, 27 Dec 2002 23:30:10 -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 CA8305DDE8 for ; Fri, 27 Dec 2002 23:30:09 -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 XAA04651 for ; Fri, 27 Dec 2002 23:30:09 -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 XAA23827 for ; Fri, 27 Dec 2002 23:30:09 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id XAA24842 for ; Fri, 27 Dec 2002 23:30:08 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 27 Dec 2002 23:30:06 -0500 Subject: Re: Application software needs to be "zeroconf-aware"? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212280110.gBS1ANj19057@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/27/2002 20:10, "Keith Moore" wrote: > your question constrains the answer in a way that would make the answer > misleading. most apps that would work on an isolated network with > only two hosts and statically-assigned IP address literals would work > as well with v4LLs. so if the only apps you care about are those that > only need to work between two hosts on an isolated network, LL is great > for you. but many other apps will fail in the presence of v4LL. > pretending that those apps don't exist, or are not important, isn't helpful. Keith, either find us a bug, or stop saying the sky is falling. One would be highly productive, the other is a waste of time. > >> The point of >> Zeroconf is not that we don't need a worldwide Internet. The point of >> Zeroconf is that it would be useful to be able to use that same IP >> software when you're not connected to the Internet. > > then please fix v4LL so that it's disabled whenever you are connected to > a larger network. that way it won't break anything that already works. Nonsense, that's absolutely the wrong way to go. I have two interfaces, and each can have its own IP address, and in fact, can easily handle multiple IP addresses on each interface. Therefore, there's no good reason whatsoever to not allow me to communicate on different networks simultaneously, and if one of those is LL, so what? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Dec 27 23:34:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20159 for ; Fri, 27 Dec 2002 23:34:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6EAB39126B; Fri, 27 Dec 2002 23:37:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E61F9126C; Fri, 27 Dec 2002 23:37: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 262979126B for ; Fri, 27 Dec 2002 23:36:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0DB705DF82; Fri, 27 Dec 2002 23:36:59 -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 983F75DDE8 for ; Fri, 27 Dec 2002 23:36:58 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id XAA00052 for ; Fri, 27 Dec 2002 23:36:57 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA17852 for ; Fri, 27 Dec 2002 23:36:57 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id XAA25210 for ; Fri, 27 Dec 2002 23:36:56 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 27 Dec 2002 23:36:55 -0500 Subject: Re: Application software needs to be "zeroconf-aware"? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212280223.gBS2N4j19495@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/27/2002 21:23, "Keith Moore" wrote: >> Could you give us some examples of what specific apps would fail and >> how they would fail? > > I've done this many times. > > distributed apps will fail; examples include gnutella (and friends), That's pretty interesting since I use Limewire and Rendezvous all the time. > apps > based on globus, pvm, netsolve; apps that use sip. Really? They would break because they can't get to the public internet, or the mere presence of LL disables them? One makes sense for reasons that have nothing to do with LL, the other shows that they are obviously too fragile to function. > also some distributed > games, some conferencing software, but since I don't use these I can't name > specific instances of these. Well, I *can* say that Unrealy GOTY, Baldur's Gate II, and SquidCam work jes' peachy in the presence of LL. Maybe you should use some apps here. > > apps that expect to be able to associate DNS names with hosts will also > fail since LL addresses should not be advertised in DNS. or if they > are advertised in DNS, they will fail if the scope of the app is beyond > the local link. This is: A) Misleading. First of all, why would you have a Unicast DNS server running on a LL network? Secondly, an app using DNS names without DNS services is going to fail ANYWAY, there's NO DNS. LL is NOT DNS, and has nothing to do with DNS, please stop trying to confuse the issue. B) If you take mDNS into account, you're wrong anyway. C) If the app is trying to connect to something that can't be reached of COURSE it's going to fail, this is true on a manually configured network with Unicast DNS. Lemme yank the connection to the public internet, and watch things break. Again, do you have anything that is an LL issue, not a common sense issue? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Dec 27 23:37:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20232 for ; Fri, 27 Dec 2002 23:37:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC77E9126D; Fri, 27 Dec 2002 23:40:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 761629126E; Fri, 27 Dec 2002 23:40: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 457F19126D for ; Fri, 27 Dec 2002 23:40:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3044A5DF98; Fri, 27 Dec 2002 23:40: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 B7D9E5DF82 for ; Fri, 27 Dec 2002 23:39:59 -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 XAA05895 for ; Fri, 27 Dec 2002 23:39: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 XAA17900 for ; Fri, 27 Dec 2002 23:39:59 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id XAA25347 for ; Fri, 27 Dec 2002 23:39:58 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 27 Dec 2002 23:39:57 -0500 Subject: Re: Application software needs to be "zeroconf-aware"? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212280230.gBS2Tsj19553@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/27/2002 21:29, "Keith Moore" wrote: >> The problem is how a device with no screen and no keyboard can detect >> with absolute certainty that it is "connected to a larger network" AND >> that it is correctly configured for that network. > > if a host is explicitly configured to have any external routes, OR > any routes to other prefixes are discovered by the host through DHCP, RIP, > or any other mechanism supported by the host and enabled on that host, it's > connected to a larger network. No, you assume it is. Why is this assumption *okay* with DHCP, or any other current configuration mechanism for you, yet the same level of assumption for LL is somehow evil? > > yes there can be rogue DHCP servers or RIP advertisements, but trying to > detect errors in the configuration of managed networks should not be in > scope for zeroconf. No, but then, zeroconf won't interfere with these unless your OS is incapable of handling more than one address per interface, but then I'd wonder how you are running Zeroconf on a System 6 Mac, or a DOS 5.0 PC, and more importantly , *why*? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sat Dec 28 09:03:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05373 for ; Sat, 28 Dec 2002 09:03:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 136A091208; Sat, 28 Dec 2002 09:06:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF4489120E; Sat, 28 Dec 2002 09:06: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 CF43191208 for ; Sat, 28 Dec 2002 09:06:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 98C915DEE7; Sat, 28 Dec 2002 09:06:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by segue.merit.edu (Postfix) with ESMTP id 1D9F75DE0D for ; Sat, 28 Dec 2002 09:06:52 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.cs.mu.OZ.AU [2001:388:c02:4001:206:5bff:feda:45ad]) by munnari.OZ.AU (8.11.6/8.11.6) with ESMTP id gBSE6kq14445; Sun, 29 Dec 2002 01:06:46 +1100 (EST) 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 gBSE6QT19763; Sun, 29 Dec 2002 01:06:27 +1100 (EST) From: Robert Elz To: Stuart Cheshire Cc: "Christian Huitema" , "Zeroconf" Subject: Re: TTL=255 on xmit, no check on receipt please In-Reply-To: <200212272340.gBRNe2f00009@scv3.apple.com> References: <200212272340.gBRNe2f00009@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 29 Dec 2002 01:06:25 +1100 Message-ID: <19761.1041084385@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 27 Dec 2002 15:40:01 -0800 From: Stuart Cheshire Message-ID: <200212272340.gBRNe2f00009@scv3.apple.com> | I quote from Dave Thaler , in the | arguments he gave which convinced the working group to adopt TTL=255: | | >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. Upon reflection though it has been shown that neither of those is correct or relevant. A node for which the spec would apply (one which is implementing LL addresses) is never going to send one to a router, so you're never going to discover holes in router configurations this way (note this is completely different from the case where the argument was first put relating to multicast). Similarly, you'll never detect offenders this way. The only packets with LL addresses in them that will get sent to routers are packets from implementations that have never heard of LL addresses, and believe these things are just regular IP addresses. Obviously, the LL spec isn't going to influence them, one way or the other, so what it says the TTL should be set to is irrelevant there. The only point of the TTL=255 stuff here, is so you could check it and reject packets that have come from outside (the way that v6 ND does). But as has also been shown here before, that's completely meaningless here, there's simply no point doing that. TTL==1 has the (very minor) benefit that Christian mentioned, where no attempt will be made in a badly misconfigured net to send packets into the internet, but the chances of this actually happening (so many things have to be broken at once for it to ever matter) are so small that this isn't worth it either. All mention of special TTL values should simply be stricken from the docs, they gain absolutely nothing. Allow implementations to set whatever they believe is sane (which may often be 1, with a config knob to allow other values so a net can communicate with implementations that assume 255 & actually check it - but this is an implementation matter). kre From owner-zeroconf@merit.edu Sat Dec 28 09:04:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05391 for ; Sat, 28 Dec 2002 09:04:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 827729120E; Sat, 28 Dec 2002 09:07:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 505479122E; Sat, 28 Dec 2002 09:07: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 441A99120E for ; Sat, 28 Dec 2002 09:07:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 360C75DEE7; Sat, 28 Dec 2002 09:07:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by segue.merit.edu (Postfix) with ESMTP id 3CE465DE0D for ; Sat, 28 Dec 2002 09:07:35 -0500 (EST) Received: from ilister.dialup.dstc.edu.au (ilister.dialup.dstc.edu.au [130.102.182.103]) by piglet.dstc.edu.au (8.12.3/8.12.3) with ESMTP id gBSE7NOT006762 for ; Sun, 29 Dec 2002 00:07:24 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id gBSE7B412832; Sun, 29 Dec 2002 00:07:11 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Sun, 29 Dec 2002 00:07:11 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: Zeroconf Subject: Re: Application software needs to be "zeroconf-aware"? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checked: SPAMASSASSIN: This message probably not SPAM X-Spam-Score: -3.9, Required: 5 X-Virus-Scanned: Message: ok X-Scanned-By: MIMEDefang 2.9 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-zeroconf@merit.edu Precedence: bulk On Fri, 27 Dec 2002, John C. Welch wrote: >On 12/27/2002 21:23, "Keith Moore" wrote: >> distributed apps will fail; examples include gnutella (and friends), > >That's pretty interesting since I use Limewire and Rendezvous all the time. Rendezvous/zeroconf as implemented in Mac OS X 10.2 doesn't assign an IPv4LL address to an interface when it has already obtained an address for that interface. I believe this difference between the draft and the existing implementations is one of Keith's primary concerns. Ian P.S. note that OS X 10.2 does create a IPv4LL route, which ensure a host with a configured address can still communicate with a LL-only host on the same link. From owner-zeroconf@merit.edu Sat Dec 28 09:09:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05433 for ; Sat, 28 Dec 2002 09:09:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E15F39122E; Sat, 28 Dec 2002 09:12:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB18C91243; Sat, 28 Dec 2002 09:12: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 A2FFE9122E for ; Sat, 28 Dec 2002 09:12:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C8305DEFC; Sat, 28 Dec 2002 09:12:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by segue.merit.edu (Postfix) with ESMTP id 8B03B5DEE7 for ; Sat, 28 Dec 2002 09:12:11 -0500 (EST) Received: from ilister.dialup.dstc.edu.au (ilister.dialup.dstc.edu.au [130.102.182.103]) by piglet.dstc.edu.au (8.12.3/8.12.3) with ESMTP id gBSEC5OT006891 for ; Sun, 29 Dec 2002 00:12:07 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id gBSEBto12858; Sun, 29 Dec 2002 00:11:55 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Sun, 29 Dec 2002 00:11:55 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: Zeroconf Subject: Re: Application software needs to be "zeroconf-aware"? In-Reply-To: <200212280223.gBS2N4j19495@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checked: SPAMASSASSIN: This message probably not SPAM X-Spam-Score: -3.9, Required: 5 X-Virus-Scanned: Message: ok X-Scanned-By: MIMEDefang 2.9 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-zeroconf@merit.edu Precedence: bulk On Fri, 27 Dec 2002, Keith Moore wrote: >distributed apps will fail; examples include gnutella (and friends), apps >based on globus, pvm, netsolve; apps that use sip. also some distributed >games, some conferencing software, but since I don't use these I can't name >specific instances of these. Perhaps it would be helpful if you picked two or three of the above examples and spelled out exactly how these applications will fail, in enough detail that nobody will be in any further doubt? Ian From owner-zeroconf@merit.edu Sat Dec 28 09:43:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05689 for ; Sat, 28 Dec 2002 09:43:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CE38191210; Sat, 28 Dec 2002 09:46:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6135E91243; Sat, 28 Dec 2002 09: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 BDDF391210 for ; Sat, 28 Dec 2002 09:46:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 933D05DF57; Sat, 28 Dec 2002 09:46:19 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 3337E5DF4D for ; Sat, 28 Dec 2002 09:46:19 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBSEjij05169; Sat, 28 Dec 2002 09:45:49 -0500 (EST) Message-Id: <200212281445.gBSEjij05169@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ian Lister Cc: Zeroconf Subject: Re: Application software needs to be "zeroconf-aware"? In-reply-to: (Your message of "Sun, 29 Dec 2002 00:11:55 +1000.") Date: Sat, 28 Dec 2002 09:45:44 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > >distributed apps will fail; examples include gnutella (and friends), apps > >based on globus, pvm, netsolve; apps that use sip. also some distributed > >games, some conferencing software, but since I don't use these I can't name > >specific instances of these. > > Perhaps it would be helpful if you picked two or three of the above > examples and spelled out exactly how these applications will fail, in > enough detail that nobody will be in any further doubt? I've already explained this also. Apps will fail when they try to use limited-scope addresses from outside of their scope, either by trying to contact those addresses or by trying to use them as unique identifiers. Such addresses can be obtained either by referral (transmitting the IP address) within the application, or referral via another application (including but not limited to DNS). From owner-zeroconf@merit.edu Sat Dec 28 10:21:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06059 for ; Sat, 28 Dec 2002 10:21:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5D27991226; Sat, 28 Dec 2002 10:24:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F0C991230; Sat, 28 Dec 2002 10:24:43 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E849B91226 for ; Sat, 28 Dec 2002 10:24:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id C9BF25DF5F; Sat, 28 Dec 2002 10:24:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by segue.merit.edu (Postfix) with ESMTP id D13C55DF44 for ; Sat, 28 Dec 2002 10:24:40 -0500 (EST) Received: from ilister.dialup.dstc.edu.au (ilister.dialup.dstc.edu.au [130.102.182.103]) by piglet.dstc.edu.au (8.12.3/8.12.3) with ESMTP id gBSFOOOT009268; Sun, 29 Dec 2002 01:24:29 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id gBSFOEt13006; Sun, 29 Dec 2002 01:24:14 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Sun, 29 Dec 2002 01:24:14 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: Keith Moore Cc: Zeroconf Subject: Re: Application software needs to be "zeroconf-aware"? In-Reply-To: <200212280110.gBS1ANj19057@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checked: SPAMASSASSIN: This message probably not SPAM X-Spam-Score: -4.5, Required: 5 X-Virus-Scanned: Message: ok X-Scanned-By: MIMEDefang 2.9 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-zeroconf@merit.edu Precedence: bulk On Fri, 27 Dec 2002, Keith Moore wrote: >your question constrains the answer in a way that would make the answer >misleading. most apps that would work on an isolated network with >only two hosts and statically-assigned IP address literals would work >as well with v4LLs. so if the only apps you care about are those that >only need to work between two hosts on an isolated network, LL is great >for you. but many other apps will fail in the presence of v4LL. >pretending that those apps don't exist, or are not important, isn't helpful. I think your point here is that zeroconf on disconnected networks is all well and good (enabling various applications to work where they otherwise couldn't), but introducing it on connected networks that already have wider scope addressing schemes in place might cause existing applications to fail, due to attempting to use link-local addresses to communicate between links. Is that correct? On Sat, 28 Dec 2002, Keith Moore wrote: >I've already explained this also. Apps will fail when they try to use >limited-scope addresses from outside of their scope, either by trying to >contact those addresses or by trying to use them as unique identifiers. You're really going to need to be specific about this in order to convince anybody. Pick an application, tell us how it works, and show how IPv4LL prevents it from working. >Such addresses can be obtained either by referral (transmitting the IP >address) within the application, A classic application that does this is FTP (one that has, I might add, been broken by other extensions to usage of IP such as NAT, but where people preferred to use the extensions and work around the protocol rather than prevent use of the extension). FTP is *not* broken because implementations use getsockname() or equivalent to find an appropriate local address to transmit. It would seem that any other application transmitting addresses directly should be doing the same, too. (Picking an arbitrary local address would be broken anyway, because a host could have addresses on different networks that cannot be routed between.) Can you name any applications that use direct referral of addresses and *are* broken by IPv4LL? > or referral via another application >(including but not limited to DNS). What in the zeroconf drafts will lead to IPv4LL addresses going into DNS? They may be advertised by mDNS but by definition that's LL only anyway. If anybody for some reason starts putting them (or allowing them to be put) into a unicast DNS zone then that's an administrative issue to ensure they are not published beyond the link, rather than a legacy fragile software issue, isn't it? It's just the same as with scoped IPv6 addresses, and administrators have just as much control over how and whether they should be published in DNS. Can you name any applications that use indirect referral of addresses and *are* broken by IPv4LL? Assuming you can provide some examples and convince the members of the group to see this as a problem, I see several options that you might think appropriate paths forward: 1. Require that IPv4LL be active only on hosts that are unable to find an address any other way. 2. Require that existing system APIs for enumerating system addresses not return IPv4LL addresses if others are available, and that (in that case) IPv4LL addresses must be explicitly asked for. Would either of these options satisfy you? Do you see any other options? >then please fix v4LL so that it's disabled whenever you are connected to >a larger network. that way it won't break anything that already works. If the draft were changed to do this (i.e. option 1 above, so that it matched the behaviour of existing implementations) would you be happy with it? Ian From owner-zeroconf@merit.edu Sat Dec 28 11:17:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06451 for ; Sat, 28 Dec 2002 11:17:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BFE1B91245; Sat, 28 Dec 2002 11:20:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F97D91246; Sat, 28 Dec 2002 11:20:01 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C7A591245 for ; Sat, 28 Dec 2002 11:20:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 20C225DE7A; Sat, 28 Dec 2002 11:20:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id EA16B5DDDF for ; Sat, 28 Dec 2002 11:19:59 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBSGJ6j05801; Sat, 28 Dec 2002 11:19:16 -0500 (EST) Message-Id: <200212281619.gBSGJ6j05801@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ian Lister Cc: Keith Moore , Zeroconf Subject: Re: Application software needs to be "zeroconf-aware"? In-reply-to: (Your message of "Sun, 29 Dec 2002 01:24:14 +1000.") Date: Sat, 28 Dec 2002 11:19:06 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > On Fri, 27 Dec 2002, Keith Moore wrote: > >your question constrains the answer in a way that would make the answer > >misleading. most apps that would work on an isolated network with > >only two hosts and statically-assigned IP address literals would work > >as well with v4LLs. so if the only apps you care about are those that > >only need to work between two hosts on an isolated network, LL is great > >for you. but many other apps will fail in the presence of v4LL. > >pretending that those apps don't exist, or are not important, isn't helpful. > > I think your point here is that zeroconf on disconnected networks is all > well and good (enabling various applications to work where they otherwise > couldn't), but introducing it on connected networks that already have > wider scope addressing schemes in place might cause existing applications > to fail, due to attempting to use link-local addresses to communicate > between links. Is that correct? Yes. (though there are other reasons that v4LL can cause problems than attempts by apps to use v4LL addresses from outside of their scope) > On Sat, 28 Dec 2002, Keith Moore wrote: > >I've already explained this also. Apps will fail when they try to use > >limited-scope addresses from outside of their scope, either by trying to > >contact those addresses or by trying to use them as unique identifiers. > Pick an application, tell us how it works, and show how IPv4LL > prevents it from working. I've already done this, multiple times. > >Such addresses can be obtained either by referral (transmitting the IP > >address) within the application, > > A classic application that does this is FTP (one that has, I might add, > been broken by other extensions to usage of IP such as NAT, Note that NAT has never been standardized for the very reason that it breaks so many apps - but that hasn't stopped zeroconf from demanding that v4LL be standardized when it breaks a similar number of apps, for similar reasons. > but where > people preferred to use the extensions and work around the protocol rather > than prevent use of the extension). FTP does this. HTTP can also use IP addresses in referrals and there are good reasons to use IP addresses in local referrals (where the referring server reliably knows the IP address of the server being referred to) as it improves reliability and performance. SIP can use IP addresses in referrals also, and this speeds call completion and is more reliable than requiring DNS lookups. Gnutella passes IP addresses over the network, both to identify resource locations (you can find resource X at address Y) and to identify nodes that can perform routing of traffic. It does have ways of trying to work around NATs and firewalls, and these might (with some modification) also work for hosts using LL. But this degrades functionality and performance for those nodes. (And they don't work entirely - if you look at traffic you'll see referrals for resources at RFC 1918 addresses. They can be filtered but the basic problem is that a node has no way of knowing whether a 1918 address - or for that matter a v4LL address - is in its scope or not.) The applications that I'm most familiar with that have problems with scoped addresses are distributed apps used in high-performance computing. For instance, PVM (parallel virtual machine) maintains a list of (host #, IP address) pairs for every host that is used in the computation; this list is replicated on every host within that computation. PVM expects to be able to send traffic from any host to any other host in the machine. Naturally this will fail if some of those IP addresses are LL addresses and some of the hosts are not in the same scope. MPI implementations that work over IP do much the same thing. (Both PVM and MPI support a model where computational nodes are represented by small, dense integers - e.g. from 1 to N. Many distributed computations are written to use this kind of model - it makes it easy to divide a problem up into N portions, for instance, and it also makes it easy to store per-node information in arrays.) NetSolve has processses known as agents which keep lists of (problem, IP address, port) triples, which describe that a particular server host listening on a particular port is willing to perform a particular kind of computation for a client. A NetSolve client that wants that kind of computation will query a NetSolve agent for the address of a host that is willing to perform that kind of computation. The client will then contact the server host directly. Obviously this will fail if the IP address of the server is a v4LL address and the client and server (or agent and server) are not in the same scope. > Assuming you can provide some examples and convince the members of the > group to see this as a problem, I see several options that you might think > appropriate paths forward: > > 1. Require that IPv4LL be active only on hosts that are unable to find an > address any other way. > > 2. Require that existing system APIs for enumerating system addresses not > return IPv4LL addresses if others are available, and that (in that > case) IPv4LL addresses must be explicitly asked for. > > Would either of these options satisfy you? Do you see any other options? I've suggested both of these in the past. I've also suggested that there be a standard way for managed networks to be able to disable v4LL, in order to work around this and other problems that v4LL might cause. > >then please fix v4LL so that it's disabled whenever you are connected to > >a larger network. that way it won't break anything that already works. > > If the draft were changed to do this (i.e. option 1 above, so that it > matched the behaviour of existing implementations) would you be happy with > it? This is most of what I've been asking for for several months. Keith From owner-zeroconf@merit.edu Sat Dec 28 12:29:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07197 for ; Sat, 28 Dec 2002 12:29:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B1AF91246; Sat, 28 Dec 2002 12:32:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F332391248; Sat, 28 Dec 2002 12:32: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 96AB191246 for ; Sat, 28 Dec 2002 12:32:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7DE195DF54; Sat, 28 Dec 2002 12:32:29 -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 13BD85DE78 for ; Sat, 28 Dec 2002 12:32:29 -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 MAA10814 for ; Sat, 28 Dec 2002 12:32: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 MAA27518 for ; Sat, 28 Dec 2002 12:32:28 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA17808 for ; Sat, 28 Dec 2002 12:32:27 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Sat, 28 Dec 2002 12:32:25 -0500 Subject: Re: Application software needs to be "zeroconf-aware"? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212281445.gBSEjij05169@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/28/2002 09:45, "Keith Moore" wrote: >> Perhaps it would be helpful if you picked two or three of the above >> examples and spelled out exactly how these applications will fail, in >> enough detail that nobody will be in any further doubt? > > I've already explained this also. Apps will fail when they try to use > limited-scope addresses from outside of their scope, either by trying to > contact those addresses or by trying to use them as unique identifiers. But that would apply to *any* situation with limited scope addresses. A network NOT connected to the public internet would have the *same* problem under the same circumstances. This has *nothing* to do with LL, and everything to do with the saying, "You cahn't get thea from hea". If I put a cleaver through all of your connections to the external world, even IPv6 is going to lose it's little mind. > Such addresses can be obtained either by referral (transmitting the IP > address) within the application, or referral via another application > (including but not limited to DNS). Again, you're talking about situations in which any addressing method is going to fail, and this includes even your much - vaunted IPv6. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sat Dec 28 12:56:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07409 for ; Sat, 28 Dec 2002 12:56:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9847491211; Sat, 28 Dec 2002 12:59:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57EA391248; Sat, 28 Dec 2002 12:59: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 04F9991211 for ; Sat, 28 Dec 2002 12:59:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF3435DF5E; Sat, 28 Dec 2002 12:59:26 -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 A57405DF44 for ; Sat, 28 Dec 2002 12:59:26 -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 MAA14770 for ; Sat, 28 Dec 2002 12:59:26 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA27984 for ; Sat, 28 Dec 2002 12:59:25 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA18901 for ; Sat, 28 Dec 2002 12:59:25 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Sat, 28 Dec 2002 12:59:23 -0500 Subject: Re: Application software needs to be "zeroconf-aware"? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212281619.gBSGJ6j05801@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/28/2002 11:19, "Keith Moore" wrote: >> I think your point here is that zeroconf on disconnected networks is all >> well and good (enabling various applications to work where they otherwise >> couldn't), but introducing it on connected networks that already have >> wider scope addressing schemes in place might cause existing applications >> to fail, due to attempting to use link-local addresses to communicate >> between links. Is that correct? > > Yes. (though there are other reasons that v4LL can cause problems than > attempts by apps to use v4LL addresses from outside of their scope) And that can be handled by any number of methods before applications see it, enough that it would be silly to enumerate them all in the spec. It's a spec, not a howto. And any addressing method used outside of it's scope is going to fail. >> Pick an application, tell us how it works, and show how IPv4LL >> prevents it from working. > > I've already done this, multiple times. You have yet to name a single application. You name general types, you name theories, but not a specific application that *anyone* can observe failing and be able to identify the problem, and then the solution. One might think you don't actually *want* a solution, just an unending list of problems to torpedo zeroconf entirely. >> A classic application that does this is FTP (one that has, I might add, >> been broken by other extensions to usage of IP such as NAT, > > Note that NAT has never been standardized for the very reason that it breaks > so many apps - but that hasn't stopped zeroconf from demanding that v4LL > be standardized when it breaks a similar number of apps, for similar reasons. > One example Keith. One specific application that can be downloaded and tested. And NAT works correctly when implemented correctly, but that's a different horse to beat. >> but where >> people preferred to use the extensions and work around the protocol rather >> than prevent use of the extension). > > FTP does this. HTTP can also use IP addresses in referrals and there are > good reasons to use IP addresses in local referrals (where the referring > server > reliably knows the IP address of the server being referred to) as it improves > reliability and performance. SIP can use IP addresses in referrals also, and > this > speeds call completion and is more reliable than requiring DNS lookups. > Gnutella > passes IP addresses over the network, both to identify resource locations (you > can find > resource X at address Y) and to identify nodes that can perform routing of > traffic. > It does have ways of trying to work around NATs and firewalls, and these might > (with some modification) also work for hosts using LL. But this degrades > functionality and performance for those nodes. (And they don't work entirely Um, Gnutella handles NATs just fine...wait, let me look...yep, running just fine through a NAT, and all it's features work right too. Hmmm. As well, you *can* do a lot of things. Using hard-wired IP addresses instead of DNS names is just dumb, *unless* you have no other choice. Considering the ubiquity of DNS, I'm thinking that will happen not often at all. As well, if DNS is so unreliable, then why use it at all? Oh wait, it isn't unreliable, but it *can* be slower. > - > if you look at traffic you'll see referrals for resources at RFC 1918 > addresses. > They can be filtered but the basic problem is that a node has no way of > knowing > whether a 1918 address - or for that matter a v4LL address - is in its scope > or not.) No, you don't until you try to use it. That's life on the internet. The Web server you were using just a second ago crashed, oops, that address is no longer valid, so sad, too bad. You can't prevent that. > > The applications that I'm most familiar with that have problems with scoped > addresses are distributed apps used in high-performance computing. > > For instance, PVM (parallel virtual machine) maintains a list of (host #, > IP address) pairs for every host that is used in the computation; this list > is replicated on every host within that computation. PVM expects to be > able to send traffic from any host to any other host in the machine. > Naturally this will fail if some of those IP addresses are LL addresses and > some of the hosts are not in the same scope. Well, you'd have to be pretty careless to set up a PVM, and not double check that all your machines are on the same subnet. That's going to bite you LL or not. If all the machines can use LL addresses, and they are all on the same physical net, then they can see each other. It's only if some are *not* able to use LL at all then you would have problems. Of course, this is easily fixable, unless the LL machines could ONLY use LL, and I have yet to see anyone dumb enough to put out a stack that can't be at least manually configured. Your example fails under manual addressing errors to. > > NetSolve has processses known as agents which keep lists of (problem, IP > address, port) > triples, which describe that a particular server host listening on a > particular port is > willing to perform a particular kind of computation for a client. A NetSolve > client that > wants that kind of computation will query a NetSolve agent for the address of > a host that > is willing to perform that kind of computation. The client will then > contact the > server host directly. Obviously this will fail if the IP address of the > server is a > v4LL address and the client and server (or agent and server) are not in the > same scope. This will also fail if the IP address of the client and server are in completely different subnets without a router. Again, yes, that is a failure condition, but it is hardly unique to LL, and is only going to be a *hard* failure if the LL machine cannot be configured to use a non-LL address. Considering every IP stack since IP began can be manually configured, I'm not real worried about anyone with two functional brain cells eliminating this ability. > >> Assuming you can provide some examples and convince the members of the >> group to see this as a problem, I see several options that you might think >> appropriate paths forward: >> >> 1. Require that IPv4LL be active only on hosts that are unable to find an >> address any other way. >> >> 2. Require that existing system APIs for enumerating system addresses not >> return IPv4LL addresses if others are available, and that (in that >> case) IPv4LL addresses must be explicitly asked for. >> >> Would either of these options satisfy you? Do you see any other options? > > I've suggested both of these in the past. I've also suggested that there > be a standard way for managed networks to be able to disable v4LL, in order > to work around this and other problems that v4LL might cause. You have yet to enumerate a single v4LL problem that isn't a problem for *any* v4 implementation, LL or not. Okay, let's restate this...name a problem that is *created by*, and *unique to* v4LL. As well, requiring either of those two options is going to break the idea of zeroconf. If I'm at a seminar, and I just need to print, and I have manually configured IPs on all my interfaces, and there is a nice zeroconf wireless network for printing, then the *only* way I can use that network is to *manually* enable zeroconf on that interface, and then later having to *manually* disable it on that interface so I can use my manual settings. (remember boys and girls, manual configs don't have any external methods to tell you that you're configured.) The idea with Zeroconf is that you don't.have.to.manually.do.anything. It.just.works. No manual configuration occaisionally. None. Yes it means that the vendors have to do more work for this, but not a lot of work, since single - link multihoming is in use every day by thousands of machines, and works real well. Multiple IP's on a single interface is not new. Neither is multiple IP's on multiple interfaces. It's been being used, without problems for *years* in the real world. Zeroconf's only purpose is to make IP networking easy. Not easier. DHCP did that. Easy. And easy for non-technical types. They way AppleTalk did over ten years ago. Why is that so alien? This isn't for us. We don't need it. It's for them. Ma and Pa Kettle. Salesmen at a client's. Kids in a dorm. Teenagers who just want to play a nice round of Unreal without needing to reconfigure IP stacks. If we cannot agree that ease of use is the primary, and indeed only reason for this standard to exist, then I vote we kill the entire IETF effort on zeroconf, indeed, *any* IETF effort that tries to mention ease of use, stop wasting time, and let the vendors sort it out. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sat Dec 28 14:31:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08188 for ; Sat, 28 Dec 2002 14:31:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EA8E791218; Sat, 28 Dec 2002 14:34:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B86549121D; Sat, 28 Dec 2002 14:34: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 A614D91218 for ; Sat, 28 Dec 2002 14:34:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 83DB25DF83; Sat, 28 Dec 2002 14:34:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by segue.merit.edu (Postfix) with ESMTP id 437325DF4E for ; Sat, 28 Dec 2002 14:34:10 -0500 (EST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 28 Dec 2002 11:34:09 -0800 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 28 Dec 2002 11:34:09 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Sat, 28 Dec 2002 11:34:09 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 28 Dec 2002 11:34:09 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Sat, 28 Dec 2002 11:34:09 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: TTL=255 on xmit, no check on receipt please Date: Sat, 28 Dec 2002 11:34:08 -0800 Message-ID: Thread-Topic: TTL=255 on xmit, no check on receipt please Thread-Index: AcKtzwH6ivfiQtulRKmge9/sCV2vfAA2G/1u From: "Christian Huitema" To: "Daniel Senie" , "Zeroconf" X-OriginalArrivalTime: 28 Dec 2002 19:34:09.0019 (UTC) FILETIME=[176774B0:01C2AEA8] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA08188 >>Using IPv6 does require a software upgrade on those computers that don't >>have an IPv6 stack, but deploying a new IPv4 feature like auto-IP on those >>computers that don't support it yet also requires a software upgrade. > >Except that for the most part we're talking about something which MOST host >platforms PRESENTLY support. LinkLocal has been shipped by Microsoft for >many years (win98), has been in Mac OS for some time and I believe it's in >the Linux distributions. Look, I am not saying that we should not issue a standard that documents the existing practice. I am saying that the main reason for standardizing an IPv4 solution is "compatibility with the installed base", which is exactly the argument you just repeated.The point is, if we wanted an incompatible solution, we could just use IPv6. If the IPv4 solution aims for compatibility, then it should consider that these Windows 98 boxes that you mention set the TTL to 128, which is precisely the argument for "no check on receipt." -- Christian Huitema From owner-zeroconf@merit.edu Sat Dec 28 14:45:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08378 for ; Sat, 28 Dec 2002 14:45:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B2ECD9121D; Sat, 28 Dec 2002 14:48:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C725491224; Sat, 28 Dec 2002 14:48: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 1DC379121D for ; Sat, 28 Dec 2002 14:48:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id EACCB5DFBC; Sat, 28 Dec 2002 14:48:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by segue.merit.edu (Postfix) with ESMTP id AAD705DFBA for ; Sat, 28 Dec 2002 14:48:07 -0500 (EST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 28 Dec 2002 11:48:07 -0800 Received: from 157.54.8.23 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 28 Dec 2002 11:48:07 -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); Sat, 28 Dec 2002 11:48:07 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 28 Dec 2002 11:48:06 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Sat, 28 Dec 2002 11:48:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Application software needs to be "zeroconf-aware"? Date: Sat, 28 Dec 2002 11:48:06 -0800 Message-ID: Thread-Topic: Application software needs to be "zeroconf-aware"? Thread-Index: AcKumuaxtIzamoPuSAyidWBBSueyFAADUWFB From: "Christian Huitema" To: "John C. Welch" , "Zeroconf" X-OriginalArrivalTime: 28 Dec 2002 19:48:06.0794 (UTC) FILETIME=[0AC1C6A0:01C2AEAA] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA08378 >>> I think your point here is that zeroconf on disconnected networks is all >>> well and good (enabling various applications to work where they otherwise >>> couldn't), but introducing it on connected networks that already have >>> wider scope addressing schemes in place might cause existing applications >>> to fail, due to attempting to use link-local addresses to communicate >>> between links. Is that correct? >> >> Yes. (though there are other reasons that v4LL can cause problems than >> attempts by apps to use v4LL addresses from outside of their scope) > >And that can be handled by any number of methods before applications see it, >enough that it would be silly to enumerate them all in the spec. It's a >spec, not a howto. And any addressing method used outside of it's scope is >going to fail. Introducing scoped addresses does indeed change the programming model. We have had multiple examples of that when porting applications to use IPv6, and IPv4 LL will have the same issue. The classic socket programming model is more or less the following: 1) Application obtains name of peer, 2) Application resolves name, obtains address of peer, and copies it in a sockaddr structure, 3) Application tries to "connect()" to the peer. The problem is that the "copy to sockaddr" operation normally only copies the address, not the link id. The stack can compensate when there is only one link, and assume that any reference to a link local address goes to this link. But if the host is multi-homed, there is no solution that works really well. For link local addresses to work reliably, the application must be able to indicate the link identifier to the stack; this is done by copying a link id in the sockaddr in IPv6. With IPv4, you have to use something else, e.g. explicitly bind the socket to an interface. In short, Keith is correct: to work reliably, the application must be aware of the scope of the addresses. -- Christian Huitema From owner-zeroconf@merit.edu Sat Dec 28 15:54:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08886 for ; Sat, 28 Dec 2002 15:54:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A470E91248; Sat, 28 Dec 2002 15:57:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67F8991249; Sat, 28 Dec 2002 15:57: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 4FBB591248 for ; Sat, 28 Dec 2002 15:57:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F2735DFBA; Sat, 28 Dec 2002 15:57:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id D78195DDB3 for ; Sat, 28 Dec 2002 15:57:08 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBSKv5j06938; Sat, 28 Dec 2002 15:57:06 -0500 (EST) Message-Id: <200212282057.gBSKv5j06938@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Christian Huitema" Cc: "Zeroconf" Subject: Re: Application software needs to be "zeroconf-aware"? In-reply-to: (Your message of "Sat, 28 Dec 2002 11:48:06 PST.") Date: Sat, 28 Dec 2002 15:57:05 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > In short, Keith is correct: to work reliably, the application must be aware of the scope of > the addresses. The other piece of this is that when scoped addresses are potentially used by other nodes, there is no way for the application to be aware of the scope of the address. There is not even a good way of naming such scopes. (On a single machine, you can use the interface name as a scope name, but these scope names are local to the host). So it is not just as simple as expecting the app or the kernel to keep track of scope - that only solves the problem on the local machine. In short: scoped addresses are not generally applicable; they need to be used sparingly. Keith From owner-zeroconf@merit.edu Sat Dec 28 21:24:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11699 for ; Sat, 28 Dec 2002 21:24:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E500091274; Sat, 28 Dec 2002 21:27:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF95E91275; Sat, 28 Dec 2002 21:27: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 9E80491274 for ; Sat, 28 Dec 2002 21:27:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8DEE75DF87; Sat, 28 Dec 2002 21:27:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 314D05DDA1 for ; Sat, 28 Dec 2002 21:27:05 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBT2R4j08223; Sat, 28 Dec 2002 21:27:04 -0500 (EST) Message-Id: <200212290227.gBT2R4j08223@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: zeroconf@merit.edu Subject: response to John Welch's bogus assertions Cc: moore@cs.utk.edu From: Keith Moore Date: Sat, 28 Dec 2002 21:27:04 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk Folks, I've prepared a response to John Welch's latest set of bogus assertions about the nature of scoped addresses, distributed apps, IP, and this group's purpose. If anyone wants to read it, let me know via a private reply and I'll send it via private mail. But I'm not going to waste this list's bandwidth with it. Keith From owner-zeroconf@merit.edu Sat Dec 28 22:28:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12739 for ; Sat, 28 Dec 2002 22:28:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4AB6D91276; Sat, 28 Dec 2002 22:31:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8A4D91277; Sat, 28 Dec 2002 22:31: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 6DF2691276 for ; Sat, 28 Dec 2002 22:31:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 41ED95DF65; Sat, 28 Dec 2002 22:31:11 -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 C6BCA5DE0A for ; Sat, 28 Dec 2002 22:31:10 -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 WAA00766 for ; Sat, 28 Dec 2002 22:31:10 -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 WAA14176 for ; Sat, 28 Dec 2002 22:31:09 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id WAA10814 for ; Sat, 28 Dec 2002 22:31:09 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Sat, 28 Dec 2002 22:31:07 -0500 Subject: Re: response to John Welch's bogus assertions From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212290227.gBT2R4j08223@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/28/2002 21:27, "Keith Moore" wrote: > I've prepared a response to John Welch's latest set of bogus assertions > about the nature of scoped addresses, distributed apps, IP, and this > group's purpose. If anyone wants to read it, let me know via a private > reply and I'll send it via private mail. But I'm not going to waste this > list's bandwidth with it. > Well, it would be about time that you showed a clear example of an app that can be tested. I'm just sorry that you had to be beaten about the head and shoulders so much by so many people to do so. But please, by all means, send to me too. But if you want to call "ease of use" bogus, then I'm not surprised at all. I've yet to meet too many folks creating networks who really cared at all about what happens to non-geeks who use them, outside of one company, namely Apple. I will stand by my remarks on the purpose of this group without flinching or backing down one bit. If we don't make IP as easy, or easier to use as Appletalk, then the group is a failure. I'm tired of calls from people who just want this to work. They don't mind minor setups, but are tired of it taking 20 minutes to set up to play a game, or print something. We spend *millions*, possibly closer to *billions* on mouse algorigthms and behaviors, and yet haven't significantly improved IP networking since DHCP and DyDNS. I can cluster a group of Playstation 2's easier than I can set up an ad hoc network, and a lot faster as well. And no, I don't think that 'wait for IPv6' is an acceptable answer. It seems that there are too many people who are willing to once again, force everyone to do things the hard way just to avoid the possibility that a geek won't be able to configure something. Well, the geeks can deal. Networking is no longer the realm of geeks. It's the realm of plain folks, and right now, there isn't a decent IPv4 config model out there for non-geeks. DHCP isn't it, DNS was never it. If it takes more than: Make sure connections are there, (wires plugged in, wireless card physically in computer). Make sure IP networking is on, (this is a default setting). Start doing networking stuff. Then it isn't easy enough, and it isn't zeroconf. What part of that is so hard to understand? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sat Dec 28 23:21:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13398 for ; Sat, 28 Dec 2002 23:21:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D103A91277; Sat, 28 Dec 2002 23:24:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E9C591278; Sat, 28 Dec 2002 23:24: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 887B891277 for ; Sat, 28 Dec 2002 23:24:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 63EE25DFD4; Sat, 28 Dec 2002 23:24:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 090AB5DFD0 for ; Sat, 28 Dec 2002 23:24:49 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBT4Omj08821; Sat, 28 Dec 2002 23:24:48 -0500 (EST) Message-Id: <200212290424.gBT4Omj08821@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: zeroconf@merit.edu Subject: what John Welch wants Cc: moore@cs.utk.edu From: Keith Moore Date: Sat, 28 Dec 2002 23:24:48 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > If we don't make IP as easy, or easier to use as > Appletalk, then the group is a failure. This is not in this group's charter. If this group is trying to do that, it's violating its charter and it needs a mercy killing. zeroconf is chartered "to enable [IP] networking in the *absence* of configuration and administration", as in isolated networks. It is NOT chartered to change how IP works on configured/managed networks. Keith From owner-zeroconf@merit.edu Sat Dec 28 23:34:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13481 for ; Sat, 28 Dec 2002 23:34:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B36E91278; Sat, 28 Dec 2002 23:37:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0ADDA91279; Sat, 28 Dec 2002 23: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 ECEAC91278 for ; Sat, 28 Dec 2002 23:37:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id C40F85DFA3; Sat, 28 Dec 2002 23:37:29 -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 4A4D15DE3F for ; Sat, 28 Dec 2002 23:37:29 -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 XAA11023 for ; Sat, 28 Dec 2002 23:37:28 -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 XAA15086 for ; Sat, 28 Dec 2002 23:37:28 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id XAA12971 for ; Sat, 28 Dec 2002 23:37:27 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Sat, 28 Dec 2002 23:37:26 -0500 Subject: Re: what John Welch wants From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212290424.gBT4Omj08821@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/28/2002 23:24, "Keith Moore" wrote: >> If we don't make IP as easy, or easier to use as >> Appletalk, then the group is a failure. > > This is not in this group's charter. If this group is trying to do that, > it's violating its charter and it needs a mercy killing. Maybe it does. Maybe the IETF is simply unable to function at the user level, and should stop bothering. It doesn't have a top notch track record there, and from what I can tell, 'easy' isn't a concept that geeks readily grok. For the most part, we've lost touch with the rest of the world. > > zeroconf is chartered "to enable [IP] networking in the *absence* of > configuration and administration", as in isolated networks. It is > NOT chartered to change how IP works on configured/managed networks. If we don't make things easy to use for normal people, then why bloody bother? I definitely have things that could easily use the time I spend tilting at the "Networking is a geek thing" windmill. But I have family who aren't geeks, and they hate everything about the current setup schemes. And how is making IPv4 as easy to use as Appletalk *changing* how IP works on a managed network? You're reducing the level of difficulty in setting it up. It is still going to work the same. But then, maybe we fear the loss of our power over people who have not the secret knowledge... john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sun Dec 29 00:17:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13938 for ; Sun, 29 Dec 2002 00:17:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4333E9121F; Sun, 29 Dec 2002 00:20:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1505191228; Sun, 29 Dec 2002 00:20: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 04D429121F for ; Sun, 29 Dec 2002 00:20:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id DBF8B5DE3F; Sun, 29 Dec 2002 00:20:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by segue.merit.edu (Postfix) with ESMTP id 9C1AA5DE1D for ; Sun, 29 Dec 2002 00:20:37 -0500 (EST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 28 Dec 2002 21:20:37 -0800 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 28 Dec 2002 21:20:37 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Sat, 28 Dec 2002 21:20:36 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 28 Dec 2002 21:20:36 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Sat, 28 Dec 2002 21:20:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should people still be making IPv4 products? Date: Sat, 28 Dec 2002 21:20:37 -0800 Message-ID: Thread-Topic: Should people still be making IPv4 products? Thread-Index: AcKuBwJ03VDH1JScQ6yCjA8vO6TwNAA8QB8U From: "Christian Huitema" To: "Stuart Cheshire" Cc: X-OriginalArrivalTime: 29 Dec 2002 05:20:35.0744 (UTC) FILETIME=[04539A00:01C2AEFA] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id AAA13938 > There appears to be a small community of people who think that indefinite > stalling of this document will somehow contribute to faster adoption of > IPv6. The sad irony here is that the unending stalling of IPv4LL has just > served to keep it in the spotlight, whereas if it had been published a > year or two ago, it would be largely forgotten by now. Look, I don't want to create some kind of misunderstanding. My only concerns are technical, focused on the compatibility issue. You cannot cite availability on old Windows platform as a reason to standardize the autoconfigured IPv4 addresses and not be concerned at the same time with the compatibility issues. I am concerned with two of these compatibility issues. One, the TTL issue, is fairly trivial -- it suffice to say that the TTL "should" be set to 255 but that for the time being testing the incoming value is optional, as it breaks compatibility. I know that some other folks in our Microsoft team have expressed different opinions -- hey, the IETF is about individual participation. In any case, there seem to be at least a rough consensus in the WG for this formulation. The other issue is the nature of these addresses, and specifically whether they should be used "in addition to" other IPv4 addresses. I think they should not, as adding this "link local" concept to IPv4 is effectively a change in the IPv4 architecture, which is way outside the charter of the working group. I believe that there should be provision in the text, or in the application statement, that such autoconfigured addresses must never be used if the node could acquire an address by another mean, e.g. DHCP. As far as still making IPv4 products, that is a business decision. My personal position is that we should freeze IPv4, and effectively only innovate with IPv6 products. -- Christian Huitema From owner-zeroconf@merit.edu Sun Dec 29 00:43:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14066 for ; Sun, 29 Dec 2002 00:43:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8EF7B91254; Sun, 29 Dec 2002 00:45:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A98091279; Sun, 29 Dec 2002 00:45: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 C76B991254 for ; Sun, 29 Dec 2002 00:45:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD0565DE27; Sun, 29 Dec 2002 00:45:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtpout.mac.com (A17-250-248-86.apple.com [17.250.248.86]) by segue.merit.edu (Postfix) with ESMTP id 4301A5DDC1 for ; Sun, 29 Dec 2002 00:45:46 -0500 (EST) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id gBT5jj9J011493 for ; Sat, 28 Dec 2002 21:45:45 -0800 (PST) Received: from [192.168.0.119] ([12.232.144.158]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id H7V9C900.J4N; Sat, 28 Dec 2002 21:45:45 -0800 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Sat, 28 Dec 2002 21:45:41 -0800 Subject: Re: Should people still be making IPv4 products? From: Alf Watt To: ZeroConf WG Cc: Stuart Cheshire , Christian Huitema Message-ID: In-Reply-To: <200212280021.gBS0L2f08537@scv3.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 12/27/02 4:21 PM, "Stuart Cheshire" wrote: > I haven't seen anyone on this list argue that IPv6 is a bad idea. I think > most people would agree that IPv6 is a good idea, and when it is > ubiquitous we'll be happy. I think it worth asserting that as long as IPv6 is not widely deployed some issues in it's own LL and auto configuration implementations may remain masked by a lack of real-world test cases. Working out standards for LL and auto configuration in IPv4, which can be tested into real-world environments, will almost certainly help strengthen IPV6 by providing profiling and debugging data along with proven techniques and algorithms. > However, the fact is that IPv4 is useful for products today. Mac OS and > Windows have done IPv4LL for years. Other vendors want to make IPv4LL > products too, and they want a standard to follow. These vendors will also learn from their IPv4LL implementations and when they do get around to implementing IPv6 they will be more likely to get it right, having had some practice. I really believe that any conflict between IPv4 and IPv6 is purely political. Allowing IPv4 to continue evolving during IPv6's infancy allows both to become a more robust protocols and can only help speed the growth and adoption of the younger. Adding modern features to IPv4 also helps to spread the word about v6. When less-technical people come to you excited about zero configuration consider it an opportunity to promote IPv6 which has all that and more. Best, Alf From owner-zeroconf@merit.edu Sun Dec 29 00:58:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14184 for ; Sun, 29 Dec 2002 00:58:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 770B19127B; Sun, 29 Dec 2002 01:00:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 403DF9127C; Sun, 29 Dec 2002 01:00: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 384C89127B for ; Sun, 29 Dec 2002 01:00:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 875295DF7A; Sun, 29 Dec 2002 01:00:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 806B15DE3F for ; Sun, 29 Dec 2002 01:00:13 -0500 (EST) Received: from nominum.com (dialup-65.56.236.151.Dial1.Buffalo1.Level3.net [65.56.236.151]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id gBT5sqq25665; Sat, 28 Dec 2002 23:54:54 -0600 (CST) Date: Sun, 29 Dec 2002 01:00:06 -0500 Subject: Re: Should people still be making IPv4 products? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu 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 > The other issue is the nature of these addresses, and specifically > whether they should be used "in addition to" other IPv4 addresses. I > think they should not, as adding this "link local" concept to IPv4 is > effectively a change in the IPv4 architecture, which is way outside > the charter of the working group IPv4 already allows interfaces to have multiple IP addresses. IPv4 link-local addresses already work, and have worked for quite some time, and are deployed on the vast majority of all deployed devices that run TCP/IP. So you are asserting here that while these two statements, taken in isolation, do not constitute a change in the IPv4 architecture, when taken together they do. This is a surprising statement. I don't think zeroconf needs to worry about this - if the right thing to do is to put these two things together, the working group should do so, write it up, go to last call, get internal rough consensus, and pass the buck to the IESG. If the IESG believes that this is something that the working group should not have done, it can send it back. But it's not the working group's job to second-guess the IESG, and it _is_ the working group's job to define its charter, and to advance drafts. A *tremendous* amount of time gets wasted discussing meta-issues like this, and it's pointless. Figure out what to say, say it, and see if it flies. > I believe that there should be provision in the text, or in the > application statement, that such autoconfigured addresses must never > be used if the node could acquire an address by another mean, e.g. > DHCP. I do not believe you have presented any reason to support this belief, but you are certainly entitled to hold it even in the absence of any such reason. > As far as still making IPv4 products, that is a business decision. My > personal position is that we should freeze IPv4, and effectively only > innovate with IPv6 products. Just today I was sitting in my father's office trying to debug a problem with his computer, and decided I needed to ssh to my laptop, which was upstairs. My first thought was "oh, rats, I wonder what my IP address is..." My second thought was, "wait, I wonder if I can use link-local ad-hoc networking. Hm. 'ssh dra-chi.local.' Yay! It works!" This is how networking should work. It should Just Work. You are right: we should all just use IPv6. But I'm really glad that some folks decided to make sure that IPv4 worked nicely too, because that is in fact what all of us poor bastards here in the 'States are stuck with right now. From owner-zeroconf@merit.edu Sun Dec 29 01:02:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14249 for ; Sun, 29 Dec 2002 01:02:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B28629127C; Sun, 29 Dec 2002 01:05:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 803499127D; Sun, 29 Dec 2002 01:05: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 722049127C for ; Sun, 29 Dec 2002 01:05:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4B2E75DF85; Sun, 29 Dec 2002 01:05:04 -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 D64255DF7A for ; Sun, 29 Dec 2002 01:05:03 -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 BAA20503 for ; Sun, 29 Dec 2002 01:05:03 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id BAA16187 for ; Sun, 29 Dec 2002 01:05:03 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id BAA15615 for ; Sun, 29 Dec 2002 01:05:02 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Sun, 29 Dec 2002 01:05:00 -0500 Subject: Re: Should people still be making IPv4 products? 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 12/29/2002 00:20, "Christian Huitema" wrote: > As far as still making IPv4 products, that is a business decision. My personal > position is that we should freeze IPv4, and effectively only innovate with > IPv6 products. Are you really advocating saddling the common user with the current IPv4 situation for the next 5 to 7 years? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sun Dec 29 01:23:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14462 for ; Sun, 29 Dec 2002 01:23:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B5D489127D; Sun, 29 Dec 2002 01:26:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F73D9127E; Sun, 29 Dec 2002 01:26: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 6120A9127D for ; Sun, 29 Dec 2002 01:26:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 43EA25DF85; Sun, 29 Dec 2002 01:26:18 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by segue.merit.edu (Postfix) with ESMTP id 040CC5DE47 for ; Sun, 29 Dec 2002 01:26:18 -0500 (EST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 28 Dec 2002 22:26:17 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 28 Dec 2002 22:26:17 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Sat, 28 Dec 2002 22:26:17 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 28 Dec 2002 22:26:16 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Sat, 28 Dec 2002 22:26:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should people still be making IPv4 products? Date: Sat, 28 Dec 2002 22:26:14 -0800 Message-ID: Thread-Topic: Should people still be making IPv4 products? Thread-Index: AcKu/49E8aKAXaEoR6iX0IpB13P43gAAvlaU From: "Christian Huitema" To: "Ted Lemon" Cc: X-OriginalArrivalTime: 29 Dec 2002 06:26:15.0361 (UTC) FILETIME=[30857310:01C2AF03] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA14462 >> The other issue is the nature of these addresses, and specifically >> whether they should be used "in addition to" other IPv4 addresses. I >> think they should not, as adding this "link local" concept to IPv4 is >> effectively a change in the IPv4 architecture, which is way outside >> the charter of the working group > > IPv4 already allows interfaces to have multiple IP addresses. IPv4 > link-local addresses already work, and have worked for quite some time, > and are deployed on the vast majority of all deployed devices that run > TCP/IP. Actually, the Windows implementations will not use autoconfigured IPv4 addresses if they already have obtained a DHCP address. Saying that "IPv4 link local already work" is a bit of an overstatement; what works is autoconfigured addresses on a disconnected network. Anything else is speculative. For example, one may speculate on the consequences of using autoconfigured addresses in a large entreprise network. -- Christian Huitema From owner-zeroconf@merit.edu Sun Dec 29 01:54:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14851 for ; Sun, 29 Dec 2002 01:54:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8709B9127E; Sun, 29 Dec 2002 01:57:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 54A8F9127F; Sun, 29 Dec 2002 01:57: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 3A7569127E for ; Sun, 29 Dec 2002 01:57:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2032D5DE47; Sun, 29 Dec 2002 01:57:12 -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 D290A5DDB3 for ; Sun, 29 Dec 2002 01:57:11 -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.5600); Sat, 28 Dec 2002 22:57:11 -0800 Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 28 Dec 2002 22:57:11 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Sat, 28 Dec 2002 22:57:11 -0800 Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 28 Dec 2002 22:57:10 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Sat, 28 Dec 2002 22:57:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should people still be making IPv4 products? Date: Sat, 28 Dec 2002 22:57:08 -0800 Message-ID: Thread-Topic: Should people still be making IPv4 products? Thread-Index: AcKvAEN/8caaoShLRwmshNyQjUT5sAABCbbj From: "Christian Huitema" To: "John C. Welch" , "Zeroconf" X-OriginalArrivalTime: 29 Dec 2002 06:57:10.0895 (UTC) FILETIME=[828177F0:01C2AF07] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA14851 >> As far as still making IPv4 products, that is a business decision. My personal >> position is that we should freeze IPv4, and effectively only innovate with >> IPv6 products. > > Are you really advocating saddling the common user with the current IPv4 > situation for the next 5 to 7 years? Actually, I am busy making sure that the common user can use IPv6 in the next 5 to 7 months, or maybe sooner. But as far as this WG is concerned, this is irrelevant. My message expressed an opinion on how to go about defining IPv4 address autoconfiguration (maximise compatibility with existing networks) rather than a statement about whether to do it or not. -- Christian Huitema From owner-zeroconf@merit.edu Sun Dec 29 02:00:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15720 for ; Sun, 29 Dec 2002 02:00:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6969291280; Sun, 29 Dec 2002 02:03:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C8A891281; Sun, 29 Dec 2002 02:03: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 6262B91280 for ; Sun, 29 Dec 2002 02:03:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4FF725DEC5; Sun, 29 Dec 2002 02:03:32 -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 D8E575DEAF for ; Sun, 29 Dec 2002 02:03:31 -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 CAA24215 for ; Sun, 29 Dec 2002 02:03:31 -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 CAA16811 for ; Sun, 29 Dec 2002 02:03:31 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id CAA16923 for ; Sun, 29 Dec 2002 02:03:30 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Sun, 29 Dec 2002 02:03:28 -0500 Subject: Re: Should people still be making IPv4 products? 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 12/29/2002 01:26, "Christian Huitema" wrote: > Actually, the Windows implementations will not use autoconfigured IPv4 > addresses if they already have obtained a DHCP address. Saying that "IPv4 link > local already work" is a bit of an overstatement; what works is autoconfigured > addresses on a disconnected network. Anything else is speculative. For > example, one may speculate on the consequences of using autoconfigured > addresses in a large entreprise network. Um...well, experience suggests that as long as the interface has both an LL address and an address set up for the enterprise network, and the device can handle multiple IPs per interface correctly, then the consequences should be minor. If there are no other nodes with LL addresses on the local link, then the LL configured address will just kind of sit there. The use of enterprise addresses should never notice this other config unless that Enterprise is using the LL subnet for its own addresses. In that case, the LL address surrender mechanism should function and the LL interface will just find a different address. Unless you have the full /16 number of devices on that physical link, (and if you have 60,000+ devices on a flat subnet, you have other issues anyway) then at most, DHCP will take an extra few milliseconds to assign you an address. If you look at it, we already *have* autoconfiguration of addresses in DHCP, which has almost no effective security. But it works. All LL is doing is removing the server, and specifying the subnet for the address range. I have yet to see concrete evidence that this is going to cause an existing network to suddenly collapse in a storm of address errors. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sun Dec 29 02:03:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18925 for ; Sun, 29 Dec 2002 02:03:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 11CF591281; Sun, 29 Dec 2002 02:05:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D170391282; Sun, 29 Dec 2002 02:05: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 C794591281 for ; Sun, 29 Dec 2002 02:05:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id A4E0D5DEAF; Sun, 29 Dec 2002 02:05:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 3ABDF5DE3F for ; Sun, 29 Dec 2002 02:05:50 -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 CAA27078 for ; Sun, 29 Dec 2002 02:05:49 -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 CAA10638 for ; Sun, 29 Dec 2002 02:05:49 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id CAA17004 for ; Sun, 29 Dec 2002 02:05:48 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Sun, 29 Dec 2002 02:05:47 -0500 Subject: Re: Should people still be making IPv4 products? 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 12/29/2002 01:57, "Christian Huitema" wrote: >> Are you really advocating saddling the common user with the current IPv4 >> situation for the next 5 to 7 years? > > Actually, I am busy making sure that the common user can use IPv6 in the next > 5 to 7 months, or maybe sooner. But as far as this WG is concerned, this is > irrelevant. My message expressed an opinion on how to go about defining IPv4 > address autoconfiguration (maximise compatibility with existing networks) > rather than a statement about whether to do it or not. Well, saying that all IPv4 development should be frozen would tend to look as though you advocate halting all IPv4 work that is at any stage other than maintenance mode. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sun Dec 29 02:08:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24786 for ; Sun, 29 Dec 2002 02:08:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1851991282; Sun, 29 Dec 2002 02:11:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE01991283; Sun, 29 Dec 2002 02:11: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 CC04091282 for ; Sun, 29 Dec 2002 02:11:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id AE8245DFC0; Sun, 29 Dec 2002 02:11:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from broadviewnet.net (unix10.broadviewnet.net [64.115.0.105]) by segue.merit.edu (Postfix) with SMTP id 3F4FA5DF89 for ; Sun, 29 Dec 2002 02:11:16 -0500 (EST) Received: (qmail 29004 invoked from network); 29 Dec 2002 07:11:15 -0000 Received: from unknown (HELO kabilla) (66.219.68.108) by smtp.broadviewnet.net with SMTP; 29 Dec 2002 07:11:15 -0000 Message-ID: <008e01c2af09$7a032c70$6401a8c0@kabilla> From: "Bill Rees" To: "Keith Moore" , Cc: References: <200212290424.gBT4Omj08821@astro.cs.utk.edu> Subject: Re: what John Welch wants Date: Sat, 28 Dec 2002 23:11:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Keith Moore" > > If we don't make IP as easy, or easier to use as > > Appletalk, then the group is a failure. > > This is not in this group's charter. If this group is trying to do that, > it's violating its charter and it needs a mercy killing. > > zeroconf is chartered "to enable [IP] networking in the *absence* of > configuration and administration", as in isolated networks. It is > NOT chartered to change how IP works on configured/managed networks. > > Keith > Seems to me that Apple is already heading in that direction (as easy as AppleTalk) with or without this group. If what this group wants to achieve is different than what Apple is already doing, then please tell Apple to quit identifying Rendezvous with zeroconf to avoid misleading the public on the concept of zero configuration (zeroconf? coincidence?) Apple is striving for.Else the expectation for easy as AppleTalk configuration will spill over onto this group whereupon the shit will not only hit the fan but probably launch the fucker into orbit. From owner-zeroconf@merit.edu Sun Dec 29 02:24:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24892 for ; Sun, 29 Dec 2002 02:24:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5035991283; Sun, 29 Dec 2002 02:27:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0271591284; Sun, 29 Dec 2002 02:27: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 14A0091283 for ; Sun, 29 Dec 2002 02:27:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id E959B5DEC5; Sun, 29 Dec 2002 02:26:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from scooter.webservepro.com (scooter.webservepro.com [198.94.136.20]) by segue.merit.edu (Postfix) with ESMTP id BD26E5DDA0 for ; Sun, 29 Dec 2002 02:26:59 -0500 (EST) Received: from scooter.webservepro.com (scooter.webservepro.com [198.94.136.20]) by scooter.webservepro.com (8.12.0.Beta5/8.12.0.Beta5) with ESMTP id gBT7QgRU020117; Sun, 29 Dec 2002 02:26:42 -0500 Date: Sun, 29 Dec 2002 02:26:42 -0500 (EST) From: "Warden, Matt" X-Sender: mwarden@scooter.webservepro.com To: Bill Rees Cc: Keith Moore , zeroconf@merit.edu Subject: Re: what the industry wants (was what John Welch wants) In-Reply-To: <008e01c2af09$7a032c70$6401a8c0@kabilla> Message-ID: X-Monkey: True MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Dec 28, Bill Rees had something to say about Re: what John Welch wants >AppleTalk) with or without this group. If what this group wants to achieve >is different than what Apple is already doing, then please tell Apple to >quit identifying Rendezvous with zeroconf to avoid misleading the public on >the concept of zero configuration (zeroconf? coincidence?) Apple is >striving for. Is that what 'zeroconf' stands for? I've only recently joined this list and the conversations I've seen so far led me to believe it stood for 'zero confidence' Are the personal attacks and endless bickering necessary? I, as a user, enjoy the networking *advancements* in Mac OS X and would like to see things progress in that manner. In fact, that's how I found you. I wanted to know where these advancements came from. But, if after all this time you people are still bickering over fundamental PURPOSES for this group, the way to see things progress is NOT with your group. And if this continues, people are going to subscribe to that belief and look to Apple or other organizations/companies to do their own "standardizing". Progress is being demanded by the industry. And if this group decides to bicker instead, it'll be left behind. Please don't view this as an attack just because it is not positive. Thanks, -- mattwarden mattwarden.com From owner-zeroconf@merit.edu Sun Dec 29 04:26:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26078 for ; Sun, 29 Dec 2002 04:26:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 20AAF91252; Sun, 29 Dec 2002 04:29:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D63F391284; Sun, 29 Dec 2002 04:29: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 C221F91252 for ; Sun, 29 Dec 2002 04:29:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id AAEAC5DF50; Sun, 29 Dec 2002 04:29:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta04ps.bigpond.com (mta04ps.bigpond.com [144.135.25.136]) by segue.merit.edu (Postfix) with ESMTP id 763AD5DDB3 for ; Sun, 29 Dec 2002 04:29:00 -0500 (EST) Received: from pc-00206 ([144.135.25.78]) by mta04ps.bigpond.com (Netscape Messaging Server 4.15 mta04ps Jul 16 2002 22:47:55) with SMTP id H7VJO800.9PT; Sun, 29 Dec 2002 19:28:56 +1000 Received: from CPE-203-51-31-46.nsw.bigpond.net.au ([203.51.31.46]) by PSMAM04.mailsvc.email.bigpond.com(MailRouter V3.0n 98/6958305); 29 Dec 2002 19:28:56 From: Brad Hards To: "Warden, Matt" Subject: Re: what the industry wants (was what John Welch wants) Date: Sun, 29 Dec 2002 20:16:05 +1100 User-Agent: KMail/1.4.5 Cc: zeroconf@merit.edu References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200212292016.05402.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 29 Dec 2002 18:26, Warden, Matt wrote: > Is that what 'zeroconf' stands for? I've only recently joined this list > and the conversations I've seen so far led me to believe it stood for > 'zero confidence' Welcome to an example of failure of peer review. > Are the personal attacks and endless bickering necessary? I, as a user, > enjoy the networking *advancements* in Mac OS X and would like to see > things progress in that manner. In fact, that's how I found you. I wanted > to know where these advancements came from. If you are interested in implementing this stuff (rather than arguing about why it might not work), feel free to drop over to zeroconf-workers@lists.sourceforge.net. Its a pretty low volume list, because we tend to focus on coding and testing. Also see: http://zeroconf.sourceforge.net for the limited progress to date. Brad - -- http://linux.conf.au. 22-25Jan2003. Perth, Aust. I'm registered. Are you? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+Dr1VW6pHgIdAuOMRAuHXAJ9fGOUf1wSHtU/rco6UVfL+s4vOrACdEe4t 6U/75gb4Ddow+Ci1FZJpkpY= =D8x/ -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Sun Dec 29 08:18:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27871 for ; Sun, 29 Dec 2002 08:18:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ABEB991240; Sun, 29 Dec 2002 08:21:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7999B91288; Sun, 29 Dec 2002 08:21: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 6B82591240 for ; Sun, 29 Dec 2002 08:21:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4B7CB5DFA5; Sun, 29 Dec 2002 08:21:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id DDA695DE8A for ; Sun, 29 Dec 2002 08:21:40 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBTDKaj13883; Sun, 29 Dec 2002 08:20:53 -0500 (EST) Message-Id: <200212291320.gBTDKaj13883@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Warden, Matt" Cc: Bill Rees , Keith Moore , zeroconf@merit.edu Subject: Re: what the industry wants (was what John Welch wants) In-reply-to: (Your message of "Sun, 29 Dec 2002 02:26:42 EST.") Date: Sun, 29 Dec 2002 08:20:36 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Progress is being demanded by the industry. changes to IP that break applications are not progress. From owner-zeroconf@merit.edu Sun Dec 29 08:58:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28215 for ; Sun, 29 Dec 2002 08:58:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 77FDE9128A; Sun, 29 Dec 2002 09:00:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D13B9128B; Sun, 29 Dec 2002 09:00: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 069DA9128A for ; Sun, 29 Dec 2002 09:00:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F3295DE8F; Sun, 29 Dec 2002 09:00:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id E32115DDA0 for ; Sun, 29 Dec 2002 09:00:24 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBTDxQj14531; Sun, 29 Dec 2002 08:59:36 -0500 (EST) Message-Id: <200212291359.gBTDxQj14531@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Alf Watt Cc: ZeroConf WG , Stuart Cheshire , Christian Huitema Subject: Re: Should people still be making IPv4 products? In-reply-to: (Your message of "Sat, 28 Dec 2002 21:45:41 PST.") Date: Sun, 29 Dec 2002 08:59:26 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Adding modern features to IPv4 also helps to spread the word about v6. it's a bit disingeneous to call features that break IPv4 'modern'. From owner-zeroconf@merit.edu Sun Dec 29 08:58:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28229 for ; Sun, 29 Dec 2002 08:58:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2CA1F91289; Sun, 29 Dec 2002 09:01:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C98209128B; Sun, 29 Dec 2002 09:01: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 CFC3391289 for ; Sun, 29 Dec 2002 09:01:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3881F5DFEE; Sun, 29 Dec 2002 09:01:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id CE6775DF9D for ; Sun, 29 Dec 2002 09:01:11 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBTE0Nj14558; Sun, 29 Dec 2002 09:00:39 -0500 (EST) Message-Id: <200212291400.gBTE0Nj14558@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Ted Lemon Cc: "Christian Huitema" , zeroconf@merit.edu Subject: Re: Should people still be making IPv4 products? In-reply-to: (Your message of "Sun, 29 Dec 2002 01:00:06 EST.") Date: Sun, 29 Dec 2002 09:00:23 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > But it's not the working group's job to second-guess the IESG, > and it _is_ the working group's job to define its charter no it's not. working groups do not define their charters; they suggest charters to IESG. IESG defines the charter. From owner-zeroconf@merit.edu Sun Dec 29 09:00:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28266 for ; Sun, 29 Dec 2002 09:00:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 44ABC9128D; Sun, 29 Dec 2002 09:03:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DDC69128C; Sun, 29 Dec 2002 09:02: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 D47469128B for ; Sun, 29 Dec 2002 09:02:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id B6C9B5DE8F; Sun, 29 Dec 2002 09:02:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 598B55DDA0 for ; Sun, 29 Dec 2002 09:02:45 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBTE28j14590; Sun, 29 Dec 2002 09:02:13 -0500 (EST) Message-Id: <200212291402.gBTE28j14590@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bill Rees" Cc: "Keith Moore" , zeroconf@merit.edu Subject: Re: what John Welch wants In-reply-to: (Your message of "Sat, 28 Dec 2002 23:11:14 PST.") <008e01c2af09$7a032c70$6401a8c0@kabilla> Date: Sun, 29 Dec 2002 09:02:08 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Seems to me that Apple is already heading in that direction (as easy as > AppleTalk) with or without this group. Apple isn't making IP as easy as appletalk; it's defining a different and way to use IP on a LAN which is somewhat incompatible with traditional IP. The effect is to make IP more confusing for users and more difficult for applications and support people. From owner-zeroconf@merit.edu Sun Dec 29 12:21:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00177 for ; Sun, 29 Dec 2002 12:21:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7D5DB91236; Sun, 29 Dec 2002 12:24:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 513E991285; Sun, 29 Dec 2002 12:24: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 3CF4B91236 for ; Sun, 29 Dec 2002 12:24:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1B0565DDA3; Sun, 29 Dec 2002 12:24:21 -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 A55015DDA0 for ; Sun, 29 Dec 2002 12:24:20 -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 MAA05024 for ; Sun, 29 Dec 2002 12:24:20 -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 MAA17819 for ; Sun, 29 Dec 2002 12:24:20 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA15707 for ; Sun, 29 Dec 2002 12:24:19 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Sun, 29 Dec 2002 12:24:17 -0500 Subject: Re: what John Welch wants From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200212291402.gBTE28j14590@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 12/29/2002 09:02, "Keith Moore" wrote: >> Seems to me that Apple is already heading in that direction (as easy as >> AppleTalk) with or without this group. > > Apple isn't making IP as easy as appletalk; it's defining a different > and way to use IP on a LAN which is somewhat incompatible with traditional > IP. The effect is to make IP more confusing for users and more difficult > for applications and support people. You have yet to show us a single example of this except in a mysterious "off-list" email, which, since it is therefore not up for public criticism, is rather like the infamous papers Joe McCarthy used to wave while shouting, "I have here a list of names..." I must however, congratulate you on a fine bit of misdirection. By making me the focal point of things, you have rather effectively, once again, killed the ability of this group to get any real work done, and avoided having to show any verifiable proof of these massive problems you say will, not may, but will happen. But then, killing any IPv4 advancement seems to be a root cause for you. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sun Dec 29 16:31:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02795 for ; Sun, 29 Dec 2002 16:31:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3A5C491238; Sun, 29 Dec 2002 16:34:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0001E9123A; Sun, 29 Dec 2002 16: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 E3EEA91238 for ; Sun, 29 Dec 2002 16:34:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id CB0675DDE9; Sun, 29 Dec 2002 16:34:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from broadviewnet.net (unix13.broadviewnet.net [64.115.0.53]) by segue.merit.edu (Postfix) with SMTP id 4FBF75DDD5 for ; Sun, 29 Dec 2002 16:34:01 -0500 (EST) Received: (qmail 9970 invoked from network); 29 Dec 2002 21:34:00 -0000 Received: from unknown (HELO kabilla) (66.219.68.108) by smtp.broadviewnet.net with SMTP; 29 Dec 2002 21:34:00 -0000 Message-ID: <001501c2af82$0060ac20$6401a8c0@kabilla> From: "Bill Rees" To: "Keith Moore" Cc: "Keith Moore" , References: <200212291402.gBTE28j14590@astro.cs.utk.edu> Subject: Re: what John Welch wants Date: Sun, 29 Dec 2002 13:33:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- > > Seems to me that Apple is already heading in that direction (as easy as > > AppleTalk) with or without this group. > > Apple isn't making IP as easy as appletalk; it's defining a different > and way to use IP on a LAN which is somewhat incompatible with traditional > IP. The effect is to make IP more confusing for users and more difficult > for applications and support people. > Well then I suggest this group disband since there is no agreement on what zeroconf means. For Apple it seems to mean automatic configuration for devices plugged into the local network so that the user is not directly involved in setup. For this group, zeroconf seems to mean a variety of different things bearing little in common with Apple's goals. This is a strong indication of a very poor charter which is the fundamental issue under "discussion" here. From owner-zeroconf@merit.edu Tue Dec 31 00:08:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08078 for ; Tue, 31 Dec 2002 00:08:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 59564912CC; Tue, 31 Dec 2002 00:11:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2290E912CE; Tue, 31 Dec 2002 00:11: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 06A65912CC for ; Tue, 31 Dec 2002 00:11:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id DC9ED5E070; Tue, 31 Dec 2002 00:11:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from arrakis.cso.uiuc.edu (arrakis.cso.uiuc.edu [130.126.113.7]) by segue.merit.edu (Postfix) with ESMTP id 84EFB5DEA0 for ; Tue, 31 Dec 2002 00:11:28 -0500 (EST) Received: from arrakis.cso.uiuc.edu (localhost [127.0.0.1]) by arrakis.cso.uiuc.edu (8.12.4/8.12.4) with ESMTP id gBV5BIXN002611; Mon, 30 Dec 2002 23:11:18 -0600 (CST) Received: (from jak@localhost) by arrakis.cso.uiuc.edu (8.12.4/8.12.4/Submit) id gBV5BHoE002610; Mon, 30 Dec 2002 23:11:17 -0600 (CST) Date: Mon, 30 Dec 2002 23:11:17 -0600 From: "Jay A. Kreibich" To: Keith Moore Cc: "Warden, Matt" , Bill Rees , zeroconf@merit.edu Subject: Re: what the industry wants (was what John Welch wants) Message-ID: <20021231051117.GC2546@uiuc.edu> Reply-To: jak@uiuc.edu References: <200212291320.gBTDKaj13883@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200212291320.gBTDKaj13883@astro.cs.utk.edu> User-Agent: Mutt/1.4i X-Editor: vi, and proud of it X-URL: http://www.uiuc.edu/~jak (includes PGP key) Sender: owner-zeroconf@merit.edu Precedence: bulk On Sun, Dec 29, 2002 at 08:20:36AM -0500, Keith Moore scratched on the wall: > > Progress is being demanded by the industry. > > changes to IP that break applications are not progress. Yeah, CIDR was a real step backwards in its time. Caused lots of things to break. -j -- Jay A. Kreibich | Integration & Software Eng. jak@uiuc.edu | Campus IT & Edu. Svcs. | University of Illinois at U/C From owner-zeroconf@merit.edu Tue Dec 31 00:16:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08119 for ; Tue, 31 Dec 2002 00:16:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E8A00912CE; Tue, 31 Dec 2002 00:19:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7A48912CF; Tue, 31 Dec 2002 00:19: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 8C2DC912CE for ; Tue, 31 Dec 2002 00:19:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 65DD55DEBF; Tue, 31 Dec 2002 00:19:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 09AC15DDAC for ; Tue, 31 Dec 2002 00:19:26 -0500 (EST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id gBV5J8j04048; Tue, 31 Dec 2002 00:19:08 -0500 (EST) Message-Id: <200212310519.gBV5J8j04048@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: jak@uiuc.edu Cc: Keith Moore , zeroconf@merit.edu Subject: Re: what the industry wants (was what John Welch wants) In-reply-to: (Your message of "Mon, 30 Dec 2002 23:11:17 CST.") <20021231051117.GC2546@uiuc.edu> Date: Tue, 31 Dec 2002 00:19:08 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Yeah, CIDR was a real step backwards in its time. Maybe my memory is fading, I don't recall too much breakage as a result of CIDR. Most applications didn't try to be aware of network topology, so CIDR mostly affected hosts and routers and diagnostic tools. And of course the net was much smaller and less diverse then and much better able to handle a certain amout of disruption. The ironic thing about your citing CIDR as a defense for LL is that LL forces apps to try to be aware of topology and address structure whereas CIDR took advantage of the fact that most apps didn't try to be aware of such things. Keith