From owner-zeroconf@merit.edu Thu Jan 2 20:04:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18682 for ; Thu, 2 Jan 2003 20:04:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7C8E49121D; Thu, 2 Jan 2003 20:07:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A63291224; Thu, 2 Jan 2003 20:07: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 568759121D for ; Thu, 2 Jan 2003 20:07:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3031D5DE06; Thu, 2 Jan 2003 20:07:44 -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 AD0745DDF0 for ; Thu, 2 Jan 2003 20:07:43 -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 h0317hw18061 for ; Thu, 2 Jan 2003 17:07:43 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 2 Jan 2003 17:07:15 -0800 Received: from [206.111.147.152] (vpn-gh-575.apple.com [17.254.138.62]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id h0317gs21893 for ; Thu, 2 Jan 2003 17:07:42 -0800 (PST) Message-Id: <200301030107.h0317gs21893@scv1.apple.com> Subject: Re: Updated Rendezvous drafts are available Date: Thu, 2 Jan 2003 17:07:46 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >I take it these are being published via the Internet-Drafts mechanism? Yes, of course, as announced (as is the custom for Internet Drafts) on the all-ietf@ietf.org mailing list on 23rd December. Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Sat Jan 4 12:46:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13975 for ; Sat, 4 Jan 2003 12:46:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0C6AB91256; Sat, 4 Jan 2003 12:49:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D03E191258; Sat, 4 Jan 2003 12:49: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 D269891256 for ; Sat, 4 Jan 2003 12:49:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id C07565DE63; Sat, 4 Jan 2003 12:49:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 5970C5DDE4 for ; Sat, 4 Jan 2003 12:49:40 -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 KAA22447; Sat, 4 Jan 2003 10:49:38 -0700 (MST) Received: from localhost (vpn-129-149-240-56.SFBay.Sun.COM [129.149.240.56]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h04HnYP19771; Sat, 4 Jan 2003 18:49:34 +0100 (MET) Date: Sat, 4 Jan 2003 09:04:28 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Application software needs to be "zeroconf-aware"? To: "John C. Welch" Cc: Zeroconf 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 > 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. John, Your comparison with client and servers in different subnets without a router makes me think the problem case hasn't been well explained. Let me try to explain an IP address configuration example where Keith's issue might appear and that is unique to different address scopes i.e. not related to a general inability to communicate. Imagine three boxes on a local link: A, B, and C. C is a link-local only box. It has the link-local address C(LL). A and B are full function boxes (support both DHCP and V4LL). They acquire their link-local addresses (e.g. because the dhcp server is not up when they boot, or because they need to them in order to communicate with C). Thus A has A(LL) and A(G) assigned to the same interface. Similarely for B. The issue appears when a node outside the link (call it D) communicates with A and B and there is a referral going on. If A wants to refer D to B, it must pass B(G) to D since D can not reach B(LL). How can this be ensured unless the application is link-local aware? When looking for specific applications that might fail in such a case I think one needs to understand how the application instances discover eachother. If this discovery process uses agents outside of the link then the process would presumably only discover the global addresses of its peers, even if those peers are on the same link and have a link-local address. But are there applications that use other discovery mechanisms and referals that would run into trouble in the above example configuration? Thus the issue isn't about link-local addresses. The issue is how boxes (and the applications running on those boxes) handle the case when the box is configured with addresses of multiple scopes. Erik From owner-zeroconf@merit.edu Mon Jan 6 14:53:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12688 for ; Mon, 6 Jan 2003 14:53:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8D1D891272; Mon, 6 Jan 2003 14:56:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 508C991274; Mon, 6 Jan 2003 14:56: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 4EBEE91272 for ; Mon, 6 Jan 2003 14:56:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 369565DDC4; Mon, 6 Jan 2003 14:56:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by segue.merit.edu (Postfix) with ESMTP id EBB675DDB8 for ; Mon, 6 Jan 2003 14:56:28 -0500 (EST) Received: from BOWLIELAPTOP (12-224-188-239.client.attbi.com[12.224.188.239]) by rwcrmhc53.attbi.com (rwcrmhc53) with SMTP id <2003010619562805300k7e8je>; Mon, 6 Jan 2003 19:56:28 +0000 Reply-To: From: "Nigel Ballard" To: Subject: X86 compiled client out there? Date: Mon, 6 Jan 2003 11:56:33 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Do we have a ready rolled PC client out there today that can work with Mac's Rendezvous? A link would be appreciated if so. Cheers Nigel Nigel Ballard Joejava Wireless Consultancy nigel@joejava.com www.joejava.com From owner-zeroconf@merit.edu Tue Jan 7 12:47:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22108 for ; Tue, 7 Jan 2003 12:47:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 72C2C91284; Tue, 7 Jan 2003 12:48:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A24391282; Tue, 7 Jan 2003 12:48:06 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1F94F91284 for ; Tue, 7 Jan 2003 12:46:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0351E5DF2E; Tue, 7 Jan 2003 12:46:15 -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 21CCD5DE67 for ; Tue, 7 Jan 2003 12:46:13 -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 h07AkBq08377; Tue, 7 Jan 2003 03:46:12 -0700 Date: Tue, 7 Jan 2003 10:46:10 -0700 Subject: Re: X86 compiled client out there? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: From: Alex Karahalios 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 Hi Nigel, Here is a link that I used some time back that Stuart Cheshire gave me: http://www.zeroconf.org/Rendezvous/Win.zip Alex Karahalios On Monday, January 6, 2003, at 12:56 PM, Nigel Ballard wrote: > Do we have a ready rolled PC client out there today that can work with > Mac's > Rendezvous? > > A link would be appreciated if so. > > Cheers Nigel > > Nigel Ballard > Joejava Wireless Consultancy > nigel@joejava.com > www.joejava.com > From owner-zeroconf@merit.edu Tue Jan 7 16:08:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28826 for ; Tue, 7 Jan 2003 16:08:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6FDB09128C; Tue, 7 Jan 2003 16:11:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3750B9128D; Tue, 7 Jan 2003 16:11: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 DC9249128C for ; Tue, 7 Jan 2003 16:11:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id CA5D85DF1F; Tue, 7 Jan 2003 16:11:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by segue.merit.edu (Postfix) with ESMTP id F306C5DEF6 for ; Tue, 7 Jan 2003 16:11:38 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h07LBYSK012748; Tue, 7 Jan 2003 16:11:34 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h07LBXFK102936; Tue, 7 Jan 2003 14:11:33 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h07L7HP26547; Tue, 7 Jan 2003 16:07:17 -0500 Message-Id: <200301072107.h07L7HP26547@rotala.raleigh.ibm.com> To: Stuart Cheshire Cc: "Erik Nordmark" , zeroconf@merit.edu Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-Reply-To: Message from Stuart Cheshire of "Fri, 13 Dec 2002 18:45:26 PST." <200212140245.gBE2jZf08650@scv3.apple.com> Date: Tue, 07 Jan 2003 16:07:17 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk I hope we aren't losing momentum on completing this draft. Do we have agreement on what words need to get tweaked in the document? > 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. Noted. But this is still a limited experience and is not proof that no problems can or will arise. For example, Apple clients may be deployed primarily in certain environments and not appear at all in other environments. So it is not immediately clear that your experience translates to "no problems can or will ever arise from these techniques". I'm not saying this to say this is a bad idea and shouldn't be done, but just to remind us all that the internet is a very big place and there are lots of localized environments that we may not have all that much direct experience in. So we need to be careful about generalizing experiences. > >How about adding > > This document updates RFC 826 and RFC 2132. > I added a header line that says "Updates: 826, 2132" It would be better to add the text in the intro/abstract. The header lines get lost sometimes in the translation to an RFC. Been there, done that. Also, how does this spec update 2132? (or do you mean 2131)? Note, if this document is to update 2131, it needs to: 1) very clearly say what aspect of 2131 it is updating. Right now, it's not clear what part is being updated. 2) need to be approved by DHC WG. I actually don't know that this document should be updating the DHC spec. It's for the DHC folk to update their specs and point to this one, even if DHC was the motivation (at one level) for the document. > >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. How about (at the end of the intro): The protocol described in this document addresses a subset of the address conflict detection of [v4LL], but is applicable for use with other unicast addresses, not just IPv4 link-local addresses. > >> 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. I hadn't really noticed this here, but the document is specifying behavior related to multiple interfaces, not just one. Traditionally, ARP is run on a single interface. It's scope is limited to that interface. I'm not sure its necessary or desirable to shift away from that model. Or what the actual benefits are. > 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. Is there really a need to talk about behavior or impacts related to multiple interfaces? I.e, normally, one runs ARP on a single interface. When doing checks about the addresses, one only checks addresses on the interface on which the ARP packet was actually received. I.e., if you have an ethernet and a wireless, one runs the checks indepdently on both. Does the current wording stem from assumptions about how ARP is implement on a particular stack? E.g., one ARP process/module for all interfaces, as opposed to conceptually different instances on both interfaces? In talking with Erik on the phone earlier today, one concern he had was that having ARP traffic on one interface actually impact what goes on on other interfaces is a DOS attack that allows an intruder to impact addresses on links other than just those to which it connects. One can argue how much of an increased threat this is, but it is an increased threat. Also, I'm not convinced its necessary for correctness. > >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. My read of the quoted comment is that 2 or 3 seconds, rather than 8 as the document currently says might be a better default. Or am I misreading? > >> 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. Again, change the defaults to make the default shorter? Or at the very least, more discussion about this (possibly in an appendix)? > >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. Maybe point out that if an implementation over ethernet can distinguish between RSTP and STP BPDU, it should choose timers intelligently in this case rather than use defaults that would be suboptimal? The point here is to try and help implementors make good implementation decision by giving them useful guidance. Maybe this would be better in an appendix. > >> 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. A user might want to disable the part about ongoing conflict detection where the node gives up an address, or that it sends out broadcast ARP responses. There is a tradeoff here in terms of increased bandwidth vs. faster detection. Not everyone will necessarily weigh the relative benefits the way you are. You seem to be saying the spec should not allow or provide for this. There is a difference between detecting at address config time vs. doing it after the address has already been used. > DHCP clients have done address conflict detection for years, and no one > has asked for an option to disable address conflict detection there. As has been pointed out on the DHC list, the DHC-specified behavior is to send out ARP replies, not ARP requests. While I value your and Apple's experience here, your experience doesn't necessarily generalize to the conclusion "not useful and not needed", which is the way your response could be read. > 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. Because in *some* environments, the broadcast traffic is more of a problem than duplicate addresses? The *conservative* thing to do is to not send out the broadcasts, as we know that broadcast traffic has caused problems in the past. What might be good is to have more explanation about the tradeoffs here so implementors can make an informed opinion. The current text just says "here are three choices." "pick one". Some other suggestions: In the introduction: > The authors of the DHCP specification may have thought the answers to > these questions too obvious to mention, but unfortunately this leaves > some of the burden of protocol design to each individual implementer. > This document seeks to remedy this omission by clearly specifying the > required actions for: > > 1. Determining whether use of an address is likely to lead to an > addressing conflict. This includes (a) the case where the address > is already actively in use by another host on the same link, and > (b) the case where two hosts are inadvertently about to begin > using the same address, and both are simultaneously in the process > of probing to determine whether the address may safely be > used. It would be good here to add a couple of sentences saying what the actual behavior is, per this spec. > > 2. Subsequent passive detection that another host on the network is > inadvertently using the same address. Even if all hosts observe > precautions to avoid using an address that is already in use, > conflicts can still occur if two hosts are out of communication at > the time of initial interface configuration. This could occur with > wireless network interfaces if the hosts are temporarily out of > range, or with Ethernet interfaces if the link between two > Ethernet hubs is not functioning at the time of address > configuration. A well-designed host will handle not only conflicts > detected during interface configuration, but also conflicts > detected later, for the entire duration of the time that the host > is using the address. Again, It would be good here to add a couple of sentences saying what the actual behavior is, per this spec. > > 3. Rate-limiting of address acquisition attempts in the case of an > excessive number of repeated conflicts. Thomas From owner-zeroconf@merit.edu Tue Jan 7 18:24:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03136 for ; Tue, 7 Jan 2003 18:24:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8FE3E91294; Tue, 7 Jan 2003 18:27:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5752D91298; Tue, 7 Jan 2003 18:27: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 D809D91294 for ; Tue, 7 Jan 2003 18:27:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id C26255DF32; Tue, 7 Jan 2003 18:27:16 -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 6CF065DF0D for ; Tue, 7 Jan 2003 18:27:16 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h07LxVq09969; Tue, 7 Jan 2003 15:59:31 -0600 (CST) Date: Tue, 7 Jan 2003 16:15:06 -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 v551) Cc: zeroconf@merit.edu, "Erik Nordmark" , Stuart Cheshire To: Thomas Narten From: Ted Lemon In-Reply-To: <200301072107.h07L7HP26547@rotala.raleigh.ibm.com> Message-Id: <7A5D963A-228D-11D7-8FB4-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > As has been pointed out on the DHC list, the DHC-specified behavior is > to send out ARP replies, not ARP requests. Although the RFC does say to send an ARP request, it appears that there are no implementations that actually do this - every implementation that does anything at all along these lines sends an ARP reply, including the latest Windows (dunno about earlier versions, but no reason to suspect they are different). So while in fact the draft is contradicting the RFC, it is not contradicting what is deployed. Which means that in fact in most network environments the behavior the draft is describing is in fact already ubiquitous - it's not just Apple clients that are doing this. From owner-zeroconf@merit.edu Wed Jan 8 09:17:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20585 for ; Wed, 8 Jan 2003 09:17:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0918B91227; Wed, 8 Jan 2003 09:18:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4F3F91228; Wed, 8 Jan 2003 09:18: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 BEDC191227 for ; Wed, 8 Jan 2003 09:18:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9CB9D5DF9C; Wed, 8 Jan 2003 09:18:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by segue.merit.edu (Postfix) with ESMTP id 0AE805DF9A for ; Wed, 8 Jan 2003 09:18:57 -0500 (EST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h08EGhl06768; Wed, 8 Jan 2003 09:16:43 -0500 Message-Id: <200301081416.h08EGhl06768@cichlid.adsl.duke.edu> To: Ted Lemon Cc: zeroconf@merit.edu, "Erik Nordmark" , Stuart Cheshire Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-Reply-To: Message from Ted Lemon of "Tue, 07 Jan 2003 16:15:06 CST." <7A5D963A-228D-11D7-8FB4-00039367340A@nominum.com> Date: Wed, 08 Jan 2003 09:16:43 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Hi Ted. > > As has been pointed out on the DHC list, the DHC-specified behavior is > > to send out ARP replies, not ARP requests. > Although the RFC does say to send an ARP request, it appears that there > are no implementations that actually do this - every implementation > that does anything at all along these lines sends an ARP reply, > including the latest Windows (dunno about earlier versions, but no > reason to suspect they are different). So while in fact the draft is > contradicting the RFC, it is not contradicting what is deployed. It would be good to bring this up on the DHC list, as Bernie's post asserting that the wording in 2131 (which says send out an ARP Reply) was correct was not followed up saying anything like the above. It would be good to get clarification on what the right thing to do, and if the wording in the DHC spec needs changing, getting that added to the list of known updates the spec needs. > Which means that in fact in most network environments the behavior the > draft is describing is in fact already ubiquitous - it's not just Apple > clients that are doing this. I agree that the sending of ARP requests to "announce" the use of an address has been widely used. But the specific point I was responding to was not about that, it was about the use of ongoing conflict detection. AFAIK, only Apple is doing this today. Is anyone else doing this? Thomas From owner-zeroconf@merit.edu Wed Jan 8 09:47:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21334 for ; Wed, 8 Jan 2003 09:47:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B36DE9122D; Wed, 8 Jan 2003 09:48:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 376329122E; Wed, 8 Jan 2003 09:48: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 DAE099122D for ; Wed, 8 Jan 2003 09:48:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id C4E505DFA6; Wed, 8 Jan 2003 09:48:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from marsha.smtp.stsn.com (p249.n-sfpop03.stsn.com [199.107.154.249]) by segue.merit.edu (Postfix) with ESMTP id 8B2DD5DF9B for ; Wed, 8 Jan 2003 09:48:38 -0500 (EST) Received: from [10.0.1.19] ([10.1.185.87]) by marsha.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Jan 2003 06:51:06 -0800 User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 08 Jan 2003 06:48:36 -0800 Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200301072107.h07L7HP26547@rotala.raleigh.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Jan 2003 14:51:06.0968 (UTC) FILETIME=[35719D80:01C2B65C] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 01/07/2003 13:07, "Thomas Narten" wrote: > A user might want to disable the part about ongoing conflict detection > where the node gives up an address, or that it sends out broadcast ARP > responses. There is a tradeoff here in terms of increased bandwidth > vs. faster detection. Not everyone will necessarily weigh the relative > benefits the way you are. You seem to be saying the spec should not > allow or provide for this. There is a difference between detecting at > address config time vs. doing it after the address has already been > used. Think about how you would try to explain that to someone who is not technical...a three paragraph dialog box is not good ;-) Seriously, how do you deal with a new client that won't accept that it cannot get a desired address if someone doesn't give up in that situation? Now you have a request - defend loop that cannot stop, *or* you end up with one machine making endless ARP broadcasts, *or* you end up with conflicting IPs. The current conflict detection mechanism does not seem, to my tired eyes, to be something that will be an eater of bandwidth to the extent this is necessary, and disabling this would seem to cause more problems than it solves. > >> DHCP clients have done address conflict detection for years, and no one >> has asked for an option to disable address conflict detection there. > > > As has been pointed out on the DHC list, the DHC-specified behavior is > to send out ARP replies, not ARP requests. > > While I value your and Apple's experience here, your experience > doesn't necessarily generalize to the conclusion "not useful and not > needed", which is the way your response could be read. In terms of traffic, there's not going to be a large problem here, and I think that what Stuart is trying to say is that address conflict detection is a good thing. Yes, you give up a miniscule portion of your bandwidth, but you gain serious functionality and ease of use in return. That sounds acceptable. > >> 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. > > Because in *some* environments, the broadcast traffic is more of a > problem than duplicate addresses? Examples of where this will be a severe problem? > > The *conservative* thing to do is to not send out the broadcasts, as > we know that broadcast traffic has caused problems in the past. What > might be good is to have more explanation about the tradeoffs here so > implementors can make an informed opinion. The current text just says > "here are three choices." "pick one". More information is always good, but, to turn things around a bit, just because in *some* environments broadcasts have been a problem, we should not use them ever? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 8 09:57:12 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21594 for ; Wed, 8 Jan 2003 09:57:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0B19791231; Wed, 8 Jan 2003 09:59:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 848319123C; Wed, 8 Jan 2003 09:59: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 3F87E91231 for ; Wed, 8 Jan 2003 09:59:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C77B5E065; Wed, 8 Jan 2003 09:59:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from marsha.smtp.stsn.com (p249.n-sfpop03.stsn.com [199.107.154.249]) by segue.merit.edu (Postfix) with ESMTP id E63425E01F for ; Wed, 8 Jan 2003 09:59:52 -0500 (EST) Received: from [10.0.1.19] ([10.1.185.87]) by marsha.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Jan 2003 07:02:21 -0800 User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 08 Jan 2003 06:59:51 -0800 Subject: Re: Application software needs to be "zeroconf-aware"? 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 X-OriginalArrivalTime: 07 Jan 2003 15:02:21.0718 (UTC) FILETIME=[C7A04B60:01C2B65D] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 01/04/2003 00:04, "Erik Nordmark" wrote: >> 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. > > John, > > Your comparison with client and servers in different subnets without a router > makes me think the problem case hasn't been well explained. > > Let me try to explain an IP address configuration example where Keith's issue > might appear and that is unique to different address scopes i.e. not > related to a general inability to communicate. > > Imagine three boxes on a local link: A, B, and C. > > C is a link-local only box. It has the link-local address C(LL). > > A and B are full function boxes (support both DHCP and V4LL). > They acquire their link-local addresses (e.g. because the dhcp server is > not up when they boot, or because they need to them in order to communicate > with C). Thus A has A(LL) and A(G) assigned to the same interface. Similarely > for B. Right...so now A is using single link multihoming, just like any one of thousands of web servers around the world. Nothing new there. > > The issue appears when a node outside the link (call it D) communicates > with A and B and there is a referral going on. > If A wants to refer D to B, it must pass B(G) to D since D can not reach > B(LL). > How can this be ensured unless the application is link-local aware? But this same situation can come up, and *does* come up with firewalls and NAT. So , (and this is my point), while this can be problematic, this is neither new, or unique to v4LL, so we aren't treading new ground here. As well, it might not be a bad idea to include specific text to point out to implementers that this situation might happen, and that they need to handle it gracefully so that non v4LL - aware apps can be used more properly. > > When looking for specific applications that might fail in such a case > I think one needs to understand how the application instances discover > eachother. If this discovery process uses agents outside of the link > then the process would presumably only discover the global addresses of > its peers, even if those peers are on the same link and have a link-local > address. But are there applications that use other discovery mechanisms and > referals that would run into trouble in the above example configuration? Maybe...how much time to we have to check the operation of every IPv4 - aware app ;-) > > Thus the issue isn't about link-local addresses. The issue is how boxes > (and the applications running on those boxes) handle the case when the > box is configured with addresses of multiple scopes. Right...but again, this isn't new ground, nor v4LL - Unique. For some time at a previous company, I had to have my laptop configured with a NAT and a global address at the same time. I found that my major problems dealt with the OS software getting confused occaisionally, but that as long as the OS was not getting cranky, the apps were fine. This is *obviously* a single case, but I think that as long as the IP stack is dealing with this correctly, the apps should be fine. After all, that's why we have layers, so the apps don't need to care. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 8 10:11:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21906 for ; Wed, 8 Jan 2003 10:11:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DAFB79123C; Wed, 8 Jan 2003 10:14:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AAD229128B; Wed, 8 Jan 2003 10:14:44 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 927549123C for ; Wed, 8 Jan 2003 10:14:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7FC075E06F; Wed, 8 Jan 2003 10:14:43 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by segue.merit.edu (Postfix) with ESMTP id 5E9AE5DE8A for ; Wed, 8 Jan 2003 10:14:43 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18WHuj-0003dh-00; Wed, 08 Jan 2003 07:14:41 -0800 Date: Wed, 8 Jan 2003 10:11:52 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, Zeroconf Subject: Re: Application software needs to be "zeroconf-aware"? Message-Id: <20030108101152.5ff69358.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > The issue appears when a node outside the link (call it D) communicates > > with A and B and there is a referral going on. > > If A wants to refer D to B, it must pass B(G) to D since D can not reach > > B(LL). > > How can this be ensured unless the application is link-local aware? > > But this same situation can come up, and *does* come up with firewalls and > NAT. So , (and this is my point), while this can be problematic, this is > neither new, or unique to v4LL, so we aren't treading new ground here. So you are admitting that v4LL does not meet the IETF criteria for proposed standard, which say nothing about "not treading new ground" but do say "no known technical omissions". Or are you trying to use other people's mistakes - which were never standardized - as a justification for zeroconf making even more mistakes and insisting that IETF standadize those mistakes? > > > > Thus the issue isn't about link-local addresses. The issue is how boxes > > (and the applications running on those boxes) handle the case when the > > box is configured with addresses of multiple scopes. > > Right...but again, this isn't new ground, nor v4LL - Unique. For some time > at a previous company, I had to have my laptop configured with a NAT and a > global address at the same time. I found that my major problems dealt with > the OS software getting confused occaisionally, but that as long as the OS > was not getting cranky, the apps were fine. This is *obviously* a single > case, but I think that as long as the IP stack is dealing with this > correctly, the apps should be fine. You're simply wrong about that. Somehow I don't think the Internet should have to be penalized because of the ignorance of people who think that "apps should be fine" with whatever ill-conceived havoc they wish to impose - particularly when those people deliberately chose to ignore evidence to the contrary. Keith From owner-zeroconf@merit.edu Wed Jan 8 10:34:26 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22513 for ; Wed, 8 Jan 2003 10:34:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5D42A9123D; Wed, 8 Jan 2003 10:37:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2700D9128B; Wed, 8 Jan 2003 10:37: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 027549123D for ; Wed, 8 Jan 2003 10:37:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id E51D15E065; Wed, 8 Jan 2003 10:37:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from marsha.smtp.stsn.com (p249.n-sfpop03.stsn.com [199.107.154.249]) by segue.merit.edu (Postfix) with ESMTP id ABAF35E01F for ; Wed, 8 Jan 2003 10:37:17 -0500 (EST) Received: from [10.0.1.19] ([10.1.185.87]) by marsha.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Jan 2003 07:39:46 -0800 User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 08 Jan 2003 07:37:16 -0800 Subject: Re: Application software needs to be "zeroconf-aware"? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030108101152.5ff69358.moore@cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Jan 2003 15:39:46.0359 (UTC) FILETIME=[01895470:01C2B663] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 01/08/2003 07:11, "Keith Moore" wrote: > >>> The issue appears when a node outside the link (call it D) communicates >>> with A and B and there is a referral going on. >>> If A wants to refer D to B, it must pass B(G) to D since D can not reach >>> B(LL). >>> How can this be ensured unless the application is link-local aware? >> >> But this same situation can come up, and *does* come up with firewalls and >> NAT. So , (and this is my point), while this can be problematic, this is >> neither new, or unique to v4LL, so we aren't treading new ground here. > > So you are admitting that v4LL does not meet the IETF criteria for > proposed standard, which say nothing about "not treading new ground" > but do say "no known technical omissions". > > Or are you trying to use other people's mistakes - which were never > standardized - as a justification for zeroconf making even more > mistakes and insisting that IETF standadize those mistakes? Keith, you and I had a month long running battle on this off list. I think NAT, like any other tool has it's place, you evidently wish for severe corporal punishment for anyone not spitting at the sound of its name. So be it, we simply disagree here. However, my point was, that this problem exists *now*, is handled *now*, so is not some 'new, unseen issue'. This means that there are ways to deal with it in an intelligent, calm, rational manner. >> Right...but again, this isn't new ground, nor v4LL - Unique. For some time >> at a previous company, I had to have my laptop configured with a NAT and a >> global address at the same time. I found that my major problems dealt with >> the OS software getting confused occaisionally, but that as long as the OS >> was not getting cranky, the apps were fine. This is *obviously* a single >> case, but I think that as long as the IP stack is dealing with this >> correctly, the apps should be fine. > > You're simply wrong about that. Somehow I don't think the Internet should > have to be penalized because of the ignorance of people who think that "apps > should be fine" with whatever ill-conceived havoc they wish to impose - > particularly when those people deliberately chose to ignore evidence to > the contrary. Well, your Internet is evidently a far more fragile place than mine. If the Internet can handle the silliness that it handles now, I fail to see how v4LL will collapse it. Didn't Bob Metcalfe have to literally eat his words over his predictions of imminent Internet collapse? It's fun to predict, it isn't going to happen anytime soon, and if it does, it won't be due to v4LL. As well, if you wish to offer hard, happening evidence, that can be reproduced by all, well documented, etc., I welcome it. That is how things get fixed. A problem is discovered, defined, and fixed. I fix things, it's what I do. I will spend whatever time it takes to fix a problem, but I have no time to waste on bemoaning it's existance. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 8 11:07:59 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23314 for ; Wed, 8 Jan 2003 11:07:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F228D91201; Wed, 8 Jan 2003 11:11:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BFC5391208; Wed, 8 Jan 2003 11:11: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 A758C91201 for ; Wed, 8 Jan 2003 11:11:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 93D085DE11; Wed, 8 Jan 2003 11:11:02 -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 66A395DDB1 for ; Wed, 8 Jan 2003 11:11:02 -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 h08GB0A21703; Wed, 8 Jan 2003 11:11:00 -0500 (EST) Message-Id: <200301081611.h08GB0A21703@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: "John C. Welch" Subject: Re: Application software needs to be "zeroconf-aware"? Cc: moore@cs.utk.edu, zeroconf@merit.edu From: Keith Moore Date: Wed, 08 Jan 2003 11:11:00 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > > So you are admitting that v4LL does not meet the IETF criteria for > > proposed standard, which say nothing about "not treading new ground" > > but do say "no known technical omissions". > > > > Or are you trying to use other people's mistakes - which were never > > standardized - as a justification for zeroconf making even more > > mistakes and insisting that IETF standadize those mistakes? > Keith, you and I had a month long running battle on this off list. > I think NAT, like any other tool has it's place, you evidently wish > for severe corporal punishment for anyone not spitting at the sound > of its name. NAT is of course a useful tool if you respect its limitations. But it has such severe limitations that it's not suitable for IETF standardization. > However, my point was, that this problem exists *now*, is handled > *now*, so is not some 'new, unseen issue'. and you are simply wrong. or at the very least, it is a gross over-generalization to say that because NATs exist and are widely deployed in some environments, that it's acceptable under IETF standardization criteria to impose NAT-like problems on *all* IP networks. for instance, networks that use NATs tend to be heavily client-oriented, because the workarounds necessary to support significant numbers of servers/listeners behind a NAT are infeasible. > This means that there are ways to deal with > it in an intelligent, calm, rational manner. I don't see how being intelligent and rational is consistent with ignoring the criteria in 2026 or with ignoring evidence that v4LL causes problems. > If the Internet can handle the silliness that it handles now, I fail > to see how v4LL will collapse it. whether the Internet will collapse is not the question at hand. the question is whether v4LL meets the criteria in 2026, which set a much higher bar than "whether the Internet will collapse". > As well, if you wish to offer hard, happening evidence, that can be > reproduced by all, well documented, etc., I welcome it. download netsolve and install it, and try to run it with some mixture of clients, servers, and agents, inside and outside of a NAT. see http://icl.cs.utk.edu/netsolve/ -- Keith Moore http://www.cs.utk.edu/~moore/ 27 February 1933 11 September 2001 From owner-zeroconf@merit.edu Wed Jan 8 11:32:32 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24058 for ; Wed, 8 Jan 2003 11:32:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 58B439120E; Wed, 8 Jan 2003 11:35:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 226B59121C; Wed, 8 Jan 2003 11:35: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 C35B89120E for ; Wed, 8 Jan 2003 11:35:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id A75825DD8D; Wed, 8 Jan 2003 11:35:35 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from msweeper.seri.co.uk (mailhost2.seri.co.uk [194.133.18.172]) by segue.merit.edu (Postfix) with ESMTP id 18FD55DDA8 for ; Wed, 8 Jan 2003 11:35:35 -0500 (EST) Received: from ex1.seri.co.uk (ex1.seri.co.uk) by msweeper.seri.co.uk (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Wed, 8 Jan 2003 16:30:24 +0000 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"? X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 8 Jan 2003 16:35:33 -0000 Message-ID: <341710540F08E34498A057DEE04DAAD75AA78D@ex1.seri.co.uk> Thread-Topic: Application software needs to be "zeroconf-aware"? Thread-Index: AcK3MJJTSVsZgYRGRwagtOaIfx8jQwAAgU6A From: "Martin Layley" To: Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA24058 Most UK subscribers to dial-up or broadband (ADSL or cable) have no choice. NAT is the default. Non-NAT connections are far & few between (and expensive). The very environment where zeroconf is going to be most useful - plug & play - is the environment where NAT is most likely to be in place. Having looked at Keith's software, I see no reason why it should not work within the confines of an unrouted network, whether formed from automatically or manually assigned addresses. If it needs to work over a wider area, such as via an ISP, then this will obviously involve a router. The problem then becomes one for the zerorouter group and not zeroconf. Martin -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: 08 January 2003 16:11 To: John C. Welch Cc: moore@cs.utk.edu; zeroconf@merit.edu Subject: Re: Application software needs to be "zeroconf-aware"? > > So you are admitting that v4LL does not meet the IETF criteria for > > proposed standard, which say nothing about "not treading new ground" > > but do say "no known technical omissions". > > > > Or are you trying to use other people's mistakes - which were never > > standardized - as a justification for zeroconf making even more > > mistakes and insisting that IETF standadize those mistakes? > Keith, you and I had a month long running battle on this off list. > I think NAT, like any other tool has it's place, you evidently wish > for severe corporal punishment for anyone not spitting at the sound > of its name. NAT is of course a useful tool if you respect its limitations. But it has such severe limitations that it's not suitable for IETF standardization. > However, my point was, that this problem exists *now*, is handled > *now*, so is not some 'new, unseen issue'. and you are simply wrong. or at the very least, it is a gross over-generalization to say that because NATs exist and are widely deployed in some environments, that it's acceptable under IETF standardization criteria to impose NAT-like problems on *all* IP networks. for instance, networks that use NATs tend to be heavily client-oriented, because the workarounds necessary to support significant numbers of servers/listeners behind a NAT are infeasible. > This means that there are ways to deal with > it in an intelligent, calm, rational manner. I don't see how being intelligent and rational is consistent with ignoring the criteria in 2026 or with ignoring evidence that v4LL causes problems. > If the Internet can handle the silliness that it handles now, I fail > to see how v4LL will collapse it. whether the Internet will collapse is not the question at hand. the question is whether v4LL meets the criteria in 2026, which set a much higher bar than "whether the Internet will collapse". > As well, if you wish to offer hard, happening evidence, that can be > reproduced by all, well documented, etc., I welcome it. download netsolve and install it, and try to run it with some mixture of clients, servers, and agents, inside and outside of a NAT. see http://icl.cs.utk.edu/netsolve/ -- Keith Moore http://www.cs.utk.edu/~moore/ 27 February 1933 11 September 2001 The mail message has been scanned by MAILsweeper for content analysis. From owner-zeroconf@merit.edu Wed Jan 8 11:46:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24543 for ; Wed, 8 Jan 2003 11:46:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 66F709120D; Wed, 8 Jan 2003 11:49:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CE409121C; Wed, 8 Jan 2003 11:49: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 470D59120D for ; Wed, 8 Jan 2003 11:49:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A62F5DE11; Wed, 8 Jan 2003 11:49:25 -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 950755DDD8 for ; Wed, 8 Jan 2003 11:49:22 -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 A62205997D; Wed, 8 Jan 2003 16:48:32 +0000 (GMT) Message-ID: <00fb01c2b735$d8625d70$131010ac@aldebaran> From: "Philip Nye" To: "John C. Welch" , "Zeroconf Working Group" References: Subject: Re: Application software needs to be "zeroconf-aware"? Date: Wed, 8 Jan 2003 16:48:45 -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: "John C. Welch" > > > The issue appears when a node outside the link (call it D) communicates > > with A and B and there is a referral going on. > > If A wants to refer D to B, it must pass B(G) to D since D can not reach > > B(LL). > > How can this be ensured unless the application is link-local aware? > > But this same situation can come up, and *does* come up with firewalls and > NAT. So , (and this is my point), while this can be problematic, this is > neither new, or unique to v4LL, so we aren't treading new ground here. As > well, it might not be a bad idea to include specific text to point out to > implementers that this situation might happen, and that they need to handle > it gracefully so that non v4LL - aware apps can be used more properly. A difference is that I generally know when I am operating on a network hiding behind a NAT or Firewall gateway and it doesn't require a very high degree of knowledge to understand how distributed operations may not work properly through the gateway - the very term "gateway" implies it. If I put my equipment directly on the internet - something which doesn't actually require very much management and expertise these days, then I will be upset if applications still fail for the much less obvious reason that they are using the "wrong" IP address in referrals. In the example given, both boxes A & B work OK in simple exchanges with hosts on other networks and also with each other without me even knowing that they have LL addresses - both are "LL aware". However, when an three point operation involving referrals is used the failure could well be intermittent and hard to troubleshoot. Are there other examples of scoped addresses of this nature where there isn't a single obvious restricted point of contact between networks (the NAT gateway)? You could cite the use of other unroutable networks (10.x.x.x etc) but are these commonly run concurrently with global addresses on multihomed hosts? If so how are the problems solved? Philip Nye From owner-zeroconf@merit.edu Wed Jan 8 13:46:32 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01789 for ; Wed, 8 Jan 2003 13:46:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 44F4591235; Wed, 8 Jan 2003 13:49:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA8219122A; Wed, 8 Jan 2003 13:49:36 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 86EC891268 for ; Wed, 8 Jan 2003 13:49:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A2935DF93; Wed, 8 Jan 2003 13:49:33 -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 B95F25DE1C for ; Wed, 8 Jan 2003 13:49:32 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h08HLZq23467; Wed, 8 Jan 2003 11:21:35 -0600 (CST) Date: Wed, 8 Jan 2003 12:49:25 -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 v551) Cc: Stuart Cheshire , "Erik Nordmark" , zeroconf@merit.edu To: Thomas Narten From: Ted Lemon In-Reply-To: <200301081416.h08EGhl06768@cichlid.adsl.duke.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > It would be good to bring this up on the DHC list, as Bernie's post > asserting that the wording in 2131 (which says send out an ARP Reply) > was correct was not followed up saying anything like the above. It > would be good to get clarification on what the right thing to do, and > if the wording in the DHC spec needs changing, getting that added to > the list of known updates the spec needs. True. TBH, though, I don't think the spec needs to be updated - I think it's fine. It's just that all the existing implementations are out of spec, in precisely the way described in the draft. > I agree that the sending of ARP requests to "announce" the use of an > address has been widely used. But the specific point I was responding > to was not about that, it was about the use of ongoing conflict > detection. AFAIK, only Apple is doing this today. Is anyone else > doing this? I think that every BSD unix stack checks, but unlike the Apple stack they do not relinquish their IP address when they detect a conflict. Instead they just log an error message on the console. TBH, I prefer this behavior, but then, I'm a networking geek. I'm not sure what the right thing is for a non-geek-oriented stack, but I think the Apple response may be the best that can be done. We can't further probe with an ICMP Echo request, because we have an IP address conflict. :'} From owner-zeroconf@merit.edu Wed Jan 8 13:54:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01959 for ; Wed, 8 Jan 2003 13:54:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2673391230; Wed, 8 Jan 2003 13:57:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E65DC91236; Wed, 8 Jan 2003 13:57: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 EE7DD91230 for ; Wed, 8 Jan 2003 13:57:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id D66AA5E06F; Wed, 8 Jan 2003 13:57:26 -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 86E755DF93 for ; Wed, 8 Jan 2003 13:57:26 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h08HTXq23652; Wed, 8 Jan 2003 11:29:34 -0600 (CST) Date: Wed, 8 Jan 2003 12:57:24 -0600 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) Cc: Zeroconf , "John C. Welch" To: Keith Moore From: Ted Lemon In-Reply-To: <20030108101152.5ff69358.moore@cs.utk.edu> Message-Id: <06426514-233B-11D7-8FB4-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > So you are admitting that v4LL does not meet the IETF criteria for > proposed standard, which say nothing about "not treading new ground" > but do say "no known technical omissions". No, Keith, I don't think he's beaten his wife lately. From owner-zeroconf@merit.edu Wed Jan 8 15:38:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06437 for ; Wed, 8 Jan 2003 15:38:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 12DF591209; Wed, 8 Jan 2003 15:41:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0C579123E; Wed, 8 Jan 2003 15:41: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 C496491209 for ; Wed, 8 Jan 2003 15:41:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id B46855DDF0; Wed, 8 Jan 2003 15:41:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by segue.merit.edu (Postfix) with ESMTP id 4481A5DDA6 for ; Wed, 8 Jan 2003 15:41:41 -0500 (EST) Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h08KfeFF007953 for ; Wed, 8 Jan 2003 12:41:40 -0800 (PST) Received: from [192.168.0.119] ([12.232.144.158]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id H8EXHG00.T4Z; Wed, 8 Jan 2003 12:41:40 -0800 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 08 Jan 2003 12:41:18 -0800 Subject: Re: Application software needs to be "zeroconf-aware"? From: Alf Watt To: ZeroConf WG Cc: "John C. Welch" 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 When communicating an address to a far away host applications SHOULD check to make sure it's a public address before sending. That's just good defensive programming, the private address blocks are well-known and can easily be checked for. When receiving an address from a far away host the same check MAY be performed for sanity. Second, due to the dynamic nature of both DHCP and LL self-assigned addresses, applications SHOULD perform late binding of network names to addresses and not exchange addresses at all. When sending address information to a far away hosts only unicast-dns names should be used. See section 2.8 of "Replacement of AppleTalk NBP": http://files.dns-sd.org/draft-cheshire-dnsext-nbp.txt Best, Alf On 1/8/03 6:59 AM, "John C. Welch" wrote: >> Thus the issue isn't about link-local addresses. The issue is how boxes >> (and the applications running on those boxes) handle the case when the >> box is configured with addresses of multiple scopes. > > Right...but again, this isn't new ground, nor v4LL - Unique. For some time > at a previous company, I had to have my laptop configured with a NAT and a > global address at the same time. I found that my major problems dealt with > the OS software getting confused occaisionally, but that as long as the OS > was not getting cranky, the apps were fine. From owner-zeroconf@merit.edu Wed Jan 8 17:41:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10854 for ; Wed, 8 Jan 2003 17:41:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4C3C591237; Wed, 8 Jan 2003 17:44:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1830C91238; Wed, 8 Jan 2003 17:44: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 E390391237 for ; Wed, 8 Jan 2003 17:44:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id C8BD95E082; Wed, 8 Jan 2003 17:44:40 -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 5D9D55E080 for ; Wed, 8 Jan 2003 17:44:40 -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 RAA15170 for ; Wed, 8 Jan 2003 17:44:39 -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 RAA09057 for ; Wed, 8 Jan 2003 17:44:39 -0500 (EST) Received: from [10.0.1.8] (mw-12-103.ny.shownets.net [216.89.12.103] (may be forged)) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA17114 for ; Wed, 8 Jan 2003 17:44:38 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 08 Jan 2003 14:44:35 -0800 Subject: Re: Application software needs to be "zeroconf-aware"? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200301081611.h08GB0A21703@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 01/08/2003 08:11, "Keith Moore" wrote: >> Keith, you and I had a month long running battle on this off list. >> I think NAT, like any other tool has it's place, you evidently wish >> for severe corporal punishment for anyone not spitting at the sound >> of its name. > > NAT is of course a useful tool if you respect its limitations. But it > has such severe limitations that it's not suitable for IETF > standardization. This has nothing to do with anything. I happened to use it for an example, and nothing more. It was in no way intended as anything else. I could have used anything else as an example. Let's drop that. > >> However, my point was, that this problem exists *now*, is handled >> *now*, so is not some 'new, unseen issue'. > > and you are simply wrong. or at the very least, it is a gross > over-generalization to say that because NATs exist and are widely > deployed in some environments, that it's acceptable under IETF > standardization criteria to impose NAT-like problems on *all* IP > networks. for instance, networks that use NATs tend to be heavily > client-oriented, because the workarounds necessary to support > significant numbers of servers/listeners behind a NAT are infeasible. > This has nothing to do with NAT whatsoever. There are other ways to have to deal with scope limitations in a single - link multihoming configuration. Personal feelings on NAT are inappropriate, since NAT is not a part of Zeroconf, and I didn't indicate that it was. > >> This means that there are ways to deal with >> it in an intelligent, calm, rational manner. > > I don't see how being intelligent and rational is consistent with > ignoring the criteria in 2026 or with ignoring evidence that v4LL > causes problems. Well, so far, I haven't seen an example of a problem that v4LL causes that isn't caused by other things. When I do see one, then we all can procede logically and calmly to see how to fix it. > >> As well, if you wish to offer hard, happening evidence, that can be >> reproduced by all, well documented, etc., I welcome it. > > download netsolve and install it, and try to run it with some mixture > of clients, servers, and agents, inside and outside of a NAT. > see http://icl.cs.utk.edu/netsolve/ This isn't a NAT working group, so I fail to see how an app that doesn't like NAT applies. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 8 17:45:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11105 for ; Wed, 8 Jan 2003 17:45:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E933F91238; Wed, 8 Jan 2003 17:48:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB11791243; Wed, 8 Jan 2003 17:48: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 E640791238 for ; Wed, 8 Jan 2003 17:48:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id C50715E06B; Wed, 8 Jan 2003 17:48: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 590AD5DFB6 for ; Wed, 8 Jan 2003 17:48: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 RAA16800 for ; Wed, 8 Jan 2003 17:48: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 RAA17119 for ; Wed, 8 Jan 2003 17:48:26 -0500 (EST) Received: from [10.0.1.8] (mw-12-103.ny.shownets.net [216.89.12.103] (may be forged)) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA18039 for ; Wed, 8 Jan 2003 17:48:25 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 08 Jan 2003 14:48:24 -0800 Subject: Re: Application software needs to be "zeroconf-aware"? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <00fb01c2b735$d8625d70$131010ac@aldebaran> 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 01/08/2003 08:48, "Philip Nye" wrote: > Are there other examples of scoped addresses of this nature where there > isn't a single obvious restricted point of contact between networks (the NAT > gateway)? You could cite the use of other unroutable networks (10.x.x.x etc) > but are these commonly run concurrently with global addresses on multihomed > hosts? If so how are the problems solved? Yes, at least in my experience, you do run into these things, for certain types of servers that have to live on the threshold. The problems are solved based on OS implementation and limitations. For the Macs, we just added a second router address, but this was a manually configured environment. The Windows boxes at the time were more limited, so they required someone with a Mac or a Sun box to be an intermediary. (our windows users at the time didn't hit this wall much, so it was not a great problem.) I wasn't running the Sun boxes, so I wasn't involved with configuring them, but it was probably the same thing as the Macs, or not much harder, since the total fix time was about an hour. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 8 17:47:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11250 for ; Wed, 8 Jan 2003 17:47:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1382E91243; Wed, 8 Jan 2003 17:50:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF30591244; Wed, 8 Jan 2003 17:50: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 D164D91243 for ; Wed, 8 Jan 2003 17:50:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id C012C5DFB6; Wed, 8 Jan 2003 17:50:19 -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 710A35DFA2 for ; Wed, 8 Jan 2003 17:50:19 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h08LMPq26775; Wed, 8 Jan 2003 15:22:25 -0600 (CST) Date: Wed, 8 Jan 2003 16:50:17 -0600 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) Cc: Zeroconf To: "John C. Welch" From: Ted Lemon In-Reply-To: Message-Id: <8EC8D73C-235B-11D7-8FB4-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Maybe the FTP PORT command would be a good example that we could use to analyze the problem? From owner-zeroconf@merit.edu Wed Jan 8 18:28:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13057 for ; Wed, 8 Jan 2003 18:28:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 960079123A; Wed, 8 Jan 2003 18:31:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 599F991244; Wed, 8 Jan 2003 18:31: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 310E79123A for ; Wed, 8 Jan 2003 18:31:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 162165DD90; Wed, 8 Jan 2003 18:31: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 A83AC5DD8C for ; Wed, 8 Jan 2003 18:31: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 h08NVgA22846; Wed, 8 Jan 2003 18:31:43 -0500 (EST) Message-Id: <200301082331.h08NVgA22846@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: Ted Lemon Subject: Re: Application software needs to be "zeroconf-aware"? Cc: moore@cs.utk.edu, zeroconf@merit.edu, jwelch@mit.edu From: Keith Moore Date: Wed, 08 Jan 2003 18:31:42 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk On Wed, 8 Jan 2003 12:57:24 -0600 Ted Lemon wrote: > > So you are admitting that v4LL does not meet the IETF criteria for > > proposed standard, which say nothing about "not treading new ground" > > but do say "no known technical omissions". > > No, Keith, I don't think he's beaten his wife lately. you are exaggerating, I'm not. John did say there were known problems with v4LL. My point is that such problems mean that v4LL in its current state does not qualify for proposed standard status. This is not an exaggeration, it's just a logical inference based on John's assertion and the plain language of RFC 2026. -- Keith Moore http://www.cs.utk.edu/~moore/ 27 February 1933 11 September 2001 From owner-zeroconf@merit.edu Wed Jan 8 18:53:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13818 for ; Wed, 8 Jan 2003 18:53:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5C34E91244; Wed, 8 Jan 2003 18:56:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29D4B91245; Wed, 8 Jan 2003 18:56: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 1BCC291244 for ; Wed, 8 Jan 2003 18:56:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0394D5DDE3; Wed, 8 Jan 2003 18:56: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 9B6525DD90 for ; Wed, 8 Jan 2003 18:56: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 h08NufA22950; Wed, 8 Jan 2003 18:56:41 -0500 (EST) Message-Id: <200301082356.h08NufA22950@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: "Philip Nye" Subject: Re: Application software needs to be "zeroconf-aware"? Cc: moore@cs.utk.edu, jwelch@mit.edu, zeroconf@merit.edu From: Keith Moore Date: Wed, 08 Jan 2003 18:56:41 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Are there other examples of scoped addresses of this nature where there > isn't a single obvious restricted point of contact between networks (the NAT > gateway)? You could cite the use of other unroutable networks (10.x.x.x etc) > but are these commonly run concurrently with global addresses on multihomed > hosts? If so how are the problems solved? IPv6 has the same problem with scoped addresses, and for this reason there is growing sentiment in the IPv6 world to restrict or discourage general-purpose use of both site-local and link-local addresses. -- Keith Moore http://www.cs.utk.edu/~moore/ 27 February 1933 11 September 2001 From owner-zeroconf@merit.edu Wed Jan 8 18:58:09 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14010 for ; Wed, 8 Jan 2003 18:58:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AAB5C91247; Wed, 8 Jan 2003 19:00:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 764E391249; Wed, 8 Jan 2003 19:00: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 4FEA591247 for ; Wed, 8 Jan 2003 19:00:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 689DD5DE9B; Wed, 8 Jan 2003 19:00: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 0A6225DE53 for ; Wed, 8 Jan 2003 19:00: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 h0900gA22969; Wed, 8 Jan 2003 19:00:42 -0500 (EST) Message-Id: <200301090000.h0900gA22969@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: Alf Watt Subject: Re: Application software needs to be "zeroconf-aware"? Cc: moore@cs.utk.edu, zeroconf@merit.edu, jwelch@mit.edu From: Keith Moore Date: Wed, 08 Jan 2003 19:00:41 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk On Wed, 08 Jan 2003 12:41:18 -0800 Alf Watt wrote: > > When communicating an address to a far away host applications SHOULD check > to make sure it's a public address before sending. the application has no way of knowing whether or not the host receiving the referral is "far away" (or more precisely, within the same addressing realm). > Second, due to the dynamic nature of both DHCP and LL self-assigned > addresses, applications SHOULD perform late binding of network names to > addresses and not exchange addresses at all. that's a gross overgeneralization. it works well for some applications, not for others. DNS names are slow, they are sometimes ambiguous (multiple names per host or multiple hosts sharing a single name) and DNS lookup is far less reliable than IP routing. it never ceases to amaze me that so many people think they understand the needs of the entire Internet well enough to make broad statements about how everyone SHOULD write applications. -- -- Keith Moore http://www.cs.utk.edu/~moore/ 27 February 1933 11 September 2001 From owner-zeroconf@merit.edu Wed Jan 8 19:00:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14117 for ; Wed, 8 Jan 2003 19:00:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A938E91245; Wed, 8 Jan 2003 19:03:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CB2F91246; Wed, 8 Jan 2003 19:03: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 5527D91245 for ; Wed, 8 Jan 2003 19:03:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2DEB85DE53; Wed, 8 Jan 2003 19:03:08 -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 D2D975DD90 for ; Wed, 8 Jan 2003 19:03:07 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h08MZCq27372; Wed, 8 Jan 2003 16:35:12 -0600 (CST) Date: Wed, 8 Jan 2003 18:03:04 -0600 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) Cc: jwelch@mit.edu, zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <200301082331.h08NVgA22846@astro.cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > you are exaggerating, I'm not. No, I was actually expressing my exact impression of the semantic content of your message. I am sorry if I read your message in a way other than that which you intended. If you are interested in having an earnest debate, then why don't you say precisely what it is that is a known problem with v4ll in the sense intended by RFC2026, and then we can talk about that? In another message, I suggested an aspect of the FTP protocol that we could use to have this debate - perhaps you'd like to take a stab at that one? If you are not interested in having this sort of debate, then you can signify that by not making a precise statement about what is a known problem with v4ll in the sense intended by RFC2026, and then we can all move on. From owner-zeroconf@merit.edu Wed Jan 8 19:13:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14379 for ; Wed, 8 Jan 2003 19:13:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EFF0291246; Wed, 8 Jan 2003 19:15:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB81791248; Wed, 8 Jan 2003 19:15: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 9D44691246 for ; Wed, 8 Jan 2003 19:15:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 138745DDE3; Wed, 8 Jan 2003 19:15:28 -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 68FA75DDD5 for ; Wed, 8 Jan 2003 19:15: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 h090FOA22996; Wed, 8 Jan 2003 19:15:25 -0500 (EST) Message-Id: <200301090015.h090FOA22996@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: "Martin Layley" Subject: Re: Application software needs to be "zeroconf-aware"? Cc: moore@cs.utk.edu, zeroconf@merit.edu From: Keith Moore Date: Wed, 08 Jan 2003 19:15:24 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > Having looked at Keith's software, Clarification: NetSolve is not my software. I just happen to work in the same group as the folks who maintain it, and occasionally they ask me to help them with thorny problems like "How do we make this work across a NAT?" > I see no reason why it should not work within the confines of an > unrouted network, whether formed from automatically or manually > assigned addresses. NetSolve works fine on an isolated network, and is often demonstrated that way. > If it needs to work over a wider area, such as via an ISP, then this > will obviously involve a router. The problem then becomes one for > the zerorouter group and not zeroconf. This is where I strongly disagree. The problem is that (the charter notwithstanding) zeroconf's link-local proposal will affect all networks, not just isolated networks, and the cases where link-local causes problems are on networks that have external connectivity. It's not acceptable for zeroconf to break operation of applications on connected networks, and it's not acceptable for zeroconf to break things and claim that they're somebody else's problem to fix. Keith From owner-zeroconf@merit.edu Wed Jan 8 19:19:59 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14563 for ; Wed, 8 Jan 2003 19:19:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B2EA91248; Wed, 8 Jan 2003 19:23:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08CF491249; Wed, 8 Jan 2003 19:23: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 EADCD91248 for ; Wed, 8 Jan 2003 19:23:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id D60C65DE53; Wed, 8 Jan 2003 19:23:02 -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 796365DDE3 for ; Wed, 8 Jan 2003 19:23:02 -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 h090N1A23010; Wed, 8 Jan 2003 19:23:01 -0500 (EST) Message-Id: <200301090023.h090N1A23010@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: Ted Lemon Subject: Re: Application software needs to be "zeroconf-aware"? Cc: moore@cs.utk.edu, zeroconf@merit.edu, jwelch@mit.edu From: Keith Moore Date: Wed, 08 Jan 2003 19:23:01 -0500 Sender: owner-zeroconf@merit.edu Precedence: bulk > If you are interested in having an earnest debate, then why don't you > say precisely what it is that is a known problem with v4ll in the sense > intended by RFC2026, and then we can talk about that? I have done so, many times, and in many different ways. I've written a lengthy document that attempts to outline these problems, that I submitted to IESG (and cc'ed to this group) in response to Last Call. I've also cited specific applications that linklocal breaks. I cannot fathom why this isn't precise enough for some people, but I'm getting tired of answering the same question again and again and still being told that I'm not answering it. > In another message, I suggested an aspect of the FTP protocol that we > could use to have this debate - perhaps you'd like to take a stab at > that one? When you argue that LL breaks 3-party FTP then you get the response that 3-party FTP is obsolete and/or a security hole anyway, so breaking 3-party FTP is no big deal. And the only reason you need PORT is for 3-party FTP; PASV works fine for 2-party FTP. So I'd rather cite applications that are currently being used. Keith From owner-zeroconf@merit.edu Wed Jan 8 19:45:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15550 for ; Wed, 8 Jan 2003 19:45:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A131D91249; Wed, 8 Jan 2003 19:48:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70E949124A; Wed, 8 Jan 2003 19:48: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 2483591249 for ; Wed, 8 Jan 2003 19:47:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE59D5DDBE; Wed, 8 Jan 2003 19:47:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.85]) by segue.merit.edu (Postfix) with ESMTP id 845855DE9B for ; Wed, 8 Jan 2003 19:47:39 -0500 (EST) Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h090lcbD006216 for ; Wed, 8 Jan 2003 16:47:39 -0800 (PST) Received: from [192.168.0.119] ([12.232.144.158]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id H8F8VE00.SI3; Wed, 8 Jan 2003 16:47:38 -0800 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 08 Jan 2003 16:47:21 -0800 Subject: Re: Application software needs to be "zeroconf-aware"? From: Alf Watt To: Keith Moore Cc: ZeroConf WG , , Ted Lemon Message-ID: In-Reply-To: <200301090023.h090N1A23010@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 1/8/03 4:23 PM, "Keith Moore" wrote: >> If you are interested in having an earnest debate, then why don't you >> say precisely what it is that is a known problem with v4ll in the sense >> intended by RFC2026, and then we can talk about that? > > I have done so, many times, and in many different ways. > > I've written a lengthy document that attempts to outline these problems, > that I submitted to IESG (and cc'ed to this group) in response to Last > Call. I've also cited specific applications that linklocal breaks. Perhaps you SHOULD re-introduce that document for review and explain in detail how one of your specific example applications breaks in the presence of v4LL addressing. This has been suggested before, by the groups chair among others. Once your issues, technical or otherwise, are clear we MAY be able to have a discussion about how to resolve those issues instead of needlessly running around in circles. Best, Alf From owner-zeroconf@merit.edu Wed Jan 8 20:49:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16691 for ; Wed, 8 Jan 2003 20:49:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5BC809124A; Wed, 8 Jan 2003 20:52:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2558F9124B; Wed, 8 Jan 2003 20: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 E2DB39124A for ; Wed, 8 Jan 2003 20:52:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id CAC2B5DDBE; Wed, 8 Jan 2003 20:52:44 -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 3F4295DD8D for ; Wed, 8 Jan 2003 20:52:44 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h090Ojq28393; Wed, 8 Jan 2003 18:24:45 -0600 (CST) Date: Wed, 8 Jan 2003 19:52:39 -0600 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) Cc: jwelch@mit.edu, zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <200301090023.h090N1A23010@astro.cs.utk.edu> Message-Id: <086EC4AD-2375-11D7-8FB4-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I have done so, many times, and in many different ways. Sigh. I had to really hunt for anything substantive - I couldn't find the draft to which you referred in your list of publications on your web page. I finally did find in the WG archive a pretty nice general analysis of the problem space that you sent before I joined the list (I joined the list at Thomas' request because of DHCP-related issues in this draft). Having read your response, I think it's a fine analysis, but I have trouble with most of the conclusions you draw as a result of your analysis. For example, you say that link-local should be disabled by default on all wireless interfaces. The only justification I can find for this in your article is your example of two companies sharing a wall, where WAPs in one company are reachable from the other company. You say this poses a security threat because the firewall has been bypassed. Well, okay, but the security threat isn't because of link-local addressing, and getting rid of link-local addressing doesn't cure the problem. The problem is a pathologically bad wireless network configuration. In a networking environment where firewall protection is needed because of poor internal security, an open wireless link on the trusted side of the firewall is just wrong, and the solution is not to kill link-local - it's to secure the WAP, or put it outside the firewall (probably a better choice, given the wireless security options that are currently available). You also say "more study is required to understand the security implications of link-local." This isn't a helpful recommendation. If you think there are security implications, why then trot them out! You worry about addresses leaking into the DNS. This is a real problem with NATs already. However, I don't see how link-local addressing exacerbates the problem - you can't communicate with the external network using your link-local address, so it's unlikely that an application is going to leak it in the first place (see below). If we want to solve this problem, we should standardize NATs and firewalls and require that they intercept lookups for private address spaces. As for the application issues, I just can't come up with a scenario where this is going to be a problem. Normally, the way an application would send its address to another host would be to do a getsockname() system call. This requires that the connection be working - that the two endpoints be communicating. If the two endpoints are communicating, the correct address is going to be returned by getsockname(). The stack does need to be smart enough not to try to connect to a non-link-local address using a link-local source address - that would simply result in repeated connection timeouts. It is possible that an application might do a system-specific call like ioctl(..., SIOCGIFCONF, ...) to get an interface list and enumerate the addresses. However, in that case I think we can assume that the application is smart enough to at least be configurable as to which address it advertises. I don't know of any applications that would be adversely affected by this. It would make sense to suggest that the stack always return the link-local address last, I suppose. I guess my conclusion from all of this is that you've thought about this pretty carefully, but that your conclusions are by no means the only ones that can be drawn from your analysis. I do not agree, based on carefully reading your analysis, that this proposal needs to be held back for further research. I don't agree that link-local should be disabled by default on wireless networks. Other than that, if you want to write up specific proposals for mitigating the problems that you've identified, I think that's a fine idea, and I hope the WG would agree with that. But if the only action you think appropriate is to scuttle the draft, it's going to be tough for you to have a meaningful discussion with the people who've worked on the draft and want to advance it. Based on the interactions I've seen so far, I wonder if that isn't why we're seeing all this back-and-forth. From owner-zeroconf@merit.edu Wed Jan 8 21:00:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16834 for ; Wed, 8 Jan 2003 21:00:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D9BE29124B; Wed, 8 Jan 2003 21:03:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A55719124C; Wed, 8 Jan 2003 21:03: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 A789C9124B for ; Wed, 8 Jan 2003 21:03:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F9EE5DEE2; Wed, 8 Jan 2003 21:03:39 -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 0DB0F5DE2D for ; Wed, 8 Jan 2003 21:03:39 -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 SAA12391; Wed, 8 Jan 2003 18:03:34 -0800 (PST) Received: from localhost (d-mpk17-85-141.Eng.Sun.COM [129.146.85.141]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h0923VP01700; Thu, 9 Jan 2003 03:03:31 +0100 (MET) Date: Thu, 9 Jan 2003 03:00:09 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt To: Ted Lemon Cc: Thomas Narten , zeroconf@merit.edu, Erik Nordmark , Stuart Cheshire In-Reply-To: "Your message with ID" <7A5D963A-228D-11D7-8FB4-00039367340A@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > As has been pointed out on the DHC list, the DHC-specified behavior is > > to send out ARP replies, not ARP requests. > > Although the RFC does say to send an ARP request, it appears that there > are no implementations that actually do this - every implementation > that does anything at all along these lines sends an ARP reply, > including the latest Windows (dunno about earlier versions, but no > reason to suspect they are different). So while in fact the draft is > contradicting the RFC, it is not contradicting what is deployed. You seem to agree with Thomas' paragraph yet you inverse request/reply. I'm confused! I guess there are two different things in RFC 2131: the probing that is done to check for a duplicate and the annoucement that the client is now using the address. The probing is consistent between RFC 2131 and ACD; an ARP request with a zero sender protocol address. But the announcement is different; DHC says broadcast ARP reply and ACD says to use a ARP request for yourself. So were you commenting on the probe or the announcement? Erik From owner-zeroconf@merit.edu Wed Jan 8 21:18:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17138 for ; Wed, 8 Jan 2003 21:18:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0D2769124C; Wed, 8 Jan 2003 21:21:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6CBE9124D; Wed, 8 Jan 2003 21:21: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 5F7679124C for ; Wed, 8 Jan 2003 21:21:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 39C9A5DEC4; Wed, 8 Jan 2003 21:21:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by segue.merit.edu (Postfix) with ESMTP id CCA955DE2D for ; Wed, 8 Jan 2003 21:21:24 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18WSJu-0005rR-00; Wed, 08 Jan 2003 18:21:22 -0800 Date: Wed, 8 Jan 2003 21:18:31 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Application software needs to be "zeroconf-aware"? Message-Id: <20030108211831.41018294.moore@cs.utk.edu> In-Reply-To: <086EC4AD-2375-11D7-8FB4-00039367340A@nominum.com> References: <200301090023.h090N1A23010@astro.cs.utk.edu> <086EC4AD-2375-11D7-8FB4-00039367340A@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Wed, 8 Jan 2003 19:52:39 -0600 Ted Lemon wrote: > > I have done so, many times, and in many different ways. > > Sigh. I had to really hunt for anything substantive - I couldn't find > the draft to which you referred in your list of publications on your > web page. I finally did find in the WG archive a pretty nice general > analysis of the problem space that you sent before I joined the list (I > joined the list at Thomas' request because of DHCP-related issues in > this draft). Having read your response, I think it's a fine analysis, > but I have trouble with most of the conclusions you draw as a result of > your analysis. thanks. > For example, you say that link-local should be disabled by default on > all wireless interfaces. The only justification I can find for this > in your article is your example of two companies sharing a wall, where > WAPs in one company are reachable from the other company. You say > this poses a security threat because the firewall has been bypassed. > Well, okay, but the security threat isn't because of link-local > addressing, and getting rid of link-local addressing doesn't cure the > problem. here's the sense in which it "cures" (or at least reduces) the problem. if the interfaces have to be explicitly configured (i.e. explicit action is required on the part of the user before the wireless interface is enabled) then the attacks can only be made when the wireless interface is enabled, which won't be all the time, or for every machine with a wireless interface. OTOH if the interfaces configure themselves automagically without interaction with the user, then every machine that supports LL (which is to say, essentially every machine) that also has a wireless interface will be potentially vulnerable to attack at any time it can possibly be in range of an attacker (which is to say, most of the time). no, the problem isn't exactly caused by link-local - rather, it's an unintended consequence of the combination of wireless interfaces and any kind of automatic configuration. it used to be that a host was safe from attack if it wasn't plugged in to a network. but with wireless+automatic configuration, the host is never safe from attack. (unless you can disable it somehow, but even then the default behavior should not be to leave the host vulnerable. that's a bit like shipping machines with + in /etc/hosts.equiv) > The problem is a pathologically bad wireless network > configuration. In a networking environment where firewall protection > is needed because of poor internal security, an open wireless link on > the trusted side of the firewall is just wrong, and the solution is not > to kill link-local - it's to secure the WAP, or put it outside the > firewall (probably a better choice, given the wireless security options > that are currently available). you don't need a WAP to have this problem, since wireless hosts can talk directly to one another. > You also say "more study is required to understand the security > implications of link-local." This isn't a helpful recommendation. > If you think there are security implications, why then trot them out! actually, it's the other way around. the burden is not on me to explain every single security consideration of link local - it is on the group to explain why link local meets the criteria for proposed standard. and if more study is indeed required (as it seems to be) then I fail to see how it can't be helpful to point that out to people who don't seem to realize it. > You worry about addresses leaking into the DNS. This is a real > problem with NATs already. However, I don't see how link-local > addressing exacerbates the problem - you can't communicate with the > external network using your link-local address, so it's unlikely that > an application is going to leak it in the first place (see below). If > we want to solve this problem, we should standardize NATs and firewalls > and require that they intercept lookups for private address spaces. what you seem to be saying is that because NATs exist and cause some of the same problems that link-local addresses do, that the criteria for standardization should be relaxed for link-local addresses. it's the other way around - neither NAT nor link-local is suitable for standardization because they both cause problems. > As for the application issues, I just can't come up with a scenario > where this is going to be a problem. Normally, the way an application > would send its address to another host would be to do a getsockname() > system call. gross overgeneralization. I know of apps that determine addresses to use in referrals by each of the following means: 1. explicit configuration 2. gethostbyname (gethostname ()) 3. getpeername () to get peer's address and use it in a referral to another host (often used as a workaround for some NAT problmes) 4. getsockname () 5. ioctl to get list of interfaces (to be clear: I don't know of any app that uses all of these; I know of at least one app for each of these cases) and as far as I can tell getsockname() isn't "normal" at all. > It is possible that an application might do a system-specific call like > ioctl(..., SIOCGIFCONF, ...) to get an interface list and enumerate the > addresses. However, in that case I think we can assume that the > application is smart enough to at least be configurable as to which > address it advertises. pvm does this. and no, it's not configurable in this way. > I don't know of any applications that would be > adversely affected by this. it happens that I work with people who write and use distributed applications, and I've also written a couple of those applications, and I've tried to design workarounds for NATs for such applications. so I'm more sensitive to this issue than most. > It would make sense to suggest that the > stack always return the link-local address last, I suppose. once upon a time I suggested that stacks respond to SIOGIFCONF in such a way that LL addresses were unlikely to be mistaken for ordinary addresses and unlikely to be used by apps that weren't LL-aware. the group refused to consider it. > I guess my conclusion from all of this is that you've thought about > this pretty carefully, but that your conclusions are by no means the > only ones that can be drawn from your analysis. I do not agree, based > on carefully reading your analysis, that this proposal needs to be held > back for further research. I don't agree that link-local should be > disabled by default on wireless networks. > > Other than that, if you want to write up specific proposals for > mitigating the problems that you've identified, I think that's a fine > idea, and I hope the WG would agree with that. But if the only action > you think appropriate is to scuttle the draft, it's going to be tough > for you to have a meaningful discussion with the people who've worked > on the draft and want to advance it. Based on the interactions I've > seen so far, I wonder if that isn't why we're seeing all this > back-and-forth. I am not trying to scuttle the draft, I'm trying to get it fixed. I've tried to suggest the minimal fixes needed to make it mostly harmless. I do think that LL needs to be disabled by default on wireless interfaces, for reasons mentioned above. I also think that LL needs to be able to be disabled by any managed network on a link-wide basis, and by any host that supports it, so that there is a workaround for networks that experience operational problems and for apps that break. None of these would prevent LL from being used effectively in ad hoc networks. The problem is, many people in this group (including it seems one of the chairs) want LL to be used in managed networks also, and they want it to always be enabled so that LL-only devices can talk to ordinary hosts in managed networks. This goes far beyond the group's charter, and it causes lots of problems. Keith From owner-zeroconf@merit.edu Wed Jan 8 21:41:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17555 for ; Wed, 8 Jan 2003 21:41:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5AC339124D; Wed, 8 Jan 2003 21:44:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A6389124E; Wed, 8 Jan 2003 21:44: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 40EEB9124D for ; Wed, 8 Jan 2003 21:44:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2268C5DF94; Wed, 8 Jan 2003 21:44:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by segue.merit.edu (Postfix) with ESMTP id 339BC5DF60 for ; Wed, 8 Jan 2003 21:44:22 -0500 (EST) Received: from localhost ([3ffe:501:4819:2000:bd67:6d47:e443:6563]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id h092i8R88258; Thu, 9 Jan 2003 11:44:08 +0900 (JST) Date: Thu, 09 Jan 2003 11:44:17 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Keith Moore Cc: "Philip Nye" , jwelch@mit.edu, zeroconf@merit.edu Subject: Re: Application software needs to be "zeroconf-aware"? In-Reply-To: <200301082356.h08NufA22950@astro.cs.utk.edu> References: <200301082356.h08NufA22950@astro.cs.utk.edu> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.2 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 27 Sender: owner-zeroconf@merit.edu Precedence: bulk >>>>> On Wed, 08 Jan 2003 18:56:41 -0500, >>>>> Keith Moore said: >> Are there other examples of scoped addresses of this nature where there >> isn't a single obvious restricted point of contact between networks (the NAT >> gateway)? You could cite the use of other unroutable networks (10.x.x.x etc) >> but are these commonly run concurrently with global addresses on multihomed >> hosts? If so how are the problems solved? > IPv6 has the same problem with scoped addresses, and for this reason there is > growing sentiment in the IPv6 world to restrict or discourage general-purpose > use of both site-local and link-local addresses. (Sorry for commenting on the point which is not very essential to the discussion here) For the record, my impression on the case of the IPv6 world is that there is few discussion about the usage of link-local addresses, while there is an ongoing, heated discussion on the usage of site-local addresses. Also, though it is true that some people in the IPv6 world have the sentiment to restrict site-local addresses, there is also a group of a certain amount of people that has the opposite opinion. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-zeroconf@merit.edu Wed Jan 8 22:37:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18254 for ; Wed, 8 Jan 2003 22:37:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 428369124E; Wed, 8 Jan 2003 22:40:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1432C9124F; Wed, 8 Jan 2003 22:40:48 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E60139124E for ; Wed, 8 Jan 2003 22:40:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id CCA585DFA4; Wed, 8 Jan 2003 22:40:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by segue.merit.edu (Postfix) with ESMTP id AA6D05DF34 for ; Wed, 8 Jan 2003 22:40:47 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18WTYd-0006XE-00; Wed, 08 Jan 2003 19:40:39 -0800 Date: Wed, 8 Jan 2003 22:37:49 -0500 From: Keith Moore To: JINMEI Tatuya / ¿=?ISO-8859-1?Q?=C0=CC=C0=C3=A3=BA?=È Cc: moore@cs.utk.edu, philip@engarts.com, jwelch@mit.edu, zeroconf@merit.edu Subject: Re: Application software needs to be "zeroconf-aware"? Message-Id: <20030108223749.03620064.moore@cs.utk.edu> In-Reply-To: References: <200301082356.h08NufA22950@astro.cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > For the record, my impression on the case of the IPv6 world is that > there is few discussion about the usage of link-local addresses, while > there is an ongoing, heated discussion on the usage of site-local > addresses. That is my impression also about the discussion. But while site-locals are controversial, there seems to be a general consensus that IPv6 link-locals are for special purposes only. > Also, though it is true that some people in the IPv6 world > have the sentiment to restrict site-local addresses, there is also a > group of a certain amount of people that has the opposite opinion. agreed. From owner-zeroconf@merit.edu Wed Jan 8 23:13:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18971 for ; Wed, 8 Jan 2003 23:13:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4D0469124F; Wed, 8 Jan 2003 23:16:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0C66691250; Wed, 8 Jan 2003 23:16: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 E24FB9124F for ; Wed, 8 Jan 2003 23:16:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id C75625DDC0; Wed, 8 Jan 2003 23:16:45 -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 73A7D5DD8D for ; Wed, 8 Jan 2003 23:16:45 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h092mkq29655; Wed, 8 Jan 2003 20:48:47 -0600 (CST) Date: Wed, 8 Jan 2003 22:16:41 -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 v551) Cc: Stuart Cheshire , zeroconf@merit.edu, Thomas Narten To: Erik Nordmark From: Ted Lemon In-Reply-To: Message-Id: <27AECC89-2389-11D7-8FB4-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > So were you commenting on the probe or the announcement? The announcement. All DHCP clients that I know of do the reply instead of the request - i.e., they're out of spec. :'} From owner-zeroconf@merit.edu Thu Jan 9 00:04:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20142 for ; Thu, 9 Jan 2003 00:04:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DCCBA91250; Thu, 9 Jan 2003 00:07:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 961E391251; Thu, 9 Jan 2003 00:07: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 4310291250 for ; Thu, 9 Jan 2003 00:07:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 23EC25DDC0; Thu, 9 Jan 2003 00:07:43 -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 AC2995DDA5 for ; Thu, 9 Jan 2003 00:07:42 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h093diq00668; Wed, 8 Jan 2003 21:39:44 -0600 (CST) Date: Wed, 8 Jan 2003 22:28:48 -0600 Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: Application software needs to be "zeroconf-aware"? From: Ted Lemon To: Keith Moore Content-Transfer-Encoding: 7bit Message-Id: <465DE255-2390-11D7-8D1D-00039367340A@nominum.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > here's the sense in which it "cures" (or at least reduces) > the problem. > if the interfaces have to be explicitly configured > (i.e. explicit action is required on the part of the user before > the wireless interface is enabled) then the attacks can only be > made when the wireless interface is enabled This has nothing to do with link-local addressing - the same attack you propose for link-local is equally possible if the attacker just sets up a DHCP server. So although I think this is an issue, and indeed I think you're raising an important point here, it is not a link-local addressing issue - it is a general issue. And whether or not this draft advances will make zero difference in this case, because the cat is already out of the bag - wireless interfaces already use DHCP. I can already attack your computer in the way you've described, if it's not buttoned down. The current state of the art in Linux and MacOS X is to just firewall everything unless the user enables it. I think it would be quite worthwhile to write up an informational RFC explaining the issue and making recommendations. I think firewalling by default is probably sufficient, but if you don't agree, you should write your draft accordingly. I don't think this would be a zeroconf draft, though. > you don't need a WAP to have this problem, since wireless hosts can > talk directly to one another. Hm, that's true. Again, not a link-local addressing issue, but definitely a problem. > actually, it's the other way around. the burden is not on me to > explain every single security consideration of link local - it > is on the group to explain why link local meets the criteria for > proposed standard. and if more study is indeed required (as it > seems to be) then I fail to see how it can't be helpful to point > that out to people who don't seem to realize it. Well, but the point is that you have some valid security concerns that don't really relate specifically to link-local, and you appear to be trying to attach them as a rider to the link-local draft. Also, if this were a completely accurate statement, I have trouble imagining how _any_ draft could advance in the IETF. > what you seem to be saying is that because NATs exist and cause some > of the > same problems that link-local addresses do, that the criteria for > standardization > should be relaxed for link-local addresses. it's the other way around > - > neither NAT nor link-local is suitable for standardization because they > both cause problems. No, that's not what I'm saying. What I said, and you can read it in the archive, is that this is probably _not_ a problem for link-local, although it is a problem for NATs. Link-local and NAT are very different beasts. > 1. explicit configuration So someone puts a link-local address in a config file, and things don't work. This is a configuration error. Not our problem. > 2. gethostbyname (gethostname ()) This is indeed a problem if gethostname() returns a .local address. Link-local addresses don't get published in the global DNS, so this shouldn't be a problem in other cases. I'm not sure precisely where to state this, but I think you're right that it should be stated somewhere, possibly in this draft, that gethostname() and equivalent system calls should not return domain names in the "local" domain if the system has a global IP address. > 3. getpeername () to get peer's address and use it in a referral to > another host > (often used as a workaround for some NAT problmes) Okay, so someone connects to me using a link-local address, I have a link-local address, and I use getpeername() and publish the results in an internet-visible registry? Can you give me a specific example of when this would happen? Also, "a workaround for some NAT problems?" I thought you'd decided that we couldn't use NAT as a justification for saying that something is okay. So, using getpeername() and sending it to a third party to work around a NAT problem can't be used that way either. > 4. getsockname () We've already eliminated this as a potential source of problems. > 5. ioctl to get list of interfaces The ISC DHCP server uses this. So does ISC BIND. BIND uses these addresses to figure out on what IP addresses to listen, and to figure out if SOA records in zone files are referring to it. I don't think this would cause a problem in either case, unless the user mistakenly configured BIND to use If the ISC DHCP server were to see the link-local address as the first address, it would use it in the server-identifier option. Clients would not be able to renew their leases using unicast. Solution? Configure the DHCP server with an explicit IP address to use as a server identifier. Don't return the link-local address as the first address on the interface. Hack ISC DHCP to recognize the link-local class B and not use addresses from it. I think the latter is probably the correct solution. Does this mean that link-local breaks ISC DHCP? No. First, there's a workaround. Second, the way ISC DHCP handles multiply-homed addresses right now is fragile, and breaks quite frequently in firewall environments already. I suspect that other examples you could come up with where SIOCGIFCONF is used would be similar. Can you name an example where SIOCGIFCONF is really the right thing to do that isn't fragile already? > pvm does this. and no, it's not configurable in this way. Hm. Okay, this is an example. Is there some reason why pvm works this way? Does pvm try every address it gets from SIOCGIFCONF, or just the first? If it only tries the first, do you assert that this is correct behavior? You've made statements to the contrary, but as far as I know it is not the position of the IETF that all existing behavior is inherently sanctioned, and that no new RFC can ever break any existing behavior, no matter how broken it may be. Also, pvm is an open source product, currently under active development, at least according to the web page I just visited. So it beggars the imagination to think that if link-local were deployed, a complete fix could not be achieved in a matter of minutes. Now, there's probably some other application out there that also does this, and that would break if a link-local address were configured on an interface. Does this mean that this shouldn't go to p-s? I don't think so. I think the application is broken if it's assuming that when an API returns more than one IP address per interface, any one of those addresses is just as valid as any other. An application like this _must_ be configurable. > once upon a time I suggested that stacks respond to SIOGIFCONF in > such a way that LL addresses were unlikely to be mistaken for > ordinary addresses and unlikely to be used by apps that weren't > LL-aware. > the group refused to consider it. There isn't a single reference to that in the mailing list archive. > I am not trying to scuttle the draft, I'm trying to get it fixed. This is a touchy point. You have your idea of what "fixed" means. Others have their idea. For some, your "fixed" is their "scuttled." If the only output of this process that you consider valid is that every single point you've raised is addressed exactly as you have specified, then it may be difficult for you to participate in the rough consensus on this draft. From owner-zeroconf@merit.edu Thu Jan 9 02:11:56 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02230 for ; Thu, 9 Jan 2003 02:11:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1D3C991251; Thu, 9 Jan 2003 02:14:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DAF2791268; Thu, 9 Jan 2003 02:14: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 D0FAB91251 for ; Thu, 9 Jan 2003 02:14:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id B0FF65DE11; Thu, 9 Jan 2003 02:14:56 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from marsha.smtp.stsn.com (p249.n-sfpop03.stsn.com [199.107.154.249]) by segue.merit.edu (Postfix) with ESMTP id 77C675DDFC for ; Thu, 9 Jan 2003 02:14:56 -0500 (EST) Received: from [10.1.184.17] ([10.1.184.17]) by marsha.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 7 Jan 2003 23:17:20 -0800 User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 08 Jan 2003 23:14:49 -0800 Subject: Re: Application software needs to be "zeroconf-aware"? From: "John C. Welch" To: Message-ID: In-Reply-To: <200301090000.h0900gA22969@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Jan 2003 07:17:20.0390 (UTC) FILETIME=[FB8D4260:01C2B6E5] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 01/08/2003 16:00, "Keith Moore" wrote: >> When communicating an address to a far away host applications SHOULD check >> to make sure it's a public address before sending. > > the application has no way of knowing whether or not the host receiving > the referral is "far away" (or more precisely, within the same addressing > realm). > It can check *very* quickly to see if an address is a LL address or not. >> Second, due to the dynamic nature of both DHCP and LL self-assigned >> addresses, applications SHOULD perform late binding of network names to >> addresses and not exchange addresses at all. > > that's a gross overgeneralization. it works well for some applications, > not for others. DNS names are slow, they are sometimes ambiguous > (multiple names per host or multiple hosts sharing a single name) > and DNS lookup is far less reliable than IP routing. But, DNS is ubiquitous, and far easier for the Hu-mans, so why not use it. Besides, multiple names per host is not bad, not uncommon, and works fine. Multiple hosts per name is the same way. > > it never ceases to amaze me that so many people think they understand the > needs of the entire Internet well enough to make broad statements about > how everyone SHOULD write applications. It never ceases to amaze me throughout history how a small number of determined factionalists have been able to grind progress to a halt for amazingly long amount of time to promulgate pet religious wars. This of course explains every problem with Unix. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Jan 9 03:55:39 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04353 for ; Thu, 9 Jan 2003 03:55:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3198191283; Thu, 9 Jan 2003 03:58:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0124791287; Thu, 9 Jan 2003 03:58: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 CCF9C91283 for ; Thu, 9 Jan 2003 03:58:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id A46475DFC1; Thu, 9 Jan 2003 03:58:43 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta04bw.bigpond.com (mta04bw.bigpond.com [139.134.6.87]) by segue.merit.edu (Postfix) with ESMTP id 3C0FC5DFC0 for ; Thu, 9 Jan 2003 03:58:42 -0500 (EST) Received: from pc-00206 ([144.135.24.69]) by mta04bw.bigpond.com (Netscape Messaging Server 4.15 mta04bw Jul 16 2002 22:47:55) with SMTP id H8FVLQ00.5SV; Thu, 9 Jan 2003 18:58:38 +1000 Received: from CPE-203-51-31-46.nsw.bigpond.net.au ([203.51.31.46]) by bwmam01.mailsvc.email.bigpond.com(MailRouter V3.0n 8/20313487); 09 Jan 2003 18:58:38 From: Brad Hards To: Keith Moore , zeroconf@merit.edu Subject: Re: Application software needs to be "zeroconf-aware"? Date: Thu, 9 Jan 2003 19:45:15 +1100 User-Agent: KMail/1.4.5 References: <200301090015.h090FOA22996@astro.cs.utk.edu> In-Reply-To: <200301090015.h090FOA22996@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: <200301091945.15364.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 9 Jan 2003 11:15, Keith Moore wrote: > This is where I strongly disagree. The problem is that (the charter > notwithstanding) zeroconf's link-local proposal will affect all > networks, not just isolated networks, and the cases where link-local > causes problems are on networks that have external connectivity. It's > not acceptable for zeroconf to break operation of applications on > connected networks, and it's not acceptable for zeroconf to break > things and claim that they're somebody else's problem to fix. I think this is where we differ. _Anything_ that the zeroconf group can do can almost certainly be shown to modify the behaviour of at least one application. Some combination of protocol design (or protocol design error) and program design (or program design error) will ensure that this is the case. I don't care if that happens. I _DO_ care if major applications break. If specialist applications break, then don't run them and zeroconf at the same time. Zeroconf is a technology that can be run in major data centres, but the people with the specialist applications are the ones best able to handle the breakage and modify the configuration of the hosts/networks to compensate. I don't want gratuitous breakage. If there is going to be problems, then I'd like to know. After all, that is why I keep updating zcip to track the I-D - so that we can make an informed decision, including abandoning the current approach and working on an alternative (which might still cause breakage, but at an acceptable level). However the progression of zeroconf should be judged on the balance of the advantages and disadvantages, not just the absence of disadvantages. The social equity aspects of zeroconf are probably worth mentioning here: at the moment, ability to use the internet (or local network) is basically the domain of the technical elite. If we pass up the opportunity to make this type of technology more accessable, just so someone's computing cluster doesn't need to be modified, then that would be sad. It might even be unethical. We generally agree that transitioning to IPv6 is going to be painful. A lot of applications needed to be updated, and it has, does, and will continue to cause breakage. But we also agree that it is going to be worth it in the end. Zeroconf should be considered in the same way. Summary: if one (or a few) specialist applications breaking is going to stop progression of an IETF zeroconf solution, then the WG was never going to produce anything, and we should probably transition this to another organisation. We should _not_ give up. 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+HTabW6pHgIdAuOMRAsKHAKCv84zkErDS8Vgj1UCOIlsSaFntfwCfdoSv CH5k59iY3vdnKytm0gB/HwQ= =TKAx -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Thu Jan 9 05:31:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06387 for ; Thu, 9 Jan 2003 05:31:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6C83B91205; Thu, 9 Jan 2003 05:34:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 343A49122F; Thu, 9 Jan 2003 05:34: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 3439591205 for ; Thu, 9 Jan 2003 05:34:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1B8D35DFC7; Thu, 9 Jan 2003 05:34:21 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 953FE5DDFB for ; Thu, 9 Jan 2003 05:34:06 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h09AWCF28956; Thu, 9 Jan 2003 17:32:13 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h09AU2823827; Thu, 9 Jan 2003 21:30:03 +1100 (EST) From: Robert Elz To: Ted Lemon Cc: Erik Nordmark , Stuart Cheshire , zeroconf@merit.edu, Thomas Narten Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt In-Reply-To: <27AECC89-2389-11D7-8FB4-00039367340A@nominum.com> References: <27AECC89-2389-11D7-8FB4-00039367340A@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Jan 2003 17:30:02 +0700 Message-ID: <23825.1042108202@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 8 Jan 2003 22:16:41 -0600 From: Ted Lemon Message-ID: <27AECC89-2389-11D7-8FB4-00039367340A@nominum.com> | > So were you commenting on the probe or the announcement? | | The announcement. All DHCP clients that I know of do the reply | instead of the request - i.e., they're out of spec. :'} Ted, I am pretty sure you have read 2131 sometime or other, but as Erik noted, 2131 says to broadcast an ARP *reply* to announce a new address has been accepted. As you note, that is what all DHCP clients do. This is hardly surprising, as it is also what systems were doing to announce their use of an address from before DHCP existed (though, unfortunately for those of us who had to live through it, not from when ARP was first invented). So, what's out of spec, other than the acd draft? (In theory, if everyone did ARP exactly as specified, the request should also suffice instead of a reply (though it is a perverse kind of "request") - but in practice, ARP implementations don't tend to conform exactly to the spec, sending ARP reply (unsolicited reply) works...) kre From owner-zeroconf@merit.edu Thu Jan 9 07:07:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07531 for ; Thu, 9 Jan 2003 07:07:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CF3689122F; Thu, 9 Jan 2003 07:10:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90CF591253; Thu, 9 Jan 2003 07:10: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 98F589122F for ; Thu, 9 Jan 2003 07:10:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7534A5E080; Thu, 9 Jan 2003 07:10:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id B47D25E07D for ; Thu, 9 Jan 2003 07:10:46 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h09C9oF07926; Thu, 9 Jan 2003 19:09:51 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h09C6N824287; Thu, 9 Jan 2003 23:06:26 +1100 (EST) From: Robert Elz To: Brad Hards Cc: Keith Moore , zeroconf@merit.edu Subject: Re: Application software needs to be "zeroconf-aware"? In-Reply-To: <200301091945.15364.bhards@bigpond.net.au> References: <200301091945.15364.bhards@bigpond.net.au> <200301090015.h090FOA22996@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 09 Jan 2003 19:06:23 +0700 Message-ID: <24285.1042113983@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 9 Jan 2003 19:45:15 +1100 From: Brad Hards Message-ID: <200301091945.15364.bhards@bigpond.net.au> | If specialist applications break, then don't run them and zeroconf at | the same time. I think you'll find that this is exactly what Keith wants (leaping to conclusions here). The issue is that as currently defined, the only way to "not run them and zeroconf at the same time" is to "not run them". That is, zeroconf is on and stays on always, and there's no way to make it go away - as defined. What Keith has been requesting (one of the things anyway) is that there be some nice (relatively) easy way to turn zeroconf off, so it is actually possible to run applications which may have problems with the existence of zeroconf addresses. As I understand them, the existing implementations work exactly that way anyway - they only configure zeroconf addresses if no other addresses are available (that is, generally, if dhcp is enabled, and fails). The WG is insisting that this be altered, and LL addresses always be configured, and never disabled. That's one of the major issues. kre From owner-zeroconf@merit.edu Thu Jan 9 07:23:36 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07826 for ; Thu, 9 Jan 2003 07:23:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4C99891253; Thu, 9 Jan 2003 07:26:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FD8691287; Thu, 9 Jan 2003 07:26: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 1657491253 for ; Thu, 9 Jan 2003 07:26:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id F20DE5E054; Thu, 9 Jan 2003 07:26:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 950A15DFC6 for ; Thu, 9 Jan 2003 07:26:40 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 6B01259959; Thu, 9 Jan 2003 09:37:53 +0000 (GMT) Message-ID: <02d201c2b7c2$d73ef100$131010ac@aldebaran> From: "Philip Nye" To: "Colin Perkins" , "Zeroconf Working Group" References: <200301090016.h090GFq27909@chiron.nge.isi.edu> Subject: Re: Application software needs to be "zeroconf-aware"? Date: Thu, 9 Jan 2003 09:38:17 -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: "Colin Perkins" > > >Are there other examples of scoped addresses of this nature where there > >isn't a single obvious restricted point of contact between networks (the NAT > >gateway)? You could cite the use of other unroutable networks (10.x.x.x etc) > >but are these commonly run concurrently with global addresses on multihomed > >hosts? If so how are the problems solved? > > Scoped IPv4 multicast addresses have the same issues, and cause the same > sorts of problems when trying to invite a client to join a multicast > session. This is interesting as I am developing applications which will make heavy use of multicast. In this instance the multicast scope is very much manually configured and generally the scoping will be managed to take account of the applications being run. Also, is it not the case that the application (or at least the multicast address allocation mechanism) will nearly always be scope aware? The thing about zeroconf is that as proposed, it will be deployed by default without users really being aware of it and as the referral example has shown, the fact that the stack is LL-aware will not prevent breakage. There is a demonstrated failure mode here which so far as I can see is unique to LL or at least severely aggravated by it. Users may be in a position where either there application will not work (LL turned on) or they will not be able to talk to their printer (LL turned off) - and making the choice is a manual configuration option! As Brad Hards' message said, this is not to say that the benefits do not outweigh the disadvantages - I do not have much sense of the scale of the problem in terms of the prevalence of the sort of application which will break and the chances of these applications being updated. Philip Nye From owner-zeroconf@merit.edu Thu Jan 9 07:41:00 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08024 for ; Thu, 9 Jan 2003 07:41:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8F18391287; Thu, 9 Jan 2003 07:44:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 547ED9128B; Thu, 9 Jan 2003 07: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 15DC291287 for ; Thu, 9 Jan 2003 07:44:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id E3C095E086; Thu, 9 Jan 2003 07:44:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by segue.merit.edu (Postfix) with ESMTP id B549B5DFC6 for ; Thu, 9 Jan 2003 07:44:04 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18Wc2U-0006Wv-00; Thu, 09 Jan 2003 04:44:02 -0800 Date: Thu, 9 Jan 2003 07:41:07 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Application software needs to be "zeroconf-aware"? Message-Id: <20030109074107.508ee5c1.moore@cs.utk.edu> In-Reply-To: <465DE255-2390-11D7-8D1D-00039367340A@nominum.com> References: <465DE255-2390-11D7-8D1D-00039367340A@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Wed, 8 Jan 2003 22:28:48 -0600 Ted Lemon wrote: > > here's the sense in which it "cures" (or at least reduces) > > the problem. > > > if the interfaces have to be explicitly configured > > (i.e. explicit action is required on the part of the user before > > the wireless interface is enabled) then the attacks can only be > > made when the wireless interface is enabled > > This has nothing to do with link-local addressing - the same attack you > propose for link-local is equally possible if the attacker just sets up > a DHCP server. well it *does* have to do with link-local addressing, because link-local addressing is one of the means by which a wireless interface may be automatically configured. it also has to do with DHCP. the fact that DHCP also causes the problem does not relieve zeroconf of the burden of documenting the problem that is associated with link-local and/or providing a workaround for when link-local addressing causes the problem. yes, similar workarounds are also needed for DHCP - but that's not zeroconf's problem. zeroconf can't avoid doing needed work by saying "but DHCP hasn't done that work either!!!" > So although I think this is an issue, and indeed I > think you're raising an important point here, it is not a link-local > addressing issue - it is a general issue. And whether or not this > draft advances will make zero difference in this case, because the cat > is already out of the bag - wireless interfaces already use DHCP. I > can already attack your computer in the way you've described, if it's > not buttoned down. bottom line is this is a problem. does zeroconf want to be part of the solution or do they want to claim that someone else has to solve a problem that they're contributing to? > > 1. explicit configuration > > So someone puts a link-local address in a config file, and things don't > work. This is a configuration error. Not our problem. I'd say that the most that zeroconf can do is to document it. But this isn't a big problem, arguably the current draft already provides adequate documentation. > > 2. gethostbyname (gethostname ()) > > This is indeed a problem if gethostname() returns a .local address. which it does on my mac, even though I've tried to turn Rendezvous off, and there doesn't seem to be any way to get it to stop doing so. > > 3. getpeername () to get peer's address and use it in a referral to > > another host > > (often used as a workaround for some NAT problmes) > > Okay, so someone connects to me using a link-local address, I have a > link-local address, and I use getpeername() and publish the results in > an internet-visible registry? it doesn't have to be a separate registry - all that is needed is to pass the address for referral within the app. > I thought you'd decided that we couldn't use NAT as a justification for > saying that something is okay. So, using getpeername() and sending it > to a third party to work around a NAT problem can't be used that way > either. it's perfectly legitimate to use getpeername() to obtain an address, and to pass that address to another host, whether or not there is a NAT involved. I just think it's interesting that a technique that is used as a workaround to a problem caused by NATs (which use scoped addresses) ends up causing other problems for link-local (which uses scoped addresses). > > 4. getsockname () > > We've already eliminated this as a potential source of problems. > > > 5. ioctl to get list of interfaces you're trying to argue about specific pieces of software. I don't believe it is reasonable to say that just because a workaround exists for say BIND, that all software that uses SIOCGIFCONF should have to provide that workaround. I don't believe it's reasonable for zeroconf to impose that burden on all users of software that uses SIOCGIFCONF to generate addresses for referrals. It's not reasonable for zeroconf to cause problems and then claim that they're somebody else's problems to fix. > > once upon a time I suggested that stacks respond to SIOGIFCONF in > > such a way that LL addresses were unlikely to be mistaken for > > ordinary addresses and unlikely to be used by apps that weren't > > LL-aware. > > the group refused to consider it. > > There isn't a single reference to that in the mailing list archive. I might not have mentioned SIOCGIFCONF by name. > > I am not trying to scuttle the draft, I'm trying to get it fixed. > > This is a touchy point. You have your idea of what "fixed" means. > Others have their idea. For some, your "fixed" is their "scuttled." My idea of "fixed" would leave link-local fully functional for ad hoc networks - the purpose for which this group was chartered. For this group to insist on extra functionality for link local which is far beyond the charter of this group and which has several known problems is not only a violation of the criteria for proposed standard, it's also a gross violation of process. > If the only output of this process that you consider valid is that > every single point you've raised is addressed exactly as you have > specified, then it may be difficult for you to participate in the rough > consensus on this draft. rough consensus is not the issue. meeting proposed standard criteria is the issue. From owner-zeroconf@merit.edu Thu Jan 9 08:01:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08439 for ; Thu, 9 Jan 2003 08:01:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6E8EC9128B; Thu, 9 Jan 2003 08:04:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 380549129D; Thu, 9 Jan 2003 08:04: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 11BF09128B for ; Thu, 9 Jan 2003 08:04:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id E8EB05E086; Thu, 9 Jan 2003 08:04:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by segue.merit.edu (Postfix) with ESMTP id C7DCC5E076 for ; Thu, 9 Jan 2003 08:04:45 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18WcMU-0004DT-00; Thu, 09 Jan 2003 05:04:42 -0800 Date: Thu, 9 Jan 2003 08:01:50 -0500 From: Keith Moore To: Brad Hards Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Application software needs to be "zeroconf-aware"? Message-Id: <20030109080150.67c4b3f0.moore@cs.utk.edu> In-Reply-To: <200301091945.15364.bhards@bigpond.net.au> References: <200301090015.h090FOA22996@astro.cs.utk.edu> <200301091945.15364.bhards@bigpond.net.au> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > _Anything_ that the zeroconf group can do can almost certainly be shown to > modify the behaviour of at least one application. Some combination of > protocol design (or protocol design error) and program design (or program > design error) will ensure that this is the case. but if the design error is on the part of the zeroconf working group, we don't give a damn... it's the applications/protocol designers' fault for assuming that IP would work like it was designed to work. > I don't care if that happens. frankly, I don't care that you think that zeroconf has the right to break any applications it wants to. I'm going to do my best to stop it from doing so. > Summary: if one (or a few) specialist applications breaking is going to stop > progression of an IETF zeroconf solution, then the WG was never going to > produce anything, and we should probably transition this to another > organisation. We should _not_ give up. it's not within the purview of this group to decide which applications it's okay to break. zeroconf is NOT chartered to change the Internet architecture. if this group can't stay within its charter, then it needs to be shut down. actually it should have been shut down a long time ago. the reason that it's difficult to do so is that it's within episilon of producing something useful - and it could do so if it weren't hell-bent on causing problems for others. Keith From owner-zeroconf@merit.edu Thu Jan 9 08:03:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08524 for ; Thu, 9 Jan 2003 08:03:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2B8F19129D; Thu, 9 Jan 2003 08:06:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF381912A0; Thu, 9 Jan 2003 08:06: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 B6B1B9129D for ; Thu, 9 Jan 2003 08:06:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9E1B35E086; Thu, 9 Jan 2003 08:06:54 -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 4F08E5DE5D for ; Thu, 9 Jan 2003 08:06:54 -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 GAA06711 for ; Thu, 9 Jan 2003 06:06:48 -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 h09D6jl10599; Thu, 9 Jan 2003 14:06:46 +0100 (MET) Date: Thu, 9 Jan 2003 14:06:44 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Cc: Erik Guttman Subject: ZEROCONF WG Work Items Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Folks, We have to complete work on the IPv4 LL document. There are a few outstanding issues in front of us. Please turn your attention to addressing the continuing IESG concerns. Note: Keith has made his point, repeatedly, that due to application interoperability considerations there should be a way to simply and effectively deactiveate v4LL. The IESG has this input. The WG has chosen not to accept Keith's argument in their submission to the IESG. It is up to the the IESG to determine how to proceed. So far, the IESG has not chosen to include the lack of a required mechanism to deactivate v4LL behavior as one of their considerations for the WG to address in order to advance the document. This is why this issue does not appear in the following list. Please let's focus on bringing the following questions to conclusion. I strongly suggest that discussion participants SUGGEST TEXT or send comments ON SPECIFIC TEXT. 1. What should the TTL be set to on send? Should the TTL be checked on receive? We have been over this repeatedly. My capsule summary of the debate is: o Existing implementations set TTL to 255 and 128 o Some existing implementations check 255 on receive and discard TTL != 255 o There is some security benefit to checking TTL=255 but we have not reached a consensus on what the value is and its importance o Many routers are not configured to not forward v4LL. Setting TTL=1 would mean these routers would not forward v4LL off the link. The current document says MUST send TTL=255, MAY reject if TTL != 255. 2. There was a request for a list of example applications which can safely be used with link-local addresses. I supplied the following list: File sharing (NFS, SMB), Print sharing (LPD, IPP), Local file sharing & web browsing (FTP, HTTP), Remote login (TELNET) This raised questions which I have not had the time, and lack enough expertise to answer: o Doesn't NFSv3 include addresses? Will that cause NFSv3 to fail? o Doesn't NFSv4 and IPP carry domain names? DNS will not have LL entries, most likely. Won't this cause NFSv4 and IPP to fail? 3. Section 2.10 is not sufficiently draconian, Harald submits. It should list a set of protocols which will fail if a link local address is sent in a protocol message instead of a global address. To discuss FTP, DNS, NFS, IPsec using IPv4 as an identifier, BGP, OSPF, RTP, ... 4. There is text in section 2.3 which suggests shorter time outs can be used for 802 media. I suggested some new, less specific text which Erik Nordmark had continuing issues with. > The time values specified above are intended for use on > technologies such as Ethernet, where switches that implement > Spanning Tree [802.1d] often silently discard all packets for > several seconds. The time values specified above result in a > delay of 8-10 seconds before a chosen IP address may be used. > For a desktop machine on Ethernet, > >FWIW when 802.1d is enabled on the port I plug in my laptop at the >office, the delay before the switch starts forwarding packets is 45 >seconds. (I think the 802.1d spec indicates a default time of around >30 seconds.) So 10 seconds don't seem to do much good. Later, Erik sent If we talk about the protocol and not the text, I know of two interesting cases on IEEE 802 media: 1. No spanning tree on the port to which you connect, or the port has been enabled for a long time before the address claim is done. In this case it probably makes sense to have slightly shorter timers i.e. a few packets over a few seconds might suffice. Thus 3 seconds instead of 8. 2. Spanning tree on the port to which you connect. If the address claim is done immediately after bringing up the link the host might as well wait for 45 seconds before sending any packet. I don't know if the host can tell the difference between #1 and #2 - or if it can "ask" (at the Ethernet layer) if the switch is running STP. With RSTP I think the problem goes away and the approach used in #1 can be used. 5. Add the following notes to the security section: NOTE: The existence of local links without physical security, such as LANs with attached wireless base stations, means that expecting all local links to be secure enough that normal precautions can be dispensed with is an extremely dangerous practice, which will expose users to considerable risks. 6. The following text leads to a problem > section 3.3 > In addition, this kind of host should probe for, and defend, all > of its link-local addresses on all of its active interfaces that > are using link-local addresses. > > When bringing up a new interface, the host SHOULD first probe > for all of its existing link-local addresses on that new interface. > If any of the addresses are found to be already in use by some > other host on that new link, then the interfaces in question MUST > be reconfigured to select new unique link-local addresses. > > The host should then select a link-local address for the new > interface, and probe on all of its active interfaces to verify > that this new address is unique on all the links that the host > has connections to. Erik Nordmark remarked: > The above breaks if multiple interfaces on the host are connected > to the same link. It also isn't clear to me why this is needed; > presumably the interfaces can be managed indepdently as long as > the host ensures that it doesn't assign the same link-local > address to more than one interface. 7. There is a security and operational consideration regarding the goal of harmonizing link-local address configuration between links of a multi-homed host. In particular, if a host attempts to configure the same v4LL address on all interfaces, an attacker can force the host to reconfigure all its interfaces by usurping the address on any link. This is an attack above and beyond the normal ARP based spoofing or DOS attacks since it effects multiple links. The suggested changed text for the security section follows. (The change bar indicates added text). 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. 8. The applications considerations section was deemed inadeqate. > > 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? Erik Nordmark replied 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 - 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. - Warnings about limitations of the applicability makes sense up front in the document - not towards the end. The document does not suggest that one use v4LL source addresses to communicate with v4LL destination addresses. There are failure modes: Send to a global multicast address from a v4LL address, Send to a global address from a v4LL address, send to a v4LL address from a global address. In each case, if routers are misconfigured, the receiver will potentially not be able to return a message to the sender. This could be addressed by a requirement, for example, such as to send to a v4LL address one MUST send from a v4LL address, and to send from a v4LL address, one MUST send to a v4LL address. This is highly restrictive and is only posted to spur conversation. If we do not restrict v4LL, however, we must meet address scope architecture issues head on. 9. The document does not suggest that one use v4LL source addresses to communicate with v4LL destination addresses. There are failure modes: Send to a global multicast address from a v4LL address, Send to a global address from a v4LL address, send to a v4LL address from a global address. In each case, if routers are misconfigured, the receiver will potentially not be able to return a message to the sender. This could be addressed by a requirement, for example, such as to send to a v4LL address one MUST send from a v4LL address, and to send from a v4LL address, one MUST send to a v4LL address. This is highly restrictive and is only posted to spur conversation. If we do not restrict v4LL, however, we must meet address scope architecture issues head on. Thanks and best regards, Erik ZEROCONF WG cochair From owner-zeroconf@merit.edu Thu Jan 9 08:08:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08564 for ; Thu, 9 Jan 2003 08:08:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B11F6912A0; Thu, 9 Jan 2003 08:11:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7885E912A2; Thu, 9 Jan 2003 08:11: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 544C6912A0 for ; Thu, 9 Jan 2003 08:11:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3EDC55E086; Thu, 9 Jan 2003 08:11:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by segue.merit.edu (Postfix) with ESMTP id 1D7225DE5D for ; Thu, 9 Jan 2003 08:11:39 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18WcTA-00051u-00; Thu, 09 Jan 2003 05:11:37 -0800 Date: Thu, 9 Jan 2003 08:08:45 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Application software needs to be "zeroconf-aware"? Message-Id: <20030109080845.190a2862.moore@cs.utk.edu> In-Reply-To: References: <200301090000.h0900gA22969@astro.cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Wed, 08 Jan 2003 23:14:49 -0800 "John C. Welch" wrote: > On 01/08/2003 16:00, "Keith Moore" wrote: > > >> When communicating an address to a far away host applications SHOULD check > >> to make sure it's a public address before sending. > > > > the application has no way of knowing whether or not the host receiving > > the referral is "far away" (or more precisely, within the same addressing > > realm). > > > > It can check *very* quickly to see if an address is a LL address or not. the problem with this strategy is that you cannot do referrals between local hosts via a third party that isn't on the local link. e.g. you can't have a netsolve agent on a remote link mediating between a client and a server that happen to be on the same link and using LL addresses. > >> Second, due to the dynamic nature of both DHCP and LL self-assigned > >> addresses, applications SHOULD perform late binding of network names to > >> addresses and not exchange addresses at all. > > > > that's a gross overgeneralization. it works well for some applications, > > not for others. DNS names are slow, they are sometimes ambiguous > > (multiple names per host or multiple hosts sharing a single name) > > and DNS lookup is far less reliable than IP routing. > > But, DNS is ubiquitous no it's not. > , and far easier for the Hu-mans, so why not use it. because you want your app to work quickly and reliably. > Besides, multiple names per host is not bad, not uncommon, and works fine. > Multiple hosts per name is the same way. it means that just because a DNS name is associated with a host, does not mean that you can use the DNS name to reliably reach that host. you might end up reaching a different host than the one which has the process you need to talk to. > > it never ceases to amaze me that so many people think they understand the > > needs of the entire Internet well enough to make broad statements about > > how everyone SHOULD write applications. > > It never ceases to amaze me throughout history how a small number of > determined factionalists have been able to grind progress to a halt for > amazingly long amount of time to promulgate pet religious wars. breaking the IP architecture is not progress. Keith From owner-zeroconf@merit.edu Thu Jan 9 09:15:18 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10453 for ; Thu, 9 Jan 2003 09:15:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D4D7F91252; Thu, 9 Jan 2003 09:18:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A48E5912A4; Thu, 9 Jan 2003 09:18:24 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB2DD91252 for ; Thu, 9 Jan 2003 09:18:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id CAC115E086; Thu, 9 Jan 2003 09:18:07 -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 91E225DDC2 for ; Thu, 9 Jan 2003 09:18:06 -0500 (EST) Received: from pc-00206 ([144.135.25.75]) by mta03ps.bigpond.com (Netscape Messaging Server 4.15 mta03ps Jul 16 2002 22:47:55) with SMTP id H8GAE300.EKH; Fri, 10 Jan 2003 00:18:03 +1000 Received: from CPE-203-51-31-46.nsw.bigpond.net.au ([203.51.31.46]) by PSMAM03.mailsvc.email.bigpond.com(MailRouter V3.0n 89/23249644); 10 Jan 2003 00:18:03 From: Brad Hards To: Keith Moore Subject: Re: Application software needs to be "zeroconf-aware"? Date: Fri, 10 Jan 2003 01:04:39 +1100 User-Agent: KMail/1.4.5 Cc: zeroconf@merit.edu References: <200301090015.h090FOA22996@astro.cs.utk.edu> <200301091945.15364.bhards@bigpond.net.au> <20030109080150.67c4b3f0.moore@cs.utk.edu> In-Reply-To: <20030109080150.67c4b3f0.moore@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: <200301100104.39344.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 10 Jan 2003 00:01, Keith Moore wrote: > > _Anything_ that the zeroconf group can do can almost certainly be shown > > to modify the behaviour of at least one application. Some combination of > > protocol design (or protocol design error) and program design (or program > > design error) will ensure that this is the case. > > but if the design error is on the part of the zeroconf working group, > we don't give a damn... it's the applications/protocol designers' fault > for assuming that IP would work like it was designed to work. I certainly care a great deal. Enough to publish and maintain an implementation of part of the technology that we are currently studying. > > I don't care if that happens. > > frankly, I don't care that you think that zeroconf has the right to break > any applications it wants to. I'm going to do my best to stop it from > doing so. You have (apparently deliberately) quoted me out of context. What I actually said, in part, was: "I don't care if that happens. I _DO_ care if major applications break.". The part you have quoted is in relation to "at least one application". For the absence of doubt, I do not think that it is OK to cause gratitous breakage, but if breaking one specialist application (that is probably broken in other common networking scenarios) is the cost of enabling IP networking to people who couldn't otherwise have it, then that is a reasonable cost. > > Summary: if one (or a few) specialist applications breaking is going to > > stop progression of an IETF zeroconf solution, then the WG was never > > going to produce anything, and we should probably transition this to > > another organisation. We should _not_ give up. > > it's not within the purview of this group to decide which applications > it's okay to break. zeroconf is NOT chartered to change the Internet > architecture. It is absolutely within the purview of this group to change the Internet architecture. If we can't change anything, then how can we progress anything? That progress may come at the cost of maintenance on some applications, that have been programmed with certain assumptions that are not true in general on the Internet as it currently exists. That maintenance is worth avoiding, if we can avoid it, but I repeat my argument: If you think you can make enough changes (whatever they might be), and not have anyone notice that something new is happening, then I think further discussion is unlikely to be productive. > if this group can't stay within its charter, then it needs to be shut down. > > actually it should have been shut down a long time ago. the reason that > it's difficult to do so is that it's within episilon of producing something > useful - and it could do so if it weren't hell-bent on causing problems > for others. If you have specific proposals, please, please, please make them. I am not saying that the current stuff we have is the right answer. I am quite willing to keep working on zeroconf, because I'd like for people like my Mum and Dad to be able to use a computer one day. I owe it to them, and lots of other people like them, to make that computer use as easy as possible, and maintaining the status quo is unacceptable to me. I think what we have is a much better than the current alternatives of requiring network managment in all cases, and that the advantages outweigh the theoretical problems, as we currently understand them. There might be better options. If someone proposes an alternative, I'll work on that too. 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+HYF3W6pHgIdAuOMRAmGKAJwI8v2sz3uZz4+AURFEn6jb5PrdxwCgm9cZ MWR6EcLwezZXflGhFq3rslc= =N+Fm -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Thu Jan 9 09:22:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10615 for ; Thu, 9 Jan 2003 09:22:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EDD0E912A4; Thu, 9 Jan 2003 09:25:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B93F3912A6; Thu, 9 Jan 2003 09:25:10 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD607912A4 for ; Thu, 9 Jan 2003 09:25:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 864085E08E; Thu, 9 Jan 2003 09:25:09 -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 10FDF5DDC2 for ; Thu, 9 Jan 2003 09:25:08 -0500 (EST) Received: from pc-00206 ([144.135.24.78]) by mta01bw.bigpond.com (Netscape Messaging Server 4.15 mta01bw Jul 16 2002 22:47:55) with SMTP id H8GAPS00.B9A; Fri, 10 Jan 2003 00:25:04 +1000 Received: from CPE-203-51-31-46.nsw.bigpond.net.au ([203.51.31.46]) by bwmam04.mailsvc.email.bigpond.com(MailRouter V3.0n 35/22373732); 10 Jan 2003 00:26:35 From: Brad Hards To: Robert Elz Subject: Re: Application software needs to be "zeroconf-aware"? Date: Fri, 10 Jan 2003 01:11:40 +1100 User-Agent: KMail/1.4.5 Cc: Keith Moore , zeroconf@merit.edu References: <200301091945.15364.bhards@bigpond.net.au> <200301090015.h090FOA22996@astro.cs.utk.edu> <24285.1042113983@munnari.OZ.AU> In-Reply-To: <24285.1042113983@munnari.OZ.AU> 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: <200301100111.40304.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 9 Jan 2003 23:06, Robert Elz wrote: > What Keith has been requesting (one of the things anyway) is that there be > some nice (relatively) easy way to turn zeroconf off, so it is actually > possible to run applications which may have problems with the existence of > zeroconf addresses. I think that if there is going to be some breakage, then we definately need to be able to disable zeroconf on a host-by-host basis. My recollection of Keith's request was actually that you can disable it on a network basis. That is clearly a DoS waiting to happen, and I can't concur. There is no precedent (for example, you can't stop all DHCP servers on a network basis) and it is unwarranted, given the likely level of breakage (minor) and the environment in which it is likely to occur (managed networks). Indeed, even if you can disable zeroconf address assignment on an per-network basis, you will still likely need to perform some "per-host" configuration to enable that machine to communicate in any case. Again, for the absence of doubt, concur that we should provide the ability to disable zeroconf address assignment, on a per-host (and perhaps, per-interface) basis. 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+HYMcW6pHgIdAuOMRAn3sAKCXS18W4nC+3K1fClPyvpOA5K64QgCgrV6W iZqgju6tDnY54zuFOweMbo0= =01H7 -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Thu Jan 9 12:26:48 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18378 for ; Thu, 9 Jan 2003 12:26:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 93D66912AA; Thu, 9 Jan 2003 12:29:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 614C2912AB; Thu, 9 Jan 2003 12:29: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 682FB912AA for ; Thu, 9 Jan 2003 12:29:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3963E5E09E; Thu, 9 Jan 2003 12:29:53 -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 DE2EB5DDA6 for ; Thu, 9 Jan 2003 12:29:52 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h09HRbP00535; Thu, 9 Jan 2003 11:27:39 -0600 (CST) Date: Thu, 9 Jan 2003 11:29:44 -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 v551) Cc: Thomas Narten , zeroconf@merit.edu, Stuart Cheshire , Erik Nordmark To: Robert Elz From: Ted Lemon In-Reply-To: <23825.1042108202@munnari.OZ.AU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Ted, I am pretty sure you have read 2131 sometime or other, but as Erik > noted, 2131 says to broadcast an ARP *reply* to announce a new address > has been accepted. As you note, that is what all DHCP clients do. Oy. I've read that text several times in the past couple of weeks, but for some reason I still got it backwards. Sorry about that. From owner-zeroconf@merit.edu Thu Jan 9 15:43:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25691 for ; Thu, 9 Jan 2003 15:43:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 05ECF912AF; Thu, 9 Jan 2003 15:46:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB5C7912B0; Thu, 9 Jan 2003 15:46: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 B5581912AF for ; Thu, 9 Jan 2003 15:46:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9C80B5DE58; Thu, 9 Jan 2003 15:46:46 -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 2F5AD5DE47 for ; Thu, 9 Jan 2003 15:46:46 -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 PAA11550 for ; Thu, 9 Jan 2003 15:46:41 -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 PAA06942 for ; Thu, 9 Jan 2003 15:46:41 -0500 (EST) Received: from [216.89.14.18] (mw-14-18.ny.shownets.net [216.89.14.18] (may be forged)) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA22241 for ; Thu, 9 Jan 2003 15:46:40 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 09 Jan 2003 12:46:38 -0800 Subject: Re: Application software needs to be "zeroconf-aware"? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030109080150.67c4b3f0.moore@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 01/09/2003 05:01, "Keith Moore" wrote: > it's not within the purview of this group to decide which applications > it's okay to break. zeroconf is NOT chartered to change the Internet > architecture. > > if this group can't stay within its charter, then it needs to be shut down. > > actually it should have been shut down a long time ago. the reason that > it's difficult to do so is that it's within episilon of producing something > useful - and it could do so if it weren't hell-bent on causing problems > for others. > I totally agree...please pick your jaws up off the ground, it's not for the same reason. Zeroconf is important, but more on an enabling/social level than on a technological one. We don't need it. But people, (you know, they buy computers, use AOL, send pictures to grammy, and don't give a rat's patoot how it happens, but DO hate the work involved to do it) DO need this. I've come to the conclusion that the IETF is utterly and absolutely incapable of doing anything for anyone who is not a geek. This is just the way things are. Apple/Microsoft/IBM and others *are* able to do things for people who aren't geeks, and I really now firmly believe that they are far better off telling this group and the IETF to pound sand when talking about anything that isn't for geeks. This of course may change, but that would require a too-large sublimation of ego and pet causes for me to believe that it will prior to the invention of faster-than-light travel, or the Cubs beating the Red Sox in the World Series in a 4-game shutout. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Jan 9 15:47:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25829 for ; Thu, 9 Jan 2003 15:47:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1F929912B0; Thu, 9 Jan 2003 15:50:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB1CB912B1; Thu, 9 Jan 2003 15:50:48 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C10BD912B0 for ; Thu, 9 Jan 2003 15:50:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9AB0D5DDC2; Thu, 9 Jan 2003 15:50:47 -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 323FE5DD97 for ; Thu, 9 Jan 2003 15:50:47 -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 PAA09956 for ; Thu, 9 Jan 2003 15:50:46 -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 PAA07867 for ; Thu, 9 Jan 2003 15:50:46 -0500 (EST) Received: from [216.89.14.18] (mw-14-18.ny.shownets.net [216.89.14.18] (may be forged)) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA24157 for ; Thu, 9 Jan 2003 15:50:45 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 09 Jan 2003 12:50:44 -0800 Subject: Re: ZEROCONF WG Work Items 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 01/09/2003 05:06, "Erik Guttman" wrote: > > 1. What should the TTL be set to on send? Should the TTL be > checked on receive? > > We have been over this repeatedly. My capsule summary of the > debate is: > o Existing implementations set TTL to 255 and 128 > o Some existing implementations check 255 on receive and > discard TTL != 255 > o There is some security benefit to checking TTL=255 but > we have not reached a consensus on what the value is > and its importance > o Many routers are not configured to not forward v4LL. > Setting TTL=1 would mean these routers would not forward > v4LL off the link. > > The current document says MUST send TTL=255, MAY reject if > TTL != 255. The current document looks like the most elegant and safe method. > > 5. Add the following notes to the security section: > > NOTE: The existence of local links without physical security, > such as LANs with attached wireless base stations, means that > expecting all local links to be secure enough that normal > precautions can be dispensed with is an extremely dangerous > practice, which will expose users to considerable risks. This is very wise to include...perhaps accentuate this even more. > 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. Works for me. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Jan 9 15:54:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25980 for ; Thu, 9 Jan 2003 15:54:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2FAFA912B2; Thu, 9 Jan 2003 15:57:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1474912B1; Thu, 9 Jan 2003 15:57: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 F286A912B2 for ; Thu, 9 Jan 2003 15:57:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA3625DE63; Thu, 9 Jan 2003 15:57:25 -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 708B25DDC2 for ; Thu, 9 Jan 2003 15:57:25 -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 PAA13229 for ; Thu, 9 Jan 2003 15:57:24 -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 PAA09055 for ; Thu, 9 Jan 2003 15:57:24 -0500 (EST) Received: from [216.89.14.18] (mw-14-18.ny.shownets.net [216.89.14.18] (may be forged)) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA27152 for ; Thu, 9 Jan 2003 15:57:23 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 09 Jan 2003 12:57:22 -0800 Subject: Re: Application software needs to be "zeroconf-aware"? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030109080845.190a2862.moore@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 01/09/2003 05:08, "Keith Moore" wrote: >> But, DNS is ubiquitous > > no it's not. I bet I can find more DNS use than people not using it. He with the most toys wins. > >> , and far easier for the Hu-mans, so why not use it. > > because you want your app to work quickly and reliably. So far so good...this seems to be how the internet progressed anyway. I imagine all the NCP people were pretty pissed that TCP/IP broke a lot of stuff...would you rather have stayed with NCP to avoid any possibility of harm > >> Besides, multiple names per host is not bad, not uncommon, and works fine. >> Multiple hosts per name is the same way. > > it means that just because a DNS name is associated with a host, does not > mean that you can use the DNS name to reliably reach that host. you > might end up reaching a different host than the one which has the > process you need to talk to. That's called load balancing. It's a good thing. There are ways of course to avoid errors in this area. If you have a proper DNS setup, then the load balancing service knows what is running on what machine. This of course is a meaningless argument, which has nothing to do with anything zeroconf - related. >> It never ceases to amaze me throughout history how a small number of >> determined factionalists have been able to grind progress to a halt for >> amazingly long amount of time to promulgate pet religious wars. > > breaking the IP architecture is not progress. Neither is keeping Networking solely in the hands of the high priests of the orthodoxy, just so they can feel superior. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Jan 9 15:55:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26022 for ; Thu, 9 Jan 2003 15:55:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 82F4D912B1; Thu, 9 Jan 2003 15:58:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 54822912B3; Thu, 9 Jan 2003 15:58: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 20095912B1 for ; Thu, 9 Jan 2003 15:58:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id F06545DDC2; Thu, 9 Jan 2003 15:58:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from www.mediatonic.com (dsl093-188-237.sfo2.dsl.speakeasy.net [66.93.188.237]) by segue.merit.edu (Postfix) with ESMTP id B4E335DD97 for ; Thu, 9 Jan 2003 15:58:36 -0500 (EST) Received: from mediatonic.com (unknown [192.168.12.2]) by www.mediatonic.com (Postfix) with ESMTP id 97641102666; Thu, 9 Jan 2003 12:58:35 -0800 (PST) Date: Thu, 9 Jan 2003 13:00:03 -0800 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) Cc: Zeroconf To: "John C. Welch" From: james mcmurry In-Reply-To: Message-Id: <532DFC45-2415-11D7-A601-000393681A12@mediatonic.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hear Hear. BUT (there always is...) Apple/Microsoft/IBM/EtAl drive what they perceive their customers want (and what will bring the greatest $$ to themselves), and damn the rest of the world. So the IETF (and all of us geeks) do have an important role to play in balancing the standards for everyone (including non-geeks and my Grandma ) We also need this viscous discussion, to ensure we are doing the best thing for everyone (not necessarily the technically preferred way). All in all, I think zeroconf has done a lot of great things, and we are (to steal Mr Moore's words) "within episilon of producing something useful". Jim McMurry (no company name to put here) On Thursday, January 9, 2003, at 12:46 PM, John C. Welch wrote: > On 01/09/2003 05:01, "Keith Moore" wrote: > >> it's not within the purview of this group to decide which applications >> it's okay to break. zeroconf is NOT chartered to change the Internet >> architecture. >> >> if this group can't stay within its charter, then it needs to be shut >> down. >> >> actually it should have been shut down a long time ago. the reason >> that >> it's difficult to do so is that it's within episilon of producing >> something >> useful - and it could do so if it weren't hell-bent on causing >> problems >> for others. >> > > > I totally agree...please pick your jaws up off the ground, it's not > for the > same reason. Zeroconf is important, but more on an enabling/social > level > than on a technological one. We don't need it. But people, (you know, > they > buy computers, use AOL, send pictures to grammy, and don't give a rat's > patoot how it happens, but DO hate the work involved to do it) DO need > this. > > I've come to the conclusion that the IETF is utterly and absolutely > incapable of doing anything for anyone who is not a geek. This is just > the > way things are. Apple/Microsoft/IBM and others *are* able to do things > for > people who aren't geeks, and I really now firmly believe that they are > far > better off telling this group and the IETF to pound sand when talking > about > anything that isn't for geeks. > > This of course may change, but that would require a too-large > sublimation of > ego and pet causes for me to believe that it will prior to the > invention of > faster-than-light travel, or the Cubs beating the Red Sox in the World > Series in a 4-game shutout. > > john > > -- > John C. Welch > Consultant III > Administrative Computing > (617) 253 - 1368 work > (508) 579 - 7380 cell > bynkii2 AIM > > From owner-zeroconf@merit.edu Thu Jan 9 16:16:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26508 for ; Thu, 9 Jan 2003 16:16:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B6B5C912B3; Thu, 9 Jan 2003 16:19:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88018912B4; Thu, 9 Jan 2003 16:19: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 8482C912B3 for ; Thu, 9 Jan 2003 16:19:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5EDC25DE77; Thu, 9 Jan 2003 16:19:51 -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 EAC7F5DE15 for ; Thu, 9 Jan 2003 16:19:50 -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 5625E598B0 for ; Thu, 9 Jan 2003 21:19:52 +0000 (GMT) Message-ID: <03f101c2b824$e73eef30$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <532DFC45-2415-11D7-A601-000393681A12@mediatonic.com> Subject: OT Re: Application software needs to be "zeroconf-aware"? Date: Thu, 9 Jan 2003 21:20:14 -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: "james mcmurry" > > We also need this viscous discussion... Do you really mean viscous? or vicious? or perhaps vacuous? Philip From owner-zeroconf@merit.edu Thu Jan 9 16:19:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26588 for ; Thu, 9 Jan 2003 16:19:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 39D2E912B4; Thu, 9 Jan 2003 16:22:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09577912B5; Thu, 9 Jan 2003 16:22: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 0DB52912B4 for ; Thu, 9 Jan 2003 16:22:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id DB4E15DE77; Thu, 9 Jan 2003 16:22:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from www.mediatonic.com (dsl093-188-237.sfo2.dsl.speakeasy.net [66.93.188.237]) by segue.merit.edu (Postfix) with ESMTP id AD9575DE15 for ; Thu, 9 Jan 2003 16:22:54 -0500 (EST) Received: from mediatonic.com (unknown [192.168.12.2]) by www.mediatonic.com (Postfix) with ESMTP id 9CE2F1026B9; Thu, 9 Jan 2003 13:22:53 -0800 (PST) Date: Thu, 9 Jan 2003 13:24:19 -0800 Subject: Re: OT 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) Cc: "Zeroconf Working Group" To: "Philip Nye" From: james mcmurry In-Reply-To: <03f101c2b824$e73eef30$131010ac@aldebaran> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I meant VISCOUS Meaning: Adhesive or sticky I didn't mean mean Vicious :) Sorry Jim McMurry On Thursday, January 9, 2003, at 01:20 PM, Philip Nye wrote: >> From: "james mcmurry" >> >> We also need this viscous discussion... > > Do you really mean viscous? or vicious? or perhaps vacuous? > > Philip From owner-zeroconf@merit.edu Fri Jan 10 19:36:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20950 for ; Fri, 10 Jan 2003 19:36:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC4A891212; Fri, 10 Jan 2003 19:39:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6090912F0; Fri, 10 Jan 2003 19:39: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 8D71491212 for ; Fri, 10 Jan 2003 19:39:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7572E5E01D; Fri, 10 Jan 2003 19:39:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by segue.merit.edu (Postfix) with ESMTP id 54BDC5E017 for ; Fri, 10 Jan 2003 19:39:17 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18X9g9-0006Qn-00; Fri, 10 Jan 2003 16:39:13 -0800 Date: Fri, 10 Jan 2003 19:36:15 -0500 From: Keith Moore To: Brad Hards Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Application software needs to be "zeroconf-aware"? Message-Id: <20030110193615.141592bb.moore@cs.utk.edu> In-Reply-To: <200301100104.39344.bhards@bigpond.net.au> References: <200301090015.h090FOA22996@astro.cs.utk.edu> <200301091945.15364.bhards@bigpond.net.au> <20030109080150.67c4b3f0.moore@cs.utk.edu> <200301100104.39344.bhards@bigpond.net.au> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > You have (apparently deliberately) quoted me out of context. What I actually > said, in part, was: "I don't care if that happens. I _DO_ care if major > applications break.". The part you have quoted is in relation to "at least > one application". For the absence of doubt, I do not think that it is OK to > cause gratitous breakage, but if breaking one specialist application (that is > probably broken in other common networking scenarios) is the cost of enabling > IP networking to people who couldn't otherwise have it, then that is a > reasonable cost. well, of course we're not talking about one specialist application. we're talking about any application that uses IP addresses to do referrals - a class which includes distributed computation, distributed simulation, internet telephony, conferencing, multiplayer games. nor are we really talking about "enabling IP networking to people who couldn't otherwise have it". we're talking about enabling use of IP for ad hoc networks. > > > Summary: if one (or a few) specialist applications breaking is going to > > > stop progression of an IETF zeroconf solution, then the WG was never > > > going to produce anything, and we should probably transition this to > > > another organisation. We should _not_ give up. > > > > it's not within the purview of this group to decide which applications > > it's okay to break. zeroconf is NOT chartered to change the Internet > > architecture. > > It is absolutely within the purview of this group to change the Internet > architecture. utterly irresponsible garbage. this group was chartered to work on a narrow problem. hubris is what is keeping this group from solving that problem without causing harm. >If we can't change anything, then how can we progress anything? architectural change has the potential to affect a much wider set of interests than can possibly be represented by this group. it's the very ignorance of, and disregard for, the needs of those interests that makes this group incompentent to try to do architectural change. > That progress may come at the cost of maintenance on some applications, that > have been programmed with certain assumptions that are not true in general on > the Internet as it currently exists. The Internet is far more diverse, both in environments and users needs, than you seem to imagine. And your dismissal of the harm done as "cost of maintenance on some applications" is hopelessly naive. > That maintenance is worth avoiding, if > we can avoid it, but I repeat my argument: If you think you can make enough > changes (whatever they might be), and not have anyone notice that something > new is happening, then I think further discussion is unlikely to be > productive. If you'll look carefully, I haven't been arguing that nobody should notice. I've been arguing that the v4 spec should include workarounds for the harm that v4LL does. I actually agree that v4LL might be of sufficient benefit that it's worth some impact to the installed base. Where I draw the line is when this group says it's okay to screw some users (and some application vendors) without giving them workarounds. > > > if this group can't stay within its charter, then it needs to be shut down. > > > > actually it should have been shut down a long time ago. the reason that > > it's difficult to do so is that it's within episilon of producing something > > useful - and it could do so if it weren't hell-bent on causing problems > > for others. > If you have specific proposals, please, please, please make them. I have made them. They've been dismissed because people are too insistent on providing functionality that isn't needed to fulfill the group's charter. > I am not saying that the current stuff we have is the right answer. I am quite > willing to keep working on zeroconf, because I'd like for people like my Mum > and Dad to be able to use a computer one day. I owe it to them, and lots of > other people like them, to make that computer use as easy as possible, and > maintaining the status quo is unacceptable to me. it's a laudable goal. however, it's not what this group was chartered to do. nor does the group appear to have sufficient expertise to credibly work on that goal. nor would v4LL be a step toward that goal. relative to that goal, v4LL is a step backwards, because the network that results from v4LL is seriously impaired when compared to an IP network with global addresses. that's not to say that v4LL isn't useful (if some constraints are placed on its operation) - just that it doesn't address this problem at all. Keith From owner-zeroconf@merit.edu Fri Jan 10 19:46:29 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21204 for ; Fri, 10 Jan 2003 19:46:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BDDC3912F1; Fri, 10 Jan 2003 19:49:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4BA2F912F5; Fri, 10 Jan 2003 19: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 0BD3B912F2 for ; Fri, 10 Jan 2003 19:47:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id DD1475E01D; Fri, 10 Jan 2003 19:47:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by segue.merit.edu (Postfix) with ESMTP id BB3545E017 for ; Fri, 10 Jan 2003 19:47:53 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18X9nj-0006pd-00; Fri, 10 Jan 2003 16:47:03 -0800 Date: Fri, 10 Jan 2003 19:44:05 -0500 From: Keith Moore To: Brad Hards Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: Application software needs to be "zeroconf-aware"? Message-Id: <20030110194405.4a106a64.moore@cs.utk.edu> In-Reply-To: <200301100111.40304.bhards@bigpond.net.au> References: <200301091945.15364.bhards@bigpond.net.au> <200301090015.h090FOA22996@astro.cs.utk.edu> <24285.1042113983@munnari.OZ.AU> <200301100111.40304.bhards@bigpond.net.au> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Fri, 10 Jan 2003 01:11:40 +1100 Brad Hards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thu, 9 Jan 2003 23:06, Robert Elz wrote: > > What Keith has been requesting (one of the things anyway) is that there be > > some nice (relatively) easy way to turn zeroconf off, so it is actually > > possible to run applications which may have problems with the existence of > > zeroconf addresses. > I think that if there is going to be some breakage, then we definately need to > be able to disable zeroconf on a host-by-host basis. > > My recollection of Keith's request was actually that you can disable it on a > network basis. That is clearly a DoS waiting to happen, and I can't concur. if you have physical access to the network, there are lots of ways to mount a DoS attack. having a way for the network to disable v4LL doesn't increase that vulnerability in any practical sense. > There is no precedent (for example, you can't stop all DHCP servers on a > network basis) and it is unwarranted, given the likely level of breakage > (minor) who are you to say that it's a "minor" breakage when someone else's application fails? > and the environment in which it is likely to occur (managed > networks). and who are you to say that it's reasonable to impose v4LL on someone else's network? isn't that something that the manager of a network should be able to decide? > Indeed, even if you can disable zeroconf address assignment on an > per-network basis, you will still likely need to perform some "per-host" > configuration to enable that machine to communicate in any case. DHCP doesn't solve all problems, but it seems to work okay for some people. I think what you're trying to say is that the abliity to disable on a per-host basis (via host configuration) should be sufficient. The reason I don't agree is that I've seen too many network problems result from some kind of machine not having reasonable defaults and requiring some explicit configuration. the "don't you dare plug your machine into the network until you've flipped this bit" rule doesn't scale very well. Keith From owner-zeroconf@merit.edu Fri Jan 10 20:10:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21744 for ; Fri, 10 Jan 2003 20:10:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 77245912F2; Fri, 10 Jan 2003 20:13:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40691912F3; Fri, 10 Jan 2003 20:13: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 34B70912F2 for ; Fri, 10 Jan 2003 20:13:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1AD765E02A; Fri, 10 Jan 2003 20:13:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from marsha.smtp.stsn.com (p249.n-sfpop03.stsn.com [199.107.154.249]) by segue.merit.edu (Postfix) with ESMTP id CCD655DEEA for ; Fri, 10 Jan 2003 20:13:07 -0500 (EST) Received: from [10.1.185.131] ([10.1.185.131]) by marsha.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 9 Jan 2003 17:15:37 -0800 User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 10 Jan 2003 17:13:05 -0800 Subject: Re: Application software needs to be "zeroconf-aware"? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030110193615.141592bb.moore@cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Jan 2003 01:15:37.0296 (UTC) FILETIME=[C8536D00:01C2B845] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 01/10/2003 16:36, "Keith Moore" wrote: >> It is absolutely within the purview of this group to change the Internet >> architecture. > > utterly irresponsible garbage. this group was chartered to work on a > narrow problem. hubris is what is keeping this group from solving that > problem without causing harm. Tripe...poppycock. Enough. By creating a standard for v4LL, you are changing the architecture of the Internet. DHCP did the same thing, as did TCP/IP. > >> If we can't change anything, then how can we progress anything? > > architectural change has the potential to affect a much wider set of > interests than can possibly be represented by this group. it's > the very ignorance of, and disregard for, the needs of those interests > that makes this group incompentent to try to do architectural change. I just think the IETF as a whole is incompetent for anything that isn't an esoteric geek toy. > >> That progress may come at the cost of maintenance on some applications, that >> have been programmed with certain assumptions that are not true in general on >> the Internet as it currently exists. > > The Internet is far more diverse, both in environments and users needs, > than you seem to imagine. And your dismissal of the harm done as "cost of > maintenance on some applications" is hopelessly naive. Oh e-bloody-nough. I'm going into lurk/autodelete mode on this, and the IETF as a whole. This isn't a group trying to get anything done as much as its a shouting contest for geeks. You guys want to argue how many angels can gavotte on a gluon, continue on. If there is any progress made beyond who is breaking what by being an incompetent coporate tool, I'll get interested again. I, like the rest of the world, have *work* to do, on a fairly large scale. Anymore, I am taking the tack of, if there is a finished standard that can be used, fine. But I am done waiting for the IETF to finish anything, as I no longer believe that it is possible on a scale of less than years, and it is irresponsible to delay work just to appease a collection of people who have no idea of life outside of the current sheltered environment they are in. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Jan 10 20:33:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22119 for ; Fri, 10 Jan 2003 20:33:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C18A1912F3; Fri, 10 Jan 2003 20:36:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97045912F4; Fri, 10 Jan 2003 20:36: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 8B4AE912F3 for ; Fri, 10 Jan 2003 20:36:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 713B55E012; Fri, 10 Jan 2003 20:36:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta06bw.bigpond.com (mta06bw.bigpond.com [139.134.6.96]) by segue.merit.edu (Postfix) with ESMTP id 3A5D15DEB3 for ; Fri, 10 Jan 2003 20:36:57 -0500 (EST) Received: from pc-00206 ([144.135.24.78]) by mta06bw.bigpond.com (Netscape Messaging Server 4.15 mta06bw Jul 16 2002 22:47:55) with SMTP id H8J0HH00.1YP; Sat, 11 Jan 2003 11:36:53 +1000 Received: from CPE-203-51-31-46.nsw.bigpond.net.au ([203.51.31.46]) by bwmam04.mailsvc.email.bigpond.com(MailRouter V3.0n 35/24549033); 11 Jan 2003 11:38:24 From: Brad Hards To: Keith Moore Subject: Re: Application software needs to be "zeroconf-aware"? Date: Sat, 11 Jan 2003 12:23:21 +1100 User-Agent: KMail/1.4.5 Cc: kre@munnari.OZ.AU, zeroconf@merit.edu References: <200301091945.15364.bhards@bigpond.net.au> <200301100111.40304.bhards@bigpond.net.au> <20030110194405.4a106a64.moore@cs.utk.edu> In-Reply-To: <20030110194405.4a106a64.moore@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: <200301111223.21937.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 11 Jan 2003 11:44, Keith Moore wrote: > > Indeed, even if you can disable zeroconf address assignment on an > > per-network basis, you will still likely need to perform some "per-host" > > configuration to enable that machine to communicate in any case. > > DHCP doesn't solve all problems, but it seems to work okay for some people. > > I think what you're trying to say is that the abliity to disable on a > per-host basis (via host configuration) should be sufficient. The > reason I don't agree is that I've seen too many network problems result > from some kind of machine not having reasonable defaults and requiring > some explicit configuration. the "don't you dare plug your machine > into the network until you've flipped this bit" rule doesn't > scale very well. In general, I'm not seeing _having_ an IPv4LL address is a major issue to causing the type of breakage (that I think) you are concerned about. The problem comes when it is used. In a managed network, I don't see this as a major issue, because each machine will normally need to be configured for other reasons. Whether you do that configuration automatically or manually, the incremental work to stop the initialisation scripts from assigning an IPv4LL address isn't likely to be very great. There is also precedent work - consider a mixed IPv6 and IPv4 network, where all the machines have IPv4 but not all the machines have IPv6. Not withstanding our differencs in opinion, I'm certainly willing to listen to a proposal you have for how we might implement a system that stops IPv4LL addresses from being acquired on a network. I have a couple of ideas (well, implementing an autoresponder that basically runs a DoS attack is clearly a option, and would at least work with existing implementations, but it might be cleaner if there was also some way of reducing the gross network load that this might cause). 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+H3IJW6pHgIdAuOMRAiahAKC2/4xJGi0KbfKBiLlePabSFS+figCgsb2g gy0f6BkJUgvoBA6BWJNJCqw= =9ZfR -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Fri Jan 10 20:50:09 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22336 for ; Fri, 10 Jan 2003 20:50:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0F874912F4; Fri, 10 Jan 2003 20:53:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4D1A912F5; Fri, 10 Jan 2003 20:53: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 C9597912F4 for ; Fri, 10 Jan 2003 20:53:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id B0EB35DF5E; Fri, 10 Jan 2003 20:53:15 -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 496055DEB3 for ; Fri, 10 Jan 2003 20:53:14 -0500 (EST) Received: from pc-00206 ([144.135.25.84]) by mta03ps.bigpond.com (Netscape Messaging Server 4.15 mta03ps Jul 16 2002 22:47:55) with SMTP id H8J18M00.AWH; Sat, 11 Jan 2003 11:53:10 +1000 Received: from CPE-203-51-31-46.nsw.bigpond.net.au ([203.51.31.46]) by psmam06.mailsvc.email.bigpond.com(MailRouter V3.0n 116/24445839); 11 Jan 2003 12:53:10 From: Brad Hards To: Keith Moore Subject: Re: Application software needs to be "zeroconf-aware"? Date: Sat, 11 Jan 2003 12:39:39 +1100 User-Agent: KMail/1.4.5 Cc: zeroconf@merit.edu References: <200301090015.h090FOA22996@astro.cs.utk.edu> <200301100104.39344.bhards@bigpond.net.au> <20030110193615.141592bb.moore@cs.utk.edu> In-Reply-To: <20030110193615.141592bb.moore@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: <200301111239.39803.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 11 Jan 2003 11:36, Keith Moore wrote: > well, of course we're not talking about one specialist application. > we're talking about any application that uses IP addresses to do > referrals - a class which includes distributed computation, distributed > simulation, internet telephony, conferencing, multiplayer games. If that occurs, that clearly isn't good. However IP referal would already seem to be broken in certain network situations (NAT, multi-homing, some proxying) and I haven't see a coherent explanation of whether the changes that we are proposing are going to change the situation in an unacceptable way. > nor are we really talking about "enabling IP networking to people who > couldn't otherwise have it". we're talking about enabling use of IP > for ad hoc networks. I don't get that interpretation out of the charter, and although ad-hoc is clearly a useful area, I think that the intent is substantially wider. Or perhaps we just disagree on what "ad-hoc" means. > I have made them. They've been dismissed because people are too insistent > on providing functionality that isn't needed to fulfill the group's > charter. We still don't seem to be communicating well. Perhaps it is because the problems that you are bringing up are simply not what people want to hear. Perhaps it is because you aren't making the issues clearly and unambiguously. Perhaps it is a difference of interpretation as to what the group's charter is. I'm not sure. I can only suggest that you try again, perhaps in a different style. For example, several people have requested a concrete example of a specific network configuration and a specific application that has specific IPv4LL breakage that doesn't otherwise occur. Or perhaps an alternative proposal, in the form of an I-D. 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+H3XbW6pHgIdAuOMRArrfAJ9kXiJ+lOT2fGBSvtWqPH7q4M4xTgCfSXyz 49jD2XmZzL7QtMNzCrih0r8= =9c6+ -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Fri Jan 10 21:08:58 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22559 for ; Fri, 10 Jan 2003 21:08:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 785E1912F5; Fri, 10 Jan 2003 21:12:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4BC98912F7; Fri, 10 Jan 2003 21:12: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 09463912F5 for ; Fri, 10 Jan 2003 21:12:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id DD9085E05E; Fri, 10 Jan 2003 21:12:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by segue.merit.edu (Postfix) with ESMTP id BB94B5DEB3 for ; Fri, 10 Jan 2003 21:12:03 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18XB79-0002vN-00; Fri, 10 Jan 2003 18:11:12 -0800 Date: Fri, 10 Jan 2003 21:08:14 -0500 From: Keith Moore To: Brad Hards Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: Application software needs to be "zeroconf-aware"? Message-Id: <20030110210814.1e488296.moore@cs.utk.edu> In-Reply-To: <200301111223.21937.bhards@bigpond.net.au> References: <200301091945.15364.bhards@bigpond.net.au> <200301100111.40304.bhards@bigpond.net.au> <20030110194405.4a106a64.moore@cs.utk.edu> <200301111223.21937.bhards@bigpond.net.au> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Sat, 11 Jan 2003 12:23:21 +1100 Brad Hards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sat, 11 Jan 2003 11:44, Keith Moore wrote: > > > > Indeed, even if you can disable zeroconf address assignment on an > > > per-network basis, you will still likely need to perform some "per-host" > > > configuration to enable that machine to communicate in any case. > > > > DHCP doesn't solve all problems, but it seems to work okay for some people. > > > > I think what you're trying to say is that the abliity to disable on a > > per-host basis (via host configuration) should be sufficient. The > > reason I don't agree is that I've seen too many network problems result > > from some kind of machine not having reasonable defaults and requiring > > some explicit configuration. the "don't you dare plug your machine > > into the network until you've flipped this bit" rule doesn't > > scale very well. > In general, I'm not seeing _having_ an IPv4LL address is a major issue to > causing the type of breakage (that I think) you are concerned about. The > problem comes when it is used. right, but if the addresses are exposed to applications (via any of the means listed in an earlier message) those that don't know any better will use them. it's even more complex than that, though. v4LL addresses will work fine with those applications in an isolated ad hoc network, so app writers will not want to simply refuse to use them. the case where v4LL addresses cause problems is when the network is not isolated, or (similarly) when some hosts on the network think it's isolated and other hosts have external connectivity. in trying to deal with a similar problem in IPv6 - use of site-locals, apparently the best that Microsoft people could do was to have a global configuration flag for distributed software - are you on an isolated network or not? it doesn't seem like a satisfactory solution to me. > In a managed network, I don't see this as a major issue, because each machine > will normally need to be configured for other reasons. Whether you do that > configuration automatically or manually, the incremental work to stop the > initialisation scripts from assigning an IPv4LL address isn't likely to be > very great. a DHCP option to disable v4LL would be fine with me if it were required as part of the v4LL standard. > There is also precedent work - consider a mixed IPv6 and IPv4 network, where > all the machines have IPv4 but not all the machines have IPv6. it's really not the same situation unless you believe that all apps should speak ipv4 and ipv6 interchangably. I don't think things will work this way - I think we'll get apps that interoperate using ipv4 and apps that interoperate using ipv6 and a few apps that can use either. Keith From owner-zeroconf@merit.edu Fri Jan 10 21:21:57 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22771 for ; Fri, 10 Jan 2003 21:21:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 00CCB912F7; Fri, 10 Jan 2003 21:25:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C245A912F8; Fri, 10 Jan 2003 21:25:04 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9E368912F7 for ; Fri, 10 Jan 2003 21:25:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B43F5E02F; Fri, 10 Jan 2003 21:25:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by segue.merit.edu (Postfix) with ESMTP id 6AD7F5DEB3 for ; Fri, 10 Jan 2003 21:25:03 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18XBKT-0004Iu-00; Fri, 10 Jan 2003 18:24:57 -0800 Date: Fri, 10 Jan 2003 21:21:59 -0500 From: Keith Moore To: Brad Hards Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Application software needs to be "zeroconf-aware"? Message-Id: <20030110212159.46604ba8.moore@cs.utk.edu> In-Reply-To: <200301111239.39803.bhards@bigpond.net.au> References: <200301090015.h090FOA22996@astro.cs.utk.edu> <200301100104.39344.bhards@bigpond.net.au> <20030110193615.141592bb.moore@cs.utk.edu> <200301111239.39803.bhards@bigpond.net.au> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Sat, 11 Jan 2003 12:39:39 +1100 Brad Hards wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sat, 11 Jan 2003 11:36, Keith Moore wrote: > > well, of course we're not talking about one specialist application. > > we're talking about any application that uses IP addresses to do > > referrals - a class which includes distributed computation, distributed > > simulation, internet telephony, conferencing, multiplayer games. > If that occurs, that clearly isn't good. However IP referal would already seem > to be broken in certain network situations (NAT, multi-homing, some proxying) > and I haven't see a coherent explanation of whether the changes that we are > proposing are going to change the situation in an unacceptable way. a crucial difference is that not all IP networks run NATs. NAT is (or should be) a voluntary choice made with recognition of the cost vs. benefit. the usual compromise for networks of significant size is to put some things behind a NAT and other things outside of the NAT - or to nail-up bindings through a NAT so that the servers will have stable addresses - thereby having (at least in the short term) most of the benefit of NAT with a minimum cost. (long term costs are that the network is not as functional as it should be - and people are starting to realize this) by comparison, v4LL is not a choice that a network can make. it will be imposed on nearly all networks if it is turned on by default in most operating systems. the fact that NATs have caused harm is not justification for zeroconf causing additional harm. > > nor are we really talking about "enabling IP networking to people who > > couldn't otherwise have it". we're talking about enabling use of IP > > for ad hoc networks. > > I don't get that interpretation out of the charter, and although ad-hoc is > clearly a useful area, I think that the intent is substantially wider. Or > perhaps we just disagree on what "ad-hoc" means. I think this is one of the fundamental differences. It appears that many of the people in this working group think that the purpose of this working group is to reduce the amount of configuration necessary to run a network. Again, it's a laudible goal. I think the name of the group and the vague wording of the charter are (in hindsight) very unfortunate because it conflates two very different problems - how do you reduce the amount of configuration needed in managed IP networks and how do enable ad hoc IP networks without requiring much configuration? > > I have made them. They've been dismissed because people are too insistent > > on providing functionality that isn't needed to fulfill the group's > > charter. > We still don't seem to be communicating well. Perhaps it is because the > problems that you are bringing up are simply not what people want to hear. > Perhaps it is because you aren't making the issues clearly and unambiguously. > Perhaps it is a difference of interpretation as to what the group's charter > is. I'm not sure. > > I can only suggest that you try again, perhaps in a different style. For > example, several people have requested a concrete example of a specific > network configuration and a specific application that has specific IPv4LL > breakage that doesn't otherwise occur. the problem is that people will say "but that breaks with NATs too" never mind that the people who are using those apps now are not using NATs. they'll still be forced to use v4LL under the current proposal. Keith From owner-zeroconf@merit.edu Fri Jan 10 22:16:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23875 for ; Fri, 10 Jan 2003 22:16:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0BAD1912F8; Fri, 10 Jan 2003 22:19:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3057912F9; Fri, 10 Jan 2003 22: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 27F16912F8 for ; Fri, 10 Jan 2003 22:18:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 042DD5DDF4; Fri, 10 Jan 2003 22:18:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from home.karahalios.org (dsl093-162-009.tus1.dsl.speakeasy.net [66.93.162.9]) by segue.merit.edu (Postfix) with ESMTP id 16AED5DDDA for ; Fri, 10 Jan 2003 22:18:38 -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 h0B3IbI08168 for ; Fri, 10 Jan 2003 20:18:37 -0700 Date: Fri, 10 Jan 2003 20:18:36 -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: <20030110210814.1e488296.moore@cs.utk.edu> Message-Id: <5F9DA226-2513-11D7-91F2-00039377AD70@Outersoft.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Sorry Keith, but requiring it as part of the v4LL standard would not be fine with me. Require that v4LL depend on DHCP is not in the spirit of the draft: "It would be beneficial for a host to have some useful subset of IP networking that it can depend upon to be always functional, even when no configuration information is available to the host..."[draft-ietf-zeroconf-ipv4-linklocal-07.txt] There are devices out there (and I am developing one) that cannot afford the extra code burden to make inquiries to a DHCP server. Alex Karahalios On Friday, January 10, 2003, at 07:08 PM, Keith Moore wrote: > a DHCP option to disable v4LL would be fine with me if it were > required as > part of the v4LL standard. > From owner-zeroconf@merit.edu Sat Jan 11 09:04:08 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11743 for ; Sat, 11 Jan 2003 09:04:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F1E59912FC; Sat, 11 Jan 2003 09:07:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB34B912FD; Sat, 11 Jan 2003 09:07: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 A5538912FC for ; Sat, 11 Jan 2003 09:07:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E4285DDAB; Sat, 11 Jan 2003 09:07:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by segue.merit.edu (Postfix) with ESMTP id 6E0F45DD8D for ; Sat, 11 Jan 2003 09:07:14 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18XMHx-0006gn-00; Sat, 11 Jan 2003 06:07:05 -0800 Date: Sat, 11 Jan 2003 09:04:06 -0500 From: Keith Moore To: Alex Karahalios Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Application software needs to be "zeroconf-aware"? Message-Id: <20030111090406.31d8618b.moore@cs.utk.edu> In-Reply-To: <5F9DA226-2513-11D7-91F2-00039377AD70@Outersoft.com> References: <20030110210814.1e488296.moore@cs.utk.edu> <5F9DA226-2513-11D7-91F2-00039377AD70@Outersoft.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Fri, 10 Jan 2003 20:18:36 -0700 Alex Karahalios wrote: > Sorry Keith, but requiring it as part of the v4LL standard would not be > fine with me. Require that v4LL depend on DHCP is not in the spirit of > the draft: > > "It would be beneficial for a host to > have some useful subset of IP networking that it can depend upon to > be always functional, even when no configuration information is > available to the host..."[draft-ietf-zeroconf-ipv4-linklocal-07.txt] > > There are devices out there (and I am developing one) that cannot > afford the extra code burden to make inquiries to a DHCP server. for better or worse, many IPv4 networks use DHCP for host configuration, and this imposes a minimum burden on devices that want to play on those networks. the idea that v4LL is a suitable means to configure a device on a managed network is another gross violation of this group's charter. Keith From owner-zeroconf@merit.edu Sat Jan 11 14:17:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16431 for ; Sat, 11 Jan 2003 14:17:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B98B59125E; Sat, 11 Jan 2003 14:20:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8734691261; Sat, 11 Jan 2003 14:20: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 7F3A99125E for ; Sat, 11 Jan 2003 14:20:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E73C5DDAF; Sat, 11 Jan 2003 14:20:33 -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 739DB5DDA2 for ; Sat, 11 Jan 2003 14:20:32 -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 h0BJKVI14755; Sat, 11 Jan 2003 12:20:31 -0700 Date: Sat, 11 Jan 2003 12:20:30 -0700 Subject: Suitability of v4LL in a managed network [was Application software needs to be "zeroconf-aware"?] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Keith Moore From: Alex Karahalios In-Reply-To: <20030111090406.31d8618b.moore@cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Keith, I guess we need to reach a consensus as to whether v4LL should be used on a managed network or not. If it's not suitable for a managed network, then there would be no DHCP to worry about. Your interpretation of the v4LL charter finds v4LL not suitable for managed networks. My interpretation is based on the charter statement: "Networks where ZEROCONF protocols apply can include (but are not limited to) environments where no DHCP, MADCAP or DNS servers are present." [http://www.ietf.org/html.charters/zeroconf-charter.html] The "but are not limited to" phrase, I think, allows for v4LL to coexist with DHCP. My feeling is that v4LL should be orthogonal to network management protocols such as DHCP. There is no need to make them interdependent, yet they should still be interoperable on the same wire. This allows "dumb" devices to be able to be self configuring via v4LL. "Smart" devices can configure themselves using both DHCP and v4LL. I believe you are seeing v4LL from your own problem domain and you have legitimate concerns. I am looking at v4LL from my problem domain, which is small embedded devices that have minimal user interfaces that need to obtain an IP address without user intervention. DHCP is not a viable solution in this case because it does not exist on these networks or is too difficult to set up and manage. As per the ZEROCONF charter, it appears that ZEROCONF (of which v4LL is part) is ideally suited to my problem domain. That's why I'm on this mailing list. Maybe we need the IETF to make a definitive statement as to the ZEROCONF charter as it pertains to the coexistence of ZEROCONF devices in a managed network? Once this is clear (and to me it already is), we can properly argue if v4LL is suitable. Maybe you are not questioning the existence of v4LL, but rather it's current draft implementation? Alex Karahalios On Saturday, January 11, 2003, at 07:04 AM, Keith Moore wrote: > for better or worse, many IPv4 networks use DHCP for host > configuration, > and this imposes a minimum burden on devices that want to play on those > networks. > > the idea that v4LL is a suitable means to configure a device on a > managed > network is another gross violation of this group's charter. From owner-zeroconf@merit.edu Sat Jan 11 14:42:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16937 for ; Sat, 11 Jan 2003 14:42:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A339491261; Sat, 11 Jan 2003 14:45:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DC1291263; Sat, 11 Jan 2003 14:45: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 A53EC91261 for ; Sat, 11 Jan 2003 14:45:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id BC9B55DE14; Sat, 11 Jan 2003 14:45:04 -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 CD7DF5DE00 for ; Sat, 11 Jan 2003 14:45:03 -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); Sat, 11 Jan 2003 11:45:03 -0800 Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 11 Jan 2003 11:45:03 -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); Sat, 11 Jan 2003 11:45:02 -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, 11 Jan 2003 11:45:02 -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.3718.0); Sat, 11 Jan 2003 11:45:02 -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: Suitability of v4LL in a managed network [was Application software needs to be "zeroconf-aware"?] Date: Sat, 11 Jan 2003 11:45:01 -0800 Message-ID: Thread-Topic: Suitability of v4LL in a managed network [was Application software needs to be "zeroconf-aware"?] Thread-Index: AcK5po0Ug2HCHj8sTGyXA/8biKiBDQAAeOGe From: "Christian Huitema" To: "Alex Karahalios" , "Keith Moore" Cc: X-OriginalArrivalTime: 11 Jan 2003 19:45:02.0235 (UTC) FILETIME=[EE88CEB0:01C2B9A9] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA16937 > "Networks where ZEROCONF protocols apply can include (but are not > limited to) environments where no DHCP, MADCAP or DNS servers are > present." > [http://www.ietf.org/html.charters/zeroconf-charter.html] > > The "but are not limited to" phrase, I think, allows for v4LL to > coexist with DHCP. Another read on the same phrase is that the charter certainly does not mandate that IPv4 autoconfiguration be available when DHCP, MADCAP or DNS servers are present. I believe the IPv4 address autoconfiguration design should follow the general robustness principle, "be conservative in what you send, liberal in what you accept." The way I read this principle is that nodes on a DHCP managed network generally do not gain much functionality by getting a second IP address for the same interface, and that they may in fact loose some functionality as having multiple addresses of different scopes wil confuse some existing application. The conservative solution would thus be to not use autoconfigured addresses when a DHCP assigned address is present, which translate in the requirement that no IETF standard should ever require the specific use of the autoconfigured addresses. The liberal part of the statement would be to accept traffic from autoconfigured addresses even if the host does not actually use these addresses, e.g. accept incoming TCP connections. -- Christian Huitema From owner-zeroconf@merit.edu Sat Jan 11 19:07:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21314 for ; Sat, 11 Jan 2003 19:07:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 49DB79126C; Sat, 11 Jan 2003 19:10:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F6459126D; Sat, 11 Jan 2003 19:10: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 0D85C9126C for ; Sat, 11 Jan 2003 19:10:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id DABDA5DE9D; Sat, 11 Jan 2003 19:10:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta01ps.bigpond.com (mta01ps.bigpond.com [144.135.25.133]) by segue.merit.edu (Postfix) with ESMTP id 63D505DE54 for ; Sat, 11 Jan 2003 19:10:33 -0500 (EST) Received: from pc-00206 ([144.135.25.81]) by mta01ps.bigpond.com (Netscape Messaging Server 4.15 mta01ps Jul 16 2002 22:47:55) with SMTP id H8KR5I00.9O3; Sun, 12 Jan 2003 10:10:30 +1000 Received: from CPE-203-51-31-46.nsw.bigpond.net.au ([203.51.31.46]) by psmam05.mailsvc.email.bigpond.com(MailRouter V3.0n 107/26461799); 12 Jan 2003 10:10:30 From: Brad Hards To: Keith Moore , Alex Karahalios Subject: Re: Application software needs to be "zeroconf-aware"? Date: Sun, 12 Jan 2003 10:56:55 +1100 User-Agent: KMail/1.4.5 Cc: zeroconf@merit.edu References: <20030110210814.1e488296.moore@cs.utk.edu> <5F9DA226-2513-11D7-91F2-00039377AD70@Outersoft.com> <20030111090406.31d8618b.moore@cs.utk.edu> In-Reply-To: <20030111090406.31d8618b.moore@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: <200301121056.55734.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 12 Jan 2003 01:04, Keith Moore wrote: > the idea that v4LL is a suitable means to configure a device on a managed > network is another gross violation of this group's charter. It is specifically within this groups charter: It is also possible that both modes (ZEROCONF and administered) may coexist on the same network; the modes may not be exclusive of each other. 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+IK9HW6pHgIdAuOMRAkGaAJ97cJPx702+g73Sz4nhIhbEmvSm+ACghNyo 39wpK7umaOLMCDl/YpAlGbo= =Ac6X -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Sat Jan 11 19:19:09 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21493 for ; Sat, 11 Jan 2003 19:19:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC1129126D; Sat, 11 Jan 2003 19:22:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 656CE9126E; Sat, 11 Jan 2003 19:22: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 575F29126D for ; Sat, 11 Jan 2003 19:22:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3BFD35DE54; Sat, 11 Jan 2003 19:22: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 B5B6A5DDDB for ; Sat, 11 Jan 2003 19:22:16 -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 h0C0MFw15754 for ; Sat, 11 Jan 2003 16:22:15 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Sat, 11 Jan 2003 16:22:07 -0800 Received: from apple.com ([17.112.74.130]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id h0C0M6f06341; Sat, 11 Jan 2003 16:22:06 -0800 (PST) Date: Sat, 11 Jan 2003 16:22:18 -0800 Subject: Re: Suitability of v4LL in a managed network [was Application software needs to be "zeroconf-aware"?] 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: Vincent Lubet 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 On Saturday, January 11, 2003, at 11:45 AM, Christian Huitema wrote: > Another read on the same phrase is that the charter certainly does not > mandate that IPv4 autoconfiguration be available when DHCP, MADCAP or > DNS servers are present. I believe the IPv4 address autoconfiguration > design should follow the general robustness principle, "be > conservative in what you send, liberal in what you accept." The way I > read this principle is that nodes on a DHCP managed network generally > do not gain much functionality by getting a second IP address for the > same interface, and that they may in fact loose some functionality as > having multiple addresses of different scopes wil confuse some > existing application. The conservative solution would thus be to not > use autoconfigured addresses when a DHCP assigned address is present, > which translate in the requirement that no IETF standard should ever > require the specific use of the autoconfigured addresses. I agree it's very reasonable not to require an LL address to be assigned when a non LL address is assigned to a network interface. > The liberal part of the statement would be to accept traffic from > autoconfigured addresses even if the host does not actually use these > addresses, e.g. accept incoming TCP connections. This is really needed because using autoconfigured LL addresses is the only way to access some devices that have not been yet configured. Vincent From owner-zeroconf@merit.edu Sat Jan 11 23:27:57 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24634 for ; Sat, 11 Jan 2003 23:27:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 76A8791272; Sat, 11 Jan 2003 23:30:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E617B91273; Sat, 11 Jan 2003 23:30: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 CA70891272 for ; Sat, 11 Jan 2003 23:30:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C4B55DE80; Sat, 11 Jan 2003 23:30:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta03bw.bigpond.com (mta03bw.bigpond.com [139.134.6.86]) by segue.merit.edu (Postfix) with ESMTP id C4C805DE56 for ; Sat, 11 Jan 2003 23:30:13 -0500 (EST) Received: from pc-00206 ([144.135.24.69]) by mta03bw.bigpond.com (Netscape Messaging Server 4.15 mta03bw Jul 16 2002 22:47:55) with SMTP id H8L36A00.BQR; Sun, 12 Jan 2003 14:30:10 +1000 Received: from CPE-203-51-31-46.nsw.bigpond.net.au ([203.51.31.46]) by bwmam01.mailsvc.email.bigpond.com(MailRouter V3.0n 8/23735848); 12 Jan 2003 14:30:09 From: Brad Hards To: Vincent Lubet , Christian Huitema Subject: Re: Suitability of v4LL in a managed network [was Application software needs to be "zeroconf-aware"?] Date: Sun, 12 Jan 2003 15:16:34 +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: <200301121516.34205.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 12 Jan 2003 11:22, Vincent Lubet wrote: > I agree it's very reasonable not to require an LL address to be > assigned when a non LL address is assigned to a network interface. http://www.zeroconf.org/w3onwire-zeroconf.pdf contains a good intro to why this is needed. 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+IOwiW6pHgIdAuOMRAobjAKCyEIO4Cd/us9tyJokNkOm4w7obAgCfW79s QQww9MAkp8HbSakK9S/1kK8= =e8WQ -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Sun Jan 12 01:11:39 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25788 for ; Sun, 12 Jan 2003 01:11:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EE65B91206; Sun, 12 Jan 2003 01:14:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA2C391275; Sun, 12 Jan 2003 01:14: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 8F8DB91206 for ; Sun, 12 Jan 2003 01:14:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 77F495DEC3; Sun, 12 Jan 2003 01:14:47 -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 37B3E5DE85 for ; Sun, 12 Jan 2003 01:14:47 -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, 11 Jan 2003 22:14:46 -0800 Received: from 157.54.8.23 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 11 Jan 2003 22:14:46 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Sat, 11 Jan 2003 22:14:46 -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, 11 Jan 2003 22:14:46 -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.3718.0); Sat, 11 Jan 2003 22:14:46 -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: Suitability of v4LL in a managed network [was Application software needs to be "zeroconf-aware"?] Date: Sat, 11 Jan 2003 22:14:45 -0800 Message-ID: Thread-Topic: Suitability of v4LL in a managed network [was Application software needs to be "zeroconf-aware"?] Thread-Index: AcK5802UYSdlzRmkRsGHh1P5F17LxAACUbkQ From: "Christian Huitema" To: "Brad Hards" , "Vincent Lubet" Cc: X-OriginalArrivalTime: 12 Jan 2003 06:14:46.0415 (UTC) FILETIME=[E7A921F0:01C2BA01] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA25788 On Sun, 12 Jan 2003, Brad Hards wrote > On Sun, 12 Jan 2003 11:22, Vincent Lubet wrote: >> I agree it's very reasonable not to require an LL address to be >> assigned when a non LL address is assigned to a network interface. > http://www.zeroconf.org/w3onwire-zeroconf.pdf contains a good intro to why > this is needed. The referenced document makes three arguments: 1) That if a server configuration changes, the clients will cease to function if they cannot find a server, i.e. resolve the server's name; 2) That if a node with only a DHCP configured address will not be able to communicate with a node that only have an autoconfigured address; 3) That there will be simple devices that only have autoconfigured addresses. I would contend that the first argument is a requirement on name resolution, not on addressing. If you can resove the name, the main drawback of the transition requirement is the possible instability of addresses. But 169.254.x.x addresses are in fact not very stable; they can be lost as the result of some form of collision. In a DHCP environment, the DHCP allocated addresses are in fact likely to be more stable, not less. The second argument is really a requirement on routing, not address allocation. It is not necessary that hosts actually allocate a 169.254.x.x address to their interface, if they are capable of simply sending local ARP requests for 169.254.x.x. Similarly, nodes with only a 169.254.x.x address could easily send ARP requests for all addresses, since presumably they have only one interface and no configured router. Communication does not require address allocation. We may debate whether building IPv4 devices that are not DHCP aware is a good idea -- I think not. But in any case the third argument is satisfied by the "liberal" part of my recommendation. If DHCP hosts accept to communicate locally with 169.254.x.x addresses, then the simple devices are not excluded. We have established that having two addresses with different scopes is not neutral: it will confuse some applications. It is thus not reasonable to mandate that all hosts configure dual addresses on all interfaces. On the other hand, I just established that if a host is aware of the 169.254.x.x convention, then the host can in fact communicate with 169.254.x.x hosts on the link using a DHCP allocated address. In short, it suffices to be zeroconf aware to maintain connectivity; allocating a 169.254.x.x address is overkill. -- Christian Huitema From owner-zeroconf@merit.edu Sun Jan 12 02:01:18 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27870 for ; Sun, 12 Jan 2003 02:01:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 097A69120A; Sun, 12 Jan 2003 02:04:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD7CE91213; Sun, 12 Jan 2003 02:04: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 6B1609120A for ; Sun, 12 Jan 2003 02:02:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F9F75DE56; Sun, 12 Jan 2003 02:02:50 -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 CC6715DDD2 for ; Sun, 12 Jan 2003 02:02:48 -0500 (EST) Received: from pc-00206 ([144.135.25.75]) by mta03ps.bigpond.com (Netscape Messaging Server 4.15 mta03ps Jul 16 2002 22:47:55) with SMTP id H8LA8L00.25L for ; Sun, 12 Jan 2003 17:02:45 +1000 Received: from CPE-203-51-31-46.nsw.bigpond.net.au ([203.51.31.46]) by PSMAM03.mailsvc.email.bigpond.com(MailRouter V3.0n 89/26729147); 12 Jan 2003 17:02:45 From: Brad Hards To: Subject: Re: Suitability of v4LL in a managed network [was Application software needs to be "zeroconf-aware"?] Date: Sun, 12 Jan 2003 17:49:09 +1100 User-Agent: KMail/1.4.5 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: <200301121749.09484.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Think of it another way. If you already have a connection to a host with IPv4LL address, and you become capable of gaining a routable address, it is better to add the routable address, not replace the IPv4LL address. Dumping a working address is gratitous breakage for a capable host. I think you can have your cake, and eat it too, if you have the right level of support from your name service code. 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+IQ/lW6pHgIdAuOMRAgvhAKCN0ixPf9qRGMCKtEghrLEgdOF7HwCfXXCk 8SlX7TT1wDzwQaAefjfYdu4= =rSaZ -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Sun Jan 12 02:38:12 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06580 for ; Sun, 12 Jan 2003 02:38:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C681791213; Sun, 12 Jan 2003 02:41:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9446D91217; Sun, 12 Jan 2003 02:41: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 908BA91213 for ; Sun, 12 Jan 2003 02:41:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6F1C95DE3B; Sun, 12 Jan 2003 02:41:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id BB3295DEA5 for ; Sun, 12 Jan 2003 02:39:51 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0C7clF23548; Sun, 12 Jan 2003 14:38:49 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0C7aZ815564; Sun, 12 Jan 2003 18:37:56 +1100 (EST) From: Robert Elz To: Alex Karahalios Cc: Keith Moore , zeroconf@merit.edu Subject: Re: Suitability of v4LL in a managed network [was Application software needs to be "zeroconf-aware"?] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 12 Jan 2003 14:36:34 +0700 Message-ID: <15562.1042356994@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sat, 11 Jan 2003 12:20:30 -0700 From: Alex Karahalios Message-ID: | I am looking at v4LL from my problem domain, which | is small embedded devices that have minimal user interfaces that need | to obtain an IP address without user intervention. That's fine but ... | DHCP is not a viable | solution in this case because it does not exist on these networks or is | too difficult to set up and manage. That's very poor reasoning. You're quite correct, DHCP might not be available, so you cannot rely upon it, and in that case, for some devices v4LL addresses are likely to be a very good fallback. But where DHCP is available you really need to use it, even in your very minimal embedded device. I suspect that might be more places than you'd think - lots of cheap hub/switch type devices implement a DHCP server these days, I have one at home, I'd prefer to disable it, but I haven't yet found out how, and as it is a "good enough" DHCP server, I decided just to use the thing instead (it brings one or two minor advantages over using a "normal" DHCP server on a host - along with the disadvantages). A dhcp client for a simple device is really a very trivial piece of code. And if that proves too much (perhaps lease renewal is just too difficult for some reason), then you could at least do BOOTP (which is about as simple as possible to imagine for the client). Without that, on my net, your trivial devices (whatever they are) are likely to be useless - I'm very unlikely to connect them (being embedded, I almost certainly won't get to audit their code) to any net which has real hosts on it. If they have some reason for using IP, they must want to be able to communicate with some other host (perhaps to be controlled by it, or something) - to do that on my net, the device is going to have to route through a firewall, for which purpose LL addresses will simply be useless. Please don't jump on LL addresses as a solution for baby devices "great, now I can forget about default routes, redirects, ... I'll just use these, and these alone, and I'll have that much less code to write". The product will be virtually useless. LL addresses are likely to be just fine for a device to use when it finds itself in an environment where there are no other available addresses (ad hoc nets, nets where the dhcp server has failed, ...) to at least permit some communication to function - they should *never* be viewed as adequate to always handle any device's networking needs. kre From owner-zeroconf@merit.edu Sun Jan 12 02:46:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06643 for ; Sun, 12 Jan 2003 02:46:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 77C9491217; Sun, 12 Jan 2003 02:49:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 439809121A; Sun, 12 Jan 2003 02:49: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 8B37E91217 for ; Sun, 12 Jan 2003 02:48:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 694875DE95; Sun, 12 Jan 2003 02:48:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta08bw.bigpond.com (mta08bw.bigpond.com [144.135.24.137]) by segue.merit.edu (Postfix) with ESMTP id 0391F5DE3B for ; Sun, 12 Jan 2003 02:48:50 -0500 (EST) Received: from pc-00206 ([144.135.24.84]) by mta08bw.bigpond.com (Netscape Messaging Server 4.15 mta08bw Jul 16 2002 22:47:55) with SMTP id H8LCDB00.1FE; Sun, 12 Jan 2003 17:48:47 +1000 Received: from CPE-203-51-31-46.nsw.bigpond.net.au ([203.51.31.46]) by bwmam06.mailsvc.email.bigpond.com(MailRouter V3.0n 53/24147346); 12 Jan 2003 17:48:47 From: Brad Hards To: Robert Elz , Alex Karahalios Subject: Re: Suitability of v4LL in a managed network [was Application software needs to be "zeroconf-aware"?] Date: Sun, 12 Jan 2003 18:35:10 +1100 User-Agent: KMail/1.4.5 Cc: zeroconf@merit.edu References: <15562.1042356994@munnari.OZ.AU> In-Reply-To: <15562.1042356994@munnari.OZ.AU> 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: <200301121835.10784.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 12 Jan 2003 18:36, Robert Elz wrote: > But where DHCP is available you really need to use it, even in your very > minimal embedded device. I suspect that might be more places than > you'd think - lots of cheap hub/switch type devices implement a DHCP > server these days, I have one at home, I'd prefer to disable it, but I > haven't yet found out how, and as it is a "good enough" DHCP server, > I decided just to use the thing instead (it brings one or two minor > advantages over using a "normal" DHCP server on a host - along with > the disadvantages). The problem with DHCP is that it is pretty critical that you have exactly one server. No servers requires IPv4LL as a fallback, two or more servers can lead to them handing out conflicting network addresses, subnet masks etc, so you can get obscure kinds of breakage. Of course, with the logic that has been bandied around here, that would be cause for banning DHCP :-) 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 iD4DBQE+IRquW6pHgIdAuOMRAtKrAJ0aEbuqCAprdpTRAxPb18E4GQgfkgCYi/CG QHqq+H+a+yOWGsIH5T+TBw== =poR1 -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Sun Jan 12 13:46:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13140 for ; Sun, 12 Jan 2003 13:46:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BADE291211; Sun, 12 Jan 2003 13:49:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92E569121B; Sun, 12 Jan 2003 13:49: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 88EFB91211 for ; Sun, 12 Jan 2003 13:49:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 777FB5DEEE; Sun, 12 Jan 2003 13:49:51 -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 CB60F5DEE6 for ; Sun, 12 Jan 2003 13:49:50 -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 h0CInoI23836; Sun, 12 Jan 2003 11:49:50 -0700 Date: Sun, 12 Jan 2003 11:49:49 -0700 Subject: Re: Suitability of v4LL in a managed network [was Application software needs to be "zeroconf-aware"?] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Zeroconf To: Robert Elz From: Alex Karahalios In-Reply-To: <15562.1042356994@munnari.OZ.AU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Robert, Sorry for not making this clear, but in reality the devices I am working on actually do have a complete DHCP client implementation. In many environments that they are run, however, there are no DHCP servers and that is the reason that ZEROCONF looks promising. The DHCP code requires about 2K bytes which is about 6% of the of the code space. The appeal of ZEROCONF is not just the v4LL aspect, but rather the entire service discovery mechanism which can be provided by mDNS and DNS-SD. Alex Karahalios On Sunday, January 12, 2003, at 12:36 AM, Robert Elz wrote: > A dhcp client for a simple device is really a very trivial piece of > code. > And if that proves too much (perhaps lease renewal is just too > difficult > for some reason), then you could at least do BOOTP (which is about as > simple as possible to imagine for the client). > From owner-zeroconf@merit.edu Mon Jan 13 14:24:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20881 for ; Mon, 13 Jan 2003 14:24:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AFB0A91227; Mon, 13 Jan 2003 14:28:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 87AC59122A; Mon, 13 Jan 2003 14:28: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 97E4891227 for ; Mon, 13 Jan 2003 14:28:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A3E55DF42; Mon, 13 Jan 2003 14:28: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 E46AF5DE09 for ; Mon, 13 Jan 2003 14:28: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 h0DJS0w26056 for ; Mon, 13 Jan 2003 11:28:01 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 13 Jan 2003 11:27:30 -0800 Received: from [17.219.194.156] (vpn-scv-x4-156.apple.com [17.219.194.156]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id h0DJRxf19503; Mon, 13 Jan 2003 11:27:59 -0800 (PST) Message-Id: <200301131927.h0DJRxf19503@scv3.apple.com> Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Date: Mon, 13 Jan 2003 11:28:01 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Robert Elz" Cc: "Erik Nordmark" , , "Thomas Narten" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Robert Elz wrote: >2131 says to broadcast an ARP *reply* to announce a new address >that is what all DHCP clients do. That is what *all* DHCP clients do? On what basis do you make this assertion? When I checked with a packet sniffer, this is what I found: Mac OS uses ARP Request. Windows uses ARP Request. BSD uses ARP Request. Which operating systems have you found that announce new addresses using ARP reply? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Mon Jan 13 14:30:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21099 for ; Mon, 13 Jan 2003 14:30:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CD8939122A; Mon, 13 Jan 2003 14:33:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 996EB9122C; Mon, 13 Jan 2003 14: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 85ED99122A for ; Mon, 13 Jan 2003 14:33:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0505C5DF36; Mon, 13 Jan 2003 14:33:58 -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 561805DE39 for ; Mon, 13 Jan 2003 14:33:57 -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 h0DJXuw27738 for ; Mon, 13 Jan 2003 11:33:56 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 13 Jan 2003 11:33:56 -0800 Received: from [17.219.194.156] (vpn-scv-x4-156.apple.com [17.219.194.156]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id h0DJXtQ17828 for ; Mon, 13 Jan 2003 11:33:55 -0800 (PST) Message-Id: <200301131933.h0DJXtQ17828@scv2.apple.com> Subject: Re: IESG draft-cheshire-ipv4-acd-02.txt Date: Mon, 13 Jan 2003 11:33:58 -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 >So, what's out of spec, other than the acd draft? (In theory, >if everyone did ARP exactly as specified, the request should >also suffice instead of a reply (though it is a perverse kind of >"request") - but in practice, ARP implementations don't tend to >conform exactly to the spec, sending ARP reply (unsolicited reply) >works...) I propose adding the following text to the draft: Why are ARP Announcements performed using ARP Request packets and not ARP Reply packets? There are two reasons, one is historical precedent, and the other is practicality. The historical precedent is that Gratuitous ARP is described in Stevens Networking [Ste94] as using ARP Request packets. What Stevens describes as Gratuitous ARP is what this document calls an ARP Announcement. BSD Unix, Windows, Mac OS 9, Mac OS X, etc. all use ARP Request packets as described in Stevens. At this stage, trying to mandate that they all switch to using ARP Reply packets would be futile. The practical reason is that ARP Request packets are more likely to work correctly with more existing ARP implementations, some of which may not implement RFC 826 correctly. The Packet Reception rules in RFC 826 state that the opcode is the last thing to check in packet processing, so it really shouldn't matter, but there may be "creative" implementations that have different packet processing depending on the ar$op field, and there are several reasons why these are more likely to accept gratuitous ARP Requests than gratuitous ARP Replies: * An incorrect ARP implementation may expect that ARP Replies are only sent via unicast. RFC 826 does not say this, but an incorrect implementation may assume it, and the "principle of least surprise" dictates that where there are two or more ways to solve a networking problem that are otherwise equally good, the one with the fewest unusual properties is the one likely to have the fewest interoperability problems with existing implementations. An ARP Announcement needs to broadcast information to all hosts on the link. Since ARP Request packets are always broadcast, and ARP Reply packets are not, receiving an ARP Request packet via broadcast is less surprising than receiving an ARP Reply packet via broadcast. * An incorrect ARP implementation may expect that ARP Replies are only received in response to ARP Requests that have been issued recently by that implementation. Unexpected unsolicited Replies may be ignored. * An incorrect ARP implementation may ignore ARP Replies where ar$tha doesn't match its hardware address. * An incorrect ARP implementation may ignore ARP Replies where if ar$tpa doesn't match its IP address. In summary, there are more ways that an incorrect ARP implementation might plausibly reject an ARP Reply (which usually occurs as a result of being solicited by the client) than an ARP Request (which is already expected to occur unsolicited). Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * Chairman, IETF Zeroconf * www.stuartcheshire.org From owner-zeroconf@merit.edu Mon Jan 13 14:50:50 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21545 for ; Mon, 13 Jan 2003 14:50:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 315A69122C; Mon, 13 Jan 2003 14:53:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF5469122D; Mon, 13 Jan 2003 14:53: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 E311B9122C for ; Mon, 13 Jan 2003 14:53:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id CADD75DF10; Mon, 13 Jan 2003 14:53:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 3AB755DF0E for ; Mon, 13 Jan 2003 14:53:57 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0DJp0P20485; Mon, 13 Jan 2003 13:51:02 -0600 (CST) Date: Mon, 13 Jan 2003 13:53:50 -0600 Subject: ARP reply vs. ARP request to announce address acquired from DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Thomas Narten , zeroconf@merit.edu, Stuart Cheshire , dhcwg@ietf.org To: Erik Nordmark From: Ted Lemon In-Reply-To: <27AECC89-2389-11D7-8FB4-00039367340A@nominum.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> So were you commenting on the probe or the announcement? > > The announcement. All DHCP clients that I know of do the reply > instead of the request - i.e., they're out of spec. :'} So, just to be clear about my faux pas last week, RFC2131 says to do an ARP *reply* to announce that it has its new IP address, but existing clients send an ARP *request* with the newly-acquired DHCP address in source and destination IP address fields - for example, here's what Win98SE transmits (I have a 10baseT switch that filters unicasts, so I only got the broadcasts): 13:33:08.865011 0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] xid:0xea456228 vend-rfc1048 DHCP:REQUEST CID:01:00:03:ff:66:34:0a RQ:10.0.1.5 SID:10.0.1.1 HN:"Windows 98SE^@" FQDN:0.0.0.87.105.110.100.111.119.115.32.57.56.83.69.0 VC:77.83.70.84.32.57.56 PR:SM+DN+DG+NS+WNS+WNT+WSC+VO+CLASS (ttl 128, id 256, len 346) 13:33:08:925932 arp who-has 10.0.1.5 tell 10.0.1.5 This is what is recommended in the Stevens TCP/IP book. I think the reason this is so common is that the ARP announcement is part of the interface configuration process, and is not done by the DHCP client, so the people that read the DHCP spec aren't the ones that write the code that does the announcement. This is certainly the case with the ISC DHCP client. On Unix systems of which I am aware, it's not possible to do ARP processing outside the kernel. Since the ISC DHCP client runs on Unix, it's pretty much stuck with whatever the operating system provides. So in fact all the DHCP clients of which I am aware are technically out of spec with RFC2131. I don't think this is a big problem, or that RFC2131 needs to be immediately updated. The language in RFC2131 is specifying generic behavior that all IP stacks should implement regardless of whether or not they support DHCP, and therefore RFC2131's recommendation is just that - a recommendation. So it's actually very helpful that Stuart is coming out with a document that's not DHCP-specific that states how this should be done, and it's also fine that it contradicts the recommendation stated in RFC2131. I'm not sure we need to say that this draft updates RFC2131 - I leave that up to those more knowledgable about the IETF process to decide. From owner-zeroconf@merit.edu Mon Jan 13 15:21:09 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22710 for ; Mon, 13 Jan 2003 15:21:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6678D9122E; Mon, 13 Jan 2003 15:24:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3005591230; Mon, 13 Jan 2003 15:24: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 3401C9122E for ; Mon, 13 Jan 2003 15:24:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 192635DEA3; Mon, 13 Jan 2003 15:24:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta06ps.bigpond.com (mta06ps.bigpond.com [144.135.25.138]) by segue.merit.edu (Postfix) with ESMTP id A05415DF5D for ; Mon, 13 Jan 2003 15:24:14 -0500 (EST) Received: from pc-00206 ([144.135.25.69]) by mta06ps.bigpond.com (Netscape Messaging Server 4.15 mta06ps May 23 2002 23:53:28) with SMTP id H8O60A00.6MX; Tue, 14 Jan 2003 06:24:10 +1000 Received: from CPE-203-51-31-46.nsw.bigpond.net.au ([203.51.31.46]) by PSMAM01.mailsvc.email.bigpond.com(MailRouter V3.0n 71/8114252); 14 Jan 2003 06:24:10 From: Brad Hards To: Ted Lemon Subject: Re: ARP reply vs. ARP request to announce address acquired from DHCP Date: Tue, 14 Jan 2003 07:10:26 +1100 User-Agent: KMail/1.4.5 Cc: zeroconf@merit.edu, dhcwg@ietf.org 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: <200301140710.27162.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 14 Jan 2003 06:53, Ted Lemon wrote: > DHCP client. On Unix systems of which I am aware, it's not possible > to do ARP processing outside the kernel. Since the ISC DHCP client > runs on Unix, it's pretty much stuck with whatever the operating system > provides. It may not be possible on all Unix systems, but it _is_ possible to do general ARP processing on many systems. We do this on zcip (http://zeroconf.sf.net), which runs in userspace. It does take some BSD type kernel extensions, but they are provided by the various BSDs ([free, net, open]) and Linux systems. I'm not sure about other unices. 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+Ix0yW6pHgIdAuOMRAvpjAJ0WtTiCOg6h07b1uY4z4qjSLDMtnQCfTXJg UFCf4HCrmvF99ceDVMEb7Gs= =LDww -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Mon Jan 13 22:24:46 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02966 for ; Mon, 13 Jan 2003 22:24:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BA0EB91244; Mon, 13 Jan 2003 22:27:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83AA091245; Mon, 13 Jan 2003 22:27:55 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7187591244 for ; Mon, 13 Jan 2003 22:27:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4ABC75DE04; Mon, 13 Jan 2003 22:27:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id F01ED5DDD1 for ; Mon, 13 Jan 2003 22:27:53 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0E3OrP23230; Mon, 13 Jan 2003 21:24:53 -0600 (CST) Date: Mon, 13 Jan 2003 21:27:46 -0600 Subject: Re: [dhcwg] ARP reply vs. ARP request to announce address acquired from DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org, Stuart Cheshire , zeroconf@merit.edu, Thomas Narten , Erik Nordmark To: Thamer Al-Harbash From: Ted Lemon In-Reply-To: Message-Id: <2681ABD0-2770-11D7-A7EA-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The thing that is missing on the Unix side is not the ability to *send* an ARP packet, but the ability to see the reply. It didn't work when I looked at it ~five years ago, and I haven't bothered since. I'll bet that when dhcpcd configures the interface, it generates the ARP request anyway, even though dhcpcd is sending an ARP reply. From owner-zeroconf@merit.edu Tue Jan 14 00:20:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05307 for ; Tue, 14 Jan 2003 00:20:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D09D791246; Tue, 14 Jan 2003 00:23:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A055391249; Tue, 14 Jan 2003 00:23: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 A074A91246 for ; Tue, 14 Jan 2003 00:23:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B8785DE1F; Tue, 14 Jan 2003 00:23:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 3B8A45DD90 for ; Tue, 14 Jan 2003 00:23:17 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0E5KJP24802; Mon, 13 Jan 2003 23:20:19 -0600 (CST) Date: Mon, 13 Jan 2003 23:23:12 -0600 Subject: Re: [dhcwg] ARP reply vs. ARP request to announce address acquired from DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Erik Nordmark , Thomas Narten , zeroconf@merit.edu, Stuart Cheshire , dhcwg@ietf.org To: Thamer Al-Harbash From: Ted Lemon In-Reply-To: Message-Id: <46C63EDB-2780-11D7-A7EA-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I can't think of any packet capturing facility that would not let > you see ARP. dhcp-agent happily ARPs. In -current you can find > the code in dhcp-arp-discovery.c BPF wasn't passing arp-reply packets at the time. Perhaps it does now, or perhaps it's handled differently in lpf. I thought it was rather odd at the time, but at the time fixing it wasn't my main priority, so I didn't look any further. > I can test against BSD and Solaris too but serial conning them is > too much of a pain right now :-) Were you using a windows box to > with your earlier test? BSD definitely sends the ARP - I've captured it in packet traces when debugging. Dunno for sure about Solaris, but it uses the BSD stack, so it probably does. Linux doesn't use the BSD stack, which perhaps explains the discrepancy - it could be that Stevens was reporting what the BSD stack was already doing, rather than recommending what it *should* do. So the question is, what does this tell us? Are you saying that Stuart's proposal is not the right way to go, or just pointing out new information? I have to say that I find Stuart's rationale for sending an ARP request rather than a reply fairly convincing. From owner-zeroconf@merit.edu Tue Jan 14 01:01:18 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06197 for ; Tue, 14 Jan 2003 01:01:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1BF2E9124F; Tue, 14 Jan 2003 01:04:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3AF19124B; Tue, 14 Jan 2003 01:04: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 2115A9124F for ; Tue, 14 Jan 2003 01:03:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 00D1E5E0AA; Tue, 14 Jan 2003 01:03:25 -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 A4DBB5E0A8 for ; Tue, 14 Jan 2003 01:03:24 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0E60OP25224; Tue, 14 Jan 2003 00:00:24 -0600 (CST) Date: Tue, 14 Jan 2003 00:03:18 -0600 Subject: Re: [dhcwg] ARP reply vs. ARP request to announce address acquired from DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org, Stuart Cheshire , zeroconf@merit.edu, Thomas Narten , Erik Nordmark To: Thamer Al-Harbash 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 > No need to update the RFC for this. Just send an ARP reply from > the client and let the OS send all the requests it wants :-) That's a fine engineering solution, but it's a lousy protocol solution - we can't specify two broadcasts. A better way to phrase my question would be, "are you objecting to what is specified in Stuart's draft?" From owner-zeroconf@merit.edu Tue Jan 14 09:20:59 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24800 for ; Tue, 14 Jan 2003 09:20:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2A3FA91220; Tue, 14 Jan 2003 09:24:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA38B91279; Tue, 14 Jan 2003 09:24: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 DC41791220 for ; Tue, 14 Jan 2003 09:24:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id BC89C5DF6A; Tue, 14 Jan 2003 09:24:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 4F69F5DDA2 for ; Tue, 14 Jan 2003 09:24:09 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn1-158.cisco.com [10.82.224.158]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0EENOjT008423; Tue, 14 Jan 2003 06:23:24 -0800 (PST) Message-Id: <4.3.2.7.2.20030114083851.01e616a8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 Jan 2003 09:23:57 -0500 To: Ted Lemon From: John Schnizlein Subject: Re: ARP reply vs. ARP request to announce address acquired from DHCP Cc: Erik Nordmark , Thomas Narten , zeroconf@merit.edu, dhcwg@ietf.org In-Reply-To: References: <27AECC89-2389-11D7-8FB4-00039367340A@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk I am uncomfortable with the attribution of out-of-spec for DHCP clients. Since the recommendation (SHOULD) to send an ARP-reply is in the context of the client (excerpt below) checking that the offered address is actually available, the ARP-request, which you say most clients perform, appears perfectly reasonable. Since, without the ARP-request the client cannot send a DHCP-decline, it seems the ARP-request is desirable. In fact, performing both the ARP-request and the ARP-reply avoids the appearance of an unsolicited ARP on a network segment, which could be an attempt to steal an IP address. My opinion is that the ARP-announce, an ARP-reply without an ARP-request, would be questionable, and I was happy to see the ZeroConf specification moving away from it. RFC 2131 [Page 38 & 39] ... The client SHOULD perform a check on the suggested address to ensure that the address is not already in use. For example, if the client is on a network that supports ARP, the client may issue an ARP request for the suggested request. When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender's hardware address, and 0 as the sender's IP address, to avoid confusing ARP caches in other hosts on the same subnet. If the network address appears to be in use, the client MUST send a DHCPDECLINE message to the server. 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. John At 02:53 PM 1/13/2003, Ted Lemon wrote: >>>So were you commenting on the probe or the announcement? >> >>The announcement. All DHCP clients that I know of do the reply instead of the request - i.e., they're out of spec. :'} > >So, just to be clear about my faux pas last week, RFC2131 says to do an ARP *reply* to announce that it has its new IP address, but existing clients send an ARP *request* with the newly-acquired DHCP address in source and destination IP address fields ... > >So in fact all the DHCP clients of which I am aware are technically out of spec with RFC2131. I don't think this is a big problem, or that RFC2131 needs to be immediately updated. The language in RFC2131 is specifying generic behavior that all IP stacks should implement regardless of whether or not they support DHCP, and therefore RFC2131's recommendation is just that - a recommendation. So it's actually very helpful that Stuart is coming out with a document that's not DHCP-specific that states how this should be done, and it's also fine that it contradicts the recommendation stated in RFC2131. I'm not sure we need to say that this draft updates RFC2131 - I leave that up to those more knowledgable about the IETF process to decide. From owner-zeroconf@merit.edu Wed Jan 15 00:53:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23234 for ; Wed, 15 Jan 2003 00:53:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B3877912A3; Wed, 15 Jan 2003 00:56:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CC43912A4; Wed, 15 Jan 2003 00:56: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 A8848912A3 for ; Wed, 15 Jan 2003 00:56:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 744B45DEC8; Wed, 15 Jan 2003 00:56:25 -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 DACDD5DE07 for ; Wed, 15 Jan 2003 00:56:24 -0500 (EST) Received: from nominum.com (cs6625147-195.austin.rr.com [66.25.147.195]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0F5rFP10417; Tue, 14 Jan 2003 23:53:15 -0600 (CST) Date: Tue, 14 Jan 2003 23:56:19 -0600 Subject: Re: ARP reply vs. ARP request to announce address acquired from DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Erik Nordmark , Thomas Narten , zeroconf@merit.edu, dhcwg@ietf.org To: John Schnizlein From: Ted Lemon In-Reply-To: <4.3.2.7.2.20030114083851.01e616a8@wells.cisco.com> Message-Id: <118CA449-284E-11D7-A3B4-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The text there says that the client should send the ARP *request* to check for a conflict. The ARP request is supposed to use an IP address of 0.0.0.0 as the sending station's IP address, so as to avoid asserting that the sending station has the assigned IP address. Only after this ARP request has failed to identify a conflict does the client send a message asserting that it has the IP address it has been assigned. So the client sends two ARP packets - an ARP request and an ARP reply. What the proposed draft does is to change the recommended behavior for asserting an IP address using ARP so that this is done with an ARP request rather than an ARP reply. You should take a look at the zeroconf mailing list archives to see Stuart's proposed text that explains why this is the right thing to do. I'm sorry that some of this stuff got cross-posted to DHCwg and some didn't, so that you don't have the full context. This whole thing is _very_ confusing, so it's a really good thing that Stuart is trying to clarify it. :'} From owner-zeroconf@merit.edu Wed Jan 15 16:48:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11129 for ; Wed, 15 Jan 2003 16:48:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 91864912BC; Wed, 15 Jan 2003 16:51:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6113D912BE; Wed, 15 Jan 2003 16:51: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 5B419912BC for ; Wed, 15 Jan 2003 16:51:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 350C45DFF4; Wed, 15 Jan 2003 16:51:34 -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 D96605DFAA for ; Wed, 15 Jan 2003 16:51:33 -0500 (EST) Received: from nominum.com (cs6625147-195.austin.rr.com [66.25.147.195]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0FLmKP21678; Wed, 15 Jan 2003 15:48:20 -0600 (CST) Date: Wed, 15 Jan 2003 15:51:33 -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 v551) Cc: To: Stuart Cheshire From: Ted Lemon In-Reply-To: <200301131933.h0DJXtQ17828@scv2.apple.com> Message-Id: <8357A528-28D3-11D7-A3B4-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I propose adding the following text to the draft: > > Why are ARP Announcements performed using ARP Request packets and not > ARP Reply packets? > [...] FWIW, I think this text is very helpful, and should be included in the draft. From owner-zeroconf@merit.edu Thu Jan 16 01:18:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22476 for ; Thu, 16 Jan 2003 01:18:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 88E1F91212; Thu, 16 Jan 2003 01:21:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58774912C1; Thu, 16 Jan 2003 01:21: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 03E3C91212 for ; Thu, 16 Jan 2003 01:21:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id D84F55DDA5; Thu, 16 Jan 2003 01:21:21 -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 59AD15DD9C for ; Thu, 16 Jan 2003 01:21:21 -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 WAA09561 for ; Wed, 15 Jan 2003 22:21:20 -0800 (PST) Received: from localhost (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 h0G6LEP00558; Thu, 16 Jan 2003 07:21:14 +0100 (MET) Date: Thu, 16 Jan 2003 01:16:26 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ZEROCONF WG Work Items To: Erik Guttman Cc: zeroconf@merit.edu, Erik Guttman In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > Note: Keith has made his point, repeatedly, that due to application > interoperability considerations there should be a way to simply and > effectively deactiveate v4LL. The IESG has this input. The WG has > chosen not to accept Keith's argument in their submission to the > IESG. It is up to the the IESG to determine how to proceed. So far, > the IESG has not chosen to include the lack of a required mechanism to > deactivate v4LL behavior as one of their considerations for the WG to > address in order to advance the document. This is why this issue > does not appear in the following list. I don't claim to understand what the right thing is to do here because I don't yet know how the WG will respond to #9 in your email. I also haven't seen much discussion about the difference between the link-local addresses that have been deployed for a long time (only used when DHCP doesn't configure an address; disabled when DHCP comes back) and what the document advocates (link-locals used in parallel with DHCP assigned addresses on the same interface). I think the WGs answers to the those questions influence how strong the need is to have a knob to turn of zeroconf. Erik From owner-zeroconf@merit.edu Thu Jan 16 01:18:25 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22493 for ; Thu, 16 Jan 2003 01:18:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BD84B912C1; Thu, 16 Jan 2003 01:21:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90EF1912C2; Thu, 16 Jan 2003 01:21: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 BB1D0912C1 for ; Thu, 16 Jan 2003 01:21:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id A84E25DDB1; Thu, 16 Jan 2003 01:21:28 -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 3EE5A5DD9C for ; Thu, 16 Jan 2003 01:21:28 -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 XAA02777; Wed, 15 Jan 2003 23:21:25 -0700 (MST) Received: from localhost (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 h0G6LLP00575; Thu, 16 Jan 2003 07:21:21 +0100 (MET) Date: Thu, 16 Jan 2003 01:27:02 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Turning off link-locals? To: Brad Hards Cc: Keith Moore , kre@munnari.OZ.AU, zeroconf@merit.edu In-Reply-To: "Your message with ID" <200301111223.21937.bhards@bigpond.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk [Was: Re: Application software needs to be "zeroconf-aware"?] > Not withstanding our differencs in opinion, I'm certainly willing to listen > to a proposal you have for how we might implement a system that stops > IPv4LL addresses from being acquired on a network. I offer the following straw-man: There is a "no" vote and a "yes" vote for enabling link-locals on a link where the "yes" wins over the "no". The "no" vote is the existence of a DHCP server which hands out addresses. The "yes" vote is some new protocol mechanism (could be a multicast query/response, or periodic multicasts). Thus by default the presence of a DHCP server turns off link-locals. But, even in the presence of the DHCP server one box on the network can turn on link-locals. This means that it isn't easy for somebody to turn off link-locals when the intent is to turn the on. A rougue DHCP server can't do that, and an ISP providing DHCP service can do it either - the "yes" vote from the on-link entity will win. Erik From owner-zeroconf@merit.edu Thu Jan 16 02:37:56 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03888 for ; Thu, 16 Jan 2003 02:37:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B663E912C3; Thu, 16 Jan 2003 02:41:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83BEE912C4; Thu, 16 Jan 2003 02:41: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 8022F912C3 for ; Thu, 16 Jan 2003 02:41:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6FA955DDF5; Thu, 16 Jan 2003 02:41:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mta02ps.bigpond.com (mta02ps.bigpond.com [144.135.25.134]) by segue.merit.edu (Postfix) with ESMTP id 091825DDEF for ; Thu, 16 Jan 2003 02:41:04 -0500 (EST) Received: from pc-00206 ([144.135.25.87]) by mta02ps.bigpond.com (Netscape Messaging Server 4.15 mta02ps Jul 16 2002 22:47:55) with SMTP id H8SQOD00.ENJ; Thu, 16 Jan 2003 17:41:01 +1000 Received: from CPE-203-51-31-46.nsw.bigpond.net.au ([203.51.31.46]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0n 125/31294597); 16 Jan 2003 17:41:00 From: Brad Hards To: Erik Nordmark Subject: Re: Turning off link-locals? Date: Thu, 16 Jan 2003 18:27:07 +1100 User-Agent: KMail/1.4.5 Cc: Keith Moore , kre@munnari.OZ.AU, 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: <200301161827.07315.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 16 Jan 2003 11:27, Erik Nordmark wrote: > There is a "no" vote and a "yes" vote for enabling link-locals > on a link where the "yes" wins over the "no". > > The "no" vote is the existence of a DHCP server which hands out addresses. > The "yes" vote is some new protocol mechanism (could be a multicast > query/response, or periodic multicasts). > > Thus by default the presence of a DHCP server turns off link-locals. > But, even in the presence of the DHCP server one box on the network > can turn on link-locals. Some questions, if I may: What happens in the absence of votes? IPv4LL on? Is this some kind of "per interface" setup, rather than disabling on a host? Does the new protocol mechanism default to off? (I assume so, otherwise you haven't changed anything) I assume we are talking about something that can work at the link layer. How would this look over time? Do we have some kind of "aging" of votes? Any thoughts for how long the aging process might take? What happens to a machine that has an IPv4LL address, and gets a "NO" vote? Does it die straight away? 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+Jl7LW6pHgIdAuOMRAvnpAKCbmRmpy+qM3uhs7Pusy1reXtuXeACfcgg6 yABnkYYwVhDW8aqdg3qZsQU= =8PW4 -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Thu Jan 16 05:50:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06831 for ; Thu, 16 Jan 2003 05:50:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0DA0F912C5; Thu, 16 Jan 2003 05:53:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BEDBC912C8; Thu, 16 Jan 2003 05:53: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 BF57D912C5 for ; Thu, 16 Jan 2003 05:53:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id A5CAE5DE1E; Thu, 16 Jan 2003 05:53:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gatekeeper.cam.virata.com (gatekeeper.virata.com [194.129.40.2]) by segue.merit.edu (Postfix) with ESMTP id 1AB915DDCC for ; Thu, 16 Jan 2003 05:53:27 -0500 (EST) Received: from boletus.cam.virata.com (boletus.cam.virata.com [10.7.5.11]) by gatekeeper.cam.virata.com (8.11.6/8.11.6) with ESMTP id h0GASdl08762; Thu, 16 Jan 2003 10:28:39 GMT Received: from mercury.cam.virata.com (mercury.cam.virata.com [10.7.5.13]) by boletus.cam.virata.com (8.9.3/8.9.3/Debian/GNU) with ESMTP id KAA22852; Thu, 16 Jan 2003 10:28:39 GMT Received: from inkcap.cam.virata.com (root@inkcap.cam.virata.com [10.7.9.79]) by mercury.cam.virata.com (8.9.3/8.9.3) with ESMTP id KAA12065; Thu, 16 Jan 2003 10:28:39 GMT Received: from globespanvirata.com (lgd@localhost [127.0.0.1]) by inkcap.cam.virata.com (8.12.6/8.12.6/Debian-8) with ESMTP id h0GASbPS005657; Thu, 16 Jan 2003 10:28:38 GMT Message-ID: <3E268955.1040902@globespanvirata.com> Date: Thu, 16 Jan 2003 10:28:37 +0000 From: Luke Diamand User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: zeroconf@merit.edu Subject: Re: Turning off link-locals? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit What if there is a rogue on-link entity? Won't this have just as bad an effect for people trying to disable link-locals? Luke Diamand > > > I offer the following straw-man: > > There is a "no" vote and a "yes" vote for enabling link-locals > on a link where the "yes" wins over the "no". > > The "no" vote is the existence of a DHCP server which hands out addresses. > The "yes" vote is some new protocol mechanism (could be a multicast > query/response, or periodic multicasts). > > Thus by default the presence of a DHCP server turns off link-locals. > But, even in the presence of the DHCP server one box on the network > can turn on link-locals. > > This means that it isn't easy for somebody to turn off link-locals > when the intent is to turn the on. A rougue DHCP server can't do that, and > an ISP providing DHCP service can do it either - the "yes" vote from the > on-link entity will win. > > Erik > From owner-zeroconf@merit.edu Thu Jan 16 08:04:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08716 for ; Thu, 16 Jan 2003 08:04:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2D1E6912C9; Thu, 16 Jan 2003 08:07:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2A60912CA; Thu, 16 Jan 2003 08:07: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 D09EB912C9 for ; Thu, 16 Jan 2003 08:07:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9BF855E121; Thu, 16 Jan 2003 08:07:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by segue.merit.edu (Postfix) with ESMTP id 79F2C5E0FB for ; Thu, 16 Jan 2003 08:07:17 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18Z9iz-0001Ip-00; Thu, 16 Jan 2003 05:06:25 -0800 Date: Thu, 16 Jan 2003 08:03:03 -0500 From: Keith Moore To: Erik Nordmark Cc: moore@cs.utk.edu, bhards@bigpond.net.au, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030116080303.14bd0eb6.moore@cs.utk.edu> In-Reply-To: References: <200301111223.21937.bhards@bigpond.net.au> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Thu, 16 Jan 2003 01:27:02 +0100 (CET) Erik Nordmark wrote: > [Was: Re: Application software needs to be "zeroconf-aware"?] > > > Not withstanding our differencs in opinion, I'm certainly willing to listen > > to a proposal you have for how we might implement a system that stops > > IPv4LL addresses from being acquired on a network. > > I offer the following straw-man: > > There is a "no" vote and a "yes" vote for enabling link-locals > on a link where the "yes" wins over the "no". > > The "no" vote is the existence of a DHCP server which hands out addresses. > The "yes" vote is some new protocol mechanism (could be a multicast > query/response, or periodic multicasts). interesting idea. some questions: - if the intent of the attacker is to turn *on* v4LL (perhaps to facilitate other attacks, given that v4LL weakens security) doesn't this make such attacks easier? in other words, is it reasonable to consider that the risk of an attacker turning off v4LL for a DoS attack is a significantly larger threat than that of an attacker turning v4LL on for the purpose of a breakin? offhand it seems to me like there are security risks with either a forged "yes" or "no" signal from the net, and they're both ameliorated in the same way - by monitoring the net for rogue transmitters of such signals. if you want anything stronger, you need authentication, which of course requires host configuration... - why could the yes vote not be a DHCP response? is it more reasonble to trust a separate mechanism which presumably could be spoofed just as easily as DHCP, and which adds complexity? or is the idea to force the yes vote to be link-local in scope. (this gets back to the security risks of spoofed yes votes - if the spoofing is inherently local to the link then it's easier to spoof yes votes without being detected - the monitoring has to take place separately for every link) From owner-zeroconf@merit.edu Thu Jan 16 09:40:58 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12418 for ; Thu, 16 Jan 2003 09:40:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 31A16912CD; Thu, 16 Jan 2003 09:44:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0504A912CF; Thu, 16 Jan 2003 09:44: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 0BA0F912CD for ; Thu, 16 Jan 2003 09:44:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id D89115DE0F; Thu, 16 Jan 2003 09:44:07 -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 6C6435DDDE for ; Thu, 16 Jan 2003 09:44:07 -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 h0GEi6J24306 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Thu, 16 Jan 2003 09:44:06 -0500 Message-Id: <5.2.0.9.2.20030116093600.02ec3fc8@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 16 Jan 2003 09:42:41 -0500 To: zeroconf@merit.edu From: Daniel Senie Subject: Re: Turning off link-locals? In-Reply-To: References: <"Your message with ID" <200301111223.21937.bhards@bigpond.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 07:27 PM 1/15/2003, Erik Nordmark wrote: >[Was: Re: Application software needs to be "zeroconf-aware"?] > > > Not withstanding our differencs in opinion, I'm certainly willing to listen > > to a proposal you have for how we might implement a system that stops > > IPv4LL addresses from being acquired on a network. > >I offer the following straw-man: > >There is a "no" vote and a "yes" vote for enabling link-locals >on a link where the "yes" wins over the "no". > >The "no" vote is the existence of a DHCP server which hands out addresses. >The "yes" vote is some new protocol mechanism (could be a multicast >query/response, or periodic multicasts). > >Thus by default the presence of a DHCP server turns off link-locals. >But, even in the presence of the DHCP server one box on the network >can turn on link-locals. > >This means that it isn't easy for somebody to turn off link-locals >when the intent is to turn the on. A rougue DHCP server can't do that, and >an ISP providing DHCP service can do it either - the "yes" vote from the >on-link entity will win. Any mechanism "on the link" which magically turns on link local is inherently MUCH MORE EVIL than having it on by default, in my opinion, and would be a major step backward. Why? If someone REALLY did want to disable LL, you've now provided a way for anyone to plug in (physically or via wireless) to a network, and force themselves in by simply yelling out a few packets. Very bad idea. I am willing to entertain a statement in the LL document which states: "An entity implementing Link Local MAY contain a local configuration option to disable LL. Further it MAY contain a local configuration option to disable LL only when DHCP is active. However, a mechanism must be present on that entity for restoring a factory default in which LL is always on. Such mechanism in an embedded system may be a reset button, or on a host environment it could be a configuration menu choice. "In the event LL is disabled by the user using either of these optional configuration switches, the user may be unable to establish communications with devices which operate solely using LL addressing." I believe that covers the bases. The configuration MUST be done on a per device basis if its to be of any value, IMO. From owner-zeroconf@merit.edu Thu Jan 16 14:02:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20876 for ; Thu, 16 Jan 2003 14:02:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0738D912D1; Thu, 16 Jan 2003 14:05:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC429912D2; Thu, 16 Jan 2003 14:05: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 A6657912D1 for ; Thu, 16 Jan 2003 14:05:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8BEDC5DECE; Thu, 16 Jan 2003 14:05:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by segue.merit.edu (Postfix) with ESMTP id 493815DE70 for ; Thu, 16 Jan 2003 14:05:36 -0500 (EST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 16 Jan 2003 11:05:35 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 16 Jan 2003 11:05:35 -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); Thu, 16 Jan 2003 11:05:35 -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); Thu, 16 Jan 2003 11:05:35 -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.3718.0); Thu, 16 Jan 2003 11:05:34 -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: Turning off link-locals? Date: Thu, 16 Jan 2003 11:05:34 -0800 Message-ID: Thread-Topic: Turning off link-locals? thread-index: AcK9bchK1EW9f3dVTtauCxEJShAcBAAIxZPm From: "Christian Huitema" To: X-OriginalArrivalTime: 16 Jan 2003 19:05:34.0742 (UTC) FILETIME=[3F76CB60:01C2BD92] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA20876 >There is a "no" vote and a "yes" vote for enabling link-locals >on a link where the "yes" wins over the "no". > >The "no" vote is the existence of a DHCP server which hands out addresses. >The "yes" vote is some new protocol mechanism (could be a multicast >query/response, or periodic multicasts). There is really a need for two knobs: whether the host will configure a "v4 link local" address on an interface, and if does not configure such an address, whether it will accept to communicate with hosts using v4 LL on the link. A lot of the programming issues arise from having multiple addresses of different scope for the same hosts -- there was an extensive debate on that point in the IPv6 WG. If a global address is available, using just that address has a number of good properties -- as in, it does not break existing applications. So, there is a strong incentive to not configure a LL address when a global address is available, either through static configuration or through DHCP. This would be knob #1. Communicating or not with LL addressed hosts on a given link is a different issue. Even if a host has a configured global address, it could communicate with a LL addressed host; this is equivalent to having two different subnets on the same link, and there are obvious optimisations for LL aware hosts. This communication may be disallowed by a site manager for security reasons, but it may also be allowed in order to gain functionality. This would be knob #2. -- Christian Huitema From owner-zeroconf@merit.edu Thu Jan 16 15:03:25 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22441 for ; Thu, 16 Jan 2003 15:03:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 355409125E; Thu, 16 Jan 2003 15:06:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0312E91261; Thu, 16 Jan 2003 15:06: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 D8E2F9125E for ; Thu, 16 Jan 2003 15:06:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id B6C285DE30; Thu, 16 Jan 2003 15:06:33 -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 6DF915DDF9 for ; Thu, 16 Jan 2003 15:06:33 -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 h0GK6WI24202 for ; Thu, 16 Jan 2003 12:06:32 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 16 Jan 2003 12:06:30 -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 h0GK6Uf20340; Thu, 16 Jan 2003 12:06:30 -0800 (PST) Date: Thu, 16 Jan 2003 12:06:19 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Daniel Senie From: Joshua Graessley In-Reply-To: <5.2.0.9.2.20030116093600.02ec3fc8@mail.amaranth.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Is there a reason that we need all these knobs? What's wrong with just recommending that an interface only acquire an IPv4LL address if it is unable to acquire a global address for an interface? If the device is not configured it should use IPv4LL or maybe default to trying DHCP if it implements DHCP. If the device has any configuration method and that method fails for some reason, the device falls back to IPv4LL. I think the reason the drafts suggest always acquiring an IPv4LL address is historical. The first few drafts suggested that traffic sent to an IPv4LL address must always use an IPv4LL source address. When, after much discussion, that requirement was dropped, the suggestion of always acquiring an IPv4LL was not dropped. I don't think it makes sense to suggest in the document that devices implement an option to disable LL. I think it makes more sense to suggest that devices only acquire an IPv4LL address on interfaces where DHCP or some other mechanism has supplied an address. Devices with global addresses should still be capable of communicating with other devices on the same link that only have an IPv4LL. It is not inconceivable that a simple device may implement only IPv4LL and not DHCP. -josh On Thursday, January 16, 2003, at 06:42 AM, Daniel Senie wrote: > Any mechanism "on the link" which magically turns on link local is > inherently MUCH MORE EVIL than having it on by default, in my opinion, > and would be a major step backward. Why? If someone REALLY did want to > disable LL, you've now provided a way for anyone to plug in > (physically or via wireless) to a network, and force themselves in by > simply yelling out a few packets. Very bad idea. > > I am willing to entertain a statement in the LL document which states: > > "An entity implementing Link Local MAY contain a local configuration > option to disable LL. Further it MAY contain a local configuration > option to disable LL only when DHCP is active. However, a mechanism > must be present on that entity for restoring a factory default in > which LL is always on. Such mechanism in an embedded system may be a > reset button, or on a host environment it could be a configuration > menu choice. > > "In the event LL is disabled by the user using either of these > optional configuration switches, the user may be unable to establish > communications with devices which operate solely using LL addressing." From owner-zeroconf@merit.edu Thu Jan 16 15:06:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22527 for ; Thu, 16 Jan 2003 15:06:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9AB5891261; Thu, 16 Jan 2003 15:09:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E7BF912D2; Thu, 16 Jan 2003 15:09: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 80E0491261 for ; Thu, 16 Jan 2003 15:09:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 68BA35DDF9; Thu, 16 Jan 2003 15:09:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id E14395DDAF for ; Thu, 16 Jan 2003 15:09:41 -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 h0GK9fw08010 for ; Thu, 16 Jan 2003 12:09:41 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 16 Jan 2003 12:09:41 -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 h0GK9eQ08097 for ; Thu, 16 Jan 2003 12:09:40 -0800 (PST) Date: Thu, 16 Jan 2003 12:09:31 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <6C7E1C6E-298E-11D7-955F-000393760260@apple.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, January 16, 2003, at 11:05 AM, Christian Huitema wrote: >> There is a "no" vote and a "yes" vote for enabling link-locals >> on a link where the "yes" wins over the "no". >> >> The "no" vote is the existence of a DHCP server which hands out >> addresses. >> The "yes" vote is some new protocol mechanism (could be a multicast >> query/response, or periodic multicasts). > > There is really a need for two knobs: whether the host will configure > a "v4 link local" address on an interface, and if does not configure > such an address, whether it will accept to communicate with hosts > using v4 LL on the link. > > A lot of the programming issues arise from having multiple addresses > of different scope for the same hosts -- there was an extensive debate > on that point in the IPv6 WG. If a global address is available, using > just that address has a number of good properties -- as in, it does > not break existing applications. So, there is a strong incentive to > not configure a LL address when a global address is available, either > through static configuration or through DHCP. This would be knob #1. Does this need to be a knob? Can we just recommend that devices not acquire an IPv4LL if they get a global address? Is there ever a case where it's better to have an IPv4LL address in addition to the global address? > Communicating or not with LL addressed hosts on a given link is a > different issue. Even if a host has a configured global address, it > could communicate with a LL addressed host; this is equivalent to > having two different subnets on the same link, and there are obvious > optimisations for LL aware hosts. This communication may be disallowed > by a site manager for security reasons, but it may also be allowed in > order to gain functionality. This would be knob #2. Is this knob necessary? I don't believe anyone has presented a case where IPv4LL addresses introduce additional security risks. -josh From owner-zeroconf@merit.edu Thu Jan 16 16:05:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23944 for ; Thu, 16 Jan 2003 16:05:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 177CF912D6; Thu, 16 Jan 2003 16:07:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA795912D9; Thu, 16 Jan 2003 16:07:51 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F16B5912D6 for ; Thu, 16 Jan 2003 16:07:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id DD6B45DE65; Thu, 16 Jan 2003 16:07:47 -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 9BF275DE4E for ; Thu, 16 Jan 2003 16:07: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 h0GL7hJ12376 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Thu, 16 Jan 2003 16:07:43 -0500 Message-Id: <5.2.0.9.2.20030116155030.03005e80@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 16 Jan 2003 15:55:55 -0500 To: Joshua Graessley From: Daniel Senie Subject: Re: Turning off link-locals? Cc: zeroconf@merit.edu In-Reply-To: References: <5.2.0.9.2.20030116093600.02ec3fc8@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 03:06 PM 1/16/2003, Joshua Graessley wrote: >Is there a reason that we need all these knobs? What's wrong with just >recommending that an interface only acquire an IPv4LL address if it is >unable to acquire a global address for an interface? What's wrong, is that limits the ability to develop a class of devices that ONLY operates in the linklocal addressing block. There is a great deal of interest in such devices, and, IMO, no good reason to preclude such from the market. > If the device is not configured it should use IPv4LL or maybe default to > trying DHCP if it implements DHCP. If the device has any configuration > method and that method fails for some reason, the device falls back to IPv4LL. So how does your desktop machine, which DID get a DHCP address talk to a device which does not support anything but LL addressing? Think about BOTH ends of a communication, not just one. >I think the reason the drafts suggest always acquiring an IPv4LL address >is historical. I disagree. > The first few drafts suggested that traffic sent to an IPv4LL address > must always use an IPv4LL source address. Indeed, I'd prefer if we stuck with this, as it would simplify a number of matters. >When, after much discussion, that requirement was dropped, the suggestion >of always acquiring an IPv4LL was not dropped. How does one talk between a DHCP address and a LL address if there's an LL-only device? Without a local way to do so, you're cooked. The LL address space is NOT supposed to be routed. So it's essential that if an LL device is going to talk with a device with a non-LL address, the box with the non-LL address must also have an LL address. >I don't think it makes sense to suggest in the document that devices >implement an option to disable LL. I think it makes more sense to suggest >that devices only acquire an IPv4LL address on interfaces where DHCP or >some other mechanism has supplied an address. Devices with global >addresses should still be capable of communicating with other devices on >the same link that only have an IPv4LL. HOW? THAT is the issue. You have to do it without a router, which means the device with a DHCP or other non-LL address MUST have an LL address to be able to communicate. > It is not inconceivable that a simple device may implement only IPv4LL > and not DHCP. Precisely. Now work backward with that assumption and think about how packets will get between that simple device and a desktop computer. >-josh > >On Thursday, January 16, 2003, at 06:42 AM, Daniel Senie wrote: > >>Any mechanism "on the link" which magically turns on link local is >>inherently MUCH MORE EVIL than having it on by default, in my opinion, >>and would be a major step backward. Why? If someone REALLY did want to >>disable LL, you've now provided a way for anyone to plug in (physically >>or via wireless) to a network, and force themselves in by simply yelling >>out a few packets. Very bad idea. >> >>I am willing to entertain a statement in the LL document which states: >> >>"An entity implementing Link Local MAY contain a local configuration >>option to disable LL. Further it MAY contain a local configuration option >>to disable LL only when DHCP is active. However, a mechanism must be >>present on that entity for restoring a factory default in which LL is >>always on. Such mechanism in an embedded system may be a reset button, or >>on a host environment it could be a configuration menu choice. >> >>"In the event LL is disabled by the user using either of these optional >>configuration switches, the user may be unable to establish >>communications with devices which operate solely using LL addressing." > From owner-zeroconf@merit.edu Thu Jan 16 19:17:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27293 for ; Thu, 16 Jan 2003 19:17:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3186C9126A; Thu, 16 Jan 2003 19:20:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 054F89126B; Thu, 16 Jan 2003 19:20: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 0773C9126A for ; Thu, 16 Jan 2003 19:20:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id D53735DE59; Thu, 16 Jan 2003 19:20:25 -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 54E1E5DDD2 for ; Thu, 16 Jan 2003 19:20:25 -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 h0H0KOI20889 for ; Thu, 16 Jan 2003 16:20:24 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 16 Jan 2003 16:19:54 -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 h0H0KNs18364 for ; Thu, 16 Jan 2003 16:20:24 -0800 (PST) Date: Thu, 16 Jan 2003 16:20:13 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <5.2.0.9.2.20030116155030.03005e80@mail.amaranth.net> Message-Id: <7299E192-29B1-11D7-9F03-000393760260@apple.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, January 16, 2003, at 12:55 PM, Daniel Senie wrote: > At 03:06 PM 1/16/2003, Joshua Graessley wrote: > > >> Is there a reason that we need all these knobs? What's wrong with >> just recommending that an interface only acquire an IPv4LL address if >> it is unable to acquire a global address for an interface? > > What's wrong, is that limits the ability to develop a class of devices > that ONLY operates in the linklocal addressing block. There is a great > deal of interest in such devices, and, IMO, no good reason to preclude > such from the market. I don't see how this precludes such class of products. See below. >> If the device is not configured it should use IPv4LL or maybe >> default to trying DHCP if it implements DHCP. If the device has any >> configuration method and that method fails for some reason, the >> device falls back to IPv4LL. > > So how does your desktop machine, which DID get a DHCP address talk to > a device which does not support anything but LL addressing? Think > about BOTH ends of a communication, not just one. If my desktop machine is LL aware, it should have no difficulty communicating with a device supporting only LL addressing. Section 1.7, Communication Between Link-Local and Routable Addresses, covers this with an example of a laptop with a global address only communicating with a web server with a global address to retrieve a page and printing that page to a printer with an IPv4LL on the local link. >> I think the reason the drafts suggest always acquiring an IPv4LL >> address is historical. > > I disagree. The original argument for requiring link local addresses all the time was to communicate with other nodes that may have nothing but a link local address. This was necessary because the first drafts required that traffic to a link local address have a link local address as the source. Without a link local address, you couldn't communicate with another node that had only a link local address. That restriction has been lifted. >> The first few drafts suggested that traffic sent to an IPv4LL >> address must always use an IPv4LL source address. > > Indeed, I'd prefer if we stuck with this, as it would simplify a > number of matters. Perhaps, perhaps not. If by allowing communication between nodes on the same local link with a mixture of global and link local addresses, a node only needs one global or one link local address, it also seems to simplify things. >> When, after much discussion, that requirement was dropped, the >> suggestion of always acquiring an IPv4LL was not dropped. > > How does one talk between a DHCP address and a LL address if there's > an LL-only device? Without a local way to do so, you're cooked. The LL > address space is NOT supposed to be routed. So it's essential that if > an LL device is going to talk with a device with a non-LL address, the > box with the non-LL address must also have an LL address. If both nodes are on the local link, the node with the global address, if link local aware, should know to arp for the address instead of sending it to a gateway. The node with the link local address knows to arp for any address. >> I don't think it makes sense to suggest in the document that devices >> implement an option to disable LL. I think it makes more sense to >> suggest that devices only acquire an IPv4LL address on interfaces >> where DHCP or some other mechanism has supplied an address. Devices >> with global addresses should still be capable of communicating with >> other devices on the same link that only have an IPv4LL. > > HOW? THAT is the issue. You have to do it without a router, which > means the device with a DHCP or other non-LL address MUST have an LL > address to be able to communicate. See section 2.6, second paragraph. >> It is not inconceivable that a simple device may implement only >> IPv4LL and not DHCP. > > Precisely. Now work backward with that assumption and think about how > packets will get between that simple device and a desktop computer. -josh From owner-zeroconf@merit.edu Fri Jan 17 03:47:48 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15761 for ; Fri, 17 Jan 2003 03:47:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5BD4391217; Fri, 17 Jan 2003 03:50:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED063912E6; Fri, 17 Jan 2003 03:50: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 A396A91217 for ; Fri, 17 Jan 2003 03:50:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 926755DDD1; Fri, 17 Jan 2003 03:50:12 -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 E924F5DDC0 for ; Fri, 17 Jan 2003 03:50:11 -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 AAA21106; Fri, 17 Jan 2003 00:50:09 -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 h0H8o7l08893; Fri, 17 Jan 2003 09:50:07 +0100 (MET) Date: Fri, 17 Jan 2003 09:50:07 +0100 (CET) From: Erik Guttman X-Sender: erikg@field Reply-To: Erik Guttman To: Joshua Graessley Cc: Daniel Senie , zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Thu, 16 Jan 2003, Joshua Graessley wrote: > > Is there a reason that we need all these knobs? What's wrong with just > recommending that an interface only acquire an IPv4LL address if it is > unable to acquire a global address for an interface? If the device is > not configured it should use IPv4LL or maybe default to trying DHCP if > it implements DHCP. If the device has any configuration method and that > method fails for some reason, the device falls back to IPv4LL. > > I think the reason the drafts suggest always acquiring an IPv4LL > address is historical. The first few drafts suggested that traffic sent > to an IPv4LL address must always use an IPv4LL source address. When, > after much discussion, that requirement was dropped, the suggestion of > always acquiring an IPv4LL was not dropped. > > I don't think it makes sense to suggest in the document that devices > implement an option to disable LL. I think it makes more sense to > suggest that devices only acquire an IPv4LL address on interfaces where > DHCP or some other mechanism has supplied an address. Devices with > global addresses should still be capable of communicating with other > devices on the same link that only have an IPv4LL. It is not > inconceivable that a simple device may implement only IPv4LL and not > DHCP. Josh, I think this is a reasonable direction to pursue. The arguments for IPv4LL being independent from DHCP configuration are presented below with some rebuttal. I present the case from both sides, leaning to supporting your position. - If a host uses IPv4LL then drops this address configuration when DHCP address configuration occurs (which older Macs do, and hosts running Windows do), communication with these hosts gets disrupted at the time that the DHCP configuration occurs. Example: Home gateway turned on. One could argue that if apps have to deal with address reconfiguration to properly function over IPv4LL, then dealing with transition from IPv4LL to DHCP configured address should work too. - There are environments in which DHCP doesn't work (more than one DHCP server is running at once). It would be nice if local communication could continue in this case. Example: Some geeky households have a cable modem, a home gateway, a... which can mean more than one DHCP server. One could argue that such a case is disfunctional and should never occur in reality. It does occur, but even then, it lasts only as long as it takes to turn off the undesired server(s). - Hosts will reconfigure at different times due to DHCP, so there may be a period in which one host will have IPv4LL and another will not. This is inconvenient, but not fatal. - If there are some hosts which use IPv4LL only, others have to support IPv4LL to communicate with them, in any case. This support may be limited to support for a stack to use ARP to resolve addresses in the LL range, and forward traffic to the link instead of to a router. Am I missing anything? Erik From owner-zeroconf@merit.edu Fri Jan 17 04:01:48 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15967 for ; Fri, 17 Jan 2003 04:01:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 74C3C912DD; Fri, 17 Jan 2003 04:04:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B72A912DF; Fri, 17 Jan 2003 04:04: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 4A677912DD for ; Fri, 17 Jan 2003 04:04:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C4065DE10; Fri, 17 Jan 2003 04:04:58 -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 A44F25DDFB for ; Fri, 17 Jan 2003 04:04:57 -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 CAA21208; Fri, 17 Jan 2003 02:04:56 -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 h0H94sl09378; Fri, 17 Jan 2003 10:04:54 +0100 (MET) Date: Fri, 17 Jan 2003 10:04:53 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Joshua Graessley Cc: zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: <6C7E1C6E-298E-11D7-955F-000393760260@apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Josh, On Thu, 16 Jan 2003, Joshua Graessley wrote: > Is this knob necessary? I don't believe anyone has presented a case > where IPv4LL addresses introduce additional security risks. There are some additional security risks which were raised in the IESG comments. First: If a multihomed host determines its LL configuration on one interface by address information on another, it is possible that an attacker on one link could force a host to perform address reconfiguration on a different link. This is a distributed attack which was not possible without v4LL. Section 3.2 suggests that a single address could be used for all interfaces. Forcing a conflict with the host's address on any interface will cause reconfiguration on all of them. Section 3.3 suggests that different addresses be used for each interface. Even here, an attacker can force a conflict with an address which is configured for the address configured on a different link and cause address reconfiguration to occur there. Second: There is concern that v4LL enables selective reconfiguration of a host. This will disrupt all communication with the host. This is a different attack than ARP spoofing which can redirect or disrupt communication to a host, but does not change the state of the host or break its transport level connections. Third: This is a concern of 'degree' not 'kind,' concerning wireless interfaces. Since it will be much easier for hosts to communicate with others using v4LL, security flaws of all kinds will be trivially exposed in cases where they were not as easily revealed in the past (on wired networks.) The IESG requested that the document be updated to include remarks on each of these issues. Erik From owner-zeroconf@merit.edu Fri Jan 17 09:24:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22998 for ; Fri, 17 Jan 2003 09:24:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2CB37912ED; Fri, 17 Jan 2003 09:27:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA14A912EE; Fri, 17 Jan 2003 09:27:35 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA5F7912ED for ; Fri, 17 Jan 2003 09:27:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id ACBAE5DE24; Fri, 17 Jan 2003 09:27:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by segue.merit.edu (Postfix) with ESMTP id 8A27C5DDB7 for ; Fri, 17 Jan 2003 09:27:34 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ZXSy-0001tj-00; Fri, 17 Jan 2003 06:27:28 -0800 Date: Fri, 17 Jan 2003 09:24:06 -0500 From: Keith Moore To: "Christian Huitema" Cc: moore@cs.utk.edu, bhards@bigpond.net.au, vlubet@apple.com, zeroconf@merit.edu Subject: Re: Suitability of v4LL in a managed network [was Application software needs to be "zeroconf-aware"?] Message-Id: <20030117092406.462a61fb.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Sat, 11 Jan 2003 22:14:45 -0800 "Christian Huitema" wrote: > On Sun, 12 Jan 2003, Brad Hards wrote > > On Sun, 12 Jan 2003 11:22, Vincent Lubet wrote: > >> I agree it's very reasonable not to require an LL address to be > >> assigned when a non LL address is assigned to a network interface. > > http://www.zeroconf.org/w3onwire-zeroconf.pdf contains a good intro to why > > this is needed. > > The referenced document makes three arguments: > > 1) That if a server configuration changes, the clients will cease to > function if they cannot find a server, i.e. resolve the server's name; > > 2) That if a node with only a DHCP configured address will not be able to > communicate with a node that only have an autoconfigured address; > > 3) That there will be simple devices that only have autoconfigured > addresses. > > I would contend that the first argument is a requirement on name resolution, > not on addressing. If you can resove the name, the main drawback of the > transition requirement is the possible instability of addresses. I disagree with this part. Not all apps are client/server (so other cases need to be considered) and some applications find out addresses of their peers by means other than name resolution. Am generally in agreement with the rest of your message. From owner-zeroconf@merit.edu Fri Jan 17 09:28:03 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23055 for ; Fri, 17 Jan 2003 09:28:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0F801912F0; Fri, 17 Jan 2003 09:30:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CEE85912F1; Fri, 17 Jan 2003 09:30: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 AADD3912F0 for ; Fri, 17 Jan 2003 09:30:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6274F5DE28; Fri, 17 Jan 2003 09:30:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from swan.mail.pas.earthlink.net (swan.mail.pas.earthlink.net [207.217.120.123]) by segue.merit.edu (Postfix) with ESMTP id 044E65DDB7 for ; Fri, 17 Jan 2003 09:30:45 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ZXW6-0001aM-00; Fri, 17 Jan 2003 06:30:43 -0800 Date: Fri, 17 Jan 2003 09:27:20 -0500 From: Keith Moore To: Brad Hards Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Suitability of v4LL in a managed network [was Application software needs to be "zeroconf-aware"?] Message-Id: <20030117092720.11aeea31.moore@cs.utk.edu> In-Reply-To: <200301121749.09484.bhards@bigpond.net.au> References: <200301121749.09484.bhards@bigpond.net.au> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Think of it another way. > If you already have a connection to a host with IPv4LL address, and you > become capable of gaining a routable address, it is better to add the > routable address, not replace the IPv4LL address. Dumping a working address > is gratitous breakage for a capable host. depending on a particular app's requirements, a v4LL address might or might not be considered "working". > I think you can have your cake, and eat it too, if you have the right level > of support from your name service code. it is incorrect to assume that address selection can be performed by name service code - first because apps get their addresses by a variety of means, second because the name service code has no idea about the context in (or purpose for) which an address will be used, third because this is overloading an existing interface and will cause breakage for apps that expect the old interface, fourth because it is poor separation of function. From owner-zeroconf@merit.edu Fri Jan 17 09:31:12 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23161 for ; Fri, 17 Jan 2003 09:31:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 949EA912EF; Fri, 17 Jan 2003 09:34:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6000D912EE; Fri, 17 Jan 2003 09:34: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 DC343912EF for ; Fri, 17 Jan 2003 09:33:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id BFC3B5DE28; Fri, 17 Jan 2003 09:33:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by segue.merit.edu (Postfix) with ESMTP id 98F395DDB7 for ; Fri, 17 Jan 2003 09:33:09 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ZXXS-0000Az-00; Fri, 17 Jan 2003 06:32:06 -0800 Date: Fri, 17 Jan 2003 09:28:44 -0500 From: Keith Moore To: Brad Hards Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, Alex@Outersoft.com, zeroconf@merit.edu Subject: Re: Suitability of v4LL in a managed network [was Application software needs to be "zeroconf-aware"?] Message-Id: <20030117092844.11048019.moore@cs.utk.edu> In-Reply-To: <200301121835.10784.bhards@bigpond.net.au> References: <15562.1042356994@munnari.OZ.AU> <200301121835.10784.bhards@bigpond.net.au> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > The problem with DHCP is that it is pretty critical that you have exactly one > server. No servers requires IPv4LL as a fallback, two or more servers can > lead to them handing out conflicting network addresses, subnet masks etc, so > you can get obscure kinds of breakage. Of course, with the logic that has > been bandied around here, that would be cause for banning DHCP :-) or fixing it. but that's not a topic for this working group. Keith From owner-zeroconf@merit.edu Fri Jan 17 09:40:03 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23618 for ; Fri, 17 Jan 2003 09:40:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 53F11912EE; Fri, 17 Jan 2003 09:43:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F44A912F1; Fri, 17 Jan 2003 09:43: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 EF526912EE for ; Fri, 17 Jan 2003 09:43:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id C9D3E5DEA9; Fri, 17 Jan 2003 09:43:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by segue.merit.edu (Postfix) with ESMTP id A9D525DEA7 for ; Fri, 17 Jan 2003 09:43:12 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ZXi9-00025U-00; Fri, 17 Jan 2003 06:43:09 -0800 Date: Fri, 17 Jan 2003 09:39:46 -0500 From: Keith Moore To: Daniel Senie Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030117093946.0f280e1a.moore@cs.utk.edu> In-Reply-To: <5.2.0.9.2.20030116093600.02ec3fc8@mail.amaranth.net> References: <"Your message with ID" <200301111223.21937.bhards@bigpond.net.au> <5.2.0.9.2.20030116093600.02ec3fc8@mail.amaranth.net> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Any mechanism "on the link" which magically turns on link local is > inherently MUCH MORE EVIL than having it on by default, in my opinion, and > would be a major step backward. Why? If someone REALLY did want to disable > LL, you've now provided a way for anyone to plug in (physically or via > wireless) to a network, and force themselves in by simply yelling out a few > packets. Very bad idea. so which is worse: a. a denial of service attack from a local attacker by disabling v4LL b. an attack on a host from a local attacker facilitated by enabling v4LL c. an attack on all IPv4 networks from the zeroconf working group I'd vastly prefer either a or b to c. At least a and b are limited in scope. And it's ridiculous to consider threat a while ignoring threat b. > I am willing to entertain a statement in the LL document which states: That's nice of you. IMHO, a more appropriate statement would be: The zeroconf working group is being abandoned due to gross violations of its charter and failure to produce a document which meets the criteria for proposed standard in RFC 2026. Now will you please stop pretending that you have the right to impose this stuff on every host in the Internet? From owner-zeroconf@merit.edu Fri Jan 17 09:46:08 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23929 for ; Fri, 17 Jan 2003 09:46:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A61A3912F1; Fri, 17 Jan 2003 09:49:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0EA5C912F5; Fri, 17 Jan 2003 09:49: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 6C52F912F1 for ; Fri, 17 Jan 2003 09:47:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 37D545DEAB; Fri, 17 Jan 2003 09:47:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by segue.merit.edu (Postfix) with ESMTP id 8C34D5DE28 for ; Fri, 17 Jan 2003 09:47:04 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ZXls-0001NL-00; Fri, 17 Jan 2003 06:47:00 -0800 Date: Fri, 17 Jan 2003 09:43:37 -0500 From: Keith Moore To: Daniel Senie Cc: moore@cs.utk.edu, jgraessley@apple.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030117094337.7eac176e.moore@cs.utk.edu> In-Reply-To: <5.2.0.9.2.20030116155030.03005e80@mail.amaranth.net> References: <5.2.0.9.2.20030116093600.02ec3fc8@mail.amaranth.net> <5.2.0.9.2.20030116155030.03005e80@mail.amaranth.net> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Thu, 16 Jan 2003 15:55:55 -0500 Daniel Senie wrote: > At 03:06 PM 1/16/2003, Joshua Graessley wrote: > > > >Is there a reason that we need all these knobs? What's wrong with just > >recommending that an interface only acquire an IPv4LL address if it is > >unable to acquire a global address for an interface? > > What's wrong, is that limits the ability to develop a class of devices that > ONLY operates in the linklocal addressing block. There is a great deal of > interest in such devices, and, IMO, no good reason to preclude such from > the market. this is not in the group's charter. and it's ridiculous to assume that any device only needs to talk to other devices on its local network segment. it's even more ridiculous to demand that every IPv4 host that wants to support zeroconf be configured by default to be able to talk to such dysfunctional devices. > So how does your desktop machine, which DID get a DHCP address talk to a > device which does not support anything but LL addressing? Think about BOTH > ends of a communication, not just one. maybe I don't want my desktop machine to talk to dysfunctional devices. who are you to insist that it should be configured to do so by default? Keith From owner-zeroconf@merit.edu Fri Jan 17 11:08:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27166 for ; Fri, 17 Jan 2003 11:08:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8F8A6912FE; Fri, 17 Jan 2003 11:11:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5EDE191300; Fri, 17 Jan 2003 11:11: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 1E6B3912FE for ; Fri, 17 Jan 2003 11:11:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 045D25DEB7; Fri, 17 Jan 2003 11:11:33 -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 8D5695DEA5 for ; Fri, 17 Jan 2003 11:11:32 -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 LAA02575 for ; Fri, 17 Jan 2003 11:11:32 -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 LAA06642 for ; Fri, 17 Jan 2003 11:11:31 -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 LAA04287 for ; Fri, 17 Jan 2003 11:06:30 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 17 Jan 2003 11:06:28 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030117093946.0f280e1a.moore@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 01/17/2003 09:39, "Keith Moore" wrote: > The zeroconf working group is being abandoned due to gross violations of its > charter and failure to produce a document which meets the criteria for > proposed standard in RFC 2026. Okay, can we all admit that we are now going so far into personal causes that it's going to be impossible to do any work until such time that we can separate ego and personal issues from the idea of actually getting stuff done. But if we do disband this, I propose this text: The zeroconf working group is being abandoned due to gross violations of its charter and failure to produce a document which meets the criteria for proposed standard in RFC 2026. As well, the IETF should abandon any efforts to standardize anything that has to do with ease of use, or human issues due to a complete inability to understand that the vast majority of computer users don't know, don't care to know, and never will want to know how their computer does anything 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 Jan 17 11:22:52 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27559 for ; Fri, 17 Jan 2003 11:22:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ADF0291300; Fri, 17 Jan 2003 11:26:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 790E491301; Fri, 17 Jan 2003 11:26:05 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 85E7091300 for ; Fri, 17 Jan 2003 11:26:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 65ACC5DE28; Fri, 17 Jan 2003 11:26:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by segue.merit.edu (Postfix) with ESMTP id B06E85DE24 for ; Fri, 17 Jan 2003 11:26:03 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0HGQ1RV063808; Fri, 17 Jan 2003 11:26:01 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0HGPnpf043118; Fri, 17 Jan 2003 09:25:50 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h0HGOuU31006; Fri, 17 Jan 2003 11:24:56 -0500 Message-Id: <200301171624.h0HGOuU31006@rotala.raleigh.ibm.com> To: "Christian Huitema" Cc: zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: Message from huitema@windows.microsoft.com of "Thu, 16 Jan 2003 11:05:34 PST." Date: Fri, 17 Jan 2003 11:24:56 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk "Christian Huitema" writes: > Communicating or not with LL addressed hosts on a given link is a > different issue. Even if a host has a configured global address, it > could communicate with a LL addressed host; this is equivalent to > having two different subnets on the same link, and there are obvious > optimisations for LL aware hosts. This communication may be > disallowed by a site manager for security reasons, but it may also > be allowed in order to gain functionality. This would be knob #2. Note: the current draft (and what I've heard some people seem to argue for recently) is that hosts with a global address CAN NOT and MUST NOT speak with a node having a LL address. Some are arguing that the service provided by LL addressing is to only use LL addresses to speak with other nodes that also speak LL addressing, as specified in the LL document. I have by own doubts about that model, but at least some people have been arguing for it. Also, there is the issue of a host with a global address (who doesn't understand LL addresing at all) sending packets for a LL destination to a router. According to the current wording in the LL document (I believe), the router will drop the packet. Thus, communication fails. This can be fairly easily fixed. The rule could/should be that a router doesn't forward LL packets off of the link from which it was received. It would be fine for it to send the packet back out on the same link on which it was recieved though. Thomas From owner-zeroconf@merit.edu Fri Jan 17 11:35:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27953 for ; Fri, 17 Jan 2003 11:35:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6613791304; Fri, 17 Jan 2003 11:36:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A55B91308; Fri, 17 Jan 2003 11: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 3D5C791304 for ; Fri, 17 Jan 2003 11:33:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 247635DE4E; Fri, 17 Jan 2003 11:33:56 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by segue.merit.edu (Postfix) with ESMTP id DAFCD5DE28 for ; Fri, 17 Jan 2003 11:33:55 -0500 (EST) Received: from mail6.nc.rr.com (fe6 [24.93.67.53]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h0HGWvur007959; Fri, 17 Jan 2003 11:32:57 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 17 Jan 2003 11:34:14 -0500 Message-ID: <3E2830D7.90408@nc.rr.com> Date: Fri, 17 Jan 2003 11:35:35 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten Cc: Christian Huitema , zeroconf@merit.edu Subject: Re: Turning off link-locals? References: <200301171624.h0HGOuU31006@rotala.raleigh.ibm.com> In-Reply-To: <200301171624.h0HGOuU31006@rotala.raleigh.ibm.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 Thomas Narten wrote: > "Christian Huitema" writes: > > >>Communicating or not with LL addressed hosts on a given link is a >>different issue. Even if a host has a configured global address, it >>could communicate with a LL addressed host; this is equivalent to >>having two different subnets on the same link, and there are obvious >>optimisations for LL aware hosts. This communication may be >>disallowed by a site manager for security reasons, but it may also >>be allowed in order to gain functionality. This would be knob #2. > > > Note: the current draft (and what I've heard some people seem to argue > for recently) is that hosts with a global address CAN NOT and MUST NOT > speak with a node having a LL address. Some are arguing that the > service provided by LL addressing is to only use LL addresses to speak > with other nodes that also speak LL addressing, as specified in the LL > document. I have by own doubts about that model, but at least some > people have been arguing for it. > > Also, there is the issue of a host with a global address (who doesn't > understand LL addresing at all) sending packets for a LL destination > to a router. According to the current wording in the LL document (I > believe), the router will drop the packet. Thus, communication fails. The router may drop the packet. Of course, if it is not link-local aware: 1. It could route the packet if it has a route for some reason 2. It could have cached ARP information it learned from the destination and forward it back out the same interface > > This can be fairly easily fixed. The rule could/should be that a > router doesn't forward LL packets off of the link from which it was > received. It would be fine for it to send the packet back out on the > same link on which it was recieved though. That rule is fine if the router is LL aware. What about also sending an ICMP redirect to the sender? Brian From owner-zeroconf@merit.edu Fri Jan 17 11:35:36 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27969 for ; Fri, 17 Jan 2003 11:35:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 013EF91305; Fri, 17 Jan 2003 11:36:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E623491307; Fri, 17 Jan 2003 11:36: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 5947691305 for ; Fri, 17 Jan 2003 11:34:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 37AA75DEA1; Fri, 17 Jan 2003 11:34:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtp.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 1F30B5DE4E for ; Fri, 17 Jan 2003 11:34:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id D54FA13FE5; Fri, 17 Jan 2003 11:34:51 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 00562-05; Fri, 17 Jan 2003 11:34:51 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 4105413FCB; Fri, 17 Jan 2003 11:34:51 -0500 (EST) Date: Fri, 17 Jan 2003 11:34:51 -0500 From: Keith Moore To: Thomas Narten Cc: moore@cs.utk.edu, huitema@windows.microsoft.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030117113451.1db293df.moore@cs.utk.edu> In-Reply-To: <200301171624.h0HGOuU31006@rotala.raleigh.ibm.com> References: <200301171624.h0HGOuU31006@rotala.raleigh.ibm.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 4b5c7658ba14f4ac3759362359f2815ee4189553 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Also, there is the issue of a host with a global address (who doesn't > understand LL addresing at all) sending packets for a LL destination > to a router. According to the current wording in the LL document (I > believe), the router will drop the packet. Thus, communication fails. > > This can be fairly easily fixed. The rule could/should be that a > router doesn't forward LL packets off of the link from which it was > received. It would be fine for it to send the packet back out on the > same link on which it was recieved though. there is an interesting idea. if communications between managed hosts and LL hosts were required to go through a router, and managed hosts were expected to ignore LL traffic not coming from a router, then the router could provide filtering as necessary to implement local policy. -- Keith Moore http://www.cs.utk.edu/~moore/ 27 February 1933 11 September 2001 From owner-zeroconf@merit.edu Fri Jan 17 11:37:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28051 for ; Fri, 17 Jan 2003 11:37:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1D42991306; Fri, 17 Jan 2003 11:40:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D666491307; Fri, 17 Jan 2003 11:40:20 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E343A91306 for ; Fri, 17 Jan 2003 11:40:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id D1FFB5DE28; Fri, 17 Jan 2003 11:40:19 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by segue.merit.edu (Postfix) with ESMTP id 57E3A5DE24 for ; Fri, 17 Jan 2003 11:40:19 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0HGeGNh020230; Fri, 17 Jan 2003 11:40:16 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0HGcxpf045482; Fri, 17 Jan 2003 09:38:59 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h0HGc7H31102; Fri, 17 Jan 2003 11:38:07 -0500 Message-Id: <200301171638.h0HGc7H31102@rotala.raleigh.ibm.com> To: Keith Moore Cc: huitema@windows.microsoft.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: Message from moore@cs.utk.edu of "Fri, 17 Jan 2003 11:34:51 EST." <20030117113451.1db293df.moore@cs.utk.edu> Date: Fri, 17 Jan 2003 11:38:07 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Keith Moore writes: > > Also, there is the issue of a host with a global address (who doesn't > > understand LL addresing at all) sending packets for a LL destination > > to a router. According to the current wording in the LL document (I > > believe), the router will drop the packet. Thus, communication fails. > > > > This can be fairly easily fixed. The rule could/should be that a > > router doesn't forward LL packets off of the link from which it was > > received. It would be fine for it to send the packet back out on the > > same link on which it was recieved though. > there is an interesting idea. if communications between managed > hosts and LL hosts were required to go through a router, and managed > hosts were expected to ignore LL traffic not coming from a router, > then the router could provide filtering as necessary to implement > local policy. Not my thinking at all. I've always been concerned with the idea that LL-enabled devices should not be allowed (by definition) to communicate with devices that don't implement LL. That seems like a strange service to me. I can understand individual applications making such a choice (on a per-service basis), but I'm less sure it makes sense for that to be the semantics of LL addressing when used by any device/application. But if a goal is to allow traffic between nodes _connected to the same link_, but one using a global addr and one using a LL addr, something like what I proposed may well be needed in order to make the communication work in practice. Thomas From owner-zeroconf@merit.edu Fri Jan 17 11:41:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28194 for ; Fri, 17 Jan 2003 11:41:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4E83191309; Fri, 17 Jan 2003 11:44:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1BA9491308; Fri, 17 Jan 2003 11:44: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 A200291309 for ; Fri, 17 Jan 2003 11:44:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 880925DEBA; Fri, 17 Jan 2003 11:44:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by segue.merit.edu (Postfix) with ESMTP id F2ADF5DEA1 for ; Fri, 17 Jan 2003 11:44:23 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e33.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0HGiNt6027650; Fri, 17 Jan 2003 11:44:23 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0HGiMpf066804; Fri, 17 Jan 2003 09:44:22 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id h0HGhU231143; Fri, 17 Jan 2003 11:43:30 -0500 Message-Id: <200301171643.h0HGhU231143@rotala.raleigh.ibm.com> To: Brian Haberman Cc: Christian Huitema , zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: Message from bkhabs@nc.rr.com of "Fri, 17 Jan 2003 11:35:35 EST." <3E2830D7.90408@nc.rr.com> Date: Fri, 17 Jan 2003 11:43:30 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Brian Haberman writes: > > Also, there is the issue of a host with a global address (who doesn't > > understand LL addresing at all) sending packets for a LL destination > > to a router. According to the current wording in the LL document (I > > believe), the router will drop the packet. Thus, communication fails. > The router may drop the packet. Of course, if it is not link-local > aware: > 1. It could route the packet if it has a route for some reason > 2. It could have cached ARP information it learned from the > destination and forward it back out the same interface Right, in other words, for non LL-aware routers, they will probably forward LL packets back as they should (if they have assigned the prefix to the interface). Or is this a big if?? > > > > This can be fairly easily fixed. The rule could/should be that a > > router doesn't forward LL packets off of the link from which it was > > received. It would be fine for it to send the packet back out on the > > same link on which it was recieved though. > That rule is fine if the router is LL aware. Yes. Note that the draft currently says a node MUST NOT forward a LL packet further. > What about also sending an ICMP redirect to the sender? That would be fine too, except wouldn't the host likely ignore it? In IPv4, the host will presumably not realize the destination is on link, which is the issue that caused it to forward the packet to a router in the first place... Thomas From owner-zeroconf@merit.edu Fri Jan 17 11:46:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28321 for ; Fri, 17 Jan 2003 11:46:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 06273912E9; Fri, 17 Jan 2003 11:49:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C396991308; Fri, 17 Jan 2003 11:49: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 9F812912E9 for ; Fri, 17 Jan 2003 11:49:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8BC125DEB7; Fri, 17 Jan 2003 11:49:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtp.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 6B8755DE4E for ; Fri, 17 Jan 2003 11:49:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 3857A1403F; Fri, 17 Jan 2003 11:49:53 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 03594-03; Fri, 17 Jan 2003 11:49:52 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 8F9C013FF2; Fri, 17 Jan 2003 11:49:52 -0500 (EST) Date: Fri, 17 Jan 2003 11:49:52 -0500 From: Keith Moore To: Thomas Narten Cc: moore@cs.utk.edu, huitema@windows.microsoft.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030117114952.1f43fc6f.moore@cs.utk.edu> In-Reply-To: <200301171638.h0HGc7H31102@rotala.raleigh.ibm.com> References: <20030117113451.1db293df.moore@cs.utk.edu> <200301171638.h0HGc7H31102@rotala.raleigh.ibm.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 49ddf16c17ba6926701195597ab03737e7edb2aa Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > there is an interesting idea. if communications between managed > > hosts and LL hosts were required to go through a router, and managed > > hosts were expected to ignore LL traffic not coming from a router, > > then the router could provide filtering as necessary to implement > > local policy. > > Not my thinking at all. > > I've always been concerned with the idea that LL-enabled devices > should not be allowed (by definition) to communicate with devices that > don't implement LL. That seems like a strange service to me. I can > understand individual applications making such a choice (on a > per-service basis), but I'm less sure it makes sense for that to be > the semantics of LL addressing when used by any device/application. I have multiple concerns. One is that devices supporting LL should inherently be allowed to connect to any service on any host that it needs to talk to (i.e. that such hosts can be expected to be on the same link). The concern here is with promoting this as an assumption that device vendors can use to simplify their designs, when it's not a reasonable assumption. Another is that devices supporting LL get to circumvent whatever policy is in place for that link merely because they can acquire an LL address. For better or worse many sites currently use DHCP as a means to control access to hosts - if your MAC address isn't known to the DHCP server then you can't talk to other hosts on the same net. (And especially with wireless networks it's important that autoconfiguration not facilitate attacks that would normally be thwarted by filters). > But if a goal is to allow traffic between nodes _connected to the same > link_, but one using a global addr and one using a LL addr, something > like what I proposed may well be needed in order to make the > communication work in practice. I certainly agree that LL should not be used to communicate off-link (not even with a NAT, though some think that NAT+v4LL is a great substitute for DHCP). -- Keith Moore http://www.cs.utk.edu/~moore/ 27 February 1933 11 September 2001 From owner-zeroconf@merit.edu Fri Jan 17 13:28:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01002 for ; Fri, 17 Jan 2003 13:28:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6702B9130D; Fri, 17 Jan 2003 13:31:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C92B59130E; Fri, 17 Jan 2003 13:31: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 2EB289130D for ; Fri, 17 Jan 2003 13:31:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6BAA15DEDF; Fri, 17 Jan 2003 13:31:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ncsmtp02.ogw.rr.com (ncsmtp02.ogw.rr.com [24.93.67.83]) by segue.merit.edu (Postfix) with ESMTP id 2C2F15DED7 for ; Fri, 17 Jan 2003 13:31:11 -0500 (EST) Received: from mail5.nc.rr.com (fe5 [24.93.67.52]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h0HIUDup023799; Fri, 17 Jan 2003 13:30:13 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 17 Jan 2003 13:29:38 -0500 Message-ID: <3E284C52.7000406@nc.rr.com> Date: Fri, 17 Jan 2003 13:32:50 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten Cc: Christian Huitema , zeroconf@merit.edu Subject: Re: Turning off link-locals? References: <200301171643.h0HGhU231143@rotala.raleigh.ibm.com> In-Reply-To: <200301171643.h0HGhU231143@rotala.raleigh.ibm.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 Thomas Narten wrote: > Brian Haberman writes: > > >>>Also, there is the issue of a host with a global address (who doesn't >>>understand LL addresing at all) sending packets for a LL destination >>>to a router. According to the current wording in the LL document (I >>>believe), the router will drop the packet. Thus, communication fails. > > >>The router may drop the packet. Of course, if it is not link-local >>aware: > > >> 1. It could route the packet if it has a route for some reason >> 2. It could have cached ARP information it learned from the >> destination and forward it back out the same interface > > > Right, in other words, for non LL-aware routers, they will probably > forward LL packets back as they should (if they have assigned the > prefix to the interface). Or is this a big if?? You are correct in that they need to have routing info for that prefix. So, yes, it would be a big if. Though, if operational guidance was provided somewhere, a network operator could add the LL prefix to the interface in order to support a mix of hosts (LL-aware and LL-unaware). I will point out that some routing platforms will not forward a packet back out the interface it was received. > > >>>This can be fairly easily fixed. The rule could/should be that a >>>router doesn't forward LL packets off of the link from which it was >>>received. It would be fine for it to send the packet back out on the >>>same link on which it was recieved though. > > >>That rule is fine if the router is LL aware. > > > Yes. Note that the draft currently says a node MUST NOT forward a LL > packet further. > > >>What about also sending an ICMP redirect to the sender? > > > That would be fine too, except wouldn't the host likely ignore it? In > IPv4, the host will presumably not realize the destination is on link, > which is the issue that caused it to forward the packet to a router in > the first place... I am not sure how many, if any, host implementations would accept the redirect... Brian From owner-zeroconf@merit.edu Fri Jan 17 14:29:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02299 for ; Fri, 17 Jan 2003 14:29:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6EFC591303; Fri, 17 Jan 2003 14:32:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A64F91311; Fri, 17 Jan 2003 14:32: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 177C891303 for ; Fri, 17 Jan 2003 14:32:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id EDA7B5DED4; Fri, 17 Jan 2003 14:32:21 -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 9C4F25DDB3 for ; Fri, 17 Jan 2003 14:32:21 -0500 (EST) Received: from nominum.com (cs6625147-195.austin.rr.com [66.25.147.195]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0HJSlP14482; Fri, 17 Jan 2003 13:28:47 -0600 (CST) Date: Fri, 17 Jan 2003 13:32:25 -0600 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Thomas Narten , Christian Huitema , zeroconf@merit.edu To: Brian Haberman From: Ted Lemon In-Reply-To: <3E284C52.7000406@nc.rr.com> Message-Id: <682542E7-2A52-11D7-A3B4-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > You are correct in that they need to have routing info for that > prefix. So, yes, it would be a big if. Though, if operational > guidance was provided somewhere, a network operator could add > the LL prefix to the interface in order to support a mix of > hosts (LL-aware and LL-unaware). This assumes that the router only has one interface connected to a network with LL-aware clients. If it has two or more, it won't know how to do the forwarding, because any of the LL-aware ports would be a valid place to which to forward the packet. It might Just Work anyway because of the ARP cache, but I wouldn't want to have to depend on it. From owner-zeroconf@merit.edu Fri Jan 17 16:38:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05199 for ; Fri, 17 Jan 2003 16:38:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 771D29121E; Fri, 17 Jan 2003 16:41:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 42E3891221; Fri, 17 Jan 2003 16:41: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 2E97B9121E for ; Fri, 17 Jan 2003 16:41:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 07DE55DF13; Fri, 17 Jan 2003 16:41:45 -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 C5B825DEFC for ; Fri, 17 Jan 2003 16:41:44 -0500 (EST) Received: (qmail 4987 invoked from network); 17 Jan 2003 21:41:44 -0000 Received: from unknown (HELO kabilla) (66.219.68.108) by smtp.broadviewnet.net with SMTP; 17 Jan 2003 21:41:44 -0000 Message-ID: <003401c2be71$3a819d30$6401a8c0@kabilla> From: "Bill Rees" To: "Zeroconf" References: Subject: Re: Turning off link-locals? Date: Fri, 17 Jan 2003 13:41:43 -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" Subject: Re: Turning off link-locals? > so which is worse: > > a. a denial of service attack from a local attacker by disabling v4LL > b. an attack on a host from a local attacker facilitated by enabling v4LL > c. an attack on all IPv4 networks from the zeroconf working group > The answer is "D: refusing to address the need for self configuring networks which require at most automated administration". This answer also answers your statement that ... > > The zeroconf working group is being abandoned due to gross violations of its > charter and failure to produce a document which meets the criteria for > proposed standard in RFC 2026. As well, the IETF should abandon any efforts > to standardize anything that has to do with ease of use, or human issues due > to a complete inability to understand that the vast majority of computer > users don't know, don't care to know, and never will want to know how their > computer does anything at all. > > john > > -- The zeroconf wg is tied to Rendezvous as an answer to D: so the defacto vendor view of the working group is of a group of people focusing on D: and making sure whatever solution standardized that the goal of self-configuration or aut-configurtion is met. Otherwise there is no reason for this working group to exist. Besides, (And I for once am thankful of Apple) if zeroconf strays from Apple's interpretation of the charter then Apple will solve the problem without us and create a defacto standard regardless of anyone's concerns expressed in this group. This interpretation argues for v4LL default to on, that some sort of propaganda concerning how the device works in a DHCP environment to contain v4LL problems (prefer static over DHCP over v4LL) and anything issues blocking this goal which defy address within this email's interpretation of the charter must be handled as addendums or errata or appendices or recommendations for best practices. Anything else is beyond the vendor defacto intrepretation of the charter. Get over it and either recharter the working group or take Rendezvous as the guide for standardization. Bill From owner-zeroconf@merit.edu Fri Jan 17 17:01:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05785 for ; Fri, 17 Jan 2003 17:01:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 24A8891315; Fri, 17 Jan 2003 17:04:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE2EC91274; Fri, 17 Jan 2003 17:04: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 D733091317 for ; Fri, 17 Jan 2003 17:03:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D4E65DDB3; Fri, 17 Jan 2003 17:03:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtp.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 0B1265DED7 for ; Fri, 17 Jan 2003 17:02:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id BAE1314130; Fri, 17 Jan 2003 17:02:57 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 14942-05; Fri, 17 Jan 2003 17:02:57 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 266051400C; Fri, 17 Jan 2003 17:02:57 -0500 (EST) Date: Fri, 17 Jan 2003 17:02:56 -0500 From: Keith Moore To: "Bill Rees" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030117170256.380d9953.moore@cs.utk.edu> In-Reply-To: <003401c2be71$3a819d30$6401a8c0@kabilla> References: <003401c2be71$3a819d30$6401a8c0@kabilla> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: a3b8ca4288b69998541c4ce20366516117ea193d Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > so which is worse: > > > > a. a denial of service attack from a local attacker by disabling > > v4LL b. an attack on a host from a local attacker facilitated by > > enabling v4LL c. an attack on all IPv4 networks from the zeroconf > > working group > > > > The answer is "D: refusing to address the need for self configuring > networks which require at most automated administration". v4LL doesn't address that need at all. The most it does (regarding self-configurating networks) is shift the burden from network configuration to host and application configuration. If you want to build self-configuring networks, you need to first understand the broad spectrum of requirements which the network will be required to support - the needs of users, applications developers, network administrators, and those concerned with security. Then you can develop an architecture that recognizes all of those needs as legitimate and incorporates provisions to satisfy those needs. Pretending that a technology that allows use of scoped addresses on ad hoc networks will work fine on managed networks and with the great diversity of applications in use, is not furthering your stated goal -- it's hindering it. The sooner this approach is abandoned the sooner real progress can be made. > The zeroconf wg is tied to Rendezvous as an answer to D: I don't believe you. But to the extent people believe Rendezvous solves these problems, it's not hard to understand why the group is having so much trouble making progress. Keith -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Fri Jan 17 17:20:53 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06160 for ; Fri, 17 Jan 2003 17:20:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1510391274; Fri, 17 Jan 2003 17:24:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCB5591317; Fri, 17 Jan 2003 17:24: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 5FC4791274 for ; Fri, 17 Jan 2003 17:24:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 425A35DEEE; Fri, 17 Jan 2003 17:24:01 -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 C24035DDC5 for ; Fri, 17 Jan 2003 17:24:00 -0500 (EST) Received: (qmail 17213 invoked from network); 17 Jan 2003 22:24:00 -0000 Received: from unknown (HELO kabilla) (66.219.68.108) by smtp.broadviewnet.net with SMTP; 17 Jan 2003 22:24:00 -0000 Message-ID: <004b01c2be77$221803a0$6401a8c0@kabilla> From: "Bill Rees" To: "Keith Moore" Cc: , References: <003401c2be71$3a819d30$6401a8c0@kabilla> <20030117170256.380d9953.moore@cs.utk.edu> Subject: Re: Turning off link-locals? Date: Fri, 17 Jan 2003 14:23: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 ----- From: "Keith Moore" > > > > > > > The answer is "D: refusing to address the need for self configuring > > networks which require at most automated administration". > > v4LL doesn't address that need at all. The most it does (regarding self-configurating networks) is shift > the burden from network configuration to host and application configuration. Well rendezvous has done a good job addressing this problem since it appears to work so far. If you state the v4LL by itself will solve these problems than I agree with you. In that case you > > If you want to build self-configuring networks, you need to first understand the broad spectrum of requirements which the network will be required to support - the needs of users, applications developers, network administrators, and those concerned with security. Then you can develop an architecture that recognizes all of those needs as legitimate and incorporates provisions to satisfy those needs. > > Pretending that a technology that allows use of scoped addresses on ad hoc networks will work fine on managed networks and with the great diversity of applications in use, is not furthering your stated goal -- it's hindering it. The sooner this approach is abandoned the sooner real progress can be made. > > > The zeroconf wg is tied to Rendezvous as an answer to D: > > I don't believe you. But to the extent people believe Rendezvous solves these problems, it's not hard to understand why the group is having so much trouble making progress. Well I certainly feel foolish here since I came to the zeroconf wg via an Apple pointer from the rendezvous page, right next to the text talking about rendezvous' connection with zeroconf. Unfortunately, I leapt to the conclusion that the association with rendezvous meant the zeroconf name was zero-configuration and had zero-configuration as its goal. If I'm off base then I'll cease to think of zero-configuration as a goal for zeroconf. Since the problems apparent within v4LL probably require a series of standard-draft responses to address the zero-configuration goal, a clear disparity needs expressing relative to rendezvous so noone else mistakenly makes this connection (as I foolishly and naively did). > > Keith > -- > I tried enlightenment but it kept crashing. > From owner-zeroconf@merit.edu Fri Jan 17 19:13:44 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08026 for ; Fri, 17 Jan 2003 19:13:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DE11A91277; Fri, 17 Jan 2003 19:16:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A199D91319; Fri, 17 Jan 2003 19:16: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 730A991277 for ; Fri, 17 Jan 2003 19:16:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 185AC5DF34; Fri, 17 Jan 2003 19:16:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by segue.merit.edu (Postfix) with ESMTP id CA3A25DE3A for ; Fri, 17 Jan 2003 19:16:50 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ZgfI-0000Op-00; Fri, 17 Jan 2003 16:16:49 -0800 Date: Fri, 17 Jan 2003 19:13:25 -0500 From: Keith Moore To: "Bill Rees" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030117191325.193ba362.moore@cs.utk.edu> In-Reply-To: <004b01c2be77$221803a0$6401a8c0@kabilla> References: <003401c2be71$3a819d30$6401a8c0@kabilla> <20030117170256.380d9953.moore@cs.utk.edu> <004b01c2be77$221803a0$6401a8c0@kabilla> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > > The answer is "D: refusing to address the need for self configuring > > > networks which require at most automated administration". > > > > v4LL doesn't address that need at all. The most it does (regarding > > self-configurating networks) is shift the burden from network > > configuration to host and application configuration. > > Well rendezvous has done a good job addressing this problem no it hasn't. rendezvous doesn't give the host a stable global IP address. rendezvous can't tell an application which of several addresses works best to reach some random host, or whether or not some random host is the same addressing realm as either the caller or some other random host. Keith From owner-zeroconf@merit.edu Fri Jan 17 19:28:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08133 for ; Fri, 17 Jan 2003 19:28:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5B4DE91319; Fri, 17 Jan 2003 19:31:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CFBF49131A; Fri, 17 Jan 2003 19:31: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 CCB4791319 for ; Fri, 17 Jan 2003 19:30:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9CCFB5DF45; Fri, 17 Jan 2003 19:30: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 EDFA35DF34 for ; Fri, 17 Jan 2003 19:30:28 -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 TAA16144 for ; Fri, 17 Jan 2003 19:30:27 -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 TAA21051 for ; Fri, 17 Jan 2003 19:25:39 -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 TAA25573 for ; Fri, 17 Jan 2003 19:25:39 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 17 Jan 2003 19:25:33 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <003401c2be71$3a819d30$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 01/17/2003 16:41, "Bill Rees" wrote: > The zeroconf wg is tied to Rendezvous as an answer to D: so the defacto > vendor view of the working group is of a group of people focusing on D: and > making sure whatever solution standardized that the goal of > self-configuration or aut-configurtion is met. Otherwise there is no reason > for this working group to exist. Besides, (And I for once am thankful of > Apple) if zeroconf strays from Apple's interpretation of the charter then > Apple will solve the problem without us and create a defacto standard > regardless of anyone's concerns expressed in this group. Excellent! This is an excellent point. Zeroconf is *not* like IPv6, where it was created by the IETF. Zeroconf is/will be/hopefully will be the standard behind things like Rendezvous, etc. But, those things will happen, and be implemented with or without the IETF. Which is why I'm rather strident that we can't afford to spend months on vague possibilities...if it's a real, repeatable problem, great, document it, post it, let's fix it and move on. Otherwise, it's a "what if..." and those don't count. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sat Jan 18 04:53:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24770 for ; Sat, 18 Jan 2003 04:53:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 87EAD91218; Sat, 18 Jan 2003 04:56:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53B109121D; Sat, 18 Jan 2003 04:56: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 14C3891218 for ; Sat, 18 Jan 2003 04:56:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF0B85DFEA; Sat, 18 Jan 2003 04:56:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 823F15DFDD for ; Sat, 18 Jan 2003 04:56:27 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0I9uC026358; Sat, 18 Jan 2003 16:56:13 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0I9u2819804; Sat, 18 Jan 2003 20:56:06 +1100 (EST) From: Robert Elz To: Daniel Senie Cc: Joshua Graessley , zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: <5.2.0.9.2.20030116155030.03005e80@mail.amaranth.net> References: <5.2.0.9.2.20030116155030.03005e80@mail.amaranth.net> <5.2.0.9.2.20030116093600.02ec3fc8@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 18 Jan 2003 16:56:02 +0700 Message-ID: <19802.1042883762@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 16 Jan 2003 15:55:55 -0500 From: Daniel Senie Message-ID: <5.2.0.9.2.20030116155030.03005e80@mail.amaranth.net> | What's wrong, is that limits the ability to develop a class of devices that | ONLY operates in the linklocal addressing block. I can't even begin to imagine why anyone would even consider making applications (or devices) which care what the bit pattern in an address is. That's truly bizarre. Changing even a comma in a doc to make that kind of device plausible (or easier) isn't worth the effort. | So how does your desktop machine, which DID get a DHCP address talk to a | device which does not support anything but LL addressing? Think about BOTH | ends of a communication, not just one. This is beyond trivial. Assuming the device with the DHCP address is LL aware (dealing with devices older than LL, or which choose to ignore it is a different problem) then it simply "knows" that LL addresses are local to the (appropriate) link. And ARPs for them. This is no different in concept to 127/8 addresses that hosts simply "know" are internal. Devices that have only LL addresses should simply ARP for everything (the LL address block serves to bound the possible addresses that can be locally assigned, but every address is otherwise treated as LL). So? Where is the difficulty? | So it's essential that if an LL device | is going to talk with a device with a non-LL address, the box with the | non-LL address must also have an LL address. Rubbish. Did you even read any of Christian's messages? We don't even need LL aware equipment (in some cases) to make this work, if there's only one interface, just about any (configurable) IP stack can be told that any random address block is directly reachable, and so to simply ARP for it. I kind of like Erik's suggestion (Erik N's). I'm not much worried by the "rogue broadcaster" problem, nets subject to those problems have much worse things to worry about. If it was an accident, then it gets fixed, and everyone learns a little. If it was deliberate, then I'd also expect arp spoofing, etc, which is a much bigger worry. But I also can't see any reason why if "dhcp" is the "off" switch for LL addresses, that dhcp can't also be the "on" switch. That is if the dhcp includes an option "retain your LL addr", the host keeps it, otherwise, it gets rid of the thing (and most of the time, what that means, is that it never gets one at all). The only real issue that needs work this this is in how to deal with devices that were using LL addresses when they're told to stop. Just breaking connections is not a great answer. Can this WG not just copy v6 deprecated addresses though? That is, allow the LL address to continue to be used, but only for existing connections (in the broad sense of the term - including UDP applications, etc). After the global addr (or 1918 addr...) is acquired, the host would stop advertising its LL addr, and would no longer use it when initiating new connections. For knobs, I think one is enough. I don't see a need for Christian's knob #2. I can't think of any plausible reason why a host would want to prohibit itself from talking to other nodes, just because they're using LL addresses. Or not only that. That is, nodes that like to filter communications based upon address are likely to want more functionality than allow LL/disallow LL. If the host has some kind of general address filtering mechanism, to control with whom it will engage in dialogs, then that mechanism will serve just fine to allow/block LL's. If it doesn't, I doubt it really needs one specially just for LL's. kre ps: there seems to be a difference of opinion here as to whether the current drafts forbid communications between LL and non LL addresses. If they do, that needs to be fixed. pps: has (or will) this WG spend any time on considering what the API ought to be like to allow hosts with more than one interface operate when LL addresses exist on both? One would assume that such methods must exist, Apple ibooks have both wireless and wired nets built in, don't they (as do numerous other laptops)? Their apps have to be able to cope somehow? How? From owner-zeroconf@merit.edu Sat Jan 18 08:31:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26730 for ; Sat, 18 Jan 2003 08:31:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 84F129121D; Sat, 18 Jan 2003 08:34:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C7EE91276; Sat, 18 Jan 2003 08:34: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 7728D9121D for ; Sat, 18 Jan 2003 08:33:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 523DB5DFC4; Sat, 18 Jan 2003 08:33:33 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by segue.merit.edu (Postfix) with ESMTP id 2ED145DF38 for ; Sat, 18 Jan 2003 08:33:33 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18Zt51-00031E-00; Sat, 18 Jan 2003 05:32:11 -0800 Date: Sat, 18 Jan 2003 08:28:45 -0500 From: Keith Moore To: Robert Elz Cc: moore@cs.utk.edu, dts@senie.com, jgraessley@apple.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030118082845.1b158762.moore@cs.utk.edu> In-Reply-To: <19802.1042883762@munnari.OZ.AU> References: <5.2.0.9.2.20030116155030.03005e80@mail.amaranth.net> <5.2.0.9.2.20030116093600.02ec3fc8@mail.amaranth.net> <19802.1042883762@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > But I also can't see any reason why if "dhcp" is the "off" switch for > LL addresses, that dhcp can't also be the "on" switch. That is if > the dhcp includes an option "retain your LL addr", the host keeps it, > otherwise, it gets rid of the thing (and most of the time, what that > means, is that it never gets one at all). That makes sense to me also. > The only real issue that needs work this this is in how to deal with > devices that were using LL addresses when they're told to stop. Just > breaking connections is not a great answer. Can this WG not just copy > v6 deprecated addresses though? That is, allow the LL address to > continue to be used, but only for existing connections (in the broad > sense of the term - including UDP applications, etc). After the global > addr (or 1918 addr...) is acquired, the host would stop advertising its > LL addr, and would no longer use it when initiating new connections. This isn't perfect, but it will work more often than anything else that has been proposed. Apps that get started on an isolated network and later acquire routable addresses may get confused -- but this should be rare and in most cases preventable. (The devil is in details like if and how the deprecated address shows up in ioctl SIOCGIFCONF.) > For knobs, I think one is enough. I don't see a need for Christian's > knob #2. I can't think of any plausible reason why a host would want > to prohibit itself from talking to other nodes, just because they're > using LL addresses. For better or worse, DHCP is sometimes used as an access control mechanism. a host that doesn't have its MAC address registered with the DHCP server cannot get an IP address. If a host without an assigned IP address can still talk to other hosts on the local link using LL, this breaks the security measures that are in place on that link. Perhaps it's a lame security measure, but sites are using it because it's the best thing that is available and that works without host software changes. So I do think there's a good argument for the second knob, to tell hosts "don't talk to LL addresses". Keith p.s. For the case of talking between a host with an LL address and a host with a routable address: I don't see a good justification for LL-only hosts, so I'm not sure why we need to consider this case - if the LL-only host can't get a routable address via DHCP or BOOTP then it is presumably a matter of site policy -- and I don't think using BOOTP to get a routable address is an onerous implementation requirement. But assuming there is a justification for it, it makes more sense for the functional host to use a routable address than to use an LL address, simply because the more LL addresses that are in use, the more problems result (addresses leaking outside their scope,collisions, multiple interface ambiguity, security, etc.). From owner-zeroconf@merit.edu Sat Jan 18 20:07:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03740 for ; Sat, 18 Jan 2003 20:07:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 86FF99122E; Sat, 18 Jan 2003 20:10:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 52CED91231; Sat, 18 Jan 2003 20:10: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 54CD99122E for ; Sat, 18 Jan 2003 20:10:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3E4335DFBD; Sat, 18 Jan 2003 20:10:22 -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 AF37F5DD92 for ; Sat, 18 Jan 2003 20:10:21 -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 RAA22680; Sat, 18 Jan 2003 17:10:15 -0800 (PST) Received: from localhost (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 h0J1A9P01086; Sun, 19 Jan 2003 02:10:10 +0100 (MET) Date: Sun, 19 Jan 2003 00:56:49 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Turning off link-locals? To: Brad Hards Cc: Erik Nordmark , Keith Moore , kre@munnari.OZ.AU, zeroconf@merit.edu In-Reply-To: "Your message with ID" <200301161827.07315.bhards@bigpond.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > Some questions, if I may: Sure, but I did say "strawman" so I don'r have the all the answers. > What happens in the absence of votes? IPv4LL on? Yes. > Is this some kind of "per interface" setup, rather than disabling on a host? Yep. > Does the new protocol mechanism default to off? (I assume so, otherwise you > haven't changed anything) Do you mean the new protocol for sending "yes" votes? That needs to default to off. But it might be reasonably for boxes that only function as home gateways to by default vote "yes" with the ability to turn this off. Even if that is done this voting scheme prevents lots of boxes in lots of environments to have both a v4ll address and a dhcp assigned address. > I assume we are talking about something that can work at the link layer. I don't understand the question. I don't want the "yes" vote protocol to cross routers - accidentally or intentionally. But it can still be implemented on top of IP. (For instance, if we do the "send with ttl=255 and verify ttl=255 on receipt and send to a link-local multicast address i.e. 224.0.0.0/24) > How would this look over time? Do we have some kind of "aging" of votes? Any > thoughts for how long the aging process might take? What happens to a > machine that has an IPv4LL address, and gets a "NO" vote? Does it die > straight away? Those are good questions to work on. Erik From owner-zeroconf@merit.edu Sat Jan 18 20:07:36 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03759 for ; Sat, 18 Jan 2003 20:07:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 44C9691231; Sat, 18 Jan 2003 20:10:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1003C91234; Sat, 18 Jan 2003 20:10: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 5C35491231 for ; Sat, 18 Jan 2003 20:10:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4581F5E061; Sat, 18 Jan 2003 20:10:38 -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 BB0D05DD92 for ; Sat, 18 Jan 2003 20:10:37 -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 SAA08066; Sat, 18 Jan 2003 18:10:35 -0700 (MST) Received: from localhost (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 h0J1AIP01090; Sun, 19 Jan 2003 02:10:18 +0100 (MET) Date: Sun, 19 Jan 2003 00:59:28 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Turning off link-locals? To: Luke Diamand Cc: Erik Nordmark , zeroconf@merit.edu In-Reply-To: "Your message with ID" <3E268955.1040902@globespanvirata.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > What if there is a rogue on-link entity? Won't this have just as bad an > effect for people trying to disable link-locals? An on-link entity can force v4ll on even in the presence of a dhcp server. I don't see a mechanism (short of additional configuration) that can avoid this given that we don't want to trust the DHCP infrastructure to make the yes/no choice. (Old discussions about this and the desire to want to use v4ll even if the ISP providing the DHCP responses might be of a different opinion.) Erik From owner-zeroconf@merit.edu Sat Jan 18 20:07:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03775 for ; Sat, 18 Jan 2003 20:07:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E237791234; Sat, 18 Jan 2003 20:11:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B41CD91235; Sat, 18 Jan 2003 20:11:00 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A7FF691234 for ; Sat, 18 Jan 2003 20:10:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 927A75E032; Sat, 18 Jan 2003 20:10:59 -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 143045DD92 for ; Sat, 18 Jan 2003 20:10:59 -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 SAA08208; Sat, 18 Jan 2003 18:10:56 -0700 (MST) Received: from localhost (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 h0J1AcP01125; Sun, 19 Jan 2003 02:10:39 +0100 (MET) Date: Sun, 19 Jan 2003 01:08:37 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Turning off link-locals? To: Keith Moore Cc: Erik Nordmark , bhards@bigpond.net.au, kre@munnari.OZ.AU, zeroconf@merit.edu In-Reply-To: "Your message with ID" <20030116080303.14bd0eb6.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > interesting idea. some questions: We live in interesting times... > - if the intent of the attacker is to turn *on* v4LL > (perhaps to facilitate other attacks, given that v4LL weakens security) > doesn't this make such attacks easier? in other words, is it > reasonable to consider that the risk of an attacker turning off > v4LL for a DoS attack is a significantly larger threat than that of > an attacker turning v4LL on for the purpose of a breakin? I think the only way you can deal with an attacker on the link is to be able to turn off v4ll manually on each host. The strawman is trying to capture a hopefully common case when the devices that are connected to the link are reasonably trusted. But if there are attacks that can not be exploited by an on-link attacker when the target only has a dhcp assigned address, but can be exploited by an on-link attacker when the target has a v4ll and a dhcp assigned address, then the strawman has a significant downside. But such setups seems odd, since such an attackable target would have to associate security properties not with whether or not the peer address is on the subnet, but whether or not the peer address is a v4ll. Such a device would work differently in an environment that doesn't have v4ll configured (likely for an office setting for instance). > offhand it seems to me like there are security risks with either > a forged "yes" or "no" signal from the net, and they're both > ameliorated in the same way - by monitoring the net for rogue > transmitters of such signals. if you want anything stronger, > you need authentication, which of course requires host configuration... Yep. > - why could the yes vote not be a DHCP response? is it more reasonble > to trust a separate mechanism which presumably could be spoofed just > as easily as DHCP, and which adds complexity? or is the idea to > force the yes vote to be link-local in scope. (this gets back to the > security risks of spoofed yes votes - if the spoofing is inherently > local to the link then it's easier to spoof yes votes without being > detected - the monitoring has to take place separately for every link) Concerns that the operator of the DHCP infrastructure (a different adminstrative entity than the operator of the hosts in some cases) would have conflicting goals with the operator of the local link. We had those discussions around the proposed dhcp option that would control whether or not v4ll was used. But the intent is that the "yes" votes be local to the link. Erik From owner-zeroconf@merit.edu Sat Jan 18 20:08:09 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03790 for ; Sat, 18 Jan 2003 20:08:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8D89C91235; Sat, 18 Jan 2003 20:11:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 56BA691237; Sat, 18 Jan 2003 20:11: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 841D891235 for ; Sat, 18 Jan 2003 20:11:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A25B5E032; Sat, 18 Jan 2003 20:11:05 -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 0E71B5DD92 for ; Sat, 18 Jan 2003 20:11:05 -0500 (EST) Received: from bebop.France.Sun.COM ([129.157.174.15]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15632; Sat, 18 Jan 2003 18:11:03 -0700 (MST) Received: from localhost (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 h0J1AxP01168; Sun, 19 Jan 2003 02:10:59 +0100 (MET) Date: Sun, 19 Jan 2003 01:13:52 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Turning off link-locals? To: Daniel Senie Cc: zeroconf@merit.edu In-Reply-To: "Your message with ID" <5.2.0.9.2.20030116093600.02ec3fc8@mail.amaranth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > Any mechanism "on the link" which magically turns on link local is > inherently MUCH MORE EVIL than having it on by default, in my opinion, and > would be a major step backward. Why? If someone REALLY did want to disable > LL, you've now provided a way for anyone to plug in (physically or via > wireless) to a network, and force themselves in by simply yelling out a few > packets. Very bad idea. How could it be worse than having it on by default with no mechanism to turn it off? The strawman allows per-host controls to override the "yes" vote, but even if they don't exist (due to hosts without any local knobs) and there is an attacker on the link, it results in it being on. > I believe that covers the bases. The configuration MUST be done on a per > device basis if its to be of any value, IMO. Because you don't think the local link should be trusted at all? I'm contrasting this with other old statements on this list that v4ll is good since it simplifies security configuration - the v4ll address are known to be on the (trusted) local link. I'm confused. Erik From owner-zeroconf@merit.edu Sun Jan 19 04:33:57 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18395 for ; Sun, 19 Jan 2003 04:33:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9B4F491243; Sun, 19 Jan 2003 04:37:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66F7791244; Sun, 19 Jan 2003 04:37: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 7753F91243 for ; Sun, 19 Jan 2003 04:37:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6488A5E0A8; Sun, 19 Jan 2003 04:37:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id CAED05DF8D for ; Sun, 19 Jan 2003 04:37:07 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0J9aT011056; Sun, 19 Jan 2003 16:36:29 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0J9aF806960; Sun, 19 Jan 2003 20:36:15 +1100 (EST) From: Robert Elz To: Keith Moore Cc: dts@senie.com, jgraessley@apple.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: <20030118082845.1b158762.moore@cs.utk.edu> References: <20030118082845.1b158762.moore@cs.utk.edu> <5.2.0.9.2.20030116155030.03005e80@mail.amaranth.net> <5.2.0.9.2.20030116093600.02ec3fc8@mail.amaranth.net> <19802.1042883762@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 19 Jan 2003 16:36:15 +0700 Message-ID: <6958.1042968975@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sat, 18 Jan 2003 08:28:45 -0500 From: Keith Moore Message-ID: <20030118082845.1b158762.moore@cs.utk.edu> | (The devil is in details like if and how the deprecated address shows up in | ioctl SIOCGIFCONF.) Yes, the API questions of all of this currently seem to be being ignored. | For better or worse, DHCP is sometimes used as an access control mechanism. That's so utterly bogus that I don't care in the slightest if it gets "broken" ("broken" in quotes, as it is already broken). If using LL addresses helps make people more aware how non-existant any "security" of that form is, then I'd count it as a feature, not a bug. Of course, hosts that want to avoid talking to LL addresses, or net 10 addresses, or anything else, should be able to be configured to do that. On the local lan, this is still no kind of "security" as anything attempting to intrude can simply allocate itself an address in the authorised range. That is, forbidding this kind of communication adds zero security. If all that's relevant is the incentive to go register the MAC address, then confining communications on the LAN should be good enough - those few servers that give the illusion of allowing wider access (web proxy servers etc) can be configured to refuse to serve LL addresses, if that's the desire. | p.s. For the case of talking between a host with an LL address and a host | with a routable address: I don't see a good justification for LL-only hosts Not only do I not see a good justification, I see no justification at all. In fact, such a "host" I would regard as flat out useless. What good is something that can't communicate where it needs to? And how can the manufacturers of any host possibly know the net topology I will be installing it into? They may like to assume that everything relevant will be on the same lan, and many times it might be, but it certainly won't always be. If there was a way to ban such things, I'd do it. I was just responding to the bogus assertion that devices have to have LL addresses in order to talk to some other device which might only have an LL address - which could happen even for sane hosts during a transition period when global addresses are just becoming available - not every host will acquire its global address at the same time. kre From owner-zeroconf@merit.edu Sun Jan 19 10:25:09 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21184 for ; Sun, 19 Jan 2003 10:25:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CCA4191232; Sun, 19 Jan 2003 10:28:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 946A591245; Sun, 19 Jan 2003 10:28:23 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 77F4991232 for ; Sun, 19 Jan 2003 10:28:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5BFE15DEC0; Sun, 19 Jan 2003 10:28:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by segue.merit.edu (Postfix) with ESMTP id 3B70C5DE53 for ; Sun, 19 Jan 2003 10:28:22 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18aHM1-000366-00; Sun, 19 Jan 2003 07:27:21 -0800 Date: Sun, 19 Jan 2003 10:23:49 -0500 From: Keith Moore To: Erik Nordmark Cc: moore@cs.utk.edu, bhards@bigpond.net.au, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030119102349.363ff913.moore@cs.utk.edu> In-Reply-To: References: <20030116080303.14bd0eb6.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Sun, 19 Jan 2003 01:08:37 +0100 (CET) Erik Nordmark wrote: > > > interesting idea. some questions: > > We live in interesting times... > > > - if the intent of the attacker is to turn *on* v4LL > > (perhaps to facilitate other attacks, given that v4LL weakens security) > > doesn't this make such attacks easier? in other words, is it > > reasonable to consider that the risk of an attacker turning off > > v4LL for a DoS attack is a significantly larger threat than that of > > an attacker turning v4LL on for the purpose of a breakin? > > I think the only way you can deal with an attacker on the link > is to be able to turn off v4ll manually on each host. why not to turn it either off or on manually on each host? in other words, why consider one kind of attack more of a threat than the other? > The strawman is trying to capture a hopefully common case when > the devices that are connected to the link are reasonably trusted. at best this only works for wired links. > > - why could the yes vote not be a DHCP response? > Concerns that the operator of the DHCP infrastructure (a different > adminstrative entity than the operator of the hosts in some cases) would > have conflicting goals with the operator of the local link. mumble. ISPs, LAN operators, link operators, host operators, users, and code developers are all potentially different parties with sometimes-conflicting interests. how much is it the job of this WG (or any IETF WG) to facilitate their competing with each other? From owner-zeroconf@merit.edu Sun Jan 19 10:31:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21317 for ; Sun, 19 Jan 2003 10:31:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3A8AB91247; Sun, 19 Jan 2003 10:34:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F295891245; Sun, 19 Jan 2003 10:34: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 1893891246 for ; Sun, 19 Jan 2003 10:33:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id F09525DED1; Sun, 19 Jan 2003 10:33:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by segue.merit.edu (Postfix) with ESMTP id CF45E5DEC0 for ; Sun, 19 Jan 2003 10:33:55 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18aHRw-0000wK-00; Sun, 19 Jan 2003 07:33:28 -0800 Date: Sun, 19 Jan 2003 10:29:58 -0500 From: Keith Moore To: Robert Elz Cc: moore@cs.utk.edu, dts@senie.com, jgraessley@apple.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030119102958.35c6a292.moore@cs.utk.edu> In-Reply-To: <6958.1042968975@munnari.OZ.AU> References: <20030118082845.1b158762.moore@cs.utk.edu> <5.2.0.9.2.20030116155030.03005e80@mail.amaranth.net> <5.2.0.9.2.20030116093600.02ec3fc8@mail.amaranth.net> <19802.1042883762@munnari.OZ.AU> <6958.1042968975@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Sun, 19 Jan 2003 16:36:15 +0700 Robert Elz wrote: > Date: Sat, 18 Jan 2003 08:28:45 -0500 > From: Keith Moore > Message-ID: <20030118082845.1b158762.moore@cs.utk.edu> > > | (The devil is in details like if and how the deprecated address shows up > in | ioctl SIOCGIFCONF.) > > Yes, the API questions of all of this currently seem to be being ignored. > > | For better or worse, DHCP is sometimes used as an access control > mechanism. > > That's so utterly bogus that I don't care in the slightest if it gets > "broken" ("broken" in quotes, as it is already broken). If using > LL addresses helps make people more aware how non-existant any "security" > of that form is, then I'd count it as a feature, not a bug. I suspect that if we break it it's more likely to be replaced with something worse, than with something better. I also think that it's perfectly reasonable for a LAN operator to impose policy on how that LAN can be used, for whatever reasons the LAN administrator happens to think are valid, and that includes down to the link level. The administrator's logic might be flawed, his/her values might be twisted, but that's not for this group to decide. Nor is it for this group to decide that the mechanisms chosen by the LAN administrator to implement that policy are to be discarded. I don't think zeroconf can reasonably declare "it's okay to use LL addresses on any link" by fiat. From owner-zeroconf@merit.edu Sun Jan 19 20:19:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28070 for ; Sun, 19 Jan 2003 20:19:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2421D91254; Sun, 19 Jan 2003 20:22:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFDE191255; Sun, 19 Jan 2003 20:22: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 D1C8591254 for ; Sun, 19 Jan 2003 20:22:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id AACF75E073; Sun, 19 Jan 2003 20:22:19 -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 246FD5E06D for ; Sun, 19 Jan 2003 20:22:19 -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 RAA06636; Sun, 19 Jan 2003 17:22:16 -0800 (PST) Received: from localhost (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 h0K1MAP20602; Mon, 20 Jan 2003 02:22:11 +0100 (MET) Date: Sun, 19 Jan 2003 22:37:38 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Turning off link-locals? To: Keith Moore Cc: Erik Nordmark , bhards@bigpond.net.au, kre@munnari.OZ.AU, zeroconf@merit.edu In-Reply-To: "Your message with ID" <20030119102349.363ff913.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > why not to turn it either off or on manually on each host? in other words, > why consider one kind of attack more of a threat than the other? Depends what defaults people can roughly agree on. Some folks want to be conservative and have v4ll be off by default. Others want things to work out of the box by having v4ll be on by default. (Of course, things are a bit more tricky since we have on/off when there is no dhcp service as well as on/off when dhcp is handing out addresses.) If the WG can't come to rough consensus on the defaults and is concerned about devices with no user-configurable parts inside, then it makes sense considering the strawman as a way to allow some other device on the link control this behavior. > > The strawman is trying to capture a hopefully common case when > > the devices that are connected to the link are reasonably trusted. > > at best this only works for wired links. Yep, unless 802.11 security is more widely used. But currently it is both to hard to configure and too insecure. > mumble. ISPs, LAN operators, link operators, host operators, users, and code > developers are all potentially different parties with sometimes-conflicting > interests. how much is it the job of this WG (or any IETF WG) to facilitate > their competing with each other? The "tussle" paper (I think "Tussles in cyperspace ..." is the title) argues that it makes sense modularizing along tussle boundaries. I think this means allowing the tussle to play out without having to modify the protocols. Erik From owner-zeroconf@merit.edu Mon Jan 20 04:18:50 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14676 for ; Mon, 20 Jan 2003 04:18:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 739589127C; Mon, 20 Jan 2003 04:22:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 455C29127D; Mon, 20 Jan 2003 04:22:04 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2BE009127C for ; Mon, 20 Jan 2003 04:22:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1763C5E09F; Mon, 20 Jan 2003 04:22:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 308FD5DDBE for ; Mon, 20 Jan 2003 04:21:56 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0K9Kw018913; Mon, 20 Jan 2003 16:20:58 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0K9JP819900; Mon, 20 Jan 2003 20:19:26 +1100 (EST) From: Robert Elz To: Keith Moore Cc: zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: <20030119102958.35c6a292.moore@cs.utk.edu> References: <20030119102958.35c6a292.moore@cs.utk.edu> <20030118082845.1b158762.moore@cs.utk.edu> <5.2.0.9.2.20030116155030.03005e80@mail.amaranth.net> <5.2.0.9.2.20030116093600.02ec3fc8@mail.amaranth.net> <19802.1042883762@munnari.OZ.AU> <6958.1042968975@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Jan 2003 16:19:25 +0700 Message-ID: <19898.1043054365@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 19 Jan 2003 10:29:58 -0500 From: Keith Moore Message-ID: <20030119102958.35c6a292.moore@cs.utk.edu> | I also think that it's perfectly reasonable for a LAN operator to impose | policy on how that LAN can be used, for whatever reasons the LAN | administrator happens to think are valid, and that includes down to | the link level. Absolutely, I don't object to that at all. However having us pretend to the administrator that "if your dhcp server doesn't answer those people you don't know, they'll be shut off your LAN" doesn't help. What's needed is for proper education about the nature of LANS - if you can connect to it, you can talk to it. The LAN (or the ones we're mostly concerned with) is a passive device. [Aside: I know there are active devices that can be stuck in the middle of a LAN, and that some of them pretend to arbitrate access, none I have yet seen takes more than a few minutes to breach though, if you're able to get physical connectivity. If anything, WEP is probably one of the hardest of the lot (which is saying something), most of what's left just needs MAC addr spoofing to defeat.] If this ... | I don't think zeroconf can reasonably declare "it's okay to use | LL addresses on any link" by fiat. was your main point here though, then I agree, and we need a way to turn the things off (we even seem to be approaching some kind of WG agreement perhaps, as they didn't seem to be any "NO, not acceptable" responses to Erik's suggestion - just questions of the mechanisms). But I don't think it gains anything to have a setting that says "LL addresses are OK on this link, but they can't be used to talk to hosts on the link that happen not to have an LL address". That's not a policy that it makes any sense to maintain. Some individual host might want to implement a policy like that, which is fine, but we don't really need to add mechanism to make it a network default policy. kre From owner-zeroconf@merit.edu Mon Jan 20 06:47:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17040 for ; Mon, 20 Jan 2003 06:47:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5837291239; Mon, 20 Jan 2003 06:50:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 13E009127E; Mon, 20 Jan 2003 06:50: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 CB01591239 for ; Mon, 20 Jan 2003 06:50:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC7435E0AB; Mon, 20 Jan 2003 06:50:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by segue.merit.edu (Postfix) with ESMTP id 8C1435E043 for ; Mon, 20 Jan 2003 06:50:36 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 18aaR0-0002yk-00; Mon, 20 Jan 2003 03:49:46 -0800 Date: Mon, 20 Jan 2003 06:46:13 -0500 From: Keith Moore To: Robert Elz Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030120064613.7337ed84.moore@cs.utk.edu> In-Reply-To: <19898.1043054365@munnari.OZ.AU> References: <20030119102958.35c6a292.moore@cs.utk.edu> <20030118082845.1b158762.moore@cs.utk.edu> <5.2.0.9.2.20030116155030.03005e80@mail.amaranth.net> <5.2.0.9.2.20030116093600.02ec3fc8@mail.amaranth.net> <19802.1042883762@munnari.OZ.AU> <6958.1042968975@munnari.OZ.AU> <19898.1043054365@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Mon, 20 Jan 2003 16:19:25 +0700 Robert Elz wrote: > Date: Sun, 19 Jan 2003 10:29:58 -0500 > From: Keith Moore > Message-ID: <20030119102958.35c6a292.moore@cs.utk.edu> > > | I also think that it's perfectly reasonable for a LAN operator to impose > | policy on how that LAN can be used, for whatever reasons the LAN > | administrator happens to think are valid, and that includes down to > | the link level. > > Absolutely, I don't object to that at all. However having us pretend to > the administrator that "if your dhcp server doesn't answer those people > you don't know, they'll be shut off your LAN" doesn't help. I don't think the admins are that deluded. They know that a rogue host can try choosing an address without DHCP, but this will be defined as antisocial behavior. On the other hand, for IETF to say "don't worry about the LAN admin, it's okay if you use LL addresses on that link, and all the vendors will ship code that implements this" circumvents the policy. > [Aside: I know there are active devices that can be stuck in the middle > of a LAN, and that some of them pretend to arbitrate access, none I have > yet seen takes more than a few minutes to breach though, if you're able > to get physical connectivity. We should not assume that the admin's goal in requiring MAC address registration is perfect security, any more than we should assume that the person who installs a short fence around a building thinks that nobody will climb over it or cut through it. The purpose in both cases is to discourage penetration and to marginalize those that do. Often this is sufficient, especially when coupled with other measures such as penalties and visibility. > But I don't think it gains anything to have a setting that says "LL > addresses are OK on this link, but they can't be used to talk to hosts > on the link that happen not to have an LL address". I guess I haven't seen much value in that myself. Basicaly I think that LL addresses should be used only in ad hoc or isolated networks. If a LL-capable device is connected to a managed network, it should get an address from that network - then it can be assured of getting an address of appropriate scope for its purposes, as the scope is controlled by the network rather than by the device. If the network is set up to require registration of all devices, then it should require registration for the LL-capable device also. Keith From owner-zeroconf@merit.edu Mon Jan 20 10:01:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21472 for ; Mon, 20 Jan 2003 10:01:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E96529125D; Mon, 20 Jan 2003 10:04:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB03D91270; Mon, 20 Jan 2003 10:04: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 5ECB99125D for ; Mon, 20 Jan 2003 10:04:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 39F785E0AE; Mon, 20 Jan 2003 10:04:14 -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 C535D5DE03 for ; Mon, 20 Jan 2003 10:04: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 KAA16635 for ; Mon, 20 Jan 2003 10:04:13 -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 KAA17554 for ; Mon, 20 Jan 2003 10:04: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 KAA29353 for ; Mon, 20 Jan 2003 10:04:12 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 20 Jan 2003 10:04:10 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030120064613.7337ed84.moore@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 01/20/2003 06:46, "Keith Moore" wrote: > Basicaly I think that LL addresses should be used only in ad hoc or isolated > networks. If a LL-capable device is connected to a managed network, it should > get an address from that network - then it can be assured of getting an > address of appropriate scope for its purposes, as the scope is controlled by > the network rather than by the device. If the network is set up to require > registration of all devices, then it should require registration for the > LL-capable device also. There are situations, and fairly common ones where you don't want this. For example, MIT requires MAC - address registration for all wireless access. If you work/got to school at MIT, no big deal. But, for consultants, temp workers, people coming in to do presentations for a single shot purpose, this requirement is now quite the pain in the heiny, because it takes multiple phone calls to get the temp access approved. This access doesn't give you certificates or a Kerberos UserID, so it's not even close to a security issue. *That* situation, fairly common, is why you want LL on, even in the presence of DHCP. Look, it may be annoying, but again, single - link multihoming is used daily, it hasn't broken doodly squat in the years it's been being used. There's no case for saying that's a problem. Some routers may need to be checked to ensure that they don't pass LL addresses, but they shouldn't be *anyway*, so there's no great reconfig needed there, unless you have already broken your router. With proper security, LL will cause you no problems by its existence, and there are good reasons to leave it on even in the face of other configuration methods. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Jan 20 10:31:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21873 for ; Mon, 20 Jan 2003 10:31:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AEED29127E; Mon, 20 Jan 2003 10:34:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84D1B9127F; Mon, 20 Jan 2003 10:34: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 5E4759127E for ; Mon, 20 Jan 2003 10:34:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3ED135DE2C; Mon, 20 Jan 2003 10:34:33 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtp.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 2022B5DDA9 for ; Mon, 20 Jan 2003 10:34:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5C355140B2; Mon, 20 Jan 2003 10:34:29 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 00386-09; Mon, 20 Jan 2003 10:34:28 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id B5CDB13FC6; Mon, 20 Jan 2003 10:34:28 -0500 (EST) Date: Mon, 20 Jan 2003 10:34:28 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030120103428.4d2ccab0.moore@cs.utk.edu> In-Reply-To: References: <20030120064613.7337ed84.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: b11445dd9bdd5d1e2c7a5b6ad004411faf7788c2 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Mon, 20 Jan 2003 10:04:10 -0500 "John C. Welch" wrote: > On 01/20/2003 06:46, "Keith Moore" wrote: > > > Basicaly I think that LL addresses should be used only in ad hoc or > > isolated networks. If a LL-capable device is connected to a managed > > network, it should get an address from that network - then it can be > > assured of getting an address of appropriate scope for its purposes, > > as the scope is controlled by the network rather than by the device. > > If the network is set up to require > > registration of all devices, then it should require registration for > > the LL-capable device also. > > There are situations, and fairly common ones where you don't want > this. For example, MIT requires MAC - address registration for all > wireless access. If you work/got to school at MIT, no big deal. > > But, for consultants, temp workers, people coming in to do > presentations for a single shot purpose, this requirement is now quite > the pain in the heiny, because it takes multiple phone calls to get > the temp access approved. This access doesn't give you certificates or > a Kerberos UserID, so it's not even close to a security issue. > > *That* situation, fairly common, is why you want LL on, even in the > presence of DHCP. no, it doesn't follow, because - LL access wouldn't solve the problem for temp users anyway, because they're often going to need access beyond the local link - Apparently MIT doesn't want users to use the network without being registered. Use of LL would circumvent that policy. I think that the policy for MIT's networks should be set by MIT. If their policy or the implementation thereof is too onerous, that may be unfortunate, but it's not a problem for IETF to solve. - Technical means are already available which would allow MIT's DHCP servers to grant temporary network access to temporary users, with appropriate bandwidth/routing limitations on such use. (If the University of Tennesse can do this I'm sure MIT can manage it.) -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Mon Jan 20 11:21:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23149 for ; Mon, 20 Jan 2003 11:21:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 31F1491281; Mon, 20 Jan 2003 11:24:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0154491284; Mon, 20 Jan 2003 11:24: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 0387391281 for ; Mon, 20 Jan 2003 11:24:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF99A5DEB2; Mon, 20 Jan 2003 11:24:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from first.cove-mtn.com (unknown [208.187.205.91]) by segue.merit.edu (Postfix) with ESMTP id 06C045DDE2 for ; Mon, 20 Jan 2003 11:24:39 -0500 (EST) Received: from cove-mtn.com (dante.cove-mtn.com [172.31.2.255]) by first.cove-mtn.com (8.12.5/8.12.4) with ESMTP id h0KGOh7g018536; Mon, 20 Jan 2003 09:24:43 -0700 (MST) Message-ID: <3E2C22C1.6070600@cove-mtn.com> Date: Mon, 20 Jan 2003 09:24:33 -0700 From: Brad Davis User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en,zh-TW MIME-Version: 1.0 To: Robert Elz , zeroconf@merit.edu Cc: Keith Moore Subject: Re: Turning off link-locals? References: <20030119102958.35c6a292.moore@cs.utk.edu> <20030118082845.1b158762.moore@cs.utk.edu> <5.2.0.9.2.20030116155030.03005e80@mail.amaranth.net> <5.2.0.9.2.20030116093600.02ec3fc8@mail.amaranth.net> <19802.1042883762@munnari.OZ.AU> <6958.1042968975@munnari.OZ.AU> <19898.1043054365@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > What's > needed is for proper education about the nature of LANS - if you can > connect to it, you can talk to it. The LAN (or the ones we're mostly > concerned with) is a passive device. This is (I think) the heart of the arguments. Keith is worried about the impact of this protocol on LANs that aren't part of the set that "we're mostly concerned with". Most "good" protocols are used far beyond what their creators imagined. We must be concerned with the impact of LL addresses outside the scope of how this WG expects them to be used. I think that the intent of this protocol will be butchered. Keith Moore wrote: >Basicaly I think that LL addresses should be used only in ad hoc or isolated >networks. If a LL-capable device is connected to a managed network, it should >get an address from that network - then it can be assured of getting an >address of appropriate scope for its purposes, as the scope is controlled by >the network rather than by the device. If the network is set up to require >registration of all devices, then it should require registration for the >LL-capable device also. I agree with this. I also think that this group should put together a "best practices" document that defines a DHCP/DNS(/others?) network that is preconfigured to support as close to zero configuration as can be done. Brad Davis From owner-zeroconf@merit.edu Mon Jan 20 12:27:33 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24775 for ; Mon, 20 Jan 2003 12:27:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0E32C91289; Mon, 20 Jan 2003 12:22:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6093591288; Mon, 20 Jan 2003 12:22: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 E1A7F91289 for ; Mon, 20 Jan 2003 12:22:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id CE4B95DE58; Mon, 20 Jan 2003 12:22:01 -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 656F35DE16 for ; Mon, 20 Jan 2003 12:22:01 -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 MAA01282 for ; Mon, 20 Jan 2003 12:22:00 -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 MAA00166 for ; Mon, 20 Jan 2003 12:22: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 MAA25268 for ; Mon, 20 Jan 2003 12:21:59 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 20 Jan 2003 12:21:58 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030120103428.4d2ccab0.moore@cs.utk.edu> 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 MAA24775 On 01/20/2003 10:34, "Keith Moore" wrote: >> *That* situation, fairly common, is why you want LL on, even in the >> presence of DHCP. > > no, it doesn't follow, because > > - LL access wouldn't solve the problem for temp users anyway, because they're > often going to need access beyond the local link In 80-90% of cases, what they need is a way to print, or get files to a machine in the same room. > > - Apparently MIT doesn't want users to use the network without being > registered. Use of LL would circumvent that policy. I think that the policy > for MIT's networks should be set by MIT. If their policy or the > implementation thereof is too onerous, that may be unfortunate, but it's not a > problem for IETF to solve. I'm not *saying* that the IETF needs to solve MIT's problems. That would take decades. I'm *saying* that there is a need for LL to run even with other address management going on. To the point, MIT doesn¹t much care about LL, as long as you aren't messing up the rest of the network, which hasn't been happening, and there are a lot of folks using it. > > - Technical means are already available which would allow MIT's DHCP servers > to grant temporary network access to temporary users, with appropriate > bandwidth/routing limitations on such use. (If the University of Tennesse can > do this I'm sure MIT can manage it.) Right...set up an IP address, track it, disable it, for a consultant to transfer a couple of PDFs...how efficient. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Jan 20 14:50:12 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28923 for ; Mon, 20 Jan 2003 14:50:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B2EFE91262; Mon, 20 Jan 2003 14:53:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84BE19128E; Mon, 20 Jan 2003 14:53: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 5006B91262 for ; Mon, 20 Jan 2003 14:53:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 243F95DE67; Mon, 20 Jan 2003 14:53:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtp.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 057115DE5A for ; Mon, 20 Jan 2003 14:53:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id C85371415F; Mon, 20 Jan 2003 14:53:26 -0500 (EST) Received: from smtp.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 01847-04; Mon, 20 Jan 2003 14:53:26 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 3186813FCC; Mon, 20 Jan 2003 14:53:26 -0500 (EST) Date: Mon, 20 Jan 2003 14:53:25 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030120145325.35d3023b.moore@cs.utk.edu> In-Reply-To: References: <20030120103428.4d2ccab0.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: a89ede901964b82e7fe6b6bcb917bb3bf80efb6c Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit > > no, it doesn't follow, because > > > > - LL access wouldn't solve the problem for temp users anyway, > > because they're often going to need access beyond the local link > > In 80-90% of cases, what they need is a way to print, or get files to > a machine in the same room. your temp users must be different than ours. lots of ours want to check their email, or to download files. > > - Apparently MIT doesn't want users to use the network without being > > registered. Use of LL would circumvent that policy. I think that > > the policy for MIT's networks should be set by MIT. If their policy > > or the implementation thereof is too onerous, that may be > > unfortunate, but it's not a problem for IETF to solve. > > I'm not *saying* that the IETF needs to solve MIT's problems. That > would take decades. > I'm *saying* that there is a need for LL to run > even with other address management going on. and I'm saying that neither you nor this working group has any business dictating to a LAN administrator that he or she "needs" for LL to circumvent his/her existing address management or network access policies. > To the point, MIT doesn¹t > much care about LL, as long as you aren't messing up the rest of the > network, which hasn't been happening, and there are a lot of folks > using it. perhaps not, but I assure you that other institutions do care about controlling access to their LANs. > > - Technical means are already available which would allow MIT's DHCP > > servers to grant temporary network access to temporary users, with > > appropriate bandwidth/routing limitations on such use. (If the > > University of Tennesse can do this I'm sure MIT can manage it.) > > Right...set up an IP address, track it, disable it, for a consultant > to transfer a couple of PDFs...how efficient. let me put it another way - if MIT can't solve the problem more simply than that, perhaps they need to hire some more clever network engineers. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Mon Jan 20 16:48:39 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02117 for ; Mon, 20 Jan 2003 16:48:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF15791295; Mon, 20 Jan 2003 16:51:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B28B491296; Mon, 20 Jan 2003 16:51: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 63DAA91295 for ; Mon, 20 Jan 2003 16:51:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 439C55DEF9; Mon, 20 Jan 2003 16:51: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 CEA535DEBD for ; Mon, 20 Jan 2003 16:51: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 QAA27065 for ; Mon, 20 Jan 2003 16:51:50 -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 QAA19704 for ; Mon, 20 Jan 2003 16:51:50 -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 QAA10905 for ; Mon, 20 Jan 2003 16:49:03 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 20 Jan 2003 16:48:57 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030120145325.35d3023b.moore@cs.utk.edu> 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 QAA02117 On 01/20/2003 14:53, "Keith Moore" wrote: >> In 80-90% of cases, what they need is a way to print, or get files to >> a machine in the same room. > > your temp users must be different than ours. lots of ours want to check their > email, or to download files. Then you give them a DHCP address too. Where's the problem with both as appropriate? And no, it's not breaking a network, it's not going to invite every cracker on the planet in either. >> I'm not *saying* that the IETF needs to solve MIT's problems. That >> would take decades. > >> I'm *saying* that there is a need for LL to run >> even with other address management going on. > > and I'm saying that neither you nor this working group has any business > dictating to a LAN administrator that he or she "needs" for LL to circumvent > his/her existing address management or network access policies. How is LL circumventing *anything*? You keep nattering on about this, but quite honestly, it's not an issue. You have this oddly limited idea of how something is useful, and seem to reject anything that is outside that idea. You have yet to show where the simple existance of an additional LL address is going to break something, and you can't, because if it did on the scale you imply, then multiple addresses on an interface WOULD.NOT.WORK. But since they do, even when they are in entirely different networks, then your issues with this are invalid. As well, I *also* don't think the WG has any business creating a configuration method that is set up as to be inherently untrustworthy, and open to abuse...if all I have to do is act like a DHCP server to kill every LL device that can see me, then LL is useless. > >> To the point, MIT doesn¹t >> much care about LL, as long as you aren't messing up the rest of the >> network, which hasn't been happening, and there are a lot of folks >> using it. > > perhaps not, but I assure you that other institutions do care about > controlling access to their LANs. Oh, MIT cares about that quite a bit. But they also are wise enough to understand that there are times when you just need to print real quick, transfer a file, and there's no real point in forcing an entire registration/deregistration process for five minutes of work. >> Right...set up an IP address, track it, disable it, for a consultant >> to transfer a couple of PDFs...how efficient. > > let me put it another way - if MIT can't solve the problem more simply than > that, perhaps they need to hire some more clever network engineers. Oh, we're plenty clever. But we also don't allow any fool with a wireless card to get a DHCP address and become part of the network without registering the MAC address. You want DHCP, that's how you get it. You want access to data, then you need SSL and Kerberos access. But again, you lead the discussion off track *again*, this time by making MIT network ops an issue. *do* stay on point, hmm? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Jan 20 17:02:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02397 for ; Mon, 20 Jan 2003 17:02:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3D08991296; Mon, 20 Jan 2003 17:05:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16D2691297; Mon, 20 Jan 2003 17:05: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 E6A1391296 for ; Mon, 20 Jan 2003 17:05:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id C784B5DFC7; Mon, 20 Jan 2003 17:05:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by segue.merit.edu (Postfix) with ESMTP id 5B3BA5DF8A for ; Mon, 20 Jan 2003 17:05:17 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ak2c-0003uY-00; Mon, 20 Jan 2003 14:05:15 -0800 Date: Mon, 20 Jan 2003 17:01:40 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030120170140.7d640b45.moore@cs.utk.edu> In-Reply-To: References: <20030120145325.35d3023b.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > >> In 80-90% of cases, what they need is a way to print, or get files to > >> a machine in the same room. > > > > your temp users must be different than ours. lots of ours want to check > > their email, or to download files. > > Then you give them a DHCP address too. Where's the problem with both as > appropriate? Whether LL is appropriate depends on the needs of the user, the needs of the application, and the policies of the network on which it would be used. It has nothing to do with what you want. > > and I'm saying that neither you nor this working group has any business > > dictating to a LAN administrator that he or she "needs" for LL to > > circumvent his/her existing address management or network access policies. > > How is LL circumventing *anything*? You keep nattering on about this, but > quite honestly, it's not an issue. It's not for you or this working group to decide whether it is an issue. > You have this oddly limited idea of how > something is useful, and seem to reject anything that is outside that idea. No, I reject your trying to declare by fiat that whatever random idea you think is good for the world should be imposed on the world by overloading existing interfaces - and whatever breakage occurs as a result (be it apps or security or whatever) well, that's either somebody else's problem, or somebody else's fault for not doing things the way you think they should be done. > You have yet to show where the simple existance of an additional LL address > is going to break something, and you can't, because if it did on the scale > you imply, then multiple addresses on an interface WOULD.NOT.WORK. Multiple addresses on an interface are rarely used in IPv4, except on dedicated servers to support virtual hosting, precisely because they break things if apps have to be clever about which addresses to use in which circumstances. But multiple global addresses cause few problems because the app generally works no matter which address is chosen. OTOH, scoped addresses cause lots of problems. > As well, I *also* don't think the WG has any business > creating a configuration method that is set up as to be inherently > untrustworthy, and open to abuse... Good, then we agree that this WG has no busines creating LL, because LL is inherently untrustworthy and open to abuse. (of course, you want to define what trust and abuse mean for other people's networks.) From owner-zeroconf@merit.edu Mon Jan 20 17:50:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03492 for ; Mon, 20 Jan 2003 17:50:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A38449129D; Mon, 20 Jan 2003 17:54:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D1849129E; Mon, 20 Jan 2003 17:54:04 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4CBD89129D for ; Mon, 20 Jan 2003 17:54:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E88C5DE72; Mon, 20 Jan 2003 17:54:02 -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 D2C055DDE1 for ; Mon, 20 Jan 2003 17:54:01 -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); Mon, 20 Jan 2003 14:54:01 -0800 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Jan 2003 14:54:00 -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); Mon, 20 Jan 2003 14:54:00 -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); Mon, 20 Jan 2003 14:54:00 -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.3718.0); Mon, 20 Jan 2003 14:53:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Turning off link-locals? Date: Mon, 20 Jan 2003 14:53:58 -0800 Message-ID: Thread-Topic: Turning off link-locals? Thread-Index: AcLAzjagKVVO8sauQViSinZRjy+tpgAB+1sg From: "Christian Huitema" To: "John C. Welch" , "Zeroconf" X-OriginalArrivalTime: 20 Jan 2003 22:53:59.0851 (UTC) FILETIME=[D1FF77B0:01C2C0D6] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA03492 > Oh, we're plenty clever. But we also don't allow any fool with a wireless > card to get a DHCP address and become part of the network without > registering the MAC address. Protecting a network by registering the MAC addresses is both cumbersome and weak. In a secure environment, you would want to something like 802.1X for controlling network access, and then check some real security credentials before granting network access. Indeed, once you do that, you can just as well assume a DHCP server; there is hardly any reason to use zeroconf. -- Christian Huitema From owner-zeroconf@merit.edu Mon Jan 20 18:01:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03694 for ; Mon, 20 Jan 2003 18:01:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2B813912A0; Mon, 20 Jan 2003 18:04:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E93229129F; Mon, 20 Jan 2003 18:04: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 63A02912A0 for ; Mon, 20 Jan 2003 18:03:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 499645DF08; Mon, 20 Jan 2003 18:03:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by segue.merit.edu (Postfix) with ESMTP id 29D125DE16 for ; Mon, 20 Jan 2003 18:03:40 -0500 (EST) Received: from timepilot.gpcc.itd.umich.edu (timepilot.gpcc.itd.umich.edu [141.211.2.206]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id SAA12139 for ; Mon, 20 Jan 2003 18:03:39 -0500 (EST) Received: from localhost (sgoswami@localhost) by timepilot.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id SAA14234 for ; Mon, 20 Jan 2003 18:03:38 -0500 (EST) Date: Mon, 20 Jan 2003 18:03:38 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@timepilot.gpcc.itd.umich.edu To: Zeroconf Subject: RE: Turning off link-locals? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk I would think zeroconf adds value to networks that do not want or need infrastrcuture support such as DHCP. As for 802.1x - its security is weak too ( the 802.1x server is not authenticated). Secondly, a more philosophical question - do we need to have a seperate authentication protocol for each layer of the network ? Subrata On Mon, 20 Jan 2003, Christian Huitema wrote: > > Oh, we're plenty clever. But we also don't allow any fool with a > wireless > > card to get a DHCP address and become part of the network without > > registering the MAC address. > > Protecting a network by registering the MAC addresses is both cumbersome > and weak. In a secure environment, you would want to something like > 802.1X for controlling network access, and then check some real security > credentials before granting network access. Indeed, once you do that, > you can just as well assume a DHCP server; there is hardly any reason to > use zeroconf. > > -- Christian Huitema > From owner-zeroconf@merit.edu Mon Jan 20 18:05:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03738 for ; Mon, 20 Jan 2003 18:05:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5C9979129F; Mon, 20 Jan 2003 18:08:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A359912A1; Mon, 20 Jan 2003 18:08: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 027D39129F for ; Mon, 20 Jan 2003 18:08:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id E2A515DF11; Mon, 20 Jan 2003 18:08:21 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by segue.merit.edu (Postfix) with ESMTP id B98CF5DF08 for ; Mon, 20 Jan 2003 18:08:21 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18al1e-0004el-00; Mon, 20 Jan 2003 15:08:18 -0800 Date: Mon, 20 Jan 2003 18:04:42 -0500 From: Keith Moore To: "Christian Huitema" Cc: moore@cs.utk.edu, jwelch@MIT.EDU, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030120180442.53d064c6.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Mon, 20 Jan 2003 14:53:58 -0800 "Christian Huitema" wrote: > > Oh, we're plenty clever. But we also don't allow any fool with a wireless > > card to get a DHCP address and become part of the network without > > registering the MAC address. > > Protecting a network by registering the MAC addresses is both cumbersome > and weak. It depends on what you're trying to accomplish - are you trying to completely prevent network access by unauthorized users, or are you trying to marginalize them enough that they can be detected, or are you just trying to raise the bar a bit to make attacks harder than they would otherwise be? There's a saying that the purpose of locks on houses is to keep honest people honest. Most houses aren't terribly difficult to enter even if the doors are locked. But locked doors means that prospective trespassers have to work a bit harder, so they're useful for keeping out those who aren't so highly motivated. For similar reasons, less-than-perfect access controls on networks can also be useful. Keith From owner-zeroconf@merit.edu Mon Jan 20 18:06:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03779 for ; Mon, 20 Jan 2003 18:06:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D37C9912A1; Mon, 20 Jan 2003 18:09:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A317E912A2; Mon, 20 Jan 2003 18:09: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 74E2C912A1 for ; Mon, 20 Jan 2003 18:09:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6259E5DF11; Mon, 20 Jan 2003 18:09: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 EAECF5DDE1 for ; Mon, 20 Jan 2003 18:09: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 SAA23136 for ; Mon, 20 Jan 2003 18:09: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 SAA27941 for ; Mon, 20 Jan 2003 18:09:36 -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 SAA24832 for ; Mon, 20 Jan 2003 18:09:30 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 20 Jan 2003 18:09:29 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030120170140.7d640b45.moore@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 01/20/2003 17:01, "Keith Moore" wrote: >> Then you give them a DHCP address too. Where's the problem with both as >> appropriate? > > Whether LL is appropriate depends on the needs of the user, the needs of the > application, and the policies of the network on which it would be used. It > has nothing to do with what you want. Right...but *I* am saying, let it be there, *you* are saying, "To heck with what the user might need, if DHCP exists, turn LL OFF, and keep it off, regardless of need." >> How is LL circumventing *anything*? You keep nattering on about this, but >> quite honestly, it's not an issue. > > It's not for you or this working group to decide whether it is an issue. It's not for you to decide that either. > >> You have this oddly limited idea of how >> something is useful, and seem to reject anything that is outside that idea. > > No, I reject your trying to declare by fiat that whatever random idea you > think is good for the world should be imposed on the world by overloading > existing interfaces - and whatever breakage occurs as a result (be it apps or > security or whatever) well, that's either somebody else's problem, or somebody > else's fault for not doing things the way you think they should be done. Oh please, get a grip. If you don't like multiple IP's for interfaces, then you have a lot of windmills to tilt at. > >> You have yet to show where the simple existance of an additional LL address >> is going to break something, and you can't, because if it did on the scale >> you imply, then multiple addresses on an interface WOULD.NOT.WORK. > > Multiple addresses on an interface are rarely used in IPv4, except on > dedicated servers to support virtual hosting, precisely because they break > things if apps have to be clever about which addresses to use in which > circumstances. But multiple global addresses cause few problems because the > app generally works no matter which address is chosen. OTOH, scoped addresses > cause lots of problems. So they're rarely used except when they're used a LOT...there's a paradox for you. And multiple addresses of different scopes don't have problems unless the app tries to circumvent the OS and get clever on it's own. > >> As well, I *also* don't think the WG has any business >> creating a configuration method that is set up as to be inherently >> untrustworthy, and open to abuse... > > Good, then we agree that this WG has no busines creating LL, because LL is > inherently untrustworthy and open to abuse. (of course, you want to define > what trust and abuse mean for other people's networks.) No, *you* want to torpedo LL. I think that it's a noble, and good idea. But then, I think that networking should be easy NOW, not at some point in the random future. You still think that only geeks should be able to set up networks. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Jan 20 18:08:18 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03804 for ; Mon, 20 Jan 2003 18:08:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 524F6912A2; Mon, 20 Jan 2003 18:11:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21F31912A3; Mon, 20 Jan 2003 18:11: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 11EA9912A2 for ; Mon, 20 Jan 2003 18:11:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id E97925DF1B; Mon, 20 Jan 2003 18:11: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 7E6735DF2B for ; Mon, 20 Jan 2003 18:11:32 -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 SAA23662 for ; Mon, 20 Jan 2003 18:11:31 -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 SAA26237 for ; Mon, 20 Jan 2003 18:11: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 SAA25087 for ; Mon, 20 Jan 2003 18:11:29 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 20 Jan 2003 18:11:28 -0500 Subject: Re: Turning off link-locals? 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 01/20/2003 17:53, "Christian Huitema" wrote: >> Oh, we're plenty clever. But we also don't allow any fool with a > wireless >> card to get a DHCP address and become part of the network without >> registering the MAC address. > > Protecting a network by registering the MAC addresses is both cumbersome > and weak. In a secure environment, you would want to something like > 802.1X for controlling network access, and then check some real security > credentials before granting network access. Indeed, once you do that, > you can just as well assume a DHCP server; there is hardly any reason to > use zeroconf. I agree, but you ever try to get a University to change *anything*? They're really bad at it. Secondly, again, why grant institute-wide access when it isn't required. If I just want to get a file from laptop a to laptop b (which isn't registered), or print a file, then why go through all that, when LL gives you that ability, and is what it's *designed* for. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Jan 20 18:35:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04515 for ; Mon, 20 Jan 2003 18:35:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C693B912A5; Mon, 20 Jan 2003 18:38:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A10F912A6; Mon, 20 Jan 2003 18:38: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 63AC5912A5 for ; Mon, 20 Jan 2003 18:38:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 45B515DF1B; Mon, 20 Jan 2003 18:38:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id C11715DF17 for ; Mon, 20 Jan 2003 18:38:19 -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 h0KNcJw13794 for ; Mon, 20 Jan 2003 15:38:19 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 20 Jan 2003 15:38:19 -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 h0KNcIs07000 for ; Mon, 20 Jan 2003 15:38:18 -0800 (PST) Date: Mon, 20 Jan 2003 15:38:08 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030117094337.7eac176e.moore@cs.utk.edu> Message-Id: <3AC3B674-2CD0-11D7-A610-000393760260@apple.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, January 17, 2003, at 06:43 AM, Keith Moore wrote: > On Thu, 16 Jan 2003 15:55:55 -0500 > Daniel Senie wrote: > >> What's wrong, is that limits the ability to develop a class of >> devices that >> ONLY operates in the linklocal addressing block. There is a great >> deal of >> interest in such devices, and, IMO, no good reason to preclude such >> from >> the market. > > this is not in the group's charter. and it's ridiculous to assume that > any > device only needs to talk to other devices on its local network > segment. > it's even more ridiculous to demand that every IPv4 host that wants to > support > zeroconf be configured by default to be able to talk to such > dysfunctional > devices. It ridiculous to assume that there are no devices for which it makes sense to only talk with devices on the local network segment. In the case of a car, it might be nice if some of the various computers talked to each other with ip instead of the proprietary protocols they use. I'd really like it if my alpine DVD player had a web browser that could bring up a configuration page for some of the options for my car. I really don't like having to use pedals, switches, knobs and dials in some obscure way to do something as silly as disable the horn when I lock the car. In some of the devices in the car, it may not be seen as worth while to implement DHCP, how often is DHCP really going to be used. The car may have an ethernet jack and I may hook it up to my home network sometime so I can copy some music from my computer to the sound system in the car. When I hook the car up to my home network, a DHCP server will be present. I'd still like my computer with a global address to be able to communicate with devices in the car that have LL addresses. This whole thread has gone pretty far off track. The suggestion was made that there be a way to disable IPv4LL. It hasn't yet been made clear if that means disabling the ability of nodes to acquire IPv4LL addresses or the ability for any device to communicate with a device that has only an IPv4LL address. A DHCP option was suggested, along with a new as yet undefined protocol, the strawman one. If the draft is changed to suggest that a device only acquire an IPv4LL on an interface that does not have a global address, then the DHCP option for disabling IPv4LL doesn't make a lot of sense. Enough about MIT already. There's nothing to stop people from running AppleTalk or IPv6 on their wireless network for sharing files or printing. There is no protocol defined to disable AppleTalk. There is no protocol defined to disable IPv6. Similarly, there is no protocol to disable manual configuration of IPv4 addresses or DHCP. I still don't see why we should define a protocol to disable IPv4LL. I think it makes sense to only acquire an IPv4LL address when the preferred configuration method fails (dhcp, bootp, whatever). I think it makes sense to allow hosts with global addresses to communicate with IPv4LLs. I think some devices may choose not to implement DHCP and rely on IPv4LL for their addresses. I don't believe we should explicit restrict the possibility of such devices. -josh From owner-zeroconf@merit.edu Mon Jan 20 18:51:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04766 for ; Mon, 20 Jan 2003 18:51:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F3E94912A6; Mon, 20 Jan 2003 18:55:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C343C912A7; Mon, 20 Jan 2003 18:55: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 9AE4A912A6 for ; Mon, 20 Jan 2003 18:55:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7AB185DF60; Mon, 20 Jan 2003 18:55:02 -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 39C3E5DF1B for ; Mon, 20 Jan 2003 18:55:02 -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); Mon, 20 Jan 2003 15:54:58 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Jan 2003 15:54:58 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 20 Jan 2003 15:54:58 -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); Mon, 20 Jan 2003 15:54:58 -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.3718.0); Mon, 20 Jan 2003 15:54:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Turning off link-locals? Date: Mon, 20 Jan 2003 15:54:56 -0800 Message-ID: Thread-Topic: Turning off link-locals? Thread-Index: AcLA2U8Jv0/9tYyRQzqO3BrunI2sVAABGPsw From: "Christian Huitema" To: "John C. Welch" , "Zeroconf" X-OriginalArrivalTime: 20 Jan 2003 23:54:57.0706 (UTC) FILETIME=[563FD8A0:01C2C0DF] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA04766 > Secondly, again, why grant institute-wide access when it isn't required. > If > I just want to get a file from laptop a to laptop b (which isn't > registered), or print a file, then why go through all that, when LL gives > you that ability, and is what it's *designed* for. Well, it seems that we have a rough consensus on at least one point: if a host has a DHCP allocated address, it should not need to also configure a LL address for the same interface. The consensus could be implemented by removing the statements in the specification that preclude communication between LL addresses and configured addresses on the same link. We have a debate on another point which is whether DHCP configured hosts should accept to communicate with LL configured hosts on the same link "all the time" or only "when explicitly authorized" -- what I called the second knob. There is some weak security benefit to disallowing such communication, but it could be argued that the benefit is not worth the operational cost, and that if we want to prevent link layer access then we should use some real link layer access service. There is also a modest operational benefit in disallowing this communication: it forces the "visiting device" to acquire a global, non ambiguous address, and thus avoids the programming hassles caused by scoped addresses on multi homed hosts and routers. My take on this would be to define an explicit DHCP option that says "don't speak to LL on this link"; in the absence of the option, LL-aware hosts would happily exchange packets with LL-addressed hosts on the same link. -- Christian Huitema From owner-zeroconf@merit.edu Mon Jan 20 19:03:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04975 for ; Mon, 20 Jan 2003 19:03:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 84C88912A9; Mon, 20 Jan 2003 19:06:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 52731912A8; Mon, 20 Jan 2003 19:06: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 26FA6912AA for ; Mon, 20 Jan 2003 19:05:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0DA215DF08; Mon, 20 Jan 2003 19:05:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 987675DF07 for ; Mon, 20 Jan 2003 19:05:33 -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 TAA07318 for ; Mon, 20 Jan 2003 19:05:31 -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 TAA29379 for ; Mon, 20 Jan 2003 19:05: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 TAA02057 for ; Mon, 20 Jan 2003 19:05:24 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 20 Jan 2003 19:05:22 -0500 Subject: Re: Turning off link-locals? 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 01/20/2003 18:54, "Christian Huitema" wrote: > Well, it seems that we have a rough consensus on at least one point: if > a host has a DHCP allocated address, it should not need to also > configure a LL address for the same interface. The consensus could be > implemented by removing the statements in the specification that > preclude communication between LL addresses and configured addresses on > the same link. If you have a visitor that needs to print, and you don't have open DHCP access on your network, then that printer which has a DHCP configured address needs to be able to simultaneously use a LL address on the same interface. They don't need, nor even want to talk to global or NAT'd addresses...they need a connection that lasts long enough to kill trees. LL provides this perfectly. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Jan 20 19:04:50 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05001 for ; Mon, 20 Jan 2003 19:04:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B570E912A8; Mon, 20 Jan 2003 19:07:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F05A912AA; Mon, 20 Jan 2003 19:07: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 3E3A7912A8 for ; Mon, 20 Jan 2003 19:07:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A56C5DF08; Mon, 20 Jan 2003 19:07:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by segue.merit.edu (Postfix) with ESMTP id 0993B5DF07 for ; Mon, 20 Jan 2003 19:07:58 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18alxL-0000lW-00; Mon, 20 Jan 2003 16:07:55 -0800 Date: Mon, 20 Jan 2003 19:04:16 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030120190416.57564420.moore@cs.utk.edu> In-Reply-To: References: <20030120170140.7d640b45.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 01/20/2003 17:01, "Keith Moore" wrote: > > >> Then you give them a DHCP address too. Where's the problem with both as > >> appropriate? > > > > Whether LL is appropriate depends on the needs of the user, the needs of > > the application, and the policies of the network on which it would be > > used. It has nothing to do with what you want. > > Right...but *I* am saying, let it be there, *you* are saying, "To heck with > what the user might need, if DHCP exists, turn LL OFF, and keep it off, > regardless of need." Nope. I'm saying, if DHCP exists, let DHCP dictate whether LL is used. DHCP can say yes, DHCP can say no. I don't even care much whether the default is yes or no as long as hosts that support LL are expected (in the absence of explicit configuration) to try a DHCP query and if it responds, honor what it says. Or if DHCP is too onerous, require LL hosts to support at least bootp. Or if that is too onerous, require that LL-capable hosts recognize some specialized response to claims for LL addresses that means "this network does not use LL, use this address/netmask/default instead". The amount of extra code required to support this can be made very small. But there needs to be some way for a managed network to disable LL. > >> How is LL circumventing *anything*? You keep nattering on about this, but > >> quite honestly, it's not an issue. > > > > It's not for you or this working group to decide whether it is an issue. > > It's not for you to decide that either. Hey, I'm not the one who is insisting on changing the behavior of existing widely-used interfaces. > > Multiple addresses on an interface are rarely used in IPv4, except on > > dedicated servers to support virtual hosting, precisely because they break > > things if apps have to be clever about which addresses to use in which > > circumstances. But multiple global addresses cause few problems because > > the app generally works no matter which address is chosen. OTOH, scoped > > addresses cause lots of problems. > > So they're rarely used except when they're used a LOT...there's a paradox > for you. I have no trouble sorting it out. Very few IPv4 hosts have multiple addresses on even a single interface, and the few that do have multiple addresses tend to be used for a few specific apps that are built to deal with that. > And multiple addresses of different scopes don't have problems > unless the app tries to circumvent the OS and get clever on it's own. Again, you don't get to impose your idea of the role of the OS (and what it means to circumvent it) on application writers. > > Good, then we agree that this WG has no busines creating LL, because LL is > > inherently untrustworthy and open to abuse. (of course, you want to > > define what trust and abuse mean for other people's networks.) > > No, *you* want to torpedo LL. No, I want to fix it. You are the one who keeps insisting that LL be imposed on everyone rather than made available to those networks that want to use it. > I think that it's a noble, and good idea. But > then, I think that networking should be easy NOW, not at some point in the > random future. You contradict yourself. LL makes networking harder, not easier. Keith From owner-zeroconf@merit.edu Mon Jan 20 19:13:18 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05115 for ; Mon, 20 Jan 2003 19:13:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F348C912AB; Mon, 20 Jan 2003 19:16:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B8C53912AC; Mon, 20 Jan 2003 19:16: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 4B5B0912AB for ; Mon, 20 Jan 2003 19:16:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 172655DF75; Mon, 20 Jan 2003 19:16:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from broadviewnet.net (unknown [64.115.0.82]) by segue.merit.edu (Postfix) with SMTP id 9B1D75DF68 for ; Mon, 20 Jan 2003 19:16:04 -0500 (EST) Received: (qmail 20449 invoked from network); 21 Jan 2003 00:16:03 -0000 Received: from unknown (HELO kabilla) (66.219.68.108) by smtp.broadviewnet.net with SMTP; 21 Jan 2003 00:16:03 -0000 Message-ID: <005501c2c0e2$490261f0$6401a8c0@kabilla> From: "Bill Rees" To: "Keith Moore" , "John C. Welch" Cc: , References: <20030120170140.7d640b45.moore@cs.utk.edu> <20030120190416.57564420.moore@cs.utk.edu> Subject: Re: Turning off link-locals? Date: Mon, 20 Jan 2003 16:16:02 -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" > You contradict yourself. LL makes networking harder, not easier. > > Keith > Seems to me that LL makes networking easier for the end user/device which is the apparent goal of zeroconf. The fact that life may be more difficult for network admins and it folks or even us is secondary. From owner-zeroconf@merit.edu Mon Jan 20 19:16:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05162 for ; Mon, 20 Jan 2003 19:16:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1DA77912AC; Mon, 20 Jan 2003 19:19:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2C4F912AE; Mon, 20 Jan 2003 19:19: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 2C75C912AC for ; Mon, 20 Jan 2003 19:17:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0E3665DF75; Mon, 20 Jan 2003 19:17:19 -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 C52585DF4B for ; Mon, 20 Jan 2003 19:17:10 -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 h0L0H2jf001555; Tue, 21 Jan 2003 10:17:04 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id h0L0H1E97992; Tue, 21 Jan 2003 10:17:01 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Tue, 21 Jan 2003 10:17:01 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: "John C. Welch" Cc: Zeroconf Subject: Re: Turning off link-locals? 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: -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 Mon, 20 Jan 2003, John C. Welch wrote: >If you have a visitor that needs to print, and you don't have open DHCP >access on your network, then that printer which has a DHCP configured >address needs to be able to simultaneously use a LL address on the same >interface. It just needs to be able to communicate with LL devices. It (being LL aware, of course) just needs a 169.254.0.0/16 route for the local subnet, and the visitor (being not only LL aware but having a LL address) has a 0.0.0.0/0 route for the local subnet. Thus they can both route to each other without compromising any other network connectivity they would have otherwise had. Mac OS X 10.2 implements this (or something along these lines), so you can talk to your LL devices without having a LL address yourself. Several people have pointed this out and I haven't seen anybody argue against it. Ian From owner-zeroconf@merit.edu Mon Jan 20 19:24:53 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05246 for ; Mon, 20 Jan 2003 19:24:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8674D912AD; Mon, 20 Jan 2003 19:28:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5001E912AE; Mon, 20 Jan 2003 19:28: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 EF575912AD for ; Mon, 20 Jan 2003 19:28:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id D66C25DF79; Mon, 20 Jan 2003 19:28:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by segue.merit.edu (Postfix) with ESMTP id 71C745DF4B for ; Mon, 20 Jan 2003 19:28:06 -0500 (EST) Received: from timepilot.gpcc.itd.umich.edu (timepilot.gpcc.itd.umich.edu [141.211.2.206]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id TAA10361; Mon, 20 Jan 2003 19:28:05 -0500 (EST) Received: from localhost (sgoswami@localhost) by timepilot.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id TAA26834; Mon, 20 Jan 2003 19:28:05 -0500 (EST) Date: Mon, 20 Jan 2003 19:28:05 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@timepilot.gpcc.itd.umich.edu To: Keith Moore Cc: "John C. Welch" , Subject: Re: Turning off link-locals? In-Reply-To: <20030120190416.57564420.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Mon, 20 Jan 2003, Keith Moore wrote: > > On 01/20/2003 17:01, "Keith Moore" wrote: > > > > >> Then you give them a DHCP address too. Where's the problem with both as > > >> appropriate? > > > > > > Whether LL is appropriate depends on the needs of the user, the needs of > > > the application, and the policies of the network on which it would be > > > used. It has nothing to do with what you want. > > > > Right...but *I* am saying, let it be there, *you* are saying, "To heck with > > what the user might need, if DHCP exists, turn LL OFF, and keep it off, > > regardless of need." > > Nope. I'm saying, if DHCP exists, let DHCP dictate whether LL is used. DHCP > can say yes, DHCP can say no. I don't even care much whether the default > is yes or no as long as hosts that support LL are expected (in the absence of > explicit configuration) to try a DHCP query and if it responds, honor what it > says. Here is the implict assumption that all LL hosts has a DHCP client. > > Or if DHCP is too onerous, require LL hosts to support at least bootp. Or if > that is too onerous, require that LL-capable hosts recognize some specialized > response to claims for LL addresses that means "this network does not use > LL, use this address/netmask/default instead". The amount of extra code > required to support this can be made very small. But there needs to be some > way for a managed network to disable LL. > disable at the client LL host (to the managed network ) ? The infrastructure should broadcast messages saying it is capable of doing LL, the LL hosts can listen for these messages and then configure a random LL address. > > >> How is LL circumventing *anything*? You keep nattering on about this, but > > >> quite honestly, it's not an issue. > > > > > > It's not for you or this working group to decide whether it is an issue. > > > > It's not for you to decide that either. > > Hey, I'm not the one who is insisting on changing the behavior of existing > widely-used interfaces. > > > > Multiple addresses on an interface are rarely used in IPv4, except on > > > dedicated servers to support virtual hosting, precisely because they break > > > things if apps have to be clever about which addresses to use in which > > > circumstances. But multiple global addresses cause few problems because > > > the app generally works no matter which address is chosen. OTOH, scoped > > > addresses cause lots of problems. > > > > So they're rarely used except when they're used a LOT...there's a paradox > > for you. > > I have no trouble sorting it out. Very few IPv4 hosts have multiple addresses > on even a single interface, and the few that do have multiple addresses tend > to be used for a few specific apps that are built to deal with that. > > > And multiple addresses of different scopes don't have problems > > unless the app tries to circumvent the OS and get clever on it's own. > > Again, you don't get to impose your idea of the role of the OS (and what it > means to circumvent it) on application writers. > > > > Good, then we agree that this WG has no busines creating LL, because LL is > > > inherently untrustworthy and open to abuse. (of course, you want to > > > define what trust and abuse mean for other people's networks.) > > > > No, *you* want to torpedo LL. > > No, I want to fix it. You are the one who keeps insisting that LL be imposed > on everyone rather than made available to those networks that want to use it. > > > I think that it's a noble, and good idea. But > > then, I think that networking should be easy NOW, not at some point in the > > random future. > > You contradict yourself. LL makes networking harder, not easier. > > Keith > From owner-zeroconf@merit.edu Mon Jan 20 19:31:50 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05402 for ; Mon, 20 Jan 2003 19:31:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EEF02912AE; Mon, 20 Jan 2003 19:35:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA84B912AF; Mon, 20 Jan 2003 19:35: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 842B9912AE for ; Mon, 20 Jan 2003 19:35:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6B81C5DF79; Mon, 20 Jan 2003 19:35:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by segue.merit.edu (Postfix) with ESMTP id 4AD7B5DF23 for ; Mon, 20 Jan 2003 19:35:04 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18amNW-0001YP-00; Mon, 20 Jan 2003 16:34:58 -0800 Date: Mon, 20 Jan 2003 19:31:23 -0500 From: Keith Moore To: Joshua Graessley Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030120193123.74327223.moore@cs.utk.edu> In-Reply-To: <3AC3B674-2CD0-11D7-A610-000393760260@apple.com> References: <20030117094337.7eac176e.moore@cs.utk.edu> <3AC3B674-2CD0-11D7-A610-000393760260@apple.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Mon, 20 Jan 2003 15:38:08 -0800 Joshua Graessley wrote: > > On Friday, January 17, 2003, at 06:43 AM, Keith Moore wrote: > > > On Thu, 16 Jan 2003 15:55:55 -0500 > > Daniel Senie wrote: > > > >> What's wrong, is that limits the ability to develop a class of > >> devices that ONLY operates in the linklocal addressing block. There is a > >great > deal of interest in such devices, and, IMO, no good reason to > >preclude such > from the market. > > > > this is not in the group's charter. and it's ridiculous to assume that > > any device only needs to talk to other devices on its local network > > segment. it's even more ridiculous to demand that every IPv4 host that > > wants to support zeroconf be configured by default to be able to talk to > > such dysfunctional devices. > > It ridiculous to assume that there are no devices for which it makes > sense to only talk with devices on the local network segment. Nobody is making that assumption. The assumption is that a) there are few devices for which it really makes sense to restrict them to talking only on the local network segment, (so few that it's not worth it to have a special facility for them) b) most devices built with such restrictions would be making unwarranted and unreasonable assumptions about the organization of their users' networks and/or the relative properties of on-link vs. off-link hosts c) such devices would, if widely deployed, constrain the organization of networks in an unproductive way, e.g. encouraging more use of bridging when routing might be more appropriate, or vice versa, when other means of access control would be better and more flexible d) scoped addresses mess up the IP architecture, and increase the burden on applications that need to use them, so it's wise to avoid them as much as possible > In the > case of a car, it might be nice if some of the various computers talked > to each other with ip instead of the proprietary protocols they use. Fine; just don't expect IETF to say that it's acceptable for car devices to speak only LL. I want my car mp3 player to be able to sync up with my home mp3 collection over an 802.11 network when it's parked in my driveway, or over a cell phone when I'm on the road -- and my house and my car are unlikely to be on the same network segment. (For that matter, don't assume that the devices in the car are going to be clients and that they'll initiate all connections - I want to be able to push new tunes to its mp3 player from my warm cozy house. My car needs a global IP address, which given the address shortage in IPv4 implies IPv6.) > In some of the devices in the car, it may not be seen as > worth while to implement DHCP, how often is DHCP really going to be > used. So pick a simpler mechanism to allow the devices to determine whether they should be assigned an address or they should pick one. But don't impose the architectural restriction that all of the hosts on an automotive network have to use scoped addresses. > The car may have an ethernet jack and I may hook it up to my home > network sometime so I can copy some music from my computer to the sound > system in the car. When I hook the car up to my home network, a DHCP > server will be present. I'd still like my computer with a global > address to be able to communicate with devices in the car that have LL > addresses. I have no problem with that. What I have a problem with is: a) IETF saying that any device that supports LL should always support LL, without giving the network any mechanism to disable it. (the mechanism doesn't have to be the mere presence of a DHCP server, but there does need to be a mechanism), or b) IETF saying that it's useful for a device to support only LL > I think it makes sense to only acquire an IPv4LL address when the > preferred configuration method fails (dhcp, bootp, whatever). agreed. > I think it makes sense to allow hosts with global addresses to communicate > with IPv4LLs. agreed, provided v4LL is permitted on that network segment. > I think some devices may choose not to implement DHCP and rely > on IPv4LL for their addresses. I don't believe we should explicit > restrict the possibility of such devices. I don't think it's reasonable for devices to assume that v4LL only is sufficient. DHCP might be too onerous, if so we need another mechanism. Trying to forbid such devices might be going too far, but we should probably try to strongly discourage folks from producing such things. From owner-zeroconf@merit.edu Mon Jan 20 19:35:36 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05467 for ; Mon, 20 Jan 2003 19:35:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 88E40912B8; Mon, 20 Jan 2003 19:38:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E425912B5; Mon, 20 Jan 2003 19:38: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 C7A09912B0 for ; Mon, 20 Jan 2003 19:38:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id ACB165DF7E; Mon, 20 Jan 2003 19:38:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by segue.merit.edu (Postfix) with ESMTP id 8C3FE5DF79 for ; Mon, 20 Jan 2003 19:38:25 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18amQp-0001rl-00; Mon, 20 Jan 2003 16:38:23 -0800 Date: Mon, 20 Jan 2003 19:34:45 -0500 From: Keith Moore To: "Bill Rees" Cc: moore@cs.utk.edu, jwelch@MIT.EDU, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030120193445.0f5e89a9.moore@cs.utk.edu> In-Reply-To: <005501c2c0e2$490261f0$6401a8c0@kabilla> References: <20030120170140.7d640b45.moore@cs.utk.edu> <20030120190416.57564420.moore@cs.utk.edu> <005501c2c0e2$490261f0$6401a8c0@kabilla> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Mon, 20 Jan 2003 16:16:02 -0800 "Bill Rees" wrote: > > ----- Original Message ----- > From: "Keith Moore" > > You contradict yourself. LL makes networking harder, not easier. > > > > Keith > > > > Seems to me that LL makes networking easier for the end user/device which is > the apparent goal of zeroconf. The fact that life may be more difficult for > network admins and it folks or even us is secondary. in the end, LL makes networking more difficult for everyone. instead of configuring hosts and networks you end up configuring apps that need to try to circumvent the limitations imposed by scoped addresses. minimizing IP configuration is a noble goal - and LL is a step backward. From owner-zeroconf@merit.edu Mon Jan 20 19:41:35 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05584 for ; Mon, 20 Jan 2003 19:41:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3D280912B1; Mon, 20 Jan 2003 19:44:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 12D33912B3; Mon, 20 Jan 2003 19:44: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 A772C912B1 for ; Mon, 20 Jan 2003 19:44:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9333F5DF79; Mon, 20 Jan 2003 19:44:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from broadviewnet.net (unknown [64.115.0.82]) by segue.merit.edu (Postfix) with SMTP id 26CDD5DF23 for ; Mon, 20 Jan 2003 19:44:39 -0500 (EST) Received: (qmail 21190 invoked from network); 21 Jan 2003 00:44:38 -0000 Received: from unknown (HELO kabilla) (66.219.68.108) by smtp.broadviewnet.net with SMTP; 21 Jan 2003 00:44:38 -0000 Message-ID: <006701c2c0e6$4701da30$6401a8c0@kabilla> From: "Bill Rees" To: "Keith Moore" , "Joshua Graessley" Cc: , References: <20030117094337.7eac176e.moore@cs.utk.edu> <3AC3B674-2CD0-11D7-A610-000393760260@apple.com> <20030120193123.74327223.moore@cs.utk.edu> Subject: Re: Turning off link-locals? Date: Mon, 20 Jan 2003 16:44:37 -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 > > I think some devices may choose not to implement DHCP and rely > > on IPv4LL for their addresses. I don't believe we should explicit > > restrict the possibility of such devices. > > I don't think it's reasonable for devices to assume that v4LL only is > sufficient. DHCP might be too onerous, if so we need another mechanism. > Trying to forbid such devices might be going too far, but we should probably > try to strongly discourage folks from producing such things. > > There will certainly be deivces that support only v4LL and to suggest that vendors include extra cruft to handle multiple configuration protocols is probably futile. I don't know yet, but will definitely check, whether the devices Apple and their partners have produced according to the Rendezvous spec are v4LL only devices. To discourage this practice is naive at best and just as arrogant as the notion that IETF will dictate how to configure networks. From owner-zeroconf@merit.edu Mon Jan 20 19:48:39 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05748 for ; Mon, 20 Jan 2003 19:48:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 44DF8912B2; Mon, 20 Jan 2003 19:51:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 002EB912B3; Mon, 20 Jan 2003 19:51: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 D61CF912B2 for ; Mon, 20 Jan 2003 19:51:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id BE58D5DF7E; Mon, 20 Jan 2003 19:51:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by segue.merit.edu (Postfix) with ESMTP id 9E2F15DF7D for ; Mon, 20 Jan 2003 19:51:53 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18amdp-0002uD-00; Mon, 20 Jan 2003 16:51:49 -0800 Date: Mon, 20 Jan 2003 19:48:12 -0500 From: Keith Moore To: "Bill Rees" Cc: moore@cs.utk.edu, jgraessley@apple.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030120194812.2db645b4.moore@cs.utk.edu> In-Reply-To: <006701c2c0e6$4701da30$6401a8c0@kabilla> References: <20030117094337.7eac176e.moore@cs.utk.edu> <3AC3B674-2CD0-11D7-A610-000393760260@apple.com> <20030120193123.74327223.moore@cs.utk.edu> <006701c2c0e6$4701da30$6401a8c0@kabilla> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 will certainly be deivces that support only v4LL and to suggest that > vendors include extra cruft to handle multiple configuration protocols is > probably futile. I don't know yet, but will definitely check, whether the > devices Apple and their partners have produced according to the Rendezvous > spec are v4LL only devices. To discourage this practice is naive at best > and just as arrogant as the notion that IETF will dictate how to configure > networks. It may be naive to assume that people won't try to do harmful things. But that doesn't mean that IETF should endorse people doing harmful things, and there are good reasons for IETF to say that those things are harmful even if it won't prevent vendors from doing them. Keith From owner-zeroconf@merit.edu Mon Jan 20 19:54:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05821 for ; Mon, 20 Jan 2003 19:54:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC238912B3; Mon, 20 Jan 2003 19:57:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBBF0912B4; Mon, 20 Jan 2003 19:57:21 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D89C912B3 for ; Mon, 20 Jan 2003 19:57:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7DBAD5DF84; Mon, 20 Jan 2003 19:57:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from broadviewnet.net (unknown [64.115.0.82]) by segue.merit.edu (Postfix) with SMTP id 4A9375DF31 for ; Mon, 20 Jan 2003 19:57:20 -0500 (EST) Received: (qmail 21503 invoked from network); 21 Jan 2003 00:57:19 -0000 Received: from unknown (HELO kabilla) (66.219.68.108) by smtp.broadviewnet.net with SMTP; 21 Jan 2003 00:57:19 -0000 Message-ID: <007101c2c0e8$0cacebc0$6401a8c0@kabilla> From: "Bill Rees" To: "Keith Moore" Cc: , , References: <20030120170140.7d640b45.moore@cs.utk.edu> <20030120190416.57564420.moore@cs.utk.edu> <005501c2c0e2$490261f0$6401a8c0@kabilla> <20030120193445.0f5e89a9.moore@cs.utk.edu> Subject: Re: Turning off link-locals? Date: Mon, 20 Jan 2003 16:57:18 -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" > > From: "Keith Moore" > > > You contradict yourself. LL makes networking harder, not easier. > > > > > > Keith > > > > > > > Seems to me that LL makes networking easier for the end user/device which is > > the apparent goal of zeroconf. The fact that life may be more difficult for > > network admins and it folks or even us is secondary. > > in the end, LL makes networking more difficult for everyone. instead of > configuring hosts and networks you end up configuring apps that need to try to > circumvent the limitations imposed by scoped addresses. > > minimizing IP configuration is a noble goal - and LL is a step backward. > No. LL is a definite step forward simply because no steps have happenned to this point. LL solves a problem in home networks where people have no clue how to manage a network so if they purchase a new receiver or tv and want the device to work with the other devices in their living room, it will. No DHCP, no bootp, no server. Any other network environment where more sophisticated management requirements exist there will surely be mechanisms to bottle up v4LL especially if you dictate some on/off switch mechanism. This requirement would be no worse/better than many other instances where new technology produced unexpected and bad side-effects. I'm not advocating casting a blind eye to these problems but I am advocating that to the extent a fix breaks the goal of zero configuration (think of this as the Rabid Rights problem with logic) the problem should go into the possibly won't fix column. From owner-zeroconf@merit.edu Mon Jan 20 23:02:21 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09129 for ; Mon, 20 Jan 2003 23:02:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C3C43912C0; Mon, 20 Jan 2003 23:04:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF2AF91327; Mon, 20 Jan 2003 23: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 646E791326 for ; Mon, 20 Jan 2003 23:02:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4C3DA5DF3C; Mon, 20 Jan 2003 23:02:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by segue.merit.edu (Postfix) with ESMTP id 2B2765DEBD for ; Mon, 20 Jan 2003 23:02:39 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18apcQ-0000Bp-00; Mon, 20 Jan 2003 20:02:34 -0800 Date: Mon, 20 Jan 2003 22:58:58 -0500 From: Keith Moore To: "Bill Rees" Cc: moore@cs.utk.edu, jwelch@MIT.EDU, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030120225858.45643d58.moore@cs.utk.edu> In-Reply-To: <007101c2c0e8$0cacebc0$6401a8c0@kabilla> References: <20030120170140.7d640b45.moore@cs.utk.edu> <20030120190416.57564420.moore@cs.utk.edu> <005501c2c0e2$490261f0$6401a8c0@kabilla> <20030120193445.0f5e89a9.moore@cs.utk.edu> <007101c2c0e8$0cacebc0$6401a8c0@kabilla> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > No. LL is a definite step forward simply because no steps have happenned to > this point. LL solves a problem in home networks where people have no clue > how to manage a network so if they purchase a new receiver or tv and want > the device to work with the other devices in their living room, it will. No > DHCP, no bootp, no server. Any other network environment where more > sophisticated management requirements exist there will surely be mechanisms > to bottle up v4LL especially if you dictate some on/off switch mechanism. LL produces a dysfunctional network that can run only a limited subset of the applications that the Internet can support. If this becomes the model for home networks it will cripple home networks. And as I said earlier, LL doesn't produce a zero configuration network, it just means that you end up spending much more effort configuring applications than you would have spent configuring the network in the current world, and you still get a less functional network as a result. LL can be justified for isolated ad hoc networks. For home networks - or any connected network - it is a disaster. From owner-zeroconf@merit.edu Mon Jan 20 23:07:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09175 for ; Mon, 20 Jan 2003 23:07:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B052491325; Mon, 20 Jan 2003 23:08:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6579691321; Mon, 20 Jan 2003 23: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 377F691325 for ; Mon, 20 Jan 2003 23:06:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1DDE15DEBD; Mon, 20 Jan 2003 23:06:49 -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 A4B6B5DF3C for ; Mon, 20 Jan 2003 23:06:48 -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 XAA03196 for ; Mon, 20 Jan 2003 23:06:48 -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 XAA09660 for ; Mon, 20 Jan 2003 23:06:47 -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 XAA27655 for ; Mon, 20 Jan 2003 23:02:25 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 20 Jan 2003 23:02:22 -0500 Subject: Re: Turning off link-locals? 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 01/20/2003 19:17, "Ian Lister" wrote: >> If you have a visitor that needs to print, and you don't have open DHCP >> access on your network, then that printer which has a DHCP configured >> address needs to be able to simultaneously use a LL address on the same >> interface. > > It just needs to be able to communicate with LL devices. It (being LL > aware, of course) just needs a 169.254.0.0/16 route for the local subnet, > and the visitor (being not only LL aware but having a LL address) has a > 0.0.0.0/0 route for the local subnet. Thus they can both route to each > other without compromising any other network connectivity they would have > otherwise had. Mac OS X 10.2 implements this (or something along these > lines), so you can talk to your LL devices without having a LL address > yourself. Right. But if DHCP kill LL, then this won't work. If you make it some bizaare switch, then it will only work correctly *sometime*, which is worse than not working 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 Mon Jan 20 23:07:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09190 for ; Mon, 20 Jan 2003 23:07:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5C05B9131E; Mon, 20 Jan 2003 23:09:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2528B91334; Mon, 20 Jan 2003 23:09: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 529AC9131E for ; Mon, 20 Jan 2003 23:09:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 165A15DE69; Mon, 20 Jan 2003 23:09:48 -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 8E4405DFE3 for ; Mon, 20 Jan 2003 23:09:47 -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 XAA03897 for ; Mon, 20 Jan 2003 23:09:47 -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 XAA09699 for ; Mon, 20 Jan 2003 23:06: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 XAA27441 for ; Mon, 20 Jan 2003 23:00:45 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 20 Jan 2003 23:00:43 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030120190416.57564420.moore@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 01/20/2003 19:04, "Keith Moore" wrote: > Nope. I'm saying, if DHCP exists, let DHCP dictate whether LL is used. DHCP > can say yes, DHCP can say no. I don't even care much whether the default > is yes or no as long as hosts that support LL are expected (in the absence of > explicit configuration) to try a DHCP query and if it responds, honor what it > says. Which means that any DHCP server, or any machine acting as one can now blow away your LL settings, and you'll never know why. Very secure. > > Or if DHCP is too onerous, require LL hosts to support at least bootp. Or if > that is too onerous, require that LL-capable hosts recognize some specialized > response to claims for LL addresses that means "this network does not use > LL, use this address/netmask/default instead". The amount of extra code > required to support this can be made very small. But there needs to be some > way for a managed network to disable LL. So, you are saying that it's not okay to have LL packets eating bandwidth, but it *is* okay to constantly broadcast LL shutoff packets? >> It's not for you to decide that either. > > Hey, I'm not the one who is insisting on changing the behavior of existing > widely-used interfaces. > LL's not new, neither is multiple addresses on an interface. >> >> So they're rarely used except when they're used a LOT...there's a paradox >> for you. > > I have no trouble sorting it out. Very few IPv4 hosts have multiple addresses > on even a single interface, and the few that do have multiple addresses tend > to be used for a few specific apps that are built to deal with that. And they break nothing on other machines. Thanks for making my point that multiple addresses on a single interface are not inherently dangerous as you have suggested. > >> And multiple addresses of different scopes don't have problems >> unless the app tries to circumvent the OS and get clever on it's own. > > Again, you don't get to impose your idea of the role of the OS (and what it > means to circumvent it) on application writers. But you do? If I'm using an application that is ignoring OS services to try and get IP addresses on it's own, it's a badly written application. That's what the OS is there for, to do the monkey work. You need to communicate with another device, you need access to network services, the OS provides them. That way, you don't have to write your own network stack for every hardware / os config your application will encounter. It's been quite the rage for a while now. >> No, *you* want to torpedo LL. > > No, I want to fix it. You are the one who keeps insisting that LL be imposed > on everyone rather than made available to those networks that want to use it. But you seem to think that all networks are monolithic entities, and the reality is, they aren't, they aren't even close, they don't work that way. Not even the military works that way, much less Universities, or multinational corporations. You cannot say with any certainty that ALL segments on a network work the same. There's no logical basis for it. > >> I think that it's a noble, and good idea. But >> then, I think that networking should be easy NOW, not at some point in the >> random future. > > You contradict yourself. LL makes networking harder, not easier. BWAAHAhAhAHAHA....not on the end that counts it doesn't. And you still have yet to provide definitive proof of it in a well-documented, repeatable, verifiable format that is an example of a problem that exists *NOW*. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Jan 20 23:07:46 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09203 for ; Mon, 20 Jan 2003 23:07:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0FF7B9132F; Mon, 20 Jan 2003 23:08:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9FF709131E; Mon, 20 Jan 2003 23: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 CD5929131E for ; Mon, 20 Jan 2003 23:06:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id AED425DFE3; Mon, 20 Jan 2003 23:06:48 -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 395E55DEBD for ; Mon, 20 Jan 2003 23:06:48 -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 XAA04799 for ; Mon, 20 Jan 2003 23:06:47 -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 XAA12746 for ; Mon, 20 Jan 2003 23:06:47 -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 XAA27792 for ; Mon, 20 Jan 2003 23:03:42 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 20 Jan 2003 23:03:39 -0500 Subject: Re: Turning off link-locals? 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 01/20/2003 19:28, "s. goswami" wrote: >> Nope. I'm saying, if DHCP exists, let DHCP dictate whether LL is used. DHCP >> can say yes, DHCP can say no. I don't even care much whether the default >> is yes or no as long as hosts that support LL are expected (in the absence of >> explicit configuration) to try a DHCP query and if it responds, honor what it >> says. > > Here is the implict assumption that all LL hosts has a DHCP > client. Yep...DHCP won't affect me at all, I don't use it. Manual configuration, so much for DHCP as a LL management tool. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Jan 20 23:11:32 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09261 for ; Mon, 20 Jan 2003 23:11:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4F070912BD; Mon, 20 Jan 2003 23:14:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 20A1D912BF; Mon, 20 Jan 2003 23:14: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 18C69912BD for ; Mon, 20 Jan 2003 23:14:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 06D555DFE3; Mon, 20 Jan 2003 23:14:47 -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 83DBF5DEBD for ; Mon, 20 Jan 2003 23:14:46 -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 XAA06654 for ; Mon, 20 Jan 2003 23:14:45 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA10084 for ; Mon, 20 Jan 2003 23:11:47 -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 XAA28062 for ; Mon, 20 Jan 2003 23:06:05 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 20 Jan 2003 23:06:03 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030120193445.0f5e89a9.moore@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 01/20/2003 19:34, "Keith Moore" wrote: >> Seems to me that LL makes networking easier for the end user/device which is >> the apparent goal of zeroconf. The fact that life may be more difficult for >> network admins and it folks or even us is secondary. > > in the end, LL makes networking more difficult for everyone. instead of > configuring hosts and networks you end up configuring apps that need to try to > circumvent the limitations imposed by scoped addresses. Only if the app is bypassing OS services. The app has no business directly probing at that level. The user/OS sets the IP address, and the app says, "I need to communicate with X at this address". The OS handles the rest. If the app is picking the interface, the app is broken. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Jan 20 23:22:26 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09325 for ; Mon, 20 Jan 2003 23:22:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 98342912BF; Mon, 20 Jan 2003 23:25:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63C8F9131F; Mon, 20 Jan 2003 23:25: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 4177F912BF for ; Mon, 20 Jan 2003 23:25:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 295FD5DFE3; Mon, 20 Jan 2003 23:25:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from broadviewnet.net (unknown [64.115.0.82]) by segue.merit.edu (Postfix) with SMTP id ABE685DE69 for ; Mon, 20 Jan 2003 23:25:37 -0500 (EST) Received: (qmail 25492 invoked from network); 21 Jan 2003 04:25:37 -0000 Received: from unknown (HELO kabilla) (66.219.68.108) by smtp.broadviewnet.net with SMTP; 21 Jan 2003 04:25:37 -0000 Message-ID: <00dc01c2c105$25abf9a0$6401a8c0@kabilla> From: "Bill Rees" To: "Keith Moore" Cc: , , References: <20030120170140.7d640b45.moore@cs.utk.edu> <20030120190416.57564420.moore@cs.utk.edu> <005501c2c0e2$490261f0$6401a8c0@kabilla> <20030120193445.0f5e89a9.moore@cs.utk.edu> <007101c2c0e8$0cacebc0$6401a8c0@kabilla> <20030120225858.45643d58.moore@cs.utk.edu> Subject: Re: Turning off link-locals? Date: Mon, 20 Jan 2003 20:25:35 -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" To: "Bill Rees" Cc: ; ; Sent: Monday, January 20, 2003 7:58 PM Subject: Re: Turning off link-locals? > > > No. LL is a definite step forward simply because no steps have happenned to > > this point. LL solves a problem in home networks where people have no clue > > how to manage a network so if they purchase a new receiver or tv and want > > the device to work with the other devices in their living room, it will. No > > DHCP, no bootp, no server. Any other network environment where more > > sophisticated management requirements exist there will surely be mechanisms > > to bottle up v4LL especially if you dictate some on/off switch mechanism. > > LL produces a dysfunctional network that can run only a limited subset of the > applications that the Internet can support. If this becomes the model for > home networks it will cripple home networks. And as I said earlier, LL > doesn't produce a zero configuration network, it just means that you end up > spending much more effort configuring applications than you would have spent > configuring the network in the current world, and you still get a less > functional network as a result. > Rendezvous is your worst enemy then. They will provide a solution to the home network problem, as will Microsoft and if you want any say in this then you have to accept LL or something very like it. The network will not be dysfunctional nor will limited subset of apps be a problem. As any new approach appears, there is always an adoption rate as IPv6 so readily points out. If you take the view that LL is more trouble than it's worth, then what would you do instead? You could use the 192.168 approach but then you have the same problem: small scope, dysfunctional network, limited apps. If you accept the dysfunctionality as just one state to internet nirvana, then you can show how to use LL as a simple intermediate step while awaiting fullscope network configuration. If LL only provides a means for a sysadmin to make the machine network visible in some fashion, then you provide enough config that the sysadmin can remotely config things instead of sitting in everyone's office. I would gladly accept this benefit as the only thing LL offers and care less about any other app. From owner-zeroconf@merit.edu Mon Jan 20 23:31:29 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09422 for ; Mon, 20 Jan 2003 23:31:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DCD359131F; Mon, 20 Jan 2003 23:34:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A810691320; Mon, 20 Jan 2003 23:34: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 8C2FD9131F for ; Mon, 20 Jan 2003 23:34:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 75EC95DEC1; Mon, 20 Jan 2003 23:34:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by segue.merit.edu (Postfix) with ESMTP id 55AC35DE69 for ; Mon, 20 Jan 2003 23:34:42 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18aq7U-000267-00; Mon, 20 Jan 2003 20:34:40 -0800 Date: Mon, 20 Jan 2003 23:31:04 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030120233104.073982e4.moore@cs.utk.edu> In-Reply-To: References: <20030120193445.0f5e89a9.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > in the end, LL makes networking more difficult for everyone. instead of > > configuring hosts and networks you end up configuring apps that need to try to > > circumvent the limitations imposed by scoped addresses. > > Only if the app is bypassing OS services. The app has no business directly > probing at that level. The user/OS sets the IP address, and the app says, "I > need to communicate with X at this address". The OS handles the rest. If the > app is picking the interface, the app is broken. it's not for you to define what APIs are appropriate for the app to use. and anyway, the app doesn't have to pick the interface. scoped addresses break things all by themselves. Keith From owner-zeroconf@merit.edu Mon Jan 20 23:35:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09464 for ; Mon, 20 Jan 2003 23:35:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 85C5B91320; Mon, 20 Jan 2003 23:38:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50EAC91321; Mon, 20 Jan 2003 23:38: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 EE67C91320 for ; Mon, 20 Jan 2003 23:38:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id BF39E5DFF9; Mon, 20 Jan 2003 23:38:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by segue.merit.edu (Postfix) with ESMTP id 9D4EF5DE69 for ; Mon, 20 Jan 2003 23:38:15 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18aqAv-00022g-00; Mon, 20 Jan 2003 20:38:14 -0800 Date: Mon, 20 Jan 2003 23:34:38 -0500 From: Keith Moore To: "Bill Rees" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030120233438.7c3e339a.moore@cs.utk.edu> In-Reply-To: <00dc01c2c105$25abf9a0$6401a8c0@kabilla> References: <20030120170140.7d640b45.moore@cs.utk.edu> <20030120190416.57564420.moore@cs.utk.edu> <005501c2c0e2$490261f0$6401a8c0@kabilla> <20030120193445.0f5e89a9.moore@cs.utk.edu> <007101c2c0e8$0cacebc0$6401a8c0@kabilla> <20030120225858.45643d58.moore@cs.utk.edu> <00dc01c2c105$25abf9a0$6401a8c0@kabilla> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > LL produces a dysfunctional network that can run only a limited subset of > > the applications that the Internet can support. If this becomes the model > > for home networks it will cripple home networks. And as I said earlier, > > LL doesn't produce a zero configuration network, it just means that you > > end up spending much more effort configuring applications than you would > > have spent configuring the network in the current world, and you still get > > a less functional network as a result. > > > > Rendezvous is your worst enemy then. rendezvous is a disaster. shipping it in production code was irresponsible. > They will provide a solution to the > home network problem, as will Microsoft and if you want any say in this then > you have to accept LL or something very like it. The network will not be > dysfunctional nor will limited subset of apps be a problem. because you say so? or because people won't realize that the network used to be able to support a wider range of apps with less overhead (and more reliably) before LL screwed it up? Keith From owner-zeroconf@merit.edu Mon Jan 20 23:46:29 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09645 for ; Mon, 20 Jan 2003 23:46:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B47A91321; Mon, 20 Jan 2003 23:49:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0465691323; Mon, 20 Jan 2003 23:49:45 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E6E5D91321 for ; Mon, 20 Jan 2003 23:49:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id C84445E00C; Mon, 20 Jan 2003 23:49:44 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from broadviewnet.net (unknown [64.115.0.82]) by segue.merit.edu (Postfix) with SMTP id 4D2495E00A for ; Mon, 20 Jan 2003 23:49:44 -0500 (EST) Received: (qmail 25785 invoked from network); 21 Jan 2003 04:49:43 -0000 Received: from unknown (HELO kabilla) (66.219.68.108) by smtp.broadviewnet.net with SMTP; 21 Jan 2003 04:49:43 -0000 Message-ID: <00ec01c2c108$840144d0$6401a8c0@kabilla> From: "Bill Rees" To: "Keith Moore" Cc: , References: <20030120170140.7d640b45.moore@cs.utk.edu> <20030120190416.57564420.moore@cs.utk.edu> <005501c2c0e2$490261f0$6401a8c0@kabilla> <20030120193445.0f5e89a9.moore@cs.utk.edu> <007101c2c0e8$0cacebc0$6401a8c0@kabilla> <20030120225858.45643d58.moore@cs.utk.edu> <00dc01c2c105$25abf9a0$6401a8c0@kabilla> <20030120233438.7c3e339a.moore@cs.utk.edu> Subject: Re: Turning off link-locals? Date: Mon, 20 Jan 2003 20:49:42 -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" > > They will provide a solution to the > > home network problem, as will Microsoft and if you want any say in this then > > you have to accept LL or something very like it. The network will not be > > dysfunctional nor will limited subset of apps be a problem. > > because you say so? or because people won't realize that the network used to > be able to support a wider range of apps with less overhead (and more > reliably) before LL screwed it up? > > > Keith > Because Apple and Microsoft don't give a flying fuck what you think. They will provide the apps to use the LL configuration and solve the home networking market to their benefit. People won't care that your big enterprise apps are fucked or that your networks are fucked or that your pretty theories are fucked. They only care about their hegemony and money. If you cannot present a solution that addresses that problem and provides the better-ness you desire then get out of the way cause Apple will run you over. If, instead, you tag along on their effort, you will much greater influence in minimizing network problems. The longer you bash v4LL, the less influence you will have. bill From owner-zeroconf@merit.edu Tue Jan 21 00:10:18 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09897 for ; Tue, 21 Jan 2003 00:10:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C61D691323; Tue, 21 Jan 2003 00:13:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9333D91324; Tue, 21 Jan 2003 00:13: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 5F26491323 for ; Tue, 21 Jan 2003 00:13:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 40BDF5DEC1; Tue, 21 Jan 2003 00:13:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by segue.merit.edu (Postfix) with ESMTP id 17BAD5DE69 for ; Tue, 21 Jan 2003 00:13:32 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18aqiw-0007IQ-00; Mon, 20 Jan 2003 21:13:22 -0800 Date: Tue, 21 Jan 2003 00:09:46 -0500 From: Keith Moore To: Ian Lister Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121000946.3ca8cef0.moore@cs.utk.edu> In-Reply-To: References: <20030120233438.7c3e339a.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Tue, 21 Jan 2003 14:46:24 +1000 (EST) Ian Lister wrote: > On Mon, 20 Jan 2003, Keith Moore wrote: > >rendezvous is a disaster. > > Oh good, then you'll be able to point to specific things that it has > broken. I've already listed several specific problems with LL addressing. the problems with name lookup are matters for other WGs. Keith From owner-zeroconf@merit.edu Tue Jan 21 00:11:29 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09922 for ; Tue, 21 Jan 2003 00:11:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2FDAD91324; Tue, 21 Jan 2003 00:14:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0108491326; Tue, 21 Jan 2003 00:14: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 C320091324 for ; Tue, 21 Jan 2003 00:14:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id A2BE35E01B; Tue, 21 Jan 2003 00:14:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by segue.merit.edu (Postfix) with ESMTP id 8262C5DE69 for ; Tue, 21 Jan 2003 00:14:34 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18aqk4-0001kr-00; Mon, 20 Jan 2003 21:14:33 -0800 Date: Tue, 21 Jan 2003 00:10:57 -0500 From: Keith Moore To: "Bill Rees" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121001057.1c9976a9.moore@cs.utk.edu> In-Reply-To: <00ec01c2c108$840144d0$6401a8c0@kabilla> References: <20030120170140.7d640b45.moore@cs.utk.edu> <20030120190416.57564420.moore@cs.utk.edu> <005501c2c0e2$490261f0$6401a8c0@kabilla> <20030120193445.0f5e89a9.moore@cs.utk.edu> <007101c2c0e8$0cacebc0$6401a8c0@kabilla> <20030120225858.45643d58.moore@cs.utk.edu> <00dc01c2c105$25abf9a0$6401a8c0@kabilla> <20030120233438.7c3e339a.moore@cs.utk.edu> <00ec01c2c108$840144d0$6401a8c0@kabilla> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Because Apple and Microsoft don't give a flying fuck what you think. maybe not, but I'll do whatever I can to keep them from using IETF to endorse their crap. Keith From owner-zeroconf@merit.edu Tue Jan 21 00:25:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11681 for ; Tue, 21 Jan 2003 00:25:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 518BE9132A; Tue, 21 Jan 2003 00:27:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24CEE91330; Tue, 21 Jan 2003 00:27: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 1D7FC9132A for ; Tue, 21 Jan 2003 00:27:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0233E5E00A; Tue, 21 Jan 2003 00:27: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 8C5125DFF5 for ; Tue, 21 Jan 2003 00:27: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 AAA21098 for ; Tue, 21 Jan 2003 00:27:27 -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 AAA16079 for ; Tue, 21 Jan 2003 00:27:26 -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 AAA05674 for ; Tue, 21 Jan 2003 00:27:26 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 21 Jan 2003 00:27:24 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030120233104.073982e4.moore@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 01/20/2003 23:31, "Keith Moore" wrote: >> Only if the app is bypassing OS services. The app has no business directly >> probing at that level. The user/OS sets the IP address, and the app says, "I >> need to communicate with X at this address". The OS handles the rest. If the >> app is picking the interface, the app is broken. > > it's not for you to define what APIs are appropriate for the app to use. No, and it's not the programmer's job to ignore OS services, and use convoluted, braindead methods that are fragile. > > and anyway, the app doesn't have to pick the interface. scoped addresses > break > things all by themselves. > No, they can't. They don't DO anything until a service using that address tries to use it. That's like that silly "TCP/IP isn't chatty"...no, because with no services running, it's not DOING anything. Of course, it's also useless without services, but hey, at least it's not chatty. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 21 00:25:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11716 for ; Tue, 21 Jan 2003 00:25:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1320D91327; Tue, 21 Jan 2003 00:29:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D26B391329; Tue, 21 Jan 2003 00:29: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 BEBEB91327 for ; Tue, 21 Jan 2003 00:29:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id B01A45DFE3; Tue, 21 Jan 2003 00:29:02 -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 47BF55DE69 for ; Tue, 21 Jan 2003 00:29:02 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA20142 for ; Tue, 21 Jan 2003 00:29:01 -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 AAA13302 for ; Tue, 21 Jan 2003 00:29:01 -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 AAA05809 for ; Tue, 21 Jan 2003 00:29:01 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 21 Jan 2003 00:28:58 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030120233438.7c3e339a.moore@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 01/20/2003 23:34, "Keith Moore" wrote: >> Rendezvous is your worst enemy then. > > rendezvous is a disaster. shipping it in production code was irresponsible. Yeah, how DARE apple make computers easier to use...oh wait, that's their reason for being. > >> They will provide a solution to the >> home network problem, as will Microsoft and if you want any say in this then >> you have to accept LL or something very like it. The network will not be >> dysfunctional nor will limited subset of apps be a problem. > > because you say so? or because people won't realize that the network used to > be able to support a wider range of apps with less overhead (and more > reliably) before LL screwed it up? And it'll melt your chocolate, turn your car into a Yugo, and make you watch "Hello Larry" reruns.... john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 21 00:28:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11732 for ; Tue, 21 Jan 2003 00:28:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8225B91329; Tue, 21 Jan 2003 00:30:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D7749132C; Tue, 21 Jan 2003 00:30: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 13F3F91329 for ; Tue, 21 Jan 2003 00:30:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F0545DDB9; Tue, 21 Jan 2003 00:30:19 -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 4BD095DFE3 for ; Tue, 21 Jan 2003 00:30:16 -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 AAA21545 for ; Tue, 21 Jan 2003 00:30:15 -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 AAA16149 for ; Tue, 21 Jan 2003 00:30:15 -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 AAA05933 for ; Tue, 21 Jan 2003 00:30:14 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 21 Jan 2003 00:30:13 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030121000946.3ca8cef0.moore@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 01/21/2003 00:09, "Keith Moore" wrote: >>> rendezvous is a disaster. >> >> Oh good, then you'll be able to point to specific things that it has >> broken. > > I've already listed several specific problems with LL addressing. > the problems with name lookup are matters for other WGs. As I recall, you decided not to send those problems to the list, mostly to spite me. So, pardon some of us if we still think you are way out in left field. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 21 00:28:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11756 for ; Tue, 21 Jan 2003 00:28:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9F1469132C; Tue, 21 Jan 2003 00:31:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C16659132D; Tue, 21 Jan 2003 00:31: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 997B59132C for ; Tue, 21 Jan 2003 00:31:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id D0C8A5E00A; Tue, 21 Jan 2003 00:31:32 -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 DCA775DDB9 for ; Tue, 21 Jan 2003 00:31:30 -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 h0KMVT601992 for ; Mon, 20 Jan 2003 15:31:29 -0700 Date: Mon, 20 Jan 2003 22:31:28 -0700 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Alex Karahalios To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030120193123.74327223.moore@cs.utk.edu> Message-Id: <972B6B58-2D01-11D7-9771-00039377AD70@Outersoft.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Keith, I don't think we should discourage anyone from producing devices which only speak v4LL. Anyone is free to create devices which speak only v4LL, and they are also free to create devices which only speak UDP and don't speak TCP. You see, no matter how objectionable you find v4LL and no matter what the IETF says, there will always be vendors out there that will create their own standards. Apple and Microsoft will head in that direction if the IETF does nothing about v4LL or mDNS. My view on this is more pragmatic. v4LL and the rest of the ZeroConf protocols make my life as an embedded network processor vendor allot easier. Right now I can have my devices discovered on the network by MAC, PC and Linux machines. This a tremendous benefit and the code required to do this is rather trivial. There is nothing else out there, other than ZeroConf, which covers as many platforms which is ready to use. Alex Karahalios P.S. I would participate in these discussion more, but I am already several months behind in my development work. I was hoping that these v4LL issues would have blown over by now. I guess this IETF standardization is a slow process. The good news is that nothing has changed in the draft in the last 4 months that would require my changing any of my code. On Monday, January 20, 2003, at 05:31 PM, Keith Moore wrote: > I don't think it's reasonable for devices to assume that v4LL only is > sufficient. DHCP might be too onerous, if so we need another > mechanism. > Trying to forbid such devices might be going too far, but we should > probably > try to strongly discourage folks from producing such things. From owner-zeroconf@merit.edu Tue Jan 21 00:31:56 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11835 for ; Tue, 21 Jan 2003 00:31:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D7E709132B; Tue, 21 Jan 2003 00:35:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A72C79132D; Tue, 21 Jan 2003 00:35: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 9576A9132B for ; Tue, 21 Jan 2003 00:35:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F3B75DEBD; Tue, 21 Jan 2003 00:35: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 15BAD5DE69 for ; Tue, 21 Jan 2003 00:35:11 -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 AAA22385 for ; Tue, 21 Jan 2003 00:35: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 AAA16280 for ; Tue, 21 Jan 2003 00:35:10 -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 AAA06285 for ; Tue, 21 Jan 2003 00:35:09 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 21 Jan 2003 00:35:08 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030121001057.1c9976a9.moore@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 01/21/2003 00:10, "Keith Moore" wrote: >> Because Apple and Microsoft don't give a flying fuck what you think. > > maybe not, but I'll do whatever I can to keep them from using IETF to endorse > their crap. It won't matter. Outside of low-level work, like IPv6, the IETF is largely irrelevant in networking. Oh, they may give an approval to a standard, which can make it easier to argue for in meetings, but face the facts...if you need something to get work done, the IETF's opinion on it, is irrelevant. What I find interesting is how the IEEE can get work done at a far faster clip than the IETF, and they deal with stuff that is far more complex. All you are doing is making the IETF as a whole more irrelevant to people who only care about the network as far as it provides them with services. If the network doesn't work, they don't quote RFCs...they call the vendor and say, "Make it better". If the vendor can't, they get a new vendor. If people like you have their way, the IETF will, in about ten years, have all the relevance of three blind monks arguing over the conjugation of the verb, "To Spam" in ancient greek. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 21 00:39:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11963 for ; Tue, 21 Jan 2003 00:39:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A8AEF9132D; Tue, 21 Jan 2003 00:43:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77EBB9132E; Tue, 21 Jan 2003 00:43: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 7A8E59132D for ; Tue, 21 Jan 2003 00:42:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 632D85DFE3; Tue, 21 Jan 2003 00:42:59 -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 52D655E004 for ; Tue, 21 Jan 2003 00:42:58 -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 h0L5gtjf005900 for ; Tue, 21 Jan 2003 15:42:55 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id h0L5grj98802; Tue, 21 Jan 2003 15:42:53 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Tue, 21 Jan 2003 15:42:53 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: Zeroconf Subject: Re: Turning off link-locals? 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 Tue, 21 Jan 2003, John C. Welch wrote: >What I find interesting is how the IEEE can get work done at a far faster >clip than the IETF, and they deal with stuff that is far more complex. That is because the IEEE work is done by people representing corporations, whose interest is in shipping useful product quickly. But that's pretty off topic :-) Ian From owner-zeroconf@merit.edu Tue Jan 21 00:43:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12038 for ; Tue, 21 Jan 2003 00:43:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 52E8F9132E; Tue, 21 Jan 2003 00:46:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06D5291330; Tue, 21 Jan 2003 00:46: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 A2E7C9132E for ; Tue, 21 Jan 2003 00:46:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 71FCB5DFF2; Tue, 21 Jan 2003 00:46:25 -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 618AD5DE69 for ; Tue, 21 Jan 2003 00:46:24 -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 h0L5kKjf006096 for ; Tue, 21 Jan 2003 15:46:21 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id h0L5kJu98824; Tue, 21 Jan 2003 15:46:19 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Tue, 21 Jan 2003 15:46:19 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: zeroconf@merit.edu Subject: Re: Turning off link-locals? 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: -0.1, 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 Tue, 21 Jan 2003, Keith Moore wrote: >On Tue, 21 Jan 2003 14:46:24 +1000 (EST) Ian Lister wrote: >> On Mon, 20 Jan 2003, Keith Moore wrote: >> >rendezvous is a disaster. >> >> Oh good, then you'll be able to point to specific things that it has >> broken. > >I've already listed several specific problems with LL addressing. You have gone on and on about two problems: 1. Use of IPv4LL addresses on hosts with assigned addresses allegedly `breaks' applications. You listed a few, but I don't see how IPv4LL breaks any of them. You identified address referral as a major source of potential breakage, but automatic address referrals work because they typically use the likes of getsockname() to determine an address, and manual address referrals (e.g. configured lists of hosts to use in distributed systems) only break if somebody manually refers IPv4LL addresses. Rendezvous does not assign IPv4LL addresses when other (DHCP or static) addresses are available, so clearly you are not referring to this alleged problem anyway. 2. A host without an administratively assigned address can still communicate with hosts with such addresses. While most consider this a feature, you have argued that in some contexts the inability to communicate may be used as a socially enforced security measure, and that the IETF should support this use. Rendezvous allows hosts to be configured so as not to communicate with IPv4LL-only hosts on the network - simply remove the 169.254.0.0/16 entry from the routing table. So, which problems with Rendezvous are you referring to? Any relating to IPv4LL at all? >the problems with name lookup are matters for other WGs. Acknowledged. Ian From owner-zeroconf@merit.edu Tue Jan 21 06:31:08 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26130 for ; Tue, 21 Jan 2003 06:31:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 126B091260; Tue, 21 Jan 2003 06:34:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D44DD9128B; Tue, 21 Jan 2003 06:34: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 2C42591260 for ; Tue, 21 Jan 2003 06:32:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 72E405DE69; Tue, 21 Jan 2003 06:32:57 -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 CB8125DE20 for ; Tue, 21 Jan 2003 06:32:53 -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 3FFC85988D; Tue, 21 Jan 2003 11:32:49 +0000 (GMT) Message-ID: <012f01c2c140$d2a67ff0$131010ac@aldebaran> From: "Philip Nye" To: "Ian Lister" , References: Subject: Re: Turning off link-locals? Date: Tue, 21 Jan 2003 11:32:47 -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: "Ian Lister" > > You have gone on and on about two problems: > > 1. Use of IPv4LL addresses on hosts with assigned addresses allegedly > `breaks' applications. You listed a few, but I don't see how IPv4LL > breaks any of them. You identified address referral as a major source > of potential breakage, but automatic address referrals work because > they typically use the likes of getsockname() to determine an address, > and manual address referrals (e.g. configured lists of hosts to use in > distributed systems) only break if somebody manually refers IPv4LL > addresses. Keith has pointed up two genuine protocol level issues and I will try and summarise them again and why they are particular to v4LL: 1. Scoped addresses. Given an interface with two addresses, which one does an application use? In the traditional case, it doesn't matter much but in the case where one address is of limited scope it does. This still doesn't cause much trouble in a straight two way exchange but in a three way exchange (a referral) the only way to solve the problem seems to be for the app to be aware of address scoping (which many such apps are not). Hitherto, scoped addresses are manually configured (either at the host or the network level) and so the limitations are implicitly accepted when configuring that way. Mandating that LL be on by default means that scoped addresses will be present whether the limitations are accepted or not. So far I have seen no rebuttal to this issue except to deny its existence, to insult Keith (who can be pretty forthright himself), or to blame those who write those apps - none of which are appropriate responses. 2. Security Any host using v4LL on two interfaces has trouble knowing which interface to route LL packets to as discussed in section 3 of the draft. As the solutions to this involve defending addresses on all interfaces the interfaces are no longer fully independent. This opens a new vulnerability where access to one link allows attacks on an adjacent one. In both these cases some might argue that the scale of the problem is small and the benefit of v4LL is great so that the disadvantages are acceptable. However, denying the problem is not the same thing and the argument would have to be backed with some hard information anyway. The option to turn v4LL off when a global address is present in a flexible way (via a DHCP option or by Erik N's strawman protocol) goes a long way to answering these issues: It does not prevent communication (on the local link) between hosts with global addresses and those with LL; It ensures that configuration can override the default behaviour of those hosts which are capable of obtaining and using global addresses; It presumes that hosts which can only use LL addresses implicitly accept the limitations. It would even be possible for the draft to place explicit limitations on LL only hosts such as "no apps requiring referrals" or "no multiple interfaces". For a while I thought these discussions were getting somewhere but then the mudslinging prevailed - at least it is familiar! Philip Nye From owner-zeroconf@merit.edu Tue Jan 21 07:03:46 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26520 for ; Tue, 21 Jan 2003 07:03:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 84C0491290; Tue, 21 Jan 2003 07:07:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 481F691291; Tue, 21 Jan 2003 07:07:01 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D82591290 for ; Tue, 21 Jan 2003 07:07:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id D8AF45DE21; Tue, 21 Jan 2003 07:06:59 -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 6E1595DE18 for ; Tue, 21 Jan 2003 07:06: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 HAA27716 for ; Tue, 21 Jan 2003 07:06:58 -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 HAA20670 for ; Tue, 21 Jan 2003 07:06:58 -0500 (EST) Received: from [192.168.1.102] (cpe-66-189-9-93.ma.charter.com [66.189.9.93]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id HAA24879 for ; Tue, 21 Jan 2003 07:06:57 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 21 Jan 2003 07:06:55 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <012f01c2c140$d2a67ff0$131010ac@aldebaran> 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 01/21/2003 06:32, "Philip Nye" wrote: > 1. Scoped addresses. > > Given an interface with two addresses, which one does an application use? In > the traditional case, it doesn't matter much but in the case where one > address is of limited scope it does. This still doesn't cause much trouble > in a straight two way exchange but in a three way exchange (a referral) the > only way to solve the problem seems to be for the app to be aware of address > scoping (which many such apps are not). > > Hitherto, scoped addresses are manually configured (either at the host or > the network level) and so the limitations are implicitly accepted when > configuring that way. Mandating that LL be on by default means that scoped > addresses will be present whether the limitations are accepted or not. > > So far I have seen no rebuttal to this issue except to deny its existence, > to insult Keith (who can be pretty forthright himself), or to blame those > who write those apps - none of which are appropriate responses. Actually, if an application is ignoring OS services, and bypassing APIs because the writer wishes to be clever, I find it wholly appropriate to lay the blame on the developer. Right now, if you have a multiple addresses on a single interface, how does it get handled? There are a number of issues. 1) Does the application even care? If it's a client, 99% of the time, it doesn't. It connects to a server via OS services. Fetch doesn't know which interface it's using. I tell it to connect to ftp.tackyshirt.com, and if either interface can make that connection it does. If either interface has multiple addresses, it *still* doesn't care. In other words, it's going to use the OS services to communicate with an interface. Which one, which address is immaterial, as long as it can make the connection. If it can't, you get a user error, and you go from there. If a client is binding to a specific address at a specific interface, it's a bug, not a feature. 2) The application cares about addresses. It's a server, it's listening at a given address on a given port. Note the lack of interface in the preceding sentence. Why? Because it's immaterial, or it should be. The application has no business binding to a specific interface, and I have yet to see an argument that says it should in this case. If it does, what happens when an interface is added or removed? You have to reconfigure the app. Again, this is a sign of the developer getting 'cute', and should be treated as a bug. If this seems harsh, well, that's how overly clever developers need to be treated. In any event, the OS handles the routing services to ensure that the right packets get to the interface on the right address/port. If it can't, then the OS has a bug, and needs to be fixed, and in the meantime, another OS should be used. 3) The application *does* care about addresses and interfaces. Packet sniffers, config utilities, etc. So now we hit the cases that will be most affected by it. I really don't see this as being an issue. Simple human greed bears this out. If you are a commercial entity, then you'll update to handle this, or go out of business. If you are a non-commercial entity, then if you don't update, someone else will, and no one will use your app. Either way, it's going to get fixed. I'm amazed that no one has thought to actually test this beyond relying on data from Apple's shipping code, especially the people screaming doom. Real data taken over time is more compelling than any theoretical fears. > > 2. Security > > Any host using v4LL on two interfaces has trouble knowing which interface to > route LL packets to as discussed in section 3 of the draft. As the solutions > to this involve defending addresses on all interfaces the interfaces are no > longer fully independent. This opens a new vulnerability where access to one > link allows attacks on an adjacent one. Right. But this is not a major problem, unless you have an insecure network anyway. If you do, LL is not your problem, you have far greater problems. > > > In both these cases some might argue that the scale of the problem is small > and the benefit of v4LL is great so that the disadvantages are acceptable. > However, denying the problem is not the same thing and the argument would > have to be backed with some hard information anyway. Who can tell. I've yet to see hard info from either side. > > The option to turn v4LL off when a global address is present in a flexible > way (via a DHCP option or by Erik N's strawman protocol) goes a long way to > answering these issues: > > It does not prevent communication (on the local link) between hosts with > global addresses and those with LL; It ensures that configuration can > override the default behaviour of those hosts which are capable of obtaining > and using global addresses; It presumes that hosts which can only use LL > addresses implicitly accept the limitations. It would even be possible for > the draft to place explicit limitations on LL only hosts such as "no apps > requiring referrals" or "no multiple interfaces". Well, those limitations will be ignored if a vendor has a customer need. We all know this, or should. Turning LL off is a bad idea unless you *require* two things: 1) Obvious, continuing and annoying user notification that you've just killed a service they assume is working. Stealth DOS configs, (and that's what killing LL is), are not acceptable to the humans. So when the computer is powered up, woken up, or the network link is changed, the the user MUST be notified, with no options to not notify. 2) There HAS to be a timer on this. No killing LL until some random service tells it to come back on. The signal to stay off must be resent at regular intervals. That way, the user is not at home, off the "No LL" network, and now unable to communicate with their home LL devices. Additionally, there MUST be a manual way to re-enable LL as a backup to the timer. Not that turning off LL solves anything other than the fears of app and OS developers who don't want to update code, but at least it's not as onerous. This makes it...acceptably silly. As well, has anyone thought about manual configs here at all, or are we all assuming that the entire world uses DHCP? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 21 07:27:50 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26838 for ; Tue, 21 Jan 2003 07:27:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E2ED491291; Tue, 21 Jan 2003 07:30:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 59ADC912C1; Tue, 21 Jan 2003 07:30: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 3C56391291 for ; Tue, 21 Jan 2003 07:30:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 62BFE5DE3D; Tue, 21 Jan 2003 07:30:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 4AC795DE1E for ; Tue, 21 Jan 2003 07:30:14 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-275.cisco.com [10.82.241.19]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0LCUAuW023930; Tue, 21 Jan 2003 04:30:11 -0800 (PST) Message-Id: <4.3.2.7.2.20030121072300.00b251d0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Jan 2003 07:30:11 -0500 To: "John C. Welch" From: John Schnizlein Subject: Re: Turning off link-locals? Cc: Zeroconf In-Reply-To: References: <012f01c2c140$d2a67ff0$131010ac@aldebaran> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk At 07:06 AM 1/21/2003, John C. Welch wrote: >... >As well, has anyone thought about manual configs here at all, or are we all >assuming that the entire world uses DHCP? Is my impression that the goal of the ZeroConf WG is to minimize manual configuration not universally shared? It seems the pursuit of particular mechanisms such as link-local (IPv4 auto-generated) addresses has taken precedence for some arguments. The practical fact is that DHCP does reduce manual configuration today, and people are working to make it easier to operate while maintaining its ability to provide host configuration in compliance with local policy and the existing address structure of the Internet. It would be a mistake to invent new mechanisms that circumvent local policy because the host (actually vendor of the host operating system) does not like to be bound by local policy. John From owner-zeroconf@merit.edu Tue Jan 21 08:38:36 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29561 for ; Tue, 21 Jan 2003 08:38:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 04F95912C1; Tue, 21 Jan 2003 08:41:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C484F912C2; Tue, 21 Jan 2003 08:41: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 AA858912C1 for ; Tue, 21 Jan 2003 08:41:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 93A8D5E004; Tue, 21 Jan 2003 08:41:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by segue.merit.edu (Postfix) with ESMTP id 614865DE1A for ; Tue, 21 Jan 2003 08:41:37 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 18ayed-0001Da-00; Tue, 21 Jan 2003 05:41:28 -0800 Date: Tue, 21 Jan 2003 08:37:50 -0500 From: Keith Moore To: Alex Karahalios Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121083750.63582bc8.moore@cs.utk.edu> In-Reply-To: <972B6B58-2D01-11D7-9771-00039377AD70@Outersoft.com> References: <20030120193123.74327223.moore@cs.utk.edu> <972B6B58-2D01-11D7-9771-00039377AD70@Outersoft.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > I don't think we should discourage anyone from producing devices which > only speak v4LL. Anyone is free to create devices which speak only > v4LL, and they are also free to create devices which only speak UDP and > don't speak TCP. and anyone is free to create devices which violate the IP, TCP, or UDP specifications too - even though this does harm. NATs are a good example. but I don't think IETF should recommend practices that are harmful, and I do think that IETF can provide a valuable service by recommending against practices that are harmful. and LL is harmful unless it's used sparingly. > You see, no matter how objectionable you find v4LL and > no matter what the IETF says, there will always be vendors out there > that will create their own standards. yes. but this is an IETF working group, so we're talking about what IETF should be doing. > My view on this is more pragmatic. v4LL and the rest of the ZeroConf > protocols make my life as an embedded network processor vendor allot > easier. and if you don't support other means of your devices obtaining an address, they make your devices a lot less functional. it would be really unfortunate if dysfunctional devices became the norm. Keith From owner-zeroconf@merit.edu Tue Jan 21 08:43:35 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29620 for ; Tue, 21 Jan 2003 08:43:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C7745912C2; Tue, 21 Jan 2003 08:46:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92D75912C3; Tue, 21 Jan 2003 08:46: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 EF09A912C2 for ; Tue, 21 Jan 2003 08:46:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 47D7F5E01B; Tue, 21 Jan 2003 08:46:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by segue.merit.edu (Postfix) with ESMTP id 166945DE1A for ; Tue, 21 Jan 2003 08:46:12 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18ayjB-0001bS-00; Tue, 21 Jan 2003 05:46:09 -0800 Date: Tue, 21 Jan 2003 08:42:32 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121084232.723ae339.moore@cs.utk.edu> In-Reply-To: References: <012f01c2c140$d2a67ff0$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Actually, if an application is ignoring OS services, and bypassing APIs > because the writer wishes to be clever, I find it wholly appropriate to lay > the blame on the developer. it's infeasible for an application writer to "bypass APIs". they're merely choosing which APIs to use. or do you really think they're shipping their own kernel mods? as for the rest of your message, all I can say is that John Welch's opinion about what is proper programming and what is appropriate security are not good justifications for screwing the installed base. From owner-zeroconf@merit.edu Tue Jan 21 09:36:39 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01184 for ; Tue, 21 Jan 2003 09:36:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DE200912C3; Tue, 21 Jan 2003 09:39:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A764E912C5; Tue, 21 Jan 2003 09:39: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 918A8912C3 for ; Tue, 21 Jan 2003 09:39:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E92B5E012; Tue, 21 Jan 2003 09:39:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtp.covadmail.net (mx03.covadmail.net [63.65.120.63]) by segue.merit.edu (Postfix) with SMTP id 3398A5E006 for ; Tue, 21 Jan 2003 09:39:55 -0500 (EST) Received: (covad.net 5100 invoked from network); 21 Jan 2003 14:39:54 -0000 Received: from h-66-166-57-19.cmbrmaor.covad.net (HELO STUDY) (66.166.57.19) by sun-qmail17 with SMTP; 21 Jan 2003 14:39:54 -0000 To: John Schnizlein Cc: "John C. Welch" , Zeroconf Subject: Re: Turning off link-locals? References: <012f01c2c140$d2a67ff0$131010ac@aldebaran> <4.3.2.7.2.20030121072300.00b251d0@wells.cisco.com> From: Scott Lawrence Date: 21 Jan 2003 09:41:50 -0500 In-Reply-To: <4.3.2.7.2.20030121072300.00b251d0@wells.cisco.com> Message-ID: Lines: 50 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-zeroconf@merit.edu Precedence: bulk John Schnizlein writes: > The practical fact is that DHCP does reduce manual configuration > today, and people are working to make it easier to operate while > maintaining its ability to provide host configuration in compliance > with local policy and the existing address structure of the > Internet. My mother-in-law will _never_ learn to run a DHCP service, no matter how long you work on it. Let's not loose sight of the fact that this is true of _most_people_; just because we think it's easy doesn't make it easy for them. The goal of enabling zero-configuration networks is a good one, _even_though_ there are some things they won't be able to do as well as configured ones. That includes possibly not being able to communicate with global Internet services as well. > It would be a mistake to invent new mechanisms that > circumvent local policy because the host (actually vendor of the > host operating system) does not like to be bound by local policy. It's not about circumventing policy - it's about providing a mechanism for those cases in which there _is_no_policy_ because the ordinary people who own the network don't know an IP address from a PO Box. The notion of 'disabling' or 'preventing' LL by sending some contra-indication on the network, whether DHCP or something else, is silly - no sensible network administrator would trust that to work. If nothing else, there are already lots of systems deployed that do some variation on LL that won't be inhibited by it. If an administrator really doesn't want any LL packets on the network, they are going to have to sniff for them or set filters to impede them, or be otherwise inventive - just as they must do now if they want to prevent Appletalk or Netbios or whatever protocol they dislike most. Putting a rule about this in our spec won't change that. The simple fact is that vendors are going to provide products for ordinary people who don't understand addressing and don't want to, because there are a _lot_ more of them than there are of us. We can accept that, and use the IETF to help to ensure that the way that they do it is interoperable at least within the local scope, and its limitations are well understood; or we can just sit here and compose email about how bad it is and they'll do it less well without us (hint - this is what has been happening for the last few years). I don't think that we should be even trying for a perfect world - getting there is too slow, and the goal keeps moving. Find solutions that work - make sure they don't mess up things that are already there - improve them as you go along; I don't think LL violates these principles because the cases that have been cited so far that it 'breaks' are cases that only work now on networks that already have global addressing - not the target for LL at all. From owner-zeroconf@merit.edu Tue Jan 21 09:47:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01468 for ; Tue, 21 Jan 2003 09:47:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B1797912C5; Tue, 21 Jan 2003 09:50:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A94D912C6; Tue, 21 Jan 2003 09:50: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 35E1F912C5 for ; Tue, 21 Jan 2003 09:50:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0F27C5E006; Tue, 21 Jan 2003 09:50:56 -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 7C73B5E01A for ; Tue, 21 Jan 2003 09:50:55 -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 6E8175992D; Tue, 21 Jan 2003 14:50:57 +0000 (GMT) Message-ID: <001101c2c15c$7ff21a00$131010ac@aldebaran> From: "Philip Nye" To: "John C. Welch" , "Zeroconf" References: Subject: Re: Turning off link-locals? Date: Tue, 21 Jan 2003 14:50:53 -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: "John C. Welch" > On 01/21/2003 06:32, "Philip Nye" wrote: > > ... There are a number of issues. > > 1) Does the application even care? If it's a client, 99% of the time, it > doesn't. It connects to a server via OS services... > > 2) The application cares about addresses. It's a server, it's listening at > a given address on a given port... These demonstrate the reasons why this "doesn't cause much trouble in a straight two way exchange" which is what I said. The issue in a three way exchange is that the OS cannot know the scoping and routing of a third party - it simply has a host address. That address may be OK for the first and second parties but not so for a third party. Such applications exist and work. > 3) The application *does* care about addresses and interfaces. Packet > sniffers, config utilities, etc. So now we hit the cases that will be most > affected by it. I really don't see this as being an issue. Simple human > greed bears this out. If you are a commercial entity, then you'll update to > handle this, or go out of business. If you are a non-commercial entity, then > if you don't update, someone else will, and no one will use your app. Either > way, it's going to get fixed. So the solution you are advocating is to update those applications which currently work but will be broken by v4LL. This is possible, but the issue goes beyond simply updating applications IF you want them to work with v4LL because with v4LL turned on all the time it will intrude even on those who don't care about it and would rather use manual configuration and not re-write their apps (assuming they could). Secondly, this presupposes that such an update is possible. I am not at all sure that that is the case with third party referrals such as happen in many distributed processing schemes - at least not without a means to discover the scoping of any arbitrary address and to discover alternative addresses where necessary. The simple guarantee that v4LL can be turned off in the presence of a configured address means that there is at least a choice as to which should work. Not allowing v4LL to be turned off denies that choice. > > The option to turn v4LL off when a global address is present in a flexible > > way (via a DHCP option or by Erik N's strawman protocol) goes a long way to > > answering these issues: > > > > It does not prevent communication (on the local link) between hosts with > > global addresses and those with LL; It ensures that configuration can > > override the default behaviour of those hosts which are capable of obtaining > > and using global addresses; It presumes that hosts which can only use LL > > addresses implicitly accept the limitations. It would even be possible for > > the draft to place explicit limitations on LL only hosts such as "no apps > > requiring referrals" or "no multiple interfaces". > > Well, those limitations will be ignored if a vendor has a customer need... Or we could try and overcome the limitations. > ... Turning LL off is a bad idea unless you *require* > two things: > > 1) Obvious, continuing and annoying user notification that you've just > killed a service they assume is working. Stealth DOS configs, (and that's > what killing LL is), are not acceptable to the humans. So when the computer > is powered up, woken up, or the network link is changed, the the user MUST > be notified, with no options to not notify. Sorry to be dense but I don't understand this. When you say "killed a service" do you mean by simply changing an IP address? or do you mean something else? > 2) There HAS to be a timer on this. No killing LL until some random service > tells it to come back on. If the signal to turn v4LL off is implicit in being assigned another address then it would last as long as that other address. If that assignment is DHCP then there is a timer (lease expiry) and a manual option (manually attempt to renew the lease). If that assignment is static then you are into user level configuration and the world is your oyster. Either of the two suggestions (DHCP option or Erik's "strawman") add the ability to turn LL on _despite_ there being another address and they would both be subject to a timer. > Not that turning off LL solves anything other than the fears of app and OS > developers who don't want to update code,... Or of users who have no ability to update code and also have little control over what is happening in the OS but who have working applications now. It would be disingenuous to suggest that such people shouldn't update their OS - they frequently have no option. Philip Nye From owner-zeroconf@merit.edu Tue Jan 21 10:01:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01726 for ; Tue, 21 Jan 2003 10:01:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5682C912C6; Tue, 21 Jan 2003 10:04:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19B7F912C7; Tue, 21 Jan 2003 10:04: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 CF62F912C6 for ; Tue, 21 Jan 2003 10:04:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id AFF6D5DE1A; Tue, 21 Jan 2003 10:04:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by segue.merit.edu (Postfix) with ESMTP id 811F05DDB8 for ; Tue, 21 Jan 2003 10:04:51 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18azxE-0000Hm-00; Tue, 21 Jan 2003 07:04:44 -0800 Date: Tue, 21 Jan 2003 10:00:56 -0500 From: Keith Moore To: Scott Lawrence Cc: moore@cs.utk.edu, jschnizl@cisco.com, jwelch@MIT.EDU, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121100056.299789ac.moore@cs.utk.edu> In-Reply-To: References: <012f01c2c140$d2a67ff0$131010ac@aldebaran> <4.3.2.7.2.20030121072300.00b251d0@wells.cisco.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 21 Jan 2003 09:41:50 -0500 Scott Lawrence wrote: > John Schnizlein writes: > > > The practical fact is that DHCP does reduce manual configuration > > today, and people are working to make it easier to operate while > > maintaining its ability to provide host configuration in compliance > > with local policy and the existing address structure of the > > Internet. > > My mother-in-law will _never_ learn to run a DHCP service, no matter > how long you work on it. That's an odd statement. There are a number of home network routers and NAT boxes out there that provide DHCP by default, and it never needs to be configured. Hosts that try DHCP by default just work, they never need to be configured. The only thing the user needs to avoid is having multiple routers on the same network, due to current limitations of DHCP. But even this could be fixed in time. > Let's not loose sight of the fact that this > is true of _most_people_; just because we think it's easy doesn't make > it easy for them. The goal of enabling zero-configuration networks is > a good one, _even_though_ there are some things they won't be able to > do as well as configured ones. That includes possibly not being able > to communicate with global Internet services as well. The goal is a good one. But if the resulting service is so dysfunctional that it impairs the ability of much of the Internet to support applications, then the technology which is supposed to implement that goal is not a good one. Just because we acknowledge that the goal is good, and just because LL has been hashed out in the context of a working group named "zeroconf" does not mean that LL is a constructive step toward usable zero configuration networks. > > It would be a mistake to invent new mechanisms that > > circumvent local policy because the host (actually vendor of the > > host operating system) does not like to be bound by local policy. > > It's not about circumventing policy - it's about providing a mechanism > for those cases in which there _is_no_policy_ because the ordinary > people who own the network don't know an IP address from a PO Box. The same device can either be hooked to a network where there is no policy, or to a network where there is policy. The question is, how does the device tell the difference and do the appropriate thing in each case? > The notion of 'disabling' or 'preventing' LL by sending some > contra-indication on the network, whether DHCP or something else, is > silly - no sensible network administrator would trust that to work. It's no more silly than having DHCP assign impaired addresses, or having DHCP refuse to assign addresses, and lots of networks place some degree of "trust" in that. We all acknowledge that this has limited security value, but some networks still find it useful. > If nothing else, there are already lots of systems deployed that do > some variation on LL that won't be inhibited by it. Those are not in our purview. This WG is discussing what the standard version of LL will require. > If an administrator really doesn't want any LL packets on the network, they > are going to have to sniff for them or set filters to impede them, or > be otherwise inventive - just as they must do now if they want to > prevent Appletalk or Netbios or whatever protocol they dislike most. > Putting a rule about this in our spec won't change that. It's about minimizing cost and complexity. If the vast majority of platforms out there will honor an indication from the network to not use LL, then we won't need bridges and hubs to filter out LL traffic. If the platforms don't do that, then more sites will need filtering bridges and hubs, and this will cost more. Similarly, if sites don't have a way to keep LL from breaking their applications, then the applications will have to be modified to be configurable to either ignore LL addresses or not, and this will cost money, and it will increase the burden on users. OTOH if this WG does its job responsibly then the impact can be minimized. > The simple fact is that vendors are going to provide products for > ordinary people who don't understand addressing and don't want to, > because there are a _lot_ more of them than there are of us. We can > accept that, and use the IETF to help to ensure that the way that they > do it is interoperable at least within the local scope, Having things interoperate only "within the local scope" does not meet the requirements of RFC 2026. Furthremore the introduction of scoped addresses into IPv4 changes the behavior of existing interfaces and thus will break programs that expect to work in the global scope. > I don't > think that we should be even trying for a perfect world - getting > there is too slow, and the goal keeps moving. Find solutions that > work - make sure they don't mess up things that are already there - > improve them as you go along; I don't think LL violates these > principles because the cases that have been cited so far that it > 'breaks' are cases that only work now on networks that already have > global addressing - not the target for LL at all. Your last statement is only true if LL only affects isolated networks. If this were the case I wouldn't be objecting to LL. But LL as currently specified affects all networks. And there are some people here who believe the "target" for LL is all networks because they want an easier way to configure plug-and-play devices than DHCP. Keith From owner-zeroconf@merit.edu Tue Jan 21 10:06:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01803 for ; Tue, 21 Jan 2003 10:06:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8F184912C7; Tue, 21 Jan 2003 10:09:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 586BF912C8; Tue, 21 Jan 2003 10:09: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 46954912C7 for ; Tue, 21 Jan 2003 10:09:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 27B4E5DDBF; Tue, 21 Jan 2003 10:09:17 -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 B15735DDB8 for ; Tue, 21 Jan 2003 10:09:16 -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 KAA00922 for ; Tue, 21 Jan 2003 10:09:16 -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 KAA12959 for ; Tue, 21 Jan 2003 10:09:15 -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 KAA16969 for ; Tue, 21 Jan 2003 10:09:15 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 21 Jan 2003 10:09:11 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <4.3.2.7.2.20030121072300.00b251d0@wells.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 01/21/2003 07:30, "John Schnizlein" wrote: >> As well, has anyone thought about manual configs here at all, or are we all >> assuming that the entire world uses DHCP? > > Is my impression that the goal of the ZeroConf WG is to minimize manual > configuration not universally shared? It seems the pursuit of particular > mechanisms such as link-local (IPv4 auto-generated) addresses has taken > precedence for some arguments. > > The practical fact is that DHCP does reduce manual configuration today, and > people are working to make it easier to operate while maintaining its ability > to provide host configuration in compliance with local policy and the existing > address structure of the Internet. It would be a mistake to invent new > mechanisms that circumvent local policy because the host (actually vendor of > the host operating system) does not like to be bound by local policy. Manual configs are still a reality, and will be forever. Reasons are unimportant for this WG. So we need to deal with it in an intelligent fashion, and it raises some different issues. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 21 10:16:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02062 for ; Tue, 21 Jan 2003 10:16:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8A9A5912CB; Tue, 21 Jan 2003 10:19:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49A4B912C8; Tue, 21 Jan 2003 10:19: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 2EAC7912C9 for ; Tue, 21 Jan 2003 10:17:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 15E015DDBF; Tue, 21 Jan 2003 10:17:58 -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 0E1CE5DDB8 for ; Tue, 21 Jan 2003 10:17:57 -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 228E15993A; Tue, 21 Jan 2003 15:17:59 +0000 (GMT) Message-ID: <003401c2c160$4681fb60$131010ac@aldebaran> From: "Philip Nye" To: "Scott Lawrence" Cc: "Zeroconf" References: <012f01c2c140$d2a67ff0$131010ac@aldebaran><4.3.2.7.2.20030121072300.00b251d0@wells.cisco.com> Subject: Re: Turning off link-locals? Date: Tue, 21 Jan 2003 15:17:56 -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: "Scott Lawrence" > > > The practical fact is that DHCP does reduce manual configuration > > today, and people are working to make it easier to operate while > > maintaining its ability to provide host configuration in compliance > > with local policy and the existing address structure of the > > Internet. DHCP raises the configuration from the host level to the network level. This is often very useful but not always the right thing hence John's comments. However, a locally configured address implies that the user rather than the network administrator is performing manual configuration and the implication is that they could also re-enable v4LL if required. > My mother-in-law will _never_ learn to run a DHCP service, no matter > how long you work on it... The scenario is this: if your mother-in-law plugs her machine into a managed network, it is assigned an address by DHCP and so far as she is concerned "it just works". If it is an unmanaged network v4LL steps in and again "it just works". If she plugs into a managed network which denies her access, this is presumably the intent of the network manager. In the unmanaged network this will not happen (unless there is a malicious host denying access which could happen in either case). > The notion of 'disabling' or 'preventing' LL by sending some > contra-indication on the network, whether DHCP or something else, is > silly - no sensible network administrator would trust that to work. > If nothing else, there are already lots of systems deployed that do > some variation on LL that won't be inhibited by it. So far as I can tell, recent versions of Mac OS are the only ones which do not quietly disable v4LL if they get a DHCP address (or a static one). > ... or we can just sit here and compose > email about how bad it is and they'll do it less well without us (hint > - this is what has been happening for the last few years). So what is wrong with the scenario above? Why should your mother-in-laws machine insist on grabbing a LL address even though it has another perfectly good one and the network has asked it not to use LL? Philip Nye From owner-zeroconf@merit.edu Tue Jan 21 10:16:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02079 for ; Tue, 21 Jan 2003 10:16:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 59E99912C9; Tue, 21 Jan 2003 10:19:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 11273912CA; Tue, 21 Jan 2003 10:19: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 53617912C8 for ; Tue, 21 Jan 2003 10:17:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 329C45DDBF; Tue, 21 Jan 2003 10:17:44 -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 BC11D5DDB8 for ; Tue, 21 Jan 2003 10:17:43 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA05881 for ; Tue, 21 Jan 2003 10:17:43 -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 KAA14847 for ; Tue, 21 Jan 2003 10:17:43 -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 KAA21399 for ; Tue, 21 Jan 2003 10:17:42 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 21 Jan 2003 10:17:40 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <001101c2c15c$7ff21a00$131010ac@aldebaran> 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 01/21/2003 09:50, "Philip Nye" wrote: >> 1) Obvious, continuing and annoying user notification that you've just >> killed a service they assume is working. Stealth DOS configs, (and that's >> what killing LL is), are not acceptable to the humans. So when the > computer >> is powered up, woken up, or the network link is changed, the the user MUST >> be notified, with no options to not notify. > > Sorry to be dense but I don't understand this. When you say "killed a > service" do you mean by simply changing an IP address? or do you mean > something else? > >> 2) There HAS to be a timer on this. No killing LL until some random > >service tells it to come back on. > > If the signal to turn v4LL off is implicit in being assigned another address > then it would last as long as that other address. If that assignment is DHCP > then there is a timer (lease expiry) and a manual option (manually attempt > to renew the lease). If that assignment is static then you are into user > level configuration and the world is your oyster. Static configs are why LL needs to be able to be on all the time. DHCP leases can be quite long, and are therefore an unacceptable timer. > > Either of the two suggestions (DHCP option or Erik's "strawman") add the > ability to turn LL on _despite_ there being another address and they would > both be subject to a timer. But who runs the timer. It needs to be, "Unless I get a signal to keep LL off, then it comes back on", and something on the scale of a DHCP lease is not fast enough. > >> Not that turning off LL solves anything other than the fears of app and OS >> developers who don't want to update code,... > > Or of users who have no ability to update code and also have little control > over what is happening in the OS but who have working applications now. It > would be disingenuous to suggest that such people shouldn't update their > OS - they frequently have no option. Then the people in charge of those updates need to be on top of changes. We can't do anything about that, and shouldn't try. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 21 10:23:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02279 for ; Tue, 21 Jan 2003 10:23:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9EB08912C8; Tue, 21 Jan 2003 10:26:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65E5C912CA; Tue, 21 Jan 2003 10:26: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 58322912C8 for ; Tue, 21 Jan 2003 10:26:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F94D5E005; Tue, 21 Jan 2003 10:26:40 -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 C8A905DFE8 for ; Tue, 21 Jan 2003 10:26:39 -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 KAA08052 for ; Tue, 21 Jan 2003 10:26:38 -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 KAA13300 for ; Tue, 21 Jan 2003 10:10:57 -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 KAA17775 for ; Tue, 21 Jan 2003 10:10:56 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 21 Jan 2003 10:10:55 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030121084232.723ae339.moore@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 01/21/2003 08:42, "Keith Moore" wrote: >> Actually, if an application is ignoring OS services, and bypassing APIs >> because the writer wishes to be clever, I find it wholly appropriate to lay >> the blame on the developer. > > it's infeasible for an application writer to "bypass APIs". they're merely > choosing which APIs to use. or do you really think they're shipping their own > kernel mods? > Does the term "undocumented calls" sound familiar? Or the concept of 'hacking'? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 21 10:23:54 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02309 for ; Tue, 21 Jan 2003 10:23:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF836912CA; Tue, 21 Jan 2003 10:27:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6C7F912CC; Tue, 21 Jan 2003 10:27: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 64010912CA for ; Tue, 21 Jan 2003 10:26:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 536725DF7D; Tue, 21 Jan 2003 10:26:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by segue.merit.edu (Postfix) with ESMTP id 30C7C5DDB8 for ; Tue, 21 Jan 2003 10:26:59 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18b0Ig-0001pR-00; Tue, 21 Jan 2003 07:26:54 -0800 Date: Tue, 21 Jan 2003 10:23:16 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121102316.3855382d.moore@cs.utk.edu> In-Reply-To: References: <001101c2c15c$7ff21a00$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Static configs are why LL needs to be able to be on all the time. DHCP > leases can be quite long, and are therefore an unacceptable timer. why? if the local network policy is that LL is not permitted, then why shouldn't the time interval on this bit be quite long? > > Either of the two suggestions (DHCP option or Erik's "strawman") add the > > ability to turn LL on _despite_ there being another address and they would > > both be subject to a timer. > > But who runs the timer. It needs to be, "Unless I get a signal to keep LL > off, then it comes back on", again, why? what is the justification for giving LL more preference than the policies of the local network administrator? > >> Not that turning off LL solves anything other than the fears of app and > >OS> developers who don't want to update code,... > > > > Or of users who have no ability to update code and also have little > > control over what is happening in the OS but who have working applications > > now. It would be disingenuous to suggest that such people shouldn't update > > their OS - they frequently have no option. > > Then the people in charge of those updates need to be on top of changes. We > can't do anything about that, and shouldn't try. yes we can. we can stop trying to break existing facilities in the name of some misguided idea of progress. From owner-zeroconf@merit.edu Tue Jan 21 10:31:09 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02542 for ; Tue, 21 Jan 2003 10:31:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E4304912CC; Tue, 21 Jan 2003 10:34:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB856912CD; Tue, 21 Jan 2003 10:34: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 D4DAC912CC for ; Tue, 21 Jan 2003 10:33:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id B32EC5DFE8; Tue, 21 Jan 2003 10:33:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by segue.merit.edu (Postfix) with ESMTP id 92D015DDBC for ; Tue, 21 Jan 2003 10:33:01 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18b0OX-0006IU-00; Tue, 21 Jan 2003 07:32:57 -0800 Date: Tue, 21 Jan 2003 10:29:19 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, lawrence@world.std.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121102919.645ffeaa.moore@cs.utk.edu> In-Reply-To: <003401c2c160$4681fb60$131010ac@aldebaran> References: <012f01c2c140$d2a67ff0$131010ac@aldebaran> <4.3.2.7.2.20030121072300.00b251d0@wells.cisco.com> <003401c2c160$4681fb60$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Why should your mother-in-laws > machine insist on grabbing a LL address even though it has another perfectly > good one and the network has asked it not to use LL? More generally, why shouldn't your mother-in-law's applications, machines, and networks coexist peacefully rather than interact destructively? Isn't it more desirable to have an address configuration facility which is flexible enough to accomodate diverse needs (managed networks vs. unmanaged), than to have one which impairs the operation of the network and/or applications and forces them to work around the limitations of the address configuration facility (say by filtering LL addresses in hardware or by requiring proxies for applications)? From owner-zeroconf@merit.edu Tue Jan 21 10:31:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02557 for ; Tue, 21 Jan 2003 10:31:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A3109912CE; Tue, 21 Jan 2003 10:34:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64527912CD; Tue, 21 Jan 2003 10: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 169FE912CE for ; Tue, 21 Jan 2003 10:34:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id EA8945DDBC; Tue, 21 Jan 2003 10:34:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by segue.merit.edu (Postfix) with ESMTP id C9B825DDB8 for ; Tue, 21 Jan 2003 10:34:22 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18b0Ps-0007Os-00; Tue, 21 Jan 2003 07:34:21 -0800 Date: Tue, 21 Jan 2003 10:30:43 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121103043.069ecff0.moore@cs.utk.edu> In-Reply-To: References: <20030121084232.723ae339.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > it's infeasible for an application writer to "bypass APIs". they're merely > > choosing which APIs to use. or do you really think they're shipping their own > > kernel mods? > > > > Does the term "undocumented calls" sound familiar? Or the concept of > 'hacking'? yes, I'm familar with both of these. neither of them are apropos here. Keith From owner-zeroconf@merit.edu Tue Jan 21 10:55:48 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03280 for ; Tue, 21 Jan 2003 10:55:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8804791330; Tue, 21 Jan 2003 10:59:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5939A91332; Tue, 21 Jan 2003 10:59: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 3B74091330 for ; Tue, 21 Jan 2003 10:59:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 195E05E01A; Tue, 21 Jan 2003 10:59:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtp.covadmail.net (mx03.covadmail.net [63.65.120.63]) by segue.merit.edu (Postfix) with SMTP id D336D5E00F for ; Tue, 21 Jan 2003 10:59:00 -0500 (EST) Received: (covad.net 17628 invoked from network); 21 Jan 2003 15:58:59 -0000 Received: from h-66-166-57-19.cmbrmaor.covad.net (HELO STUDY) (66.166.57.19) by sun-qmail14 with SMTP; 21 Jan 2003 15:58:59 -0000 To: "Philip Nye" Cc: "Zeroconf" Subject: Re: Turning off link-locals? References: <012f01c2c140$d2a67ff0$131010ac@aldebaran> <4.3.2.7.2.20030121072300.00b251d0@wells.cisco.com> <003401c2c160$4681fb60$131010ac@aldebaran> From: Scott Lawrence Date: 21 Jan 2003 11:00:54 -0500 In-Reply-To: <003401c2c160$4681fb60$131010ac@aldebaran> Message-ID: Lines: 46 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-zeroconf@merit.edu Precedence: bulk "Philip Nye" writes: > > From: "Scott Lawrence" > > ... or we can just sit here and compose > > email about how bad it is and they'll do it less well without us (hint > > - this is what has been happening for the last few years). > > So what is wrong with the scenario above? Why should your mother-in-laws > machine insist on grabbing a LL address even though it has another perfectly > good one and the network has asked it not to use LL? I didn't mean to imply that it should. I do think that we'd serve the needs of users better by making progress, and, on this issue at least, this working group manifestly is not doing that (some would obviously say that's a good thing). I'd been on this list since the early BOFs, and am just returning from a hiatus of several months. I just spent a few days perusing the archive and reading all the traffic for the last couple of months. As far as I can tell, almost nothing has changed in about a year, except that vendors have shipped another generation or two of systems that have thier own versions of some LL scheme. Indeed, the suggested rule from early drafts was that systems should attempt a DHCP address and not use LL if they get one - a fine suggestion. My main points are: - Such system configuration constraints as "try DHCP first and don't use LL if it is present" can in practice be no better than suggestions. We don't write protocol specs that have rules for what your nsswitch.conf file MUST be. We do have rules about documenting the implications of poor configuration choices, and I think that is where the responsibility of the IETF ends. - Get done with it and approve _some_ specification, or admit that you can't and drop the effort. In that case, vendors will likely choose to standardize somewhere else, or just muddle along as they've been doing. If you think either of those is likely to produce a better result than the world has already got, or if you think that you'd rather preserve your own integrity and sleep better at night by not endorsing any IETF v4LL scheme, ok. Don't kid yourself that it will prevent such schemes from being deployed - that's already history. I suspect that if this WG had gotten a PS done with the "try DHCP" suggestion in it, that Apple would have built OSX that way; maybe not, but now we'll never know. From owner-zeroconf@merit.edu Tue Jan 21 11:25:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04107 for ; Tue, 21 Jan 2003 11:25:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C5C5B91335; Tue, 21 Jan 2003 11:28:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9703D91336; Tue, 21 Jan 2003 11:28: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 A5D8891335 for ; Tue, 21 Jan 2003 11:28:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 948C45E066; Tue, 21 Jan 2003 11:28:32 -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 637365E05A for ; Tue, 21 Jan 2003 11:28:32 -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 03CBA59923; Tue, 21 Jan 2003 16:03:36 +0000 (GMT) Message-ID: <00b501c2c166$a5c0b4d0$131010ac@aldebaran> From: "Philip Nye" To: "John C. Welch" , "Zeroconf" References: Subject: Re: Turning off link-locals? Date: Tue, 21 Jan 2003 16:03:32 -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: "John C. Welch" > Static configs are why LL needs to be able to be on all the time. DHCP > leases can be quite long, and are therefore an unacceptable timer. So is your concern that the DHCP server has turned off LL at work, you now go home and find your machine no longer works at home because LL is off? Couldn't the OS attempt a renewal on the lease at this point? It needs to take action anyway since it is on a different network. Philip From owner-zeroconf@merit.edu Tue Jan 21 11:32:59 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04340 for ; Tue, 21 Jan 2003 11:32:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6BBBD91336; Tue, 21 Jan 2003 11:36:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 32CB491337; Tue, 21 Jan 2003 11:36: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 1A95491336 for ; Tue, 21 Jan 2003 11:36:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id F1E4E5E079; Tue, 21 Jan 2003 11:36:11 -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 86F535E078 for ; Tue, 21 Jan 2003 11:36:11 -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 LAA18184 for ; Tue, 21 Jan 2003 11:36: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 LAA07029 for ; Tue, 21 Jan 2003 11:36:10 -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 LAA05575 for ; Tue, 21 Jan 2003 11:36:10 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 21 Jan 2003 11:36:07 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <00b501c2c166$a5c0b4d0$131010ac@aldebaran> 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 01/21/2003 11:03, "Philip Nye" wrote: >> Static configs are why LL needs to be able to be on all the time. DHCP >> leases can be quite long, and are therefore an unacceptable timer. > > So is your concern that the DHCP server has turned off LL at work, you now > go home and find your machine no longer works at home because LL is off? > > Couldn't the OS attempt a renewal on the lease at this point? It needs to > take action anyway since it is on a different network. Or I go to a different subnet that isn't using DHCP, and I just need to print. Or I have a manual config, but I'm at a different subnet and I just need to print. Or maybe I just want to print, and I don't want to have to be a network geek to print to a networked printer. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 21 11:35:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04448 for ; Tue, 21 Jan 2003 11:35:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9862691337; Tue, 21 Jan 2003 11:38:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D69D91338; Tue, 21 Jan 2003 11:38: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 3169791337 for ; Tue, 21 Jan 2003 11:38:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 132D65E078; Tue, 21 Jan 2003 11:38: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 9C8455DDBF for ; Tue, 21 Jan 2003 11:38: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 LAA13876 for ; Tue, 21 Jan 2003 11:38: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 LAA07614 for ; Tue, 21 Jan 2003 11:38:26 -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 LAA06865 for ; Tue, 21 Jan 2003 11:38:25 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 21 Jan 2003 11:38:23 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <003401c2c160$4681fb60$131010ac@aldebaran> 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 01/21/2003 10:17, "Philip Nye" wrote: > The scenario is this: if your mother-in-law plugs her machine into a managed > network, it is assigned an address by DHCP and so far as she is concerned > "it just works". If it is an unmanaged network v4LL steps in and again "it > just works". Only if she's using DHCP. Stop making this assumption, it's a bad one. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 21 11:39:12 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04608 for ; Tue, 21 Jan 2003 11:39:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 39BF091338; Tue, 21 Jan 2003 11:42:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02ED191339; Tue, 21 Jan 2003 11:42: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 E767C91338 for ; Tue, 21 Jan 2003 11:42:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id CE0D95DDBF; Tue, 21 Jan 2003 11:42:24 -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 65B435DD99 for ; Tue, 21 Jan 2003 11:42:24 -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 LAA21778 for ; Tue, 21 Jan 2003 11:42:23 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA08549 for ; Tue, 21 Jan 2003 11:42:23 -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 LAA09077 for ; Tue, 21 Jan 2003 11:42:22 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 21 Jan 2003 11:42:19 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030121102316.3855382d.moore@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 01/21/2003 10:23, "Keith Moore" wrote: > >> Static configs are why LL needs to be able to be on all the time. DHCP >> leases can be quite long, and are therefore an unacceptable timer. > > why? if the local network policy is that LL is not permitted, then why > shouldn't the time interval on this bit be quite long? Because then how do you reset it after you get off that DHCP network. Or the DHCP server goes down. Or any one of a hundred conditions that no one can plan for. >>> >> But who runs the timer. It needs to be, "Unless I get a signal to keep LL >> off, then it comes back on", > > again, why? what is the justification for giving LL more preference than the > policies of the local network administrator? Because they have these laptop things...that actually move about. As well, I haven't seen any safeguards that ensure the off signal is legitimate, and not some schmuck having fun. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 21 11:43:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04678 for ; Tue, 21 Jan 2003 11:43:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 458559133A; Tue, 21 Jan 2003 11:46:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EB5FD9133B; Tue, 21 Jan 2003 11:46: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 9BE1B9133A for ; Tue, 21 Jan 2003 11:46:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6FD1F5E0B9; Tue, 21 Jan 2003 11:46:15 -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 03B145DDBF for ; Tue, 21 Jan 2003 11:46:15 -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 LAA17969 for ; Tue, 21 Jan 2003 11:46:13 -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 LAA08897 for ; Tue, 21 Jan 2003 11:43:44 -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 LAA09909 for ; Tue, 21 Jan 2003 11:43:43 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 21 Jan 2003 11:43:41 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030121103043.069ecff0.moore@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 01/21/2003 10:30, "Keith Moore" wrote: >>> it's infeasible for an application writer to "bypass APIs". they're merely >>> choosing which APIs to use. or do you really think they're shipping their >>> own >>> kernel mods? >>> >> >> Does the term "undocumented calls" sound familiar? Or the concept of >> 'hacking'? > > yes, I'm familar with both of these. neither of them are apropos here. It happens all the time. Adobe got bit by this. It will happen, and I no longer care if someone doing something 'clever' gets broken by LL, or anything else. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 21 11:46:39 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04778 for ; Tue, 21 Jan 2003 11:46:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 145459133D; Tue, 21 Jan 2003 11:49:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE8F19133B; Tue, 21 Jan 2003 11:49:45 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AF29F9133F for ; Tue, 21 Jan 2003 11:48:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8D4125E078; Tue, 21 Jan 2003 11:48:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 694355DDBF for ; Tue, 21 Jan 2003 11:48:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 25430141F8; Tue, 21 Jan 2003 11:48:05 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 15223-10; Tue, 21 Jan 2003 11:48:04 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 88C00141F7; Tue, 21 Jan 2003 11:48:04 -0500 (EST) Date: Tue, 21 Jan 2003 11:48:04 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121114804.43353481.moore@cs.utk.edu> In-Reply-To: References: <00b501c2c166$a5c0b4d0$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: f76104680663fbc85f8e671f0b8f4768b2764308 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > So is your concern that the DHCP server has turned off LL at work, > > you now go home and find your machine no longer works at home > > because LL is off? > > > > Couldn't the OS attempt a renewal on the lease at this point? It > > needs to take action anyway since it is on a different network. > > Or I go to a different subnet that isn't using DHCP, and I just need > to print. Or I have a manual config, but I'm at a different subnet and > I just need to print. Or maybe I just want to print, and I don't want > to have to be a network geek to print to a networked printer. in general, whenever a host moves relative to the network, there's potentially a need to reconfigure that host's interfaces. LL doesn't, and cannot, change that. Now if you want to have a way that a host can detect that it has moved, that's a potentially useful idea, but it needs to be independent of LL. Keith From owner-zeroconf@merit.edu Tue Jan 21 11:55:03 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05070 for ; Tue, 21 Jan 2003 11:55:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9C2659133B; Tue, 21 Jan 2003 11:58:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 695AE9133C; Tue, 21 Jan 2003 11: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 312119133B for ; Tue, 21 Jan 2003 11:58:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 11AD85E00F; Tue, 21 Jan 2003 11:58:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id ED3E25DDBF for ; Tue, 21 Jan 2003 11:58:12 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id BB2D0141F9; Tue, 21 Jan 2003 11:58:12 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 16306-10; Tue, 21 Jan 2003 11:58:12 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 259D7141F8; Tue, 21 Jan 2003 11:58:12 -0500 (EST) Date: Tue, 21 Jan 2003 11:58:11 -0500 From: Keith Moore To: Scott Lawrence Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121115811.70762d56.moore@cs.utk.edu> In-Reply-To: References: <012f01c2c140$d2a67ff0$131010ac@aldebaran> <4.3.2.7.2.20030121072300.00b251d0@wells.cisco.com> <003401c2c160$4681fb60$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 17f61cb8176ea39409c5f0bf07f9e692f5b87dba Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Indeed, the suggested rule from early drafts was that systems should > attempt a DHCP address and not use LL if they get one - a fine > suggestion. My main points are: > > - Such system configuration constraints as "try DHCP first and don't > use LL if it is present" can in practice be no better than > suggestions. We don't write protocol specs that have rules for what > your nsswitch.conf file MUST be. well, it wouldn't necessarily be out of scope for us to do so. if nsswitch.conf had a setting to allow TCP retransmit timeouts to be changed, changing them would still be a violation of the protocol specs. at the same time, I haven't seen anyone insisting that local host configuration shouldn't take precedence for whether to use LL; the disagreements are about what the behavior should be in the absence of local host configuration. > - Get done with it and approve _some_ specification, or admit that you > can't and drop the effort. approving a bad specification is worse than not approving one. maybe vendors will ship bad code anyway - they often do. but at least IETF is not endorsing it. the alternative - for IETF to endorse bad code - makes IETF's endorsement mean nothing and doesn't make the deployment situation any better. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Tue Jan 21 11:58:14 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05154 for ; Tue, 21 Jan 2003 11:58:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF89991343; Tue, 21 Jan 2003 12:01:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A4BB91341; Tue, 21 Jan 2003 12:01: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 F2D2191340 for ; Tue, 21 Jan 2003 12:01:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id C351C5E00F; Tue, 21 Jan 2003 12:00:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id 305655E005 for ; Tue, 21 Jan 2003 12:00:51 -0500 (EST) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id MAA22255 for ; Tue, 21 Jan 2003 12:00:50 -0500 (EST) From: "Subrata Goswami" To: "'Zeroconf'" Subject: RE: Turning off link-locals? Date: Tue, 21 Jan 2003 08:55:18 -0800 Message-ID: <003901c2c16d$e138d770$02a2fea9@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit 1. Is it possible to make LL independent of DHCP ? Yes. As LL only uses addresses 169.254/16, DHCP can keep itself out of handing out those addresses. 2. Is there any responsibility from the infrastructure in LL ? Yes, it should let all connected (at the link level) node know that it is possible to do LL. One LL node should decide to broadcast/multicast (say 169.254.255.255) a response message to a inquery by a LL capable node..... 3. Should the client decide between using DHCP and LL ? Yes. If it can do either then let it have the choice, other wise the choice is obvious. 4. Is it possible to have two IP subnet running over the same link network ? Yes. 5. Can one link have multiple IP addresses ? Yes. It is being used in IPSec VPN's. > -----Original Message----- > From: owner-zeroconf@merit.edu > [mailto:owner-zeroconf@merit.edu] On Behalf Of John C. Welch > Sent: Tuesday, January 21, 2003 8:38 AM > To: Zeroconf > Subject: Re: Turning off link-locals? > > > On 01/21/2003 10:17, "Philip Nye" wrote: > > > The scenario is this: if your mother-in-law plugs her > machine into a > > managed network, it is assigned an address by DHCP and so > far as she > > is concerned "it just works". If it is an unmanaged network > v4LL steps > > in and again "it just works". > > Only if she's using DHCP. Stop making this assumption, it's a bad one. > > john > > -- > John C. Welch > Consultant III > Administrative Computing > (617) 253 - 1368 work > (508) 579 - 7380 cell > bynkii2 AIM > > From owner-zeroconf@merit.edu Tue Jan 21 12:01:25 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05225 for ; Tue, 21 Jan 2003 12:01:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E04EC9133E; Tue, 21 Jan 2003 12:04:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A56859133F; Tue, 21 Jan 2003 12:04: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 403E99133E for ; Tue, 21 Jan 2003 12:03:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 276C85DDBF; Tue, 21 Jan 2003 12:03:09 -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 E41245DD99 for ; Tue, 21 Jan 2003 12:03:08 -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 2CDBA5988C; Tue, 21 Jan 2003 17:03:11 +0000 (GMT) Message-ID: <00e401c2c16e$f8e33b80$131010ac@aldebaran> From: "Philip Nye" To: "John C. Welch" , "Zeroconf" References: Subject: Re: Turning off link-locals? Date: Tue, 21 Jan 2003 17:03:07 -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: "John C. Welch" > > why? if the local network policy is that LL is not permitted, then why > > shouldn't the time interval on this bit be quite long? > > Because then how do you reset it after you get off that DHCP network. Or the > DHCP server goes down. Or any one of a hundred conditions that no one can > plan for. ... > Because they have these laptop things...that actually move about... If you have changed network, then reconfiguration is needed - this applies with LL too. Re-configuration in this context does not necessarily mean manual configuration - most common network interfaces are capable of detecting disconnection and reconnection which can trigger reconfiguration. In the case of laptops a simple user interface "rediscover" button is also an option. > As well, I > haven't seen any safeguards that ensure the off signal is legitimate, and > not some schmuck having fun. A schmuck can "have fun" with or without this mechanism as has been well established. Philip Nye From owner-zeroconf@merit.edu Tue Jan 21 12:09:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05387 for ; Tue, 21 Jan 2003 12:09:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 49A3591342; Tue, 21 Jan 2003 12:10:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CBDFD91344; Tue, 21 Jan 2003 12:10: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 1128291342 for ; Tue, 21 Jan 2003 12:10:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id E7F245DDE8; Tue, 21 Jan 2003 12:10:24 -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 7DDD65DD99 for ; Tue, 21 Jan 2003 12:10:24 -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 MAA10171 for ; Tue, 21 Jan 2003 12:10:24 -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 MAA12313 for ; Tue, 21 Jan 2003 12:10:23 -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 MAA25710 for ; Tue, 21 Jan 2003 12:10:23 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 21 Jan 2003 12:10:20 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <00e401c2c16e$f8e33b80$131010ac@aldebaran> 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 01/21/2003 12:03, "Philip Nye" wrote: > > Re-configuration in this context does not necessarily mean manual > configuration - most common network interfaces are capable of detecting > disconnection and reconnection which can trigger reconfiguration. In the > case of laptops a simple user interface "rediscover" button is also an > option. I haven't seen this in either of the two majority desktop OS's. It may be in some version of Linux somewhere. > >> As well, I >> haven't seen any safeguards that ensure the off signal is legitimate, and >> not some schmuck having fun. > > A schmuck can "have fun" with or without this mechanism as has been well > established. So we make it *easier* because this is a politically correct DOS? No automatic configuration without notification or authentication. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 21 12:10:26 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05479 for ; Tue, 21 Jan 2003 12:10:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2B88A91344; Tue, 21 Jan 2003 12:13:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F0D7791345; Tue, 21 Jan 2003 12:13: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 E96EE91344 for ; Tue, 21 Jan 2003 12:13:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id CD4DF5DDB8; Tue, 21 Jan 2003 12:13:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 5C6CC5DD99 for ; Tue, 21 Jan 2003 12:13:34 -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 MAA12103 for ; Tue, 21 Jan 2003 12:13:33 -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 MAA11523 for ; Tue, 21 Jan 2003 12:07:10 -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 MAA23841 for ; Tue, 21 Jan 2003 12:07:09 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 21 Jan 2003 12:07:06 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030121114804.43353481.moore@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 01/21/2003 11:48, "Keith Moore" wrote: >> Or I go to a different subnet that isn't using DHCP, and I just need >> to print. Or I have a manual config, but I'm at a different subnet and >> I just need to print. Or maybe I just want to print, and I don't want >> to have to be a network geek to print to a networked printer. > > in general, whenever a host moves relative to the network, there's potentially > a need to reconfigure that host's interfaces. LL doesn't, and cannot, change > that. I don't want it to. I just want to know that when someone needs to use LL, they *know* if they can or not. Stealth DHCP signals are bogus. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 21 12:17:33 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05668 for ; Tue, 21 Jan 2003 12:17:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5721A91346; Tue, 21 Jan 2003 12:20:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2024991347; Tue, 21 Jan 2003 12: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 072F091346 for ; Tue, 21 Jan 2003 12:20:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA7D05DDEB; Tue, 21 Jan 2003 12:20:41 -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 AAB585DD99 for ; Tue, 21 Jan 2003 12:20:41 -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 3E53D5993A; Tue, 21 Jan 2003 17:20:44 +0000 (GMT) Message-ID: <011a01c2c171$6c3f2ce0$131010ac@aldebaran> From: "Philip Nye" To: "John C. Welch" , "Zeroconf" References: Subject: Re: Turning off link-locals? Date: Tue, 21 Jan 2003 17:20:40 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > No automatic configuration without notification or authentication. LL is automatic configuration too! In the case where a user is using manual configuration, then we are not even remotely zero-config and have to assume she (or someone advising her) has some skill and - assuming the option is there - should know whether to turn LL on or not. Philip From owner-zeroconf@merit.edu Tue Jan 21 12:23:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05840 for ; Tue, 21 Jan 2003 12:23:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B09F291347; Tue, 21 Jan 2003 12:26:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7FB9A91348; Tue, 21 Jan 2003 12:26: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 868D991347 for ; Tue, 21 Jan 2003 12:26:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6223F5DDB8; Tue, 21 Jan 2003 12:26:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 31C8B5DD99 for ; Tue, 21 Jan 2003 12:26:34 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id CCF2C5993E; Tue, 21 Jan 2003 17:26:36 +0000 (GMT) Message-ID: <011d01c2c172$3e64a150$131010ac@aldebaran> From: "Philip Nye" To: "Scott Lawrence" Cc: "Zeroconf" References: <012f01c2c140$d2a67ff0$131010ac@aldebaran><4.3.2.7.2.20030121072300.00b251d0@wells.cisco.com> <003401c2c160$4681fb60$131010ac@aldebaran> Subject: Re: Turning off link-locals? Date: Tue, 21 Jan 2003 17:26:33 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Scott Lawrence" > "Philip Nye" writes: > > > > From: "Scott Lawrence" > > > ... or we can just sit here and compose > > > email about how bad it is and they'll do it less well without us (hint > > > - this is what has been happening for the last few years). > > > > So what is wrong with the scenario above? Why should your mother-in-laws > > machine insist on grabbing a LL address even though it has another perfectly > > good one and the network has asked it not to use LL? > > I didn't mean to imply that it should. > > I do think that we'd serve the needs of users better by making > progress, and, on this issue at least, this working group manifestly > is not doing that (some would obviously say that's a good thing). There has been some progress in that some credible methods have been suggested for a compromise between the "LL is always on" position and the "LL always goes off in the presence of another address" positions. I rather think recent posts have lost sight of this. Philip From owner-zeroconf@merit.edu Tue Jan 21 12:25:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05909 for ; Tue, 21 Jan 2003 12:25:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A9B7B91348; Tue, 21 Jan 2003 12:28:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 72B3691349; Tue, 21 Jan 2003 12:28: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 7785B91348 for ; Tue, 21 Jan 2003 12:28:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6590F5DDEA; Tue, 21 Jan 2003 12:28:18 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from first.cove-mtn.com (unknown [208.187.205.91]) by segue.merit.edu (Postfix) with ESMTP id 235475DDB8 for ; Tue, 21 Jan 2003 12:28:18 -0500 (EST) Received: from cove-mtn.com (dante.cove-mtn.com [172.31.2.255]) by first.cove-mtn.com (8.12.5/8.12.4) with ESMTP id h0LHS67g027190; Tue, 21 Jan 2003 10:28:07 -0700 (MST) Message-ID: <3E2D8318.3070505@cove-mtn.com> Date: Tue, 21 Jan 2003 10:27:52 -0700 From: Brad Davis User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en,zh-TW MIME-Version: 1.0 To: Ian Lister Cc: Zeroconf Subject: Re: Turning off link-locals? 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 Ian Lister wrote: > On Tue, 21 Jan 2003, John C. Welch wrote: > >>What I find interesting is how the IEEE can get work done at a far faster >>clip than the IETF, and they deal with stuff that is far more complex. > > That is because the IEEE work is done by people representing corporations, > whose interest is in shipping useful product quickly. But that's pretty > off topic :-) The IEEE is not fast (see how fast the 802.11b standard worked through committee and look at the political battles between the two groups) and the ISO is even slower (why don't we have faster fax machines yet?). The last effort I spent time on was PPP and PPP-ML. None of that even comes close to matching the prototype protocols (and all the companies involved, including the company that created the prototype, changed their code a number of times). Brad Davis From owner-zeroconf@merit.edu Tue Jan 21 12:31:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06132 for ; Tue, 21 Jan 2003 12:31:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2CB5991340; Tue, 21 Jan 2003 12:34:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9DCA91349; Tue, 21 Jan 2003 12:34: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 3EF5591340 for ; Tue, 21 Jan 2003 12:33:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 200E65DDEA; Tue, 21 Jan 2003 12:33:41 -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 E42A75DD99 for ; Tue, 21 Jan 2003 12:33:40 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 6980459939; Tue, 21 Jan 2003 17:33:40 +0000 (GMT) Message-ID: <012a01c2c173$3adc2160$131010ac@aldebaran> From: "Philip Nye" To: "John C. Welch" , "Zeroconf" References: Subject: Re: Turning off link-locals? Date: Tue, 21 Jan 2003 17:33:36 -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: "John C. Welch" > > Re-configuration in this context does not necessarily mean manual > > configuration - most common network interfaces are capable of detecting > > disconnection and reconnection which can trigger reconfiguration. In the > > case of laptops a simple user interface "rediscover" button is also an > > option. > > I haven't seen this in either of the two majority desktop OS's. It may be in > some version of Linux somewhere. Interesting. Is there an obvious flaw with attempting to detect whether the network has changed when a re-connection is detected? I would have thought that sending a DHCP discovery and possibly a renew would make sense - as would sending an ARP probe for LL. For statically configured hosts then pinging (or ARPing) the default route would be equivalent. Philip From owner-zeroconf@merit.edu Tue Jan 21 12:43:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06479 for ; Tue, 21 Jan 2003 12:43:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CE05391349; Tue, 21 Jan 2003 12:46:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 970139134A; Tue, 21 Jan 2003 12:46: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 898F691349 for ; Tue, 21 Jan 2003 12:46:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6ABD35DE13; Tue, 21 Jan 2003 12:46:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from first.cove-mtn.com (unknown [208.187.205.91]) by segue.merit.edu (Postfix) with ESMTP id 6BA0E5DD99 for ; Tue, 21 Jan 2003 12:46:44 -0500 (EST) Received: from cove-mtn.com (dante.cove-mtn.com [172.31.2.255]) by first.cove-mtn.com (8.12.5/8.12.4) with ESMTP id h0LHkv7g016433; Tue, 21 Jan 2003 10:46:57 -0700 (MST) Message-ID: <3E2D8783.80201@cove-mtn.com> Date: Tue, 21 Jan 2003 10:46:43 -0700 From: Brad Davis User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en,zh-TW MIME-Version: 1.0 To: Scott Lawrence , Zeroconf Subject: Re: Turning off link-locals? References: <012f01c2c140$d2a67ff0$131010ac@aldebaran> <4.3.2.7.2.20030121072300.00b251d0@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 Scott Lawrence wrote: > My mother-in-law will _never_ learn to run a DHCP service, no matter > how long you work on it. Let's not loose sight of the fact that this > is true of _most_people_; just because we think it's easy doesn't make > it easy for them. The goal of enabling zero-configuration networks is > a good one, _even_though_ there are some things they won't be able to > do as well as configured ones. That includes possibly not being able > to communicate with global Internet services as well. You think that millions of households world-wide today know how to run DHCP servers? They still run them. The server comes pre-configured in those DSL, Cable, or Ethernet to Ethernet routers that have been shipping and sold by the boatloads over the past few years. DHCP works for these people, and while it may be imperfect, it works well enough that broadband service providers that support home networking require DHCP (on by default) and NAT (address being in short supply). The home networking requirements are very different from John Welch's MIT requirements. One major requirement is that all devices that are plugged into a home network must be able to talk to every other device on the home network so the service provider doen't have to take support calls that can cost $50 to $100 per call. If this requirement isn't met, the service provider will stop supporting home networking or will charge so much on monthly bills that networking will die (and all you little embedded guys will go out of business). Their other option will be charge for support and then people will throw away those $50 devices rather than spend $100 to find out that they can't get them running. Brad Davis From owner-zeroconf@merit.edu Tue Jan 21 13:16:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07552 for ; Tue, 21 Jan 2003 13:16:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B340F91216; Tue, 21 Jan 2003 13:19:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 852FA912C4; Tue, 21 Jan 2003 13:19: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 0A28D91216 for ; Tue, 21 Jan 2003 13:17:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id E3B9C5DDBA; Tue, 21 Jan 2003 13:17:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 9DC9B5DD90 for ; Tue, 21 Jan 2003 13:17:48 -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 h0LIHmw03092 for ; Tue, 21 Jan 2003 10:17:48 -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, 21 Jan 2003 10:17:47 -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 h0LIHlf08846 for ; Tue, 21 Jan 2003 10:17:47 -0800 (PST) Date: Tue, 21 Jan 2003 10:17:35 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030121001057.1c9976a9.moore@cs.utk.edu> Message-Id: <9DADCDA8-2D6C-11D7-A610-000393760260@apple.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, January 20, 2003, at 09:10 PM, Keith Moore wrote: > >> Because Apple and Microsoft don't give a flying fuck what you think. > > maybe not, but I'll do whatever I can to keep them from using IETF to > endorse their crap. That's a wonderful idea. That way IPv4LL can go the way of NAT. IPv4LL does solve a problem, it is useful. It may break a small number of applications. Perhaps with work we can document that or reduce the number of applications broken. We can also define how IPv4LL should work so it will behave consistently across all platforms and products. NAT is evil and nasty, but it's really useful for tens of thousands of people. The IETF didn't take any part in standardizing how a NAT should work. The result? No two NATs work the same way. Anyone working on a NAT traversal solution has to contend with the slight variations in the way that each NAT works. Is this the way things should be? The IETF will only bless a standard if everyone comes to a complete agreement and there isn't a single person with a loud mouth complaining? -josh From owner-zeroconf@merit.edu Tue Jan 21 13:36:58 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08000 for ; Tue, 21 Jan 2003 13:36:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D0A3F912C4; Tue, 21 Jan 2003 13:40:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9BF729134A; Tue, 21 Jan 2003 13:40: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 75D7F912C4 for ; Tue, 21 Jan 2003 13:40:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 65A615E079; Tue, 21 Jan 2003 13:40:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 46C4A5E05A for ; Tue, 21 Jan 2003 13:40:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 0F5DC14202; Tue, 21 Jan 2003 13:40:13 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 30773-07; Tue, 21 Jan 2003 13:40:09 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 53577141FB; Tue, 21 Jan 2003 13:40:09 -0500 (EST) Date: Tue, 21 Jan 2003 13:40:09 -0500 From: Keith Moore To: Joshua Graessley Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121134009.5460a65b.moore@cs.utk.edu> In-Reply-To: <9DADCDA8-2D6C-11D7-A610-000393760260@apple.com> References: <20030121001057.1c9976a9.moore@cs.utk.edu> <9DADCDA8-2D6C-11D7-A610-000393760260@apple.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: dd7d70108d0a52536249a6e024d2d2021d084d6f Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 21 Jan 2003 10:17:35 -0800 Joshua Graessley wrote: > > On Monday, January 20, 2003, at 09:10 PM, Keith Moore wrote: > > > > >> Because Apple and Microsoft don't give a flying fuck what you > >think. > > > > maybe not, but I'll do whatever I can to keep them from using IETF > > to endorse their crap. > > That's a wonderful idea. That way IPv4LL can go the way of > NAT. sorry, I let my buttons get pushed. > IPv4LL does solve a problem, it is useful. It may break a small number > of applications. Perhaps with work we can document that or reduce the > number of applications broken. We can also define how IPv4LL should > work so it will behave consistently across all platforms and products. that sounds good. > NAT is evil and nasty, but it's really useful for tens of thousands of > people. The IETF didn't take any part in standardizing how a NAT > should work. The result? No two NATs work the same way. Anyone working > on a NAT traversal solution has to contend with the slight variations > in the way that each NAT works. Is this the way things should be? The > IETF will only bless a standard if everyone comes to a complete > agreement and there isn't a single person with a loud mouth > complaining? IETF does have a problem in that it has a hard time saying "here's how to do this bad thing, if you're going to insist on doing it, in a way that doesn't cause as many problems as you might otherwise cause". Though for the case of NAT I don't see how IETF could have helped much. The reasons we get so many variant behaviors out of NATs is that NATs inherently cause so many problems that fundamentally cannot be fixed. That doesn't stop NAT vendors from trying to fix them, often in ways that make the problems worse (like having NATs try to recognize addresees that are embedded in packets without specific knowledge of the protocols). Fortunately, LL doesn't have to be as bad as that. There's a clear use case for LL in isolated/ad hoc networks, and there are good reasons to provide managed networks with a way of disabling LL. If we provide for both of these cases then we will have most of the real benefit of LL with the least potential for harm. With NATs there was not much that could have been done to avoid the harm. Keith -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Tue Jan 21 13:42:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08126 for ; Tue, 21 Jan 2003 13:42:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 898859134A; Tue, 21 Jan 2003 13:45:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 008B79134C; Tue, 21 Jan 2003 13: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 C520F9134A for ; Tue, 21 Jan 2003 13:45:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 473445DDB8; Tue, 21 Jan 2003 13:45:08 -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 BEA945DD90 for ; Tue, 21 Jan 2003 13:45:07 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0LIetP02005; Tue, 21 Jan 2003 12:40:55 -0600 (CST) Date: Tue, 21 Jan 2003 10:45:19 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Zeroconf To: "John C. Welch" From: Ted Lemon In-Reply-To: Message-Id: <7D296F7F-2D70-11D7-AFDA-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > The application cares about addresses. It's a server, it's listening at > a given address on a given port. Note the lack of interface in the > preceding > sentence. Why? Because it's immaterial, or it should be. The > application has > no business binding to a specific interface, and I have yet to see an > argument that says it should in this case. If it does, what happens > when an > interface is added or removed? You have to reconfigure the app. Again, > this > is a sign of the developer getting 'cute', and should be treated as a > bug. In effect, here you are saying that DHCP servers are not useful network applications. In practice, DHCP servers need to do precisely what you've suggested, and they can't be implemented without this capability. One of the big problems getting DHCP working is that there are no standard APIs that provide this functionality, so you have to do something different on every UNIX-like operating system. However, as I've said previously, the DHCP server implementors are aware of this problem, and provide knobs for the user to tweak to avoid getting into trouble. Furthermore, as others have pointed out, you don't need an IPv4LL address to communicate with IPv4LL hosts on the local wire, so this scenario shouldn't even come up. From owner-zeroconf@merit.edu Tue Jan 21 13:46:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08374 for ; Tue, 21 Jan 2003 13:46:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 140689134F; Tue, 21 Jan 2003 13:49:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C73D09134C; Tue, 21 Jan 2003 13:49: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 1690F9134C for ; Tue, 21 Jan 2003 13:48:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id E0D935DF04; Tue, 21 Jan 2003 13:48:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 917335DE2D for ; Tue, 21 Jan 2003 13:48:17 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0LIi5P02105; Tue, 21 Jan 2003 12:44:05 -0600 (CST) Date: Tue, 21 Jan 2003 10:48:29 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Zeroconf" , "John C. Welch" To: "Philip Nye" From: Ted Lemon In-Reply-To: <001101c2c15c$7ff21a00$131010ac@aldebaran> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Secondly, this presupposes that such an update is possible. I am not > at all > sure that that is the case with third party referrals such as happen > in many > distributed processing schemes - at least not without a means to > discover > the scoping of any arbitrary address and to discover alternative > addresses > where necessary. Link-local addresses are well-defined numbers. This is a non-problem. From owner-zeroconf@merit.edu Tue Jan 21 13:53:18 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08652 for ; Tue, 21 Jan 2003 13:53:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 44EBE9134C; Tue, 21 Jan 2003 13:56:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 13F639134E; Tue, 21 Jan 2003 13:56: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 0EAD29134C for ; Tue, 21 Jan 2003 13:56:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id E22155E05A; Tue, 21 Jan 2003 13:56:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 52DDD5E09F for ; Tue, 21 Jan 2003 13:56:32 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0LIqJP02214; Tue, 21 Jan 2003 12:52:19 -0600 (CST) Date: Tue, 21 Jan 2003 10:56:43 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030121102919.645ffeaa.moore@cs.utk.edu> Message-Id: <152D8234-2D72-11D7-AFDA-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > More generally, why shouldn't your mother-in-law's applications, > machines, > and networks coexist peacefully rather than interact destructively? This is just more of the wife-beater rhetoric. You have never demonstrated any such destructive interaction, so I suggest that you stop using this terminology and stick to the facts. From owner-zeroconf@merit.edu Tue Jan 21 13:58:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08782 for ; Tue, 21 Jan 2003 13:58:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2590891351; Tue, 21 Jan 2003 14:01:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 849AD91350; Tue, 21 Jan 2003 14:01: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 648429134E for ; Tue, 21 Jan 2003 14:00:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4932E5E07F; Tue, 21 Jan 2003 14:00:45 -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 849F25E079 for ; Tue, 21 Jan 2003 14:00:44 -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 h0LJ0iw18627 for ; Tue, 21 Jan 2003 11:00:44 -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, 21 Jan 2003 11:00:43 -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 h0LJ0hQ07048 for ; Tue, 21 Jan 2003 11:00:43 -0800 (PST) Date: Tue, 21 Jan 2003 11:00:32 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Joshua Graessley To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <003401c2c160$4681fb60$131010ac@aldebaran> Message-Id: <9D8E5D65-2D72-11D7-A610-000393760260@apple.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, January 21, 2003, at 07:17 AM, Philip Nye wrote: > So far as I can tell, recent versions of Mac OS are the only ones > which do > not quietly disable v4LL if they get a DHCP address (or a static one). Versions of Mac OS that support link-local will only acquire link local addresses when configured to use DHCP and the DHCP server does not respond. Various versions of the Mac OS will continue to send DHCP requests. If a DHCP server does appear, the Mac will use the address from the DHCP server but it will also continue to use the IPv4LL address. The IPv4LL address is maintained to avoid unnecessarily killing already established connections. The Mac OS will watch for link changed events to determine if DHCP should be tried again or the IPv4LL address assignment should occur again. >> ... or we can just sit here and compose >> email about how bad it is and they'll do it less well without us (hint >> - this is what has been happening for the last few years). > > So what is wrong with the scenario above? Why should your > mother-in-laws > machine insist on grabbing a LL address even though it has another > perfectly > good one and the network has asked it not to use LL? If DHCP is present, I don't see any reason to acquire a LL address. On the other hand, if my machine or some other device for whatever reason can't get an address from DHCP, or if it doesn't implement DHCP, then I'd like it get an IPv4LL address. This assures me that I have some way of communicating with the device. I don't want my machine to silently refuse to acquire an address because some guy in the dorm playing a prank is sending out some magic packet to disable IPv4LL. I don't think we need to design a special protocol either. If someone is so disgusted with IPv4LL, they can write or use a utility that conflicts with the ARP probes that IPv4LL addresses send before self assigning an address. That will effectively eliminate IPv4LL on the local link. I think some people are hugely exaggerating the need for a way to disable IPv4LL. To date, I'm not aware of any device shipped that will acquire an IPv4LL address when a DHCP server is present or the device is manually configured (or configured through bootp or some other mechanism). The only thing Keith needs to do to keep IPv4LL off his networks is keep his DHCP server running. If, in the future, someone does develop a device that only uses IPv4LL addresses, then people like Keith can choose not to buy such devices or tell people not to put those devices in the network in much the same way one might tell people not to use an AppleTalk or IPv6 printer. There is no protocol to tell devices not to acquire IPv6LL addresses, AppleTalk address, or IPX addresses (yeah yeah, everything but IPv6 is outside the scope of the IETF). -josh From owner-zeroconf@merit.edu Tue Jan 21 13:58:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08806 for ; Tue, 21 Jan 2003 13:58:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC58991350; Tue, 21 Jan 2003 14:01:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9ED5D91352; Tue, 21 Jan 2003 14:01: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 A69A491350 for ; Tue, 21 Jan 2003 14:01:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id F038E5E0C2; Tue, 21 Jan 2003 14:01:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id B9AFF5E0B3 for ; Tue, 21 Jan 2003 14:01:37 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 85A9E141FD; Tue, 21 Jan 2003 14:01:37 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 01698-10; Tue, 21 Jan 2003 14:01:36 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id E463D141FB; Tue, 21 Jan 2003 14:01:36 -0500 (EST) Date: Tue, 21 Jan 2003 14:01:36 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu, jwelch@MIT.EDU Subject: Re: Turning off link-locals? Message-Id: <20030121140136.7d6232bf.moore@cs.utk.edu> In-Reply-To: References: <001101c2c15c$7ff21a00$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 0fe3511a69e071421aae63eff37fe25be187a574 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 21 Jan 2003 10:48:29 -0800 Ted Lemon wrote: > > Secondly, this presupposes that such an update is possible. I am not > > at all sure that that is the case with third party referrals such as > > happen in many distributed processing schemes - at least not without > > means to discover the scoping of any arbitrary address and to > > discover alternative addresses where necessary. > > Link-local addresses are well-defined numbers. This is a > non-problem. there are two problems: 1. compatibility with existing software that is not LL aware 2. trying to make the app work both in cases where LL addresses need to be used and in cases where they need to be avoided. for instance, you may want to make your conferencing app workable on ad hoc networks, but it also needs to be able to work across the public Internet. if you tell the app to ignore LLs you prevent its use on ad hoc networks; if you allow it to use LLs you prevent it from being used across the public Internet; if you allow the app to be configured as to which mode it is in you have lost whatever benefit you would have gained from the supposed "zero configuration" provided by LL - and your app *still* cannot work with a mixture of LL-only hosts and hosts elsewhere on the Internet. this is one reason why LL-only hosts are a bad idea, though this particular argument against LL-only hosts only applies to general-purpose programmable hosts. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Tue Jan 21 14:20:44 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09385 for ; Tue, 21 Jan 2003 14:20:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 216C7912D1; Tue, 21 Jan 2003 14:24:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E6EC191353; Tue, 21 Jan 2003 14:24: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 E565B912D1 for ; Tue, 21 Jan 2003 14:23:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id C7D7C5DD90; Tue, 21 Jan 2003 14:23:59 -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 53D815DDB8 for ; Tue, 21 Jan 2003 14:23:59 -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 h0LJNwI12702 for ; Tue, 21 Jan 2003 11:23:58 -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, 21 Jan 2003 11:23:58 -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 h0LJNvQ27905 for ; Tue, 21 Jan 2003 11:23:58 -0800 (PST) Date: Tue, 21 Jan 2003 11:23:47 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <012f01c2c140$d2a67ff0$131010ac@aldebaran> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tuesday, January 21, 2003, at 03:32 AM, Philip Nye wrote: > Keith has pointed up two genuine protocol level issues and I will try > and > summarise them again and why they are particular to v4LL: > > 1. Scoped addresses. > > Given an interface with two addresses, which one does an application > use? In > the traditional case, it doesn't matter much but in the case where one > address is of limited scope it does. This still doesn't cause much > trouble > in a straight two way exchange but in a three way exchange (a > referral) the > only way to solve the problem seems to be for the app to be aware of > address > scoping (which many such apps are not). > > Hitherto, scoped addresses are manually configured (either at the host > or > the network level) and so the limitations are implicitly accepted when > configuring that way. Mandating that LL be on by default means that > scoped > addresses will be present whether the limitations are accepted or not. > > So far I have seen no rebuttal to this issue except to deny its > existence, > to insult Keith (who can be pretty forthright himself), or to blame > those > who write those apps - none of which are appropriate responses. This problem is not as significant as it may seem. If IPv4LLs are only acquired on an interface when no global address can be (no DHCP, manual config, or other config method), the device will be unable to communicate with anything off of the local link through that interface. Most applications don't actively participate in picking a local address to communicate using. In fact, on a lot of multi-homed systems, if applications, did this would most likely lead to a number of problems. If an application tries to pick a source address to use for communication, and it picks an address that is not on the same subnet as the default gateway and it sends to a device which leads to routing the packet through the default gateway and the local machine does not implement the strong end system model, there is a good chance the communication will fail, especially if a router along the way supports ingress filtering. We offer suggestions to our developers. For a number of reasons, mostly related to multi-homed machines, we recommend that our developers avoid knowing anything about the local IP addresses unless they absolutely must. For an outgoing connection, the network stack figures out the best local IP address to use. For incoming connections, a server can bind to the all zeros address (any addr) and accept from any interface. A server could also bind to every local address. The real problem IPv4LLs cause is referrals. In the case of most referral services, a connection is opened to the server. FTP and AIM can be used as examples. If the program is written to get a list of addresses assigned to the local device and use those in the referral, it usually has to pick one of those addresses. FTP only allows you to specify one address, I imagine AIM tracks only one address as well. Picking the right address is already a challenge. As an app developer, I'd take the simple solution and just call some function like getsockname on the connected socket to find the local address I should use in my referral. In the case of a device with IPv4LL, the initial connection to any server off of the local link would fail, so we are unlikely to send an IPv4LL address to the remote side. In the case of a multi-homed device with an IPv4LL address assigned to one interface and a global address assigned to another interface, getsockname is going to return the global address if the connection is to a global address. Referrals where an intermediary party registers the existence of a device may lead to problems, but problems that could not be otherwise solved. If we have three devices, A, B, and C. A and B are both on the same link. A has only an IPv4LL address. B has only a global address. C has a global address and is on a different link. Without IPv4LL, A would be unable to communicate with B. With IPv4LL, A and B can communicate. If B refers C to A by A's IPv4LL address, C will be unable to communicate with A. This is irrelevant because C would never be able to communicate with A since they are not both on the same local link. IPv4LL address are simple to detect. In time, applications which are found to not work with IPv4LL addresses can be modified to ignore them or handle them as appropriate. FTP has problems with NAT and firewalls (though it will work with IPv4LL, if the client is written properly). FTP has since been modified to work better with NAT and firewalls through the addition of passive connections. Finding all of the applications that break may take time. I'm not convinced that common applications will break, especially since we haven't had any report of broken apps and we've been shipping for years now. -josh From owner-zeroconf@merit.edu Tue Jan 21 14:35:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09849 for ; Tue, 21 Jan 2003 14:35:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CD66991353; Tue, 21 Jan 2003 14:38:27 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 964A491354; Tue, 21 Jan 2003 14:38: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 88EE891353 for ; Tue, 21 Jan 2003 14:38:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7088E5DF2D; Tue, 21 Jan 2003 14:38:26 -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 E65725DF04 for ; Tue, 21 Jan 2003 14:38:25 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0LJYCP02795; Tue, 21 Jan 2003 13:34:12 -0600 (CST) Date: Tue, 21 Jan 2003 11:38:35 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: philip@engarts.com, zeroconf@merit.edu, jwelch@MIT.EDU To: Keith Moore From: Ted Lemon In-Reply-To: <20030121140136.7d6232bf.moore@cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > if you tell the app to ignore LLs you prevent its use on ad hoc > networks; > > if you allow it to use LLs you prevent it from being used across the > public Internet; > > if you allow the app to be configured as to which mode it is in you > have lost whatever benefit you would In the event that you need to do this, you use your non-IPv4ll address in all cases where you have one, because it can be used to communicate both to IPv4ll hosts and non-IPv4ll hosts. If you have no non-IPv4ll address, you use your IPv4ll address, and you can only communicate on your local network, unless you have some kind of NAT setup that works with IPv4ll, in which case you couldn't have forwarded your IP address through the NAT if you were using a NATted IP address anyway. Manually configuring the app is the wrong answer - having it programmatically differentiate between IPv4ll and non-IPv4LL addresses is the right answer. From owner-zeroconf@merit.edu Tue Jan 21 14:38:57 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09975 for ; Tue, 21 Jan 2003 14:38:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3294B91354; Tue, 21 Jan 2003 14:42:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E98E591355; Tue, 21 Jan 2003 14:42: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 B9B0091354 for ; Tue, 21 Jan 2003 14:42:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id A0E065E096; Tue, 21 Jan 2003 14:42:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 8897E5DF2D for ; Tue, 21 Jan 2003 14:42:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 59293141FE; Tue, 21 Jan 2003 14:42:11 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 07305-09; Tue, 21 Jan 2003 14:42:10 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id BA1C4141FD; Tue, 21 Jan 2003 14:42:10 -0500 (EST) Date: Tue, 21 Jan 2003 14:42:10 -0500 From: Keith Moore To: Joshua Graessley Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121144210.7e019317.moore@cs.utk.edu> In-Reply-To: <9D8E5D65-2D72-11D7-A610-000393760260@apple.com> References: <003401c2c160$4681fb60$131010ac@aldebaran> <9D8E5D65-2D72-11D7-A610-000393760260@apple.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 2d91abd94e31c0a43b61c698465bfff1c8f6cd12 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I don't want my machine to > silently refuse to acquire an address because some guy in the dorm > playing a prank is sending out some magic packet to disable IPv4LL. well, for that matter, I don't want machines to be open to attacks just because the machine happens to support v4LL or because an attacker is sending out signals to enable IPv4LL. > I don't think we need to design a special protocol either. If someone > is so disgusted with IPv4LL, they can write or use a utility that > conflicts with the ARP probes that IPv4LL addresses send before self > assigning an address. That will effectively eliminate IPv4LL on > the local link. I examimed this and concluded that this imposed an unreasonable penalty on network bandwidth. > I think some people are hugely exaggerating the need for a way to > disable IPv4LL. I think some people are hugely exaggerating the value of having LL on managed networks. > To date, I'm not aware of any device shipped that will > acquire an IPv4LL address when a DHCP server is present or the device > is manually configured (or configured through bootp or some other > mechanism). that's fine w/me as a mechanism, but we need a standard mechanism, not one which is at the whim of an implementation. networks need a uniform way to disable LL, not one which varies from one device to another. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Tue Jan 21 14:39:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09999 for ; Tue, 21 Jan 2003 14:39:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 25A7A91355; Tue, 21 Jan 2003 14:43:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0AFE91356; Tue, 21 Jan 2003 14:43: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 BEFBA91355 for ; Tue, 21 Jan 2003 14:43:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id A46B25E09F; Tue, 21 Jan 2003 14:43:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 8BEF85E096 for ; Tue, 21 Jan 2003 14:43:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 62E14141FE; Tue, 21 Jan 2003 14:43:04 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 08151-01; Tue, 21 Jan 2003 14:43:03 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 05F7F14204; Tue, 21 Jan 2003 14:43:03 -0500 (EST) Date: Tue, 21 Jan 2003 14:43:02 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121144302.0ca6e210.moore@cs.utk.edu> In-Reply-To: <152D8234-2D72-11D7-AFDA-00039317663C@nominum.com> References: <20030121102919.645ffeaa.moore@cs.utk.edu> <152D8234-2D72-11D7-AFDA-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: c95d5bc7fe3a63cdd100c776204a559f5fd19b34 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 21 Jan 2003 10:56:43 -0800 Ted Lemon wrote: > > More generally, why shouldn't your mother-in-law's applications, > > machines, and networks coexist peacefully rather than interact > > destructively? > > This is just more of the wife-beater rhetoric. You have never > demonstrated any such destructive interaction, so I suggest that you > stop using this terminology and stick to the facts. I've done so many times. And frankly, your abuse is way out of line. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Tue Jan 21 14:47:00 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10192 for ; Tue, 21 Jan 2003 14:47:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CE31891356; Tue, 21 Jan 2003 14:50:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9925191357; Tue, 21 Jan 2003 14:50: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 6D56691356 for ; Tue, 21 Jan 2003 14:50:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5E6DB5E09F; Tue, 21 Jan 2003 14:50:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 43CF35DE26 for ; Tue, 21 Jan 2003 14:50:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id F3A16141FD; Tue, 21 Jan 2003 14:50:15 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 08408-06; Tue, 21 Jan 2003 14:50:15 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 59C1D141D2; Tue, 21 Jan 2003 14:50:15 -0500 (EST) Date: Tue, 21 Jan 2003 14:50:15 -0500 From: Keith Moore To: Joshua Graessley Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121145015.76181f31.moore@cs.utk.edu> In-Reply-To: References: <012f01c2c140$d2a67ff0$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: d02c2ae08badac0a6b2660a4d888ff86cd9bc538 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Referrals where an intermediary party registers the existence of a > device may lead to problems, but problems that could not be otherwise > solved. If we have three devices, A, B, and C. A and B are both on the > same link. A has only an IPv4LL address. B has only a global address. > C has a global address and is on a different link. Without IPv4LL, A > would be unable to communicate with B. With IPv4LL, A and B can > communicate. If B refers C to A by A's IPv4LL address, C will be > unable to communicate with A. This is irrelevant because C would never > be able to communicate with A since they are not both on the same > local link. for the specific case of NetSolve - if C is the netsolve agent trying to mediate between a netsolve server on A and a netsolve client on B, then it's difficult for C to permit referrals to B for A, even though A and B are both on the same link and should be able to talk to each other. if the agent filters LL addresses from referrals, it will filter A's address. if the agent allows referrals containing LL addresses, it may pass A's address into realms in which it is not valid. > IPv4LL address are simple to detect. In time, applications which are > found to not work with IPv4LL addresses can be modified to ignore them > or handle them as appropriate. no good way has been found to do this. both passing the scoped addresses in referrals nor filtering them from referrals breaks things. Keith -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Tue Jan 21 14:49:52 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10268 for ; Tue, 21 Jan 2003 14:49:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D9ACC91357; Tue, 21 Jan 2003 14:53:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AACDB91358; Tue, 21 Jan 2003 14:53: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 A988D91357 for ; Tue, 21 Jan 2003 14:53:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 999245DF04; Tue, 21 Jan 2003 14:53:07 -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 19AA55DE26 for ; Tue, 21 Jan 2003 14:53:07 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0LJmsP02978; Tue, 21 Jan 2003 13:48:54 -0600 (CST) Date: Tue, 21 Jan 2003 11:53:19 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030121144302.0ca6e210.moore@cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> This is just more of the wife-beater rhetoric. You have never >> demonstrated any such destructive interaction, so I suggest that you >> stop using this terminology and stick to the facts. > > I've done so many times. And frankly, your abuse is way out of line. No, no, *your* abuse is out of line! (You see the problem with this kind of talk? :') This is why I'm asking you to stick to the facts, and simply not use negative rhetoric. It doesn't work, it doesn't get you what you want, what it gets is people just deleting your comments without reading them, which is what I did yesterday because there was so much volume on this topic, most of it from a very few people, most of it reiterating emotional points and not making any new informational points. From owner-zeroconf@merit.edu Tue Jan 21 14:58:12 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10454 for ; Tue, 21 Jan 2003 14:58:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EF7E891358; Tue, 21 Jan 2003 15:01:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24B4291359; Tue, 21 Jan 2003 15:01: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 5C21E91358 for ; Tue, 21 Jan 2003 15:00:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id D57BF5E09F; Tue, 21 Jan 2003 15:00:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 88D1A5DF2D for ; Tue, 21 Jan 2003 15:00:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 474CD141FD; Tue, 21 Jan 2003 15:00:49 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 10876-02; Tue, 21 Jan 2003 15:00:48 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id A7232141D2; Tue, 21 Jan 2003 15:00:48 -0500 (EST) Date: Tue, 21 Jan 2003 15:00:48 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu, jwelch@MIT.EDU Subject: Re: Turning off link-locals? Message-Id: <20030121150048.7f3e8fbc.moore@cs.utk.edu> In-Reply-To: References: <20030121140136.7d6232bf.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 601cfcbfaa37ed7829be8793bc3179b38c33761d Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > if you tell the app to ignore LLs you prevent its use on ad hoc > > networks; > > > > if you allow it to use LLs you prevent it from being used across the > > > > public Internet; > > > > if you allow the app to be configured as to which mode it is in you > > have lost whatever benefit you would > > In the event that you need to do this, you use your non-IPv4ll address > in all cases where you have one, because it can be used to communicate > both to IPv4ll hosts and non-IPv4ll hosts. It depends on how hosts work when they only have an LL address. If all such hosts can communicate with routable addresses as easily as they can communicate with the same remote host and interface using a LL address, then yes, any time you have a routable address for a host you should use it in a referral instead of an LL address for that host. OTOH if there are any cases where it is necessary to use an LL address to talk to a host that also has a routable address, this strategy fails. Which seems like a good argument for insisting that hosts have a way to talk to routable addresses even when they only have an LL address. > Manually configuring the app is the wrong answer - having it > programmatically differentiate between IPv4ll and non-IPv4LL addresses > is the right answer. I was told that such a configuration bit was the best that Microsoft people had come up with for dealing with site-local addresses in v6. I need to think some more to understand whether these two cases are different. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Tue Jan 21 16:08:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12092 for ; Tue, 21 Jan 2003 16:08:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F27999125E; Tue, 21 Jan 2003 16:12:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC11B91261; Tue, 21 Jan 2003 16:12: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 A7ED79125E for ; Tue, 21 Jan 2003 16:12:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7FE615E0B5; Tue, 21 Jan 2003 16:12:09 -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 3079D5E0B3 for ; Tue, 21 Jan 2003 16:12:09 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0LL7sP03873; Tue, 21 Jan 2003 15:07:54 -0600 (CST) Date: Tue, 21 Jan 2003 13:12:19 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: philip@engarts.com, zeroconf@merit.edu, jwelch@MIT.EDU To: Keith Moore From: Ted Lemon In-Reply-To: <20030121150048.7f3e8fbc.moore@cs.utk.edu> Message-Id: <068AE37C-2D85-11D7-AFDA-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > It depends on how hosts work when they only have an LL address. If > all such hosts can communicate with routable addresses as easily as > they can communicate with the same remote host and interface using a > LL address, then yes, any time you have a routable address for a host > you should use it in a referral instead of an LL address for that > host. OTOH if there are any cases where it is necessary to use an LL > address to talk to a host that also has a routable address, this > strategy fails. Hm, right. So here's the code from the draft: If the destination address is a unicast address outside the 169.254/16 prefix, then the host SHOULD use an appropriate routable source address, if it has one. If the host does not have a routable source address, then it MAY choose to ARP for the destination address and then send its packet, with a link-local source IP address and a routable destination IP address, directly to its destination on the same physical link. The host MUST NOT send the packet to any router for forwarding. So I guess it's possible for an implementation to not support this capability, and I have to admit that this seems like a mistake to me. Can anyone explain the reasoning behind making this a MAY instead of a MUST? From owner-zeroconf@merit.edu Tue Jan 21 16:09:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12111 for ; Tue, 21 Jan 2003 16:09:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AABB991261; Tue, 21 Jan 2003 16:12:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 726A9912D2; Tue, 21 Jan 2003 16:12: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 EA9D091261 for ; Tue, 21 Jan 2003 16:12:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id D90255E0B5; Tue, 21 Jan 2003 16:12:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from DIN-SMTPOUT.dreamersi.net (din-smtpout.dreamersi.net [216.217.219.195]) by segue.merit.edu (Postfix) with ESMTP id 77FF85E0B3 for ; Tue, 21 Jan 2003 16:12:22 -0500 (EST) Received: from ADAM3 ([216.137.29.184]) by DIN-SMTPOUT.dreamersi.net with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 13:13:05 -0800 From: "Adam MacBeth" To: "'Joshua Graessley'" , "'Zeroconf'" Subject: RE: Turning off link-locals? Date: Tue, 21 Jan 2003 13:12:21 -0800 Message-ID: <004801c2c191$c991f600$950aa8c0@oius.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <9D8E5D65-2D72-11D7-A610-000393760260@apple.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 21 Jan 2003 21:13:05.0875 (UTC) FILETIME=[E3F5CA30:01C2C191] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > If DHCP is present, I don't see any reason to acquire a LL address. > Determining if DHCP is present may take a while. For example, IP address autoconfiguration in Windows takes a few minutes to give up on DHCP and assign a LL address, which makes adhoc networking pretty unusable. The timeout could be configurable, but anything longer than a few seconds is a hassle. Is there a way to make this usable without immediately acquiring a LL address when a new interface is brought up? From owner-zeroconf@merit.edu Tue Jan 21 16:15:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12233 for ; Tue, 21 Jan 2003 16:15:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC92E912D2; Tue, 21 Jan 2003 16:18:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE139912D3; Tue, 21 Jan 2003 16:18: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 BB239912D2 for ; Tue, 21 Jan 2003 16:18:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id A03305DE73; Tue, 21 Jan 2003 16:18:42 -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 6FC685DE14 for ; Tue, 21 Jan 2003 16:18:42 -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 B973F598B0; Tue, 21 Jan 2003 21:18:45 +0000 (GMT) Message-ID: <017b01c2c192$ac514b30$131010ac@aldebaran> From: "Philip Nye" To: "Joshua Graessley" , References: Subject: Re: Turning off link-locals? Date: Tue, 21 Jan 2003 21:18:41 -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 Joshua, > This problem is not as significant as it may seem. If IPv4LLs are only > acquired on an interface when no global address can be (no DHCP, manual > config, or other config method), the device will be unable to > communicate with anything off of the local link through that interface. Your analysis is reasonable - but it is rather off the track because the current draft recommends that IPv4LL be turned on even when a global address IS found - and this is the source of the problems. Philip From owner-zeroconf@merit.edu Tue Jan 21 16:20:01 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12309 for ; Tue, 21 Jan 2003 16:20:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 29AA791368; Tue, 21 Jan 2003 16:22:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15B0391363; Tue, 21 Jan 2003 16:22: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 5A01491363 for ; Tue, 21 Jan 2003 16:22:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 46A355DE47; Tue, 21 Jan 2003 16:22:49 -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 D98D05DE14 for ; Tue, 21 Jan 2003 16:22:48 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0LLIZP04013; Tue, 21 Jan 2003 15:18:35 -0600 (CST) Date: Tue, 21 Jan 2003 13:23:00 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Philip Nye" From: Ted Lemon In-Reply-To: <012f01c2c140$d2a67ff0$131010ac@aldebaran> Message-Id: <84EEC1B1-2D86-11D7-AFDA-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Given an interface with two addresses, which one does an application > use? In > the traditional case, it doesn't matter much but in the case where one > address is of limited scope it does. This still doesn't cause much > trouble > in a straight two way exchange but in a three way exchange (a > referral) the > only way to solve the problem seems to be for the app to be aware of > address > scoping (which many such apps are not). > So far I have seen no rebuttal to this issue except to deny its > existence, [...] That's because the current draft does not require that you have a link-local address in order to communicate with link-local nodes. The only reason this is a problem at all is that the draft has a MAY where I think it should have a MUST, as I mentioned in my recent message to Keith. > Any host using v4LL on two interfaces has trouble knowing which > interface to > route LL packets to as discussed in section 3 of the draft. I can think of a few scenarios here: First, in all cases consider it a constant that host A has two interfaces. Host B is on the network attached to one of these interfaces, and host C is on the network attached to the other interface. Hosts B and C are both using the same IPv4LL IP address. Problem 1: Host B tries to establish a TCP connection to host A. How does host A decide to which host to send the SYN+ACK? Solution: Stash the interface ID in the TCP control block. Problem 2: Host B sends a UDP packet to host A. Host A needs to respond to host B, but UDP is connectionless so we don't know which ARP cache entry to use. Solution: The draft says that host A should only talk to the first of host B or host C from which it gets an ARP reply when it ARPs for the address that B and C share. In practice, this will probably be the one that it ARPs for first, since it needs to send two ARP packets. So it won't be able to talk to one of these hosts, and it will not be obvious to the user why this is so. Problem 3: Host A needs to send a packet to a host called B.local. It looks up B.local using MDNS, and gets the IP address that B and C are both using. It got the address from B, but there's no way to communicate this through the API. How does it connect to B? Solution: Here it's not clear what to do - we may have done MDNS to host B when host C is the one we actually have in our ARP cache, because MDNS doesn't use ARP - it uses multicast. Here again we have a case where the user will be unable to communicate with host B, and there will be no obvious explanation for why this is so. I can think of solutions to this problem, possibly involving an ICMP message and multiple IPv4ll addresses on the same interface. That is, host A detects the conflict and sends host B an ICMP message saying "dude, can you acquire a second IPv4LL address so I can talk to you?" This would work, but it's complicated. These problems aren't addressed by the draft, except by the rather drastic option of simply not doing IPv4LL on two interfaces at once. The problem with this is that I think it doesn't work - I may have a wireless printer and an unmanaged wired connection, and I want both of them to work. On which interface does the O.S. not do IPv4LL? On what basis does it decide? > For a while I thought these discussions were getting somewhere but > then the > mudslinging prevailed - at least it is familiar! I have seen some mudslinging, mostly between a few individuals. I've also seen a lot of constructive conversation, mostly from other individuals. If you just filter out the mudslinging, I think you'll do fine. From owner-zeroconf@merit.edu Tue Jan 21 16:31:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12594 for ; Tue, 21 Jan 2003 16:31:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D36A7912D6; Tue, 21 Jan 2003 16:34:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A4A4B9135A; Tue, 21 Jan 2003 16:34: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 1FD0C912D6 for ; Tue, 21 Jan 2003 16:34:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id EA1915E0C2; Tue, 21 Jan 2003 16:34:00 -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 AB9275E0BF for ; Tue, 21 Jan 2003 16:34:00 -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 h0LLXwJ04170 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 21 Jan 2003 16:33:59 -0500 Message-Id: <5.2.0.9.2.20030121162018.02799280@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 21 Jan 2003 16:33:07 -0500 To: "'Zeroconf'" From: Daniel Senie Subject: RE: Turning off link-locals? In-Reply-To: <004801c2c191$c991f600$950aa8c0@oius.com> References: <9D8E5D65-2D72-11D7-A610-000393760260@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 04:12 PM 1/21/2003, Adam MacBeth wrote: > > If DHCP is present, I don't see any reason to acquire a LL address. > > > >Determining if DHCP is present may take a while. For example, IP >address autoconfiguration in Windows takes a few minutes to give up on >DHCP and assign a LL address, which makes adhoc networking pretty >unusable. The timeout could be configurable, but anything longer than a >few seconds is a hassle. Is there a way to make this usable without >immediately acquiring a LL address when a new interface is brought up? Windows (at least recent versions) appears to always assign a LL address when an interface is brought up. If/when DHCP completes, the address is replaced with the assigned address. The degree to which that address is actually used by Windows while waiting for DHCP is unclear. From owner-zeroconf@merit.edu Tue Jan 21 19:01:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15866 for ; Tue, 21 Jan 2003 19:01:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9C21091266; Tue, 21 Jan 2003 19:04:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9CC191265; Tue, 21 Jan 2003 19:02: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 F114191264 for ; Tue, 21 Jan 2003 19:01:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id D137B5DE61; Tue, 21 Jan 2003 19:01:52 -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 D970D5DE46 for ; Tue, 21 Jan 2003 19:01:51 -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 h0M01Xjf015498; Wed, 22 Jan 2003 10:01:34 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id h0M01U201820; Wed, 22 Jan 2003 10:01:31 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Wed, 22 Jan 2003 10:01:30 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: Philip Nye Cc: Joshua Graessley , Subject: Re: Turning off link-locals? In-Reply-To: <017b01c2c192$ac514b30$131010ac@aldebaran> 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 Tue, 21 Jan 2003, Philip Nye wrote: >Joshua, > >> This problem is not as significant as it may seem. If IPv4LLs are only >> acquired on an interface when no global address can be (no DHCP, manual >> config, or other config method), the device will be unable to >> communicate with anything off of the local link through that interface. > >Your analysis is reasonable - but it is rather off the track because the >current draft recommends that IPv4LL be turned on even when a global address >IS found - and this is the source of the problems. It is not off track if the draft is amended to specify the behaviour Joshua described (which is currently implemented in Mac OS and IMO is the most appropriate behaviour). With that behaviour IPv4LL is used only where there is no alternative, so there can be no accusations of breakage. Is there anybody who actually wants to argue against this? Ian From owner-zeroconf@merit.edu Tue Jan 21 19:16:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16135 for ; Tue, 21 Jan 2003 19:16:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9876591264; Tue, 21 Jan 2003 19:19:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 663CB91265; Tue, 21 Jan 2003 19:19: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 C929D91264 for ; Tue, 21 Jan 2003 19:17:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9A4365DDFD; Tue, 21 Jan 2003 19:17:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by segue.merit.edu (Postfix) with ESMTP id 31DFE5DDE9 for ; Tue, 21 Jan 2003 19:17:04 -0500 (EST) Received: from rygar.gpcc.itd.umich.edu (rygar.gpcc.itd.umich.edu [141.211.2.202]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id TAA00867; Tue, 21 Jan 2003 19:17:02 -0500 (EST) Received: from localhost (sgoswami@localhost) by rygar.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id TAA23246; Tue, 21 Jan 2003 19:17:02 -0500 (EST) Date: Tue, 21 Jan 2003 19:17:02 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@rygar.gpcc.itd.umich.edu To: Ian Lister Cc: Philip Nye , Joshua Graessley , Subject: Re: Turning off link-locals? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk See inline On Wed, 22 Jan 2003, Ian Lister wrote: > On Tue, 21 Jan 2003, Philip Nye wrote: > >Joshua, > > > >> This problem is not as significant as it may seem. If IPv4LLs are only > >> acquired on an interface when no global address can be (no DHCP, manual > >> config, or other config method), the device will be unable to > >> communicate with anything off of the local link through that interface. > > > >Your analysis is reasonable - but it is rather off the track because the > >current draft recommends that IPv4LL be turned on even when a global address > >IS found - and this is the source of the problems. > > It is not off track if the draft is amended to specify the behaviour > Joshua described (which is currently implemented in Mac OS and IMO is the > most appropriate behaviour). With that behaviour IPv4LL is used only where > there is no alternative, so there can be no accusations of breakage. Is > there anybody who actually wants to argue against this? > > Ian > So you are professing a preference level for each method: DHCP 1, Manual 2, LL 3 ? Correct ? Subrata From owner-zeroconf@merit.edu Tue Jan 21 19:31:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16342 for ; Tue, 21 Jan 2003 19:31:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ED4B791265; Tue, 21 Jan 2003 19:34:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19CCC91269; Tue, 21 Jan 2003 19:32: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 A819491265 for ; Tue, 21 Jan 2003 19:31:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3FA085DDAB; Tue, 21 Jan 2003 19:31:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by segue.merit.edu (Postfix) with ESMTP id E7BF95DD9F for ; Tue, 21 Jan 2003 19:31:49 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18b8np-0006zw-00; Tue, 21 Jan 2003 16:31:37 -0800 Date: Tue, 21 Jan 2003 19:27:58 -0500 From: Keith Moore To: Ian Lister Cc: moore@cs.utk.edu, philip@engarts.com, jgraessley@apple.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121192758.13dc98f4.moore@cs.utk.edu> In-Reply-To: References: <017b01c2c192$ac514b30$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Wed, 22 Jan 2003 10:01:30 +1000 (EST) Ian Lister wrote: > On Tue, 21 Jan 2003, Philip Nye wrote: > >Joshua, > > > >> This problem is not as significant as it may seem. If IPv4LLs are only > >> acquired on an interface when no global address can be (no DHCP, manual > >> config, or other config method), the device will be unable to > >> communicate with anything off of the local link through that interface. > > > >Your analysis is reasonable - but it is rather off the track because the > >current draft recommends that IPv4LL be turned on even when a global address > >IS found - and this is the source of the problems. > > It is not off track if the draft is amended to specify the behaviour > Joshua described (which is currently implemented in Mac OS and IMO is the > most appropriate behaviour). With that behaviour IPv4LL is used only where > there is no alternative, so there can be no accusations of breakage. Is > there anybody who actually wants to argue against this? now I'm losing track of what is meant by "used" - - when should an IPv4LL address be configured by a host? suggest: if the host is explicitly configured to do so, OR if the host has attempted and failed to acquire a routable address via DHCP (alternative: provide a lighter weight mechanism by which a host can acquire a routable address, netmask, and default route, in response to its attempt to claim an IPv4LL address) - when should an IPv4LL address be used by a host as a source address? suggest: when the only addresses available to the host are IPv4LL addresses, OR when the application has explicitly specified the source address to use, OR when the application has explicitly specified the interface to use and the IPv4LL address is the only address associated with that interface. - when should a host honor an attempt to connect to an IPv4LL address that was once configured by that host? suggest: anytime the address is still valid (e.g. there have been no conflicting claims) and there is a process listening for connections either specifically to that address or for incoming connections at any of the host's addresses. - when should an application attempt to connect to a IPv4LL address? suggest: only when the address is literally specified, or if there are no other routable addresses for the destination host known to the application. - when should an application send an IPv4LL address in a referral to another host? suggest: only when there are no routable addresses for the destination host known to the application. even then, care needs to be taken that a host reached at a particular IPv4LL address is really the one intended - since IPv4LL addresses can be reassigned without notice and/or reused on different network segments. From owner-zeroconf@merit.edu Tue Jan 21 19:41:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16495 for ; Tue, 21 Jan 2003 19:41:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9116E91267; Tue, 21 Jan 2003 19:44:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58A8391269; Tue, 21 Jan 2003 19:44:33 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1D27491267 for ; Tue, 21 Jan 2003 19:44:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id E1E1B5DE87; Tue, 21 Jan 2003 19:44:31 -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 F07C15DE83 for ; Tue, 21 Jan 2003 19:44:30 -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 h0M0iQjf019291; Wed, 22 Jan 2003 10:44:28 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id h0M0iQd01961; Wed, 22 Jan 2003 10:44:26 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Wed, 22 Jan 2003 10:44:25 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: "s. goswami" Cc: zeroconf@merit.edu Subject: Re: Turning off link-locals? 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: -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 Tue, 21 Jan 2003, s. goswami wrote: >> It is not off track if the draft is amended to specify the behaviour >> Joshua described (which is currently implemented in Mac OS and IMO is the >> most appropriate behaviour). With that behaviour IPv4LL is used only where >> there is no alternative, so there can be no accusations of breakage. Is >> there anybody who actually wants to argue against this? >So you are professing a preference level for each method: DHCP 1, Manual >2, LL 3 ? Correct ? I am expressing a preference level for: 1. Configured/managed mechanisms This is manual, DHCP, or whatever is configured using a host's normal configuration mechanism (/etc/hostname.if, Network control panel, etc) 2. Zero configuration mechanisms IPv4LL Note that by `use' I am referring to acquiring an address, not to ability to communicate with other hosts using such an address. Ian From owner-zeroconf@merit.edu Tue Jan 21 20:32:18 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17382 for ; Tue, 21 Jan 2003 20:32:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F099291362; Tue, 21 Jan 2003 20:35:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1B3791365; Tue, 21 Jan 2003 20:35: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 86F5B91362 for ; Tue, 21 Jan 2003 20:35:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 64FBD5DDE9; Tue, 21 Jan 2003 20:35:33 -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 70F805DDD3 for ; Tue, 21 Jan 2003 20:35:32 -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 h0M1ZMjf023571; Wed, 22 Jan 2003 11:35:22 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id h0M1ZK902110; Wed, 22 Jan 2003 11:35:20 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Wed, 22 Jan 2003 11:35:20 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: Keith Moore Cc: zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: <20030121192758.13dc98f4.moore@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 Tue, 21 Jan 2003, Keith Moore wrote: >On Wed, 22 Jan 2003 10:01:30 +1000 (EST) Ian Lister wrote: >> It is not off track if the draft is amended to specify the behaviour >> Joshua described (which is currently implemented in Mac OS and IMO is the >> most appropriate behaviour). With that behaviour IPv4LL is used only where >> there is no alternative, so there can be no accusations of breakage. Is >> there anybody who actually wants to argue against this? > >now I'm losing track of what is meant by "used" - Sorry, I was ambiguous. As I just clarified in a mail a minute ago, I meant acquiring an IPv4LL address, not communicating with a host with an IPv4LL address. >- when should an IPv4LL address be configured by a host? > > suggest: if the host is explicitly configured to do so, OR > if the host has attempted and failed to acquire a routable address via DHCP This seems fair enough. > (alternative: provide a lighter weight mechanism by which a host can acquire a > routable address, netmask, and default route, in response to its attempt to claim > an IPv4LL address) I'm not sure what this is aimed at, or what its purpose is over and above DHCP, but given that the first suggestion seems fine I won't dwell on it. >- when should an IPv4LL address be used by a host as a source address? > > suggest: when the only addresses available to the host are IPv4LL addresses, OR > when the application has explicitly specified the source address to use, OR > when the application has explicitly specified the interface to use and the IPv4LL address > is the only address associated with that interface. That seems fine. Also when the destination address is IPv4LL there doesn't seem to be any reason not to use an IPv4LL source address. >- when should a host honor an attempt to connect to an IPv4LL address that was once > configured by that host? > > suggest: anytime the address is still valid (e.g. there have been no conflicting claims) > and there is a process listening for connections either specifically to that address or > for incoming connections at any of the host's addresses. Seems straightforward enough. >- when should an application attempt to connect to a IPv4LL address? > > suggest: only when the address is literally specified, or if there are no other routable > addresses for the destination host known to the application. OK. Also if the source has only an IPv4LL address and the destination IPv4LL address is known to be in-scope (i.e. on the same link) I don't see a good reason not to use the IPv4LL destination address. >- when should an application send an IPv4LL address in a referral to another host? > > suggest: only when there are no routable addresses for the destination host known to the > application. even then, care needs to be taken that a host reached at a particular > IPv4LL address is really the one intended - since IPv4LL addresses can be reassigned > without notice and/or reused on different network segments. This seems fair enough. So, it seems for the most part we agree on these things. Does anybody care to disagree? Ian From owner-zeroconf@merit.edu Tue Jan 21 20:41:39 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18131 for ; Tue, 21 Jan 2003 20:41:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B8BAE91365; Tue, 21 Jan 2003 20:44:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81BE391367; Tue, 21 Jan 2003 20:44: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 703E391365 for ; Tue, 21 Jan 2003 20:44:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 537735DE7A; Tue, 21 Jan 2003 20:44:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by segue.merit.edu (Postfix) with ESMTP id DF66A5DE79 for ; Tue, 21 Jan 2003 20:44:53 -0500 (EST) Received: from rygar.gpcc.itd.umich.edu (rygar.gpcc.itd.umich.edu [141.211.2.202]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id UAA14110; Tue, 21 Jan 2003 20:44:53 -0500 (EST) Received: from localhost (sgoswami@localhost) by rygar.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id UAA05920; Tue, 21 Jan 2003 20:44:53 -0500 (EST) Date: Tue, 21 Jan 2003 20:44:53 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@rygar.gpcc.itd.umich.edu To: Ian Lister Cc: zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk So a relevant question is can LL coexist with DHCP/Manual ? 1. In different subnets (or physical link). Absolutely. 2. In the same physical link (i.e. mix 169.254/16 with say 192.168/16 )? A 169.254 interface can talk to a 192.168 host sitting on the same physical link without a router. DHCP servers can handout 169.254/16 addresses if they want. Subrata On Wed, 22 Jan 2003, Ian Lister wrote: > On Tue, 21 Jan 2003, s. goswami wrote: > >> It is not off track if the draft is amended to specify the behaviour > >> Joshua described (which is currently implemented in Mac OS and IMO is the > >> most appropriate behaviour). With that behaviour IPv4LL is used only where > >> there is no alternative, so there can be no accusations of breakage. Is > >> there anybody who actually wants to argue against this? > > >So you are professing a preference level for each method: DHCP 1, Manual > >2, LL 3 ? Correct ? > > I am expressing a preference level for: > > 1. Configured/managed mechanisms > > This is manual, DHCP, or whatever is configured using a host's normal > configuration mechanism (/etc/hostname.if, Network control panel, etc) > > 2. Zero configuration mechanisms > > IPv4LL > > Note that by `use' I am referring to acquiring an address, not to ability > to communicate with other hosts using such an address. > > Ian > From owner-zeroconf@merit.edu Tue Jan 21 21:01:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18505 for ; Tue, 21 Jan 2003 21:01:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F327D91367; Tue, 21 Jan 2003 21:04:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC5599126C; Tue, 21 Jan 2003 21:04: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 C9FB991367 for ; Tue, 21 Jan 2003 21:02:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 508095DDD3; Tue, 21 Jan 2003 21:02:18 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by segue.merit.edu (Postfix) with ESMTP id A4FEC5DDD2 for ; Tue, 21 Jan 2003 21:02:16 -0500 (EST) Received: from rygar.gpcc.itd.umich.edu (rygar.gpcc.itd.umich.edu [141.211.2.202]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id VAA14964; Tue, 21 Jan 2003 21:02:12 -0500 (EST) Received: from localhost (sgoswami@localhost) by rygar.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id VAA08242; Tue, 21 Jan 2003 21:02:12 -0500 (EST) Date: Tue, 21 Jan 2003 21:02:12 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@rygar.gpcc.itd.umich.edu To: Ian Lister Cc: zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Yes, using DHCP for 169.254/16 is not necessary. What are the pitfalls if one wishes to do so ? Subrata On Wed, 22 Jan 2003, Ian Lister wrote: > On Tue, 21 Jan 2003, s. goswami wrote: > >So a relevant question is can LL coexist with DHCP/Manual ? > > > >1. In different subnets (or physical link). Absolutely. > >2. In the same physical link (i.e. mix 169.254/16 with say 192.168/16 )? > > A 169.254 interface can talk to a 192.168 host sitting on the same > > physical link without a router. DHCP servers can handout 169.254/16 > > addresses if they want. > > I'm not quite sure what you're driving at, but yes, IPvLL can coexist with > non-IPv4LL on the same link and can communicate with each other. > However, configuring a DHCP server to hand out IPv4LL addresses seems like > a distinctly bad idea. > > Ian > From owner-zeroconf@merit.edu Tue Jan 21 21:16:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18769 for ; Tue, 21 Jan 2003 21:16:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 22CB79126C; Tue, 21 Jan 2003 21:19:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECCCF9136C; Tue, 21 Jan 2003 21:19: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 82D809126C for ; Tue, 21 Jan 2003 21:17:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5C9DA5DDE9; Tue, 21 Jan 2003 21:17:39 -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 E38F15DE41 for ; Tue, 21 Jan 2003 21:17: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 h0M2HbJ15433 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Tue, 21 Jan 2003 21:17:38 -0500 Message-Id: <5.2.0.9.2.20030121211404.0275bdc0@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 21 Jan 2003 21:17:08 -0500 To: zeroconf@merit.edu From: Daniel Senie Subject: Re: Turning off link-locals? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 09:02 PM 1/21/2003, s. goswami wrote: >Yes, using DHCP for 169.254/16 is not necessary. What are >the pitfalls if one wishes to do so ? Addresses in 169.254/16 are self-assigned, using claim and defend. DHCP servers need not be attached to the segment or subnet on which they're handing out addresses (e.g. DHCP Relay in use). As such, the DHCP server has no way to know which addresses are in use on a subnet where stations self assign addresses. Even if the DHCP server were on the same subnet, IT would have to do the claim and defend for all addresses it handed out. This is not wise. So, it's important that DHCP servers NEVER hand out addresses in LL space. >On Wed, 22 Jan 2003, Ian Lister wrote: > > > On Tue, 21 Jan 2003, s. goswami wrote: > > >So a relevant question is can LL coexist with DHCP/Manual ? > > > > > >1. In different subnets (or physical link). Absolutely. > > >2. In the same physical link (i.e. mix 169.254/16 with say 192.168/16 )? > > > A 169.254 interface can talk to a 192.168 host sitting on the same > > > physical link without a router. DHCP servers can handout 169.254/16 > > > addresses if they want. > > > > I'm not quite sure what you're driving at, but yes, IPvLL can coexist with > > non-IPv4LL on the same link and can communicate with each other. > > However, configuring a DHCP server to hand out IPv4LL addresses seems like > > a distinctly bad idea. > > > > Ian > > From owner-zeroconf@merit.edu Tue Jan 21 21:31:21 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18990 for ; Tue, 21 Jan 2003 21:31:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DACEA91370; Tue, 21 Jan 2003 21:32:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C5E09136D; Tue, 21 Jan 2003 21:31: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 3FDC29136C for ; Tue, 21 Jan 2003 21:31:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id B6D675E0CB; Tue, 21 Jan 2003 21:31:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by segue.merit.edu (Postfix) with ESMTP id DA2265DE87 for ; Tue, 21 Jan 2003 21:31:27 -0500 (EST) Received: from rygar.gpcc.itd.umich.edu (rygar.gpcc.itd.umich.edu [141.211.2.202]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id VAA08226; Tue, 21 Jan 2003 21:31:26 -0500 (EST) Received: from localhost (sgoswami@localhost) by rygar.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id VAA11807; Tue, 21 Jan 2003 21:31:26 -0500 (EST) Date: Tue, 21 Jan 2003 21:31:26 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@rygar.gpcc.itd.umich.edu To: Daniel Senie Cc: zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: <5.2.0.9.2.20030121211404.0275bdc0@mail.amaranth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk see inline On Tue, 21 Jan 2003, Daniel Senie wrote: > At 09:02 PM 1/21/2003, s. goswami wrote: > > > >Yes, using DHCP for 169.254/16 is not necessary. What are > >the pitfalls if one wishes to do so ? > > Addresses in 169.254/16 are self-assigned, using claim and defend. > > DHCP servers need not be attached to the segment or subnet on which they're > handing out addresses (e.g. DHCP Relay in use). As such, the DHCP server > has no way to know which addresses are in use on a subnet where stations > self assign addresses. Even if the DHCP server were on the same subnet, IT > would have to do the claim and defend for all addresses it handed out. This > is not wise. > the DHCP server is supposed to ping (ICMP) the address before handing it out (takes IT out of the loop). > So, it's important that DHCP servers NEVER hand out addresses in LL space. > > > > >On Wed, 22 Jan 2003, Ian Lister wrote: > > > > > On Tue, 21 Jan 2003, s. goswami wrote: > > > >So a relevant question is can LL coexist with DHCP/Manual ? > > > > > > > >1. In different subnets (or physical link). Absolutely. > > > >2. In the same physical link (i.e. mix 169.254/16 with say 192.168/16 )? > > > > A 169.254 interface can talk to a 192.168 host sitting on the same > > > > physical link without a router. DHCP servers can handout 169.254/16 > > > > addresses if they want. > > > > > > I'm not quite sure what you're driving at, but yes, IPvLL can coexist with > > > non-IPv4LL on the same link and can communicate with each other. > > > However, configuring a DHCP server to hand out IPv4LL addresses seems like > > > a distinctly bad idea. > > > > > > Ian > > > > From owner-zeroconf@merit.edu Tue Jan 21 22:02:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19768 for ; Tue, 21 Jan 2003 22:02:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6BCD29136D; Tue, 21 Jan 2003 22:05:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CD869136E; Tue, 21 Jan 2003 22:05: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 8D4689136D for ; Tue, 21 Jan 2003 22:05:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 64C805DDE9; Tue, 21 Jan 2003 22:05:56 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by segue.merit.edu (Postfix) with ESMTP id 40F225DD9F for ; Tue, 21 Jan 2003 22:05:56 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bBCr-0002V1-00; Tue, 21 Jan 2003 19:05:37 -0800 Date: Tue, 21 Jan 2003 22:01:51 -0500 From: Keith Moore To: Ian Lister Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121220151.5c48f44d.moore@cs.utk.edu> In-Reply-To: References: <20030121192758.13dc98f4.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Wed, 22 Jan 2003 11:35:20 +1000 (EST) Ian Lister wrote: > On Tue, 21 Jan 2003, Keith Moore wrote: > >On Wed, 22 Jan 2003 10:01:30 +1000 (EST) Ian Lister wrote: > >> It is not off track if the draft is amended to specify the behaviour > >> Joshua described (which is currently implemented in Mac OS and IMO is the > >> most appropriate behaviour). With that behaviour IPv4LL is used only > >where> there is no alternative, so there can be no accusations of breakage. > >Is> there anybody who actually wants to argue against this? > > > >now I'm losing track of what is meant by "used" - > > Sorry, I was ambiguous. As I just clarified in a mail a minute ago, I > meant acquiring an IPv4LL address, not communicating with a host with an > IPv4LL address. > > >- when should an IPv4LL address be configured by a host? > > > > suggest: if the host is explicitly configured to do so, OR > > if the host has attempted and failed to acquire a routable address via > > DHCP > > This seems fair enough. > > > (alternative: provide a lighter weight mechanism by which a host can > > acquire a > > routable address, netmask, and default route, in response to its attempt > > to claim an IPv4LL address) > > I'm not sure what this is aimed at, or what its purpose is over and above > DHCP, but given that the first suggestion seems fine I won't dwell on it. the idea is to lower the implementation burden for fixed-function devices that can't afford to dedicate much code space to address allocation, to minimize as much as possible the split between routable and v4LL worlds, and to discourage vendors from making devices that can only talk to hosts on the local link. > >- when should an IPv4LL address be used by a host as a source address? > > > > suggest: when the only addresses available to the host are IPv4LL > > addresses, OR when the application has explicitly specified the source > > address to use, OR when the application has explicitly specified the > > interface to use and the IPv4LL address is the only address associated > > with that interface. > > That seems fine. Also when the destination address is IPv4LL there doesn't > seem to be any reason not to use an IPv4LL source address. actually I disagree, because a v4LL source address might be used by the destination host in a referral to another host which is not on the same link. > >- when should an application attempt to connect to a IPv4LL address? > > > > suggest: only when the address is literally specified, or if there are no > > other routable addresses for the destination host known to the > > application. > > OK. Also if the source has only an IPv4LL address and the destination > IPv4LL address is known to be in-scope (i.e. on the same link) I don't see > a good reason not to use the IPv4LL destination address. same reason as above - because it might be used by the destination in a referral to another node. basically life is much simpler if: a. every host on a managed network gets a routable address, and b. hosts and apps avoid using scoped addresses whenever possible. Keith From owner-zeroconf@merit.edu Tue Jan 21 22:08:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19828 for ; Tue, 21 Jan 2003 22:08:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5C77D9136F; Tue, 21 Jan 2003 22:10:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F89F91378; Tue, 21 Jan 2003 22:10: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 6B6A99136F for ; Tue, 21 Jan 2003 22:10:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 54ABA5DDE9; Tue, 21 Jan 2003 22:10: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 E09005DD9F for ; Tue, 21 Jan 2003 22:10: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 WAA28881 for ; Tue, 21 Jan 2003 22:10: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 WAA17047 for ; Tue, 21 Jan 2003 22:10: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 WAA19366 for ; Tue, 21 Jan 2003 22:10:28 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 21 Jan 2003 22:10:27 -0500 Subject: Re: Turning off link-locals? 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 01/21/2003 19:01, "Ian Lister" wrote: > It is not off track if the draft is amended to specify the behaviour > Joshua described (which is currently implemented in Mac OS and IMO is the > most appropriate behaviour). With that behaviour IPv4LL is used only where > there is no alternative, so there can be no accusations of breakage. Is > there anybody who actually wants to argue against this? Yes, actually. Because now, so that you avoid dictating behavior to network managers, you're dictating behavior to end users. So we need to decide who has priority for the standard, end users or network managers. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 21 22:08:58 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19850 for ; Tue, 21 Jan 2003 22:08:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3096691372; Tue, 21 Jan 2003 22:12:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFBE391373; Tue, 21 Jan 2003 22:12: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 9F58E91372 for ; Tue, 21 Jan 2003 22:12:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 888A55DF93; Tue, 21 Jan 2003 22:12:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by segue.merit.edu (Postfix) with ESMTP id 682445DDE9 for ; Tue, 21 Jan 2003 22:12:08 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bBIx-0003jy-00; Tue, 21 Jan 2003 19:11:55 -0800 Date: Tue, 21 Jan 2003 22:08:16 -0500 From: Keith Moore To: "s. goswami" Cc: moore@cs.utk.edu, ilister@lister.dnsalias.net, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121220816.38148671.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Yes, using DHCP for 169.254/16 is not necessary. What are > the pitfalls if one wishes to do so ? well, there are the normal pitfalls associated with scoped addresses of any kind - they're ambiguous, etc. of course those pitfalls exist with RFC 1918 addresses also. then you can probably expect that some applications will treat v4LL addresses differently than normal routable addresses, where this behavior is application-specific and might or might not be what you want for your network. then there is the potential for conflict between DHCP-assigned addresses in that space and automatically-claimed addresses in that space, from legacy (i.e. pre-standardization) implementations of v4LL. offhand it seems better if such addresses are not doled out by DHCP. Keith From owner-zeroconf@merit.edu Tue Jan 21 22:13:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19886 for ; Tue, 21 Jan 2003 22:13:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 89A7C91373; Tue, 21 Jan 2003 22:15:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1054F91376; Tue, 21 Jan 2003 22:15: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 222E591373 for ; Tue, 21 Jan 2003 22:15:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id AEC805DDE9; Tue, 21 Jan 2003 22:15:23 -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 95DFC5DD9F for ; Tue, 21 Jan 2003 22:15:22 -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 WAA20334 for ; Tue, 21 Jan 2003 22:15: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 WAA11425 for ; Tue, 21 Jan 2003 22:15: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 WAA20038 for ; Tue, 21 Jan 2003 22:15:21 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 21 Jan 2003 22:15:19 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030121192758.13dc98f4.moore@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 01/21/2003 19:27, "Keith Moore" wrote: > - when should an IPv4LL address be configured by a host? > > suggest: if the host is explicitly configured to do so, OR > if the host has attempted and failed to acquire a routable address via DHCP > > (alternative: provide a lighter weight mechanism by which a host can acquire > a > routable address, netmask, and default route, in response to its attempt to > claim > an IPv4LL address) Now, here's a monkey wrench, and a fairly logical one...printers... WHY do you need to have printers with routable, global addresses in all cases? Normally, you don't. So printers with LLv4 - only addressing actually makes a fair bit of sense, especially behind a firewall and a NAT. (Yes, keith, we KNOW how you feel about NAT, but they exist, so sticking fingers in ears and yelling loudly won't change that). Again, HOW do you easily override the DHCP = OFF condition here? This is NOT the simple conditional some think it is. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 21 22:21:14 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19964 for ; Tue, 21 Jan 2003 22:21:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 915C591374; Tue, 21 Jan 2003 22:24:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E67C91375; Tue, 21 Jan 2003 22:24: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 3689391374 for ; Tue, 21 Jan 2003 22:24:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E0245DF93; Tue, 21 Jan 2003 22:24:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by segue.merit.edu (Postfix) with ESMTP id F155D5DEA3 for ; Tue, 21 Jan 2003 22:24:28 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bBV1-0003LW-00; Tue, 21 Jan 2003 19:24:23 -0800 Date: Tue, 21 Jan 2003 22:20:44 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121222044.2717af0d.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Tue, 21 Jan 2003 22:10:27 -0500 "John C. Welch" wrote: > On 01/21/2003 19:01, "Ian Lister" wrote: > > > It is not off track if the draft is amended to specify the behaviour > > Joshua described (which is currently implemented in Mac OS and IMO is the > > most appropriate behaviour). With that behaviour IPv4LL is used only where > > there is no alternative, so there can be no accusations of breakage. Is > > there anybody who actually wants to argue against this? > > Yes, actually. Because now, so that you avoid dictating behavior to network > managers, you're dictating behavior to end users. So we need to decide who > has priority for the standard, end users or network managers. my assumption is that we're specifying a default behavior in the absence of explicit per-host configuration. IMHO it should be possible for explicit per-host configuration to override essentially anything that can be obtained by DHCP, because much of what is obtained through DHCP really doesn't have any relationship to the location in the network. Keith From owner-zeroconf@merit.edu Tue Jan 21 22:33:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20370 for ; Tue, 21 Jan 2003 22:33:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9F6D591375; Tue, 21 Jan 2003 22:36:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E8FA91376; Tue, 21 Jan 2003 22:36: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 50C9991375 for ; Tue, 21 Jan 2003 22:36:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3937D5DEA3; Tue, 21 Jan 2003 22:36:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by segue.merit.edu (Postfix) with ESMTP id 18BA75DDD2 for ; Tue, 21 Jan 2003 22:36:52 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bBh4-0000ue-00; Tue, 21 Jan 2003 19:36:50 -0800 Date: Tue, 21 Jan 2003 22:33:10 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121223310.3fc68000.moore@cs.utk.edu> In-Reply-To: References: <20030121192758.13dc98f4.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > WHY do you need to have printers with routable, global addresses in all > cases? Normally, you don't. You might or might not want your printers to be potentially accessible from anywhere in the world (mine are and it really can be quite useful). But there's no real reason to assume that a printer need only be accessible from the local link. If I want to use my palm pilot with a CDMA connection to print a file from the workstation in my office, to a printer in the same room as I am, that's a very convenient and perfectly reasonable thing to do. Similarly, I often find myself sending print jobs to printers on remote subnets, because the printer can duplex, or print high-quality color. > So printers with LLv4 - only addressing actually > makes a fair bit of sense, especially behind a firewall and a NAT. Even that only makes sense if either the local link and the realm behind the NAT are identical, or the realm from which you want to be able to print happens to be some subset of the local link. > Again, HOW do you easily override the DHCP = OFF condition here? Devices that aren't explicitly configurable have to accept whatever the network tells them to do. If the network admin (whether by DHCP or some other mechanism) wants to tell different devices to do different things, based on their MAC addresses or whatever, that's his business. Of course the point isn't to insist that all devices be accessible from everywhere, but to avoid building limitations into devices that are unnecessary and which aren't a good match to users' needs. Keith From owner-zeroconf@merit.edu Tue Jan 21 23:00:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20748 for ; Tue, 21 Jan 2003 23:00:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BC0A291377; Tue, 21 Jan 2003 23:01:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6821F91378; Tue, 21 Jan 2003 23:01: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 94AFE91377 for ; Tue, 21 Jan 2003 23:01:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 06A605DDD0; Tue, 21 Jan 2003 23:01:21 -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 0B7A95DD96 for ; Tue, 21 Jan 2003 23:01:20 -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 h0M417jf007919; Wed, 22 Jan 2003 14:01:08 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id h0M415m02503; Wed, 22 Jan 2003 14:01:06 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Wed, 22 Jan 2003 14:01:05 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: "John C. Welch" Cc: Zeroconf Subject: Re: Turning off link-locals? 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: -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 Tue, 21 Jan 2003, John C. Welch wrote: >On 01/21/2003 19:27, "Keith Moore" wrote: >> - when should an IPv4LL address be configured by a host? >> >> suggest: if the host is explicitly configured to do so, OR >> if the host has attempted and failed to acquire a routable address via DHCP >> >> (alternative: provide a lighter weight mechanism by which a host can acquire >> a >> routable address, netmask, and default route, in response to its attempt to >> claim >> an IPv4LL address) > >Now, here's a monkey wrench, and a fairly logical one...printers... > >WHY do you need to have printers with routable, global addresses in all >cases? Normally, you don't. So printers with LLv4 - only addressing actually >makes a fair bit of sense, especially behind a firewall and a NAT. That is true, but I don't see anything in Keith's proposal that causes a problem with this. If you have a managed network (DHCP or manual) then you get to choose whether or not your printers are going to get global addresses. If you give them global addresses then they have no need of IPv4LL addresses (remember, visiting laptops and the like can still talk to them). If you don't give them global addresses then they will fail to acquire one and Keith's suggestion above allows them to acquire an IPv4LL address (and everything on the link can still talk to them). Perhaps I've missed something but I don't think there's a problem here. >Again, HOW do you easily override the DHCP = OFF condition here? The condition is `if you get a global address then don't get a local address too'. >This is NOT the simple conditional some think it is. If I've missed something, please explain more. Ian From owner-zeroconf@merit.edu Tue Jan 21 23:06:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20809 for ; Tue, 21 Jan 2003 23:06:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 510F99126D; Tue, 21 Jan 2003 23:09:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1290E9126E; Tue, 21 Jan 2003 23:09: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 027199126D for ; Tue, 21 Jan 2003 23:09:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id E38445DDD0; Tue, 21 Jan 2003 23:09:30 -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 F0BCF5DD96 for ; Tue, 21 Jan 2003 23:09:29 -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 h0M49Qjf008705 for ; Wed, 22 Jan 2003 14:09:27 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id h0M49OJ02531; Wed, 22 Jan 2003 14:09:24 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Wed, 22 Jan 2003 14:09:24 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: <20030121223310.3fc68000.moore@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 Tue, 21 Jan 2003, Keith Moore wrote: >> Again, HOW do you easily override the DHCP = OFF condition here? > >Devices that aren't explicitly configurable have to accept whatever the >network tells them to do. If the network admin (whether by DHCP or some other >mechanism) wants to tell different devices to do different things, based on >their MAC addresses or whatever, that's his business. IOW, along the lines of Subrata's earlier mail, there's a precedence: 1. Host configuration 2. Network configuration 3. Zero configuration Ian From owner-zeroconf@merit.edu Tue Jan 21 23:06:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20828 for ; Tue, 21 Jan 2003 23:06:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3362A9126E; Tue, 21 Jan 2003 23:09:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D65169126F; Tue, 21 Jan 2003 23:09: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 CFDA19126E for ; Tue, 21 Jan 2003 23:09:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC3205DDD0; Tue, 21 Jan 2003 23:09:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by segue.merit.edu (Postfix) with ESMTP id 8BBAB5DD96 for ; Tue, 21 Jan 2003 23:09:34 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bCCf-0005ns-00; Tue, 21 Jan 2003 20:09:29 -0800 Date: Tue, 21 Jan 2003 23:05:50 -0500 From: Keith Moore To: Ian Lister Cc: moore@cs.utk.edu, jwelch@MIT.EDU, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030121230550.6a77a5fd.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > >WHY do you need to have printers with routable, global addresses in all > >cases? Normally, you don't. So printers with LLv4 - only addressing > >actually makes a fair bit of sense, especially behind a firewall and a NAT. > > That is true, but I don't see anything in Keith's proposal that causes a > problem with this. If you have a managed network (DHCP or manual) then you > get to choose whether or not your printers are going to get global > addresses. If you give them global addresses then they have no need of > IPv4LL addresses (remember, visiting laptops and the like can still talk > to them). If you don't give them global addresses then they will fail to > acquire one and Keith's suggestion above allows them to acquire an IPv4LL > address (and everything on the link can still talk to them). more generally, you can give such devices whatever netmasks and default routes you want, so you can restrict their scope fairly flexibly. and you can of course filter their packets also, since you know which addresses you are assigning to which devices. it is *much* better to let the network decide the scope from which the device may be used than to encourage devices to assume that all networks are alike. Keith From owner-zeroconf@merit.edu Tue Jan 21 23:06:50 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20844 for ; Tue, 21 Jan 2003 23:06:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CD5079126F; Tue, 21 Jan 2003 23:09:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9517791378; Tue, 21 Jan 2003 23:09: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 6CBCA9126F for ; Tue, 21 Jan 2003 23:09:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9E38F5DDD0; Tue, 21 Jan 2003 23:09:52 -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 AD4465DD96 for ; Tue, 21 Jan 2003 23:09:51 -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 h0M49djf008711; Wed, 22 Jan 2003 14:09:39 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id h0M49bW02542; Wed, 22 Jan 2003 14:09:37 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Wed, 22 Jan 2003 14:09:37 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: Keith Moore Cc: zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: <20030121220151.5c48f44d.moore@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 Tue, 21 Jan 2003, Keith Moore wrote: >> > (alternative: provide a lighter weight mechanism by which a host can >> > acquire a >> > routable address, netmask, and default route, in response to its attempt >> > to claim an IPv4LL address) >> >> I'm not sure what this is aimed at, or what its purpose is over and above >> DHCP, but given that the first suggestion seems fine I won't dwell on it. > >the idea is to lower the implementation burden for fixed-function devices that >can't afford to dedicate much code space to address allocation, to minimize as >much as possible the split between routable and v4LL worlds, and to discourage >vendors from making devices that can only talk to hosts on the local link. I see. I thought it might be that, but I don't think we're going to get very far trying to create a new `lighter weight' DHCP or BOOTP to slip in between IPv4LL and DHCP/BOOTP (and nor would it be worth it IMO, given the simplicity of BOOTP). YMMV. >actually I disagree, because a v4LL source address might be used by the >destination host in a referral to another host which is not on the same link. >same reason as above - because it might be used by the destination in a >referral to another node. OK. I was trying to be tolerant of hosts that have only IPv4LL addresses but treat only 169.254.0.0/16 as being on the local link (and 0.0.0.0/0 as unroutable), but your consideration may be more widely applicable. >basically life is much simpler if: >a. every host on a managed network gets a routable address, and >b. hosts and apps avoid using scoped addresses whenever possible. Yes, I think I agree with that. Ian From owner-zeroconf@merit.edu Wed Jan 22 01:23:26 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22843 for ; Wed, 22 Jan 2003 01:23:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF30591203; Wed, 22 Jan 2003 01:26:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9325291271; Wed, 22 Jan 2003 01:26: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 76AB291203 for ; Wed, 22 Jan 2003 01:26:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5FC775DE78; Wed, 22 Jan 2003 01:26:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by segue.merit.edu (Postfix) with ESMTP id 212845E048 for ; Wed, 22 Jan 2003 01:26:41 -0500 (EST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 21 Jan 2003 22:26:40 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 21 Jan 2003 22:26:40 -0800 Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 21 Jan 2003 22:26:39 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3718.0); Tue, 21 Jan 2003 22:26:39 -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); Tue, 21 Jan 2003 22:26:39 -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.3718.0); Tue, 21 Jan 2003 22:26:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Turning off link-locals? Date: Tue, 21 Jan 2003 22:25:08 -0800 Message-ID: Thread-Topic: Turning off link-locals? Thread-Index: AcLBlMP2wsMrTN8+SQCTgW7JMqVmtQASVZn8 From: "Christian Huitema" To: "Daniel Senie" , "Zeroconf" X-OriginalArrivalTime: 22 Jan 2003 06:26:38.0829 (UTC) FILETIME=[386C61D0:01C2C1DF] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA22843 >>Determining if DHCP is present may take a while. For example, IP >>address autoconfiguration in Windows takes a few minutes to give up on >>DHCP and assign a LL address, which makes adhoc networking pretty >>unusable. The timeout could be configurable, but anything longer than a >>few seconds is a hassle. Is there a way to make this usable without >>immediately acquiring a LL address when a new interface is brought up? > >Windows (at least recent versions) appears to always assign a LL address >when an interface is brought up. If/when DHCP completes, the address is >replaced with the assigned address. The degree to which that address is >actually used by Windows while waiting for DHCP is unclear. Not really. Adam MacBeth is correct: Windows (including the recent versions) will first try to get a DHCP address for about 1 minute, and will only resign itself to use an autonet address after that. However, the Windows stack will keep looking for a DHCP server after that, trying to contact DHCP every few minutes. This is probably the behavior that Daniel observed, i.e. a Windows system that is using an autonet address, presumably after waiting 60 seconds to configure it, but that continues hunting for a DHCP server. -- Christian Huitema From owner-zeroconf@merit.edu Wed Jan 22 03:52:01 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19431 for ; Wed, 22 Jan 2003 03:52:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2B62D9120A; Wed, 22 Jan 2003 03:55:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F38A791213; Wed, 22 Jan 2003 03:55: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 DD1909120A for ; Wed, 22 Jan 2003 03:55:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id C2D2E5DE0E; Wed, 22 Jan 2003 03:55:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 5DB265DE0C for ; Wed, 22 Jan 2003 03:55:15 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 9E7FB598CA; Wed, 22 Jan 2003 08:55:15 +0000 (GMT) Message-ID: <001b01c2c1f3$fa32c480$131010ac@aldebaran> From: "Philip Nye" To: "Keith Moore" , "Zeroconf Working Group" References: <20030121192758.13dc98f4.moore@cs.utk.edu> <20030121220151.5c48f44d.moore@cs.utk.edu> Subject: Re: Turning off link-locals? Date: Wed, 22 Jan 2003 08:55:13 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Keith Moore" > > the idea is to lower the implementation burden for fixed-function devices that > can't afford to dedicate much code space to address allocation, to minimize as > much as possible the split between routable and v4LL worlds, and to discourage > vendors from making devices that can only talk to hosts on the local link. Keith, this is interesting. Is the idea that in response to an ARP probe claiming a new address, the Zeroconf device receives a message along the lines of "Don't use that one - use this one" along with a default route? Who would send the message? an "almost DHCP" server? Why is this lighter weight than BOOTP? What advantage does it have over BOOTP/DHCP? How does it scale? Philip From owner-zeroconf@merit.edu Wed Jan 22 04:31:33 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20256 for ; Wed, 22 Jan 2003 04:31:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D104E91213; Wed, 22 Jan 2003 04:34:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 868DE91217; Wed, 22 Jan 2003 04:34: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 7307191213 for ; Wed, 22 Jan 2003 04:34:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id E4D915DE0F; Wed, 22 Jan 2003 04:34:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 60D445DDFB for ; Wed, 22 Jan 2003 04:34:46 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0M9Y0R11002; Wed, 22 Jan 2003 16:34:01 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0M9Xc811194; Wed, 22 Jan 2003 20:33:43 +1100 (EST) From: Robert Elz To: Joshua Graessley Cc: Zeroconf Subject: Re: Turning off link-locals? In-Reply-To: <9D8E5D65-2D72-11D7-A610-000393760260@apple.com> References: <9D8E5D65-2D72-11D7-A610-000393760260@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Jan 2003 16:33:38 +0700 Message-ID: <11192.1043228018@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 21 Jan 2003 11:00:32 -0800 From: Joshua Graessley Message-ID: <9D8E5D65-2D72-11D7-A610-000393760260@apple.com> | Versions of Mac OS that support link-local will only acquire link local | addresses when configured to use DHCP and the DHCP server does not | respond. Various versions of the Mac OS will continue to send DHCP | requests. If a DHCP server does appear, the Mac will use the address | from the DHCP server but it will also continue to use the IPv4LL | address. The IPv4LL address is maintained to avoid unnecessarily | killing already established connections. If the "to avoid" is correct exactly as it reads (and I assume it is, as that is the easiest and simplest way to make this work) then that's exactly what is wanted I believe. That is, this is what the draft should say should happen. Why doesn't it now? | The Mac OS will watch for link changed events to determine if DHCP | should be tried again or the IPv4LL address assignment should occur | again. Again, that is both correct, and necessary, and (usually) pretty easy. | On the other hand, if my machine or some other device for whatever | reason can't get an address from DHCP, or if it doesn't implement DHCP, | then I'd like it get an IPv4LL address. Unless it is a human configurable device (in which case its vendor can decide to just let humans manage the addresses if it wants) it should implement DHCP. Otherwise it is simply useless on many networks. | I don't want my machine to | silently refuse to acquire an address because some guy in the dorm | playing a prank is sending out some magic packet to disable IPv4LL. In that case, you're going to have to start all over again with IPv4LL as the way it is currently proposed to work (and does work in those products that use it), this is impossible to achieve. | I don't think we need to design a special protocol either. If someone is | so disgusted with IPv4LL, they can write or use a utility that | conflicts with the ARP probes that IPv4LL addresses send before self | assigning an address. That will effectively eliminate IPv4LL on the | local link. Exactly. But as a recommended standard way of disabling IPv4LL, don't you think that's a bit crude? Given that you have demonstrated that there is a way that can't be defeated, that disables LL addresses, clearly those wanting to deny that such a method should be permitted now have to go away - the method exists whether they like it or not. The question now is whether that is the method that should be suggested, or whether a new one is better to suggest. Specifying the method you outlined above, along with a general recommendation that for any kind of low config IP node, client dhcp (or at a minimum, bootp) is really essential, seems like a much nicer, and cleaner, method than the ARP attack way of disabling v4LL - what's more, it allows your apps that acquired a LL address to keep function, the ARP attack method (if implemented to do so) would break that. | I think some people are hugely exaggerating the need for a way to | disable IPv4LL. To date, I'm not aware of any device shipped that will | acquire an IPv4LL address when a DHCP server is present or the device | is manually configured (or configured through bootp or some other | mechanism). That's fine - the problem is that the current draft says that that is what devices should do - that they should all go give themselves a LL address, in addition to anything they get from elsewhere. You should also be aware that the reason that (I think most of us) want a way to disable LL addresses, is not because we're worried about packets flying around on the LAN with some stray address in them - that's harmless (even the traffic doesn't matter, as one must assume that would be there with some address or other anyway). The reason that there's a desire to be able to disable LL addresses is because we know that they're simply not going to work well enough in the relevant environment to achieve anything at all - the user (or device) would be better to simply close down if it is unable to get some other address, rather than carry on in the hope that its LL address will somehow be useful for it. Other LANS aren't like that of course, and having a LL address might be useful there. This is why a method to disable them when the local network administrator knows that is best is the right thing to do. kre From owner-zeroconf@merit.edu Wed Jan 22 04:45:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20503 for ; Wed, 22 Jan 2003 04:45:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EDD8E91217; Wed, 22 Jan 2003 04:48:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 276D991271; Wed, 22 Jan 2003 04:48: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 98D1E91217 for ; Wed, 22 Jan 2003 04:46:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2531A5DE66; Wed, 22 Jan 2003 04:46:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 34FFE5DE23 for ; Wed, 22 Jan 2003 04:46:03 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0M9j8R12026; Wed, 22 Jan 2003 16:45:08 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0M9j0811217; Wed, 22 Jan 2003 20:45:00 +1100 (EST) From: Robert Elz To: "Christian Huitema" Cc: "Daniel Senie" , "Zeroconf" Subject: Re: Turning off link-locals? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Jan 2003 16:45:00 +0700 Message-ID: <11215.1043228700@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 21 Jan 2003 22:25:08 -0800 From: "Christian Huitema" Message-ID: | Not really. Adam MacBeth is correct: Windows (including the recent | versions) will first try to get a DHCP address for about 1 minute, And one assumes, that should there be lots of complaints about the time that is taking (compared to other things happening in parallel that people are waiting for anyway - virus scanners and such), then the amount of effort it would take to lower that minute to 10 seconds, or something, would not bankrupt Microsoft? (Ignoring distribution, those who want the mod can just fetch a patch). In the vast majority of cases, if you haven't received signs of DHCP server activity in a couple of seconds, you're not going to get any by waiting longer, or sending more requests. (Of course, once you have some evidence that a DHCP server is out there and responding, then you can take longer to complete the process in the unlikely case it is necessary). I guess that the reason for "1 minute" though, is so that a DHCP server can still be found if the system is connected to a switch that is going to run the spanning tree protocol (for 45 seconds) after the system initializes its LAN interface. If that's what it is about, then it is even more crucial that any LL address acquisition attempts also continue for about a minute (after LAN initialization) for the same reason - the node cannot possibly get back an "address in use" notification during the spanning tree interval. This suggests a minimum automatic configuration interval that can't really be reduced, no matter how much some people would like to have it complete as fast as possible. In fact, the draft should probably say that an LL address cannot be acquired within a minute of LAN initialization, precisely to avoid this problem. kre From owner-zeroconf@merit.edu Wed Jan 22 06:06:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21720 for ; Wed, 22 Jan 2003 06:06:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4E06491271; Wed, 22 Jan 2003 06:09:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19B4791272; Wed, 22 Jan 2003 06:09: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 F390091271 for ; Wed, 22 Jan 2003 06:09:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id CBE3D5DE00; Wed, 22 Jan 2003 06:09:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by segue.merit.edu (Postfix) with ESMTP id 669875DD91 for ; Wed, 22 Jan 2003 06:09:17 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0MBA2pM018412 for ; Wed, 22 Jan 2003 06:10:03 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn2-26.cisco.com [10.82.240.26]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA07718 for ; Wed, 22 Jan 2003 06:09:14 -0500 (EST) Message-Id: <4.3.2.7.2.20030122060343.00b82770@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Jan 2003 06:09:08 -0500 To: zeroconf@merit.edu From: Ralph Droms Subject: Re: Turning off link-locals? In-Reply-To: References: <20030121220151.5c48f44d.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Note that there already is a "lightweight DHCP" - the DHCPINFORM/DHCPACK message is a two-message exchange for use when the client does not need to acquire an IP address. This variation on DHCP requires no dynamic state on the part of either the client or the server. I've never seen a DHCPINFORM-only client or server, but I imagine those implementations would be *much* smaller than DHCP for address assignment. - Ralph At 02:09 PM 1/22/2003 +1000, Ian Lister wrote: >On Tue, 21 Jan 2003, Keith Moore wrote: > >> > (alternative: provide a lighter weight mechanism by which a host can > >> > acquire a > >> > routable address, netmask, and default route, in response to its > attempt > >> > to claim an IPv4LL address) > >> > >> I'm not sure what this is aimed at, or what its purpose is over and above > >> DHCP, but given that the first suggestion seems fine I won't dwell on it. > > > >the idea is to lower the implementation burden for fixed-function > devices that > >can't afford to dedicate much code space to address allocation, to > minimize as > >much as possible the split between routable and v4LL worlds, and to > discourage > >vendors from making devices that can only talk to hosts on the local link. > >I see. I thought it might be that, but I don't think we're going to get >very far trying to create a new `lighter weight' DHCP or BOOTP to slip in >between IPv4LL and DHCP/BOOTP (and nor would it be worth it IMO, given the >simplicity of BOOTP). YMMV. > > >actually I disagree, because a v4LL source address might be used by the > >destination host in a referral to another host which is not on the same > link. > > >same reason as above - because it might be used by the destination in a > >referral to another node. > >OK. I was trying to be tolerant of hosts that have only IPv4LL addresses >but treat only 169.254.0.0/16 as being on the local link (and 0.0.0.0/0 as >unroutable), but your consideration may be more widely applicable. > > >basically life is much simpler if: > >a. every host on a managed network gets a routable address, and > >b. hosts and apps avoid using scoped addresses whenever possible. > >Yes, I think I agree with that. > >Ian From owner-zeroconf@merit.edu Wed Jan 22 06:11:09 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21823 for ; Wed, 22 Jan 2003 06:11:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A68E891272; Wed, 22 Jan 2003 06:14:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 702FA91273; Wed, 22 Jan 2003 06:14: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 786C191272 for ; Wed, 22 Jan 2003 06:14:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5E1925DE5F; Wed, 22 Jan 2003 06:14: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 046D15DE00 for ; Wed, 22 Jan 2003 06:14: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 C336759895; Wed, 22 Jan 2003 11:14:24 +0000 (GMT) Message-ID: <009001c2c207$6ad70030$131010ac@aldebaran> From: "Philip Nye" To: "Robert Elz" , "Joshua Graessley" Cc: "Zeroconf" References: <9D8E5D65-2D72-11D7-A610-000393760260@apple.com> <11192.1043228018@munnari.OZ.AU> Subject: Re: Turning off link-locals? Date: Wed, 22 Jan 2003 11:14: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: "Robert Elz" > > | Versions of Mac OS that support link-local will only acquire link local > | addresses when configured to use DHCP and the DHCP server does not > | respond. Various versions of the Mac OS will continue to send DHCP > | requests. If a DHCP server does appear, the Mac will use the address > | from the DHCP server but it will also continue to use the IPv4LL > | address. The IPv4LL address is maintained to avoid unnecessarily > | killing already established connections. > > If the "to avoid" is correct exactly as it reads (and I assume it is, as > that is the easiest and simplest way to make this work) then that's > exactly what is wanted I believe. Is it feasible to mandate (or recommend) that where two addresses are present the OS always returns the global address to applications first? (e.g. in gethostbyname) so that where both are present the LL address is not used by the app unless it tries really hard. > | On the other hand, if my machine or some other device for whatever > | reason can't get an address from DHCP, or if it doesn't implement DHCP, > | then I'd like it get an IPv4LL address. > > Unless it is a human configurable device (in which case its vendor can > decide to just let humans manage the addresses if it wants) it should > implement DHCP. Otherwise it is simply useless on many networks. What does the machine do if the DHCP server is present but refuses it an address? This probably indicates that the network manager does not want this machine on the link. Philip From owner-zeroconf@merit.edu Wed Jan 22 07:20:33 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22705 for ; Wed, 22 Jan 2003 07:20:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 02A8F912D5; Wed, 22 Jan 2003 07:23:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C221A912D7; Wed, 22 Jan 2003 07:23: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 A6295912D5 for ; Wed, 22 Jan 2003 07:23:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8A6255DE8A; Wed, 22 Jan 2003 07:23:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 210815DE0F for ; Wed, 22 Jan 2003 07:23:46 -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 HAA13488 for ; Wed, 22 Jan 2003 07:23:45 -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 HAA08276 for ; Wed, 22 Jan 2003 07:23:45 -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 HAA00399 for ; Wed, 22 Jan 2003 07:23:44 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 07:23:43 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030121222044.2717af0d.moore@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 01/21/2003 22:20, "Keith Moore" wrote: >> Yes, actually. Because now, so that you avoid dictating behavior to network >> managers, you're dictating behavior to end users. So we need to decide who >> has priority for the standard, end users or network managers. > > my assumption is that we're specifying a default behavior in the absence of > explicit per-host configuration. IMHO it should be possible for explicit > per-host configuration to override essentially anything that can be obtained > by DHCP, because much of what is obtained through DHCP really doesn't have any > relationship to the location in the network. ...so you really aren't going to shut off LL if the user says, "Bugger off, I want it on". What's the default setting, allow pcDOS or don't allow pcDOS? If the human can easily override the pcDOS, *why bother* with pcDOS in the first place? It's a waste of time and packets. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 07:30:25 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22879 for ; Wed, 22 Jan 2003 07:30:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 43878912D7; Wed, 22 Jan 2003 07:33:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 12FA0912D8; Wed, 22 Jan 2003 07:33: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 95C74912D7 for ; Wed, 22 Jan 2003 07:32:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 688685DE8A; Wed, 22 Jan 2003 07:32:45 -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 F239F5DE00 for ; Wed, 22 Jan 2003 07:32:44 -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 HAA24112 for ; Wed, 22 Jan 2003 07:32:44 -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 HAA02433 for ; Wed, 22 Jan 2003 07:32:43 -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 HAA01118 for ; Wed, 22 Jan 2003 07:32:42 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 07:32:41 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030121223310.3fc68000.moore@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 01/21/2003 22:33, "Keith Moore" wrote: >> WHY do you need to have printers with routable, global addresses in all >> cases? Normally, you don't. > > You might or might not want your printers to be potentially accessible from > anywhere in the world (mine are and it really can be quite useful). I didn't say they weren't. I said it wasn't the majority case. It's *far* more common not to see this, and if you are dealing with chargebacks for IP addresses and whatnot, (again, not 100%, but rather common), LL - only printers do make a lot of sense. > But there's no real reason to assume that a printer need only be accessible > from the local link. If I want to use my palm pilot with a CDMA connection to > print a file from the workstation in my office, to a printer in the same room > as I am, that's a very convenient and perfectly reasonable thing to do. Right...because it's far easier than doing a sync and using Ethernet....I can write some AppleScripts that use the motion sensors in BTV to activate my WebCam to scan a document, pass it through an OCR app, then print it. But why make life harder. > Similarly, I often find myself sending print jobs to printers on remote > subnets, because the printer can duplex, or print high-quality color. Again, not questioning that. But, printer prices are coming down. You can get a high-res, color, duplexing printer for under $5K US. This is not an aberrant trend. But beside that, there are points for both methods of printing, and what I'm saying is, consider that an LL - only device would not be some bizarre abberation, but a common potential. > >> So printers with LLv4 - only addressing actually >> makes a fair bit of sense, especially behind a firewall and a NAT. > > Even that only makes sense if either the local link and the realm behind the > NAT are identical, or the realm from which you want to be able to print > happens to be some subset of the local link. I've dealt with a LOT of companies that have printers for each work group, and due to chargebacks, you aren't *allowed* to print on someone else's printer. Or if you work in a classified environment, you may only be able to print from your printer. It doesn't have to be something you or I use regularly. But it does happen, and we need to think about it. > >> Again, HOW do you easily override the DHCP = OFF condition here? > > Devices that aren't explicitly configurable have to accept whatever the > network tells them to do. If the network admin (whether by DHCP or some other > mechanism) wants to tell different devices to do different things, based on > their MAC addresses or whatever, that's his business. But earlier you said that it should be manually overridable...so again, What do you do about situations that don't fit your model? > > Of course the point isn't to insist that all devices be accessible from > everywhere, but to avoid building limitations into devices that are > unnecessary and which aren't a good match to users' needs. But you assume that global accessibility is always wanted or needed, and that simply isn't true. Most military organizations DON'T want this. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 07:32:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22928 for ; Wed, 22 Jan 2003 07:32:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0FB00912D8; Wed, 22 Jan 2003 07:36:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCE6C912D9; Wed, 22 Jan 2003 07:36:04 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C32BE912D8 for ; Wed, 22 Jan 2003 07:36:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id A43DB5DE8A; Wed, 22 Jan 2003 07:36:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 3B84E5DE88 for ; Wed, 22 Jan 2003 07:36: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 HAA15800 for ; Wed, 22 Jan 2003 07:36:02 -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 HAA08705 for ; Wed, 22 Jan 2003 07:36:02 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id HAA01461 for ; Wed, 22 Jan 2003 07:36:02 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 07:36:00 -0500 Subject: Re: Turning off link-locals? 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 01/21/2003 23:09, "Ian Lister" wrote: >> basically life is much simpler if: >> a. every host on a managed network gets a routable address, and >> b. hosts and apps avoid using scoped addresses whenever possible. > > Yes, I think I agree with that. But since reality shows that WON'T happen, we need to deal with *reality* not "What we dream about" john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 07:34:50 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22968 for ; Wed, 22 Jan 2003 07:34:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6F525912D9; Wed, 22 Jan 2003 07:38:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 42750912DA; Wed, 22 Jan 2003 07: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 22B55912D9 for ; Wed, 22 Jan 2003 07:38:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id F3BC25DE8A; Wed, 22 Jan 2003 07:38:05 -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 5A4635DF93 for ; Wed, 22 Jan 2003 07:38:04 -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 HAA16309 for ; Wed, 22 Jan 2003 07:38: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 HAA08632 for ; Wed, 22 Jan 2003 07:34:48 -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 HAA01320 for ; Wed, 22 Jan 2003 07:34:47 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 07:34:46 -0500 Subject: Re: Turning off link-locals? 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 01/21/2003 23:01, "Ian Lister" wrote: >> WHY do you need to have printers with routable, global addresses in all >> cases? Normally, you don't. So printers with LLv4 - only addressing actually >> makes a fair bit of sense, especially behind a firewall and a NAT. > > That is true, but I don't see anything in Keith's proposal that causes a > problem with this. If you have a managed network (DHCP or manual) then you > get to choose whether or not your printers are going to get global > addresses. If you give them global addresses then they have no need of > IPv4LL addresses (remember, visiting laptops and the like can still talk > to them). If you don't give them global addresses then they will fail to > acquire one and Keith's suggestion above allows them to acquire an IPv4LL > address (and everything on the link can still talk to them). Because you have a reason to not want the world to be able to get to your printers, so a LL - only device satisfies this need nicely. So they CAN'T get global addresses. Now, how do you deal with this case? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 07:38:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23005 for ; Wed, 22 Jan 2003 07:38:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2780A912DA; Wed, 22 Jan 2003 07:41:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D66A8912DB; Wed, 22 Jan 2003 07:41: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 C8F7B912DA for ; Wed, 22 Jan 2003 07:41:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id B1BD65E094; Wed, 22 Jan 2003 07:41:20 -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 494395DF93 for ; Wed, 22 Jan 2003 07:41:20 -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 HAA17140 for ; Wed, 22 Jan 2003 07:41: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 HAA09004 for ; Wed, 22 Jan 2003 07:41:18 -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 HAA01985 for ; Wed, 22 Jan 2003 07:41:18 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 07:41:16 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <11192.1043228018@munnari.OZ.AU> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 01/22/2003 04:33, "Robert Elz" wrote: > Unless it is a human configurable device (in which case its vendor can > decide to just let humans manage the addresses if it wants) it should > implement DHCP. Otherwise it is simply useless on many networks. Because I don't want to *have* to buy a DHCP device on a two node network. Maybe I bought a cheapie little networkable inkjet, and all I have is my laptop. I've got a little dumb switch, but not a cable modem router, because I don't feel I need one. (Hypothetically). I don't *want* to pay for my printer to have an IP address from my ISP, just my computer. But since my computer is using DHCP under your schemes, I now *have* to buy a router with DHCP capability, because my computer will not use v4LL, since it has a global address. Great...so now I have to set up a DHCP server on the internal interface, configure the external interface, I HAVE to use NAT, probably set up the router I HAD to buy to spoof the MAC address of my computer on the external interface... This is simpler? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 07:45:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23125 for ; Wed, 22 Jan 2003 07:45:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5BDF2912DD; Wed, 22 Jan 2003 07:48:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 22897912DB; Wed, 22 Jan 2003 07:48: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 69F85912DC for ; Wed, 22 Jan 2003 07:48:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4EA625DE8A; Wed, 22 Jan 2003 07:48:36 -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 E34CA5DD91 for ; Wed, 22 Jan 2003 07:48:35 -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 DC1BC598AA; Wed, 22 Jan 2003 12:48:32 +0000 (GMT) Message-ID: <00aa01c2c214$912fab30$131010ac@aldebaran> From: "Philip Nye" To: "John C. Welch" , "Zeroconf" References: Subject: Re: Turning off link-locals? Date: Wed, 22 Jan 2003 12:48:30 -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: "John C. Welch" > > Because you have a reason to not want the world to be able to get to your > printers, so a LL - only device satisfies this need nicely. So they CAN'T > get global addresses. > > Now, how do you deal with this case? You hand them a scoped address, or you only allow them to acquire a LL address, or you configure your routers so they can't get in/out, or... In none of these cases is it necessary that the printer is LL only by design. As a designer of small embedded devices, I know that I cannot afford to make my devices only accessible on the local link by design - that is far too restrictive for them to have much market. I AM interested in having them as easily configured as possible and if they are likely to required to be accessible only on the local link then I will try to ensure that this option is _easily_ configured either at the host or at the network level or probably both. Philip From owner-zeroconf@merit.edu Wed Jan 22 07:46:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23141 for ; Wed, 22 Jan 2003 07:46:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 44878912DB; Wed, 22 Jan 2003 07:49:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3AA1912DC; Wed, 22 Jan 2003 07:49: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 D8240912DB for ; Wed, 22 Jan 2003 07:49:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id C64355DE92; Wed, 22 Jan 2003 07:49:15 -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 CC5285DE8A for ; Wed, 22 Jan 2003 07:49:14 -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 h0MCmmjf017848; Wed, 22 Jan 2003 22:49:00 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id h0MCmOK03615; Wed, 22 Jan 2003 22:48:39 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Wed, 22 Jan 2003 22:48:23 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: "John C. Welch" Cc: Zeroconf Subject: Re: Turning off link-locals? 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: -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 Wed, 22 Jan 2003, John C. Welch wrote: >On 01/22/2003 04:33, "Robert Elz" wrote: >> Unless it is a human configurable device (in which case its vendor can >> decide to just let humans manage the addresses if it wants) it should >> implement DHCP. Otherwise it is simply useless on many networks. > >Because I don't want to *have* to buy a DHCP device on a two node network. >Maybe I bought a cheapie little networkable inkjet, and all I have is my >laptop. I've got a little dumb switch, but not a cable modem router, because >I don't feel I need one. (Hypothetically). I don't *want* to pay for my >printer to have an IP address from my ISP, just my computer. > >But since my computer is using DHCP under your schemes, I now *have* to buy >a router with DHCP capability, because my computer will not use v4LL, since >it has a global address. Great...so now I have to set up a DHCP server on >the internal interface, configure the external interface, I HAVE to use NAT, >probably set up the router I HAD to buy to spoof the MAC address of my >computer on the external interface... > >This is simpler? He said these devices should implement DHCP, not that they should do nothing else except DHCP. Nobody is saying you should have to have a DHCP server on a network - that's the whole point of zeroconf! Ian From owner-zeroconf@merit.edu Wed Jan 22 07:47:56 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23158 for ; Wed, 22 Jan 2003 07:47:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3981D912DC; Wed, 22 Jan 2003 07:51:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04DF7912DE; Wed, 22 Jan 2003 07:51: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 EB352912DC for ; Wed, 22 Jan 2003 07:51:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id D11945DE94; Wed, 22 Jan 2003 07:51:04 -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 D7DE15DE92 for ; Wed, 22 Jan 2003 07:51:03 -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 h0MConjf017956 for ; Wed, 22 Jan 2003 22:50:57 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id h0MColQ03633; Wed, 22 Jan 2003 22:50:47 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Wed, 22 Jan 2003 22:50:46 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: zeroconf@merit.edu Subject: Re: Turning off link-locals? 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: -0.1, 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 Wed, 22 Jan 2003, John C. Welch wrote: >Because you have a reason to not want the world to be able to get to your >printers, so a LL - only device satisfies this need nicely. So they CAN'T >get global addresses. OK, that's fine. Not exactly a common case (most people would just filter printer traffic at the firewall if they didn't want them to be world-accessible), but let's consider it. >Now, how do you deal with this case? Either configure your DHCP server to not assign an address to your printers (in which case they will fail to acquire an address by any other means and fall back to IPv4LL, still able to communicate with the other hosts on the link), or configure the printers to not do DHCP (and only do IPv4LL). Pretty much the same as how it works now if you don't want your printers to acquire an IP address at all (perhaps to only do IPX/AppleTalk/whatever). Ian From owner-zeroconf@merit.edu Wed Jan 22 07:53:48 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23402 for ; Wed, 22 Jan 2003 07:53:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2DFCB912DE; Wed, 22 Jan 2003 07:57:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF7CB912DF; Wed, 22 Jan 2003 07:57:04 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DFB50912DE for ; Wed, 22 Jan 2003 07:57:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id C62115DE92; Wed, 22 Jan 2003 07:57:03 -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 693315DE8A for ; Wed, 22 Jan 2003 07:57:03 -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 9F0E7598C7; Wed, 22 Jan 2003 12:57:04 +0000 (GMT) Message-ID: <00b001c2c215$c2312e60$131010ac@aldebaran> From: "Philip Nye" To: "John C. Welch" , "Zeroconf" References: Subject: Re: Turning off link-locals? Date: Wed, 22 Jan 2003 12:57:02 -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: "John C. Welch" > > > Unless it is a human configurable device (in which case its vendor can > > decide to just let humans manage the addresses if it wants) it should > > implement DHCP. Otherwise it is simply useless on many networks. > > Because I don't want to *have* to buy a DHCP device on a two node network. > Maybe I bought a cheapie little networkable inkjet, and all I have is my > laptop. I've got a little dumb switch, but not a cable modem router, because > I don't feel I need one. (Hypothetically). I don't *want* to pay for my > printer to have an IP address from my ISP, just my computer. > > But since my computer is using DHCP under your schemes, I now *have* to buy > a router with DHCP capability, because my computer will not use v4LL, since > it has a global address. Great...so now I have to set up a DHCP server on > the internal interface, configure the external interface, I HAVE to use NAT, > probably set up the router I HAD to buy to spoof the MAC address of my > computer on the external interface... There appears to be a misunderstanding here. With the proposed scheme, your computer and the cheapie printer do not find a DHCP server and so assign themselves a LL address. They then talk nicely. Even if the computer has a manually assigned global address it is "LL aware" and so knows to ARP for the printer. Similarly the draft currently describes how the printer can talk to the computer. The obligation is simply to look for a DHCP server not to provide one. Philip From owner-zeroconf@merit.edu Wed Jan 22 08:09:09 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23806 for ; Wed, 22 Jan 2003 08:09:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5B0C4912DF; Wed, 22 Jan 2003 08:12:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 18299912E0; Wed, 22 Jan 2003 08:12: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 E01BC912DF for ; Wed, 22 Jan 2003 08:12:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id C2F565DE99; Wed, 22 Jan 2003 08:12:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by segue.merit.edu (Postfix) with ESMTP id 9BA4B5DE95 for ; Wed, 22 Jan 2003 08:12:24 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bKg2-0004Sv-00; Wed, 22 Jan 2003 05:12:22 -0800 Date: Wed, 22 Jan 2003 08:08:41 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030122080841.2aa92a62.moore@cs.utk.edu> In-Reply-To: <001b01c2c1f3$fa32c480$131010ac@aldebaran> References: <20030121192758.13dc98f4.moore@cs.utk.edu> <20030121220151.5c48f44d.moore@cs.utk.edu> <001b01c2c1f3$fa32c480$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Wed, 22 Jan 2003 08:55:13 -0000 "Philip Nye" wrote: > > From: "Keith Moore" > > > > the idea is to lower the implementation burden for fixed-function devices > > that can't afford to dedicate much code space to address allocation, to > > minimize as much as possible the split between routable and v4LL worlds, and to > > discourage vendors from making devices that can only talk to hosts on the local link. > > Keith, this is interesting. > > Is the idea that in response to an ARP probe claiming a new address, the > Zeroconf device receives a message along the lines of "Don't use that one - > use this one" along with a default route? > > Who would send the message? an "almost DHCP" server? Why is this lighter > weight than BOOTP? What advantage does it have over BOOTP/DHCP? How does it > scale? I haven't had time to sit down and compare them yet. Keith From owner-zeroconf@merit.edu Wed Jan 22 08:15:46 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24253 for ; Wed, 22 Jan 2003 08:15:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 74E769121A; Wed, 22 Jan 2003 08:19:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1BD9B912E0; Wed, 22 Jan 2003 08:19: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 CCF9F9121A for ; Wed, 22 Jan 2003 08:19:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id B8D825DE95; Wed, 22 Jan 2003 08:19:01 -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 7CD7C5DE8A for ; Wed, 22 Jan 2003 08:19:01 -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 h0MDIwJ32749 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Wed, 22 Jan 2003 08:18:59 -0500 Message-Id: <5.2.0.9.2.20030122075607.02db8318@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 22 Jan 2003 08:07:22 -0500 To: "s. goswami" From: Daniel Senie Subject: Re: Turning off link-locals? Cc: zeroconf@merit.edu In-Reply-To: References: <5.2.0.9.2.20030121211404.0275bdc0@mail.amaranth.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 09:31 PM 1/21/2003, s. goswami wrote: >see inline > >On Tue, 21 Jan 2003, Daniel Senie wrote: > > > At 09:02 PM 1/21/2003, s. goswami wrote: > > > > > > >Yes, using DHCP for 169.254/16 is not necessary. What are > > >the pitfalls if one wishes to do so ? > > > > Addresses in 169.254/16 are self-assigned, using claim and defend. > > > > DHCP servers need not be attached to the segment or subnet on which they're > > handing out addresses (e.g. DHCP Relay in use). As such, the DHCP server > > has no way to know which addresses are in use on a subnet where stations > > self assign addresses. Even if the DHCP server were on the same subnet, IT > > would have to do the claim and defend for all addresses it handed out. This > > is not wise. > > > >the DHCP server is supposed to ping (ICMP) the address before handing it >out (takes IT out of the loop). Two problems I see with this: 1. A ping is NOT equivalent or compatible with what this draft requires for claim and DEFEND. Note my emphasis on the latter part. If the DHCP server is providing the address, the DHCP client generally expects it will get to keep that address. So if an LL host comes up and chooses the same address, will the DHCP client defend itself? Should it have to? Isn't the station (DHCP Server) which made the allocation responsible for ensuring the address is (AND REMAINS) available for that station? Please read section 1.4 of the LL draft and explain how and why you think thia is in error. 2. It is possible for a DHCP server to functionally hand out addresses on a network which it cannot reach via routed packets. Since DHCP Relay is a function of intervening routers, there's the possibility it would not be able to ping the remote lan where the allocation is being made. Whether this violates the DHCP specs or not is not entirely clear to me without doing some research. Fundamentally, I fail to see why you're harping on this issue in the first place. Why do you want a DHCP server handing out 169.254/16 addresses at all? What value or benefit do you see in this? If it's to try and give out addresses that are in the same IP Subnet as LL addresses, so that LL and non-LL can talk, there could almost be merit there, but since the DHCP servers will more often NOT give out such addresses, the problem of intercommunication must still be solved. Also note that the first 256 and last 256 addresses in 169.254/16 are reserved for future IETF standards work. If there were a compelling reason to permit DHCP to allocate anywhere in 169.254/16, it would be into one of these two blocks, but would also require an IETF Standards Track document. > > So, it's important that DHCP servers NEVER hand out addresses in LL space. > > > > > > > > >On Wed, 22 Jan 2003, Ian Lister wrote: > > > > > > > On Tue, 21 Jan 2003, s. goswami wrote: > > > > >So a relevant question is can LL coexist with DHCP/Manual ? > > > > > > > > > >1. In different subnets (or physical link). Absolutely. > > > > >2. In the same physical link (i.e. mix 169.254/16 with say > 192.168/16 )? > > > > > A 169.254 interface can talk to a 192.168 host sitting on the same > > > > > physical link without a router. DHCP servers can handout > 169.254/16 > > > > > addresses if they want. > > > > > > > > I'm not quite sure what you're driving at, but yes, IPvLL can > coexist with > > > > non-IPv4LL on the same link and can communicate with each other. > > > > However, configuring a DHCP server to hand out IPv4LL addresses > seems like > > > > a distinctly bad idea. > > > > > > > > Ian > > > > > > From owner-zeroconf@merit.edu Wed Jan 22 09:26:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25550 for ; Wed, 22 Jan 2003 09:26:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DF464912E3; Wed, 22 Jan 2003 09:29:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0612912E4; Wed, 22 Jan 2003 09:29: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 B8FC0912E3 for ; Wed, 22 Jan 2003 09:29:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9F36E5DE59; Wed, 22 Jan 2003 09:29:51 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 230D05DE5C for ; Wed, 22 Jan 2003 09:29:50 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0METWR26844; Wed, 22 Jan 2003 21:29:32 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0MET3812412; Thu, 23 Jan 2003 01:29:04 +1100 (EST) From: Robert Elz To: "Philip Nye" Cc: "Joshua Graessley" , "Zeroconf" Subject: Re: Turning off link-locals? In-Reply-To: <009001c2c207$6ad70030$131010ac@aldebaran> References: <009001c2c207$6ad70030$131010ac@aldebaran> <9D8E5D65-2D72-11D7-A610-000393760260@apple.com> <11192.1043228018@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Jan 2003 21:29:03 +0700 Message-ID: <12410.1043245743@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 22 Jan 2003 11:14:22 -0000 From: "Philip Nye" Message-ID: <009001c2c207$6ad70030$131010ac@aldebaran> | Is it feasible to mandate (or recommend) that where two addresses are | present the OS always returns the global address to applications first? I suspect that would be a good idea. That or strike "first" from that. | (e.g. in gethostbyname) but it seems a little unlikely that gethostbyname() would ever encounter the situation. LL addresses in the DNS are a horrid idea, for the same reason that IPv6 SL addresses there are. LL addresses in even less dynamic databases (/etc/hosts, NIS, ...) would be a nightmare (how do they get there?) So, it is likely that LL addresses will only ever be discovered via some mechanism like mDNS. Then it is up to the owner of the address to decide what to return, and if there's a global address, I'd suggest, returning just that is optimal. | so that where both are present the LL address is not | used by the app unless it tries really hard. The harder problem isn't which address for a remote system gets used, but which of my addresses gets used when I have both. And for that we need to consider both active and passive socket opens (ie: connect & bind/listen) | What does the machine do if the DHCP server is present but refuses it an | address? This probably indicates that the network manager does not want this | machine on the link. Squawk, flash its red led, and emit liquids in small drops down its front panel... If it isn't supposed to be on the link, then it shouldn't automatically put itself there (if some human wants to explicitly configure it to exist there, if that is possible for the device in question, then that person takes responsibility for that). To get it to work, either it would need to be moved to a new link, or the network manager would need to permit it to get an address. Either of those may be appropriate in different circumstances. kre From owner-zeroconf@merit.edu Wed Jan 22 09:34:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25730 for ; Wed, 22 Jan 2003 09:34:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2D462912E4; Wed, 22 Jan 2003 09:37:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2DCE912E5; Wed, 22 Jan 2003 09:37: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 E5125912E4 for ; Wed, 22 Jan 2003 09:37:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id CCA485DE9A; Wed, 22 Jan 2003 09:37:46 -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 57A045DE5C for ; Wed, 22 Jan 2003 09:37:46 -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 JAA02403 for ; Wed, 22 Jan 2003 09:37:45 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA15156 for ; Wed, 22 Jan 2003 09:37:45 -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 JAA00922 for ; Wed, 22 Jan 2003 09:37:44 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 09:37:42 -0500 Subject: Re: Turning off link-locals? 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 01/22/2003 07:45, "Ian Lister" wrote: > Either configure your DHCP server to not assign an address to your > printers (in which case they will fail to acquire an address by any other > means and fall back to IPv4LL, still able to communicate with the other > hosts on the link), or configure the printers to not do DHCP (and only do > IPv4LL). Pretty much the same as how it works now if you don't want your > printers to acquire an IP address at all (perhaps to only do > IPX/AppleTalk/whatever). > But since my computers all have DHCP addresses, v4LL is now disabled on all of them, so pray tell, exactly how do they talk to the v4LL device? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 09:36:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25771 for ; Wed, 22 Jan 2003 09:36:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 877EA912E5; Wed, 22 Jan 2003 09:39:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 528A8912E6; Wed, 22 Jan 2003 09:39: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 44D05912E5 for ; Wed, 22 Jan 2003 09:39:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2BF075DE95; Wed, 22 Jan 2003 09:39:58 -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 B69DE5DE5C for ; Wed, 22 Jan 2003 09:39:57 -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 JAA03368 for ; Wed, 22 Jan 2003 09:39: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 JAA15620 for ; Wed, 22 Jan 2003 09:39:57 -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 JAA01958 for ; Wed, 22 Jan 2003 09:39:56 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 09:39:53 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <00aa01c2c214$912fab30$131010ac@aldebaran> 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 01/22/2003 07:48, "Philip Nye" wrote: > You hand them a scoped address, or you only allow them to acquire a LL > address, or you configure your routers so they can't get in/out, or... > > In none of these cases is it necessary that the printer is LL only by > design. But what about when it happens. Or some other device that we don't know about yet? Maybe a home MP3 server? > > As a designer of small embedded devices, I know that I cannot afford to make > my devices only accessible on the local link by design - that is far too > restrictive for them to have much market. Okay, that's you. > > I AM interested in having them as easily configured as possible and if they > are likely to required to be accessible only on the local link then I will > try to ensure that this option is _easily_ configured either at the host or > at the network level or probably both. By disabling v4LL in the face of any and all other configuration mechanisms, you are now *forcing* everyone with a small home network to buy a DHCP server of some kind. Great, that's so much easier. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 09:40:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25871 for ; Wed, 22 Jan 2003 09:40:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B333912E6; Wed, 22 Jan 2003 09:43:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A962912E7; Wed, 22 Jan 2003 09:43: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 BAF7D912E6 for ; Wed, 22 Jan 2003 09:43:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id A2D865DF87; Wed, 22 Jan 2003 09:43:56 -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 36CF75DE9C for ; Wed, 22 Jan 2003 09:43:56 -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 JAA28574 for ; Wed, 22 Jan 2003 09:43:55 -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 JAA16402 for ; Wed, 22 Jan 2003 09:43:55 -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 JAA03647 for ; Wed, 22 Jan 2003 09:43:54 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 09:43:52 -0500 Subject: Re: Turning off link-locals? 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 01/22/2003 07:48, "Ian Lister" wrote: > He said these devices should implement DHCP, not that they should do > nothing else except DHCP. Nobody is saying you should have to have a DHCP > server on a network - that's the whole point of zeroconf! BUT...you are ALSO saying that if *any* other address configuration mechanism is present, then v4LL is *turned off*. So that means, that to work in this environment, EVERY device HAS to support both DHCP and manual addressing...and bootp too. Which means that if your ISP uses manual or DHCP configuration, then your computer will not use v4LL. That means that you either get additional addresses from your ISP, and have every device on your system globally visible, OR, you buy a little home router, set up your own DHCP server...which is NO different than it is now. Maybe Keith's right, but for a different reason. The IETF should just leave this stuff alone. You don't seem to get why it's important. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 09:41:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25896 for ; Wed, 22 Jan 2003 09:41:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 72EF7912E7; Wed, 22 Jan 2003 09:44:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1FB35912E8; Wed, 22 Jan 2003 09:44: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 EB20A912E7 for ; Wed, 22 Jan 2003 09:44:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id D47385DF87; Wed, 22 Jan 2003 09:44:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 3E8735DE9C for ; Wed, 22 Jan 2003 09:44:07 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0MEhQR27608; Wed, 22 Jan 2003 21:43:26 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0MEh9812434; Thu, 23 Jan 2003 01:43:12 +1100 (EST) From: Robert Elz To: "John C. Welch" Cc: Zeroconf Subject: Re: Turning off link-locals? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Jan 2003 21:43:09 +0700 Message-ID: <12432.1043246589@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 22 Jan 2003 07:41:16 -0500 From: "John C. Welch" Message-ID: I have no idea why I am replying to you - you have constantly shown a complete inability to even attempt to understand what anyone else is saying, and an almost complete lack of understanding of how networks actually work - and Ian Lister and Philip Nye have already done a pretty good job of answering, but ... | Because I don't want to *have* to buy a DHCP device on a two node network. When did anyone ever say that you had to? If there's no DHCP server you won't get a DHCP response, nothing will disable LL addresses, and you'll just go and allocate yourself one. | But since my computer is using DHCP under your schemes, Huh? How is it doing that? Do you mean that is attempting to get an address via DHCP ("using DHCP") or that it is actually obtaining one? I assume obtaining one from ... | I now *have* to buy a router with DHCP capability, Huh, why? | because my computer will not use v4LL, since it has a global address. If it has its global address, why would it possibly need a v4LL addr? One address is enough for (just about) any (singly-homed) system, and the global one will allow it to talk to everyone (including your other device that has only v4LL). You're imagining all kinds of absurdities that simply don't exist. I suspect (though you didn't actually make it clear) that you are connected directly to your ISP, both your printer and computer are connected to the ISP's LAN, so all your printer's noise packets are being dumped on the ISP (but you're refusing to pay the ISP anything for that) the ISP will allocate you one address for your computer via DHCP, but will refuse to give your printer a global address, is that the scenario? If that's it, then why would the ISP also be telling your LAN to disable LL addresses? Whether the "default" state is "DHCP server implies no LL" or whether a DHCP option is required to disable LL (either way is fine, and each has advantages and disadvantages), the ISP isn't going to care that you have other stuff out there that doesn't connect through them. So, why would they be disabling your LL addresses (or not enabling them if that's what it takes). If you just have a cantankerous ISP, you switch to another right? The ISP wants to minimise customer help calls - they'll do whatever config is going to make that happen, and stopping v4LL from working on their customers' private LANS isn't going to achieve that aim, is it? So, why? kre From owner-zeroconf@merit.edu Wed Jan 22 09:45:09 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26012 for ; Wed, 22 Jan 2003 09:45:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 58F3A912E8; Wed, 22 Jan 2003 09:45:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A251912EA; Wed, 22 Jan 2003 09:45: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 2CD07912E8 for ; Wed, 22 Jan 2003 09:45:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id A257A5DEA9; Wed, 22 Jan 2003 09:45:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130]) by segue.merit.edu (Postfix) with ESMTP id 9520E5DE9C for ; Wed, 22 Jan 2003 09:45:41 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e32.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0MEjeGC059710 for ; Wed, 22 Jan 2003 09:45:40 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-244-157.mts.ibm.com [9.65.244.157]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0MEiOFS092952 for ; Wed, 22 Jan 2003 07:44:24 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h0MEi3210690 for ; Wed, 22 Jan 2003 09:44:08 -0500 Message-Id: <200301221444.h0MEi3210690@cichlid.adsl.duke.edu> To: zeroconf@merit.edu Subject: AD to zeroconf WG Date: Wed, 22 Jan 2003 09:44:03 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk AD hat on. This WG has been going around in circles for months, having many yes/no much-heat-little-light rathole discussions. In particular: Alex Karahalios writes: > P.S. I would participate in these discussion more, but I am already > several months behind in my development work. I was hoping that these > v4LL issues would have blown over by now. I guess this IETF > standardization is a slow process. The good news is that nothing has > changed in the draft in the last 4 months that would require my > changing any of my code. This says it all. There are a number of outstanding issues with the LL document, including specific IESG comments. My belief is that none of these issues are show-stoppers. However, rather than try to address those issues, and despite attempts by the chairs to get closure on specific text, the WG fails to respond or participate, chosing instead to rathole and discuss things that are not directly related to getting closure on the documents. If folks are unwilling to focus on the open isssues and actually try to resolve them (which means talking about specific document text changes), the document will never get finished. That's a shame, as the document is 98% there and contains useful stuff. If the WG isn't willing to focus getting the LL document finished, I suspect it's time to just give up and close the WG. Surely, many of you are aware of discussions on the overall (in)effectiveness of the IETF on, e.g., the problem-statement list. This WG is a prime example of a WG that is not working, and hasn't been working for a long time. There are lots of reasons for that, but its probably not productive to discuss them here. Shall we try to complete the tasks at hand, or should we just give up? PS, actions speak louder then words. The best response would be to particpate in coming to closure. Thomas From owner-zeroconf@merit.edu Wed Jan 22 09:45:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26033 for ; Wed, 22 Jan 2003 09:45:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 388E0912EB; Wed, 22 Jan 2003 09:48:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 01C14912EC; Wed, 22 Jan 2003 09:48: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 C5997912EB for ; Wed, 22 Jan 2003 09:48:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id EFE985DE9A; Wed, 22 Jan 2003 09:48:33 -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 868F85DDC6 for ; Wed, 22 Jan 2003 09:48:32 -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 JAA00662 for ; Wed, 22 Jan 2003 09:48:32 -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 JAA17438 for ; Wed, 22 Jan 2003 09:48:32 -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 JAA05924 for ; Wed, 22 Jan 2003 09:48:31 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 09:48:28 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <00b001c2c215$c2312e60$131010ac@aldebaran> 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 01/22/2003 07:57, "Philip Nye" wrote: > > With the proposed scheme, your computer and the cheapie printer do not find > a DHCP server and so assign themselves a LL address. They then talk nicely. That's only if you have a home network with no form of public internet connection. This is really not going to be common. > > Even if the computer has a manually assigned global address it is "LL aware" > and so knows to ARP for the printer. Similarly the draft currently describes > how the printer can talk to the computer. No, because everything I've seen says, "In the face of any other configuration methodology, disable v4LL" Now, disabled is rather clear. It means off. Off is off. Not sort of on, not kind of on, but off. You cannot use a v4LL address, because it is disabled. You can ARP for anything, but since v4LL is disabled, you can't talk to that device. > > The obligation is simply to look for a DHCP server not to provide one. Right...now, show me an ISP that doesn't require you to configure a device with some form of addressing. v4LL will *always* be off. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 09:45:53 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26046 for ; Wed, 22 Jan 2003 09:45:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B269C912EA; Wed, 22 Jan 2003 09:46:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7CD3912EB; Wed, 22 Jan 2003 09: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 34396912EA for ; Wed, 22 Jan 2003 09:45:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9DC5D5DEA9; Wed, 22 Jan 2003 09:45:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by segue.merit.edu (Postfix) with ESMTP id B221B5DF87 for ; Wed, 22 Jan 2003 09:45:45 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0MEjil9039640; Wed, 22 Jan 2003 09:45:44 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-244-157.mts.ibm.com [9.65.244.157]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0MEjhFS104594; Wed, 22 Jan 2003 07:45:44 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h0MEjSR10944; Wed, 22 Jan 2003 09:45:28 -0500 Message-Id: <200301221445.h0MEjSR10944@cichlid.adsl.duke.edu> To: "John C. Welch" Cc: Zeroconf Subject: LL-only devices [was Re: Turning off link-locals?] In-Reply-To: Message from jwelch@MIT.EDU of "Tue, 21 Jan 2003 22:15:19 EST." Date: Wed, 22 Jan 2003 09:45:28 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk "John C. Welch" writes: > WHY do you need to have printers with routable, global addresses in all > cases? Because this is the norm today, it works, and we understand it's limitations. There are fewer problems in general if a device has a global address. LL addresses only work in limited circumstances -- namely, on a single link. > Normally, you don't. So printers with LLv4 - only addressing actually > makes a fair bit of sense, especially behind a firewall and a NAT. (Yes, > keith, we KNOW how you feel about NAT, but they exist, so sticking fingers > in ears and yelling loudly won't change that). You are making a bunch of assumptions here that I don't think generalize, and I suspect we do not want to mandate or suggest is The Right Way for the future. Recall, LL addresses only work on a single link. If a printer has only a LL address, one can no longer print on it from behind a router. This may not be a limitation in typical home networks *today*, but certainly is in small offices, and future homes. Thus, we need to be very careful about encouraging such a direction for the future. I'd be rather suprised of printer (and other small device) vendors thought it made business sense to not implement DHC on the client. I do not believe this WG should be legitimizing LL-only hosts. If vendors want to ship such devices, we can't stop them, but blessing such behavior, and encouraging it *in* *general* is also not something we need to allow. General comment: there is a long history of folk wanting to "simplify" TCP/IP for a device with limited capabilities. That is not the goal of this WG. It might be a fine topic for a different WG. But it is not in the charter for this WG. On the other hand, when looking at limited functionality devices, the IETF has historically said, after getting to the underlying technical issues, "the arguments about limited code space, etc. are bogus, you need to implement full TCP/IP". For example, crying that DHCP is too expensive to implement in a small device that also includes TCP/HTTP and a limited web server (e.g., for configuration) just doesn't sway a lot of folk. Or for a printer that implements the IPP protocols (no lean-and-mean protocol). But again, that topic is a distraction for this WG. Thomas From owner-zeroconf@merit.edu Wed Jan 22 09:47:19 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26126 for ; Wed, 22 Jan 2003 09:47:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D74CC912EC; Wed, 22 Jan 2003 09:50:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 963EF912ED; Wed, 22 Jan 2003 09:50: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 3FC84912EC for ; Wed, 22 Jan 2003 09:50:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E0CA5DE9A; Wed, 22 Jan 2003 09:50:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by segue.merit.edu (Postfix) with ESMTP id 829F65DDC6 for ; Wed, 22 Jan 2003 09:50:27 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0MEoNSf036928 for ; Wed, 22 Jan 2003 09:50:23 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-244-157.mts.ibm.com [9.65.244.157]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0MEoHFS061882 for ; Wed, 22 Jan 2003 07:50:17 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h0MEo2l11224 for ; Wed, 22 Jan 2003 09:50:02 -0500 Message-Id: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> To: zeroconf@merit.edu Subject: WG decision: when to configure LL addrs In-Reply-To: Message from moore@cs.utk.edu of "Tue, 21 Jan 2003 19:27:58 EST." <20030121192758.13dc98f4.moore@cs.utk.edu> Date: Wed, 22 Jan 2003 09:50:01 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Folks, This WG needs to declare consensus on some basic issues, or it will never get done. The note below from Keith summarizes what I see a lot of other folk seeming to agree with. So, I would like to ask the WG to answer the following questions: 1) Should the ID recommend that LL addresses only be configured as per below. Please answer clearly, along the lines of a) yes, I think this is what the document should say (maybe with some small tweaks, which then need to be explained) b) no, this is a showstopper for me (and explain why, so the rest of the WG can understand and then agree or disagree with your position) c) Not my first choice, but I can live with it. Note that two things need to happen. First, get general agreement on the direction, second, agreement on the exact text to go in the document. It would be helpful if folk would post their views (including lurkers) but also to restrict themselves to answering the above questions. If only a small number of the usual suspects post, we will risk not have enough input to make a clear consensus call. Thus, everyone who cares should speak up. Thomas Keith Moore writes: > On Wed, 22 Jan 2003 10:01:30 +1000 (EST) > Ian Lister wrote: > > On Tue, 21 Jan 2003, Philip Nye wrote: > > >Joshua, > > > > > >> This problem is not as significant as it may seem. If IPv4LLs are only > > >> acquired on an interface when no global address can be (no DHCP, manual > > >> config, or other config method), the device will be unable to > > >> communicate with anything off of the local link through that interface. > > > > > >Your analysis is reasonable - but it is rather off the track because the > > >current draft recommends that IPv4LL be turned on even when a global address > > >IS found - and this is the source of the problems. > > > > It is not off track if the draft is amended to specify the behaviour > > Joshua described (which is currently implemented in Mac OS and IMO is the > > most appropriate behaviour). With that behaviour IPv4LL is used only where > > there is no alternative, so there can be no accusations of breakage. Is > > there anybody who actually wants to argue against this? > now I'm losing track of what is meant by "used" - > - when should an IPv4LL address be configured by a host? > suggest: if the host is explicitly configured to do so, OR > if the host has attempted and failed to acquire a routable address via DHCP > (alternative: provide a lighter weight mechanism by which a host can acquire a > routable address, netmask, and default route, in response to its attempt to claim > an IPv4LL address) > - when should an IPv4LL address be used by a host as a source address? > suggest: when the only addresses available to the host are IPv4LL addresses, OR > when the application has explicitly specified the source address to use, OR > when the application has explicitly specified the interface to use and the IPv4LL address > is the only address associated with that interface. > - when should a host honor an attempt to connect to an IPv4LL address that was once > configured by that host? > suggest: anytime the address is still valid (e.g. there have been no conflicting claims) > and there is a process listening for connections either specifically to that address or > for incoming connections at any of the host's addresses. > - when should an application attempt to connect to a IPv4LL address? > suggest: only when the address is literally specified, or if there are no other routable > addresses for the destination host known to the application. > - when should an application send an IPv4LL address in a referral to another host? > suggest: only when there are no routable addresses for the destination host known to the > application. even then, care needs to be taken that a host reached at a particular > IPv4LL address is really the one intended - since IPv4LL addresses can be reassigned > without notice and/or reused on different network segments. From owner-zeroconf@merit.edu Wed Jan 22 09:57:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26470 for ; Wed, 22 Jan 2003 09:57:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7CED691378; Wed, 22 Jan 2003 10:00:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C643F912F7; Wed, 22 Jan 2003 09:59: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 58D83912EE for ; Wed, 22 Jan 2003 09:59:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3EDDC5DDC6; Wed, 22 Jan 2003 09:59:55 -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 A494B5DD91 for ; Wed, 22 Jan 2003 09:59:50 -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 029A259900 for ; Wed, 22 Jan 2003 14:59:52 +0000 (GMT) Message-ID: <00f301c2c226$e9403440$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: Subject: Re: Turning off link-locals? Date: Wed, 22 Jan 2003 14:59:49 -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: "John C. Welch" > > No, because everything I've seen says, "In the face of any other > configuration methodology, disable v4LL" Now, disabled is rather clear. It > means off. Off is off. Not sort of on, not kind of on, but off. You cannot > use a v4LL address, because it is disabled. You can ARP for anything, but > since v4LL is disabled, you can't talk to that device. Perhaps this is the cause of the confusion. I believe that most of the people advocating this mean "Do not claim a LL address" and not "Do not communicate using LL addresses in any way" If this is not the case I am sure they will say so. Philip From owner-zeroconf@merit.edu Wed Jan 22 09:57:57 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26500 for ; Wed, 22 Jan 2003 09:57:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD55B912EE; Wed, 22 Jan 2003 10:00:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 548E79137A; Wed, 22 Jan 2003 10:00: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 35DF7912EE for ; Wed, 22 Jan 2003 10:00:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1842D5DDC6; Wed, 22 Jan 2003 10:00:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 9B68C5DD91 for ; Wed, 22 Jan 2003 09:59:58 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0MExaR00879; Wed, 22 Jan 2003 21:59:36 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0MExR812639; Thu, 23 Jan 2003 01:59:29 +1100 (EST) From: Robert Elz To: "John C. Welch" Cc: Zeroconf Subject: Re: Turning off link-locals? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Jan 2003 21:59:27 +0700 Message-ID: <12637.1043247567@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 22 Jan 2003 09:37:42 -0500 From: "John C. Welch" Message-ID: | But since my computers all have DHCP addresses, v4LL is now disabled on all | of them, so pray tell, exactly how do they talk to the v4LL device? Have you bothered to read the mailing list over the past few days? If not, don't you think you should, before displaying your ignorance? If you have, then the inference is obvious. kre From owner-zeroconf@merit.edu Wed Jan 22 10:03:57 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26832 for ; Wed, 22 Jan 2003 10:03:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B5470912EF; Wed, 22 Jan 2003 10:07:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84AA9912F0; Wed, 22 Jan 2003 10:07: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 6CC10912EF for ; Wed, 22 Jan 2003 10:07:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 591C65DE83; Wed, 22 Jan 2003 10:07: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 E37765DE5C for ; Wed, 22 Jan 2003 10:07:12 -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 KAA10389 for ; Wed, 22 Jan 2003 10:07: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 KAA21089 for ; Wed, 22 Jan 2003 10:03:56 -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 KAA13869 for ; Wed, 22 Jan 2003 10:03:55 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 10:03:53 -0500 Subject: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: 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 Okay, ignoring a bunch of ad hominem attacks on my network knowledge. Preexisting conditions: I have an internet connection This internet connection gives me a global address This address is assigned via DHCP (the most common method). I only have one computer, so I don't need a router of any kind. I only have one physical interface on the computer. Ethernet. Now, I buy a printer. The printer is a zeroconf printer. It supports v4LL addressing. It too only has an ethernet interface I buy a little switch, a 4 - port 10/100 job. It is not a router. It is only a switch. It provides no configuration capabilities. None. I don't need them. I don't want them. I'm not a geek (in this example), I just want to print, and I'm already using a lot of USB devices, so I don't want to add another one. Now, we get interesting. My computer, since it is configured via DHCP has its v4LL capabilities disabled. It can not use a v4LL address. Period. This is what disabled means. Not functional. I don't want to pay for another address from my ISP. It's not that I'm trying to steal from them. I just only want to print at home. Not from Pago Pago, or Botswana, or France. Just from home. But now I have a problem. I can't use v4LL, because I am using DHCP for my address configuration, and v4LL is (according to many on this list), not going to be available on my computer until such time as I am no longer getting my IP configuration via DHCP. But now I can't print unless I have my printer configured via DHCP too. So now, I have to either pay for an additional address, *or*, legally or not, buy a router of some kind that can be an interface to the public network. I may have to use DHCP for my two device network. I may not. The point is, thanks to v4LL being off, I now HAVE to get another piece of equipment, or deal with my printer being globally visible. THAT is bogus. It's requiring the home user to now become far more aware of networking than they should have to. THAT is why I want v4LL to just be on. I really can't say it any clearer than that. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 10:04:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26866 for ; Wed, 22 Jan 2003 10:04:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CE781912F0; Wed, 22 Jan 2003 10:07:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9FF29912F1; Wed, 22 Jan 2003 10:07: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 942A5912F0 for ; Wed, 22 Jan 2003 10:07:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7FA945DE37; Wed, 22 Jan 2003 10:07:52 -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 162855DD91 for ; Wed, 22 Jan 2003 10:07:52 -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 KAA10771 for ; Wed, 22 Jan 2003 10:07:51 -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 KAA27011 for ; Wed, 22 Jan 2003 10:05: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 KAA14751 for ; Wed, 22 Jan 2003 10:05:39 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 10:05:37 -0500 Subject: Re: WG decision: when to configure LL addrs From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200301221450.h0MEo2l11224@cichlid.adsl.duke.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 01/22/2003 09:50, "Thomas Narten" wrote: > Note that two things need to happen. First, get general agreement on > the direction, second, agreement on the exact text to go in the > document. v4LL communication should always be available and usable without manual intervention by the user. That is my position. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 10:09:58 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27094 for ; Wed, 22 Jan 2003 10:09:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 130AD912F1; Wed, 22 Jan 2003 10:13:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA610912F2; Wed, 22 Jan 2003 10:13: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 C6C4F912F1 for ; Wed, 22 Jan 2003 10:13:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC0665DE95; Wed, 22 Jan 2003 10:13:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 4278D5DE5C for ; Wed, 22 Jan 2003 10:13:12 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-237.cisco.com [10.82.240.237]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0MFD8uW004887; Wed, 22 Jan 2003 07:13:09 -0800 (PST) Message-Id: <4.3.2.7.2.20030122100243.03e0fef0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Jan 2003 10:13:09 -0500 To: Thomas Narten From: John Schnizlein Subject: Re: WG decision: when to configure LL addrs Cc: zeroconf@merit.edu In-Reply-To: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk Yes to all 5 rules, but with the tweak that the alternative "lighter weight mechanism" is too poorly specified to be considered at this time. Thank you for your concrete path forward. John At 09:50 AM 1/22/2003, Thomas Narten wrote: >Should the ID recommend that LL addresses only be configured as per > below. > > a) yes, I think this is what the document should say (maybe > with some small tweaks, which then need to be explained) > > b) no, this is a showstopper for me (and explain why, so the > rest of the WG can understand and then agree or disagree > with your position) > > c) Not my first choice, but I can live with it. > >Keith Moore writes: > >> On Wed, 22 Jan 2003 10:01:30 +1000 (EST) >> >> 1 when should an IPv4LL address be configured by a host? > >> suggest: if the host is explicitly configured to do so, OR if the >> host has attempted and failed to acquire a routable address via DHCP > >> (alternative: provide a lighter weight mechanism by which a host >> can acquire a routable address, netmask, and default route, in >> response to its attempt to claim an IPv4LL address) > >> 2 when should an IPv4LL address be used by a host as a source address? > >> suggest: when the only addresses available to the host are IPv4LL >> addresses, OR when the application has explicitly specified the >> source address to use, OR when the application has explicitly >> specified the interface to use and the IPv4LL address is the >> only address associated with that interface. > >> 3 when should a host honor an attempt to connect to an IPv4LL >> address that was once configured by that host? > >> suggest: anytime the address is still valid (e.g. there have >> been no conflicting claims) and there is a process listening >> for connections either specifically to that address or >> for incoming connections at any of the host's addresses. > >> 4 when should an application attempt to connect to a IPv4LL address? > >> suggest: only when the address is literally specified, >> or if there are no other routableaddresses for the destination >> host known to the application. > >> 5 when should an application send an IPv4LL address in a referral >> to another host? > >> suggest: only when there are no routable addresses for the >> destination host known to the application. >> Even then, care needs to be taken that a host reached at a particular >> IPv4LL address is really the one intended - since IPv4LL addresses >> can be reassigned without notice and/or reused on different network >> segments. From owner-zeroconf@merit.edu Wed Jan 22 10:10:08 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27109 for ; Wed, 22 Jan 2003 10:10:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D8181912F2; Wed, 22 Jan 2003 10:13:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0C51912F3; Wed, 22 Jan 2003 10:13: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 83FAD912F2 for ; Wed, 22 Jan 2003 10:13:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E80C5DE5C; Wed, 22 Jan 2003 10:13:19 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by segue.merit.edu (Postfix) with ESMTP id 23C7E5DDC6 for ; Wed, 22 Jan 2003 10:13:19 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0MFDIl9017328; Wed, 22 Jan 2003 10:13:18 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-244-157.mts.ibm.com [9.65.244.157]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0MFBwFS107620; Wed, 22 Jan 2003 08:11:58 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h0MFBhY11975; Wed, 22 Jan 2003 10:11:43 -0500 Message-Id: <200301221511.h0MFBhY11975@cichlid.adsl.duke.edu> To: "John C. Welch" Cc: Zeroconf Subject: Re: WG decision: when to configure LL addrs In-Reply-To: Message from jwelch@MIT.EDU of "Wed, 22 Jan 2003 10:05:37 EST." Date: Wed, 22 Jan 2003 10:11:42 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk "John C. Welch" writes: > On 01/22/2003 09:50, "Thomas Narten" wrote: > > Note that two things need to happen. First, get general agreement on > > the direction, second, agreement on the exact text to go in the > > document. > v4LL communication should always be available and usable without manual > intervention by the user. To be 100% sure I understand, are you saying that devices should always configure a LL address (whether or not they have a global address), and it is fine for a device to configure and use both simultaneously? Thomas From owner-zeroconf@merit.edu Wed Jan 22 10:15:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27270 for ; Wed, 22 Jan 2003 10:15:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1039D912F3; Wed, 22 Jan 2003 10:18:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3363912F4; Wed, 22 Jan 2003 10:17: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 6D1CC912F3 for ; Wed, 22 Jan 2003 10:16:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D3EB5DEA9; Wed, 22 Jan 2003 10:16:09 -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 2BD575DDC6 for ; Wed, 22 Jan 2003 10:16:09 -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 KAA20172 for ; Wed, 22 Jan 2003 10:16: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 KAA29258 for ; Wed, 22 Jan 2003 10:16:08 -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 KAA19934 for ; Wed, 22 Jan 2003 10:16:07 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 10:16:05 -0500 Subject: Re: WG decision: when to configure LL addrs From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200301221511.h0MFBhY11975@cichlid.adsl.duke.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 01/22/2003 10:11, "Thomas Narten" wrote: >> v4LL communication should always be available and usable without manual >> intervention by the user. > > To be 100% sure I understand, are you saying that devices should > always configure a LL address (whether or not they have a global > address), and it is fine for a device to configure and use both > simultaneously? yes john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 10:15:46 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27285 for ; Wed, 22 Jan 2003 10:15:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A9CB8912F4; Wed, 22 Jan 2003 10:19:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 731B6912F5; Wed, 22 Jan 2003 10:19: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 3CBF8912F4 for ; Wed, 22 Jan 2003 10:19:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A6D25DE83; Wed, 22 Jan 2003 10:19:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.132]) by segue.merit.edu (Postfix) with ESMTP id 955715DDC6 for ; Wed, 22 Jan 2003 10:19:00 -0500 (EST) Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e34.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id h0MFIw1G028286; Wed, 22 Jan 2003 10:18:58 -0500 Received: from cichlid.adsl.duke.edu (sig-9-65-244-157.mts.ibm.com [9.65.244.157]) by westrelay01.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id h0MFGFFS040186; Wed, 22 Jan 2003 08:16:15 -0700 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h0MFG0M12033; Wed, 22 Jan 2003 10:16:00 -0500 Message-Id: <200301221516.h0MFG0M12033@cichlid.adsl.duke.edu> To: "John C. Welch" Cc: Zeroconf Subject: Re: One last attempt to illustrate my concerns In-Reply-To: Message from jwelch@MIT.EDU of "Wed, 22 Jan 2003 10:03:53 EST." Date: Wed, 22 Jan 2003 10:16:00 -0500 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk "John C. Welch" writes: > My computer, since it is configured via DHCP has its v4LL capabilities > disabled. It can not use a v4LL address. Period. This is what disabled > means. Not functional. You are making a possibly unwarranted assumption. DHC communicates two kinds of parameters. Those having global scope (i.e., impact the node as a whole). The other kind of parameter are those that only impact the interface on which the configuration information came on. My assumption is that a DHCP option saying "don't use LL addressing" would only apply to the interface where DHC was run. (But in anycase, this level of detail would need to be fleshed out). Thus, recieving such an option on interface X would not imply LL is not to be run on other interfaces. Thomas From owner-zeroconf@merit.edu Wed Jan 22 10:23:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27578 for ; Wed, 22 Jan 2003 10:23:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2DDB7912F5; Wed, 22 Jan 2003 10:27:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D951E912F6; Wed, 22 Jan 2003 10: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 D1F0F912F5 for ; Wed, 22 Jan 2003 10:27:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id B5AF95DDC6; Wed, 22 Jan 2003 10:27:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 3D2D55DD91 for ; Wed, 22 Jan 2003 10:27:04 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0MFQwR14709; Wed, 22 Jan 2003 22:26:58 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0MFQj812786; Thu, 23 Jan 2003 02:26:45 +1100 (EST) From: Robert Elz To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: WG decision: when to configure LL addrs In-Reply-To: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> References: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Jan 2003 22:26:45 +0700 Message-ID: <12784.1043249205@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 22 Jan 2003 09:50:01 -0500 From: Thomas Narten Message-ID: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> | So, I would like to ask the WG to answer the following questions: | | 1) Should the ID recommend that LL addresses only be configured as per | below. Please answer clearly, along the lines of | | a) yes, I think this is what the document should say (maybe with | some small tweaks, which then need to be explained) Yes With tweaks, as below... | > - when should an IPv4LL address be configured by a host? | | > suggest: if the host is explicitly configured to do so, OR | > if the host has attempted and failed to acquire a routable | > address via DHCP This needs to be adjusted to make it clear that "failed to acquire" isn't "was refused an address" but means "found no-one able to allocate addresses" (and "routable" is unnecessary - a 1918 address is just fine too - in fact any address the DHCP server decides to assign is just fine, if any at all, if there's an operating DHCP server). Also, add "OR is configured to do so via DHCP", so even if a DHCP address is assigned, or explicitly not assigned, the DHCP server can tell the device to go ahead and allocate itself a LL address. (No objection if there is support for the DHCP option being inverted so an explicit option is required to prevent hosts assigning themselves LL addresses). | > - when should an IPv4LL address be used by a host as a source address? | | > suggest: when the only addresses available to the host are IPv4LL addresses, OR | > when the application has explicitly specified the source address to use, OR | > when the application has explicitly specified the interface to use and the IPv4LL address | > is the only address associated with that interface. This isn't going to work in many cases - a host with a global address on one interface, and only LL on another, wanting to talk to a LL device on the LL interface, almost certainly shouldn't be using its global address as the source address - sometimes that will work (if the host is willing to answer ARP on the "wrong" interface), but it isn't reliable. If there's no specified source address, the stack should work like stacks tend to do now, and assign an address from the interface through which the packet is to be sent - then if that interface happens to have both LL and other address, take the other. The rest are fine as Keith wrote them I believe. kre From owner-zeroconf@merit.edu Wed Jan 22 10:27:01 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27756 for ; Wed, 22 Jan 2003 10:27:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1BBF1912F6; Wed, 22 Jan 2003 10:30:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 962DA912F7; Wed, 22 Jan 2003 10:30: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 A0CE0912F6 for ; Wed, 22 Jan 2003 10:30:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id D6B155DE9E; Wed, 22 Jan 2003 10:30:03 -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 4322F5DE83 for ; Wed, 22 Jan 2003 10:30:03 -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 KAA28282 for ; Wed, 22 Jan 2003 10:30:02 -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 KAA02307 for ; Wed, 22 Jan 2003 10:30:02 -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 KAA26767 for ; Wed, 22 Jan 2003 10:30:01 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 10:29:59 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200301221516.h0MFG0M12033@cichlid.adsl.duke.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 01/22/2003 10:16, "Thomas Narten" wrote: >> My computer, since it is configured via DHCP has its v4LL capabilities >> disabled. It can not use a v4LL address. Period. This is what disabled >> means. Not functional. > > You are making a possibly unwarranted assumption. DHC communicates two > kinds of parameters. Those having global scope (i.e., impact the node > as a whole). The other kind of parameter are those that only impact > the interface on which the configuration information came on. > > My assumption is that a DHCP option saying "don't use LL addressing" > would only apply to the interface where DHC was run. (But in anycase, > this level of detail would need to be fleshed out). Thus, recieving > such an option on interface X would not imply LL is not to be run on > other interfaces. Ah, but there are a lot of computers in homes with only one interface. Which is where the problems with turning off LL in the face of DHCP lie. And I don't like unspecified assumptions in a standard. It causes problems, just ask the Kerberos people. I fully realize that there are things that v4LL on all the time will break. Having seen that they are what could easily be considered edge cases for simple networks, and that these applications can be updated to deal with this, then I simply cannot agree that turning off v4LL as an automatic function of other configurations is a good idea. Now, since there are times when you would want this shut off, any earlier objections I may have had to requiring a manual shutoff are removed. There are reasons, outside of edge case clustering apps, (I was reminded about working in places like Livermore, and other extreme security environments by some friends complaining about having to remove wireless cards to simply enter the building,) where it needs to be off. A manual config provides this in an obvious, noticeable way. Along with a reminder dialog on (re)boot, wake up, interface (re)configuration, my issues with this would be settled nicely. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 10:31:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27961 for ; Wed, 22 Jan 2003 10:31:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7A491912F9; Wed, 22 Jan 2003 10:34:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29CB291379; Wed, 22 Jan 2003 10:34: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 3AA6091391 for ; Wed, 22 Jan 2003 10:32:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 21CA35DE8A; Wed, 22 Jan 2003 10:32:12 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ms-smtp-03.southeast.rr.com (ms-smtp-03.southeast.rr.com [24.93.67.84]) by segue.merit.edu (Postfix) with ESMTP id A32B25DE83 for ; Wed, 22 Jan 2003 10:32:11 -0500 (EST) Received: from mail8.nc.rr.com (fe8 [24.93.67.55]) by ms-smtp-03.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h0MFVNLv021559; Wed, 22 Jan 2003 10:31:23 -0500 (EST) Received: from nc.rr.com ([63.109.132.2]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 22 Jan 2003 10:30:39 -0500 Message-ID: <3E2EB9EA.6000207@nc.rr.com> Date: Wed, 22 Jan 2003 10:34:02 -0500 From: Brian Haberman Organization: No Organization Here User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten Cc: "John C. Welch" , Zeroconf Subject: Re: One last attempt to illustrate my concerns References: <200301221516.h0MFG0M12033@cichlid.adsl.duke.edu> In-Reply-To: <200301221516.h0MFG0M12033@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: > "John C. Welch" writes: > > >>My computer, since it is configured via DHCP has its v4LL capabilities >>disabled. It can not use a v4LL address. Period. This is what disabled >>means. Not functional. > > > You are making a possibly unwarranted assumption. DHC communicates two > kinds of parameters. Those having global scope (i.e., impact the node > as a whole). The other kind of parameter are those that only impact > the interface on which the configuration information came on. > > My assumption is that a DHCP option saying "don't use LL addressing" > would only apply to the interface where DHC was run. (But in anycase, > this level of detail would need to be fleshed out). Thus, recieving > such an option on interface X would not imply LL is not to be run on > other interfaces. I believe the scenario is supposed to look like this: ISP | | +---+ |hub| +---+ | | | | printer ---+ +--- PC (169.254.38.54) (67.45.33.4) So, here is my view. The PC could honor the "no v4LL" on the interface and still reach the printer. The PC could simply add a route for 169.254/16 for each interface. This can be done without configuring a v4LL address on the interface. And it would cause the PC's IP stack to arp for the address in question. The user would have to specify the printer by its IP address, but that is not a big deal. Brian From owner-zeroconf@merit.edu Wed Jan 22 10:31:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27976 for ; Wed, 22 Jan 2003 10:31:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9ED31912F8; Wed, 22 Jan 2003 10:34:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67DE5912FA; Wed, 22 Jan 2003 10:34: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 EC08F912F8 for ; Wed, 22 Jan 2003 10:34:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id C72AC5DEA4; Wed, 22 Jan 2003 10:34:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id A16835DE9E for ; Wed, 22 Jan 2003 10:34:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 610BF14264; Wed, 22 Jan 2003 10:34:46 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 23817-10; Wed, 22 Jan 2003 10:34:45 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 6936F14262; Wed, 22 Jan 2003 10:34:45 -0500 (EST) Date: Wed, 22 Jan 2003 10:34:44 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030122103444.56c0084e.moore@cs.utk.edu> In-Reply-To: References: <20030121223310.3fc68000.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 98b259b22bad5d5116933209c7965326256c2301 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 22 Jan 2003 07:32:41 -0500 "John C. Welch" wrote: > On 01/21/2003 22:33, "Keith Moore" wrote: > > >> WHY do you need to have printers with routable, global addresses in > >all> cases? Normally, you don't. > > > > You might or might not want your printers to be potentially > > accessible from anywhere in the world (mine are and it really can be > > quite useful). > > I didn't say they weren't. I said it wasn't the majority case. Perhaps being able to access your printer from anywhere in the world is currently unusual, but this may also change - as better print spooling protocols (with useful authentication) are deployed, there is no inherent need to restrict who can access the printer based on the source address. And print spooling with appropriate authentication is a much better way of transferring high-quality documents than fax. And it's certainly not the majority case that access to networked printers is restricted to the local link. The local subnet, perhaps, but not the local link. > > But there's no real reason to assume that a printer need only be > > accessible from the local link. If I want to use my palm pilot with > > a CDMA connection to print a file from the workstation in my office, > > to a printer in the same room as I am, that's a very convenient and > > perfectly reasonable thing to do. > > Right...because it's far easier than doing a sync and using > Ethernet. The document never touches my palm pilot. I'm just using it as a terminal to cause the document to be spooled from another remote host. > and what I'm saying is, consider that an LL - > only device would not be some bizarre abberation, but a common > potential. And what I'm saying is, it's not a very useful potential. Restricting access to the local link means that you have to organize your network topology so that every device that needs to access something is on the same link as all of the things it needs to access. Far better to let the network decide what things the device can access (for the managed case) and you can still have LL for the unmanaged ad hoc networks. > >> So printers with LLv4 - only addressing actually > >> makes a fair bit of sense, especially behind a firewall and a NAT. > > > > Even that only makes sense if either the local link and the realm > > behind the NAT are identical, or the realm from which you want to be > > able to print happens to be some subset of the local link. > > I've dealt with a LOT of companies that have printers for each work > group, and due to chargebacks, you aren't *allowed* to print on > someone else's printer. That's fine for them if they want to do things that way, but it's not a justification for forcing large numbers of networks and applications every to have to worry about link scope. If the network admin wants the device to be limited to link scope, he simply arranges for the device to have no default route, and/or for the device's traffic to be filtered. Or he can just have the network not respond to the device's request for an address and let the device default to LL. In other words, LL will still be available for those managed networks that want to use it. > >> Again, HOW do you easily override the DHCP = OFF condition here? > > > > Devices that aren't explicitly configurable have to accept whatever > > the network tells them to do. If the network admin (whether by DHCP > > or some other mechanism) wants to tell different devices to do > > different things, based on their MAC addresses or whatever, that's > > his business. > > But earlier you said that it should be manually overridable...so > again, What do you do about situations that don't fit your model? no, I said that for devices that are explicitly configurable, local configuration needs to take precedence over network configuration or LL. if the network admin wants to prevent such devices from talking outside of a particular scope, he/she needs to install filters, just as for any other configurable host. this is nothing new. OTOH, for devices that aren't explicitly configurable, it's useful if the network admin can provide minimal configuration over the network. again, this is nothing new - except that it would be nice to have a clean mechanism for allowing a device to automagically "do the right thing" on either a managed network or an unmanaged network, and one with less code overhead than requiring the device to implement DHCP. > > Of course the point isn't to insist that all devices be accessible > > from everywhere, but to avoid building limitations into devices that > > are unnecessary and which aren't a good match to users' needs. > > But you assume that global accessibility is always wanted or needed, > and that simply isn't true. no I don't assume that, and if you take the trouble to read what I wrote, it's obvious that I don't assume that. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 10:32:52 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28001 for ; Wed, 22 Jan 2003 10:32:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5845B912FA; Wed, 22 Jan 2003 10:36:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BB7191379; Wed, 22 Jan 2003 10:36:04 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1206E912FA for ; Wed, 22 Jan 2003 10:36:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE12A5DE8A; Wed, 22 Jan 2003 10:36:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id C73E45DEAB for ; Wed, 22 Jan 2003 10:36:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 996DE14262; Wed, 22 Jan 2003 10:36:02 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 24216-10; Wed, 22 Jan 2003 10:36:02 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 07C8313FD5; Wed, 22 Jan 2003 10:36:02 -0500 (EST) Date: Wed, 22 Jan 2003 10:36:01 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030122103601.70330403.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 70d3f0300a539f328b81cca852796b482e81ee6b Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > But since reality shows that WON'T happen, we need to deal with > *reality* not "What we dream about" whenever someone insists on dealing with reality, what they generally mean is "you should accept my delusions as truth". -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 10:38:14 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28252 for ; Wed, 22 Jan 2003 10:38:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0E9D791379; Wed, 22 Jan 2003 10:41:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CBC539137A; Wed, 22 Jan 2003 10:41: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 A7EFE91379 for ; Wed, 22 Jan 2003 10:41:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E4195DEA9; Wed, 22 Jan 2003 10:41:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 761525DE9E for ; Wed, 22 Jan 2003 10:41:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 40B0C14266; Wed, 22 Jan 2003 10:41:31 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 25498-07; Wed, 22 Jan 2003 10:41:30 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id A289314262; Wed, 22 Jan 2003 10:41:30 -0500 (EST) Date: Wed, 22 Jan 2003 10:41:30 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030122104130.7ba56df5.moore@cs.utk.edu> In-Reply-To: References: <00aa01c2c214$912fab30$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 45d10911bd95324c85e6b0e8e29a2c006948c126 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > In none of these cases is it necessary that the printer is LL only > > by design. > > But what about when it happens. Or some other device that we don't > know about yet? Maybe a home MP3 server? I definitely want my home mp3 server to be able to talk to my car, which will not be on the same link. you are grasping at straws. there is no good reason for a device to assume that its access should be limited to the local link. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 10:45:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28419 for ; Wed, 22 Jan 2003 10:45:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1FB99912FC; Wed, 22 Jan 2003 10:48:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8714912FB; Wed, 22 Jan 2003 10:48: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 AD01A9137B for ; Wed, 22 Jan 2003 10:46:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8CB3E5DE9E; Wed, 22 Jan 2003 10:46: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 1F5FB5DE37 for ; Wed, 22 Jan 2003 10:46:59 -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 KAA05953 for ; Wed, 22 Jan 2003 10:46:58 -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 KAA06617 for ; Wed, 22 Jan 2003 10:43:34 -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 KAA03244 for ; Wed, 22 Jan 2003 10:43:33 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 10:43:30 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <3E2EB9EA.6000207@nc.rr.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 01/22/2003 10:34, "Brian Haberman" wrote: > So, here is my view. The PC could honor the "no v4LL" on the > interface and still reach the printer. The PC could simply add > a route for 169.254/16 for each interface. This can be done > without configuring a v4LL address on the interface. And it > would cause the PC's IP stack to arp for the address in question. > The user would have to specify the printer by its IP address, but > that is not a big deal. Well, that actually is a big deal, but that's for service discovery and mDNS, not v4LL. But if you're going to go through all the trouble to communicate with v4LL devices, why not just take the last step and give them the address too? It's simpler, and easier to plan for if it's *always* there. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 10:49:46 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28598 for ; Wed, 22 Jan 2003 10:49:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 29C5D912FB; Wed, 22 Jan 2003 10:53:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EAF519137A; Wed, 22 Jan 2003 10:53: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 B4A80912FB for ; Wed, 22 Jan 2003 10:53:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9E0CC5DE37; Wed, 22 Jan 2003 10:53:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 85F945DD91 for ; Wed, 22 Jan 2003 10:53:01 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5173F14262; Wed, 22 Jan 2003 10:53:01 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 27202-07; Wed, 22 Jan 2003 10:53:00 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id AE4B614043; Wed, 22 Jan 2003 10:53:00 -0500 (EST) Date: Wed, 22 Jan 2003 10:53:00 -0500 From: Keith Moore To: Thomas Narten Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: AD to zeroconf WG Message-Id: <20030122105300.7cd3fbbf.moore@cs.utk.edu> In-Reply-To: <200301221444.h0MEi3210690@cichlid.adsl.duke.edu> References: <200301221444.h0MEi3210690@cichlid.adsl.duke.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: e48af1155067ccda55a64fd22d2b61c601784cfe Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 22 Jan 2003 09:44:03 -0500 Thomas Narten wrote: > AD hat on. > > This WG has been going around in circles for months, having many > yes/no much-heat-little-light rathole discussions. What has finally become clear from these discussions is that the WG has been suffering for a long time from a fundamental dissonance between - those wanting a mechanism to allow ad hoc networks to function, - those wanting a mechanism to allow automatic configuration of devices in connected networks, - those wanting a low-overhead mechanism to allow automatic configuration of fixed-function IP-capable devices, and - those wanting to promote the idea that some devices should have access limited to the local link LL, as currently designed, only addresses the first goal, but it doesn't play well on connected networks. It appears that it can be modified with little difficulty to allow it to address the first three goals. The discussion for the last few days has been productive at exploring the technical details of how to do this. And the last item is not a desirable goal. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 10:52:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28649 for ; Wed, 22 Jan 2003 10:52:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1B9769137A; Wed, 22 Jan 2003 10:55:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DECED9137B; Wed, 22 Jan 2003 10:55: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 DF98D9137A for ; Wed, 22 Jan 2003 10:55:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id CD75A5DEA9; Wed, 22 Jan 2003 10:55:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 64CA25DE8A for ; Wed, 22 Jan 2003 10:55: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 KAA03730 for ; Wed, 22 Jan 2003 10:55: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 KAA28517 for ; Wed, 22 Jan 2003 10:52:02 -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 KAA05025 for ; Wed, 22 Jan 2003 10:47:07 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 10:47:05 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122104130.7ba56df5.moore@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 01/22/2003 10:41, "Keith Moore" wrote: >> But what about when it happens. Or some other device that we don't >> know about yet? Maybe a home MP3 server? > > I definitely want my home mp3 server to be able to talk to my car, > which will not be on the same link. > > you are grasping at straws. there is no good reason for a device to assume > that its access should be limited to the local link. There is no logic in assuming that there won't be either. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 10:54:18 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28778 for ; Wed, 22 Jan 2003 10:54:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DFF589137B; Wed, 22 Jan 2003 10:57:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B316E9137C; Wed, 22 Jan 2003 10:57: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 ADC629137B for ; Wed, 22 Jan 2003 10:57:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 95F185DE8A; Wed, 22 Jan 2003 10:57: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 2C9025DE37 for ; Wed, 22 Jan 2003 10:57:31 -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 KAA03742 for ; Wed, 22 Jan 2003 10:55: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 KAA28532 for ; Wed, 22 Jan 2003 10:52:02 -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 KAA04634 for ; Wed, 22 Jan 2003 10:46:14 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 10:46:12 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122103601.70330403.moore@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 01/22/2003 10:36, "Keith Moore" wrote: >> But since reality shows that WON'T happen, we need to deal with > *reality* >> not "What we dream about" > > whenever someone insists on dealing with reality, what they generally mean is > "you should accept my delusions as truth". In my case, it means "I'm absolutely cynical about people doing the right thing. I assume they won't, and it is *far* better to deal with it now, than hope for the best and get burned yet again" The Kerberos folks learned this the hard way. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 11:00:19 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28958 for ; Wed, 22 Jan 2003 11:00:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9E2ED91380; Wed, 22 Jan 2003 11:00:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B3BB91381; Wed, 22 Jan 2003 11: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 4FAE69137E for ; Wed, 22 Jan 2003 11:00:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4EB5E5DEAE; Wed, 22 Jan 2003 11:00:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id F1FD15DEAB for ; Wed, 22 Jan 2003 11:00:25 -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 956DE598F9; Wed, 22 Jan 2003 16:00:28 +0000 (GMT) Message-ID: <003b01c2c22f$60c463d0$131010ac@aldebaran> From: "Philip Nye" To: , "Thomas Narten" References: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> Subject: Re: WG decision: when to configure LL addrs Date: Wed, 22 Jan 2003 16:00:25 -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" > So, I would like to ask the WG to answer the following questions: > > 1) Should the ID recommend that LL addresses only be configured as per > below. Please answer clearly, along the lines of > > a) yes, I think this is what the document should say (maybe with > some small tweaks, which then need to be explained) Yes With tweaks exactly as outlined by Robert Elz (22 Jan 2003) Philip Nye From owner-zeroconf@merit.edu Wed Jan 22 11:03:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29023 for ; Wed, 22 Jan 2003 11:03:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 387AB912FD; Wed, 22 Jan 2003 11:06:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05C7F912FF; Wed, 22 Jan 2003 11:06:28 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D3DBE912FD for ; Wed, 22 Jan 2003 11:06:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id BB4975DEAF; Wed, 22 Jan 2003 11:06:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 9C2F35DEAE for ; Wed, 22 Jan 2003 11:06:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 6B0CB14141; Wed, 22 Jan 2003 11:06:27 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 29469-07; Wed, 22 Jan 2003 11:06:26 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id C16A5140AA; Wed, 22 Jan 2003 11:06:26 -0500 (EST) Date: Wed, 22 Jan 2003 11:06:26 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: problems with using DHCP (was: one last attempt to illustrate my concerns) Message-Id: <20030122110626.77a2c8f8.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: be3c2ecd2b6ffd7480d67ed7da7fad8a65adf37c Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > My computer, since it is configured via DHCP has its v4LL capabilities > disabled. It can not use a v4LL address. Period. This is what disabled > means. Not functional. no, this is not what was intended. what was intended is if your computer gets an address from DHCP it should not attempt to acquire a v4LL address. however, the lack of a v4LL address should not stop it from attempting to talk to a v4LL address on one of its interfaces. -- However this did cause me to realize a problem with the idea that any DHCP service should suffice to disable v4LL. I have a DSL modem at home. As shipped, that modem had a DHCP server that assigned a RFC 1918 address to the first host that asked for an address. It would do NAT (arrgh) between that address and the address assigned to the DSL line by the ISP.[*] However it would NOT NAT for multiple devices and it woudl NOT honor any subsequent DHCP requests for addresses by other hosts on the network. So imagine a home network with a DSL modem like mine, an Ethernet hub, and two hosts - a windows or mac box and a zeroconf printer. If the windows or mac box asks DHCP for an address first, then all is well - the windows or mac box can talk externally, and it can talk to the printer's v4LL address. On the other hand if the printer asks DHCP for an address first, then the printer can accept connections from anywhere in the network, but the windows or mac box will be isolated. And the poor clueless user has to reboot the cable modem, *then* reboot the windows or mac box, or something. That's a lousy arrangement. Now this is a limited sample space, and maybe that's just an anomaly with this one DSP modem, but I've heard that this kind of behavior is common. If so then what we need is some more explicit way for a network to say "don't use LL" than just the presence of a DHCP server. Keith [*] fortunately I was able to configure the modem to operate in PPPoE mode, which gets rid of the NAT, and allows me to run 6to4 to talk to my home machines. From owner-zeroconf@merit.edu Wed Jan 22 11:08:01 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29186 for ; Wed, 22 Jan 2003 11:08:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 37D97912FF; Wed, 22 Jan 2003 11:11:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0902D9137E; Wed, 22 Jan 2003 11:11: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 035F3912FF for ; Wed, 22 Jan 2003 11:11:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id E23315DF87; Wed, 22 Jan 2003 11:11:15 -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 77B285DECE for ; Wed, 22 Jan 2003 11:11:15 -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 LAA19447 for ; Wed, 22 Jan 2003 11:11:14 -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 LAA03059 for ; Wed, 22 Jan 2003 11:11:14 -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 LAA16755 for ; Wed, 22 Jan 2003 11:11:14 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 11:11:11 -0500 Subject: Re: AD to zeroconf WG From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122105300.7cd3fbbf.moore@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 01/22/2003 10:53, "Keith Moore" wrote: > LL, as currently designed, only addresses the first goal, but it doesn't play > well on connected networks. It appears that it can be modified with little > difficulty to allow it to address the first three goals. The discussion for > the last few days has been productive at exploring the technical details of > how to do this. And the last item is not a desirable goal. It would be in a hospital so that you could connect things like EKGs and other monitoring devices to things like palm pilots, or multiple monitoring stations. You would, in that case, want to make it as hard as possible for that type of data to get out on the public Internet. Law Enforcement would benefit from this 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 Wed Jan 22 11:13:36 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29468 for ; Wed, 22 Jan 2003 11:13:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD70D9137F; Wed, 22 Jan 2003 11:15:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B8F291383; Wed, 22 Jan 2003 11:15: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 7608E9137F for ; Wed, 22 Jan 2003 11:15:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9688A5DECE; Wed, 22 Jan 2003 11:15:15 -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 D7B505DF87 for ; Wed, 22 Jan 2003 11:15:13 -0500 (EST) Received: from mail6.microsoft.com ([157.54.6.196]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 22 Jan 2003 08:15:12 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 22 Jan 2003 08:15:12 -0800 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 22 Jan 2003 08:15:12 -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); Wed, 22 Jan 2003 08:15:12 -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); Wed, 22 Jan 2003 08:15:11 -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.3718.0); Wed, 22 Jan 2003 08:15:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: WG decision: when to configure LL addrs Date: Wed, 22 Jan 2003 08:14:09 -0800 Message-ID: Thread-Topic: WG decision: when to configure LL addrs Thread-Index: AcLCJXwvDCx/5NZGRfqVMvOGCJ00/QAC9mXA From: "Christian Huitema" To: "Thomas Narten" , X-OriginalArrivalTime: 22 Jan 2003 16:15:11.0623 (UTC) FILETIME=[707D2170:01C2C231] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA29468 > So, I would like to ask the WG to answer the following questions: > > 1) Should the ID recommend that LL addresses only be configured as per > below. Please answer clearly, along the lines of > > a) yes, I think this is what the document should say (maybe with > some small tweaks, which then need to be explained) Yes. -- Christian Huitema From owner-zeroconf@merit.edu Wed Jan 22 11:15:44 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29522 for ; Wed, 22 Jan 2003 11:15:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0F43E91386; Wed, 22 Jan 2003 11:18:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8800A91388; Wed, 22 Jan 2003 11:18: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 7892791383 for ; Wed, 22 Jan 2003 11:17:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 602685DE95; Wed, 22 Jan 2003 11:17:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id E48105DECE for ; Wed, 22 Jan 2003 11:17:02 -0500 (EST) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id LAA12669; Wed, 22 Jan 2003 11:16:53 -0500 (EST) From: "Subrata Goswami" To: "'Keith Moore'" Cc: Subject: RE: problems with using DHCP (was: one last attempt to illustrate my concerns) Date: Wed, 22 Jan 2003 08:11:18 -0800 Message-ID: <006301c2c230$e9c3d7a0$02a2fea9@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20030122110626.77a2c8f8.moore@cs.utk.edu> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Well, a $30.0 router/nat box from Liksys/Dlink/3Com after your DSL modem should give you access to many more 192.168/16 IP addresses. Subrata > -----Original Message----- > From: owner-zeroconf@merit.edu > [mailto:owner-zeroconf@merit.edu] On Behalf Of Keith Moore > Sent: Wednesday, January 22, 2003 8:06 AM > To: John C. Welch > Cc: moore@cs.utk.edu; zeroconf@merit.edu > Subject: problems with using DHCP (was: one last attempt to > illustrate my concerns) > > > > > My computer, since it is configured via DHCP has its v4LL > capabilities > > disabled. It can not use a v4LL address. Period. This is > what disabled > > means. Not functional. > > no, this is not what was intended. > > what was intended is if your computer gets an address from > DHCP it should not attempt to acquire a v4LL address. > however, the lack of a v4LL address should not stop it from > attempting to talk to a v4LL address on one of its interfaces. > > -- > > However this did cause me to realize a problem with the idea > that any DHCP service should suffice to disable v4LL. > > I have a DSL modem at home. As shipped, that modem had a > DHCP server that assigned a RFC 1918 address to the first > host that asked for an address. It would do NAT (arrgh) > between that address and the address assigned to the DSL line > by the ISP.[*] However it would NOT NAT for multiple devices > and it woudl NOT honor any subsequent DHCP requests for > addresses by other hosts on the network. > > So imagine a home network with a DSL modem like mine, an > Ethernet hub, and two hosts - a windows or mac box and a > zeroconf printer. If the windows or mac box asks DHCP for an > address first, then all is well - the windows or mac box can > talk externally, and it can talk to the printer's v4LL > address. On the other hand if the printer asks DHCP for an > address first, then the printer can accept connections from > anywhere in the network, but the windows or mac box will be > isolated. And the poor clueless user has to reboot the cable > modem, *then* reboot the windows or mac box, or something. > That's a lousy arrangement. > > Now this is a limited sample space, and maybe that's just an > anomaly with this one DSP modem, but I've heard that this > kind of behavior is common. If so then what we need is some > more explicit way for a network to say "don't use LL" than > just the presence of a DHCP server. > > Keith > > [*] fortunately I was able to configure the modem to operate > in PPPoE mode, which gets rid of the NAT, and allows me to > run 6to4 to talk to my home machines. > From owner-zeroconf@merit.edu Wed Jan 22 11:15:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29532 for ; Wed, 22 Jan 2003 11:15:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CCE0891384; Wed, 22 Jan 2003 11:18:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 754149138C; Wed, 22 Jan 2003 11:18: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 A71CC91387 for ; Wed, 22 Jan 2003 11:18:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8C0D45DEAF; Wed, 22 Jan 2003 11:18: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 217E25DEAB for ; Wed, 22 Jan 2003 11:18: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 LAA17158 for ; Wed, 22 Jan 2003 11:18: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 LAA11579 for ; Wed, 22 Jan 2003 11:18:17 -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 LAA20250 for ; Wed, 22 Jan 2003 11:18:16 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 11:18:14 -0500 Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122110626.77a2c8f8.moore@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 01/22/2003 11:06, "Keith Moore" wrote: > >> My computer, since it is configured via DHCP has its v4LL capabilities >> disabled. It can not use a v4LL address. Period. This is what disabled >> means. Not functional. > > no, this is not what was intended. > > what was intended is if your computer gets an address from DHCP it should not > attempt to acquire a v4LL address. however, the lack of a v4LL address should > not stop it from attempting to talk to a v4LL address on one of its > interfaces. Okay, but now we are getting into this odd 'v4LL' is kind of off, but kind of on. And if you have a computer with only one interface, (common enough, I have a dualie 800 G4 with only one interface, it's a UTGOTY server among other things), then the 'oh, you can use another interface' is not an option. Look, I understand that stuff will break if you have v4LL addresses all the time. That's a pain, but heck, v6 will break stuff, DHCP broke stuff too. All change breaks stuff. Such is life. But, one of the things I *hated* coding around, (when I was silly enough to program for a living), was 'sometimes'. Sometimes is a real pain to deal with. Always is a pain too, but planning for 'always' and dealing with 'always' is *far* easier than dealing with 'sometimes'. If you have the shutoff be manual only, with proper user notification, then you get far closer to the best of both worlds, and you get 'always' far more often. > > Now this is a limited sample space, and maybe that's just an anomaly with this > one DSP modem, but I've heard that this kind of behavior is common. If so > then what we need is some more explicit way for a network to say "don't use > LL" than just the presence of a DHCP server. ...it's not uncommon at all. It's real common in fact. Which is why a manual shutoff is going to be the simplest, and most elegant way to handle this. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 11:21:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29651 for ; Wed, 22 Jan 2003 11:21:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9DA07912FE; Wed, 22 Jan 2003 11:25:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 68E8F91383; Wed, 22 Jan 2003 11: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 57259912FE for ; Wed, 22 Jan 2003 11:25:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 403E25DEB1; Wed, 22 Jan 2003 11:25:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtp.covadmail.net (mx03.covadmail.net [63.65.120.63]) by segue.merit.edu (Postfix) with SMTP id E9C725DEAB for ; Wed, 22 Jan 2003 11:25:01 -0500 (EST) Received: (covad.net 20181 invoked from network); 22 Jan 2003 16:25:01 -0000 Received: from unknown (HELO STUDY) (66.167.13.195) by sun-qmail07 with SMTP; 22 Jan 2003 16:25:01 -0000 To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: WG decision: when to configure LL addrs References: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> From: Scott Lawrence Date: 22 Jan 2003 11:26:57 -0500 In-Reply-To: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> Message-ID: Lines: 53 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-zeroconf@merit.edu Precedence: bulk Thomas Narten writes: > 1) Should the ID recommend that LL addresses only be configured as per > below. Thank you, Thomas. > - when should an IPv4LL address be configured by a host? > > suggest: if the host is explicitly configured to do so, OR > if the host has attempted and failed to acquire a routable address via DHCP Agreed, but I think that 'a routable' should be changed to just 'an'; routing is not the issue here; getting some address is. If I get a non-routable 10.x.y.z address, I don't need a LL address. > - when should an IPv4LL address be used by a host as a source address? > suggest: when the only addresses available to the host are IPv4LL addresses, OR > when the application has explicitly specified the source address to use, OR > when the application has explicitly specified the interface to use and the IPv4LL address > is the only address associated with that interface. Fine. > - when should a host honor an attempt to connect to an IPv4LL address that was once > configured by that host? > suggest: anytime the address is still valid (e.g. there have been no conflicting claims) > and there is a process listening for connections either specifically to that address or > for incoming connections at any of the host's addresses. I'm not sure why this needs to be said - it seems to me to be the normal behaviour for an IP interface, but fine. > - when should an application attempt to connect to a IPv4LL address? > suggest: only when the address is literally specified, or if there are no other routable > addresses for the destination host known to the application. I think that this question should be 'when should a host use an IPv4LL destination address?'. The answer given is fine. > - when should an application send an IPv4LL address in a referral to another host? > suggest: only when there are no routable addresses for the destination host known to the > application. even then, care needs to be taken that a host reached at a particular > IPv4LL address is really the one intended - since IPv4LL addresses can be reassigned > without notice and/or reused on different network segments. I think that both this and the previous question are obvious to any reasonable person who understands what a link-local address means, but if the WG feels that explicit text for this case is needed, fine. From owner-zeroconf@merit.edu Wed Jan 22 11:23:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29719 for ; Wed, 22 Jan 2003 11:23:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 21DA591383; Wed, 22 Jan 2003 11:26:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E14AB91387; Wed, 22 Jan 2003 11:26: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 03F4291383 for ; Wed, 22 Jan 2003 11:26:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id E5F095DEAE; Wed, 22 Jan 2003 11:26:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 54C095DEAB for ; Wed, 22 Jan 2003 11:26:29 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0MGQJR03706; Wed, 22 Jan 2003 23:26:19 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0MGQB813377; Thu, 23 Jan 2003 03:26:12 +1100 (EST) From: Robert Elz To: "John C. Welch" Cc: Zeroconf Subject: Re: One last attempt to illustrate my concerns In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Jan 2003 23:26:11 +0700 Message-ID: <13375.1043252771@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 22 Jan 2003 10:43:30 -0500 From: "John C. Welch" Message-ID: | But if you're going to go through all the trouble to communicate with v4LL | devices, It is no trouble, it "just works". If you don't understand how & why, then .... (rewind to an earlier message). | why not just take the last step and give them the address too? It's | simpler, and easier to plan for if it's *always* there. It isn't simpler. Actually allocating the address is easy enough (though unnecessary), but now the node has two addresses, and both it and every other node, has to continually try to work out which one of the two should be used. That isn't simpler, for anything. kre From owner-zeroconf@merit.edu Wed Jan 22 11:26:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29810 for ; Wed, 22 Jan 2003 11:26:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AE3E991387; Wed, 22 Jan 2003 11:29:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CDB691388; Wed, 22 Jan 2003 11:29: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 370BE91387 for ; Wed, 22 Jan 2003 11:29:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1F8CA5DEB1; Wed, 22 Jan 2003 11:29:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id ABC785DEAE for ; Wed, 22 Jan 2003 11:29:33 -0500 (EST) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id LAA16496; Wed, 22 Jan 2003 11:29:26 -0500 (EST) From: "Subrata Goswami" To: "'Thomas Narten'" Cc: Subject: RE: WG decision: when to configure LL addrs Date: Wed, 22 Jan 2003 08:23:52 -0800 Message-ID: <006601c2c232$a794dee0$02a2fea9@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <4.3.2.7.2.20030122100243.03e0fef0@wells.cisco.com> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yes to 1. No to 2,3,4,5 as they are unduly restrictive, confusing in multiple interface hosts, and requires the hosts to be more intelligent then they need to be. > -----Original Message----- > From: owner-zeroconf@merit.edu > [mailto:owner-zeroconf@merit.edu] On Behalf Of John Schnizlein > Sent: Wednesday, January 22, 2003 7:13 AM > To: Thomas Narten > Cc: zeroconf@merit.edu > Subject: Re: WG decision: when to configure LL addrs > > > Yes to all 5 rules, but with the tweak that the alternative > "lighter weight mechanism" is too poorly specified to be > considered at this time. > > Thank you for your concrete path forward. > John > > At 09:50 AM 1/22/2003, Thomas Narten wrote: > >Should the ID recommend that LL addresses only be configured as per > > below. > > > > a) yes, I think this is what the document should say (maybe > > with some small tweaks, which then need to be explained) > > > > b) no, this is a showstopper for me (and explain why, so the > > rest of the WG can understand and then agree or disagree > > with your position) > > > > c) Not my first choice, but I can live with it. > > > >Keith Moore writes: > > > >> On Wed, 22 Jan 2003 10:01:30 +1000 (EST) > >> > >> 1 when should an IPv4LL address be configured by a host? > > > >> suggest: if the host is explicitly configured to do so, > OR if the > >> host has attempted and failed to acquire a routable address via > >> DHCP > > > >> (alternative: provide a lighter weight mechanism by which a host > >> can acquire a routable address, netmask, and default route, in > >> response to its attempt to claim an IPv4LL address) > > > >> 2 when should an IPv4LL address be used by a host as a source > >> address? > > > >> suggest: when the only addresses available to the host > are IPv4LL > >> addresses, OR when the application has explicitly specified the > >> source address to use, OR when the application has explicitly > >> specified the interface to use and the IPv4LL address is the > >> only address associated with that interface. > > > >> 3 when should a host honor an attempt to connect to an IPv4LL > >> address that was once configured by that host? > > > >> suggest: anytime the address is still valid (e.g. there have > >> been no conflicting claims) and there is a process listening > >> for connections either specifically to that address or > >> for incoming connections at any of the host's addresses. > > > >> 4 when should an application attempt to connect to a > IPv4LL address? > > > >> suggest: only when the address is literally specified, > >> or if there are no other routableaddresses for the destination > >> host known to the application. > > > >> 5 when should an application send an IPv4LL address in a referral > >> to another host? > > > >> suggest: only when there are no routable addresses for the > >> destination host known to the application. > >> Even then, care needs to be taken that a host reached at > a particular > >> IPv4LL address is really the one intended - since IPv4LL > addresses > >> can be reassigned without notice and/or reused on > different network > >> segments. > From owner-zeroconf@merit.edu Wed Jan 22 11:33:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00060 for ; Wed, 22 Jan 2003 11:33:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1C65C91301; Wed, 22 Jan 2003 11:35:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D79D89138E; Wed, 22 Jan 2003 11:35: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 32E5791301 for ; Wed, 22 Jan 2003 11:35:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 16BE35DE31; Wed, 22 Jan 2003 11:35:12 -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 9C7325DE83 for ; Wed, 22 Jan 2003 11:35:11 -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 LAA27429 for ; Wed, 22 Jan 2003 11:35:11 -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 LAA15262 for ; Wed, 22 Jan 2003 11:35:10 -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 LAA28598 for ; Wed, 22 Jan 2003 11:35:10 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 11:35:08 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <13375.1043252771@munnari.OZ.AU> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 01/22/2003 11:26, "Robert Elz" wrote: > It is no trouble, it "just works". If you don't understand how & why, > then .... (rewind to an earlier message). I understand how and why. I just find it an overly complex method to avoid something and still use it. > > | why not just take the last step and give them the address too? It's > | simpler, and easier to plan for if it's *always* there. > > It isn't simpler. Actually allocating the address is easy enough > (though unnecessary), but now the node has two addresses, and both it > and every other node, has to continually try to work out which one of > the two should be used. That isn't simpler, for anything. The methodologies for this are well understood, and provides a more consistent set of circumstances. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 11:40:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00273 for ; Wed, 22 Jan 2003 11:40:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1E63C91305; Wed, 22 Jan 2003 11:44:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFB5391306; Wed, 22 Jan 2003 11:44:04 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B3AF591305 for ; Wed, 22 Jan 2003 11:44:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9DFC05DECE; Wed, 22 Jan 2003 11:44:03 -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 5EB4F5DEB4 for ; Wed, 22 Jan 2003 11:44:03 -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); Wed, 22 Jan 2003 08:44:01 -0800 Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 22 Jan 2003 08:44:01 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Wed, 22 Jan 2003 08:44:00 -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); Wed, 22 Jan 2003 08:44:00 -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.3718.0); Wed, 22 Jan 2003 08:44:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Turning off link-locals? Date: Wed, 22 Jan 2003 08:42:53 -0800 Message-ID: Thread-Topic: Turning off link-locals? Thread-Index: AcLB+vbmd3Lx6zWdQdWhsgrt/tBnpgAOVQFw From: "Christian Huitema" To: "Robert Elz" Cc: "Daniel Senie" , "Zeroconf" X-OriginalArrivalTime: 22 Jan 2003 16:44:00.0485 (UTC) FILETIME=[76F88950:01C2C235] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA00273 > | Not really. Adam MacBeth is correct: Windows (including the recent > | versions) will first try to get a DHCP address for about 1 minute, > > And one assumes, that should there be lots of complaints about the time > that is taking (compared to other things happening in parallel that > people are waiting for anyway - virus scanners and such), then the > amount of effort it would take to lower that minute to 10 seconds, or > something, would not bankrupt Microsoft? (Ignoring distribution, > those who want the mod can just fetch a patch). The purpose of my message was to document what is actually implemented. I have heard several types of complaints: that the initial set-up takes too long; that it takes too long to go back to DHCP assigned addresses once the stack has chosen to use auto-IP; and that the host should keep an allocated DHCP address even if the DHCP server is momentarily unavailable when it tries to renew. The "too slow" complaint is mostly an issue with mobile devices plugging in an ad hoc network; it is not a big issue in home networks, as most home routers tend to have a DHCP server anyhow; my preferred solution for mobile hosts in ad hoc networks would be to just use IPv6. -- Christian Huitema From owner-zeroconf@merit.edu Wed Jan 22 11:45:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00446 for ; Wed, 22 Jan 2003 11:45:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5A46991304; Wed, 22 Jan 2003 11:48:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D85891302; Wed, 22 Jan 2003 11:48: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 D6CB691304 for ; Wed, 22 Jan 2003 11:47:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id B34BB5DE37; Wed, 22 Jan 2003 11:47:48 -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 47A285DE24 for ; Wed, 22 Jan 2003 11:47:48 -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 LAA04326 for ; Wed, 22 Jan 2003 11:47:47 -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 LAA18014 for ; Wed, 22 Jan 2003 11:47:47 -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 LAA05021 for ; Wed, 22 Jan 2003 11:47:47 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 11:47:45 -0500 Subject: On manual control of v4LL From: "John C. Welch" To: Zeroconf Message-ID: 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 LAA00446 You know, it occurs to me that maybe trying to make the v4LL switch automatic isn't the way to go. Think about this, it brings up all kinds of issues, like authentication, notification, communicating with v4LL without an address, ad nauseum. It's going to take three pages at least to properly define, and there's going to be a half - dozen loopholes. But what if we don't make it automatic in the face of DHCP, or creating some other protocol to turn it off? Why NOT make it manual? It really answers a lot of problems: 1) Authentication. If you make it a manual process, that needs either direct human contact to run a command to turn it off, or a script, then you can use existing authentication mechanisms transparently. SSH, SSL, Kerberos, etc, blah. We already *know* how to handle manual configs. 2) Convenience for user and network admin. If your machine is a home machine, great, v4LL is on, so most home uses are covered, bob's your uncle. If it's on a network that disallows v4LL, then you turn it off, and it's off. Not kind of off, not 'only no address off', but off. Zeroconf is less of a need here, you have ITConf, and you most likely DON'T want users configuring their machines anyway. Now, how about dual use machines? Well, Apple at least, and most other OS's have a way to deal with multiple configurations, so you can have a 'home' and a 'work' setup. 'home' has v4LL on, 'work' does not. 3) it makes handling the existence of v4LL programmatically far more predictable. You can either update code to deal with it, or not. If not, put in warnings about it, and if people insist on using your app anyway, then they're being silly. But either way, you have more of a binary issue. 4) It's a lot simpler to implement. It doesn¹t *have* to have a UI switch. It could be a standalone app, a new option in ifconfig, whatever. It avoids rogue DHCP servers from killing v4LL inappropriately. It makes it easier to keep it off if needed. It provides authentication without adding in MORE STUFF. It allows home users to not have to worry about cases like the one Keith ran into. It allows people in environments where v4LL will be a problem to turn it *off* It seems to me, that sometimes, manual is the way to go, and this seems to be a really simple, elegant way to answer all concerns. And it's a quick read: All v4LL implementations MUST have a manual way to shut off v4LL. This SHALL be the only way to turn off v4LL. I mean...that's 95% of it in two sentences. Not many loopholes. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 12:00:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01095 for ; Wed, 22 Jan 2003 12:00:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 691C891306; Wed, 22 Jan 2003 12:03:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E796912E9; Wed, 22 Jan 2003 12: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 348A191306 for ; Wed, 22 Jan 2003 12:02:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0ED5F5DEB4; Wed, 22 Jan 2003 12:02:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 8F9105DEA5 for ; Wed, 22 Jan 2003 12:02:28 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-237.cisco.com [10.82.240.237]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id h0MH2PuW007814; Wed, 22 Jan 2003 09:02:25 -0800 (PST) Message-Id: <4.3.2.7.2.20030122115827.00b24fe0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Jan 2003 12:02:25 -0500 To: "John C. Welch" From: John Schnizlein Subject: Re: On manual control of v4LL Cc: Zeroconf In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk At 11:47 AM 1/22/2003, John C. Welch wrote: >... >It avoids rogue DHCP servers from killing v4LL inappropriately. It makes it >easier to keep it off if needed. It provides authentication without adding >in MORE STUFF. It allows home users to not have to worry about cases like >the one Keith ran into. It allows people in environments where v4LL will be >a problem to turn it *off* Why do you think rogue DHCP servers are more of a threat than rogue v4LL hosts? >It seems to me, that sometimes, manual is the way to go, and this seems to >be a really simple, elegant way to answer all concerns. Is your goal the technology of link-local addresses, or minimizing configuration effort for most users? >And it's a quick read: > >All v4LL implementations MUST have a manual way to shut off v4LL. This SHALL >be the only way to turn off v4LL. John From owner-zeroconf@merit.edu Wed Jan 22 12:12:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01343 for ; Wed, 22 Jan 2003 12:12:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5B61791307; Wed, 22 Jan 2003 12:15:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB1FC91309; Wed, 22 Jan 2003 12:15: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 83F0091307 for ; Wed, 22 Jan 2003 12:15:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id D0BCC5DEB9; Wed, 22 Jan 2003 12:15:08 -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 B2B5A5DEB4 for ; Wed, 22 Jan 2003 12:15:07 -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 MAA23221 for ; Wed, 22 Jan 2003 12:15: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 MAA23661 for ; Wed, 22 Jan 2003 12:15:06 -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 MAA18196 for ; Wed, 22 Jan 2003 12:15:06 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 12:15:04 -0500 Subject: Re: On manual control of v4LL From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <4.3.2.7.2.20030122115827.00b24fe0@wells.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 01/22/2003 12:02, "John Schnizlein" wrote: >> It avoids rogue DHCP servers from killing v4LL inappropriately. It makes it >> easier to keep it off if needed. It provides authentication without adding >> in MORE STUFF. It allows home users to not have to worry about cases like >> the one Keith ran into. It allows people in environments where v4LL will be >> a problem to turn it *off* > > Why do you think rogue DHCP servers are more of a threat than rogue v4LL > hosts? Because I work at MIT, and it would be a fun prank to build a little wireless device whose entire purpose in life would be to broadcast just enough DHCP packets to kill off v4LL. It's not a real hard thing to do, building a 'Zeroconf wireless deathtrap'. I used to build IR deathtraps when I played LaserTag...all you needed was a trainable remote and some duct tape, and the fun began. I have no faith in humans beyond their amazing ability to piss on someone else's parade. There's no easy way to authenticate that a given DHCP server is *allowed* to kill v4LL. Keith showed a reason why using DHCP can be a bad idea in a fairly common setup. An additional problem is that under Windows XP, with a wired and wireless interface, it's a little too easy to accidentally set up your laptop to be an unauthorized DHCP server. That's not malicious, but it would effectively kill every v4LL device in range. Manual only control is convenient, without being onerous. It's a simple setup, and easy to script. It's harder to accidently use, with proper use of permissions/ACLs, you can lock it down tight. > >> It seems to me, that sometimes, manual is the way to go, and this seems to >> be a really simple, elegant way to answer all concerns. > > Is your goal the technology of link-local addresses, or minimizing > configuration effort for most users? Both. With Manual config, you ship with v4LL on. So now you have a consistent shipping config. Easy to plan for. Oh, you don't want your network to use v4LL. Fine, no problem. It's easily turned off, but not by 'some machine'. Network management tools allow for you to remotely execute commands on managed machines. It is a FAR simpler way to please both sides, and isn't as complicated as the DHCP/BootP proposals I've seen here. It's even automatable, but far more controllable than other methods. It *seems* to work really well, which is why I'm a little nervous about proposing it...it seems too simple...but I can't come up with a reason not to do it that way. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 13:02:44 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02449 for ; Wed, 22 Jan 2003 13:02:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2861E91390; Wed, 22 Jan 2003 13:05:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A60AB91399; Wed, 22 Jan 2003 13:05: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 4194C9139B for ; Wed, 22 Jan 2003 13:04:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 215745DE4E; Wed, 22 Jan 2003 13:04:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from first.cove-mtn.com (unknown [208.187.205.91]) by segue.merit.edu (Postfix) with ESMTP id 4DC665DE24 for ; Wed, 22 Jan 2003 13:04:15 -0500 (EST) Received: from cove-mtn.com (dante.cove-mtn.com [172.31.2.255]) by first.cove-mtn.com (8.12.5/8.12.4) with ESMTP id h0MI4R7g026094 for ; Wed, 22 Jan 2003 11:04:27 -0700 (MST) Message-ID: <3E2EDD18.4070101@cove-mtn.com> Date: Wed, 22 Jan 2003 11:04:08 -0700 From: Brad Davis User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en,zh-TW MIME-Version: 1.0 To: zeroconf@merit.edu Subject: Proposed changes to the document Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit (I know this will cause a bit of heartburn): General: As has been pointed out, IPv4LL addresses (as defined here) are not link local addresses but subnet local addresses (SL?). I feel we need to change the terminology in the document because LL implies a level of security that doesn't exist. Almost everyone outside these discussions (and it seems many inside them) will assume that the address doesn't pass beyond the local network. Section 1.2, Applicability: Limiting this draft to 802 media means that this draft may not be applicable in a home network. Bluetooth, HomePlug, HomePNA, IEEE 1394, and USB have all been promoted as the technology to network the home (as opposed to traditional 802 media). Any proposal that limits itself to 802 media and claims to support home networking is just bad (especially since IP over HomePlug and HomePNA is deployed, and 1394 is being pushed by some of the large CE companies). Section 5, Security Considerations: It should be pointed out that because these are subnet local addresses, their "physical" scope may easily range far beyond what a user considers the "local network". This will occur in any WAN/MAN that uses bridging rather than routing at the leafs (an example of this is the original CableLab's cable modem), the "LL" address may (unless specifically blocked by something) will have scope over the entire subnet, including other homes or businesses. "LL" devices will be open to attacks that aren't expected by the (naive) user. (Of course, implementing security on a zeroconf device is somewhat of an oxymoron and having to tell a (naive) user that their new device will randomly disappear from their home network is bad.) Brad Davis From owner-zeroconf@merit.edu Wed Jan 22 13:02:46 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02462 for ; Wed, 22 Jan 2003 13:02:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 69ACB91399; Wed, 22 Jan 2003 13:05:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66A159139C; Wed, 22 Jan 2003 13:05: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 6B27B9139E for ; Wed, 22 Jan 2003 13:04:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 584C05DE24; Wed, 22 Jan 2003 13:04:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 260D85DE4E for ; Wed, 22 Jan 2003 13:04:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id E8CB314141; Wed, 22 Jan 2003 13:04:29 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 14090-04; Wed, 22 Jan 2003 13:04:29 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 534CF14047; Wed, 22 Jan 2003 13:04:29 -0500 (EST) Date: Wed, 22 Jan 2003 13:04:29 -0500 From: Keith Moore To: "Subrata Goswami" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) Message-Id: <20030122130429.5a65c819.moore@cs.utk.edu> In-Reply-To: <006301c2c230$e9c3d7a0$02a2fea9@SGOSWAMIPCL> References: <20030122110626.77a2c8f8.moore@cs.utk.edu> <006301c2c230$e9c3d7a0$02a2fea9@SGOSWAMIPCL> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 747e726568e4d2a9014efea75d58753972551195 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 22 Jan 2003 08:11:18 -0800 "Subrata Goswami" wrote: > Well, a $30.0 router/nat box from Liksys/Dlink/3Com after your DSL > modem should give you access to many more 192.168/16 IP addresses. two wrongs don't make a right, and two NATs don't let applications that need a global address work. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 13:09:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02623 for ; Wed, 22 Jan 2003 13:09:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4CC099130C; Wed, 22 Jan 2003 13:12:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 142E09138D; Wed, 22 Jan 2003 13: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 A72C19130C for ; Wed, 22 Jan 2003 13:12:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 92D125DE37; Wed, 22 Jan 2003 13:12:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 7AC575DDD9 for ; Wed, 22 Jan 2003 13:12:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 470EE14146; Wed, 22 Jan 2003 13:12:32 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 14711-10; Wed, 22 Jan 2003 13:12:31 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 9DD3F14141; Wed, 22 Jan 2003 13:12:31 -0500 (EST) Date: Wed, 22 Jan 2003 13:12:31 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122131231.2ebe0bf1.moore@cs.utk.edu> In-Reply-To: References: <200301221516.h0MFG0M12033@cichlid.adsl.duke.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 6003e342cb99289b4a34863434d8ab4d49c62795 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I fully realize that there are things that v4LL on all the time will > break. Having seen that they are what could easily be considered edge > cases for simple networks, and that these applications can be updated > to deal with this, then I simply cannot agree that turning off v4LL as > an automatic function of other configurations is a good idea. The cases that break are not edge cases (or at least, that characterization seems rather arbitrary), and the applications cannot always be updated to deal with this, particularly when they are expected to deal with a mixture of devices some of which have ambiguous addresses and some of which don't. > Now, since there are times when you would want this shut off, any > earlier objections I may have had to requiring a manual shutoff are > removed. Manual shutoff is desirable for devices that can be manually configured, but not sufficient. There needs to be some way for the network to specify whether LL is allowed on the link. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 13:10:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02643 for ; Wed, 22 Jan 2003 13:10:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DE2129138D; Wed, 22 Jan 2003 13:13:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B111E9138E; Wed, 22 Jan 2003 13:13: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 A7DF69138D for ; Wed, 22 Jan 2003 13:13:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F5745DE37; Wed, 22 Jan 2003 13:13:19 -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 0F2F85DDD9 for ; Wed, 22 Jan 2003 13:13:19 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0MI8qP18970; Wed, 22 Jan 2003 12:08:52 -0600 (CST) Date: Wed, 22 Jan 2003 10:13:27 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Philip Nye" , "Joshua Graessley" , "Zeroconf" To: Robert Elz From: Ted Lemon In-Reply-To: <12410.1043245743@munnari.OZ.AU> Message-Id: <3450D7C8-2E35-11D7-AFDA-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > So, it is likely that LL addresses will only ever be discovered via > some > mechanism like mDNS. Then it is up to the owner of the address to > decide > what to return, and if there's a global address, I'd suggest, returning > just that is optimal. In order for mDNS to be really useful, gethostbyname("foo.local.") has to work. So unfortunately your reasoning here doesn't work. > | What does the machine do if the DHCP server is present but refuses > it an > | address? This probably indicates that the network manager does not > want this > | machine on the link. > > If it isn't supposed to be on the link, then it shouldn't automatically > put itself there (if some human wants to explicitly configure it to > exist there, if that is possible for the device in question, then that > person takes responsibility for that). DHCP doesn't provide a protocol message that says "I'm here, but I'm not going to give you an IP address." So a client that can't contact a DHCP server has no way of telling whether this is because there is no DHCP server, or because the DHCP server doesn't like it. From owner-zeroconf@merit.edu Wed Jan 22 13:11:12 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02670 for ; Wed, 22 Jan 2003 13:11:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 167E29138E; Wed, 22 Jan 2003 13:14:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D77429138F; Wed, 22 Jan 2003 13:14: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 B9FD59138E for ; Wed, 22 Jan 2003 13:14:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id A25135DE37; Wed, 22 Jan 2003 13:14:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 8A7205DDD9 for ; Wed, 22 Jan 2003 13:14:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 6119F14146; Wed, 22 Jan 2003 13:14:29 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 15022-08; Wed, 22 Jan 2003 13:14:28 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id C052414141; Wed, 22 Jan 2003 13:14:28 -0500 (EST) Date: Wed, 22 Jan 2003 13:14:28 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122131428.16cdc035.moore@cs.utk.edu> In-Reply-To: References: <3E2EB9EA.6000207@nc.rr.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: ce49a69ab6be26de553dda2671f9246afe84a04b Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > But if you're going to go through all the trouble to communicate with > v4LL devices, why not just take the last step and give them the > address too? 1. because this forces apps to deal with the extra complexity of being aware of network topology and having to choose between addresses of different scopes. 2. because the addresses will leak into areas of the network in which they are not valid. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 13:15:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02718 for ; Wed, 22 Jan 2003 13:15:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6E10C9138F; Wed, 22 Jan 2003 13:18:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40C7591391; Wed, 22 Jan 2003 13: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 CAE299138F for ; Wed, 22 Jan 2003 13:18:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id B2E8B5DE24; Wed, 22 Jan 2003 13:18:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 9A48E5DDD9 for ; Wed, 22 Jan 2003 13:18:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 675AB14146; Wed, 22 Jan 2003 13:18:03 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 16176-04; Wed, 22 Jan 2003 13:18:02 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id CAC0814141; Wed, 22 Jan 2003 13:18:02 -0500 (EST) Date: Wed, 22 Jan 2003 13:18:02 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030122131802.0d627f2b.moore@cs.utk.edu> In-Reply-To: References: <20030122103601.70330403.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: d902cd3569a07faaa491d785ddbfd6c18965c043 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > In my case, it means "I'm absolutely cynical about people doing the > right thing. I assume they won't, and it is *far* better to deal with > it now, than hope for the best and get burned yet again" I share your cynicism about people doing the right thing. But if we don't do the right thing when we ship a spec (which means to give due consideration to how it will affect IP applications, networks, and users), how can we even hope to avoid giving people even more difficult choices down the road, where the "right thing" will not be nearly so obvuious? -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 13:18:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02772 for ; Wed, 22 Jan 2003 13:18:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ABEB791391; Wed, 22 Jan 2003 13:19:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50D7991393; Wed, 22 Jan 2003 13:19:34 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0832791391 for ; Wed, 22 Jan 2003 13:19:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id EACED5DE24; Wed, 22 Jan 2003 13:19:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id D1C565DDD9 for ; Wed, 22 Jan 2003 13:19:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id A8A4E14146; Wed, 22 Jan 2003 13:19:28 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 16312-03; Wed, 22 Jan 2003 13:19:28 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 1B58D14141; Wed, 22 Jan 2003 13:19:28 -0500 (EST) Date: Wed, 22 Jan 2003 13:19:27 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030122131927.316cde84.moore@cs.utk.edu> In-Reply-To: References: <20030122104130.7ba56df5.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 45d7f02af9137483fe547b157c36a4ef8c7db937 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > there is no good reason for a device to assume > > that its access should be limited to the local link. > > There is no logic in assuming that there won't be either. actually there is plenty of reason to assume that - it is almost never the case today that a single link is chosen as a trust boundary, and with greater use of wireless it becoming less and less useful to assume that network topology has anything to do with trust boundaries. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 13:21:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02906 for ; Wed, 22 Jan 2003 13:21:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1528E91392; Wed, 22 Jan 2003 13:24:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D417D91393; Wed, 22 Jan 2003 13:24:32 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CAF0D91392 for ; Wed, 22 Jan 2003 13:24:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id B2BF55DEAD; Wed, 22 Jan 2003 13:24:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 32B635DE37 for ; Wed, 22 Jan 2003 13:24:31 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0MIK9P19191; Wed, 22 Jan 2003 12:20:09 -0600 (CST) Date: Wed, 22 Jan 2003 10:24:44 -0800 Subject: Re: WG decision: when to configure LL addrs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Thomas Narten From: Ted Lemon In-Reply-To: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> - when should an IPv4LL address be configured by a host? > >> suggest: if the host is explicitly configured to do so, OR >> if the host has attempted and failed to acquire a routable address >> via DHCP This doesn't satisfy me because it requires that an arbitrary delay before I can use my zeroconf network. I say arbitrary because the DHCP protocol doesn't really say how to determine that the client is not going to win, so the delay here could be anywhere from three seconds to five minutes or longer. Zeroconf should Just Work, and in order for that to happen, the delay here has to be short. I would be satisfied if the delay were shorter than ten seconds. >> - when should an application send an IPv4LL address in a referral to >> another host? > >> suggest: only when there are no routable addresses for the >> destination host known to the >> application. even then, care needs to be taken that a host reached >> at a particular >> IPv4LL address is really the one intended - since IPv4LL addresses >> can be reassigned >> without notice and/or reused on different network segments. How about only when the IP destination to which the referral is being sent is an IPv4LL address? If you send the referral to a routable IP address that may be on another network, it's quite possible that the referral could *work* on that remote network - to connect to an IPv4LL address on that remote network. From owner-zeroconf@merit.edu Wed Jan 22 13:21:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02922 for ; Wed, 22 Jan 2003 13:21:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EFACD91393; Wed, 22 Jan 2003 13:24:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8ABA91395; Wed, 22 Jan 2003 13:24: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 D0DA391393 for ; Wed, 22 Jan 2003 13:24:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id B46C75DDD9; Wed, 22 Jan 2003 13:24:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 9C31A5DDB7 for ; Wed, 22 Jan 2003 13:24:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 6999D1404A; Wed, 22 Jan 2003 13:24:46 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 17069-01; Wed, 22 Jan 2003 13:24:45 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id C22B21403F; Wed, 22 Jan 2003 13:24:45 -0500 (EST) Date: Wed, 22 Jan 2003 13:24:45 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) Message-Id: <20030122132445.5da26f53.moore@cs.utk.edu> In-Reply-To: References: <20030122110626.77a2c8f8.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 662deb7329b81e73ddd011e59f4bdb062ddcfded Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > Now this is a limited sample space, and maybe that's just an anomaly > > with this one DSP modem, but I've heard that this kind of behavior > > is common. If so then what we need is some more explicit way for a > > network to say "don't use LL" than just the presence of a DHCP > > server. > > ...it's not uncommon at all. It's real common in fact. Which is > why a manual shutoff is going to be the simplest, and most elegant way > to handle this. manual shutoff doesn't scale. and it sort of defeats the purpose of having zero configuration, doesn't it? I think what this means is that we need an explicit indication from the network to turn LL off or on; in the absence of any indication about LL from the network it can default to on. this would let a network disable LL, it would also let a network assign routable addresses instead of LL addresses. but the mere presence of DHCP should not be taken as an indication one way or another of whether LL should be used. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 13:23:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02975 for ; Wed, 22 Jan 2003 13:23:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B895A91397; Wed, 22 Jan 2003 13:26:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D12191396; Wed, 22 Jan 2003 13:26: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 7666891395 for ; Wed, 22 Jan 2003 13:26:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5AC055DE37; Wed, 22 Jan 2003 13:26:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 4240E5DDD9 for ; Wed, 22 Jan 2003 13:26:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 1862A140F8; Wed, 22 Jan 2003 13:26:13 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 17193-02; Wed, 22 Jan 2003 13:26:12 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 7B8C01405E; Wed, 22 Jan 2003 13:26:12 -0500 (EST) Date: Wed, 22 Jan 2003 13:26:12 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122132612.5f900048.moore@cs.utk.edu> In-Reply-To: References: <13375.1043252771@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 707260be54cdf4e20b67eea1722b79b9520f6509 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Actually allocating the address is easy enough > > (though unnecessary), but now the node has two addresses, and both > > it and every other node, has to continually try to work out which > > one of the two should be used. That isn't simpler, for anything. > > The methodologies for this are well understood, and provides a more > consistent set of circumstances. there are no methodologies that work, at least not without imposing some other constraints - e.g. that every node also have a global address. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 13:30:50 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03070 for ; Wed, 22 Jan 2003 13:30:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7A7B59130D; Wed, 22 Jan 2003 13:34:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4DB8291395; Wed, 22 Jan 2003 13: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 4C3F49130D for ; Wed, 22 Jan 2003 13:33:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F5A95DDB7; Wed, 22 Jan 2003 13:33:33 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 0470D5DE83 for ; Wed, 22 Jan 2003 13:33:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 8564114268; Wed, 22 Jan 2003 13:33:32 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 17959-07; Wed, 22 Jan 2003 13:33:31 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id CFCAB1426C; Wed, 22 Jan 2003 13:33:31 -0500 (EST) Date: Wed, 22 Jan 2003 13:33:31 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: On manual control of v4LL Message-Id: <20030122133331.44e1a99b.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 130194bbb95e3a5ac9712915e4b6a0a662cc4323 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > You know, it occurs to me that maybe trying to make the v4LL switch > automatic isn't the way to go. > > Think about this, it brings up all kinds of issues, like > authentication, notification, communicating with v4LL without an > address, ad nauseum. It's going to take three pages at least to > properly define, and there's going to be a half - dozen loopholes. > > But what if we don't make it automatic in the face of DHCP, or > creating some other protocol to turn it off? > > Why NOT make it manual? You know, it occurs to me that maybe trying to make address allocation automatic is not the way to go. Think about this, it brings up all kinds of issues, like authentication, notification, communicating between ad hoc addresses and managed addresses, ad nauseum. It's going to take several dozen pages at least to properly define, and there's going to be a dozen loopholes. Why NOT make it manual? Seems like the very reason we want autoconfiguration is to avoid having to explicitly configure hosts on a per-host basis. An autoconfiguration solution that optimizes for ad hoc networks and pessimizes for managed networks isn't going to play very well, especially given that the vast majority of existing networks are managed (in the sense that they assign addresses) and the vast majority of deployed applications use hosts from outside the local link. For an autoconfiguration solution to be significantly more useful than what we have now (i.e.. DHCP), it needs to work on both ad hoc networks and managed networks without explicit host configuration. That's not to say that the ability to do manual configuration isn't extremely desirable, but it's not something that should need to be used in normal cases. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 13:31:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03092 for ; Wed, 22 Jan 2003 13:31:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1BDD991395; Wed, 22 Jan 2003 13:34:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE86291396; Wed, 22 Jan 2003 13:34:08 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C967C91395 for ; Wed, 22 Jan 2003 13:34:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id A99805DE37; Wed, 22 Jan 2003 13:34:03 -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 3C6A95DDB7 for ; Wed, 22 Jan 2003 13:34:03 -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 NAA03764 for ; Wed, 22 Jan 2003 13:34:02 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA02963 for ; Wed, 22 Jan 2003 13:34:01 -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 NAA21579 for ; Wed, 22 Jan 2003 13:34:00 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 13:33:56 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122131428.16cdc035.moore@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 01/22/2003 13:14, "Keith Moore" wrote: >> But if you're going to go through all the trouble to communicate with >> v4LL devices, why not just take the last step and give them the >> address too? > > 1. because this forces apps to deal with the extra complexity of being aware > of network topology and having to choose between addresses of different > scopes. > > 2. because the addresses will leak into areas of the network in which they are > not valid. Okay...so compromise...support manual only control, and I'll not object to turning v4LL off...I just don't like an unauthenticated, random server able to screw up my settings. Manual avoids this. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 13:32:54 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03130 for ; Wed, 22 Jan 2003 13:32:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5BB2191398; Wed, 22 Jan 2003 13:36:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0420F9139A; Wed, 22 Jan 2003 13:36: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 E0ED591398 for ; Wed, 22 Jan 2003 13:35:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id A79265DE37; Wed, 22 Jan 2003 13:35:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 8FE785DDB7 for ; Wed, 22 Jan 2003 13:35:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id D3A0A1426D; Wed, 22 Jan 2003 13:35:54 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 18676-06; Wed, 22 Jan 2003 13:35:53 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 6B03D1426B; Wed, 22 Jan 2003 13:35:53 -0500 (EST) Date: Wed, 22 Jan 2003 13:35:53 -0500 From: Keith Moore To: Brad Davis Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Proposed changes to the document Message-Id: <20030122133553.56515987.moore@cs.utk.edu> In-Reply-To: <3E2EDD18.4070101@cove-mtn.com> References: <3E2EDD18.4070101@cove-mtn.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: a792c18af497a34410f179f7669bf539f8e5525b Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 22 Jan 2003 11:04:08 -0700 Brad Davis wrote: > (I know this will cause a bit of heartburn): > > General: As has been pointed out, IPv4LL addresses (as defined here) > are not link local addresses but subnet local addresses (SL?). well, they're not routable. you can subnet a subnet but you can't subnet a link using link-locals. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 13:33:00 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03143 for ; Wed, 22 Jan 2003 13:32:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E9C1291396; Wed, 22 Jan 2003 13:35:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAA9E91398; Wed, 22 Jan 2003 13:35: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 8CEE491396 for ; Wed, 22 Jan 2003 13:35:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 795075DE37; Wed, 22 Jan 2003 13:35:49 -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 0EC5D5DDB7 for ; Wed, 22 Jan 2003 13:35:49 -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 NAA29159 for ; Wed, 22 Jan 2003 13:35:48 -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 NAA03308 for ; Wed, 22 Jan 2003 13:35:48 -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 NAA22436 for ; Wed, 22 Jan 2003 13:35:47 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 13:35:43 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122131802.0d627f2b.moore@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 01/22/2003 13:18, "Keith Moore" wrote: >> In my case, it means "I'm absolutely cynical about people doing the >> right thing. I assume they won't, and it is *far* better to deal with >> it now, than hope for the best and get burned yet again" > > I share your cynicism about people doing the right thing. But if we don't do > the right thing when we ship a spec (which means to give due consideration to > how it will affect IP applications, networks, and users), how can we even hope > to avoid giving people even more difficult choices down the road, where the > "right thing" will not be nearly so obvuious? That's why I like manual only control...it is a simple, yet flexible way to make us both, (and we are kind of the poles in this imbroglio) happy. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 13:33:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03171 for ; Wed, 22 Jan 2003 13:33:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E0FBB9139A; Wed, 22 Jan 2003 13:36:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A9C659139B; Wed, 22 Jan 2003 13:36: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 9C83F9139A for ; Wed, 22 Jan 2003 13:36:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8AE0E5DEBE; Wed, 22 Jan 2003 13:36:27 -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 2045D5DE83 for ; Wed, 22 Jan 2003 13:36:27 -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 NAA29811 for ; Wed, 22 Jan 2003 13:36: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 NAA08262 for ; Wed, 22 Jan 2003 13:31:58 -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 NAA20683 for ; Wed, 22 Jan 2003 13:31:57 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 13:31:48 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122131231.2ebe0bf1.moore@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 01/22/2003 13:12, "Keith Moore" wrote: >> Now, since there are times when you would want this shut off, any >> earlier objections I may have had to requiring a manual shutoff are >> removed. > > Manual shutoff is desirable for devices that can be manually configured, but > not sufficient. There needs to be some way for the network to specify whether > LL is allowed on the link. Ah, but make it part of the standard. Then, it has to be in there, (well, as much as anything else). The network admin *can* do this via any number of mechanisms that allow for remote command execution on the devices in question. Or, for things like printers, it can be an option on a web or command line config program. Heck, you could even automate it: For example, on Mac OS X, Sustainable Softworks has a firewall product that can kick off applescripts when a rule is violated... So, when v4LL traffic is detected, you run an Applescript that uses SSH to remotely log into the box, and kill v4LL. You can also send an email to the registered user of the box. If the system is a transient/visiting system, and you get an error when SSH'ing into the box, you could, as an error handler, run a script that instructs your managed switches to ignore all traffic from that MAC address. The user is notified, and the access mechanism is authenticated. I'm happy. You can easily keep v4LL off of your network. You're happy, or should be. It's *SIMPLE**...everyone should like that. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 13:39:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03252 for ; Wed, 22 Jan 2003 13:39:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 30C479139B; Wed, 22 Jan 2003 13:42:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0368F9139C; Wed, 22 Jan 2003 13:42: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 CB3AC9139B for ; Wed, 22 Jan 2003 13:42:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id A27F15DECC; Wed, 22 Jan 2003 13:42:26 -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 396C85DEBE for ; Wed, 22 Jan 2003 13:42:26 -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 NAA02883 for ; Wed, 22 Jan 2003 13:42:25 -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 NAA04621 for ; Wed, 22 Jan 2003 13:42:21 -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 NAA25414 for ; Wed, 22 Jan 2003 13:42:20 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 13:42:12 -0500 Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122132445.5da26f53.moore@cs.utk.edu> 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 NAA03252 On 01/22/2003 13:24, "Keith Moore" wrote: >> ...it's not uncommon at all. It's real common in fact. Which is >> why a manual shutoff is going to be the simplest, and most elegant way >> to handle this. > > manual shutoff doesn't scale. and it sort of defeats the purpose of having > zero configuration, doesn't it? It scales extremely well, as you can easily run remote apps on *thousands* of machines at once if need be. It also doesn¹t need to be continuously told to stay off. Managed switches can identify violators of the policy, as can any number of network management apps. It also doesn't have to violate zeroconf. The devices ship with it on by default. Always...so unless you turn it off, it's zeroconf. If you turn it off, you had to *manually*, at some point do so. Which means a conscious decision was made to do so. Since it's a manual decision, it lets off mean OFF. No silliness with ARPs and what not. LL is on, you get ALL of LL. LL is off, you get NO LL. > > I think what this means is that we need an explicit indication from the > network to turn LL off or on; in the absence of any indication about LL from > the network it can default to on. this would let a network disable LL, it > would also let a network assign routable addresses instead of LL addresses. You can do this with my method, only you get some side benefits pretty much for free...like authentication, permissions controls, encryption. What's not to like? > > but the mere presence of DHCP should not be taken as an indication one way or > another of whether LL should be used. On that, we are in complete agreement. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 13:40:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03272 for ; Wed, 22 Jan 2003 13:40:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C56B29139C; Wed, 22 Jan 2003 13:43:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9244B9139D; Wed, 22 Jan 2003 13:43:40 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D21E9139C for ; Wed, 22 Jan 2003 13:43:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C5375DE83; Wed, 22 Jan 2003 13:43:39 -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 F33DB5DE37 for ; Wed, 22 Jan 2003 13:43:38 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0MIdHP19447; Wed, 22 Jan 2003 12:39:17 -0600 (CST) Date: Wed, 22 Jan 2003 10:43:53 -0800 Subject: When to configure LL addrs vs. whether to require LL communication Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Zeroconf To: "John C. Welch" From: Ted Lemon In-Reply-To: Message-Id: <74507C46-2E39-11D7-AFDA-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > v4LL communication should always be available and usable without manual > intervention by the user. v4LL communication _is_ always available, even if you don't have a v4ll IP address, IF YOUR STACK SUPPORTS IT. I think this is the disconnect that's causing a lot of this back-and-forth. There are two referents for the phrase "v4ll is enabled." The first is, the stack is allowed to and does acquire a v4LL IP address. The second is, the stack is able to communicate with devices that have a v4LL IP address. I think that to some degree you have been confusing these two meanings. This is understandable, because we are talking about disabling the acquisition of v4ll addresses on links. In the case you describe, if the DHCP server is following the standard, but only has one address to allocate to you, what will happen is that it will assign an IP address to whichever device requests it first - your printer, or your computer. The other device will hear no response from the DHCP server, and thus will just use IPv4ll. If you are lucky, the device that gets the routable address will be your computer. So to make this scenario work, you need two things: 1. You need the IP stack on your computer to support communicating with v4ll devices when it has a routable address. 2a. You need to be able to configure your printer not to attempt DHCP, and instead only use v4LL, or 2b. You need to convince your ISP to give your one IP address to your computer (many ISPs do this by default anyway, even though it's not specifically recommended in rfc2131). I think in your scenario you are assuming 2b, and so things will Just Work. But 2b isn't standardized, nor is it a given, so in fact the situation you describe is likely not to Just Work. From owner-zeroconf@merit.edu Wed Jan 22 13:40:56 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03299 for ; Wed, 22 Jan 2003 13:40:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A54CD9139D; Wed, 22 Jan 2003 13:44:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 742619139E; Wed, 22 Jan 2003 13:44: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 509949139D for ; Wed, 22 Jan 2003 13:44:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F6FE5DE83; Wed, 22 Jan 2003 13:44:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 2627F5DE37 for ; Wed, 22 Jan 2003 13:44:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 88E1F140CD; Wed, 22 Jan 2003 13:44:03 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 20499-04; Wed, 22 Jan 2003 13:44:03 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id E889114044; Wed, 22 Jan 2003 13:44:02 -0500 (EST) Date: Wed, 22 Jan 2003 13:44:03 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122134403.2152b6a4.moore@cs.utk.edu> In-Reply-To: References: <20030122131428.16cdc035.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 84493cbb84e91bb925078ed0dbe43acdd0067db2 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 22 Jan 2003 13:33:56 -0500 "John C. Welch" wrote: > On 01/22/2003 13:14, "Keith Moore" wrote: > > >> But if you're going to go through all the trouble to communicate > >with> v4LL devices, why not just take the last step and give them the > >> address too? > > > > 1. because this forces apps to deal with the extra complexity of > > being aware of network topology and having to choose between > > addresses of different scopes. > > > > 2. because the addresses will leak into areas of the network in > > which they are not valid. > > Okay...so compromise...support manual only control, and I'll not > object to turning v4LL off...I just don't like an unauthenticated, > random server able to screw up my settings. Manual avoids this. Zero configuration inherently implies not having authentication, because without configuration there's no way to tell a device who to trust and who to ignore. So in the absence of explicit configuration there is no way for a device to know whether a response to its address claim or address request is acting on behalf of the network, or whether it is one that is trying to subvert the local network's policy. A rogue responder could either be trying to disable LL when the network's policy was to permit it, or it could be trying to enable LL when the network's policy was to forbid it. And there's no reason to assume that the breakage resulting from using LL when it's not permitted is always or even highly likely to be better than the breakage resulting from refusing to use LL when it is permitted. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 13:45:54 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03367 for ; Wed, 22 Jan 2003 13:45:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C12709139E; Wed, 22 Jan 2003 13:47:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85EA89139F; Wed, 22 Jan 2003 13:47: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 679099139E for ; Wed, 22 Jan 2003 13:47:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 49B0E5DE83; Wed, 22 Jan 2003 13:47: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 BBAF35DE37 for ; Wed, 22 Jan 2003 13:47: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 h0MIkuw03150 for ; Wed, 22 Jan 2003 10:46:56 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 22 Jan 2003 10:46:56 -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 h0MIkts19398 for ; Wed, 22 Jan 2003 10:46:55 -0800 (PST) Date: Wed, 22 Jan 2003 10:46:42 -0800 Subject: Re: WG decision: when to configure LL addrs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, January 22, 2003, at 06:50 AM, Thomas Narten wrote: > 1) Should the ID recommend that LL addresses only be configured as per > below. Please answer clearly, along the lines of > > a) yes, I think this is what the document should say (maybe with > some small tweaks, which then need to be explained) > > b) no, this is a showstopper for me (and explain why, so the rest > of the WG can understand and then agree or disagree with your > position) > > c) Not my first choice, but I can live with it. A. My only comment is that the alternative from the first section should be dropped entirely. >> - when should an IPv4LL address be configured by a host? > >> suggest: if the host is explicitly configured to do so, OR >> if the host has attempted and failed to acquire a routable address >> via DHCP > >> (alternative: provide a lighter weight mechanism by which a host >> can acquire a >> routable address, netmask, and default route, in response to its >> attempt to claim >> an IPv4LL address) > >> - when should an IPv4LL address be used by a host as a source address? > >> suggest: when the only addresses available to the host are IPv4LL >> addresses, OR >> when the application has explicitly specified the source address to >> use, OR >> when the application has explicitly specified the interface to use >> and the IPv4LL address >> is the only address associated with that interface. > >> - when should a host honor an attempt to connect to an IPv4LL address >> that was once >> configured by that host? > >> suggest: anytime the address is still valid (e.g. there have been >> no conflicting claims) >> and there is a process listening for connections either >> specifically to that address or >> for incoming connections at any of the host's addresses. > >> - when should an application attempt to connect to a IPv4LL address? > >> suggest: only when the address is literally specified, or if there >> are no other routable >> addresses for the destination host known to the application. > >> - when should an application send an IPv4LL address in a referral to >> another host? > >> suggest: only when there are no routable addresses for the >> destination host known to the >> application. even then, care needs to be taken that a host reached >> at a particular >> IPv4LL address is really the one intended - since IPv4LL addresses >> can be reassigned >> without notice and/or reused on different network segments. From owner-zeroconf@merit.edu Wed Jan 22 13:49:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03416 for ; Wed, 22 Jan 2003 13:49:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 983EE9130E; Wed, 22 Jan 2003 13:52:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B7BE9130F; Wed, 22 Jan 2003 13:52: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 660E19130E for ; Wed, 22 Jan 2003 13:52:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 53AB65DE83; Wed, 22 Jan 2003 13:52: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 DC5BA5DE37 for ; Wed, 22 Jan 2003 13:52: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 NAA07924 for ; Wed, 22 Jan 2003 13:52: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 NAA12373 for ; Wed, 22 Jan 2003 13:48:02 -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 NAA27832 for ; Wed, 22 Jan 2003 13:47:32 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 13:47:26 -0500 Subject: Re: On manual control of v4LL From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122133331.44e1a99b.moore@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 01/22/2003 13:33, "Keith Moore" wrote: > > For an autoconfiguration solution to be significantly more useful than what we > have now (i.e.. DHCP), it needs to work on both ad hoc networks and managed > networks without explicit host configuration. That's not to say that the > ability to do manual configuration isn't extremely desirable, but it's not > something that should need to be used in normal cases. Manual does not mean "Not automatable". I automate manual commands as a hobby. But I have MAJOR objections to the automation solutions proposed. Requiring a command to be specifically run, removes a lot of those objections...well, actually, all of them, as long as the user is notified that v4LL has been turned off. You also don't have to create some change to DHCP, some 'other' network notification mechanism. The infrastructure to support this is already there. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 13:49:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03430 for ; Wed, 22 Jan 2003 13:49:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9D1859130F; Wed, 22 Jan 2003 13:52:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 046579139F; Wed, 22 Jan 2003 13:52: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 C7E2E9130F for ; Wed, 22 Jan 2003 13:52:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id B61565DEBE; Wed, 22 Jan 2003 13:52:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 9E85C5DE37 for ; Wed, 22 Jan 2003 13:52:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5DA0714277; Wed, 22 Jan 2003 13:52:24 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 21548-09; Wed, 22 Jan 2003 13:52:23 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id BF9F5140CD; Wed, 22 Jan 2003 13:52:23 -0500 (EST) Date: Wed, 22 Jan 2003 13:52:23 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122135223.4a9d1146.moore@cs.utk.edu> In-Reply-To: References: <20030122131231.2ebe0bf1.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 1128ff42579b7abdb3b03ab04cf616d66c40035a Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > Manual shutoff is desirable for devices that can be manually > > configured, but not sufficient. There needs to be some way for the > > network to specify whether LL is allowed on the link. > > Ah, but make it part of the standard. Then, it has to be in there, > (well, as much as anything else). The network admin *can* do this via > any number of mechanisms that allow for remote command execution on > the devices in question. Well, we'd need to pick a standard mechanism that every device would implement, having to support a different one for each device would be a nightmare. And it would therefore need to be lightweight. And it's hard to see how to get useful authentication in such a mechanism unless there's a way to configure each device with a password or some such. And it would be less dirsuptive to have the device learn an appropriate address *before* using an LL address, rather than having to have to wait for the device to generate traffic and then kick it. That, and there's no way to require manual shutoff for devices that lack any means of manual input. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 13:49:57 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03461 for ; Wed, 22 Jan 2003 13:49:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 654719139F; Wed, 22 Jan 2003 13:53:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3BFE9913A0; Wed, 22 Jan 2003 13: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 4D2FF9139F for ; Wed, 22 Jan 2003 13:53:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3983B5DE83; Wed, 22 Jan 2003 13:53:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ethel.diamand.org (pc3-cmbg4-3-cust194.cmbg.cable.ntl.com [81.100.94.194]) by segue.merit.edu (Postfix) with ESMTP id 6C80A5DE37 for ; Wed, 22 Jan 2003 13:53:13 -0500 (EST) Received: from localhost ([127.0.0.1] helo=globespanvirata.com) by ethel.diamand.org with esmtp (Exim 3.35 #1 (Debian)) id 18bPvU-0005Sz-00; Wed, 22 Jan 2003 18:48:40 +0000 Message-ID: <3E2EE787.5070305@globespanvirata.com> Date: Wed, 22 Jan 2003 18:48:39 +0000 From: Luke Diamand User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ted Lemon Cc: Thomas Narten , zeroconf@merit.edu Subject: Re: WG decision: when to configure LL addrs References: In-Reply-To: X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ted Lemon wrote: > Zeroconf should Just Work, and in order for > that to happen, the delay here has to be short. I would be satisfied > if the delay were shorter than ten seconds. I thougt an earlier poster made the point that if you try to acquire a V4LL address on a network bridged using a spanning tree bridge, you *have* to wait for 45 seconds while the spanning tree algorithm does its thing. Otherwise you might well pick an address that's already in use on the other side of the bridge. I think you are going to have to live with the existing delay of a minute (or thereabouts) unless you can find a way to (manually?) turn it down if you know that spanning tree bridge is not in use on this network. Luke Diamand From owner-zeroconf@merit.edu Wed Jan 22 13:51:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03484 for ; Wed, 22 Jan 2003 13:51:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B7369913A0; Wed, 22 Jan 2003 13:54:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88207913A1; Wed, 22 Jan 2003 13:54: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 68E2D913A0 for ; Wed, 22 Jan 2003 13:54:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 56EA85DE83; Wed, 22 Jan 2003 13:54:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 3DC695DE37 for ; Wed, 22 Jan 2003 13:54:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 0E2E014273; Wed, 22 Jan 2003 13:54:55 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 21823-07; Wed, 22 Jan 2003 13:54:54 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 620D314276; Wed, 22 Jan 2003 13:54:54 -0500 (EST) Date: Wed, 22 Jan 2003 13:54:54 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, jwelch@MIT.EDU, zeroconf@merit.edu Subject: Re: When to configure LL addrs vs. whether to require LL communication Message-Id: <20030122135454.74479779.moore@cs.utk.edu> In-Reply-To: <74507C46-2E39-11D7-AFDA-00039317663C@nominum.com> References: <74507C46-2E39-11D7-AFDA-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: dc6f5a965bedc79dcaaecc0f0e85740a48edf648 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > v4LL communication _is_ always available, even if you don't have a > v4ll IP address, IF YOUR STACK SUPPORTS IT. I think this is the > disconnect that's causing a lot of this back-and-forth. There are > two referents for the phrase "v4ll is enabled." The first is, the > stack is allowed to and does acquire a v4LL IP address. The second > is, the stack is able to communicate with devices that have a v4LL IP > address. I think that to some degree you have been confusing these > two meanings. it's even better if v4LL doesn't get used at all in those cases where the network is willing to assign addresses to hosts. actually it's hard to imagine why a managed network would prefer use of v4LL addresses when it can explicitly control the scope of addresses that it assigns. v4LL seems far less reliable. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 13:53:26 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03559 for ; Wed, 22 Jan 2003 13:53:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ED6E8913A1; Wed, 22 Jan 2003 13:56:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4001913A2; Wed, 22 Jan 2003 13:56: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 9052C913A1 for ; Wed, 22 Jan 2003 13:56:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7B3775DEBE; Wed, 22 Jan 2003 13:56:43 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 637665DE83 for ; Wed, 22 Jan 2003 13:56:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 396CA14275; Wed, 22 Jan 2003 13:56:43 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 21862-09; Wed, 22 Jan 2003 13:56:42 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id A030514273; Wed, 22 Jan 2003 13:56:42 -0500 (EST) Date: Wed, 22 Jan 2003 13:56:42 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) Message-Id: <20030122135642.0a93346b.moore@cs.utk.edu> In-Reply-To: References: <20030122132445.5da26f53.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 9465a546573d44cafd79a23c7fb0c0eb8f0668cf Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > manual shutoff doesn't scale. and it sort of defeats the purpose of > > having zero configuration, doesn't it? > > It scales extremely well, as you can easily run remote apps on > *thousands* of machines at once if need be. I think we're using the word "manual" in different ways. I'm using it a way that means that someone has to physically touch that specific device in order to alter its behavior, rather than sending it a signal over a network. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 14:04:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03723 for ; Wed, 22 Jan 2003 14:04:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 15D84913A7; Wed, 22 Jan 2003 14:07:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9855A913A3; Wed, 22 Jan 2003 14:07: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 7E31A913A5 for ; Wed, 22 Jan 2003 14:06:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5C6B35DECC; Wed, 22 Jan 2003 14:06:54 -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 E4FFF5DEBF for ; Wed, 22 Jan 2003 14:06: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 OAA14931 for ; Wed, 22 Jan 2003 14:06: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 OAA14641 for ; Wed, 22 Jan 2003 14:02: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 NAA02522 for ; Wed, 22 Jan 2003 13:57:40 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 13:57:34 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122134403.2152b6a4.moore@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 01/22/2003 13:44, "Keith Moore" wrote: > Zero configuration inherently implies not having authentication, because > without configuration there's no way to tell a device who to trust and who to > ignore. Right...so we should therefore not require any authentication anywhere when dealing with Zeroconf? > > So in the absence of explicit configuration there is no way for a device to > know whether a response to its address claim or address request is acting on > behalf of the network, or whether it is one that is trying to subvert the > local network's policy. A rogue responder could either be trying to disable > LL when the network's policy was to permit it, or it could be trying to enable > LL when the network's policy was to forbid it. Which is a reason why unauthenticated modification to LL status is such a BAD idea...it's too easy to subvert either way. > And there's no reason to assume that the breakage resulting from using LL when > it's not permitted is always or even highly likely to be better than the > breakage resulting from refusing to use LL when it is permitted. That's why having to make a conscious decision to kill it, or turn it back on, is a better idea. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 14:07:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03787 for ; Wed, 22 Jan 2003 14:07:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2A447913A3; Wed, 22 Jan 2003 14:10:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E709A913A4; Wed, 22 Jan 2003 14:10: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 E1CF0913A3 for ; Wed, 22 Jan 2003 14:10:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id CF9525DEBF; Wed, 22 Jan 2003 14:10:43 -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 85B585DE83 for ; Wed, 22 Jan 2003 14:10:43 -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 h0MJAgI18167 for ; Wed, 22 Jan 2003 11:10:42 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 22 Jan 2003 11:10:42 -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 h0MJAfQ21789 for ; Wed, 22 Jan 2003 11:10:41 -0800 (PST) Date: Wed, 22 Jan 2003 11:10:30 -0800 Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030122110626.77a2c8f8.moore@cs.utk.edu> Message-Id: <2C45BDE9-2E3D-11D7-8BF8-000393760260@apple.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I must be missing something. I don't see how some method other than DHCP to turn off IPv4LL would solve the problem described by Keith. Maybe I'm missing something? If the NAT box ignores the Mac and PC DHCP requests for addresses then both boxes should self assign IPv4LLs. The mere presence of a DHCP server should not prevent a device from self assigning an IPv4LL. A device should not self assign an IPv4LL if it does not get an address through some other configuration method (i.e. no DHCP response). There is no way for the Mac or PC to know that there is a DHCP server, right? I'm not intimately familiar with DHCP, but I was under the impression that if a DHCP server didn't want to give you an address, it wouldn't respond with a "no, go away", it would simply fail to respond at all. Robert Elz argued we should distinguish between the case where we're refused an address and the case where there is no DHCP server. Robert Elz seemed to suggest that we should not acquire an IPv4LL in the case where we're refused an address. Is there an easy way to tell the difference? Does it matter? I don't think we should put unnecessary restrictions in to the IPv4LL draft to satisfy deluded administrators that think not handing out a DHCP address is a way to keep unauthorized people from using the network. If a device does get an IPv4LL address, the device will still be unable to communicate with anything off of the local link. An IPv4LL address will not instantly give access to the global internet, only other devices on the local link. Those devices are not protected by not automatically assigning an address on the local link to unauthorized devices. Once a device has access to the link, there is nothing to prevent it from using any number of protocols (AppleTalk, IPX, IPv6) to communicate with other devices on that link. -josh On Wednesday, January 22, 2003, at 08:06 AM, Keith Moore wrote: > However this did cause me to realize a problem with the idea that any > DHCP service should suffice to disable v4LL. > > I have a DSL modem at home. As shipped, that modem had a DHCP server > that assigned a RFC 1918 address to the first host that asked for an > address. It would do NAT (arrgh) between that address and the address > assigned to the DSL line by the ISP.[*] However it would NOT NAT for > multiple devices and it woudl NOT honor any subsequent DHCP requests > for addresses by other hosts on the network. > > So imagine a home network with a DSL modem like mine, an Ethernet hub, > and two hosts - a windows or mac box and a zeroconf printer. If the > windows or mac box asks DHCP for an address first, then all is well - > the windows or mac box can talk externally, and it can talk to the > printer's v4LL address. On the other hand if the printer asks DHCP > for an address first, then the printer can accept connections from > anywhere in the network, but the windows or mac box will be isolated. > And the poor clueless user has to reboot the cable modem, *then* > reboot the windows or mac box, or something. That's a lousy > arrangement. > > Now this is a limited sample space, and maybe that's just an anomaly > with this one DSP modem, but I've heard that this kind of behavior is > common. If so then what we need is some more explicit way for a > network to say "don't use LL" than just the presence of a DHCP server. > > Keith From owner-zeroconf@merit.edu Wed Jan 22 14:11:08 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03852 for ; Wed, 22 Jan 2003 14:11:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 65E7E913A5; Wed, 22 Jan 2003 14:12:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26FB5913A6; Wed, 22 Jan 2003 14:12: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 7A048913A5 for ; Wed, 22 Jan 2003 14:12:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 629115DEBF; Wed, 22 Jan 2003 14:12: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 E7F375DDB7 for ; Wed, 22 Jan 2003 14:12: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 OAA18120 for ; Wed, 22 Jan 2003 14:12: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 OAA15626 for ; Wed, 22 Jan 2003 14:07:14 -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 OAA05678 for ; Wed, 22 Jan 2003 14:04:30 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 14:04:24 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122135223.4a9d1146.moore@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 01/22/2003 13:52, "Keith Moore" wrote: > Well, we'd need to pick a standard mechanism that every device would > implement, having to support a different one for each device would be a > nightmare. And it would therefore need to be lightweight. Nope...leave it up to the vendor. Most unix -based OS's would get either 'v4LL.conf' or a new switch to ifconfig. Probably take about a week to do, based on past experience. Windows, the same way. You wouldn't want to tell them how, just what. It's not like you can force anyone to obey a standard anyway, but this is pretty simple compared to DHCP/other - based schemes. > And it's hard to > see how to get useful authentication in such a mechanism unless there's a way > to configure each device with a password or some such. Well, lets see...I can do it for JetDirect print servers, I can do it for anything with a web interface, Mac OS X and most Unixen require SSH, Windows supports PPTP as a part of the OS.... > And it would be less dirsuptive to have the device learn an appropriate > address *before* using an LL address, rather than having to have to wait for > the device to generate traffic and then kick it. Take at most three packets to detect, about five minutes to run the script, and is only going to be an issue for transient or misconfigured devices anyway. > > That, and there's no way to require manual shutoff for devices that lack any > means of manual input. There are VERY few networked devices that don't have some means of remote access bit it http, SSH, even, (ugh), telnet. Again, the infrastructure is *there*. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 14:18:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03972 for ; Wed, 22 Jan 2003 14:18:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC1799121B; Wed, 22 Jan 2003 14:21:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79F45913A8; Wed, 22 Jan 2003 14:21: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 945E89121B for ; Wed, 22 Jan 2003 14:21:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7812C5DE83; Wed, 22 Jan 2003 14:21:11 -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 285885DE37 for ; Wed, 22 Jan 2003 14:21:11 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0MJGlP19903; Wed, 22 Jan 2003 13:16:47 -0600 (CST) Date: Wed, 22 Jan 2003 11:21:23 -0800 Subject: Re: WG decision: when to configure LL addrs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Thomas Narten , zeroconf@merit.edu To: Luke Diamand From: Ted Lemon In-Reply-To: <3E2EE787.5070305@globespanvirata.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I thougt an earlier poster made the point that if you try to acquire a > V4LL address on a network bridged using a spanning tree bridge, you > *have* to wait for 45 seconds while the spanning tree algorithm does > its thing. This kind of spanning tree delay also breaks DHCP. It has to be disabled in order to make DHCP work. We get support questions about this pretty frequently, and indeed the new version of the DHCP Handbook has a specific note about this in the debugging chapter. AFAIK it only works reliably with a completely manually-configured network. From owner-zeroconf@merit.edu Wed Jan 22 14:21:00 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04047 for ; Wed, 22 Jan 2003 14:21:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C05B9913A8; Wed, 22 Jan 2003 14:24:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B26A913A9; Wed, 22 Jan 2003 14:24: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 860B0913A8 for ; Wed, 22 Jan 2003 14:24:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6F1005DE37; Wed, 22 Jan 2003 14:24:16 -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 02D055DDB7 for ; Wed, 22 Jan 2003 14:24:16 -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 OAA25805 for ; Wed, 22 Jan 2003 14:24: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 OAA10790 for ; Wed, 22 Jan 2003 14:19:09 -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 OAA12310 for ; Wed, 22 Jan 2003 14:19:08 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 14:19:01 -0500 Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122135642.0a93346b.moore@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 01/22/2003 13:56, "Keith Moore" wrote: >>> manual shutoff doesn't scale. and it sort of defeats the purpose of >>> having zero configuration, doesn't it? >> >> It scales extremely well, as you can easily run remote apps on >> *thousands* of machines at once if need be. > > I think we're using the word "manual" in different ways. I'm using it a way > that means that someone has to physically touch that specific device in order > to alter its behavior, rather than sending it a signal over a network. Ahh...no, not at all. I'm using it in the sense that there has to be a concious decision made, and a manual action taken. That action can be initiated from a network management console, but it is not just run because you happen to see a DHCP server. By using a manual process, such as say, a new switch to ifconfig, you can remotely execute that manual action, BUT you can use things like SSH to ensure that only authorized, authenticated sources can take that action. You get what you want, I get what I want, zeroconf ships as zeroconf by default, the script kiddies can't build v4LL DeathTraps...sounds good to me. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 14:23:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04104 for ; Wed, 22 Jan 2003 14:23:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 683E4913A9; Wed, 22 Jan 2003 14:26:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 289EB913AC; Wed, 22 Jan 2003 14:26: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 E163F913A9 for ; Wed, 22 Jan 2003 14:26:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id C46945DEBF; Wed, 22 Jan 2003 14:26: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 562945DE37 for ; Wed, 22 Jan 2003 14:26: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 OAA28371 for ; Wed, 22 Jan 2003 14:26: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 OAA12494 for ; Wed, 22 Jan 2003 14:26: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 OAA15620 for ; Wed, 22 Jan 2003 14:26:27 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 14:26:25 -0500 Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <2C45BDE9-2E3D-11D7-8BF8-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 01/22/2003 14:10, "Joshua Graessley" wrote: > I don't think we should put unnecessary restrictions in to the IPv4LL > draft to satisfy deluded administrators that think not handing out a > DHCP address is a way to keep unauthorized people from using the > network. I don't think DHCP should be in the business of deciding which config is to be used. It provides one form of config, it shouldn't be used to turn others off...it's too insecure to do this. So I want authentication and authorization. A manual on/off switch provides this, since you use things like SSH for remote login/execution *anyway*. I also think that if I, as a network admin, want v4LL off my network, I want to know that It's NOT THERE AT ALL. No communication with v4LL addresses whatsoever. A manual on/off switch provides this. I also don't want to lose my v4LL just because my idiot brother has his laptop set up as a DHCP server by accident. A manual on/off switch prevents this. Finally, if I want zeroconf on out of the box, then I want it ON...no mucking about. A manual on/off switch allows for this. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 14:30:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04256 for ; Wed, 22 Jan 2003 14:30:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E586B913AB; Wed, 22 Jan 2003 14:33:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 878BE913AD; Wed, 22 Jan 2003 14:33: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 662A0913AB for ; Wed, 22 Jan 2003 14:33:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 375E25DDD9; Wed, 22 Jan 2003 14:33:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 1EC175DDB7 for ; Wed, 22 Jan 2003 14:33:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 1D71814275; Wed, 22 Jan 2003 14:33:02 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 28350-05; Wed, 22 Jan 2003 14:33:01 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 7AC9914273; Wed, 22 Jan 2003 14:33:01 -0500 (EST) Date: Wed, 22 Jan 2003 14:33:01 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122143301.4e396cb8.moore@cs.utk.edu> In-Reply-To: References: <20030122134403.2152b6a4.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: ae02278eadb9ed1cb998a727da8386fc91024adb Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > Zero configuration inherently implies not having authentication, > > because without configuration there's no way to tell a device who to > > trust and who to ignore. > > Right...so we should therefore not require any authentication anywhere > when dealing with Zeroconf? The intersection between "zero configuration technologies" and authentication is the null set. On the other hand, if you want to develop an architecture that allows devices to automatically adapt to a variety of network situations (including varying needs for security and varying policies about the default level of access) with a minimum of configuration, then authentication probably does need to be part of that picture. But this would be a drastic departure from the way this group has been working. > Which is a reason why unauthenticated modification to LL status is > such a BAD idea...it's too easy to subvert either way. But assuming that LL is permitted is also a bad idea. > That's why having to make a conscious decision to kill it, or turn it > back on, is a better idea. I am assuming that any decision on the part of a network administrator to explicitly permit or forbid LL on a network would be a conscious one, though it would not be acceptable to force that administrator to make such decisions on a per-device basis. At the same time, it is technically infeasible for such indications to be authenticated if the device cannot be reliably configured as to which authorities to trust. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 14:33:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04330 for ; Wed, 22 Jan 2003 14:33:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DB75791211; Wed, 22 Jan 2003 14:36:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF5AC91303; Wed, 22 Jan 2003 14:36: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 5E29A91211 for ; Wed, 22 Jan 2003 14:36:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 40F0A5DEE5; Wed, 22 Jan 2003 14:36:56 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 218AF5DDD9 for ; Wed, 22 Jan 2003 14:36:56 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 2F36D14273; Wed, 22 Jan 2003 14:36:56 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 29112-02; Wed, 22 Jan 2003 14:36:55 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 8390F14275; Wed, 22 Jan 2003 14:36:55 -0500 (EST) Date: Wed, 22 Jan 2003 14:36:55 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122143655.2241b729.moore@cs.utk.edu> In-Reply-To: References: <20030122135223.4a9d1146.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: eba6fd097be31a32c3cc8f72f25e6d0f980135ea Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > Well, we'd need to pick a standard mechanism that every device would > > implement, having to support a different one for each device would > > be a nightmare. And it would therefore need to be lightweight. > > Nope...leave it up to the vendor. completely unacceptable. without a uniform means of disabling LL, it is a denial-of-service attack on networks and applications. and you seem to be thinking in terms of conventional hosts when at least as much of the problems is hosts without a manual input. > > And it's hard to > > see how to get useful authentication in such a mechanism unless > > there's a way to configure each device with a password or some such. > > Well, lets see...I can do it for JetDirect print servers, I can do it > for anything with a web interface, Mac OS X and most Unixen require > SSH, Windows supports PPTP as a part of the OS.... I'm getting the impression you don't know what authentication is. > > And it would be less dirsuptive to have the device learn an > > appropriate address *before* using an LL address, rather than having > > to have to wait for the device to generate traffic and then kick it. > > Take at most three packets to detect, about five minutes to run the > script, and is only going to be an issue for transient or > misconfigured devices anyway. that doesn't mean that they're few in number. > > That, and there's no way to require manual shutoff for devices that > > lack any means of manual input. > > There are VERY few networked devices that don't have some means of > remote access bit it http, SSH, even, (ugh), telnet. how do you talk to a device when it doesn't even have a valid address? (and no, LL doesn't work - that forces you to configure each device from its own link) -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 14:49:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04824 for ; Wed, 22 Jan 2003 14:49:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 57BC091311; Wed, 22 Jan 2003 14:52:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1AB46913AC; Wed, 22 Jan 2003 14:52: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 030CC91311 for ; Wed, 22 Jan 2003 14:52:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id E3A0C5DEBF; Wed, 22 Jan 2003 14:52: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 777AA5DE28 for ; Wed, 22 Jan 2003 14:52:51 -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 OAA11252 for ; Wed, 22 Jan 2003 14:52: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 OAA22813 for ; Wed, 22 Jan 2003 14:49:53 -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 OAA27511 for ; Wed, 22 Jan 2003 14:49:46 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 14:49:44 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122143655.2241b729.moore@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 01/22/2003 14:36, "Keith Moore" wrote: >> Nope...leave it up to the vendor. > > completely unacceptable. without a uniform means of disabling LL, it is > a denial-of-service attack on networks and applications. and you seem > to be thinking in terms of conventional hosts when at least as much of > the problems is hosts without a manual input. Reality check...without everyone running the same OS, uniformity will never happen *anyway*. And you confuse manual with physical. >> Well, lets see...I can do it for JetDirect print servers, I can do it >> for anything with a web interface, Mac OS X and most Unixen require >> SSH, Windows supports PPTP as a part of the OS.... > > I'm getting the impression you don't know what authentication is. Authentication: to require a user to identify themselves against a predetermined criteria that determines their ability to access a resource. This can be everything from a simple password file to a Kerberos realm. So, since you can require a userID and password, even with JetDirect, you can force *some* authentication. >> Take at most three packets to detect, about five minutes to run the >> script, and is only going to be an issue for transient or >> misconfigured devices anyway. > > that doesn't mean that they're few in number. Won't matter. Three to three thousand, this kind of stuff is run every day, breaks nothing, changes no standards. > >>> That, and there's no way to require manual shutoff for devices that >>> lack any means of manual input. >> >> There are VERY few networked devices that don't have some means of >> remote access bit it http, SSH, even, (ugh), telnet. > > how do you talk to a device when it doesn't even have a valid address? > (and no, LL doesn't work - that forces you to configure each device from > its own link) Initial out of the box config for devices without a physical input device would require a one time hookup over the LL. Which would be there by default. But then, you have to take it out of the box physically *anyway*, and configure other operational aspects *anyway*, so this is not onerous by any stretch of the imagination. BUT, you would ONLY have to do this if you are *disabling* v4LL. If you weren't, then you wouldn't do this anyway. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 14:53:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04934 for ; Wed, 22 Jan 2003 14:53:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D7DAE913AC; Wed, 22 Jan 2003 14:57:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C964913AD; Wed, 22 Jan 2003 14:57: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 6EDA7913AC for ; Wed, 22 Jan 2003 14:57:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5DE195DEDF; Wed, 22 Jan 2003 14:57:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 3E43A5DE28 for ; Wed, 22 Jan 2003 14:57:06 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 7B1E213FDA; Wed, 22 Jan 2003 14:57:06 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 32716-05; Wed, 22 Jan 2003 14:57:05 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id D342F13FD3; Wed, 22 Jan 2003 14:57:05 -0500 (EST) Date: Wed, 22 Jan 2003 14:57:05 -0500 From: Keith Moore To: Joshua Graessley Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) Message-Id: <20030122145705.554eaf0a.moore@cs.utk.edu> In-Reply-To: <2C45BDE9-2E3D-11D7-8BF8-000393760260@apple.com> References: <20030122110626.77a2c8f8.moore@cs.utk.edu> <2C45BDE9-2E3D-11D7-8BF8-000393760260@apple.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 92e290545e8252b1e922b167ce8dc0cc5ecfef06 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I am not sure I even understand what you are saying, because some of the statements seem to be contradictory. So rather than trying to respond in detail to statements that I don't think I understand, let me see if it helps to rephrase what I'm saying: 1. Networks need a way to say to devices "don't use LL" (because LL causes problems) and optionally "use this other address" (so that autoconfiguring devices will continue to function) 2. Having autoconfiguring devices try DHCP first will not interoperate well with certain DSL modems. Maybe that's not this group's problem, but we should at least be aware of it. Partially because of #2, it might be that an explicit indication from DHCP(or some other protocol) that means "don't use LL" would be better than interpreting a DHCP response to an address request as an implicit indication that LL should not be used. Or not. I see this as a question of which is worse: a. Accidental use of LL on a managed network, with all of the problems that this causes for applications, or b. Failure of home networks that use such DSL modems in the presence of autoconfiguring devices. Offhand, I tend to think that the second case is worse. The managed network presumably has someone with expertise and perhaps diagnostic tools who can turn on the "disable LL" signal if/when it causes problems, whereas the home network user has neither of these. So it's better to break the managed network, *provided* there's a way in the standard for the managed network to fix the problem. > I don't think we should put unnecessary restrictions in to the IPv4LL > draft to satisfy deluded administrators that think not handing out a > DHCP address is a way to keep unauthorized people from using the > network. As for this, as I explained earlier - it is not for this WG to decide whether existing networks' access control methods for IP networks are useful or secure, nor to decide that it's okay to subvert them. This WG is proposing changes to an long-existing, widely-deployed, heavily-used communications interface. It therefore has the burden of minimizing harm to existing uses of that interface. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 14:54:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04974 for ; Wed, 22 Jan 2003 14:54:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3EEB3913AD; Wed, 22 Jan 2003 14:57:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 019ED913AE; Wed, 22 Jan 2003 14:57: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 E068D913AD for ; Wed, 22 Jan 2003 14:57:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id CD8875DED4; Wed, 22 Jan 2003 14:57:54 -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 6316E5DDB7 for ; Wed, 22 Jan 2003 14:57: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 OAA15644 for ; Wed, 22 Jan 2003 14:57: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 OAA24617 for ; Wed, 22 Jan 2003 14:57:52 -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 OAA02146 for ; Wed, 22 Jan 2003 14:57:52 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 14:57:49 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122143301.4e396cb8.moore@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 01/22/2003 14:33, "Keith Moore" wrote: >> Right...so we should therefore not require any authentication anywhere >> when dealing with Zeroconf? > > The intersection between "zero configuration technologies" and > authentication is the null set. Missing the point...i'm talking about authentication to *turn it off*. If you want it, you don't care. If you *don't* want it, then you turn it off, and configure it some other way. > >> Which is a reason why unauthenticated modification to LL status is >> such a BAD idea...it's too easy to subvert either way. > > But assuming that LL is permitted is also a bad idea. But you aren't assuming it's *permitted* under my proposal. You don't *have* to. You are only assuming that it's *present*. If you *don't* want it, then you turn it off, and it stays off. So you don't have to have it on if you don't want to. At all. > >> That's why having to make a conscious decision to kill it, or turn it >> back on, is a better idea. > > I am assuming that any decision on the part of a network administrator > to explicitly permit or forbid LL on a network would be a conscious one, > though it would not be acceptable to force that administrator to make > such decisions on a per-device basis. Not if the mere presence of DHCP kills it. As long as it's easy to automate killing v4LL, then I don't see a lot of network admins minding. Hell, you end up doing per-device config for *everything* anyway, network or not. You config users, you config capabilities...so this is one more, very fast, very efficient thing. Not a big deal. I can do the script in five minutes. > > At the same time, it is technically infeasible for such indications to > be authenticated if the device cannot be reliably configured as to which > authorities to trust. You get the device out of the box and set the password for it. This is a common task for *all* new devices on a network for any network admin. So we aren't creating any problems here. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 14:55:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04992 for ; Wed, 22 Jan 2003 14:55:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8E4A9913AE; Wed, 22 Jan 2003 14:58:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53060913AF; Wed, 22 Jan 2003 14:58: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 3BA2A913AE for ; Wed, 22 Jan 2003 14:58:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 287E85DED4; Wed, 22 Jan 2003 14:58:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 0FB3E5DDB7 for ; Wed, 22 Jan 2003 14:58:24 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5ED4814135; Wed, 22 Jan 2003 14:58:24 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 00705-05; Wed, 22 Jan 2003 14:58:23 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 7D7D114129; Wed, 22 Jan 2003 14:58:23 -0500 (EST) Date: Wed, 22 Jan 2003 14:58:22 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) Message-Id: <20030122145822.29b717b1.moore@cs.utk.edu> In-Reply-To: References: <20030122135642.0a93346b.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 1ab0036a7ec491a18ddf68220e4a0a2f5abd3366 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > BUT you can use things like SSH to ensure that only authorized, > authenticated sources can take that action. actually no. SSHing to a device that isn't configured to know which authentication tokens to accept and which to reject is not authentication. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 15:00:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05124 for ; Wed, 22 Jan 2003 15:00:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DDA51913B0; Wed, 22 Jan 2003 15:03:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94237913B2; Wed, 22 Jan 2003 15: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 8F96C913B0 for ; Wed, 22 Jan 2003 15:03:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 794365DEE4; Wed, 22 Jan 2003 15:03:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 5BA7C5DEBF for ; Wed, 22 Jan 2003 15:03:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id B72DF13FDA; Wed, 22 Jan 2003 15:03:31 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 00936-08; Wed, 22 Jan 2003 15:03:31 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 1F94B13FD3; Wed, 22 Jan 2003 15:03:31 -0500 (EST) Date: Wed, 22 Jan 2003 15:03:30 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122150330.5c8419a4.moore@cs.utk.edu> In-Reply-To: References: <20030122143655.2241b729.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: d94ffcc4b87c15b252beb6c5ee4ce9023e2462a6 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > completely unacceptable. without a uniform means of disabling LL, > > it is a denial-of-service attack on networks and applications. and > > you seem to be thinking in terms of conventional hosts when at least > > as much of the problems is hosts without a manual input. > > Reality check...without everyone running the same OS, uniformity will > never happen *anyway*. reality check - we have hundreds of millions of machines on the planet, of varying operating systems, all supporting TCP and IP and lots of other protocols. you're insisting on uniform implementation of LL but not on a uniform way of disabling LL. > And you confuse manual with physical. look up the word in a dictionary. hint: the root of "manual" is "man" which means "hand". > > I'm getting the impression you don't know what authentication is. > > Authentication: to require a user to identify themselves against a > predetermined criteria so how do you get a box which isn't configurable to have predetermined criteria that are appropriate to its network? > > how do you talk to a device when it doesn't even have a valid > > address?(and no, LL doesn't work - that forces you to configure each > > device from its own link) > > Initial out of the box config for devices without a physical input > device would require a one time hookup over the LL. not acceptable. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 15:03:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05282 for ; Wed, 22 Jan 2003 15:03:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B2110913B1; Wed, 22 Jan 2003 15:06:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8709991312; Wed, 22 Jan 2003 15:06: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 17147913B2 for ; Wed, 22 Jan 2003 15:06:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id F3EA75DEE4; Wed, 22 Jan 2003 15:06:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id DBF705DED4 for ; Wed, 22 Jan 2003 15:06:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 5553B14129; Wed, 22 Jan 2003 15:06:55 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 01502-07; Wed, 22 Jan 2003 15:06:54 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 29C8C13FDA; Wed, 22 Jan 2003 15:06:54 -0500 (EST) Date: Wed, 22 Jan 2003 15:06:53 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122150653.662bcc91.moore@cs.utk.edu> In-Reply-To: References: <20030122143301.4e396cb8.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 1157e0ef75150b28fc6c0ff80f08090367fae583 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 22 Jan 2003 14:57:49 -0500 "John C. Welch" wrote: > On 01/22/2003 14:33, "Keith Moore" wrote: > > >> Right...so we should therefore not require any authentication > >anywhere> when dealing with Zeroconf? > > > > The intersection between "zero configuration technologies" and > > authentication is the null set. > > Missing the point...i'm talking about authentication to *turn it off*. no you are missing the point. there is no way to securely authenticate to a device which has no explicit configuration about which authentication tokens to accept. none at all. and even if you do explicitly configure the device about what to accept (which does not scale), that configuration is wrong as soon as that device moves to another network. > > I am assuming that any decision on the part of a network > > administrator to explicitly permit or forbid LL on a network would > > be a conscious one, though it would not be acceptable to force that > > administrator to make such decisions on a per-device basis. > > Not if the mere presence of DHCP kills it. okay fine, but we're agreed (perhaps for different reasons) that the mere presence of DHCP should not kill LL. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 15:06:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05396 for ; Wed, 22 Jan 2003 15:06:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1B50791312; Wed, 22 Jan 2003 15:09:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA89D913B2; Wed, 22 Jan 2003 15:09: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 CF0A691312 for ; Wed, 22 Jan 2003 15:09:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id BD57D5DEE4; Wed, 22 Jan 2003 15:09:56 -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 4C8F55DED4 for ; Wed, 22 Jan 2003 15:09:56 -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 PAA21955 for ; Wed, 22 Jan 2003 15:09:55 -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 PAA27287 for ; Wed, 22 Jan 2003 15:09:55 -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 PAA09648 for ; Wed, 22 Jan 2003 15:09:55 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 15:09:52 -0500 Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122145822.29b717b1.moore@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 01/22/2003 14:58, "Keith Moore" wrote: >> BUT you can use things like SSH to ensure that only authorized, >> authenticated sources can take that action. > > actually no. SSHing to a device that isn't configured to know which > authentication tokens to accept and which to reject is not > authentication. It's not perfect, but it beats the hell out of any DHCP server being able to pooch your setttings. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 15:07:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05439 for ; Wed, 22 Jan 2003 15:07:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E3962913B2; Wed, 22 Jan 2003 15:10:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC598913B3; Wed, 22 Jan 2003 15:10: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 A73D7913B2 for ; Wed, 22 Jan 2003 15:10:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 95AA45DED4; Wed, 22 Jan 2003 15:10:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smail2.alcatel.fr (colt-na7.alcatel.fr [62.23.212.7]) by segue.merit.edu (Postfix) with ESMTP id 9ED185DEBF for ; Wed, 22 Jan 2003 15:10:53 -0500 (EST) Received: from mrsmail02.ms.cit.alcatel.fr (thot.ms.cit.alcatel.fr [172.25.80.18]) by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id h0MKAnbV014422; Wed, 22 Jan 2003 21:10:49 +0100 Received: from glaieul.ms.cit.alcatel.fr (glaieul [172.25.81.63]) by mrsmail02.ms.cit.alcatel.fr (8.10.2+Sun/8.8.7/ms-1.0) with ESMTP id h0MKAn928237; Wed, 22 Jan 2003 21:10:49 +0100 (MET) Received: (from jmaisonn@localhost) by glaieul.ms.cit.alcatel.fr (8.11.6+Sun/8.10.2) id h0MKAnS22262; Wed, 22 Jan 2003 21:10:49 +0100 (MET) Date: Wed, 22 Jan 2003 21:10:49 +0100 (MET) Message-Id: <200301222010.h0MKAnS22262@glaieul.ms.cit.alcatel.fr> From: julien maisonneuve To: moore@cs.utk.edu Cc: jwelch@mit.edu, moore@cs.utk.edu, zeroconf@merit.edu In-reply-to: <20030122143655.2241b729.moore@cs.utk.edu> (message from Keith Moore on Wed, 22 Jan 2003 14:36:55 -0500) Subject: Re: One last attempt to illustrate my concerns X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-zeroconf@merit.edu Precedence: bulk > Date: Wed, 22 Jan 2003 14:36:55 -0500 > From: Keith Moore > > completely unacceptable. without a uniform means of disabling LL, it is > a denial-of-service attack on networks and applications. and you seem > to be thinking in terms of conventional hosts when at least as much of > the problems is hosts without a manual input. But what if your attacker happens to have a stack that won't listen to you disabling requests and ignores DHCP altogether ? This mechanism doesn't give you any additional security. Julien. From owner-zeroconf@merit.edu Wed Jan 22 15:08:44 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05484 for ; Wed, 22 Jan 2003 15:08:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B286E913B3; Wed, 22 Jan 2003 15:11:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D109913B4; Wed, 22 Jan 2003 15:11: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 762E1913B3 for ; Wed, 22 Jan 2003 15:11:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6268E5DEEC; Wed, 22 Jan 2003 15:11:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smail2.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by segue.merit.edu (Postfix) with ESMTP id BFDCF5DEE4 for ; Wed, 22 Jan 2003 15:11:53 -0500 (EST) Received: from mrsmail02.ms.cit.alcatel.fr (thot.ms.cit.alcatel.fr [172.25.80.18]) by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id h0MKBqbV014722; Wed, 22 Jan 2003 21:11:52 +0100 Received: from glaieul.ms.cit.alcatel.fr (glaieul [172.25.81.63]) by mrsmail02.ms.cit.alcatel.fr (8.10.2+Sun/8.8.7/ms-1.0) with ESMTP id h0MKBq928304; Wed, 22 Jan 2003 21:11:52 +0100 (MET) Received: (from jmaisonn@localhost) by glaieul.ms.cit.alcatel.fr (8.11.6+Sun/8.10.2) id h0MKBqQ22265; Wed, 22 Jan 2003 21:11:52 +0100 (MET) Date: Wed, 22 Jan 2003 21:11:52 +0100 (MET) Message-Id: <200301222011.h0MKBqQ22265@glaieul.ms.cit.alcatel.fr> From: julien maisonneuve To: jwelch@mit.edu Cc: zeroconf@merit.edu In-reply-to: Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-zeroconf@merit.edu Precedence: bulk > Date: Wed, 22 Jan 2003 14:26:25 -0500 > From: "John C. Welch" > > Finally, if I want zeroconf on out of the box, then I want it ON...no > mucking about. Just a small throught : when you buy a printer, or any such device that has specific properties, you often have to install some sort of a driver that knows how to talk with it and configure it properly (most devices are shipped with a CD). This driver is perfectly able to switch v4ll ON whenever it is required. So why not use your approach (manual setting, no network decision which is too easily subverted), and ship computers with v4ll OFF as a default ? I suppose a printer and other dumb devices should be shipped with v4ll ON to avoid any config. Julien. From owner-zeroconf@merit.edu Wed Jan 22 15:15:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05757 for ; Wed, 22 Jan 2003 15:15:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E4950913B7; Wed, 22 Jan 2003 15:18:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8211913BB; Wed, 22 Jan 2003 15:18: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 E9777913B4 for ; Wed, 22 Jan 2003 15:17:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id C5B155DEB7; Wed, 22 Jan 2003 15:17:01 -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 5C5E95DE92 for ; Wed, 22 Jan 2003 15:17:01 -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 PAA26111 for ; Wed, 22 Jan 2003 15:17:00 -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 PAA28831 for ; Wed, 22 Jan 2003 15:17:00 -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 PAA13831 for ; Wed, 22 Jan 2003 15:17:00 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 15:16:57 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122150330.5c8419a4.moore@cs.utk.edu> 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 PAA05757 On 01/22/2003 15:03, "Keith Moore" wrote: >> Reality check...without everyone running the same OS, uniformity will >> never happen *anyway*. > > reality check - we have hundreds of millions of machines on the planet, > of varying operating systems, all supporting TCP and IP and lots of > other protocols. you're insisting on uniform implementation of LL but > not on a uniform way of disabling LL. You can't get a uniform implementation of TCP/IP, what makes you think your proposal will magically get done in a uniform manner. My proposal only requires an on/off switch. It allows vendors to implement it in the fashion that will work best for their customers. > >> And you confuse manual with physical. > > look up the word in a dictionary. hint: the root of "manual" is "man" > which means "hand". I *manually* configure my Unreal Tournament server from my bedroom, it's in my living room...no KVM, and I'm not plastic man...but, since you forget that every word has multiple meanings: " operated by human effort rather than by a machine, computer, or type of power Encarta® World English Dictionary © 1999 Microsoft Corporation. All rights reserved. Developed for Microsoft by Bloomsbury Publishing Plc." Definition 3. THAT is the one I'm using. >> Authentication: to require a user to identify themselves against a >> predetermined criteria > > so how do you get a box which isn't configurable to have predetermined > criteria that are appropriate to its network? How do you configure a new box now? Answer, you do it manually, for the initial setup. Your computer didn't come from the factory knowing who you were, your userID or your password. ALL networkable devices have SOME way to MANUALLY configure them...otherwise, you can't change ANY setting, which makes them pretty useless. > >>> how do you talk to a device when it doesn't even have a valid >>> address?(and no, LL doesn't work - that forces you to configure each >>> device from its own link) >> >> Initial out of the box config for devices without a physical input >> device would require a one time hookup over the LL. > > not acceptable. Give me one device that comes out of the box with every setting configured for every possible situation. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 15:17:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05815 for ; Wed, 22 Jan 2003 15:17:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 68240913B4; Wed, 22 Jan 2003 15:20:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39152913B5; Wed, 22 Jan 2003 15:20: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 F189C913B4 for ; Wed, 22 Jan 2003 15:20:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF55D5DE83; Wed, 22 Jan 2003 15:20:19 -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 725B15DEB7 for ; Wed, 22 Jan 2003 15:20:19 -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 PAA27743 for ; Wed, 22 Jan 2003 15:20:18 -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 PAA29528 for ; Wed, 22 Jan 2003 15:20:18 -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 PAA15685 for ; Wed, 22 Jan 2003 15:20:18 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 15:20:16 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122150653.662bcc91.moore@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 01/22/2003 15:06, "Keith Moore" wrote: >> Missing the point...i'm talking about authentication to *turn it off*. > > no you are missing the point. there is no way to securely authenticate > to a device which has no explicit configuration about which > authentication tokens to accept. none at all. It's MORE secure than random servers killing it. > > and even if you do explicitly configure the device about what to accept > (which does not scale), that configuration is wrong as soon as that > device moves to another network. > Bullshit. Network admins do this trick on thousands of devices *daily*...it scales amazingly well. Your second sentence is wrong if you tell it "Don't use v4LL, use DHCP". If you use manual addresses, then you assume the responsibility of changing that address the hard way ANYWAY. >>> I am assuming that any decision on the part of a network >>> administrator to explicitly permit or forbid LL on a network would >>> be a conscious one, though it would not be acceptable to force that >>> administrator to make such decisions on a per-device basis. >> >> Not if the mere presence of DHCP kills it. > > okay fine, but we're agreed (perhaps for different reasons) that the > mere presence of DHCP should not kill LL. Oh definitely. I think it's an amazingly convoluted and bad idea. But I at least have a solution that I can show you a direct analog for *now*, this instant. Do you have something similar? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 15:18:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05869 for ; Wed, 22 Jan 2003 15:18:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C2942913B5; Wed, 22 Jan 2003 15:21:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 933C2913B6; Wed, 22 Jan 2003 15:21: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 59496913B5 for ; Wed, 22 Jan 2003 15:21:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 466915DEB7; Wed, 22 Jan 2003 15:21:47 -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 BB9615DE83 for ; Wed, 22 Jan 2003 15:21:46 -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 PAA27890 for ; Wed, 22 Jan 2003 15:21:45 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA24203 for ; Wed, 22 Jan 2003 15:21:45 -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 PAA16431 for ; Wed, 22 Jan 2003 15:21:44 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 15:21:42 -0500 Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200301222011.h0MKBqQ22265@glaieul.ms.cit.alcatel.fr> 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 01/22/2003 15:11, "julien maisonneuve" wrote: >> Finally, if I want zeroconf on out of the box, then I want it ON...no >> mucking about. > > Just a small throught : when you buy a printer, or any such device > that has specific properties, you often have to install some sort of a > driver that knows how to talk with it and configure it properly (most > devices are shipped with a CD). > This driver is perfectly able to switch v4ll ON whenever it is > required. > So why not use your approach (manual setting, no network decision > which is too easily subverted), and ship computers with v4ll OFF > as a default ? I suppose a printer and other dumb devices should be > shipped with v4ll ON to avoid any config. v4LL on is then zeroconf, v4LL off is not. As you just pointed out, changing it to off takes about ten seconds. That way, it's there, until/unless you don't want it, then it is not. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 15:20:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05951 for ; Wed, 22 Jan 2003 15:20:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 21BCE913B6; Wed, 22 Jan 2003 15:23:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA540913B8; Wed, 22 Jan 2003 15:23:31 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B0EFE913B6 for ; Wed, 22 Jan 2003 15:23:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 919A25DEB7; Wed, 22 Jan 2003 15:23:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 71E3B5DE83 for ; Wed, 22 Jan 2003 15:23:30 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 4EF8A13FDA; Wed, 22 Jan 2003 15:23:30 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 03934-05; Wed, 22 Jan 2003 15:23:29 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id ABC0613FD3; Wed, 22 Jan 2003 15:23:29 -0500 (EST) Date: Wed, 22 Jan 2003 15:23:29 -0500 From: Keith Moore To: julien maisonneuve Cc: moore@cs.utk.edu, jwelch@mit.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122152329.497c05ab.moore@cs.utk.edu> In-Reply-To: <200301222010.h0MKAnS22262@glaieul.ms.cit.alcatel.fr> References: <20030122143655.2241b729.moore@cs.utk.edu> <200301222010.h0MKAnS22262@glaieul.ms.cit.alcatel.fr> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 07175b2957d59dc388951c144a5d6b28cb866225 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 22 Jan 2003 21:10:49 +0100 (MET) julien maisonneuve wrote: > > Date: Wed, 22 Jan 2003 14:36:55 -0500 > > From: Keith Moore > > > > completely unacceptable. without a uniform means of disabling LL, > > it is a denial-of-service attack on networks and applications. and > > you seem to be thinking in terms of conventional hosts when at least > > as much of the problems is hosts without a manual input. > > But what if your attacker happens to have a stack that won't listen to > you disabling requests and ignores DHCP altogether ? > This mechanism doesn't give you any additional security. then (assuming other devices are well-behaved) the attacker is marginalized and easier to detect. it is understood that an attacker may be ill-behaved. what is unacceptable is having the standard encourage poor behavior on the part of devices. also, by "denial-of-service attack" above, I was referring to the effect of having large numbers of hosts on managed networks speaking LL, rather than some specific, intentional attack. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 15:20:52 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05981 for ; Wed, 22 Jan 2003 15:20:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 92274913B8; Wed, 22 Jan 2003 15:24:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE1CE913BB; Wed, 22 Jan 2003 15:24: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 9C0B8913B8 for ; Wed, 22 Jan 2003 15:24:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8AB0B5DEBF; Wed, 22 Jan 2003 15:24:00 -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 9D6005DE83 for ; Wed, 22 Jan 2003 15:23:59 -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 h0MDNc620833; Wed, 22 Jan 2003 06:23:38 -0700 Date: Wed, 22 Jan 2003 13:23:37 -0700 Subject: Re: One last attempt to illustrate my concerns Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "John C. Welch" , zeroconf@merit.edu To: Keith Moore From: Alex Karahalios In-Reply-To: <20030122150330.5c8419a4.moore@cs.utk.edu> Message-Id: <6375C1C0-2E47-11D7-A5CD-00039377AD70@Outersoft.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Keith, Also manual (hand) could mean your hand typing on a keyboard sending commands through the network. In reality the semantics of the word "manual" should not deter a vendor for providing a means of disabling LL. For example, the device which I am developing, has a web interface which allows configuration. I would consider this manual in the sense that a person has to use their hands to affect a change. The device also has a physical factory default button which can be manipulated to set the device to factory defaults. I think this is manual also. Alex Karahalios On Wednesday, January 22, 2003, at 01:03 PM, Keith Moore wrote: >> And you confuse manual with physical. > > look up the word in a dictionary. hint: the root of "manual" is "man" > which means "hand". From owner-zeroconf@merit.edu Wed Jan 22 15:26:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06115 for ; Wed, 22 Jan 2003 15:26:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B78A9913BB; Wed, 22 Jan 2003 15:29:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A321913BC; Wed, 22 Jan 2003 15:29: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 5299D913BB for ; Wed, 22 Jan 2003 15:29:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3B78F5DEBF; Wed, 22 Jan 2003 15:29:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 228EB5DE83 for ; Wed, 22 Jan 2003 15:29:46 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id F08AD14135; Wed, 22 Jan 2003 15:29:45 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 04457-08; Wed, 22 Jan 2003 15:29:45 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 5DC9613FD3; Wed, 22 Jan 2003 15:29:45 -0500 (EST) Date: Wed, 22 Jan 2003 15:29:45 -0500 From: Keith Moore To: Alex Karahalios Cc: moore@cs.utk.edu, jwelch@MIT.EDU, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122152945.2873d4d7.moore@cs.utk.edu> In-Reply-To: <6375C1C0-2E47-11D7-A5CD-00039377AD70@Outersoft.com> References: <20030122150330.5c8419a4.moore@cs.utk.edu> <6375C1C0-2E47-11D7-A5CD-00039377AD70@Outersoft.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 8ef99ef7c28bad11eea8839acb51606c0514a1ce Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wed, 22 Jan 2003 13:23:37 -0700 Alex Karahalios wrote: > Hi Keith, > > Also manual (hand) could mean your hand typing on a keyboard sending > commands through the network. In reality the semantics of the word > "manual" should not deter a vendor for providing a means of disabling > LL. I hope we can manage to have a clear standard without having to rely on fine distinctions in the English language, especially because many implementors will not be native English speakers. But there's clearly a difference between being able to specify policy on LL use on a per-network basis and having to configure each device individually, regardless of whether or not someone's hands have to touch that device. As one particular example, you can't automate configuration of nework devices if you have to arrange for each device to be hooked to a link that is shared with a computer that is doing the configuration. Whether that's "manual" or not, that's not an acceptable way to dictate policy. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 15:28:08 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06218 for ; Wed, 22 Jan 2003 15:28:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 51246913BC; Wed, 22 Jan 2003 15:30:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 17E82913BD; Wed, 22 Jan 2003 15:30: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 E0589913BC for ; Wed, 22 Jan 2003 15:30:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id D9E185DEE4; Wed, 22 Jan 2003 15:30:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id F07905DE83 for ; Wed, 22 Jan 2003 15:30:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id EF78414147; Wed, 22 Jan 2003 15:30:42 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 04876-08; Wed, 22 Jan 2003 15:30:42 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 624C913FD3; Wed, 22 Jan 2003 15:30:42 -0500 (EST) Date: Wed, 22 Jan 2003 15:30:42 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) Message-Id: <20030122153042.1a6a4364.moore@cs.utk.edu> In-Reply-To: References: <20030122145822.29b717b1.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 4f5a4e565487bdae3cbcb51964e4d50347f0e39f Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > actually no. SSHing to a device that isn't configured to know which > > authentication tokens to accept and which to reject is not > > authentication. > > It's not perfect, but it beats the hell out of any DHCP server being > able to pooch your setttings. from a security point-of-view, it's exactly the same level of vulnerability. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 15:30:50 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06275 for ; Wed, 22 Jan 2003 15:30:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1E42B91210; Wed, 22 Jan 2003 15:34:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA3D1913BD; Wed, 22 Jan 2003 15:34: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 C823391210 for ; Wed, 22 Jan 2003 15:32:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id A86EF5DE92; Wed, 22 Jan 2003 15:32:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 879155DE83 for ; Wed, 22 Jan 2003 15:32:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 3F0FE14148; Wed, 22 Jan 2003 15:32:20 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 05168-07; Wed, 22 Jan 2003 15:32:19 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 9515813FD3; Wed, 22 Jan 2003 15:32:19 -0500 (EST) Date: Wed, 22 Jan 2003 15:32:18 -0500 From: Keith Moore To: julien maisonneuve Cc: moore@cs.utk.edu, jwelch@mit.edu, zeroconf@merit.edu Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) Message-Id: <20030122153218.7c5476f7.moore@cs.utk.edu> In-Reply-To: <200301222011.h0MKBqQ22265@glaieul.ms.cit.alcatel.fr> References: <200301222011.h0MKBqQ22265@glaieul.ms.cit.alcatel.fr> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: ab9e73f17ac365e3e363acf3abeed081a33da759 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Just a small throught : when you buy a printer, or any such device > that has specific properties, you often have to install some sort of a > driver that knows how to talk with it and configure it properly (most > devices are shipped with a CD). let's not use printer vendors' mistakes to justify other mistakes. it's perfectly reasonable to expect printers to work out of the box, and implement standard spooling protocols and page description languages, without having to install drivers. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 15:31:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06298 for ; Wed, 22 Jan 2003 15:31:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2BE9D913BD; Wed, 22 Jan 2003 15:34:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4DDA913BE; Wed, 22 Jan 2003 15:34: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 AD314913BD for ; Wed, 22 Jan 2003 15:34:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 91BD35DEBF; Wed, 22 Jan 2003 15:34:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 7A7635DE83 for ; Wed, 22 Jan 2003 15:34:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 54EAA14135; Wed, 22 Jan 2003 15:34:23 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 05168-10; Wed, 22 Jan 2003 15:34:22 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id B8D3013FD3; Wed, 22 Jan 2003 15:34:22 -0500 (EST) Date: Wed, 22 Jan 2003 15:34:22 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122153422.39536559.moore@cs.utk.edu> In-Reply-To: References: <20030122150653.662bcc91.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 288d49877cd006d8384ae02a015ae7046e648f71 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > no you are missing the point. there is no way to securely > > authenticate to a device which has no explicit configuration about > > which authentication tokens to accept. none at all. > > It's MORE secure than random servers killing it. nope, it's the same problem. the same random server that kills LL via DHCP can "authenticate" to the device and kill LL that way. and having the device save state about network configuration isn't necessarily a good way to go anyway - the network should indicate to the device what it's policies are. the network is in a good position to police those policies - it can filter traffic that doesn't follow them. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 15:31:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06313 for ; Wed, 22 Jan 2003 15:31:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 23CC0913BE; Wed, 22 Jan 2003 15:34:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1D41913BF; Wed, 22 Jan 2003 15:34: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 781FB913BE for ; Wed, 22 Jan 2003 15:34:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 67C0F5DE92; Wed, 22 Jan 2003 15:34:53 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by segue.merit.edu (Postfix) with ESMTP id 1A99A5DE83 for ; Wed, 22 Jan 2003 15:34:53 -0500 (EST) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h0MKYqFF020783 for ; Wed, 22 Jan 2003 12:34:52 -0800 (PST) Received: from mac.com ([200.67.17.194]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id H94UI300.JAB for ; Wed, 22 Jan 2003 12:34:51 -0800 Date: Wed, 22 Jan 2003 14:34:51 -0600 Subject: On Killing IPv4LL on the Link Content-Type: multipart/alternative; boundary=Apple-Mail-8-535982436 Mime-Version: 1.0 (Apple Message framework v551) From: Rod To: zeroconf@merit.edu In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk --Apple-Mail-8-535982436 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit John, do you realize what is being suggested is what Mac OS X 10.2 does right now? You seemed to defend it quite a bit previously, and now you don't seem to agree with standarizing the way OS X 10.2 does it. I think you overlooked the description of the new proposal, and that's the reason why suddenly everyone who agreed with your points now seems to be in disagreement with you. Here are some excrepts from Josh Graessley's messages that I beg you to carefully re-read and understand: > Versions of Mac OS that support link-local will only acquire link > local addresses when configured to use DHCP and the DHCP server does > not respond. Various versions of the Mac OS will continue to send DHCP > requests. If a DHCP server does appear, the Mac will use the address > from the DHCP server but it will also continue to use the IPv4LL > address. The IPv4LL address is maintained to avoid unnecessarily > killing already established connections. > The Mac OS will watch for link changed events to determine if DHCP > should be tried again or the IPv4LL address assignment should occur > again. > If DHCP is present, I don't see any reason to acquire a LL address. > > On the other hand, if my machine or some other device for whatever > reason can't get an address from DHCP, or if it doesn't implement > DHCP, then I'd like it get an IPv4LL address. This assures me that I > have some way of communicating with the device. I don't want my > machine to silently refuse to acquire an address because some guy in > the dorm playing a prank is sending out some magic packet to disable > IPv4LL. I don't think we need to design a special protocol either. > I think it makes sense to only acquire an IPv4LL address when the > preferred configuration method fails (dhcp, bootp, whatever). I think > it makes sense to allow hosts with global addresses to communicate > with IPv4LLs. I think some devices may choose not to implement DHCP > and rely on IPv4LL for their addresses. I don't believe we should > explicit restrict the possibility of such devices. > If my desktop machine is LL aware, it should have no difficulty > communicating with a device supporting only LL addressing. Section > 1.7, Communication Between Link-Local and Routable Addresses, covers > this with an example of a laptop with a global address only > communicating with a web server with a global address to retrieve a > page and printing that page to a printer with an IPv4LL on the local > link. > The original argument for requiring link local addresses all the time > was to communicate with other nodes that may have nothing but a link > local address. This was necessary because the first drafts required > that traffic to a link local address have a link local address as the > source. Without a link local address, you couldn't communicate with > another node that had only a link local address. That restriction has > been lifted. Do you realize no changes have to be made to the DHCP spec to support this? Do you realize the presence of a DHCP server will NOT kill IPv4LL on the link? It will only make hosts that aquire a global address NOT acquire an IPv4 LL address as well (since they DON'T need it!), and STILL be easily able to communicate with IPv4LL addresses by the way of ARP, which is NOT complicated, in fact that's how Mac OS X 10.2 does it today? You seem to think that DHCP will absolutely kill IPv4LL on the link. It will not! Not acquiring an IPv4LL address when you already have a global one does not mean you won't be able to communicate with devices that do have one, either because they only work with IPv4LL or because they failed to get a global address. If you are concerned with them getting global addresses, you can disable this yourself most of the time (either on the device itself or on the dhcp server) and instead they will use an IPv4LL address. I think this proposal goes in line with what you want, you just haven't taken the time to understand it well, and seem to be confusing it with earlier proposals of completely disabling IPv4LL with a dhcp option and whatnot. This is not the same. Your manual config suggestion seems unwarranted since I think if you understand these points you will see they cover the needs you have been addressing. Thanks! -Rod --Apple-Mail-8-535982436 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit John, do you realize what is being suggested is what Mac OS X 10.2 does right now? You seemed to defend it quite a bit previously, and now you don't seem to agree with standarizing the way OS X 10.2 does it. I think you overlooked the description of the new proposal, and that's the reason why suddenly everyone who agreed with your points now seems to be in disagreement with you. Here are some excrepts from Josh Graessley's messages that I beg you to carefully re-read and understand: Versions of Mac OS that support link-local will only acquire link local addresses when configured to use DHCP and the DHCP server does not respond. Various versions of the Mac OS will continue to send DHCP requests. If a DHCP server does appear, the Mac will use the address from the DHCP server but it will also continue to use the IPv4LL address. The IPv4LL address is maintained to avoid unnecessarily killing already established connections. The Mac OS will watch for link changed events to determine if DHCP should be tried again or the IPv4LL address assignment should occur again. If DHCP is present, I don't see any reason to acquire a LL address. On the other hand, if my machine or some other device for whatever reason can't get an address from DHCP, or if it doesn't implement DHCP, then I'd like it get an IPv4LL address. This assures me that I have some way of communicating with the device. I don't want my machine to silently refuse to acquire an address because some guy in the dorm playing a prank is sending out some magic packet to disable IPv4LL. I don't think we need to design a special protocol either. I think it makes sense to only acquire an IPv4LL address when the preferred configuration method fails (dhcp, bootp, whatever). I think it makes sense to allow hosts with global addresses to communicate with IPv4LLs. I think some devices may choose not to implement DHCP and rely on IPv4LL for their addresses. I don't believe we should explicit restrict the possibility of such devices.0000,6363,1212 If my desktop machine is LL aware, it should have no difficulty communicating with a device supporting only LL addressing. Section 1.7, Communication Between Link-Local and Routable Addresses, covers this with an example of a laptop with a global address only communicating with a web server with a global address to retrieve a page and printing that page to a printer with an IPv4LL on the local link.0000,6363,1212 The original argument for requiring link local addresses all the time was to communicate with other nodes that may have nothing but a link local address. This was necessary because the first drafts required that traffic to a link local address have a link local address as the source. Without a link local address, you couldn't communicate with another node that had only a link local address. That restriction has been lifted. Do you realize no changes have to be made to the DHCP spec to support this? Do you realize the presence of a DHCP server will NOT kill IPv4LL on the link? It will only make hosts that aquire a global address NOT acquire an IPv4 LL address as well (since they DON'T need it!), and STILL be easily able to communicate with IPv4LL addresses by the way of ARP, which is NOT complicated, in fact that's how Mac OS X 10.2 does it today? You seem to think that DHCP will absolutely kill IPv4LL on the link. It will not! Not acquiring an IPv4LL address when you already have a global one does not mean you won't be able to communicate with devices that do have one, either because they only work with IPv4LL or because they failed to get a global address. If you are concerned with them getting global addresses, you can disable this yourself most of the time (either on the device itself or on the dhcp server) and instead they will use an IPv4LL address. I think this proposal goes in line with what you want, you just haven't taken the time to understand it well, and seem to be confusing it with earlier proposals of completely disabling IPv4LL with a dhcp option and whatnot. This is not the same. Your manual config suggestion seems unwarranted since I think if you understand these points you will see they cover the needs you have been addressing. Thanks! -Rod --Apple-Mail-8-535982436-- From owner-zeroconf@merit.edu Wed Jan 22 15:43:36 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06634 for ; Wed, 22 Jan 2003 15:43:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 63440913BF; Wed, 22 Jan 2003 15:46:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C137913C0; Wed, 22 Jan 2003 15:46: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 B0834913BF for ; Wed, 22 Jan 2003 15:46:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 023CC5DF02; Wed, 22 Jan 2003 15:46:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smail2.alcatel.fr (colt-na7.alcatel.fr [62.23.212.7]) by segue.merit.edu (Postfix) with ESMTP id BBF755DF01 for ; Wed, 22 Jan 2003 15:46:08 -0500 (EST) Received: from mrsmail02.ms.cit.alcatel.fr (thot.ms.cit.alcatel.fr [172.25.80.18]) by smail2.alcatel.fr (ALCANET/NETFR) with ESMTP id h0MKk6bV024812; Wed, 22 Jan 2003 21:46:06 +0100 Received: from glaieul.ms.cit.alcatel.fr (glaieul [172.25.81.63]) by mrsmail02.ms.cit.alcatel.fr (8.10.2+Sun/8.8.7/ms-1.0) with ESMTP id h0MKk6929495; Wed, 22 Jan 2003 21:46:06 +0100 (MET) Received: (from jmaisonn@localhost) by glaieul.ms.cit.alcatel.fr (8.11.6+Sun/8.10.2) id h0MKk5R22291; Wed, 22 Jan 2003 21:46:05 +0100 (MET) Date: Wed, 22 Jan 2003 21:46:05 +0100 (MET) Message-Id: <200301222046.h0MKk5R22291@glaieul.ms.cit.alcatel.fr> From: julien maisonneuve To: jwelch@mit.edu Cc: Zeroconf In-reply-to: Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-zeroconf@merit.edu Precedence: bulk > Date: Wed, 22 Jan 2003 15:21:42 -0500 > From: "John C. Welch" > > v4LL on is then zeroconf, v4LL off is not. As you just pointed out, changing > it to off takes about ten seconds. That way, it's there, until/unless you > don't want it, then it is not. The point is not to qualify what is zeroconf and what is not, the point is to minimize user intervention. Switching it on on your computer requires no additional user intervention if there is already a driver to install. So far I do not share other people's concerns about v4ll (or rather I don't think any of this will buy us anymore than an illusion of security), so I do not specifically care whether it is on or off, but a lot of people seem to care, and want it off unless there is a good reason. IF people want a v4ll switching mechanism, it should not be network based because it is too easily subverted (and thus lead to denial of service of linklocal devices), so it should be manual. Several people want it off by default, and I can't see the problem since drivers can change it to on at installation and/or runtime. Also, it would be useful to say what we mean exactly by switching «it» on or off. Giving a v4ll address to an interface is not the same thing as sending packets to a v4ll address (which may take no more than a local route). I am assuming that we talk about the former. Julien. From owner-zeroconf@merit.edu Wed Jan 22 15:50:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06775 for ; Wed, 22 Jan 2003 15:50:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 94D1A91313; Wed, 22 Jan 2003 15:54:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6206691314; Wed, 22 Jan 2003 15:54: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 442CD91313 for ; Wed, 22 Jan 2003 15:54:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2952A5DEE2; Wed, 22 Jan 2003 15:54:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 111F35DEBE for ; Wed, 22 Jan 2003 15:54:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id CFE6114148; Wed, 22 Jan 2003 15:54:04 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 08204-08; Wed, 22 Jan 2003 15:54:04 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 337EC14147; Wed, 22 Jan 2003 15:54:04 -0500 (EST) Date: Wed, 22 Jan 2003 15:54:04 -0500 From: Keith Moore To: julien maisonneuve Cc: moore@cs.utk.edu, jwelch@mit.edu, zeroconf@merit.edu Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) Message-Id: <20030122155404.1c0ccd0f.moore@cs.utk.edu> In-Reply-To: <200301222046.h0MKk5R22291@glaieul.ms.cit.alcatel.fr> References: <200301222046.h0MKk5R22291@glaieul.ms.cit.alcatel.fr> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: ccfd8f7e8e9eee424e6335d78ac191cf76a0c103 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > IF people want a v4ll switching mechanism, it should not be network > based because it is too easily subverted (and thus lead to denial of > service of linklocal devices), so it should be manual. nobody has given a convincing argument that "subverting" a device to not use LL is any more likely than any of the myriad other kinds of "subversion" that an attacker could use if the default were different. and if by "manual" you mean "cannot be automated" then it doesn't solve the problem. > Several people want it off by default, and I can't see the problem > since drivers can change it to on at installation and/or runtime. the last thing I'd want is for a device driver to try to decide whether it should talk to a printer using an LL address or a routable address. the device driver should not be trying to guess network policy any more the device it wants to talk to. nor should we presume that a device driver is necessary. (I can talk to most of the printers around here without any kind of device driver - since they all speak lpd and postscript. I just type "port-lpr -Plp -Sprinter-address filename". ) -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 16:19:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07496 for ; Wed, 22 Jan 2003 16:19:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 65ADB9120F; Wed, 22 Jan 2003 16:22:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3BB9A91316; Wed, 22 Jan 2003 16:22: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 378A69120F for ; Wed, 22 Jan 2003 16:22:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E1E25DF15; Wed, 22 Jan 2003 16:22:30 -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 3102A5DF09 for ; Wed, 22 Jan 2003 16:22:29 -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 h0MEMQ621415; Wed, 22 Jan 2003 07:22:27 -0700 Date: Wed, 22 Jan 2003 14:22:25 -0700 Subject: Re: On Killing IPv4LL on the Link Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Rod From: Alex Karahalios In-Reply-To: Message-Id: <99F940EE-2E4F-11D7-A5CD-00039377AD70@Outersoft.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Rod, What is wrong with a "device" acquiring both a v4LL address and an address via DHCP? By "device" I mean something that has a controlled set of applications which know how to handle both addresses. This makes the implementation much easier since the network stack or application does not have to deal with the LL address no longer being valid when a DHCP address is acquired. The v4LL draft should not preclude both being active at any given time, although the draft may specify a mechanism such as the alternate (e.g. DHCP) acquisition of an address as a means to optionally disable v4LL. Alex Karahalios On Wednesday, January 22, 2003, at 01:34 PM, Rod wrote: > Do you realize the presence of a DHCP server will NOT kill IPv4LL on > the link? It will only make hosts that aquire a global address NOT > acquire an IPv4 LL address as well (since they DON'T need it!), and > STILL be easily able to communicate with IPv4LL addresses by the way > of ARP, which is NOT complicated, in fact that's how Mac OS X 10.2 > does it today? From owner-zeroconf@merit.edu Wed Jan 22 16:36:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08165 for ; Wed, 22 Jan 2003 16:36:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F3F09913C1; Wed, 22 Jan 2003 16:39:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C8C2C913C2; Wed, 22 Jan 2003 16:39: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 B9A80913C1 for ; Wed, 22 Jan 2003 16:39:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id A7F885DF15; Wed, 22 Jan 2003 16:39:45 -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 5F3365DF12 for ; Wed, 22 Jan 2003 16:39:45 -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); Wed, 22 Jan 2003 13:39:44 -0800 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 22 Jan 2003 13:39:44 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by INET-HUB-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3710.0); Wed, 22 Jan 2003 13:39:44 -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); Wed, 22 Jan 2003 13:39:44 -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.3718.0); Wed, 22 Jan 2003 13:39:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: On Killing IPv4LL on the Link Date: Wed, 22 Jan 2003 13:38:42 -0800 Message-ID: Thread-Topic: On Killing IPv4LL on the Link Thread-Index: AcLCXFBWLQEIpMttQu+49MVDxSQqQwAAjWYg From: "Christian Huitema" To: "Alex Karahalios" , "Rod" Cc: X-OriginalArrivalTime: 22 Jan 2003 21:39:43.0743 (UTC) FILETIME=[C6C6D8F0:01C2C25E] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA08165 > What is wrong with a "device" acquiring both a v4LL address and an > address via DHCP? By "device" I mean something that has a controlled > set of applications which know how to handle both addresses. This makes > the implementation much easier since the network stack or application > does not have to deal with the LL address no longer being valid when a > DHCP address is acquired. What would be wrong would be to force systems that already have a DHCP address to also acquire a more ambiguous, scoped address. -- Christian Huitema From owner-zeroconf@merit.edu Wed Jan 22 16:45:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08536 for ; Wed, 22 Jan 2003 16:45:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B53691221; Wed, 22 Jan 2003 16:48:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EAA729121E; Wed, 22 Jan 2003 16:48: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 6E11B913C4 for ; Wed, 22 Jan 2003 16:48:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4DA635DEE8; Wed, 22 Jan 2003 16:48:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 012D85DEBA for ; Wed, 22 Jan 2003 16:48: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 h0MLmlI28906 for ; Wed, 22 Jan 2003 13:48:47 -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, 22 Jan 2003 13:48:47 -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 h0MLmlf02283 for ; Wed, 22 Jan 2003 13:48:47 -0800 (PST) Date: Wed, 22 Jan 2003 13:48:36 -0800 Subject: When to assign IPv4LL Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030122145705.554eaf0a.moore@cs.utk.edu> Message-Id: <42650098-2E53-11D7-8BF8-000393760260@apple.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, January 22, 2003, at 11:57 AM, Keith Moore wrote: > I am not sure I even understand what you are saying, because some of > the > statements seem to be contradictory. So rather than trying to > respond in detail to statements that I don't think I understand, let me > see if it helps to rephrase what I'm saying: My apologies. Let me try to clarify. > 1. Networks need a way to say to devices "don't use LL" (because LL > causes problems) and optionally "use this other address" (so that > autoconfiguring devices will continue to function) My opinion on this is that networks don't need a way to say this. I don't even really understand what it means for a network to say anything. A network is a collection of devices connected together, there is no central authority. I do believe that IPv4LL address can cause some issues and a global address is preferable over an IPv4LL. I think that there is no reason to assign a link local address unless a device is unable to acquire a global address through any configuration method. As an example, if a client is configured to use DHCP and it receives no DHCP response, I believe it makes sense to try and assign an IPv4LL address. > 2. Having autoconfiguring devices try DHCP first will not interoperate > well with certain DSL modems. Maybe that's not this group's problem, > but we should at least be aware of it. I think of IPv4LL as another configuration method, similar to DHCP, though you end up with a scoped address which does have limitations. I think it makes sense for vendors to offer an option to use only IPv4LL in addition to the other configuration methods they support. As stated above, I believe that if a configuration method fails to acquire an address, a device should try to self assign an IPv4LL. > Partially because of #2, it might be that an explicit indication from > DHCP(or some other protocol) that means "don't use LL" would be better > than interpreting a DHCP response to an address request as an implicit > indication that LL should not be used. Or not. I see this as a > question of which is worse: I don't see what adding any options to DHCP buys us. If a device gets a DHCP response, then presumably it's getting a global address so it doesn't need an address. If a device doesn't receive a DHCP response, then the device should self assign an IPv4LL. If the device is not configured to use DHCP then DHCP options won't matter. In the scenario you outlined before, it sounds like the only good solution is for your printer to be assigned to not bother with DHCP and just self assign an IPv4LL address. > a. Accidental use of LL on a managed network, with all of the problems > that this causes for applications, or > > b. Failure of home networks that use such DSL modems in the presence of > autoconfiguring devices. Even in a managed environment, it may be desirable or acceptable for a device to self assign an IPv4LL initially. If you get a printer out of the box and it defaults to using IPv4LL (or DHCP and falls back to IPv4LL), it might be nice to have that printer just show up so you can connect to and configure it the way you'd like. > Offhand, I tend to think that the second case is worse. The managed > network presumably has someone with expertise and perhaps diagnostic > tools who can turn on the "disable LL" signal if/when it causes > problems, whereas the home network user has neither of these. So it's > better to break the managed network, *provided* there's a way in the > standard for the managed network to fix the problem. I still don't see a case for the "disable LL" signal. If you don't want IPv4LL addresses on your network, configure devices to use DHCP and don't let your DHCP server go down. >> I don't think we should put unnecessary restrictions in to the IPv4LL >> draft to satisfy deluded administrators that think not handing out a >> DHCP address is a way to keep unauthorized people from using the >> network. > > As for this, as I explained earlier - it is not for this WG to decide > whether existing networks' access control methods for IP networks > are useful or secure, nor to decide that it's okay to subvert them. > This WG is proposing changes to an long-existing, widely-deployed, > heavily-used communications interface. It therefore has the burden of > minimizing harm to existing uses of that interface. We are doing two things. 1) Introducing addresses that have a very limited scope. Those addresses can cause problems for applications that use referrals. 2) Introducing a method to assign an address to an interface. This method will only assign address which have a limited scope. Ideally, other methods would be used when available to acquire an address that does not have scope limitations. There is no protocol on the wire that prevents people from manually assigning addresses. Why should there be one that prevents the computer from self assigning an IPv4LL address? Yes, IPv4LL addresses are arguably less functional that a global address, but if a global address is not available, they're a lot better than nothing. -josh From owner-zeroconf@merit.edu Wed Jan 22 16:53:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08800 for ; Wed, 22 Jan 2003 16:53:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0E7979121E; Wed, 22 Jan 2003 16:56:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC5D7913C2; Wed, 22 Jan 2003 16:56:49 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B60B19121E for ; Wed, 22 Jan 2003 16:56:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 985BE5DEBE; Wed, 22 Jan 2003 16:56:48 -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 A57C75DDBC for ; Wed, 22 Jan 2003 16:56:47 -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 h0MEuk621723; Wed, 22 Jan 2003 07:56:46 -0700 Date: Wed, 22 Jan 2003 14:56:45 -0700 Subject: Re: On Killing IPv4LL on the Link Content-Type: multipart/alternative; boundary=Apple-Mail-2-540896397 Mime-Version: 1.0 (Apple Message framework v551) Cc: To: "Christian Huitema" From: Alex Karahalios In-Reply-To: Message-Id: <663C4DD7-2E54-11D7-A5CD-00039377AD70@Outersoft.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk --Apple-Mail-2-540896397 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi Christian, I am not advocating on "forced" use of LL. If a device wants to use both, it should not be precluded. Alex Karahalios. On Wednesday, January 22, 2003, at 02:38 PM, Christian Huitema wrote: > >> What is wrong with a "device" acquiring both a v4LL address and an >> address via DHCP? By "device" I mean something that has a controlled >> set of applications which know how to handle both addresses. This > makes >> the implementation much easier since the network stack or application >> does not have to deal with the LL address no longer being valid when a >> DHCP address is acquired. > > What would be wrong would be to force systems that already have a DHCP > address to also acquire a more ambiguous, scoped address. --Apple-Mail-2-540896397 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Christian, I am not advocating on "forced" use of LL. If a device wants to use both, it should not be precluded. Alex Karahalios. On Wednesday, January 22, 2003, at 02:38 PM, Christian Huitema wrote: What is wrong with a "device" acquiring both a v4LL address and an address via DHCP? By "device" I mean something that has a controlled set of applications which know how to handle both addresses. This makes the implementation much easier since the network stack or application does not have to deal with the LL address no longer being valid when a DHCP address is acquired. What would be wrong would be to force systems that already have a DHCP address to also acquire a more ambiguous, scoped address. --Apple-Mail-2-540896397-- From owner-zeroconf@merit.edu Wed Jan 22 16:53:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08822 for ; Wed, 22 Jan 2003 16:53:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5C965913C2; Wed, 22 Jan 2003 16:57:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3366A913C4; Wed, 22 Jan 2003 16:57: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 AB5B8913C2 for ; Wed, 22 Jan 2003 16:57:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9548C5DEBE; Wed, 22 Jan 2003 16:57:02 -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 2523F5DDBC for ; Wed, 22 Jan 2003 16:57:02 -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 QAA22865 for ; Wed, 22 Jan 2003 16:57:01 -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 QAA20937 for ; Wed, 22 Jan 2003 16:57:01 -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 QAA09696 for ; Wed, 22 Jan 2003 16:50:23 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 16:50:21 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122152945.2873d4d7.moore@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 01/22/2003 15:29, "Keith Moore" wrote: > As one particular example, you can't automate configuration of > nework devices if you have to arrange for each device to be hooked to a > link that is shared with a computer that is doing the configuration. > Whether that's "manual" or not, that's not an acceptable way to dictate > policy. You have to do that anyway to manage them. You have to set up what stations can manage them, who can manage them, etc. You think this stuff happens by magic some how? No. You *have* to do some manual config for managed devices. Period. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 17:01:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09123 for ; Wed, 22 Jan 2003 17:01:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 99767913C8; Wed, 22 Jan 2003 17:04:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A187913C4; Wed, 22 Jan 2003 17:04: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 B703B913C5 for ; Wed, 22 Jan 2003 17:02:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 967675DEBE; Wed, 22 Jan 2003 17:02: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 282BB5DE28 for ; Wed, 22 Jan 2003 17:02:35 -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 RAA21935 for ; Wed, 22 Jan 2003 17:02:33 -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 QAA20985 for ; Wed, 22 Jan 2003 16:57: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 QAA11074 for ; Wed, 22 Jan 2003 16:52:59 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 16:52:57 -0500 Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122153042.1a6a4364.moore@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 01/22/2003 15:30, "Keith Moore" wrote: >>> actually no. SSHing to a device that isn't configured to know which >>> authentication tokens to accept and which to reject is not >>> authentication. >> >> It's not perfect, but it beats the hell out of any DHCP server being >> able to pooch your setttings. > > from a security point-of-view, it's exactly the same level of > vulnerability. No it's not, but you are unwilling to compromise from your "Perfect or nothing" stance. Can anyone ELSE tell me if my manual idea has merit or not? Keith either won't accept anything I say, or won't accept any idea not his own. I'm not sure if I'm the first person to suggest manual configs here, but I doubt it. I simpley think that it's usable NOW, requires no new magical config protocol, and requires no changes to a spec. It simply requires the vendor to implement some manual method of turning v4LL off. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 17:01:11 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09138 for ; Wed, 22 Jan 2003 17:01:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8F49B913C5; Wed, 22 Jan 2003 17:04:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8E9D913C7; Wed, 22 Jan 2003 17:04: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 59D1C913C4 for ; Wed, 22 Jan 2003 17:02:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 39BC85DEBE; Wed, 22 Jan 2003 17:02: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 A13D55DE28 for ; Wed, 22 Jan 2003 17:02: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 RAA21904 for ; Wed, 22 Jan 2003 17:02: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 QAA20958 for ; Wed, 22 Jan 2003 16:57:02 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA11769 for ; Wed, 22 Jan 2003 16:54:34 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 16:54:33 -0500 Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122153218.7c5476f7.moore@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 01/22/2003 15:32, "Keith Moore" wrote: > it's perfectly reasonable to expect printers to work out of the box, and > implement standard spooling protocols and page description > languages, without having to install drivers. > Um...it's also perfectly reasonable to expect that if you have a printer that ships with three or four different network print protocols that you may have to configure those, or turn them on or off. As well, if your computer doesn't ship with the PPD files for that printer, then it is perfectly reasonable to expect to have to install the PPD files for that printer. This is common when a new printer is released after an OS update. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 17:04:12 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09259 for ; Wed, 22 Jan 2003 17:04:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5072191315; Wed, 22 Jan 2003 17:07:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 23AE9913C4; Wed, 22 Jan 2003 17:07: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 141CB91315 for ; Wed, 22 Jan 2003 17:07:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id ECDB45DF15; Wed, 22 Jan 2003 17:07:19 -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 827B35DEBE for ; Wed, 22 Jan 2003 17:07:19 -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 RAA28736 for ; Wed, 22 Jan 2003 17:07:18 -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 RAA21599 for ; Wed, 22 Jan 2003 17:02:02 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA13234 for ; Wed, 22 Jan 2003 16:57:15 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 16:57:13 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122153422.39536559.moore@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 01/22/2003 15:34, "Keith Moore" wrote: > and having the device save state about network configuration isn't > necessarily a good way to go anyway - the network should indicate to the > device what it's policies are. the network is in a good position to > police those policies - it can filter traffic that doesn't follow them. And who tells the network to do this...why, a *human*. Who decides network policy? Why, a *human*. Who sets up userids and passwords? Why, a Human... The network is nothing without humans telling it how to function. Your objection here is really quite bizaare. My suggestion prevents NOTHING. It allows you to turn stuff off. It allows vendors to implement that switch in a way that makes sense for that device. It allows network managers to easily set policy for that device. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 17:06:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09290 for ; Wed, 22 Jan 2003 17:06:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2CA8E913C4; Wed, 22 Jan 2003 17:09:22 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF7FE913C6; Wed, 22 Jan 2003 17:09: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 C4024913C4 for ; Wed, 22 Jan 2003 17:09:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD72E5DF15; Wed, 22 Jan 2003 17:09:20 -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 442D75DEBE for ; Wed, 22 Jan 2003 17:09: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 RAA00049 for ; Wed, 22 Jan 2003 17:09:19 -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 RAA13772 for ; Wed, 22 Jan 2003 17:09: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 RAA19970 for ; Wed, 22 Jan 2003 17:09:18 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 17:09:16 -0500 Subject: Re: On Killing IPv4LL on the Link 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 01/22/2003 15:34, "Rod" wrote: > Versions of Mac OS that support link-local will only acquire link local > addresses when configured to use DHCP and the DHCP server does not respond. > Various versions of the Mac OS will continue to send DHCP requests. If a DHCP > server does appear, the Mac will use the address from the DHCP server but it > will also continue to use the IPv4LL address. The IPv4LL address is maintained > to avoid unnecessarily killing already established connections. I have no problems with this. > The Mac OS will watch for link changed events to determine if DHCP should be > tried again or the IPv4LL address assignment should occur again. > > If DHCP is present, I don't see any reason to acquire a LL address. I do. I don't see a reason not to, unless there's a policy against it, such as it will break an application, or the network ops folks don't want it. > > On the other hand, if my machine or some other device for whatever reason > can't get an address from DHCP, or if it doesn't implement DHCP, then I'd like > it get an IPv4LL address. This assures me that I have some way of > communicating with the device. I don't want my machine to silently refuse to > acquire an address because some guy in the dorm playing a prank is sending out > some magic packet to disable IPv4LL. I don't think we need to design a special > protocol either. But, when you have DHCP present, then a prankster can keep you from getting a v4LL address, simply by having a DHCP server up and running when you connect an interface to the network. DHCP present, no v4LL address. But, since it's a bogus DHCP server, you don't really have DHCP, now do you. > > I think it makes sense to only acquire an IPv4LL address when the preferred > configuration method fails (dhcp, bootp, whatever). I think it makes sense to > allow hosts with global addresses to communicate with IPv4LLs. I think some > devices may choose not to implement DHCP and rely on IPv4LL for their > addresses. I don't believe we should explicit restrict the possibility of such > devices. My proposal does neither. It simply removes the ability of DHCP/BootP/whatever to deny a v4LL address automatically by it's presence on the network prior to a computer getting a v4LL address. > > If my desktop machine is LL aware, it should have no difficulty communicating > with a device supporting only LL addressing. Section 1.7, Communication > Between Link-Local and Routable Addresses, covers this with an example of a > laptop with a global address only communicating with a web server with a > global address to retrieve a page and printing that page to a printer with an > IPv4LL on the local link. But now, it's also impossible to easily disable LL completely. And there are many cases where you want this. My proposal allows this too. > > The original argument for requiring link local addresses all the time was to > communicate with other nodes that may have nothing but a link local address. > This was necessary because the first drafts required that traffic to a link > local address have a link local address as the source. Without a link local > address, you couldn't communicate with another node that had only a link local > address. That restriction has been lifted. I never viewed it as a restriction per se, but rather quite sensible, and a bit simpler, but it makes no real difference. > > Do you realize no changes have to be made to the DHCP spec to support this? Do you realize that if I have a rouge DHCP server, no v4LL machine that supports not acquiring an address in the previous presence of DHCP can't? I don't see this as a good thing. I want explicit human control over this. > > Do you realize the presence of a DHCP server will NOT kill IPv4LL on the link? > It will only make hosts that aquire a global address NOT acquire an IPv4 LL > address as well (since they DON'T need it!), and STILL be easily able to > communicate with IPv4LL addresses by the way of ARP, which is NOT complicated, > in fact that's how Mac OS X 10.2 does it today? You also have no control this way to say, hey, that's a bogus DHCP server. You also assume, and I don't, that there is NO reason to get a v4LL address if you use DHCP. > > You seem to think that DHCP will absolutely kill IPv4LL on the link. It will > not! Not acquiring an IPv4LL address when you already have a global one does > not mean you won't be able to communicate with devices that do have one, > either because they only work with IPv4LL or because they failed to get a > global address. If you are concerned with them getting global addresses, you > can disable this yourself most of the time (either on the device itself or on > the dhcp server) and instead they will use an IPv4LL address. How? If I'm around a rouge DHCP/bootP server, then I have to set my machine to manual config so as to avoid it. Now I have a manual address, so no v4LL address, and no way to get one either. > > I think this proposal goes in line with what you want, you just haven't taken > the time to understand it well, and seem to be confusing it with earlier > proposals of completely disabling IPv4LL with a dhcp option and whatnot. This > is not the same. Your manual config suggestion seems unwarranted since I think > if you understand these points you will see they cover the needs you have been > addressing. No they don't. The mere presence of a functional BootP or DHCP server should not be enough to kill v4LL addressing. There has to be more human control over this. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 17:08:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09338 for ; Wed, 22 Jan 2003 17:08:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BE79C913C6; Wed, 22 Jan 2003 17:11:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9751E913C7; Wed, 22 Jan 2003 17:11: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 8A404913C6 for ; Wed, 22 Jan 2003 17:11:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 71EB95DEBE; Wed, 22 Jan 2003 17:11:12 -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 06D0C5DDBC for ; Wed, 22 Jan 2003 17:11:12 -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 RAA26119 for ; Wed, 22 Jan 2003 17:11:11 -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 RAA14473 for ; Wed, 22 Jan 2003 17:11:11 -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 RAA21024 for ; Wed, 22 Jan 2003 17:11:10 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 17:11:08 -0500 Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200301222046.h0MKk5R22291@glaieul.ms.cit.alcatel.fr> 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 RAA09338 On 01/22/2003 15:46, "julien maisonneuve" wrote: > Also, it would be useful to say what we mean exactly by switching «it» > on or off. Giving a v4ll address to an interface is not the same thing > as sending packets to a v4ll address (which may take no more than a > local route). I am assuming that we talk about the former. I tend to prefer the simpler answer, mostly because it works better. Off means no v4LL period, end of sentence. That way, if I, as a network manager, choose to turn off v4LL, I have a simple way to completely disable it, but a way that I can make harder for unauthorized people to manipulate. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 17:10:03 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09361 for ; Wed, 22 Jan 2003 17:10:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1A0E2913C7; Wed, 22 Jan 2003 17:13:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DEFB1913C9; Wed, 22 Jan 2003 17:13: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 CDD1F913C7 for ; Wed, 22 Jan 2003 17:13:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id B52075DDBC; Wed, 22 Jan 2003 17:13:16 -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 483CF5DF15 for ; Wed, 22 Jan 2003 17:13:16 -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 RAA02475 for ; Wed, 22 Jan 2003 17:13: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 RAA15345 for ; Wed, 22 Jan 2003 17:13:15 -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 RAA22243 for ; Wed, 22 Jan 2003 17:13:14 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 17:13:13 -0500 Subject: Re: problems with using DHCP (was: one last attempt to illustrate my concerns) From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122155404.1c0ccd0f.moore@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 01/22/2003 15:54, "Keith Moore" wrote: > and if by "manual" you mean "cannot be automated" then it doesn't solve > the problem. That most certainly is NOT what *I* have meant at all. > >> Several people want it off by default, and I can't see the problem >> since drivers can change it to on at installation and/or runtime. > > the last thing I'd want is for a device driver to try to decide whether > it should talk to a printer using an LL address or a routable address. > the device driver should not be trying to guess network policy any more > the device it wants to talk to. nor should we presume that a device > driver is necessary. The first part I agree with. As far as the necessity of a device driver, well, that's always a *maybe*, so you can't really plan anything around it. > > (I can talk to most of the printers around here without any > kind of device driver - since they all speak lpd and postscript. > I just type "port-lpr -Plp -Sprinter-address filename". ) > Um...okay, so in the non-geek world, NO one is going to use that to print. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 17:16:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09456 for ; Wed, 22 Jan 2003 17:16:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 96BDF913CA; Wed, 22 Jan 2003 17:19:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57D09913CB; Wed, 22 Jan 2003 17: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 AB4DD913CA for ; Wed, 22 Jan 2003 17:19:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 92FB45DE28; Wed, 22 Jan 2003 17:19:24 -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 26BAE5DED0 for ; Wed, 22 Jan 2003 17:19:24 -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 RAA05770 for ; Wed, 22 Jan 2003 17:19:23 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA15659 for ; Wed, 22 Jan 2003 17:14:18 -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 RAA22775 for ; Wed, 22 Jan 2003 17:14:18 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 17:14:16 -0500 Subject: Re: On Killing IPv4LL on the Link 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 01/22/2003 16:38, "Christian Huitema" wrote: >> What is wrong with a "device" acquiring both a v4LL address and an >> address via DHCP? By "device" I mean something that has a controlled >> set of applications which know how to handle both addresses. This > makes >> the implementation much easier since the network stack or application >> does not have to deal with the LL address no longer being valid when a >> DHCP address is acquired. > > What would be wrong would be to force systems that already have a DHCP > address to also acquire a more ambiguous, scoped address. > Unless of course, you happen to need it. There needs to be both ways. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 17:16:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09469 for ; Wed, 22 Jan 2003 17:16:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5AB99913C9; Wed, 22 Jan 2003 17:19:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 193BA913CA; Wed, 22 Jan 2003 17:19: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 CC2C3913C9 for ; Wed, 22 Jan 2003 17:19:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC75D5DEAD; Wed, 22 Jan 2003 17:19:17 -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 419E75DE28 for ; Wed, 22 Jan 2003 17:19:17 -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 RAA05677 for ; Wed, 22 Jan 2003 17:19:16 -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 RAA16683 for ; Wed, 22 Jan 2003 17:19: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 RAA25416 for ; Wed, 22 Jan 2003 17:19:15 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 17:19:13 -0500 Subject: Re: When to assign IPv4LL From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <42650098-2E53-11D7-8BF8-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 01/22/2003 16:48, "Joshua Graessley" wrote: > My opinion on this is that networks don't need a way to say this. I > don't even really understand what it means for a network to say > anything. A network is a collection of devices connected together, > there is no central authority. Um...that last sentence is SO incorrect in SO many cases. You can't assume all networks are ad hoc. All the ones I've ever done work on outside of my house have a *very* central authority. > > I do believe that IPv4LL address can cause some issues and a global > address is preferable over an IPv4LL. I think that there is no reason > to assign a link local address unless a device is unable to acquire a > global address through any configuration method. As an example, if a > client is configured to use DHCP and it receives no DHCP response, I > believe it makes sense to try and assign an IPv4LL address. But you cannot assume that there is NO need for both addresses, or that there never WILL be a need. The better option is to make both possible. > >> 2. Having autoconfiguring devices try DHCP first will not interoperate >> well with certain DSL modems. Maybe that's not this group's problem, >> but we should at least be aware of it. > > I think of IPv4LL as another configuration method, similar to DHCP, > though you end up with a scoped address which does have limitations. I > think it makes sense for vendors to offer an option to use only IPv4LL > in addition to the other configuration methods they support. As stated > above, I believe that if a configuration method fails to acquire an > address, a device should try to self assign an IPv4LL. What do you do about rouge DHCP servers? > >> Partially because of #2, it might be that an explicit indication from >> DHCP(or some other protocol) that means "don't use LL" would be better >> than interpreting a DHCP response to an address request as an implicit >> indication that LL should not be used. Or not. I see this as a >> question of which is worse: > > I don't see what adding any options to DHCP buys us. If a device gets a > DHCP response, then presumably it's getting a global address so it > doesn't need an address. If a device doesn't receive a DHCP response, > then the device should self assign an IPv4LL. If the device is not > configured to use DHCP then DHCP options won't matter. In the scenario > you outlined before, it sounds like the only good solution is for your > printer to be assigned to not bother with DHCP and just self assign an > IPv4LL address. Because not all DHCP servers are the ones you are supposed to use. > >> Offhand, I tend to think that the second case is worse. The managed >> network presumably has someone with expertise and perhaps diagnostic >> tools who can turn on the "disable LL" signal if/when it causes >> problems, whereas the home network user has neither of these. So it's >> better to break the managed network, *provided* there's a way in the >> standard for the managed network to fix the problem. > > I still don't see a case for the "disable LL" signal. If you don't want > IPv4LL addresses on your network, configure devices to use DHCP and > don't let your DHCP server go down. Um...I like the idea of being able to disable v4LL totally. So do a lot of people in the right setup. I don't like the mere presence of a functional DHCP server affecting v4LL addressing. > There is no protocol on the wire that prevents people from manually > assigning addresses. Why should there be one that prevents the computer > from self assigning an IPv4LL address? Yes, IPv4LL addresses are > arguably less functional that a global address, but if a global address > is not available, they're a lot better than nothing. I agree, but I also agree with keith that DHCP alone should not be enough to stop v4LL address acquistion. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 18:02:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10715 for ; Wed, 22 Jan 2003 18:02:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BA798913CB; Wed, 22 Jan 2003 18:03:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 811B1913CC; Wed, 22 Jan 2003 18:03:50 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 849B9913CB for ; Wed, 22 Jan 2003 18:03:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 608455DEFC; Wed, 22 Jan 2003 18:03:19 -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 32EE75DDBC for ; Wed, 22 Jan 2003 18:03:19 -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 DEECD598D6; Wed, 22 Jan 2003 23:03:22 +0000 (GMT) Message-ID: <013901c2c26a$744c3af0$131010ac@aldebaran> From: "Philip Nye" To: "John C. Welch" , "Zeroconf" References: Subject: Re: OT (When to assign IPv4LL) Date: Wed, 22 Jan 2003 23:03:18 -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 > What do you do about rouge DHCP servers? I always paint mine bleu. From owner-zeroconf@merit.edu Wed Jan 22 18:05:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10763 for ; Wed, 22 Jan 2003 18:05:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1FA20913D3; Wed, 22 Jan 2003 18:07:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3528913D2; Wed, 22 Jan 2003 18:07:49 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74B20913CD for ; Wed, 22 Jan 2003 18:07:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 578DA5DF15; Wed, 22 Jan 2003 18:07:43 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 331005DEFC for ; Wed, 22 Jan 2003 18:07:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 00A9B13FDE; Wed, 22 Jan 2003 18:07:43 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 27110-10; Wed, 22 Jan 2003 18:07:42 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 410D113FE5; Wed, 22 Jan 2003 18:07:42 -0500 (EST) Date: Wed, 22 Jan 2003 18:07:41 -0500 From: Keith Moore To: Joshua Graessley Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: When to assign IPv4LL Message-Id: <20030122180741.0e089e33.moore@cs.utk.edu> In-Reply-To: <42650098-2E53-11D7-8BF8-000393760260@apple.com> References: <20030122145705.554eaf0a.moore@cs.utk.edu> <42650098-2E53-11D7-8BF8-000393760260@apple.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: f00c9a8411f45b656eee1d404a5af487196e01f5 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > 1. Networks need a way to say to devices "don't use LL" (because LL > > causes problems) and optionally "use this other address" (so that > > autoconfiguring devices will continue to function) > > My opinion on this is that networks don't need a way to say this. I > don't even really understand what it means for a network to say > anything. A network is a collection of devices connected together, > there is no central authority. Networks are resources in their own right. They cost money and whoever pays for them wants some say in how they are run. They are sometimes seen as security threats. They fail. They require configuration and management. Many of them have usage policies, and means of enforcing those policies. Now it is also the case that there are networks for which many of the above characteristics do not apply. Such networks may become more prevalent in the future. But we expect the same devices to play well in both kind of networks. > > 2. Having autoconfiguring devices try DHCP first will not > > interoperate well with certain DSL modems. Maybe that's not this > > group's problem, but we should at least be aware of it. > > I think of IPv4LL as another configuration method, similar to DHCP, > though you end up with a scoped address which does have limitations. I > think it makes sense for vendors to offer an option to use only IPv4LL > in addition to the other configuration methods they support. As stated > above, I believe that if a configuration method fails to acquire an > address, a device should try to self assign an IPv4LL. Even if this causes networks using DSL modems to break? Are you unconcerned about the interoperability issues with these networks? > > Partially because of #2, it might be that an explicit indication > > from DHCP(or some other protocol) that means "don't use LL" would be > > better than interpreting a DHCP response to an address request as an > > implicit indication that LL should not be used. Or not. I see this > > as a question of which is worse: > > I don't see what adding any options to DHCP buys us. Again, it doesn't have to be DHCP. And actually if the autoconfiguring printer asks for an address from the DSL modem before the user's computer, it's going to cause the user's computer to fail to connect to the Internet whether or not the autoconfiguring printer looks at a specific DHCP option or just uses the fact that it was assigned an address. So maybe we just don't worry about the DSL modems. Or maybe we use something besides DHCP. > If a device gets > a DHCP response, then presumably it's getting a global address so it > doesn't need an address. If a device doesn't receive a DHCP response, > then the device should self assign an IPv4LL. If the device is not > configured to use DHCP then DHCP options won't matter. In the scenario > you outlined before, it sounds like the only good solution is for your > printer to be assigned to not bother with DHCP and just self assign an > IPv4LL address. But how does the printer know to not bother with DHCP? It's supposed to be autoconfiguring. It doesn't necessarily have a manual override. Even if it does, the user doesn't know that it's needed, or how to use it when it is needed. > Even in a managed environment, it may be desirable or acceptable for a > device to self assign an IPv4LL initially. If you get a printer out of > the box and it defaults to using IPv4LL (or DHCP and falls back to > IPv4LL), it might be nice to have that printer just show up so you can > connect to and configure it the way you'd like. Well if you have to configure the printer in order to make it work in common cases, it doesn't seem like "zero configuration" any more. > There is no protocol on the wire that prevents people from manually > assigning addresses. Why should there be one that prevents the > computer from self assigning an IPv4LL address? Neither is there any protocol that prevents hosts from choosing an address at random from the 2**32 that are available. But we would not consider this a desirable behavior. We need to stop thinking of this as "preventing" a host from doing something that isn't desirable - we can't stop hosts and implementors from doing bad things anyway. What we need to do is define how a host interacts with a network (where "network" can be dumb or smart, passive or active, ad hoc or managed, isolated or connected) in order for that host to understand how best to interact on that network. We've been discussing whether it is wise for a host to assume that being assigned a DHCP address is a good indication that it should not, by default, configure a v4LL address. I identified an apparently common case where this will cause a failure. Perhaps that is an acceptable failure, though I am doubtful. But if it's not acceptable then we should perhaps consider other mechanisms for allowing a network to tell a host to use some other kind of address besides v4LL - especially given the occasional complaints that expecting low-cost fixed-function devices to implement DHCP is too onerous. From owner-zeroconf@merit.edu Wed Jan 22 18:11:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10825 for ; Wed, 22 Jan 2003 18:11:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C9610913CD; Wed, 22 Jan 2003 18:14:17 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91F54913CE; Wed, 22 Jan 2003 18:14: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 62623913CD for ; Wed, 22 Jan 2003 18:14:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4737F5DF28; Wed, 22 Jan 2003 18:14:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 1CC905DF2E for ; Wed, 22 Jan 2003 18:14:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id E19AB1401A; Wed, 22 Jan 2003 18:14:15 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 28114-09; Wed, 22 Jan 2003 18:14:15 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 4B92C13FE5; Wed, 22 Jan 2003 18:14:15 -0500 (EST) Date: Wed, 22 Jan 2003 18:14:15 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122181415.7b3c2212.moore@cs.utk.edu> In-Reply-To: References: <20030122152945.2873d4d7.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 4602de5aa0f82abbd25c8c8c5125843a62364606 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > As one particular example, you can't automate configuration of > > nework devices if you have to arrange for each device to be hooked > > to a link that is shared with a computer that is doing the > > configuration. Whether that's "manual" or not, that's not an > > acceptable way to dictate policy. > > You have to do that anyway to manage them. You have to set up what > stations can manage them, who can manage them, etc. You think this > stuff happens by magic some how? No. You *have* to do some manual > config for managed devices. Period. To some degree, it depends on what the device does. If the device is just a temperature sensor, does it need access control? Maybe, maybe not. Perhaps more to the point, if a user plugs an IP printer into a hub, the user might want to specify who can print to that printer rather than leaving it wide open for anyone who wants to consume the user's paper. But should the network manager be required to explicitly specify policy to that device? Just because the user wants to be able to specify some things does not mean that the user should have to specify things that the device could learn from the network. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 18:18:44 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10969 for ; Wed, 22 Jan 2003 18:18:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 46FBE913CF; Wed, 22 Jan 2003 18:21:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 07705913D0; Wed, 22 Jan 2003 18:21: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 993FF913CF for ; Wed, 22 Jan 2003 18:21:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 87F545DF28; Wed, 22 Jan 2003 18:21:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 6C47B5DF1E for ; Wed, 22 Jan 2003 18:21:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 417451401A; Wed, 22 Jan 2003 18:21:52 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 29519-02; Wed, 22 Jan 2003 18:21:51 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 9ED6613FDE; Wed, 22 Jan 2003 18:21:51 -0500 (EST) Date: Wed, 22 Jan 2003 18:21:51 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122182151.126907ca.moore@cs.utk.edu> In-Reply-To: References: <20030122153422.39536559.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: c2d4cd94792102054f20d837ec24a40628761303 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > And who tells the network to do this...why, a *human*. Who decides > network policy? Why, a *human*. Who sets up userids and passwords? > Why, a Human... completely different scale. it's one thing to set policy for plug-in devices for large chunks of a network; quite another to have to separately/individually configure each device. > The network is nothing without humans telling it how to function. Your > objection here is really quite bizaare. My suggestion prevents > NOTHING. It allows you to turn stuff off. your situation make it so cumbersome to turn off LL that it's not a feasible workaround for the problems that LL causes. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 18:21:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11013 for ; Wed, 22 Jan 2003 18:21:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C49DD913D0; Wed, 22 Jan 2003 18:24:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 935F6913D1; Wed, 22 Jan 2003 18:24: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 76027913D0 for ; Wed, 22 Jan 2003 18:24:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5DEE75DEFC; Wed, 22 Jan 2003 18:24:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 45A9B5DE6E for ; Wed, 22 Jan 2003 18:24:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 21DBD1401A; Wed, 22 Jan 2003 18:24:39 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 29280-09; Wed, 22 Jan 2003 18:24:38 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 81A6214067; Wed, 22 Jan 2003 18:24:38 -0500 (EST) Date: Wed, 22 Jan 2003 18:24:38 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: On Killing IPv4LL on the Link Message-Id: <20030122182438.346ad0b6.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: f0eaad96ee22d7fda91d8a510b9f7c667eef6ab4 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > What would be wrong would be to force systems that already have a > > DHCP address to also acquire a more ambiguous, scoped address. > > > > Unless of course, you happen to need it. but you don't. there is no situation where you need both v4LL and a routable address on the same interface. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 18:31:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11224 for ; Wed, 22 Jan 2003 18:31:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A7D7D91318; Wed, 22 Jan 2003 18:34:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60DE6913D1; Wed, 22 Jan 2003 18:34: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 5357C91318 for ; Wed, 22 Jan 2003 18:34:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3BDDE5DE70; Wed, 22 Jan 2003 18:34: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 C504C5DE6E for ; Wed, 22 Jan 2003 18:34: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 SAA07811 for ; Wed, 22 Jan 2003 18:34:37 -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 SAA02788 for ; Wed, 22 Jan 2003 18:34:36 -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 SAA24004 for ; Wed, 22 Jan 2003 18:34:36 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 18:34:34 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122181415.7b3c2212.moore@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 01/22/2003 18:14, "Keith Moore" wrote: >> You have to do that anyway to manage them. You have to set up what >> stations can manage them, who can manage them, etc. You think this >> stuff happens by magic some how? No. You *have* to do some manual >> config for managed devices. Period. > > To some degree, it depends on what the device does. If the device is > just a temperature sensor, does it need access control? Maybe, maybe > not. Maybe...but then again, if you have that much of an IP stack, then you have a way to get data *out* of the device. If you can get data out, then you have a way to get data in. > > Perhaps more to the point, if a user plugs an IP printer into a hub, the > user might want to specify who can print to that printer rather than > leaving it wide open for anyone who wants to consume the user's paper. > But should the network manager be required to explicitly specify policy > to that device? By default, printers are open to everyone. If you want to change that, it's manual. By default, under my proposal, you have v4LL addressing. You normally, (for every printer I've ever configured, and that list is very long), it ships with a default address, or a control panel on the printer, or both. If it uses v4LL for the default, and you DON'T want that, or you want additional config modes, then you use that to access the printer, (I guarantee when you take the printer out of the box, and set it up, you will be in the same room with it.) and make any other changes you'll need to make, including either setting policy, or pointing it to a policy server, etc. > > Just because the user wants to be able to specify some things does not > mean that the user should have to specify things that the device could > learn from the network. I'm not requiring that by default. ALL I am saying is that to *disable* v4LL, you have to do that manually, not simply because there is a DHCP server on the network. I'm not killing anything by default. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 18:43:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11395 for ; Wed, 22 Jan 2003 18:43:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 68D0E913D1; Wed, 22 Jan 2003 18:46:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA7E9913D2; Wed, 22 Jan 2003 18:46: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 0F80A913D1 for ; Wed, 22 Jan 2003 18:45:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6EE555DF15; Wed, 22 Jan 2003 18:45:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 1C9495DDC3 for ; Wed, 22 Jan 2003 18:45:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id D004D14067; Wed, 22 Jan 2003 18:45:47 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 32753-01; Wed, 22 Jan 2003 18:45:47 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 34ECB1401D; Wed, 22 Jan 2003 18:45:47 -0500 (EST) Date: Wed, 22 Jan 2003 18:45:46 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122184546.7e616b06.moore@cs.utk.edu> In-Reply-To: References: <20030122181415.7b3c2212.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 32d17b385bfc2dda5308d9521ac7d88559e69fa1 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > To some degree, it depends on what the device does. If the device > > is just a temperature sensor, does it need access control? Maybe, > > maybe not. > > Maybe...but then again, if you have that much of an IP stack, then you > have a way to get data *out* of the device. If you can get data out, > then you have a way to get data in. you don't necessarily have stable storage. > > Perhaps more to the point, if a user plugs an IP printer into a hub, > > the user might want to specify who can print to that printer rather > > than leaving it wide open for anyone who wants to consume the user's > > paper. But should the network manager be required to explicitly > > specify policy to that device? > > By default, under my proposal, you have v4LL addressing. > You normally, (for every printer I've ever configured, and that list > is very long), it ships with a default address, or a control panel on > the printer, or both. If it uses v4LL for the default, and you DON'T > want that, or you want additional config modes, then you use that to > access the printer, requiring anyone to explicitly configure every device is not an acceptable way to disable LL. I've already explained why this is the case. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 18:45:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11418 for ; Wed, 22 Jan 2003 18:45:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4F5B0913D5; Wed, 22 Jan 2003 18:46:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E48D913D4; Wed, 22 Jan 2003 18:46: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 B1B51913D2 for ; Wed, 22 Jan 2003 18:46:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8ADCA5DEA6; Wed, 22 Jan 2003 18:46:36 -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 18B665DDC3 for ; Wed, 22 Jan 2003 18:46: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 SAA13570 for ; Wed, 22 Jan 2003 18:46: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 SAA03873 for ; Wed, 22 Jan 2003 18:46:35 -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 SAA27863 for ; Wed, 22 Jan 2003 18:46:34 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 18:46:32 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122182151.126907ca.moore@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 01/22/2003 18:21, "Keith Moore" wrote: >> And who tells the network to do this...why, a *human*. Who decides >> network policy? Why, a *human*. Who sets up userids and passwords? >> Why, a Human... > > completely different scale. it's one thing to set policy for plug-in > devices for large chunks of a network; quite another to have to > separately/individually configure each device. > You have to do it anyway...have you actually spent large amounts of time as a network admin? To get to the automation, you have to spend some manual time >> The network is nothing without humans telling it how to function. Your >> objection here is really quite bizaare. My suggestion prevents >> NOTHING. It allows you to turn stuff off. > > your situation make it so cumbersome to turn off LL that it's not a > feasible workaround for the problems that LL causes. Okay...this is like So cumbersome...NOT Here's a script that will, when used with a decent network admin tool on a Mac, kill en0 on every mac that tool has control over, and you have an admin password on. Just replace the password in quotes with a valid one. (this can be made more secure in a number of ways, but here's the minimum effort) Count the lines boys and girls: property killen0 : "/sbin/ifconfig en0 down" do shell script killen0 password "someadminpassword" with administrator privileges Ta-daa. Stick a valid password in there, make the script an application so the code is no longer plain text, and *two* lines, (if you use shell directly, you don't need applescript), and it's only two because I'm a property freak, it could be done in ONE line. It's a lot of things, but to call it cumbersome 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 Wed Jan 22 18:46:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11438 for ; Wed, 22 Jan 2003 18:46:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 40A27913D6; Wed, 22 Jan 2003 18:49:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CEBB0913D4; Wed, 22 Jan 2003 18:49:07 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 57299913D8 for ; Wed, 22 Jan 2003 18:49:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id E31F65DF15; Wed, 22 Jan 2003 18:49:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtpout.mac.com (A17-250-248-89.apple.com [17.250.248.89]) by segue.merit.edu (Postfix) with ESMTP id 786AB5DEA6 for ; Wed, 22 Jan 2003 18:49:00 -0500 (EST) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h0MNmxr4025124 for ; Wed, 22 Jan 2003 15:49:00 -0800 (PST) Received: from mac.com ([200.67.17.194]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id H953HM00.S4V for ; Wed, 22 Jan 2003 15:48:58 -0800 Date: Wed, 22 Jan 2003 17:48:59 -0600 Subject: Re: On Killing IPv4LL on the Link Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Rod To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <141F994F-2E64-11D7-B0D2-003065A87BBE@mac.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, January 22, 2003, at 04:09 PM, John C. Welch wrote: >> If DHCP is present, I don't see any reason to acquire a LL address. > > I do. I don't see a reason not to, unless there's a policy against it, > such > as it will break an application, or the network ops folks don't want > it. Some people here have mentioned reasons not to, so the aforementioned method was suggested to apeace them. Can you elaborate on reasons to acquire an IPv4LL address when you already have a valid global one? >> On the other hand, if my machine or some other device for whatever >> reason >> can't get an address from DHCP, or if it doesn't implement DHCP, then >> I'd like >> it get an IPv4LL address. This assures me that I have some way of >> communicating with the device. I don't want my machine to silently >> refuse to >> acquire an address because some guy in the dorm playing a prank is >> sending out >> some magic packet to disable IPv4LL. I don't think we need to design >> a special >> protocol either. > > But, when you have DHCP present, then a prankster can keep you from > getting > a v4LL address, simply by having a DHCP server up and running when you > connect an interface to the network. DHCP present, no v4LL address. > But, > since it's a bogus DHCP server, you don't really have DHCP, now do you. But you can still communicate with devices that have IPv4LL addresses via ARP, so what seems to be the problem? See below. >> I think it makes sense to only acquire an IPv4LL address when the >> preferred >> configuration method fails (dhcp, bootp, whatever). I think it makes >> sense to >> allow hosts with global addresses to communicate with IPv4LLs. I >> think some >> devices may choose not to implement DHCP and rely on IPv4LL for their >> addresses. I don't believe we should explicit restrict the >> possibility of such >> devices. > > My proposal does neither. It simply removes the ability of > DHCP/BootP/whatever to deny a v4LL address automatically by it's > presence on > the network prior to a computer getting a v4LL address. It's not denying anything. The device will just rather get a global address because it can use that to communicate with anyone, LL or not. The only problem you have pointed out with this is the existence of bogus dhcp servers. >> If my desktop machine is LL aware, it should have no difficulty >> communicating >> with a device supporting only LL addressing. Section 1.7, >> Communication >> Between Link-Local and Routable Addresses, covers this with an >> example of a >> laptop with a global address only communicating with a web server >> with a >> global address to retrieve a page and printing that page to a printer >> with an >> IPv4LL on the local link. > > But now, it's also impossible to easily disable LL completely. And > there are > many cases where you want this. My proposal allows this too. And you had been arguing fiercely all this time against a way to disable LL completely. Now that they give it to you you want the opposite? >> The original argument for requiring link local addresses all the time >> was to >> communicate with other nodes that may have nothing but a link local >> address. >> This was necessary because the first drafts required that traffic to >> a link >> local address have a link local address as the source. Without a link >> local >> address, you couldn't communicate with another node that had only a >> link local >> address. That restriction has been lifted. > > I never viewed it as a restriction per se, but rather quite sensible, > and a > bit simpler, but it makes no real difference. It makes a difference because devices don't need an IPv4LL address to communicate with other devices that use IPv4LL addresses exclusively or non-exclusively. >> Do you realize no changes have to be made to the DHCP spec to support >> this? > > Do you realize that if I have a rouge DHCP server, no v4LL machine that > supports not acquiring an address in the previous presence of DHCP > can't? But it can still communicate with IPv4LL devices. >> Do you realize the presence of a DHCP server will NOT kill IPv4LL on >> the link? >> It will only make hosts that aquire a global address NOT acquire an >> IPv4 LL >> address as well (since they DON'T need it!), and STILL be easily able >> to >> communicate with IPv4LL addresses by the way of ARP, which is NOT >> complicated, >> in fact that's how Mac OS X 10.2 does it today? > > You also have no control this way to say, hey, that's a bogus DHCP > server. > You also assume, and I don't, that there is NO reason to get a v4LL > address > if you use DHCP. Can you please elaborate on reasons why both addresses would be needed. >> You seem to think that DHCP will absolutely kill IPv4LL on the link. >> It will >> not! Not acquiring an IPv4LL address when you already have a global >> one does >> not mean you won't be able to communicate with devices that do have >> one, >> either because they only work with IPv4LL or because they failed to >> get a >> global address. If you are concerned with them getting global >> addresses, you >> can disable this yourself most of the time (either on the device >> itself or on >> the dhcp server) and instead they will use an IPv4LL address. > > How? If I'm around a rouge DHCP/bootP server, then I have to set my > machine > to manual config so as to avoid it. Now I have a manual address, so no > v4LL > address, and no way to get one either. Although I agree with the proposal of not acquiring an IPv4LL address when a global address has already been acquired, I don't think devices that implement LL should be forced to implement DHCP. In the same way, I don't think the only way of acquiring an IPv4LL address should be to configure the device to use DHCP and then failing to acquire an address. >> >> I think this proposal goes in line with what you want, you just >> haven't taken >> the time to understand it well, and seem to be confusing it with >> earlier >> proposals of completely disabling IPv4LL with a dhcp option and >> whatnot. This >> is not the same. Your manual config suggestion seems unwarranted >> since I think >> if you understand these points you will see they cover the needs you >> have been >> addressing. > > No they don't. The mere presence of a functional BootP or DHCP server > should > not be enough to kill v4LL addressing. There has to be more human > control > over this. It's not killing v4LL addressing. The host is just using the address it finds more convenient to use. From owner-zeroconf@merit.edu Wed Jan 22 18:46:15 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11452 for ; Wed, 22 Jan 2003 18:46:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 401EA913D2; Wed, 22 Jan 2003 18:49:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E7C85913D4; Wed, 22 Jan 2003 18:49: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 3D426913D2 for ; Wed, 22 Jan 2003 18:47:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2114D5DF15; Wed, 22 Jan 2003 18:47:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id A429D5DEA6 for ; Wed, 22 Jan 2003 18:47:06 -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 SAA19251 for ; Wed, 22 Jan 2003 18:47:06 -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 SAA27458 for ; Wed, 22 Jan 2003 18:47:06 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id SAA28061 for ; Wed, 22 Jan 2003 18:47:05 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 18:47:03 -0500 Subject: Re: On Killing IPv4LL on the Link From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122182438.346ad0b6.moore@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 01/22/2003 18:24, "Keith Moore" wrote: >> Unless of course, you happen to need it. > > but you don't. there is no situation where you need both v4LL and a > routable address on the same interface. You can't guarantee that unless you got the clairvoyance upgrade. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 19:00:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11702 for ; Wed, 22 Jan 2003 19:00:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 31DC8913D4; Wed, 22 Jan 2003 19:03:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2BA491229; Wed, 22 Jan 2003 19:03: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 BC046913D4 for ; Wed, 22 Jan 2003 19:02:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D77F5DEBE; Wed, 22 Jan 2003 19:02:19 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 84C925DE4A for ; Wed, 22 Jan 2003 19:02:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 525611401D; Wed, 22 Jan 2003 19:02:19 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 01535-08; Wed, 22 Jan 2003 19:02:18 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 8FF5314069; Wed, 22 Jan 2003 19:02:18 -0500 (EST) Date: Wed, 22 Jan 2003 19:02:18 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122190218.3faf0466.moore@cs.utk.edu> In-Reply-To: References: <20030122182151.126907ca.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: aa1bb931d4ef2e12caaeabe9fad1d37157b72a22 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > completely different scale. it's one thing to set policy for > > plug-in devices for large chunks of a network; quite another to have > > to separately/individually configure each device. > > > > You have to do it anyway... uh, no. I assure you that our network admins don't do configuration of individual devices. > > your situation make it so cumbersome to turn off LL that it's not a > > feasible workaround for the problems that LL causes. > > > > Okay...this is like So cumbersome...NOT > > Here's a script that will, wonderful. now make it work for every device on the network, no matter what kind of device it is, so that the network admin can set policy. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Wed Jan 22 19:03:08 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11733 for ; Wed, 22 Jan 2003 19:03:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F41D391229; Wed, 22 Jan 2003 19:06:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C0C48913D7; Wed, 22 Jan 2003 19:06: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 6317491229 for ; Wed, 22 Jan 2003 19:06:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 400CD5DEED; Wed, 22 Jan 2003 19:06: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 C8F5F5DEEA for ; Wed, 22 Jan 2003 19:06: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 TAA26999 for ; Wed, 22 Jan 2003 19:06: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 TAA28797 for ; Wed, 22 Jan 2003 19:06: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 TAA03996 for ; Wed, 22 Jan 2003 19:06:18 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 19:06:17 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122184546.7e616b06.moore@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 01/22/2003 18:45, "Keith Moore" wrote: >> Maybe...but then again, if you have that much of an IP stack, then you >> have a way to get data *out* of the device. If you can get data out, >> then you have a way to get data in. > > you don't necessarily have stable storage. You have enough to tell it to use DHCP, you have enough for the IP stack. >> By default, under my proposal, you have v4LL addressing. >> You normally, (for every printer I've ever configured, and that list >> is very long), it ships with a default address, or a control panel on >> the printer, or both. If it uses v4LL for the default, and you DON'T >> want that, or you want additional config modes, then you use that to >> access the printer, > > requiring anyone to explicitly configure every device is not an > acceptable way to disable LL. I've already explained why this is the > case. You have, but from the POV of someone with no experience in actually running a network of any real size. I *do* have that experience, and what I have suggested would cause no admin more than five seconds of work per zeroconf device...if that long. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 19:36:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12447 for ; Wed, 22 Jan 2003 19:36:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CE98691277; Wed, 22 Jan 2003 19:39:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C38691319; Wed, 22 Jan 2003 19:39:21 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8612E91277 for ; Wed, 22 Jan 2003 19:39:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 636125E052; Wed, 22 Jan 2003 19:39:20 -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 EB1165E02E for ; Wed, 22 Jan 2003 19:39:19 -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 TAA08532 for ; Wed, 22 Jan 2003 19:39:19 -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 TAA01022 for ; Wed, 22 Jan 2003 19:36:13 -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 TAA13899 for ; Wed, 22 Jan 2003 19:36:12 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 19:36:09 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122190218.3faf0466.moore@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 01/22/2003 19:02, "Keith Moore" wrote: >> You have to do it anyway... > > uh, no. I assure you that our network admins don't do configuration of > individual devices. > Um...if you think for three seconds that I am going to believe that a Windows PC on your network goes directly from factory to User Desktop with absolutely no human intervention on it other than to unpack it, I'm going to tell you that I think you don't know what you're talking about, and I want proof. > >>> your situation make it so cumbersome to turn off LL that it's not a >>> feasible workaround for the problems that LL causes. >> >> >> >> Okay...this is like So cumbersome...NOT >> >> Here's a script that will, > > wonderful. now make it work for every device on the network, no > matter what kind of device it is, so that the network admin can set > policy. LOL...what's your management tool that you use for every single device on a network no matter what kind of device, platform or operating system? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 19:37:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12507 for ; Wed, 22 Jan 2003 19:37:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3103691319; Wed, 22 Jan 2003 19:40:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8209913D7; Wed, 22 Jan 2003 19:40: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 B817491319 for ; Wed, 22 Jan 2003 19:40:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id A6A6F5E060; Wed, 22 Jan 2003 19:40:21 -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 8B6625DEED for ; Wed, 22 Jan 2003 19:40:21 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h0N0eLHI019568; Wed, 22 Jan 2003 17:40:21 -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 RAA07072; Wed, 22 Jan 2003 17:40:17 -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 h0N0eDEE016588; Thu, 23 Jan 2003 11:40:15 +1100 (EST) Message-ID: <3E2F39EC.90105@motorola.com> Date: Thu, 23 Jan 2003 11:40:12 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: WG decision: when to configure LL addrs References: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> In-Reply-To: <200301221450.h0MEo2l11224@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: > a) yes, I think this is what the document should say (maybe with > some small tweaks, which then need to be explained) > Mostly, yes. Some tweaks. Some of it seems to re-write/re-word text that is already in the draft. >>- when should an IPv4LL address be configured by a host? > >> suggest: if the host is explicitly configured to do so, OR >> if the host has attempted and failed to acquire a routable address via DHCP > The word "routable" is not relevant and should be dropped. A host may also choose not to use DHCP and use a LL address instead, but perhaps that is adequately covered by "explicitly configured". >>- when should an IPv4LL address be used by a host as a source address? > >> suggest: when the only addresses available to the host are IPv4LL addresses, OR >> when the application has explicitly specified the source address to use, OR >> when the application has explicitly specified the interface to use and the IPv4LL address >> is the only address associated with that interface. > I don't agree with the "only address associated with the interface" part. If you *have* an IPv4-LL address it should be used when connecting to IPv4-LL destinations. I'm happy with Section 2.6, "Source Address Selection" as it is. >>- when should a host honor an attempt to connect to an IPv4LL address that was once >> configured by that host? > >> suggest: anytime the address is still valid (e.g. there have been no conflicting claims) >> and there is a process listening for connections either specifically to that address or >> for incoming connections at any of the host's addresses. > This seems needlessly verbose. Stating that connections should only succeed to the current valid address seems enough. There is existing text in the draft which suggest that existing connections to LL addresses should continue to work when a DHCP server becomes available (Section 1.5, Supporting Multiple Addresses per Interface). I think that is reasonable and should remain. >>- when should an application attempt to connect to a IPv4LL address? > >> suggest: only when the address is literally specified, or if there are no other routable >> addresses for the destination host known to the application. > Literally specified? By whom? I would be happier with: An application with a choice between connecting to LL address and non-LL address SHOULD prefer the non-LL address. >>- when should an application send an IPv4LL address in a referral to another host? > >> suggest: only when there are no routable addresses for the destination host known to the >> application. even then, care needs to be taken that a host reached at a particular >> IPv4LL address is really the one intended - since IPv4LL addresses can be reassigned >> without notice and/or reused on different network segments. Most of these issues seem to be covered already. Section 7.2, Limited Forwarding of Locators Section 7.3, Address Ambiguity Section 2.9, Higher-Layer Protocol Considerations A host always need to take care the host reached at a particular address is really the one intended. The IPv4-LL case is a difference in degree only. The "correctness" or "stability" of the name to address mapping seems much more important to me and that is out of scope of this document. - aidan From owner-zeroconf@merit.edu Wed Jan 22 19:50:33 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12815 for ; Wed, 22 Jan 2003 19:50:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 185C6913D8; Wed, 22 Jan 2003 19:53:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1BAE913D9; Wed, 22 Jan 2003 19:53: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 CE277913D8 for ; Wed, 22 Jan 2003 19:53:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id BB8625DEF8; Wed, 22 Jan 2003 19:53:42 -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 619375DDC1 for ; Wed, 22 Jan 2003 19:53:42 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h0N0reVH014834 for ; Wed, 22 Jan 2003 17:53:41 -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 RAA17291 for ; Wed, 22 Jan 2003 17:52: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 h0N0rXEE017364; Thu, 23 Jan 2003 11:53:35 +1100 (EST) Message-ID: <3E2F3D0D.4000706@motorola.com> Date: Thu, 23 Jan 2003 11:53:33 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Karahalios Cc: Christian Huitema , zeroconf@merit.edu Subject: Re: On Killing IPv4LL on the Link References: <663C4DD7-2E54-11D7-A5CD-00039377AD70@Outersoft.com> In-Reply-To: <663C4DD7-2E54-11D7-A5CD-00039377AD70@Outersoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Alex Karahalios wrote: > I am not advocating on "forced" use of LL. If a device wants to use > both, it should not be precluded. > I take this to be a "manual configuration" case. Possibly "manually pre-configured". If you want to make a device that has been explicitly configured to do this, and you can make it work because your device has a suitably constrained set of applications, go for it. - aidan From owner-zeroconf@merit.edu Wed Jan 22 20:37:32 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13450 for ; Wed, 22 Jan 2003 20:37:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B372B913DF; Wed, 22 Jan 2003 20:40:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 864C4913E0; Wed, 22 Jan 2003 20:40: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 1A418913DF for ; Wed, 22 Jan 2003 20:40:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id F05435DF15; Wed, 22 Jan 2003 20:40:45 -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 0AA995DEFC for ; Wed, 22 Jan 2003 20:40:45 -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 h0N1eejf000471; Thu, 23 Jan 2003 11:40:41 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id h0N1ecQ06069; Thu, 23 Jan 2003 11:40:38 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Thu, 23 Jan 2003 11:40:38 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: WG decision: when to configure LL addrs In-Reply-To: <200301221450.h0MEo2l11224@cichlid.adsl.duke.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.4, 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 Wed, 22 Jan 2003, Thomas Narten wrote: >1) Should the ID recommend that LL addresses only be configured as per > below. Generally, yes. As others have pointed out, there should probably be some tweaks to the use of the term `routable addresses', and the `alternative' from the first section is not required. Most of the subsequent comments from other people seem OK, but I'm not convinced by Robert Elz's argument for disabling IPv4LL when a DHCP server exists but does not assign an address. (The point about picking a source address based on the interface the packet will be sent on is fine, though) Ian From owner-zeroconf@merit.edu Wed Jan 22 20:40:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13476 for ; Wed, 22 Jan 2003 20:40:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E8F5C913E0; Wed, 22 Jan 2003 20:43:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5A83913E1; Wed, 22 Jan 2003 20:43: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 8C22D913E0 for ; Wed, 22 Jan 2003 20:43:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 69E435DF15; Wed, 22 Jan 2003 20:43:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by segue.merit.edu (Postfix) with ESMTP id ED4195DEFC for ; Wed, 22 Jan 2003 20:43:30 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id h0N1iEbr015986 for ; Wed, 22 Jan 2003 20:44:15 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-85.cisco.com [10.82.224.85]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA05155 for ; Wed, 22 Jan 2003 20:43:26 -0500 (EST) Message-Id: <4.3.2.7.2.20030122195509.03ebf9f8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Jan 2003 20:43:18 -0500 To: zeroconf@merit.edu From: Ralph Droms Subject: Re: WG decision: when to configure LL addrs In-Reply-To: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 09:50 AM 1/22/2003 -0500, Thomas Narten wrote: >1) Should the ID recommend that LL addresses only be configured as per > below. Please answer clearly, along the lines of > > a) yes, I think this is what the document should say (maybe with > some small tweaks, which then need to be explained) Yes, with changes as suggested below. > > b) no, this is a showstopper for me (and explain why, so the rest > of the WG can understand and then agree or disagree with your > position) > > c) Not my first choice, but I can live with it. > > > 1 when should an IPv4LL address be configured by a host? > > > suggest: if the host is explicitly configured to do so, OR > > if the host has attempted and failed to acquire a routable address > via DHCP "Routable" may not be clear, here. Is routable == non-LLv4? Or routable == non-RFC1918? I would suggest just dropping "routable". "Failed to acquire" may also be problematic, as RFC2131 does not give a precise definition of when to declare DHCP "failed". How about "until the host has successfully obtained an address through DHCP"? > > (alternative: provide a lighter weight mechanism by which a host can > acquire a > > routable address, netmask, and default route, in response to its > attempt to claim > > an IPv4LL address) This proposed alternative is a red herring; consideration of it will lead only to more rat-holing. DHCP is here, it's been deployed for years and nobody has had a well-defined set of requirements and strong enough motivation to come up with something "lighter weight", yet. > > 2 when should an IPv4LL address be used by a host as a source address? > > > suggest: when the only addresses available to the host are IPv4LL > addresses, OR > > when the application has explicitly specified the source address to > use, OR > > when the application has explicitly specified the interface to use > and the IPv4LL address > > is the only address associated with that interface. When the only addresses available to the host are IPv4LL addresses. > > 3 when should a host honor an attempt to connect to an IPv4LL address > that was once > > configured by that host? > > > suggest: anytime the address is still valid (e.g. there have been no > conflicting claims) > > and there is a process listening for connections either specifically > to that address or > > for incoming connections at any of the host's addresses. When the only addresses available to the host are IPv4LL addresses. > > 4 when should an application attempt to connect to a IPv4LL address? > > > suggest: only when the address is literally specified, or if there > are no other routable > > addresses for the destination host known to the application. I agree with the suggested text. > > 5 when should an application send an IPv4LL address in a referral to > another host? > > > suggest: only when there are no routable addresses for the > destination host known to the > > application. even then, care needs to be taken that a host reached > at a particular > > IPv4LL address is really the one intended - since IPv4LL addresses > can be reassigned > > without notice and/or reused on different network segments. I agree with the suggested text. From owner-zeroconf@merit.edu Wed Jan 22 22:16:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15191 for ; Wed, 22 Jan 2003 22:16:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D3FF3913DC; Wed, 22 Jan 2003 22:19:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D1569131A; Wed, 22 Jan 2003 22:19: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 B622A9131A for ; Wed, 22 Jan 2003 22:17:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 937BF5DEBA; Wed, 22 Jan 2003 22:17:11 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by segue.merit.edu (Postfix) with ESMTP id 1D2685DE50 for ; Wed, 22 Jan 2003 22:17:11 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0N3Hvl3022719 for ; Wed, 22 Jan 2003 22:17:57 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-85.cisco.com [10.82.224.85]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA08987 for ; Wed, 22 Jan 2003 22:17:08 -0500 (EST) Message-Id: <4.3.2.7.2.20030122220931.03eb71d0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Jan 2003 22:17:02 -0500 To: Zeroconf From: Ralph Droms Subject: Re: LL-only devices [was Re: Turning off link-locals?] In-Reply-To: <200301221445.h0MEjSR10944@cichlid.adsl.duke.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Seems to me LLv4 is a short-term solution that will not serve in the long run - assuming the long run is homes, offices and other sites with multiple links connected by routers. In fact, LLv4 might turn out to be an obstacle to progress, as it might encourage bridging or some other way of flattening networks for LLv4. I can imagine a future in which LLv4 addresses are bridged across an entire site - to allow use of LLv4-only devices across the entire site - while non-LLv4 addresses are routed in the familiar way. "Simplification" without looking at wider impact sounds like a variant of the NAT-virus to me. - Ralph At 09:45 AM 1/22/2003 -0500, Thomas Narten wrote: >"John C. Welch" writes: > > > WHY do you need to have printers with routable, global addresses in all > > cases? > >Because this is the norm today, it works, and we understand it's >limitations. There are fewer problems in general if a device has a >global address. LL addresses only work in limited circumstances -- >namely, on a single link. > > > Normally, you don't. So printers with LLv4 - only addressing actually > > makes a fair bit of sense, especially behind a firewall and a NAT. (Yes, > > keith, we KNOW how you feel about NAT, but they exist, so sticking fingers > > in ears and yelling loudly won't change that). > >You are making a bunch of assumptions here that I don't think >generalize, and I suspect we do not want to mandate or suggest is The >Right Way for the future. > >Recall, LL addresses only work on a single link. If a printer has only >a LL address, one can no longer print on it from behind a router. This >may not be a limitation in typical home networks *today*, but >certainly is in small offices, and future homes. Thus, we need to be >very careful about encouraging such a direction for the future. I'd be >rather suprised of printer (and other small device) vendors thought it >made business sense to not implement DHC on the client. > >I do not believe this WG should be legitimizing LL-only hosts. If >vendors want to ship such devices, we can't stop them, but blessing >such behavior, and encouraging it *in* *general* is also not something >we need to allow. > >General comment: there is a long history of folk wanting to "simplify" >TCP/IP for a device with limited capabilities. That is not the goal of >this WG. It might be a fine topic for a different WG. But it is not in >the charter for this WG. On the other hand, when looking at limited >functionality devices, the IETF has historically said, after getting >to the underlying technical issues, "the arguments about limited code >space, etc. are bogus, you need to implement full TCP/IP". For >example, crying that DHCP is too expensive to implement in a small >device that also includes TCP/HTTP and a limited web server (e.g., for >configuration) just doesn't sway a lot of folk. Or for a printer that >implements the IPP protocols (no lean-and-mean protocol). But again, >that topic is a distraction for this WG. > >Thomas From owner-zeroconf@merit.edu Wed Jan 22 22:16:08 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15204 for ; Wed, 22 Jan 2003 22:16:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ACC519131B; Wed, 22 Jan 2003 22:19:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D5D091381; Wed, 22 Jan 2003 22:18: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 211439131B for ; Wed, 22 Jan 2003 22:17:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 055485DEBA; Wed, 22 Jan 2003 22:17:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtpout.mac.com (A17-250-248-89.apple.com [17.250.248.89]) by segue.merit.edu (Postfix) with ESMTP id 8DCB85DE50 for ; Wed, 22 Jan 2003 22:17:33 -0500 (EST) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h0N2xnr4023428 for ; Wed, 22 Jan 2003 18:59:49 -0800 (PST) Received: from mac.com ([200.67.17.194]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id H95CBO00.T7P for ; Wed, 22 Jan 2003 18:59:48 -0800 Date: Wed, 22 Jan 2003 20:59:49 -0600 Subject: Re: WG decision: when to configure LL addrs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Rod To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, January 22, 2003, at 08:50 AM, Thomas Narten wrote: > Folks, > > This WG needs to declare consensus on some basic issues, or it will > never get done. > > The note below from Keith summarizes what I see a lot of other folk > seeming to agree with. > > So, I would like to ask the WG to answer the following questions: > > 1) Should the ID recommend that LL addresses only be configured as per > below. Please answer clearly, along the lines of > > a) yes, I think this is what the document should say (maybe with > some small tweaks, which then need to be explained) I Agree. Eliminating "routable" from the first part, as well as the "lighter weight mechanism." I also like Aidan's suggestion of: "An application with a choice between connecting to LL address and non-LL address SHOULD prefer the non-LL address." instead of what was previously suggested. Also: > suggest: when the only addresses available to the host are IPv4LL > addresses Shouldn't this read "when the only addresses available to the host on that interface are IPv4LL addresses?" It wouldn't make sense to send the host's global address if it's on a different interface than the one communicating with the LL device. Still, I disagree. I agree with Aidan, that if a host has an IPv4LL address, it should use that to communicate with an IPv4LL destination, even if it's not the only address specified for that interface. I disagree with Robert Elz's suggestion that if a host was refused an address it should not configure an IPv4LL address, since it's both unfeasible at the moment and pointless, as one can assign a manual IP address anyway. -Rod Lopez From owner-zeroconf@merit.edu Wed Jan 22 22:30:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15406 for ; Wed, 22 Jan 2003 22:30:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AAB1F91381; Wed, 22 Jan 2003 22:30:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7BA25913E1; Wed, 22 Jan 2003 22:30: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 6433B91381 for ; Wed, 22 Jan 2003 22:30:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C2EE5DEE4; Wed, 22 Jan 2003 22:30:52 -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 B504A5DE50 for ; Wed, 22 Jan 2003 22:30:50 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h0N3UoHI006484 for ; Wed, 22 Jan 2003 20:30:50 -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 UAA08843 for ; Wed, 22 Jan 2003 20:29: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 h0N3UiEE025660; Thu, 23 Jan 2003 14:30:44 +1100 (EST) Message-ID: <3E2F61E2.4060402@motorola.com> Date: Thu, 23 Jan 2003 14:30:42 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Cc: narten@us.ibm.com, zeroconf@merit.edu Subject: Address stability, again References: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> <3E2F39EC.90105@motorola.com> <20030122220950.48c3ce90.moore@cs.utk.edu> In-Reply-To: <20030122220950.48c3ce90.moore@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: >>A host always need to take care the host reached at a particular address >>is really the one intended. > > There's no way that a host can know this, because the only identifier that a > host has to recognize another host is the IP address, which is precisely what > is ambiguous. If the application has a better identifier which is independent > of the IP address, the application may be able to verify the identities of its > peers. However most application protocols don't have a mechanism for doing > this. > Great! Then I would be happy to dispense with this text entirely: > even then, care needs to be taken that a host reached at a > particular IPv4LL address is really the one intended There are plenty of scenarios where non-IPv4LL IP addresses change frequently. Cryptographic techniques are the only real answer to authenticating identity and those techniques can be applied over the top of IPv4-LL if necessary. > >>The IPv4-LL case is a difference in degree >>only. The "correctness" or "stability" of the name to address mapping >>seems much more important to me and that is out of scope of this document. > > > The stability of the name-to-address binding and the stability of the > address-to-host binding are two separate issues which are easily confused. > Either binding can change independently of the other. This document only > deals with the address-to-host binding, but both bindings are relevant, > because a change to either binding will generally cause the application to > fail. I disagree with you on the emphasis you place on address stability. I think IPv4-LL addresses are likely to be more stable in a given environment that you give them credit for. I also think that the stability of link-local addresses is less important than you seem to believe. I am not inclined to rat-hole further on the subject. - aidan From owner-zeroconf@merit.edu Wed Jan 22 22:30:36 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15462 for ; Wed, 22 Jan 2003 22:30:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5DCAE913E1; Wed, 22 Jan 2003 22:33:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E9B8913E2; Wed, 22 Jan 2003 22:33: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 F02D6913E1 for ; Wed, 22 Jan 2003 22:32:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id CBB485DEBA; Wed, 22 Jan 2003 22:32:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from soulshock.mail.pas.earthlink.net (soulshock.mail.pas.earthlink.net [207.217.120.130]) by segue.merit.edu (Postfix) with ESMTP id 30F8F5DE50 for ; Wed, 22 Jan 2003 22:32:36 -0500 (EST) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by soulshock.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0N3E5H16527 for ; Wed, 22 Jan 2003 19:14:05 -0800 (PST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bXoS-0005U7-00; Wed, 22 Jan 2003 19:13:56 -0800 Date: Wed, 22 Jan 2003 22:12:26 -0500 From: Keith Moore To: Ian Lister Cc: moore@cs.utk.edu, narten@us.ibm.com, zeroconf@merit.edu Subject: Re: WG decision: when to configure LL addrs Message-Id: <20030122221226.06d64806.moore@cs.utk.edu> In-Reply-To: References: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Thu, 23 Jan 2003 11:40:38 +1000 (EST) Ian Lister wrote: > On Wed, 22 Jan 2003, Thomas Narten wrote: > >1) Should the ID recommend that LL addresses only be configured as per > > below. > > Generally, yes. > > As others have pointed out, there should probably be some tweaks to the > use of the term `routable addresses', and the `alternative' from the first > section is not required. note that 'routable' was intended in the sense that it is used in the current LL draft - it doesn't mean global, it means something that can be routed. LL addresses cannot be routed, not even within a private network. RFC 1918 addresses can be routed, just not on the public internet. as for the 'alternative' - I'd be curious to hear from those who want to use this for simple plug-and-play fixed-function devices whether they think a requirement to implement DHCP is too onerous. Keith From owner-zeroconf@merit.edu Wed Jan 22 22:35:57 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15808 for ; Wed, 22 Jan 2003 22:35:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 45CFB913E2; Wed, 22 Jan 2003 22:39:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16887913E3; Wed, 22 Jan 2003 22:39: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 03B97913E2 for ; Wed, 22 Jan 2003 22:39:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id DDE945DEE4; Wed, 22 Jan 2003 22:39:06 -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 739E65DEBA for ; Wed, 22 Jan 2003 22:39:06 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id WAA09681 for ; Wed, 22 Jan 2003 22:39:05 -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 WAA17386 for ; Wed, 22 Jan 2003 22:36:08 -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 WAA01683 for ; Wed, 22 Jan 2003 22:36:07 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Wed, 22 Jan 2003 22:36:05 -0500 Subject: Re: One last attempt to illustrate my concerns From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030122220125.278529b5.moore@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 01/22/2003 22:01, "Keith Moore" wrote: >> LOL...what's your management tool that you use for every single device on a >> network no matter what kind of device, platform or operating system? > > DHCP comes close. Okay...that's a network stack configuration tool...i'm talking Network management, ala Tivoli, CA - Unicenter, netOctopus...a bit more extensive. Network admins need to do a lot more than just configure IP addresses. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Wed Jan 22 22:45:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16048 for ; Wed, 22 Jan 2003 22:45:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 57899913E3; Wed, 22 Jan 2003 22:48:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD01B913E4; Wed, 22 Jan 2003 22:47: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 233F5913E3 for ; Wed, 22 Jan 2003 22:46:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id A09D15DED2; Wed, 22 Jan 2003 22:46:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from soulshock.mail.pas.earthlink.net (soulshock.mail.pas.earthlink.net [207.217.120.130]) by segue.merit.edu (Postfix) with ESMTP id 4120D5DEBA for ; Wed, 22 Jan 2003 22:46:34 -0500 (EST) Received: from flamingo.mail.pas.earthlink.net (flamingo.mail.pas.earthlink.net [207.217.120.232]) by soulshock.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0N3BqH15340 for ; Wed, 22 Jan 2003 19:11:52 -0800 (PST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bXlw-00020A-00; Wed, 22 Jan 2003 19:11:20 -0800 Date: Wed, 22 Jan 2003 22:09:50 -0500 From: Keith Moore To: Aidan Williams Cc: moore@cs.utk.edu, narten@us.ibm.com, zeroconf@merit.edu Subject: Re: WG decision: when to configure LL addrs Message-Id: <20030122220950.48c3ce90.moore@cs.utk.edu> In-Reply-To: <3E2F39EC.90105@motorola.com> References: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> <3E2F39EC.90105@motorola.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 clarification here: > >>- when should an application attempt to connect to a IPv4LL address? > > > >> suggest: only when the address is literally specified, or if there are > >no other routable> addresses for the destination host known to the > >application. > > > > Literally specified? By whom? by a user. in other words, if for some reason a user types in a v4 address literal (and there are indeed times when this is appropriate), the application should honor it. I certainly don't want the standard to forbid talking to a v4LL address that was explicitly specified by a user. > I would be happier with: > > An application with a choice between connecting to LL address and > non-LL address SHOULD prefer the non-LL address. > that is certainly more brief, and it might be sufficient. > >>- when should an application send an IPv4LL address in a referral to > >another host? > > > >> suggest: only when there are no routable addresses for the destination > >host known to the > application. even then, care needs to be taken that a > >host reached at a particular> IPv4LL address is really the one intended - > >since IPv4LL addresses can be reassigned> without notice and/or reused on > >different network segments. > > > Most of these issues seem to be covered already. > > Section 7.2, Limited Forwarding of Locators > Section 7.3, Address Ambiguity > Section 2.9, Higher-Layer Protocol Considerations > > A host always need to take care the host reached at a particular address > is really the one intended. There's no way that a host can know this, because the only identifier that a host has to recognize another host is the IP address, which is precisely what is ambiguous. If the application has a better identifier which is independent of the IP address, the application may be able to verify the identities of its peers. However most application protocols don't have a mechanism for doing this. > The IPv4-LL case is a difference in degree > only. The "correctness" or "stability" of the name to address mapping > seems much more important to me and that is out of scope of this document. The stability of the name-to-address binding and the stability of the address-to-host binding are two separate issues which are easily confused. Either binding can change independently of the other. This document only deals with the address-to-host binding, but both bindings are relevant, because a change to either binding will generally cause the application to fail. From owner-zeroconf@merit.edu Wed Jan 22 23:16:00 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16661 for ; Wed, 22 Jan 2003 23:16:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DCDF4913E4; Wed, 22 Jan 2003 23:19:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A17A8913E5; Wed, 22 Jan 2003 23:19: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 4D4C6913E4 for ; Wed, 22 Jan 2003 23:19:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 29FF05DE4A; Wed, 22 Jan 2003 23:19:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from badboy.mail.pas.earthlink.net (badboy.mail.pas.earthlink.net [207.217.120.20]) by segue.merit.edu (Postfix) with ESMTP id 9EA7B5DD9E for ; Wed, 22 Jan 2003 23:19:16 -0500 (EST) Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by badboy.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0N3xuk03403 for ; Wed, 22 Jan 2003 19:59:56 -0800 (PST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bYWX-0003VB-00; Wed, 22 Jan 2003 19:59:29 -0800 Date: Wed, 22 Jan 2003 22:57:58 -0500 From: Keith Moore To: Aidan Williams Cc: moore@cs.utk.edu, narten@us.ibm.com, zeroconf@merit.edu Subject: Re: Address stability, again Message-Id: <20030122225758.63299936.moore@cs.utk.edu> In-Reply-To: <3E2F61E2.4060402@motorola.com> References: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> <3E2F39EC.90105@motorola.com> <20030122220950.48c3ce90.moore@cs.utk.edu> <3E2F61E2.4060402@motorola.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Thu, 23 Jan 2003 14:30:42 +1100 Aidan Williams wrote: > Keith Moore wrote: > >>A host always need to take care the host reached at a particular address > >>is really the one intended. > > > > There's no way that a host can know this, because the only identifier that > > a host has to recognize another host is the IP address, which is precisely > > what is ambiguous. If the application has a better identifier which is > > independent of the IP address, the application may be able to verify the > > identities of its peers. However most application protocols don't have a > > mechanism for doing this. > > > > Great! Then I would be happy to dispense with this text entirely: > > > even then, care needs to be taken that a host reached at a > > particular IPv4LL address is really the one intended It depends on your point-of-view. If you're implementing IPv4LL in a host stack, there's nothing you can do about the potential for address-to-host bindings changing. If you're implementing an application with a pre-defined protocol, there's not likely to be much you can do about it. If you're designing a new application and you want it to be tolerant of v4LL addresses, you can do a bit more. > There are plenty of scenarios where non-IPv4LL IP addresses change > frequently. Yes- misconfigured DHCP servers, and hosts with intermittent dialup connections where the connections fail often. Often the DHCP servers can be fixed, and we tend to not expect dialup connections to support long-running appliations. But basically the fact that LL can introduce additional failures due to changing address-to-host bindings does not bother me much as long as we don't use LL except on isolated networks. It's when LL is touted as suitable for general-purpose use (e.g. as a replacement for DHCP) that I get concerned. Ad hoc networks are always going to be somewhat less functional than their managed cousins, and there's simply no way for a configurationless, isolated v4 network to assign a unique address that isn't subject to change. So I accept the current limitations of v4LL address stability as the best that can be done given the available address space in v4, and (regarding stabliity) I mostly ask that we don't use v4LL addresses when better addresses are available, and we don't try to pretend that v4LLs are as (stable, useful, unambiguous) as v4 addresses assigned by a managed network. > >>The IPv4-LL case is a difference in degree > >>only. The "correctness" or "stability" of the name to address mapping > >>seems much more important to me and that is out of scope of this document. > > > > > > The stability of the name-to-address binding and the stability of the > > address-to-host binding are two separate issues which are easily confused. > > > > Either binding can change independently of the other. This document only > > deals with the address-to-host binding, but both bindings are relevant, > > because a change to either binding will generally cause the application to > > fail. > > I disagree with you on the emphasis you place on address stability. > I think IPv4-LL addresses are likely to be more stable in a given > environment that you give them credit for. I also think that the > stability of link-local addresses is less important than you seem > to believe. Again, it depends on what you are doing. The current draft is probably about as good as we can do at providing automatic assignment of stable addresses in v4. At the same time, if you are writing a distributed application, or an application that uses long-lived connections, it cannot so easily be dismissed as unimportant. Keith From owner-zeroconf@merit.edu Wed Jan 22 23:18:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16703 for ; Wed, 22 Jan 2003 23:18:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 35D0B913E5; Wed, 22 Jan 2003 23:21:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0493C913E6; Wed, 22 Jan 2003 23:21: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 B0B62913E5 for ; Wed, 22 Jan 2003 23:21:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 956605DF26; Wed, 22 Jan 2003 23:21:19 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtp.covadmail.net (mx03.covadmail.net [63.65.120.63]) by segue.merit.edu (Postfix) with SMTP id 240925DDA1 for ; Wed, 22 Jan 2003 23:21:19 -0500 (EST) Received: (covad.net 3540 invoked from network); 23 Jan 2003 04:21:18 -0000 Received: from unknown (HELO STUDY) (66.166.57.4) by sun-qmail17 with SMTP; 23 Jan 2003 04:21:18 -0000 To: Keith Moore Cc: narten@us.ibm.com, zeroconf@merit.edu Subject: Re: WG decision: when to configure LL addrs References: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> <20030122221226.06d64806.moore@cs.utk.edu> From: Scott Lawrence Date: 22 Jan 2003 23:23:13 -0500 In-Reply-To: <20030122221226.06d64806.moore@cs.utk.edu> Message-ID: Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-zeroconf@merit.edu Precedence: bulk Keith Moore writes: > as for the 'alternative' - I'd be curious to hear from those who want to use > this for simple plug-and-play fixed-function devices whether they think a > requirement to implement DHCP is too onerous. That's a space I've spent a lot of time in the last several years. No, I don't, which is part of why I thought developing an alternative was not a good idea. A very constrained implementation could dispense with recognizing most options, since only a few would be relevant. In effect, it could be BOOTP with lease timers. I doubt that many product managers would choose to have thier devices ignore DHCP in any event, because they wouldn't want to risk not being able to communicate with devices that couldn't figure out that the LL address was reachable (as simple as that is, I certainly wouldn't bet against someone having gotten it wrong). As has been pointed out, in this sort of product one support call can more than wipe out the profit on the sale; it's gotta just work. From owner-zeroconf@merit.edu Wed Jan 22 23:31:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16919 for ; Wed, 22 Jan 2003 23:31:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F07C2913E7; Wed, 22 Jan 2003 23:34:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB2E5913E8; Wed, 22 Jan 2003 23:34: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 7F55E913E7 for ; Wed, 22 Jan 2003 23:34:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 652275DE4A; Wed, 22 Jan 2003 23:34:43 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from soulshock.mail.pas.earthlink.net (soulshock.mail.pas.earthlink.net [207.217.120.130]) by segue.merit.edu (Postfix) with ESMTP id 0E1E65DE44 for ; Wed, 22 Jan 2003 23:34:43 -0500 (EST) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by soulshock.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0N45EH10454 for ; Wed, 22 Jan 2003 20:05:14 -0800 (PST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bYbi-0005lt-00; Wed, 22 Jan 2003 20:04:50 -0800 Date: Wed, 22 Jan 2003 23:03:19 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122230319.1da927aa.moore@cs.utk.edu> In-Reply-To: References: <20030122220125.278529b5.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > >> LOL...what's your management tool that you use for every single device on > >a> network no matter what kind of device, platform or operating system? > > > > DHCP comes close. > > Okay...that's a network stack configuration tool...i'm talking Network > management, ala Tivoli, CA - Unicenter, netOctopus...a bit more extensive. > Network admins need to do a lot more than just configure IP addresses. well, we were talking about just the one bit that says whether to use LL or not. to me it makes more sense for that bit be conveyed by DHCP than by a more complex and less standard mechanism. and I don't particularly see why that bit needs to be any more authenticated than any other address configuration information. if DHCP is good enough for address and netmask, it's good enough for LL yes/no. Keith From owner-zeroconf@merit.edu Wed Jan 22 23:31:58 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16935 for ; Wed, 22 Jan 2003 23:31:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 34538913E8; Wed, 22 Jan 2003 23:35:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF1B3913E9; Wed, 22 Jan 2003 23:35: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 C9A34913E8 for ; Wed, 22 Jan 2003 23:35:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD9CF5DEA1; Wed, 22 Jan 2003 23:35:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from soulshock.mail.pas.earthlink.net (soulshock.mail.pas.earthlink.net [207.217.120.130]) by segue.merit.edu (Postfix) with ESMTP id 2B9985DE4C for ; Wed, 22 Jan 2003 23:35:14 -0500 (EST) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by soulshock.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0N41YH08877 for ; Wed, 22 Jan 2003 20:01:34 -0800 (PST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bYY8-0000wq-00; Wed, 22 Jan 2003 20:01:09 -0800 Date: Wed, 22 Jan 2003 22:59:38 -0500 From: Keith Moore To: Rod Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: WG decision: when to configure LL addrs Message-Id: <20030122225938.40fb3b80.moore@cs.utk.edu> In-Reply-To: References: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > I agree with Aidan, that if a host has an IPv4LL address, it should use > that to communicate with an IPv4LL destination, even if it's not the > only address specified for that interface. have to disagree here. there should be as little use of v4LL addresses as possible, because the more exposure of such addresses, the greater the potential for them to leak outside of their realms. From owner-zeroconf@merit.edu Wed Jan 22 23:37:26 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17004 for ; Wed, 22 Jan 2003 23:37:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0A219913E9; Wed, 22 Jan 2003 23:40:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6EF4913EA; Wed, 22 Jan 2003 23:40: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 954BB913E9 for ; Wed, 22 Jan 2003 23:40:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7DC6E5DE4C; Wed, 22 Jan 2003 23:40:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from badboy.mail.pas.earthlink.net (badboy.mail.pas.earthlink.net [207.217.120.20]) by segue.merit.edu (Postfix) with ESMTP id EF8045DDA1 for ; Wed, 22 Jan 2003 23:40:40 -0500 (EST) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by badboy.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0N33Lk06815 for ; Wed, 22 Jan 2003 19:03:21 -0800 (PST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bXdo-00013g-00; Wed, 22 Jan 2003 19:02:56 -0800 Date: Wed, 22 Jan 2003 22:01:25 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: One last attempt to illustrate my concerns Message-Id: <20030122220125.278529b5.moore@cs.utk.edu> In-Reply-To: References: <20030122190218.3faf0466.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > LOL...what's your management tool that you use for every single device on a > network no matter what kind of device, platform or operating system? DHCP comes close. Keith From owner-zeroconf@merit.edu Thu Jan 23 00:08:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17461 for ; Thu, 23 Jan 2003 00:08:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E60E1913EA; Thu, 23 Jan 2003 00:11:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0A90913EB; Thu, 23 Jan 2003 00:11: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 A19D0913EA for ; Thu, 23 Jan 2003 00:11:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 87C115DF5C; Thu, 23 Jan 2003 00:11:38 -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 6AACE5DF29 for ; Thu, 23 Jan 2003 00:11:38 -0500 (EST) Received: from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h0N5BYHI005540; Wed, 22 Jan 2003 22:11:34 -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 WAA09794; Wed, 22 Jan 2003 22:10:41 -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 h0N5BUEE000590; Thu, 23 Jan 2003 16:11:30 +1100 (EST) Message-ID: <3E2F7982.9090703@motorola.com> Date: Thu, 23 Jan 2003 16:11:30 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Keith Moore Cc: Rod , zeroconf@merit.edu Subject: Re: WG decision: when to configure LL addrs References: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> <20030122225938.40fb3b80.moore@cs.utk.edu> In-Reply-To: <20030122225938.40fb3b80.moore@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: > have to disagree here. there should be as little use of v4LL addresses as > possible, because the more exposure of such addresses, the greater the > potential for them to leak outside of their realms. > Danger Will Robinson! Danger! Since we'll be preferring globals, again I think that the problem is much larger in your head than in real life. Once again, lets agree to disagree and stop ratholing. - aidan From owner-zeroconf@merit.edu Thu Jan 23 04:22:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01189 for ; Thu, 23 Jan 2003 04:22:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B7F8491214; Thu, 23 Jan 2003 04:25:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 858B9913F0; Thu, 23 Jan 2003 04:25: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 9BD0891214 for ; Thu, 23 Jan 2003 04:25:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7E4F45DF6C; Thu, 23 Jan 2003 04:25:38 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 07A7F5DF64 for ; Thu, 23 Jan 2003 04:25:38 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA12436; Thu, 23 Jan 2003 01:25:36 -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 h0N9PYl23558; Thu, 23 Jan 2003 10:25:34 +0100 (MET) Date: Thu, 23 Jan 2003 10:25:32 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Thomas Narten Cc: zeroconf@merit.edu Subject: Re: WG decision: when to configure LL addrs In-Reply-To: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Thomas, On Wed, 22 Jan 2003, Thomas Narten wrote: > This WG needs to declare consensus on some basic issues, or it will > never get done. Yes. > 1) Should the ID recommend that LL addresses only be configured as per > below. Please answer clearly, along the lines of > > a) yes, I think this is what the document should say (maybe with > some small tweaks, which then need to be explained) I agree, after consideration and voluminous reading. The arguments for keeping an IPv4LL address configuration despite having a global one are weak if one considers that the host supporting IPv4LL already has to support address renumbering. If a host can already find a peer and continue communicating with it despite IPv4LL address renumbering events (using service discovery or a multicast name resolution protocol), the hosts should be able to transition to communication via IPv4 global addresses as well. Thanks for your intervention, Thomas. Erik From owner-zeroconf@merit.edu Thu Jan 23 05:12:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02094 for ; Thu, 23 Jan 2003 05:12:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F3A6D913F0; Thu, 23 Jan 2003 04:56:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B42CD913F1; Thu, 23 Jan 2003 04:56: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 B13AA913F0 for ; Thu, 23 Jan 2003 04:56:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 97CA45DE4A; Thu, 23 Jan 2003 04:56:41 -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 69B955DE0B for ; Thu, 23 Jan 2003 04:56:41 -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 1A55059899; Thu, 23 Jan 2003 09:56:42 +0000 (GMT) Message-ID: <002b01c2c2c5$b9c9ef40$131010ac@aldebaran> From: "Philip Nye" To: "Aidan Williams" , "Zeroconf Working Group" References: <200301221450.h0MEo2l11224@cichlid.adsl.duke.edu> <3E2F39EC.90105@motorola.com> <20030122220950.48c3ce90.moore@cs.utk.edu> <3E2F61E2.4060402@motorola.com> Subject: Re: Address stability, again Date: Thu, 23 Jan 2003 09:56:39 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Aidan Williams" > > I disagree with you on the emphasis you place on address stability. > I think IPv4-LL addresses are likely to be more stable in a given > environment that you give them credit for. I also think that the > stability of link-local addresses is less important than you seem > to believe. There is an issue with scoped addresses which goes beyond address stability over time. Namely that many applications have no way of knowing what the scope of the address is or what the "viewpoint" of another host is. This causes a breakage mode in distributed apps - if I refer you to a third party X, you may successfully contact a different X to the one I can see - while both Xs have stable addresses. Philip From owner-zeroconf@merit.edu Thu Jan 23 10:32:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10339 for ; Thu, 23 Jan 2003 10:32:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CF3CA913FE; Thu, 23 Jan 2003 10:35:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 983D8913FF; Thu, 23 Jan 2003 10:35: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 8F2A4913FE for ; Thu, 23 Jan 2003 10:35:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 776625DFA3; Thu, 23 Jan 2003 10:35:24 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id BE1CE5DEDD for ; Thu, 23 Jan 2003 10:35:22 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0NFZ5R11731; Thu, 23 Jan 2003 22:35:05 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0NFYl818537; Fri, 24 Jan 2003 02:34:50 +1100 (EST) From: Robert Elz To: Ted Lemon Cc: "Zeroconf" Subject: Re: Turning off link-locals? In-Reply-To: <3450D7C8-2E35-11D7-AFDA-00039317663C@nominum.com> References: <3450D7C8-2E35-11D7-AFDA-00039317663C@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Jan 2003 22:34:47 +0700 Message-ID: <18535.1043336087@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 22 Jan 2003 10:13:27 -0800 From: Ted Lemon Message-ID: <3450D7C8-2E35-11D7-AFDA-00039317663C@nominum.com> Answering two of your messages in one reply, to try and keep this list a little quieter.... | In order for mDNS to be really useful, gethostbyname("foo.local.") has | to work. So unfortunately your reasoning here doesn't work. Of course, but I think you missed my point. If mDNS is used, the host owning the name supplies the address to be used - if it has a non-LL address, it should just supply that one - we don't need to have gethostbyname() do some rule based algorithm to handle things. | DHCP doesn't provide a protocol message that says "I'm here, but I'm | not going to give you an IP address." So a client that can't contact | a DHCP server has no way of telling whether this is because there is no | DHCP server, or because the DHCP server doesn't like it. That's a good point. I should know enough about DHCP to have known that. So, I guess we can't have a "I'm here but I'm not going to give you an address, and you should not use v4LL either" mode, and so clearly no language like that in the doc is required. I guess the functionality can always be had by having the DHCP server assign 0.0.0.0 or 127.0.0.1 as the address though... Even if the client decides to DHCPNAK (or ignore the DHCPOFFER) then at least it knows there is a DHCP server out there that can assign addresses. In that case, it should not give itself a LL address (if the DHCP message included the "no LL" option, or didn't include the "allow LL" option, depending which way that question goes). Ted.Lemon@nominum.com said: | This doesn't satisfy me because it requires that an arbitrary delay | before I can use my zeroconf network. For zeroconf you have to have that, because of the spanning tree problem. If you go and assign yourself an address, you're quite likely going to get a duplicate (sometimes anyway) and so cause problems to some other innocent device, for no good reason at all (this is much more common than the "two isolated halves of a link reconnecting" issue that can also cause problems). So, unless the node can be *certain* that there cannot possibly be something running the spanning tree algorithm, it must wait long enough for that to have completed before it decides that there is no other user of the address it wants. You said in yet another message that this breaks DHCP too. It doesn't. It breaks some clients, that don't wait long enough to receive an offer. If the client just keeps on doing its DISCOVER eventually (server able and willing) an offer will appear. Nothing actually breaks here. Even in the face of impatient client code however, the only breakage is to the client itself. That's relatively harmless. kre From owner-zeroconf@merit.edu Thu Jan 23 10:40:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10490 for ; Thu, 23 Jan 2003 10:40:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DF91E913FF; Thu, 23 Jan 2003 10:44:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC3CD91400; Thu, 23 Jan 2003 10:44: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 AB57C913FF for ; Thu, 23 Jan 2003 10:44:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B5495DFA5; Thu, 23 Jan 2003 10:44:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 3D7725DFA3 for ; Thu, 23 Jan 2003 10:44:06 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 8943E59891; Thu, 23 Jan 2003 15:44:07 +0000 (GMT) Message-ID: <010301c2c2f6$42226950$131010ac@aldebaran> From: "Philip Nye" To: "Robert Elz" , "Ted Lemon" Cc: "Zeroconf" References: <3450D7C8-2E35-11D7-AFDA-00039317663C@nominum.com> <18535.1043336087@munnari.OZ.AU> Subject: Re: Turning off link-locals? Date: Thu, 23 Jan 2003 15:44:03 -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: "Robert Elz" > > From: Ted Lemon > > | DHCP doesn't provide a protocol message that says "I'm here, but I'm > | not going to give you an IP address." So a client that can't contact > | a DHCP server has no way of telling whether this is because there is no > | DHCP server, or because the DHCP server doesn't like it. > > That's a good point. I should know enough about DHCP to have known that. > > So, I guess we can't have a "I'm here but I'm not going to give you an > address, and you should not use v4LL either" mode, and so clearly no > language like that in the doc is required. Digging around in DHCP I found RFC2563 which appears to give precisely this message. Is it no longer valid? Philip From owner-zeroconf@merit.edu Thu Jan 23 11:32:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12394 for ; Thu, 23 Jan 2003 11:32:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8B8B391408; Thu, 23 Jan 2003 11:35:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5798B91409; Thu, 23 Jan 2003 11:35:55 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 292D791408 for ; Thu, 23 Jan 2003 11:35:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 07AC85DFC4; Thu, 23 Jan 2003 11:35:54 -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 90D585DF98 for ; Thu, 23 Jan 2003 11:35: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 LAA24483 for ; Thu, 23 Jan 2003 11:35: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 LAA09808 for ; Thu, 23 Jan 2003 11:35:52 -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 LAA24675 for ; Thu, 23 Jan 2003 11:35:52 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 23 Jan 2003 11:35:51 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <010301c2c2f6$42226950$131010ac@aldebaran> 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 01/23/2003 10:44, "Philip Nye" wrote: >> So, I guess we can't have a "I'm here but I'm not going to give you an >> address, and you should not use v4LL either" mode, and so clearly no >> language like that in the doc is required. > > Digging around in DHCP I found RFC2563 which appears to give precisely this > message. > Is it no longer valid? The problem here, and with relying solely on DHCP for this is implementation. There are a lot of options within DHCP that may not be included with a server, or turned on if included. It may not be desireable, but that's the way things go, and it's unrealistic to expect that you can force anyone to implement every option of everything unless it's required. With that in mind, how about including two methods...DHCP shutdown with a manual override. That way, the network manager/user can avoid any problems due to the idiot neighbor kid discovering phrack as an alternative to pulling wings off of flies. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Jan 23 11:43:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12770 for ; Thu, 23 Jan 2003 11:43:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 554939140C; Thu, 23 Jan 2003 11:46:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D4F79140B; Thu, 23 Jan 2003 11:46: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 E67D69140C for ; Thu, 23 Jan 2003 11:46:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id A513C5DFDB; Thu, 23 Jan 2003 11:46:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtp.covadmail.net (mx03.covadmail.net [63.65.120.63]) by segue.merit.edu (Postfix) with SMTP id 321315DEE3 for ; Thu, 23 Jan 2003 11:46:17 -0500 (EST) Received: (covad.net 925 invoked from network); 23 Jan 2003 16:46:16 -0000 Received: from unknown (HELO STUDY) (66.167.13.235) by sun-qmail08 with SMTP; 23 Jan 2003 16:46:16 -0000 To: "Philip Nye" Cc: "Zeroconf" Subject: Re: Turning off link-locals? References: <3450D7C8-2E35-11D7-AFDA-00039317663C@nominum.com> <18535.1043336087@munnari.OZ.AU> <010301c2c2f6$42226950$131010ac@aldebaran> From: Scott Lawrence Date: 23 Jan 2003 11:48:21 -0500 In-Reply-To: <010301c2c2f6$42226950$131010ac@aldebaran> Message-ID: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-zeroconf@merit.edu Precedence: bulk "Philip Nye" writes: > Digging around in DHCP I found RFC2563 which appears to give precisely this > message. > Is it no longer valid? The RFC Editor lists it as Proposed Standard status with no updates or obsoletes... seems to me that all this debate could be resolved by just putting a reference into the current draft to that and removing any conflicting text we have now. Personally, I don't agree that a DHCP server should be able to both deny my system an address and prevent me from allocating a LL address, and if building a product would likely just ignore the prohibition. If that increased the likelyhood that my product would work for some circumstances, I would happily trade that for not being able to claim perfect conformance. From owner-zeroconf@merit.edu Thu Jan 23 12:01:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13312 for ; Thu, 23 Jan 2003 12:01:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7F0C591225; Thu, 23 Jan 2003 12:04:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 530F09121F; Thu, 23 Jan 2003 12: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 3CE3D9140D for ; Thu, 23 Jan 2003 12:04:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 174335DE74; Thu, 23 Jan 2003 12:04:14 -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 CB39B5DDEF for ; Thu, 23 Jan 2003 12:04:13 -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 A397D59912 for ; Thu, 23 Jan 2003 17:04:16 +0000 (GMT) Message-ID: <011f01c2c301$74589060$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <3450D7C8-2E35-11D7-AFDA-00039317663C@nominum.com><18535.1043336087@munnari.OZ.AU><010301c2c2f6$42226950$131010ac@aldebaran> Subject: Re: Turning off link-locals? Date: Thu, 23 Jan 2003 17:04:13 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Scott Lawrence" > > Personally, I don't agree that a DHCP server should be able to both > deny my system an address and prevent me from allocating a LL address, > and if building a product would likely just ignore the prohibition. > If that increased the likelyhood that my product would work for some > circumstances, I would happily trade that for not being able to claim > perfect conformance. Of course a network administrator who wanted to deny access to your devices would have to go a lot further than simply turning on a DHCP option. However, it might be an indication that having got your IP anyway, you are likely to find it of very limited use. DHCP is generally your first point of contact with local network policy. I notice that section 2.2 of RFC2563 only _requires_ a client which is refused an IP to examine this option. However, a client granted an IP could also examine the option to see if it should get a LL address as well (although the only good argument I have seen here as to why a host with a global address should want both is one of continuity of existing connections). This RFC certainly looks very relevant to the IPv4LL draft which should probably reference it in some way. Philip From owner-zeroconf@merit.edu Thu Jan 23 12:02:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13358 for ; Thu, 23 Jan 2003 12:02:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 105169121F; Thu, 23 Jan 2003 12:06:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C3D2D9140B; Thu, 23 Jan 2003 12:06: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 9F8539121F for ; Thu, 23 Jan 2003 12:06:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8CC225DE74; Thu, 23 Jan 2003 12:06:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtp.covadmail.net (mx03.covadmail.net [63.65.120.63]) by segue.merit.edu (Postfix) with SMTP id 21AB95DE60 for ; Thu, 23 Jan 2003 12:06:04 -0500 (EST) Received: (covad.net 27814 invoked from network); 23 Jan 2003 17:06:03 -0000 Received: from unknown (HELO STUDY) (66.167.13.235) by sun-qmail15 with SMTP; 23 Jan 2003 17:06:03 -0000 To: Robert Elz Cc: "Zeroconf" Subject: Re: Turning off link-locals? References: <3450D7C8-2E35-11D7-AFDA-00039317663C@nominum.com> <18535.1043336087@munnari.OZ.AU> From: Scott Lawrence Date: 23 Jan 2003 12:08:08 -0500 In-Reply-To: <18535.1043336087@munnari.OZ.AU> Message-ID: Lines: 34 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-zeroconf@merit.edu Precedence: bulk Robert Elz writes: > Ted.Lemon@nominum.com said: > | This doesn't satisfy me because it requires that an arbitrary delay > | before I can use my zeroconf network. > > For zeroconf you have to have that, because of the spanning tree problem. > > If you go and assign yourself an address, you're quite likely going to > get a duplicate (sometimes anyway) and so cause problems to some other > innocent device, for no good reason at all (this is much more common than > the "two isolated halves of a link reconnecting" issue that can also cause > problems). You and I seem to have a very different notions of 'quite likely'. If I did my math right (probablility is not my strong suit - someone correct me please if I've gotten this wrong), there's slightly less than a 1% chance on a link with 50 nodes on it. So, given that: - Nodes on the same link off the ST bridge will detect collisions immediately, so that the above <1% is only a problem when there are 50 nodes on other links off the same ST bridge. - Collision detection will step in as soon as the bridge concatentates the links and fix this situation. I'll take my chances and make a better user experience by not waiting for a bridge that may not even be there. -- Scott Lawrence http://world.std.com/~lawrence/ From owner-zeroconf@merit.edu Thu Jan 23 13:37:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16085 for ; Thu, 23 Jan 2003 13:37:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3139491322; Thu, 23 Jan 2003 13:40:31 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA5DC9140B; Thu, 23 Jan 2003 13:40: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 F126891322 for ; Thu, 23 Jan 2003 13:40:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id D3F695DFD9; Thu, 23 Jan 2003 13:40:29 -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 5A7FF5DFD4 for ; Thu, 23 Jan 2003 13:40:29 -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 h0NIeSw11687 for ; Thu, 23 Jan 2003 10:40:28 -0800 (PST) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 23 Jan 2003 10:40:28 -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 h0NIeSs16842 for ; Thu, 23 Jan 2003 10:40:28 -0800 (PST) Date: Thu, 23 Jan 2003 10:40:15 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Joshua Graessley To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <1D058DD0-2F02-11D7-9D41-000393760260@apple.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, January 23, 2003, at 08:48 AM, Scott Lawrence wrote: > "Philip Nye" writes: > >> Digging around in DHCP I found RFC2563 which appears to give >> precisely this >> message. >> Is it no longer valid? > > The RFC Editor lists it as Proposed Standard status with no updates or > obsoletes... seems to me that all this debate could be resolved by > just putting a reference into the current draft to that and removing > any conflicting text we have now. > > Personally, I don't agree that a DHCP server should be able to both > deny my system an address and prevent me from allocating a LL address, > and if building a product would likely just ignore the prohibition. > If that increased the likelyhood that my product would work for some > circumstances, I would happily trade that for not being able to claim > perfect conformance. I agree whole heartedly with Scott. I think the idea that the mere existence of a DHCP server be a signal that IPv4LL should not be self assigned is a huge mistake. It would lead to things not working in cases where they otherwise could. I haven't seen a compelling argument for it. If the draft were changed to suggest such a ridiculous thing I would most certainly ignore that recommendation. -josh From owner-zeroconf@merit.edu Thu Jan 23 15:53:43 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19752 for ; Thu, 23 Jan 2003 15:53:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 66C629121C; Thu, 23 Jan 2003 15:57:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 349409140E; Thu, 23 Jan 2003 15:57: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 0A3CF9121C for ; Thu, 23 Jan 2003 15:57:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 377FE5E00E; Thu, 23 Jan 2003 15:56:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id F09825E010 for ; Thu, 23 Jan 2003 15:56:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id A050A14080; Thu, 23 Jan 2003 15:56:58 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 27979-04; Thu, 23 Jan 2003 15:56:58 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 0E2D113FC8; Thu, 23 Jan 2003 15:56:58 -0500 (EST) Date: Thu, 23 Jan 2003 15:56:57 -0500 From: Keith Moore To: Joshua Graessley Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030123155657.29803e49.moore@cs.utk.edu> In-Reply-To: <1D058DD0-2F02-11D7-9D41-000393760260@apple.com> References: <1D058DD0-2F02-11D7-9D41-000393760260@apple.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 119e0873b05f122a0b76f71bc8a39022f80a1571 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > Personally, I don't agree that a DHCP server should be able to both > > deny my system an address and prevent me from allocating a LL > > address, and if building a product would likely just ignore the > > prohibition. If that increased the likelyhood that my product would > > work for some circumstances, I would happily trade that for not > > being able to claim perfect conformance. > > I agree whole heartedly with Scott. I think the idea that the mere > existence of a DHCP server be a signal that IPv4LL should not be self > assigned is a huge mistake. It would lead to things not working in > cases where they otherwise could. I haven't seen a compelling argument > for it. If the draft were changed to suggest such a ridiculous thing I > would most certainly ignore that recommendation. what if there were a DHCP message that said "you don't have permission to talk to this network"? would you ignore that also? -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Thu Jan 23 16:01:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19948 for ; Thu, 23 Jan 2003 16:01:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DB4069140E; Thu, 23 Jan 2003 16:04:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A134C9120D; Thu, 23 Jan 2003 16:04: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 AD7719140F for ; Thu, 23 Jan 2003 16:04:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 825EB5DFE5; Thu, 23 Jan 2003 16:04:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtp.covadmail.net (mx03.covadmail.net [63.65.120.63]) by segue.merit.edu (Postfix) with SMTP id 138555DFE2 for ; Thu, 23 Jan 2003 16:04:09 -0500 (EST) Received: (covad.net 17525 invoked from network); 23 Jan 2003 21:04:08 -0000 Received: from unknown (HELO STUDY) (66.167.13.235) by sun-qmail16 with SMTP; 23 Jan 2003 21:04:08 -0000 To: Keith Moore Cc: Joshua Graessley , zeroconf@merit.edu Subject: Re: Turning off link-locals? References: <1D058DD0-2F02-11D7-9D41-000393760260@apple.com> <20030123155657.29803e49.moore@cs.utk.edu> From: Scott Lawrence Date: 23 Jan 2003 16:06:12 -0500 In-Reply-To: <20030123155657.29803e49.moore@cs.utk.edu> Message-ID: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-zeroconf@merit.edu Precedence: bulk Keith Moore writes: > what if there were a DHCP message that said "you don't have permission > to talk to this network"? would you ignore that also? Yes. As has been pointed out, such a message would be a perfect DOS tool, and since systems that don't know about it (including such common protocols as Netbios and Appletalk) will disregard it anyway, I don't think it would actually be valuable as a management tool. If a network owner really wants to control what packets are on the network, only monitors with alarms and filters can hope to work. -- Scott Lawrence http://world.std.com/~lawrence/ From owner-zeroconf@merit.edu Thu Jan 23 16:08:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20044 for ; Thu, 23 Jan 2003 16:08:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7312C9120D; Thu, 23 Jan 2003 16:12:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38CE99140F; Thu, 23 Jan 2003 16:12: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 3ACE79120D for ; Thu, 23 Jan 2003 16:11:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1612F5DFE9; Thu, 23 Jan 2003 16:11:59 -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 801A75DFD4 for ; Thu, 23 Jan 2003 16:11:58 -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 h0NLBvw20281 for ; Thu, 23 Jan 2003 13:11:57 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 23 Jan 2003 13:11:57 -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 h0NLBvf13139; Thu, 23 Jan 2003 13:11:57 -0800 (PST) Date: Thu, 23 Jan 2003 13:11:43 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Keith Moore From: Joshua Graessley In-Reply-To: <20030123155657.29803e49.moore@cs.utk.edu> Message-Id: <4618962C-2F17-11D7-8E70-000393760260@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, Jan 23, 2003, at 12:56 US/Pacific, Keith Moore wrote: > >>> Personally, I don't agree that a DHCP server should be able to both >>> deny my system an address and prevent me from allocating a LL >>> address, and if building a product would likely just ignore the >>> prohibition. If that increased the likelyhood that my product would >>> work for some circumstances, I would happily trade that for not >>> being able to claim perfect conformance. >> >> I agree whole heartedly with Scott. I think the idea that the mere >> existence of a DHCP server be a signal that IPv4LL should not be self >> assigned is a huge mistake. It would lead to things not working in >> cases where they otherwise could. I haven't seen a compelling argument >> for it. If the draft were changed to suggest such a ridiculous thing I >> would most certainly ignore that recommendation. > > what if there were a DHCP message that said "you don't have permission > to talk to this network"? would you ignore that also? There is no such DHCP message, and such a message seems like it's outside the scope of this working group. Off Topic: If there were such a message, and our customers were asking for support or it made sense to us, we would certainly consider supporting such a thing. I would hope the DHC working group wouldn't attempt to tackle such a thing. It seems ridiculous to assume that a malicious client wouldn't just ignore the message. -josh From owner-zeroconf@merit.edu Thu Jan 23 16:17:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20131 for ; Thu, 23 Jan 2003 16:17:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3CC109140F; Thu, 23 Jan 2003 16:20:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 083D391410; Thu, 23 Jan 2003 16:20: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 C142C9140F for ; Thu, 23 Jan 2003 16:20:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id A928C5DFE5; Thu, 23 Jan 2003 16:20:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 90B215DFAE for ; Thu, 23 Jan 2003 16:20:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 43A6E1407D; Thu, 23 Jan 2003 16:20:54 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 31649-01; Thu, 23 Jan 2003 16:20:53 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 6DD4B13FCF; Thu, 23 Jan 2003 16:20:53 -0500 (EST) Date: Thu, 23 Jan 2003 16:20:53 -0500 From: Keith Moore To: Scott Lawrence Cc: moore@cs.utk.edu, jgraessley@apple.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030123162053.743341ee.moore@cs.utk.edu> In-Reply-To: References: <1D058DD0-2F02-11D7-9D41-000393760260@apple.com> <20030123155657.29803e49.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: bd0b3249a08929717e640a4b99d4107789f4b30a Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 23 Jan 2003 16:06:12 -0500 Scott Lawrence wrote: > Keith Moore writes: > > > what if there were a DHCP message that said "you don't have > > permission to talk to this network"? would you ignore that also? > > Yes. As has been pointed out, such a message would be a perfect DOS > tool, and since systems that don't know about it (including such > common protocols as Netbios and Appletalk) will disregard it anyway, I > don't think it would actually be valuable as a management tool. So if you're walking through an unfamiliar building and you see a sign that says "NO TRESPASSING BEYOND THIS POINT", do you say to yourself "I must assume I'm not permitted beyond this point"? Or do you say to yourself "This sign is probably a forgery. I'll just keep going and see if something or somebody actually tries to stop me"? What about if you're writing the code in a TCP stack that deals with receipt of a SYN packet? Do you assume that it's probably legitimate and allocate a connection block, etc., or do you assume it's probably a DoS attack and ignore it? Yes, DoS attacks are possible, but what is your default assumption? Your code is not smarter than the network administrator. It is not more aware of network policy than the network. It should not be trying to second guess what the network is saying. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Thu Jan 23 16:18:58 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20145 for ; Thu, 23 Jan 2003 16:18:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9C05C91410; Thu, 23 Jan 2003 16:22:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6A04F91411; Thu, 23 Jan 2003 16:22: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 4958891410 for ; Thu, 23 Jan 2003 16:22:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F1D65DFEB; Thu, 23 Jan 2003 16:22:08 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 152195DFE9 for ; Thu, 23 Jan 2003 16:22:08 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id E26481407D; Thu, 23 Jan 2003 16:22:07 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 30966-09; Thu, 23 Jan 2003 16:22:07 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 1B1BA13FC8; Thu, 23 Jan 2003 16:22:07 -0500 (EST) Date: Thu, 23 Jan 2003 16:22:06 -0500 From: Keith Moore To: Joshua Graessley Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030123162206.4008631e.moore@cs.utk.edu> In-Reply-To: <4618962C-2F17-11D7-8E70-000393760260@apple.com> References: <20030123155657.29803e49.moore@cs.utk.edu> <4618962C-2F17-11D7-8E70-000393760260@apple.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: b48ffc0cf54482b386cb82099c2da14129d80765 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > what if there were a DHCP message that said "you don't have > > permission to talk to this network"? would you ignore that also? > > There is no such DHCP message, and such a message seems like it's > outside the scope of this working group. > > Off Topic: > If there were such a message, and our customers were asking for > support or it made sense to us, we would certainly consider supporting > such a thing. I would hope the DHC working group wouldn't attempt to > tackle such a thing. It seems ridiculous to assume that a malicious > client wouldn't just ignore the message. do you think the purpose of protocol messages is to communicate to malicious parties, or to communicate between cooperating parties ? -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Thu Jan 23 16:33:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20459 for ; Thu, 23 Jan 2003 16:33:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CC5D391209; Thu, 23 Jan 2003 16:36:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9632B91227; Thu, 23 Jan 2003 16:36: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 052C291209 for ; Thu, 23 Jan 2003 16:36:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id DEAC35DE98; Thu, 23 Jan 2003 16:36:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from DIN-SMTPOUT.dreamersi.net (din-smtpout.dreamersi.net [216.217.219.195]) by segue.merit.edu (Postfix) with ESMTP id 629F05DEB0 for ; Thu, 23 Jan 2003 16:36:36 -0500 (EST) Received: from ADAM3 ([216.137.29.184]) by DIN-SMTPOUT.dreamersi.net with Microsoft SMTPSVC(5.0.2195.5329); Thu, 23 Jan 2003 13:37:16 -0800 From: "Adam MacBeth" To: Subject: RE: Turning off link-locals? Date: Thu, 23 Jan 2003 13:36:35 -0800 Message-ID: <006701c2c327$810c6810$950aa8c0@oius.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 23 Jan 2003 21:37:16.0921 (UTC) FILETIME=[99AD5690:01C2C327] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > what if there were a DHCP message that said "you don't have permission > > to talk to this network"? would you ignore that also? > > Yes. As has been pointed out, such a message would be a perfect DOS > tool, and since systems that don't know about it (including such > common protocols as Netbios and Appletalk) will disregard it anyway, I > don't think it would actually be valuable as a management tool. > > If a network owner really wants to control what packets are on the > network, only monitors with alarms and filters can hope to work. > Exactly. It's equally futile to have a message telling manually configured hosts not to use a manually configured address. Maybe there's a reason such a message doesn't exist. I really can't see how this is any different from a LL address in terms of controlling its use. Can't I just plug in my laptop and manually configure an address? How can the network admin stop me from doing this? If I have physical access to the network, I have access to the local link at the very least. It's possible that rogue (or misconfigured) hosts with manually configured addresses could be detected and labeled as such based on their IP address, whereas hosts with LL addresses can't really be labeled as trusted, unless you want to use MAC address based access control. Is there any other difference? From owner-zeroconf@merit.edu Thu Jan 23 16:46:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21071 for ; Thu, 23 Jan 2003 16:46:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 08E1791227; Thu, 23 Jan 2003 16:49:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3E8691411; Thu, 23 Jan 2003 16:49: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 6603C91227 for ; Thu, 23 Jan 2003 16:49:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9A8295DFEB; Thu, 23 Jan 2003 16:49:27 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 196525DF67 for ; Thu, 23 Jan 2003 16:49:27 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0NLijP08208; Thu, 23 Jan 2003 15:44:48 -0600 (CST) Date: Thu, 23 Jan 2003 13:49:31 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Scott Lawrence , jgraessley@apple.com, zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030123162053.743341ee.moore@cs.utk.edu> Message-Id: <8DF9E5E0-2F1C-11D7-B72A-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > What about if you're writing the code in a TCP stack that deals with > receipt of a SYN packet? Do you assume that it's probably legitimate > and allocate a connection block, etc., or do you assume it's probably a > DoS attack and ignore it? Yes, DoS attacks are possible, but what is > your default assumption? > > Your code is not smarter than the network administrator. It is not > more > aware of network policy than the network. It should not be trying to > second guess what the network is saying. Actually, the NetBSD stack has code to detect SYN floods, and in fact does assume that when it receives a SYN, it's an attack. Only when it gets the ACK to its SYN+ACK does it actually instantiate a tcp control block to manage the connection. And it's careful about sequence numbers so that it's not easy to guess what the sequence number of its SYN+ACK will be. I think this code originally came from BSD/os (it's been long enough since I integrated it that I can't remember anymore). Linux probably has something similar. We are coming to the point where in most cases the code has better heuristics than the network administrator, not so much because the code is really great, but because the lowest common denominator in system adminstration isn't very high (by which I do not mean to cast aspersions on sysadmins who are reading this - if you are reading this, you aren't part of the LCD). From owner-zeroconf@merit.edu Thu Jan 23 16:47:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21127 for ; Thu, 23 Jan 2003 16:47:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 748FE91411; Thu, 23 Jan 2003 16:50:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C78A91412; Thu, 23 Jan 2003 16:50: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 C0BC991411 for ; Thu, 23 Jan 2003 16:50:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id A2F735DFEB; Thu, 23 Jan 2003 16:50:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 81A635DF67 for ; Thu, 23 Jan 2003 16:50:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 531D11407D; Thu, 23 Jan 2003 16:50:34 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 02701-07; Thu, 23 Jan 2003 16:50:33 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id B3C1A13FCF; Thu, 23 Jan 2003 16:50:33 -0500 (EST) Date: Thu, 23 Jan 2003 16:50:33 -0500 From: Keith Moore To: "Adam MacBeth" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030123165033.05c68f32.moore@cs.utk.edu> In-Reply-To: <006701c2c327$810c6810$950aa8c0@oius.com> References: <006701c2c327$810c6810$950aa8c0@oius.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 17990b7a09c4ae1173301ae0bbcdbdcebf4e857b Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Can't I just plug in my laptop and manually configure an address? if a human user manually does something on a network without permission, presumably that's a conscious action on his part and he can accept responsibility for it. otoh, if a specification or code writer breaks the network's rules without the user doing anything to cause that, who is responsible then? bottom line is network operators have reasons to restrict access to their networks. this group has no business trying to insist that they have no right to do so, or that the mechanisms they are currently using to do so are not valid. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Thu Jan 23 16:52:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21271 for ; Thu, 23 Jan 2003 16:52:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E078491412; Thu, 23 Jan 2003 16:55:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A867891413; Thu, 23 Jan 2003 16:55: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 6D58291412 for ; Thu, 23 Jan 2003 16:55:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 46CAC5DFF2; Thu, 23 Jan 2003 16:55:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 2E2595DFEF for ; Thu, 23 Jan 2003 16:55:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 047C813FCF; Thu, 23 Jan 2003 16:55:22 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 02989-09; Thu, 23 Jan 2003 16:55:21 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 616B613FC8; Thu, 23 Jan 2003 16:55:21 -0500 (EST) Date: Thu, 23 Jan 2003 16:55:21 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, lawrence@world.std.com, jgraessley@apple.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030123165521.24a9130c.moore@cs.utk.edu> In-Reply-To: <8DF9E5E0-2F1C-11D7-B72A-00039317663C@nominum.com> References: <20030123162053.743341ee.moore@cs.utk.edu> <8DF9E5E0-2F1C-11D7-B72A-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: fab631effb7ae48e7acdaded54cb31125f3a0584 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Actually, the NetBSD stack has code to detect SYN floods, and in fact > does assume that when it receives a SYN, it's an attack. Only when > it gets the ACK to its SYN+ACK does it actually instantiate a tcp > control block to manage the connection. And it's careful about > sequence numbers so that it's not easy to guess what the sequence > number of its SYN+ACK will be. well, if you can write code so that a device that gets a DHCP response does the right thing no matter whether the DHCP message is legitimate or a forgery, my hat's off to you. but I don't buy the idea that the host has a right to run LL whether the network wants it to or not. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Thu Jan 23 16:52:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21294 for ; Thu, 23 Jan 2003 16:52:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1530391413; Thu, 23 Jan 2003 16:56:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D34C091414; Thu, 23 Jan 2003 16:56: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 CAFB991413 for ; Thu, 23 Jan 2003 16:56:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id B25DB5DFF7; Thu, 23 Jan 2003 16:56:02 -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 636E15DFF2 for ; Thu, 23 Jan 2003 16:56:02 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0NLpSP08244; Thu, 23 Jan 2003 15:51:28 -0600 (CST) Date: Thu, 23 Jan 2003 13:56:16 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Zeroconf To: Joshua Graessley From: Ted Lemon In-Reply-To: <1D058DD0-2F02-11D7-9D41-000393760260@apple.com> Message-Id: <7F3A0518-2F1D-11D7-B72A-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I agree whole heartedly with Scott. I think the idea that the mere > existence of a DHCP server be a signal that IPv4LL should not be self > assigned is a huge mistake. It would lead to things not working in > cases where they otherwise could. I haven't seen a compelling argument > for it. If the draft were changed to suggest such a ridiculous thing I > would most certainly ignore that recommendation. There's a problem in the draft, which I've mentioned several times here, but which nobody has commented on (this is from section 2.6): If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), the host SHOULD use its link- local source address, if it has one. If the host does not have a link-local source address, then it MAY choose to ARP for the destination address and then send its packet, with a routable source IP address and a link-local destination IP address, directly to its destination on the same physical link. The host MUST NOT send the packet to any router for forwarding. If this MAY were a MUST, your complaint would not be valid. That is, if this MAY were a MUST, we could be sure that all IPv4ll-aware stacks would be able to interoperate with all other IPv4ll stacks on the same wire, regardless of whether any given stack was configured with a non-IPv4ll IP address. Because this is a MAY, your objection is valid. That is, because this says "MAY", you are right that things may not work in the case where one stack is configured with a non-IPv4ll address and the other is not. It depends on whether or not the implementor decides to implement this optional functionality. From owner-zeroconf@merit.edu Thu Jan 23 17:00:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21467 for ; Thu, 23 Jan 2003 17:00:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4F17A91416; Thu, 23 Jan 2003 17:04:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0405991414; Thu, 23 Jan 2003 17:04: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 4815991416 for ; Thu, 23 Jan 2003 17:03:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A3935DF00; Thu, 23 Jan 2003 17:03:16 -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 CFF855DEE9 for ; Thu, 23 Jan 2003 17:03:15 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0NLwgP08298; Thu, 23 Jan 2003 15:58:42 -0600 (CST) Date: Thu, 23 Jan 2003 14:03:30 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Zeroconf" To: Robert Elz From: Ted Lemon In-Reply-To: <18535.1043336087@munnari.OZ.AU> Message-Id: <81BA292B-2F1E-11D7-B72A-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > | In order for mDNS to be really useful, gethostbyname("foo.local.") > has > | to work. So unfortunately your reasoning here doesn't work. > > Of course, but I think you missed my point. If mDNS is used, the host > owning the name supplies the address to be used - if it has a non-LL > address, it should just supply that one - we don't need to have > gethostbyname() > do some rule based algorithm to handle things. Does the mDNS spec say that this is what should happen? Does the IPv4ll spec say it? :'} From owner-zeroconf@merit.edu Thu Jan 23 17:01:04 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21489 for ; Thu, 23 Jan 2003 17:01:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9A9BC9120E; Thu, 23 Jan 2003 17:04:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E893091417; Thu, 23 Jan 2003 17:03: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 0FEC491414 for ; Thu, 23 Jan 2003 17:02:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA28D5DF1D; Thu, 23 Jan 2003 17:02:07 -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 8BF005DF00 for ; Thu, 23 Jan 2003 17:02:07 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0NLswP08287; Thu, 23 Jan 2003 15:54:58 -0600 (CST) Date: Thu, 23 Jan 2003 13:59:46 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Robert Elz" , "Zeroconf" To: "Philip Nye" From: Ted Lemon In-Reply-To: <010301c2c2f6$42226950$131010ac@aldebaran> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Digging around in DHCP I found RFC2563 which appears to give precisely > this > message. > Is it no longer valid? It passed through the DHC working group a few years ago, but AFAIK nobody implemented it, and it's not referenced by anything. Last time it was discussed in the DHC working group, nobody was willing to defend its existence anymore. It should probably be declared obsolete. From owner-zeroconf@merit.edu Thu Jan 23 17:06:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21602 for ; Thu, 23 Jan 2003 17:06:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6B97791414; Thu, 23 Jan 2003 17:09:28 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3187B91415; Thu, 23 Jan 2003 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 0ECF591414 for ; Thu, 23 Jan 2003 17:09:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id E90475DF5D; Thu, 23 Jan 2003 17:09:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id D00575DF1D for ; Thu, 23 Jan 2003 17:09:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id A1F5113FCF; Thu, 23 Jan 2003 17:09:26 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 05511-04; Thu, 23 Jan 2003 17:09:26 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 0E0CE13FC8; Thu, 23 Jan 2003 17:09:26 -0500 (EST) Date: Thu, 23 Jan 2003 17:09:25 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, jgraessley@apple.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030123170925.057f5f5a.moore@cs.utk.edu> In-Reply-To: <7F3A0518-2F1D-11D7-B72A-00039317663C@nominum.com> References: <1D058DD0-2F02-11D7-9D41-000393760260@apple.com> <7F3A0518-2F1D-11D7-B72A-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 9b0b421ba8373494376bdad21361372d558e04e0 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > There's a problem in the draft, which I've mentioned several times > here, but which nobody has commented on (this is from section 2.6): > > If the destination address is in the 169.254/16 prefix (including > the 169.254.255.255 broadcast address), the host SHOULD use its > link- local source address, if it has one. If the host does not > have a link-local source address, then it MAY choose to ARP for > the destination address and then send its packet, with a routable > source IP address and a link-local destination IP address, > directly to its destination on the same physical link. The host > MUST NOT send the packet to any router for forwarding. > > If this MAY were a MUST, your complaint would not be valid. That is, > if this MAY were a MUST, we could be sure that all IPv4ll-aware stacks > would be able to interoperate with all other IPv4ll stacks on the same > wire, regardless of whether any given stack was configured with a > non-IPv4ll IP address. Because this is a MAY, your objection is > valid. mumble. it shouldn't be expressed in MUST terms, because the protocol for normal routing of packets to destinations isn't expressed in MUST terms either. instead of MAY or MUST, say something like: the way a host with a routable address sends a packet to an LL address on a link is to ARP for that packet as if the destination address were local to that link, determine the MAC address for that packet, and then forward the IP packet to that MAC address. -- I tried enlightenment but it kept crashing. From owner-zeroconf@merit.edu Thu Jan 23 17:15:54 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21796 for ; Thu, 23 Jan 2003 17:15:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C46DF91418; Thu, 23 Jan 2003 17:19:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF88891415; Thu, 23 Jan 2003 17: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 6483991418 for ; Thu, 23 Jan 2003 17:18:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A1835DFEB; Thu, 23 Jan 2003 17:18:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id ED89B5DF9F for ; Thu, 23 Jan 2003 17:18:56 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0NMEKP08464; Thu, 23 Jan 2003 16:14:20 -0600 (CST) Date: Thu, 23 Jan 2003 14:19:08 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: jgraessley@apple.com, zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030123170925.057f5f5a.moore@cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > mumble. it shouldn't be expressed in MUST terms, because the protocol > for normal routing of packets to destinations isn't expressed in MUST > terms either. > > instead of MAY or MUST, say something like: > > the way a host with a routable address sends a packet to an LL address > on a link is to ARP for that packet as if the destination address were > local to that link, determine the MAC address for that packet, and then > forward the IP packet to that MAC address. Right, fair enough. From owner-zeroconf@merit.edu Thu Jan 23 17:19:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21828 for ; Thu, 23 Jan 2003 17:19:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B427091415; Thu, 23 Jan 2003 17:22:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B94891419; Thu, 23 Jan 2003 17:22: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 3AE0A91415 for ; Thu, 23 Jan 2003 17:22:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 21F075DF5D; Thu, 23 Jan 2003 17:22:29 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 871585DF36 for ; Thu, 23 Jan 2003 17:22:28 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0NMHsP08478; Thu, 23 Jan 2003 16:17:54 -0600 (CST) Date: Thu, 23 Jan 2003 14:22:42 -0800 Subject: Re: LL-only devices [was Re: Turning off link-locals?] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Zeroconf To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20030122220931.03eb71d0@funnel.cisco.com> Message-Id: <308FC972-2F21-11D7-B72A-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Seems to me LLv4 is a short-term solution that will not serve in the > long run - assuming the long run is homes, offices and other sites > with multiple links connected by routers. In fact, LLv4 might turn > out to be an obstacle to progress, as it might encourage bridging or > some other way of flattening networks for LLv4. I can imagine a > future in which LLv4 addresses are bridged across an entire site - to > allow use of LLv4-only devices across the entire site - while non-LLv4 > addresses are routed in the familiar way. This seems like an argument against llv4-only, not against llv4. From owner-zeroconf@merit.edu Thu Jan 23 17:49:48 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22864 for ; Thu, 23 Jan 2003 17:49:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 311E891228; Thu, 23 Jan 2003 17:53:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EEF909141A; Thu, 23 Jan 2003 17:53: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 95B0191228 for ; Thu, 23 Jan 2003 17:53:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 852DF5DFBC; Thu, 23 Jan 2003 17:53:06 -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 1B7F15DE09 for ; Thu, 23 Jan 2003 17:53:06 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA02867 for ; Thu, 23 Jan 2003 17:53:05 -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 RAA24793 for ; Thu, 23 Jan 2003 17:53:05 -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 RAA19387 for ; Thu, 23 Jan 2003 17:53:04 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 23 Jan 2003 17:53:03 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <8DF9E5E0-2F1C-11D7-B72A-00039317663C@nominum.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 01/23/2003 16:49, "Ted Lemon" wrote: > We are coming to the point where in most cases the code has better > heuristics than the network administrator, not so much because the code > is really great, but because the lowest common denominator in system > adminstration isn't very high (by which I do not mean to cast > aspersions on sysadmins who are reading this - if you are reading this, > you aren't part of the LCD). Most sysadmins, YT included, welcome smarter code. We just really want an 'on/off' switch for it 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 Thu Jan 23 17:53:01 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22999 for ; Thu, 23 Jan 2003 17:53:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9FAE69141A; Thu, 23 Jan 2003 17:56:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6FB509141B; Thu, 23 Jan 2003 17:56: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 5318D9141A for ; Thu, 23 Jan 2003 17:56:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2E8235DFBC; Thu, 23 Jan 2003 17:56:20 -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 B79DD5DE09 for ; Thu, 23 Jan 2003 17:56:19 -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 RAA08091 for ; Thu, 23 Jan 2003 17:56:18 -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 RAA17950 for ; Thu, 23 Jan 2003 17:56:18 -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 RAA20274 for ; Thu, 23 Jan 2003 17:56:18 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 23 Jan 2003 17:56:16 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030123165521.24a9130c.moore@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 01/23/2003 16:55, "Keith Moore" wrote: > well, if you can write code so that a device that gets a DHCP response > does the right thing no matter whether the DHCP message is legitimate or > a forgery, my hat's off to you. > > but I don't buy the idea that the host has a right to run LL whether the > network wants it to or not. Well, to be precise, the network can't want anything. The network admin does. And if the network admin wants v4LL off, then it should be off, *regardless* of the alternate config method. By the same token, if they want it on, then it should be on, *regardless* of the alternate config method. If the admin wants it on, then DHCP shouldn't be able to override this, because no on here knows everything about every network need until the end of v4. In either case, the DHCP switch doesn't fully meet either need. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Jan 23 18:17:46 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23903 for ; Thu, 23 Jan 2003 18:17:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 176FE91223; Thu, 23 Jan 2003 18:20:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D91449141C; Thu, 23 Jan 2003 18:20: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 7BFD491223 for ; Thu, 23 Jan 2003 18:20:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5ED425DF3A; Thu, 23 Jan 2003 18:20:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by segue.merit.edu (Postfix) with ESMTP id DF9025DF36 for ; Thu, 23 Jan 2003 18:20:54 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NNLZwx026797 for ; Thu, 23 Jan 2003 18:21:36 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-349.cisco.com [10.82.225.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA23446 for ; Thu, 23 Jan 2003 18:20:41 -0500 (EST) Message-Id: <4.3.2.7.2.20030123181824.039bef58@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 18:18:43 -0500 To: "Zeroconf" From: Ralph Droms Subject: Re: Turning off link-locals? In-Reply-To: References: <010301c2c2f6$42226950$131010ac@aldebaran> <3450D7C8-2E35-11D7-AFDA-00039317663C@nominum.com> <18535.1043336087@munnari.OZ.AU> <010301c2c2f6$42226950$131010ac@aldebaran> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Check out draft-droms-rfc2563-deprecate-00.txt - Ralph At 11:48 AM 1/23/2003 -0500, Scott Lawrence wrote: >"Philip Nye" writes: > > > Digging around in DHCP I found RFC2563 which appears to give precisely this > > message. > > Is it no longer valid? > >The RFC Editor lists it as Proposed Standard status with no updates or >obsoletes... seems to me that all this debate could be resolved by >just putting a reference into the current draft to that and removing >any conflicting text we have now. > >Personally, I don't agree that a DHCP server should be able to both >deny my system an address and prevent me from allocating a LL address, >and if building a product would likely just ignore the prohibition. >If that increased the likelyhood that my product would work for some >circumstances, I would happily trade that for not being able to claim >perfect conformance. From owner-zeroconf@merit.edu Thu Jan 23 18:26:27 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24149 for ; Thu, 23 Jan 2003 18:26:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6822891420; Thu, 23 Jan 2003 18:27:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D18B9141D; Thu, 23 Jan 2003 18:27: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 EF48691420 for ; Thu, 23 Jan 2003 18:27:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id CD2A05DE39; Thu, 23 Jan 2003 18:27:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by segue.merit.edu (Postfix) with ESMTP id 5F1FA5DEF4 for ; Thu, 23 Jan 2003 18:27:15 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NNS1MW027487 for ; Thu, 23 Jan 2003 18:28:02 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-349.cisco.com [10.82.225.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA23806 for ; Thu, 23 Jan 2003 18:27:13 -0500 (EST) Message-Id: <4.3.2.7.2.20030123182132.03a5e958@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 18:22:27 -0500 To: Zeroconf From: Ralph Droms Subject: Re: LL-only devices [was Re: Turning off link-locals?] In-Reply-To: <308FC972-2F21-11D7-B72A-00039317663C@nominum.com> References: <4.3.2.7.2.20030122220931.03eb71d0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Ted, Yeah, I can understand your logic. Will all vendors and customers all understand and believe the same logic? - Ralph At 02:22 PM 1/23/2003 -0800, Ted Lemon wrote: >>Seems to me LLv4 is a short-term solution that will not serve in the long >>run - assuming the long run is homes, offices and other sites with >>multiple links connected by routers. In fact, LLv4 might turn out to be >>an obstacle to progress, as it might encourage bridging or some other way >>of flattening networks for LLv4. I can imagine a future in which LLv4 >>addresses are bridged across an entire site - to allow use of LLv4-only >>devices across the entire site - while non-LLv4 addresses are routed in >>the familiar way. > >This seems like an argument against llv4-only, not against llv4. > From owner-zeroconf@merit.edu Thu Jan 23 18:26:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24164 for ; Thu, 23 Jan 2003 18:26:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2A9AA9141D; Thu, 23 Jan 2003 18:28:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2A4A91428; Thu, 23 Jan 2003 18:28: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 E94069141D for ; Thu, 23 Jan 2003 18:28:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id D7FF95DEF4; Thu, 23 Jan 2003 18:28:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by segue.merit.edu (Postfix) with ESMTP id 4736A5DE39 for ; Thu, 23 Jan 2003 18:28:32 -0500 (EST) Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h0NNSVFF009369 for ; Thu, 23 Jan 2003 15:28:31 -0800 (PST) Message-Id: <200301232328.h0NNSVFF009369@smtpout.mac.com> Received: from [192.168.0.119] ([12.232.144.158]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id H96X7I00.2GL for ; Thu, 23 Jan 2003 15:28:30 -0800 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Thu, 23 Jan 2003 13:54:59 -0800 Subject: Re: WG decision: when to configure LL addrs From: Alf Watt To: Thomas Narten In-Reply-To: <200301221450.h0MEo2l11224@cichlid.adsl.duke.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 Thanks, Thomas, for the consensus call. 1) not my first choice, but I can live with it. I tend to agree with Subrata Goswami that 2,3,4,5 are restrictive and confusing. Aidan's suggestion that they be the least preferred address on the link seems like the right text for the standard. Best, Alf On 1/22/03 6:50 AM, "Thomas Narten" wrote: > Folks, > > This WG needs to declare consensus on some basic issues, or it will > never get done. > > The note below from Keith summarizes what I see a lot of other folk > seeming to agree with. > > So, I would like to ask the WG to answer the following questions: > > 1) Should the ID recommend that LL addresses only be configured as per > below. Please answer clearly, along the lines of > > a) yes, I think this is what the document should say (maybe with > some small tweaks, which then need to be explained) > > b) no, this is a showstopper for me (and explain why, so the rest > of the WG can understand and then agree or disagree with your > position) > > c) Not my first choice, but I can live with it. > > Note that two things need to happen. First, get general agreement on > the direction, second, agreement on the exact text to go in the > document. > > It would be helpful if folk would post their views (including lurkers) > but also to restrict themselves to answering the above questions. If > only a small number of the usual suspects post, we will risk not have > enough input to make a clear consensus call. Thus, everyone who cares > should speak up. > > Thomas > > Keith Moore writes: > >> On Wed, 22 Jan 2003 10:01:30 +1000 (EST) >> Ian Lister wrote: > >>> On Tue, 21 Jan 2003, Philip Nye wrote: >>>> Joshua, >>>> >>>>> This problem is not as significant as it may seem. If IPv4LLs are only >>>>> acquired on an interface when no global address can be (no DHCP, manual >>>>> config, or other config method), the device will be unable to >>>>> communicate with anything off of the local link through that interface. >>>> >>>> Your analysis is reasonable - but it is rather off the track because the >>>> current draft recommends that IPv4LL be turned on even when a global >>>> address >>>> IS found - and this is the source of the problems. >>> >>> It is not off track if the draft is amended to specify the behaviour >>> Joshua described (which is currently implemented in Mac OS and IMO is the >>> most appropriate behaviour). With that behaviour IPv4LL is used only where >>> there is no alternative, so there can be no accusations of breakage. Is >>> there anybody who actually wants to argue against this? > >> now I'm losing track of what is meant by "used" - > >> - when should an IPv4LL address be configured by a host? > >> suggest: if the host is explicitly configured to do so, OR >> if the host has attempted and failed to acquire a routable address via DHCP > >> (alternative: provide a lighter weight mechanism by which a host can >> acquire a >> routable address, netmask, and default route, in response to its attempt >> to claim >> an IPv4LL address) > >> - when should an IPv4LL address be used by a host as a source address? > >> suggest: when the only addresses available to the host are IPv4LL >> addresses, OR >> when the application has explicitly specified the source address to use, OR >> when the application has explicitly specified the interface to use and the >> IPv4LL address >> is the only address associated with that interface. > >> - when should a host honor an attempt to connect to an IPv4LL address that >> was once >> configured by that host? > >> suggest: anytime the address is still valid (e.g. there have been no >> conflicting claims) >> and there is a process listening for connections either specifically to >> that address or >> for incoming connections at any of the host's addresses. > >> - when should an application attempt to connect to a IPv4LL address? > >> suggest: only when the address is literally specified, or if there are no >> other routable >> addresses for the destination host known to the application. > >> - when should an application send an IPv4LL address in a referral to another >> host? > >> suggest: only when there are no routable addresses for the destination host >> known to the >> application. even then, care needs to be taken that a host reached at a >> particular >> IPv4LL address is really the one intended - since IPv4LL addresses can be >> reassigned >> without notice and/or reused on different network segments. From owner-zeroconf@merit.edu Thu Jan 23 18:26:33 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24177 for ; Thu, 23 Jan 2003 18:26:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 09CE191422; Thu, 23 Jan 2003 18:29:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C685891423; Thu, 23 Jan 2003 18:29: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 0150B91422 for ; Thu, 23 Jan 2003 18:29:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id E32BF5DEF4; Thu, 23 Jan 2003 18:29:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by segue.merit.edu (Postfix) with ESMTP id C2DF65DE39 for ; Thu, 23 Jan 2003 18:29:49 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bqn4-0001KQ-00; Thu, 23 Jan 2003 15:29:46 -0800 Date: Thu, 23 Jan 2003 18:28:13 -0500 From: Keith Moore To: "John C. Welch" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030123182813.2f57dffe.moore@cs.utk.edu> In-Reply-To: References: <20030123165521.24a9130c.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > By the same token, if they want it on, then it should be on, *regardless* of > the alternate config method. If the admin wants it on, then DHCP shouldn't > be able to override this, because no on here knows everything about every > network need until the end of v4. I find myself imagining that in the DHC working group someone is saying about now "if the admin wants to use DHCP to specify whether and how the network is to be used by a host, then LL shouldn't be able to override this..." From owner-zeroconf@merit.edu Thu Jan 23 18:31:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24316 for ; Thu, 23 Jan 2003 18:31:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9C49E9141E; Thu, 23 Jan 2003 18:34:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E6FE91421; Thu, 23 Jan 2003 18:34: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 5EDD69141E for ; Thu, 23 Jan 2003 18:33:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 21E0A5DF5D; Thu, 23 Jan 2003 18:33:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62]) by segue.merit.edu (Postfix) with ESMTP id 3573C5DEF4 for ; Thu, 23 Jan 2003 18:32:57 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bqq5-0006Sc-00; Thu, 23 Jan 2003 15:32:53 -0800 Date: Thu, 23 Jan 2003 18:31:19 -0500 From: Keith Moore To: Ralph Droms Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030123183119.3504487c.moore@cs.utk.edu> In-Reply-To: <4.3.2.7.2.20030123181824.039bef58@funnel.cisco.com> References: <010301c2c2f6$42226950$131010ac@aldebaran> <3450D7C8-2E35-11D7-AFDA-00039317663C@nominum.com> <18535.1043336087@munnari.OZ.AU> <010301c2c2f6$42226950$131010ac@aldebaran> <4.3.2.7.2.20030123181824.039bef58@funnel.cisco.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > draft-droms-rfc2563-deprecate-00.txt I don't follow the argument in the draft. How is this attack different than any other DoS attack mounted by supplying false information via DHCP, for instance, by supplying bogus addresses or too-short lease times or whatever? If the logic in this document were followed, shouldn't DHCP itself be deprecated? From owner-zeroconf@merit.edu Thu Jan 23 18:36:52 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24409 for ; Thu, 23 Jan 2003 18:36:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 90A6891421; Thu, 23 Jan 2003 18:40:10 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5EADA91423; Thu, 23 Jan 2003 18: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 5C6FB91421 for ; Thu, 23 Jan 2003 18:40:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F8F25DFBC; Thu, 23 Jan 2003 18:40:09 -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 B6FBE5DF80 for ; Thu, 23 Jan 2003 18:40:08 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0NNZWP08912; Thu, 23 Jan 2003 17:35:34 -0600 (CST) Date: Thu, 23 Jan 2003 15:40:19 -0800 Subject: Re: LL-only devices [was Re: Turning off link-locals?] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Zeroconf To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20030123182132.03a5e958@funnel.cisco.com> Message-Id: <0820F1C3-2F2C-11D7-B72A-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Yeah, I can understand your logic. Will all vendors and customers all > understand and believe the same logic? Possibly not. The question is, are you proposing that ipv4ll be killed to avoid this, or that language be added to the draft to recommend against ipv4ll-only devices? TBH, given the way people use networks now, and uses that I can anticipate, I really don't see this being a big problem - at this point I think that the ability to have global IP addresses is sufficiently important to the average computer user that ipv4ll will, in practice, wind up being used exactly as I think this wg intends. I think it's very unlikely that we're going to see a proliferation of ipv4ll-only devices with which one could meaningfully communicate outside of a very small area. E.g., you might see an ipv4ll-only iPod, but you're not going to see an ipv4ll-only printer, and you're definitely not going to see an ipv4ll-only desktop or laptop computer. From owner-zeroconf@merit.edu Thu Jan 23 18:39:21 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24432 for ; Thu, 23 Jan 2003 18:39:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C6F2291423; Thu, 23 Jan 2003 18:42:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8EE2D91424; Thu, 23 Jan 2003 18:42: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 526E991423 for ; Thu, 23 Jan 2003 18:42:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 11FF45DF80; Thu, 23 Jan 2003 18:42:37 -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 B2FA05DF5D for ; Thu, 23 Jan 2003 18:42:36 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0NNc2P08928; Thu, 23 Jan 2003 17:38:02 -0600 (CST) Date: Thu, 23 Jan 2003 15:42:51 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030123182813.2f57dffe.moore@cs.utk.edu> Message-Id: <62FB5087-2F2C-11D7-B72A-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I find myself imagining that in the DHC working group someone is > saying about > now "if the admin wants to use DHCP to specify whether and how the > network is > to be used by a host, then LL shouldn't be able to override this..." Nope, the folks in the DHCwg are probably just relieved that this discussion isn't going on on that mailing list. The mailing list has been quiet the last few days as all the email<->brain bandwidth of the several of the more frequent contributors has been consumed by the zeroconf mailing list. From owner-zeroconf@merit.edu Thu Jan 23 18:50:24 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24649 for ; Thu, 23 Jan 2003 18:50:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 533AC91424; Thu, 23 Jan 2003 18:53:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2141591425; Thu, 23 Jan 2003 18:53: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 F0A2B91424 for ; Thu, 23 Jan 2003 18:53:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id CDD2E5DF5D; Thu, 23 Jan 2003 18:53:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by segue.merit.edu (Postfix) with ESMTP id 4BEDB5DF3A for ; Thu, 23 Jan 2003 18:53:42 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0NNsS8M000247 for ; Thu, 23 Jan 2003 18:54:28 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-349.cisco.com [10.82.225.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA25270 for ; Thu, 23 Jan 2003 18:53:39 -0500 (EST) Message-Id: <4.3.2.7.2.20030123184917.0398ddc0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 18:53:34 -0500 To: zeroconf@merit.edu From: Ralph Droms Subject: Re: Turning off link-locals? In-Reply-To: <62FB5087-2F2C-11D7-B72A-00039317663C@nominum.com> References: <20030123182813.2f57dffe.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk And some of the other regular contributors have been consumed by DHCPv6 testing at TAHI... Ted, I came *this close* to cross-posting the discussion about draft-droms-rfc2563-deprecate-00.txt to the dhcwg list. Perhaps what I'll do is point out to the dhcwg list that this discussion is taking place on zeroconf and that folks who are interested might want to join in. - Ralph At 03:42 PM 1/23/2003 -0800, Ted Lemon wrote: >>I find myself imagining that in the DHC working group someone is saying about >>now "if the admin wants to use DHCP to specify whether and how the network is >>to be used by a host, then LL shouldn't be able to override this..." > >Nope, the folks in the DHCwg are probably just relieved that this >discussion isn't going on on that mailing list. The mailing list has >been quiet the last few days as all the email<->brain bandwidth of the >several of the more frequent contributors has been consumed by the >zeroconf mailing list. > From owner-zeroconf@merit.edu Thu Jan 23 18:58:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24826 for ; Thu, 23 Jan 2003 18:58:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 688A191425; Thu, 23 Jan 2003 19:01:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E70C91426; Thu, 23 Jan 2003 19:01: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 A32BA91425 for ; Thu, 23 Jan 2003 19:01:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id CBD2B5DFF2; Thu, 23 Jan 2003 19:01:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by segue.merit.edu (Postfix) with ESMTP id 4C62A5DFB0 for ; Thu, 23 Jan 2003 19:01:15 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0O021ts001057; Thu, 23 Jan 2003 19:02:01 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-349.cisco.com [10.82.225.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA25582; Thu, 23 Jan 2003 19:01:11 -0500 (EST) Message-Id: <4.3.2.7.2.20030123184246.039a0400@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 19:01:07 -0500 To: Ted Lemon From: Ralph Droms Subject: Re: LL-only devices [was Re: Turning off link-locals?] Cc: Zeroconf In-Reply-To: <0820F1C3-2F2C-11D7-B72A-00039317663C@nominum.com> References: <4.3.2.7.2.20030123182132.03a5e958@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I actually wasn't proposing any particular course of action, just thinking ahead a little to where LLv4 might lead. What started off my speculation was the observation that single-link networks are a pretty limited special case. In reality, just how useful is the ability to set up single-link networks, how often will single-link networks really stay isolated from other networks and how can participants in a single-link network operate continue to operate reliably in the case that the single-link network joins a larger network. Another thing that concerns me is the amount of time I've spent trying to figure out what's going on when my computer has silently used a 192.168.0.0 address in a situation where I expected to be connected to a multi-link network. Perhaps that problem will be solved by the "odn't-ever-use-LLv4" switch? Will that switch fix the problem for un-knowlegdeable users? - Ralph At 03:40 PM 1/23/2003 -0800, Ted Lemon wrote: >>Yeah, I can understand your logic. Will all vendors and customers all >>understand and believe the same logic? > >Possibly not. The question is, are you proposing that ipv4ll be killed >to avoid this, or that language be added to the draft to recommend against >ipv4ll-only devices? > >TBH, given the way people use networks now, and uses that I can >anticipate, I really don't see this being a big problem - at this point I >think that the ability to have global IP addresses is sufficiently >important to the average computer user that ipv4ll will, in practice, wind >up being used exactly as I think this wg intends. I think it's very >unlikely that we're going to see a proliferation of ipv4ll-only devices >with which one could meaningfully communicate outside of a very small >area. E.g., you might see an ipv4ll-only iPod, but you're not going to >see an ipv4ll-only printer, and you're definitely not going to see an >ipv4ll-only desktop or laptop computer. > From owner-zeroconf@merit.edu Thu Jan 23 19:06:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25012 for ; Thu, 23 Jan 2003 19:06:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0164F9122A; Thu, 23 Jan 2003 19:09:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C35A491426; Thu, 23 Jan 2003 19:09: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 AAFEB9122A for ; Thu, 23 Jan 2003 19:09:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 88DD45DFB0; Thu, 23 Jan 2003 19:09:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by segue.merit.edu (Postfix) with ESMTP id 083F75DF5D for ; Thu, 23 Jan 2003 19:09:54 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0O0AZ51001720 for ; Thu, 23 Jan 2003 19:10:36 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-349.cisco.com [10.82.225.93]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA26039 for ; Thu, 23 Jan 2003 19:09:46 -0500 (EST) Message-Id: <4.3.2.7.2.20030123184057.03a69f38@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Jan 2003 19:09:42 -0500 To: zeroconf@merit.edu From: Ralph Droms Subject: Re: Turning off link-locals? In-Reply-To: <20030123183119.3504487c.moore@cs.utk.edu> References: <4.3.2.7.2.20030123181824.039bef58@funnel.cisco.com> <010301c2c2f6$42226950$131010ac@aldebaran> <3450D7C8-2E35-11D7-AFDA-00039317663C@nominum.com> <18535.1043336087@munnari.OZ.AU> <010301c2c2f6$42226950$131010ac@aldebaran> <4.3.2.7.2.20030123181824.039bef58@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk Well, as someone once said, "it seemed like a good idea at the time"... So, now the idea is written up as a draft and we can discuss it. Or let it expire if it's no longer a good idea. - Ralph At 06:31 PM 1/23/2003 -0500, Keith Moore wrote: > > draft-droms-rfc2563-deprecate-00.txt > >I don't follow the argument in the draft. How is this attack different than >any other DoS attack mounted by supplying false information via DHCP, for >instance, by supplying bogus addresses or too-short lease times or whatever? >If the logic in this document were followed, shouldn't DHCP itself be >deprecated? From owner-zeroconf@merit.edu Thu Jan 23 19:38:50 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25803 for ; Thu, 23 Jan 2003 19:38:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2198B91427; Thu, 23 Jan 2003 19:42:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2ECC91428; Thu, 23 Jan 2003 19:42: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 C277A91427 for ; Thu, 23 Jan 2003 19:42:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id B09A65DFEF; Thu, 23 Jan 2003 19:42:05 -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 452245DE09 for ; Thu, 23 Jan 2003 19:42:05 -0500 (EST) Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h0O0g4wU025332 for ; Thu, 23 Jan 2003 16:42:04 -0800 (PST) Received: from mac.com ([131.178.122.126]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id H970M300.6K3 for ; Thu, 23 Jan 2003 16:42:03 -0800 Date: Thu, 23 Jan 2003 18:42:02 -0600 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Rod To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030123165521.24a9130c.moore@cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, January 23, 2003, at 03:55 PM, Keith Moore wrote: > I don't buy the idea that the host has a right to run LL whether the > network wants it to or not. If the network admin -gives- physical access to a host, the host can use that link in pretty much whichever way it pleases. It is up to the administrator to enforce access policies on the network. Ways to turn off every single protocol are not the answer. That's why we don't have ways of turning off TCP/IP. There are ways of enforcing these policies, and the admin should be aware of the appropriate ones to use. Denying an ip address from DHCP is not a way to guarantee that use of a network link will be restricted. We are not trying to dictate which ways are correct or not, we are just saying that a protocol should not be designed around ways that are inherently not guaranteed nor intended to work for a certain purpose. DHCP was never designed or intended to restrict access to all kinds of communication on a link. You say that the difference between IPv4LL and assigning an IP manually is that one requires user interaction. Plugging into a network and using stuff also requires user interaction. The fact that we make this easier to work doesn't mean that we are bypassing any security measures the admin might want to use to restrict access/communication. Must every single protocol the IETF endorses have an OFF switch? I can understand the need for it to not conflict with other protocols (hence the -not on when DHCP address assigned- idea), but I don't think there HAS to be a way to turn every protocol off, when they can be blocked or restricted trough other methods. If you don't want someone to come into your house, you don't send a "don't come into my house" note to every person in the block, you lock your house down. I don't think it's smart to rely on the hosts (and protocols) to restrict themselves in this manner when you have ways of doing it externally. -Rod Lopez From owner-zeroconf@merit.edu Thu Jan 23 20:10:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26515 for ; Thu, 23 Jan 2003 20:10:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6CA199122C; Thu, 23 Jan 2003 20:13:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 366859122D; Thu, 23 Jan 2003 20:13: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 2A7C49122C for ; Thu, 23 Jan 2003 20:13:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 084C85DFFF; Thu, 23 Jan 2003 20:13:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtp.covadmail.net (mx03.covadmail.net [63.65.120.63]) by segue.merit.edu (Postfix) with SMTP id 955E35DFF7 for ; Thu, 23 Jan 2003 20:13:30 -0500 (EST) Received: (covad.net 11748 invoked from network); 24 Jan 2003 01:13:30 -0000 Received: from unknown (HELO STUDY) (66.167.13.235) by sun-qmail13 with SMTP; 24 Jan 2003 01:13:30 -0000 To: Keith Moore Cc: jgraessley@apple.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? References: <1D058DD0-2F02-11D7-9D41-000393760260@apple.com> <20030123155657.29803e49.moore@cs.utk.edu> <20030123162053.743341ee.moore@cs.utk.edu> From: Scott Lawrence Date: 23 Jan 2003 20:15:34 -0500 In-Reply-To: <20030123162053.743341ee.moore@cs.utk.edu> Message-ID: Lines: 12 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-zeroconf@merit.edu Precedence: bulk Keith Moore writes: > Your code is not smarter than the network administrator. It is not more > aware of network policy than the network. It should not be trying to > second guess what the network is saying. Not giving me an IP address _is_ denying me access to the network - any policies that have been established based on the addresses handed out by DHCP have been denied me; most emphatically routability. By getting an LL address, I'm settling for just the Link, knowing that I can't do better, but that still might be useful. From owner-zeroconf@merit.edu Thu Jan 23 20:24:48 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26762 for ; Thu, 23 Jan 2003 20:24:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1A06B9122D; Thu, 23 Jan 2003 20:28:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DBF829122E; Thu, 23 Jan 2003 20:28: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 A32429122D for ; Thu, 23 Jan 2003 20:28:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 857BD5E002; Thu, 23 Jan 2003 20:28:04 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by segue.merit.edu (Postfix) with ESMTP id 565B45DFF7 for ; Thu, 23 Jan 2003 20:28:04 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bsdU-0007jV-00; Thu, 23 Jan 2003 17:28:01 -0800 Date: Thu, 23 Jan 2003 20:26:25 -0500 From: Keith Moore To: Rod Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030123202625.3c8b024b.moore@cs.utk.edu> In-Reply-To: References: <20030123165521.24a9130c.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > I don't buy the idea that the host has a right to run LL whether the > > network wants it to or not. > > If the network admin -gives- physical access to a host, the host can > use that link in pretty much whichever way it pleases. Uh, no. The fact that a network admin provides an Ethernet jack for my host does not authorize my host to impersonate another host, to consume excessive bandwidth by violating the TCP specifications, to mount attacks on other hosts or the network itself, or to choose an address for itself. Of course the notion of giving someone physical access is less meaningful for a wireless network. But even using a wireless network often still involves dedicated resources like access points - resources which may require permissions and have policies associated with their use. >It is up to the administrator to enforce access policies on the network. Enforcement is not the issue at hand. The purpose of a protocol is to communicate between cooperating parties. We are (or should be) talking about a protocol that allows a host to cooperate with a network in order to allow the host to determine whether and how it can use the network. The host is not axiomatically assured carte blanche access. Because the network is typically a limited resource that is shared between competing concerns it is likely that there will be some constraints on its use. Many existing networks have acceptable use policies; many have mechanisms for requesting and granting access. Violating those policies or circumventing those mechanisms is often seen as theft or tresspass or some other crime punishable by fine, imprisonment, job termination, or other sanction. Perhaps those sanctions would not be applied in the case where the violation was caused by a software vendor, but the point is that these policies exist for good reasons and they are frequently taken seriously. > Ways to turn > off every single protocol are not the answer. That's why we don't have > ways of turning off TCP/IP. There are ways of enforcing these policies, > and the admin should be aware of the appropriate ones to use. Denying > an ip address from DHCP is not a way to guarantee that use of a network > link will be restricted. Like it or not, use of DHCP for this purpose is common. The most obvious alternative, PPPoE, has enough problems that DHCP remains attractive in some cases. Communicating policy and enforcing policy are different things, and it's up to each network's admins to determine how best to enforce policy according to the risks and the needs of its users. > We are not trying to dictate which ways are correct or not, we are just > saying that a protocol should not be designed around ways that are > inherently not guaranteed nor intended to work for a certain purpose. The protocol should be designed to let the host communicate what it needs and the network communicate what the host gets, and also to allow communication between hosts in the absence of an engine that assigns addresses on the network. "correct" means that the host has a way to ask for things that hosts normally require of networks - things like addresses, netmasks, routes - and the network has a way to say to hosts things that networks need to say to hosts - things like addresses, netmasks, routes; but also things like "sorry, you're not authorized". > DHCP was never designed or intended to restrict access to all kinds of > communication on a link. True. But it's not being used to restrict. It's being used to communicate policy, which is more subtle. Arguably DHCP wasn't designed for this either, but the fact that it's being widely used to do this means that there's a need for it. Screwing with facilities that network administrators need, and forcing them to solve these problems in a more complex or more costly way (or a way that is less convenient to users) is not a good way to win acceptance for your new protocol - not in IETF nor in the marketplace. > You say that the difference between IPv4LL and assigning an IP manually > is that one requires user interaction. Plugging into a network and > using stuff also requires user interaction. Not in the case of wireless it doesn't. And even when a wire is plugged in, it doesn't necessarily require users to be involved with mundane details like address allocation and stack configuration. > The fact that we make this > easier to work doesn't mean that we are bypassing any security measures > the admin might want to use to restrict access/communication. If this group says "yes, it's okay to use this network even if DHCP refused to give you an address", or "... even if DHCP told you that you couldn't use the network", or "...even if DHCP told you you couldn't use LL", then it may not be breaking security measures (depending on how you define security) but it certainly *is* violating policy. > Must every single protocol the IETF endorses have an OFF switch? Ask the question in another way. Given that large numbers of networks already have demonstrated the need to communicate certain kinds of policies to hosts - like which addresses the hosts will use - and chosen DHCP to do that, should IETF then standardize the practice of ignoring such communication? > I can > understand the need for it to not conflict with other protocols (hence > the -not on when DHCP address assigned- idea), but I don't think there > HAS to be a way to turn every protocol off, Again, we are not talking about forcing protocols off. That can be done with filters on the wire. We are talking about giving the network a way to communicate commonly useful policies and assignments to hosts and expecting well-behaved hosts to honor those policies and assignments. > when they can be blocked or > restricted trough other methods. If you don't want someone to come into > your house, you don't send a "don't come into my house" note to every > person in the block, you lock your house down. Actually you might put a "no tresspassing" sign on the fence outside your house, even if the gate is unlocked. It's useful to have an unlocked gate; it's also useful to put passers-by on notice that they're not welcome to pass through the gate without permission. > I don't think it's smart to rely on the hosts (and protocols) to > restrict themselves in this manner when you have ways of doing it > externally. Why do we rely on hosts to obey protocols at all, then? Why don't we see large numbers of hosts violating TCP timer or window specs so they can get more bandwidth? Should we expect the network to prevent that, too? The main reason the network works at all is that most hosts follow the protocols willingly. The network does not force them to do so; in most cases it's not feasible to force them to do so. From owner-zeroconf@merit.edu Thu Jan 23 20:28:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26805 for ; Thu, 23 Jan 2003 20:28:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 42CCA9122E; Thu, 23 Jan 2003 20:30:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 807A291230; Thu, 23 Jan 2003 20:30: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 7AA7A9122E for ; Thu, 23 Jan 2003 20:30:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9E8035E002; Thu, 23 Jan 2003 20:30:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.120.12]) by segue.merit.edu (Postfix) with ESMTP id 109E95DFF7 for ; Thu, 23 Jan 2003 20:30:19 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by harrier.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bsff-000123-00; Thu, 23 Jan 2003 17:30:15 -0800 Date: Thu, 23 Jan 2003 20:28:41 -0500 From: Keith Moore To: Scott Lawrence Cc: moore@cs.utk.edu, jgraessley@apple.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030123202841.627e9762.moore@cs.utk.edu> In-Reply-To: References: <1D058DD0-2F02-11D7-9D41-000393760260@apple.com> <20030123155657.29803e49.moore@cs.utk.edu> <20030123162053.743341ee.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > Your code is not smarter than the network administrator. It is not more > > aware of network policy than the network. It should not be trying to > > second guess what the network is saying. > > Not giving me an IP address _is_ denying me access to the network - > any policies that have been established based on the addresses handed > out by DHCP have been denied me; most emphatically routability. > > By getting an LL address, I'm settling for just the Link, knowing that > I can't do better, but that still might be useful. even assuming that you have the right to access the Link is a stretch. especially if you've been told (by DHCP) that you don't have that right. Keith From owner-zeroconf@merit.edu Thu Jan 23 22:08:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28477 for ; Thu, 23 Jan 2003 22:08:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ADEC991231; Thu, 23 Jan 2003 22:11:52 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 739C591234; Thu, 23 Jan 2003 22:11: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 6360091231 for ; Thu, 23 Jan 2003 22:11:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4454D5DF53; Thu, 23 Jan 2003 22:11:51 -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 BA1EB5DE39 for ; Thu, 23 Jan 2003 22:11:50 -0500 (EST) Received: from nominum.com (dsl081-073-044.sfo1.dsl.speakeasy.net [64.81.73.44]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0O37EP11020; Thu, 23 Jan 2003 21:07:15 -0600 (CST) Date: Thu, 23 Jan 2003 17:32:14 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20030123184057.03a69f38@funnel.cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > So, now the idea is written up as a draft and we can discuss it. Or > let it expire if it's no longer a good idea. As far as I know, nobody's implemented it in all this time, even though clients using IPv4 link-local addressing have been around for a long time. I've never heard anybody ask for the functionality described in the RFC, other than the person who advanced it in the first place. In retrospect it seems like it was a hasty response to a non-problem. I think there's little chance that the RFC is going to continue to advance as a standard - if nobody's implemented it yet, it seems unlikely that anybody is going to. So IMHO we should in fact deprecate it - it's confusing that it's there, because people think it's a standard when it's really not. From owner-zeroconf@merit.edu Thu Jan 23 22:15:48 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28624 for ; Thu, 23 Jan 2003 22:15:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B09DD91234; Thu, 23 Jan 2003 22:19:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 827BA91235; Thu, 23 Jan 2003 22:19: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 56B5191234 for ; Thu, 23 Jan 2003 22:17:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C1935DF0E; Thu, 23 Jan 2003 22:17:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by segue.merit.edu (Postfix) with ESMTP id 0A6AB5DD9B for ; Thu, 23 Jan 2003 22:17:37 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18buLV-0002HH-00; Thu, 23 Jan 2003 19:17:33 -0800 Date: Thu, 23 Jan 2003 22:15:59 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, rdroms@cisco.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030123221559.3db565bc.moore@cs.utk.edu> In-Reply-To: References: <4.3.2.7.2.20030123184057.03a69f38@funnel.cisco.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Thu, 23 Jan 2003 17:32:14 -0800 Ted Lemon wrote: > > So, now the idea is written up as a draft and we can discuss it. Or > > let it expire if it's no longer a good idea. > > As far as I know, nobody's implemented it in all this time, even though > clients using IPv4 link-local addressing have been around for a long > time. I've never heard anybody ask for the functionality described in > the RFC, other than the person who advanced it in the first place. well, you've heard several people ask for similar functionality here. Keith From owner-zeroconf@merit.edu Thu Jan 23 22:19:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28658 for ; Thu, 23 Jan 2003 22:19:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EAD1591235; Thu, 23 Jan 2003 22:22:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B89F791237; Thu, 23 Jan 2003 22:22: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 7DC1D91235 for ; Thu, 23 Jan 2003 22:22:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5EB595DE39; Thu, 23 Jan 2003 22:22:52 -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 D32705DD9B for ; Thu, 23 Jan 2003 22:22:51 -0500 (EST) Received: from nominum.com (dsl081-073-044.sfo1.dsl.speakeasy.net [64.81.73.44]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0O3I8P11100; Thu, 23 Jan 2003 21:18:08 -0600 (CST) Date: Thu, 23 Jan 2003 19:22:59 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Scott Lawrence , jgraessley@apple.com, zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030123202841.627e9762.moore@cs.utk.edu> Message-Id: <236535A6-2F4B-11D7-B72A-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > even assuming that you have the right to access the Link is a stretch. > especially if you've been told (by DHCP) that you don't have that > right. Computers do not make moral decisions. Humans do. Choosing not to access a link because you are not authorized to do so is a moral decision, not a protocol decision. Therefore, it is up to the human to make the decision. The human makes this decision by connecting to the network, or by not connecting to the network. The reason for this distinction is that computer decisions have to be enforced. For example, if it's not okay for a non-root user to scribble in /etc, you make sure that /etc is protected so that only root processes can write to it. It doesn't make sense to tell the computer program "you shouldn't do that" but allow it to do it. Likewise, with network access, if the network administrator wishes to control access to the link, s/he must actually control access to the link using some mechanism that can't be defeated simply by ignoring it. If there is a reason to have a DHCP message that stops link-local addresses from being used, it should be for a protocol reason, not because of some mechanism that is called an access control mechanism but that does not actually control access. From owner-zeroconf@merit.edu Thu Jan 23 22:38:56 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29189 for ; Thu, 23 Jan 2003 22:38:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C95091238; Thu, 23 Jan 2003 22:42:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA72C91428; Thu, 23 Jan 2003 22:42: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 C7F6891238 for ; Thu, 23 Jan 2003 22:42:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id AAFE05DF81; Thu, 23 Jan 2003 22:42:14 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.85]) by segue.merit.edu (Postfix) with ESMTP id 3719E5DF62 for ; Thu, 23 Jan 2003 22:42:14 -0500 (EST) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h0O3gDbD000106 for ; Thu, 23 Jan 2003 19:42:13 -0800 (PST) Received: from mac.com ([200.67.17.194]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id H978YB00.098 for ; Thu, 23 Jan 2003 19:42:11 -0800 Date: Thu, 23 Jan 2003 21:42:08 -0600 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Rod To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030123202625.3c8b024b.moore@cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I can understand your points Keith, I just don't think it should be up to -each- protocol to disable itself according to whatever the network admin's policies are. See below. On Thursday, January 23, 2003, at 07:26 PM, Keith Moore wrote: >> If the network admin -gives- physical access to a host, the host can >> use that link in pretty much whichever way it pleases. > > Uh, no. The fact that a network admin provides an Ethernet jack for > my host > does not authorize my host to impersonate another host, to consume > excessive > bandwidth by violating the TCP specifications, to mount attacks on > other hosts > or the network itself, or to choose an address for itself. I said it can, I didn't say it was ok for it do do so. > Of course the notion of giving someone physical access is less > meaningful for > a wireless network. But even using a wireless network often still > involves > dedicated resources like access points - resources which may require > permissions and have policies associated with their use. Exactly. > Like it or not, use of DHCP for this purpose is common. It's use is common to restrict access to the routed network, not to the local link. In fact I don't think that's common at all. > The protocol should be designed to let the host communicate what it > needs and > the network communicate what the host gets, and also to allow > communication > between hosts in the absence of an engine that assigns addresses on the > network. The host might not need anything from the network other than physical access. > "correct" means that the host has a way to ask for things that hosts > normally require of networks - things like addresses, netmasks, routes > - and > the network has a way to say to hosts things that networks need to say > to > hosts - things like addresses, netmasks, routes; but also things like > "sorry, > you're not authorized". Hosts might not need an address, netmask, routes, from the network. The introduction of DHCP to make things easier doesn't mean it's a link restriction mechanism because all hosts depend on it. They don't. >> DHCP was never designed or intended to restrict access to all kinds of >> communication on a link. > > True. But it's not being used to restrict. It's being used to > communicate > policy, which is more subtle. Arguably DHCP wasn't designed for this > either, > but the fact that it's being widely used to do this means that there's > a need > for it. And that need is being addressed by mechanisms to restrict access on a link and 'communicate policy', not by each and every protocol that may be used on it once you have access. > If this group says "yes, it's okay to use this network even if DHCP > refused to > give you an address", or "... even if DHCP told you that you couldn't > use the > network", or "...even if DHCP told you you couldn't use LL", then it > may not > be breaking security measures (depending on how you define security) > but it > certainly *is* violating policy. And using FTP or HTTP might be against my network's policy, yet no one is asking for these protocols to specify a way to disable themselves. >> Must every single protocol the IETF endorses have an OFF switch? > > Ask the question in another way. Given that large numbers of networks > already > have demonstrated the need to communicate certain kinds of policies to > hosts - > like which addresses the hosts will use - and chosen DHCP to do that, > should > IETF then standardize the practice of ignoring such communication? No, it should suggest appropiate ways of communicating (and/or enforcing) this policy. >> when they can be blocked or >> restricted trough other methods. If you don't want someone to come >> into >> your house, you don't send a "don't come into my house" note to every >> person in the block, you lock your house down. > > Actually you might put a "no tresspassing" sign on the fence outside > your > house, even if the gate is unlocked. It's useful to have an unlocked > gate; > it's also useful to put passers-by on notice that they're not welcome > to pass > through the gate without permission. Yes, but you can't rely on that to be certain no one will come in, intentionally or unintentionally. And you also can't expect people who design cars to implement some way to disable their cars if that sign is present, just because you or other people choose that as their way of communicating policy. > Why do we rely on hosts to obey protocols at all, then? Why don't we > see > large numbers of hosts violating TCP timer or window specs so they can > get > more bandwidth? Should we expect the network to prevent that, too? That's why I tried to make a distinction between what a protocol needs and what a network (in the sense of the word we're using) needs. If the network wants to disable its usage in some way, it should do so without relying on a protocol having an off switch or disabling itself. The protocol should address its own functional needs, and the network should address its own. On Thursday, January 23, 2003, at 07:28 PM, Keith Moore wrote: > even assuming that you have the right to access the Link is a stretch. > especially if you've been told (by DHCP) that you don't have that > right. I think it's unreasonable to assume DHCP should or can be used to tell someone they don't have the right to access a -link-. Not only was it not designed with this purpose, we're talking about different layers and/or scopes. And if an admin still wants to use it for that purpose, it doesn't mean all protocol designers should implement ways for DHCP to disable their protocols. Coexist with it, yes, but be disabled by it just for the sake of "communicating the admin's policies", no. You always argue about how horrendous NAT is, and about how it's not standarized and so it's wrong to consider it as an example or justification for doing things, yet thousands of people and networks use NAT. Now you are arguing that because lots of networks use DHCP for a purpose it was not intended for, we should consider this and use this as a justification for doing things. And, as I stated previously, I don't think a lot of admins will tell you they use DHCP to "communicate" to a person or host that access to that link is not authorized. They'll tell you they use it to "communicate" that access to that "managed/routed" network is not authorized. I, as a user and/or software designer, would not see a DHCP deny signal as something that tells me "you are not allowed to use this link." Just as I would not see a certain region of a city fenced down and think "I am not allowed to be on this city." If an admin wants to communicate that his network should not be used, he should go further than just communicating that access to a certain part of that network is restricted. He should use a method that communicates and/or enforces that no part or functionality of the network shall be used. There are appropriate tools to do so. -Rod Lopez From owner-zeroconf@merit.edu Thu Jan 23 22:46:29 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29352 for ; Thu, 23 Jan 2003 22:46:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4E5D89123A; Thu, 23 Jan 2003 22:49:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C2AF9123C; Thu, 23 Jan 2003 22:49: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 DD8C69123A for ; Thu, 23 Jan 2003 22:49:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id BF5415DF62; Thu, 23 Jan 2003 22:49:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by segue.merit.edu (Postfix) with ESMTP id 9D12D5DF1D for ; Thu, 23 Jan 2003 22:49:40 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18buqU-0002HX-00; Thu, 23 Jan 2003 19:49:34 -0800 Date: Thu, 23 Jan 2003 22:47:59 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, lawrence@world.std.com, jgraessley@apple.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030123224759.29a97929.moore@cs.utk.edu> In-Reply-To: <236535A6-2F4B-11D7-B72A-00039317663C@nominum.com> References: <20030123202841.627e9762.moore@cs.utk.edu> <236535A6-2F4B-11D7-B72A-00039317663C@nominum.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Thu, 23 Jan 2003 19:22:59 -0800 Ted Lemon wrote: > > even assuming that you have the right to access the Link is a stretch. > > especially if you've been told (by DHCP) that you don't have that > > right. > > Computers do not make moral decisions. Humans do. and human standards-writers do. and human code implementors do. we're not discussing what a computer will autonomously decide to do, we're discussing what the computer should be told to do as a matter of standards conformance. > Choosing not to access a link because you are not authorized to do so is a > moral decision, not a protocol decision. we're talking about what a computer should do in the absence of explicit configuration by a human user. nobody is saying that a human user should not be able to override the computer's behavior (and suffer the consequences, if any) > Therefore, it is up to the human > to make the decision. The human makes this decision by connecting to > the network, or by not connecting to the network. no. the decision to plug a wire into a network is not the same as a decision to use it, any more than the decision to knock on a door is the same as a decision to enter whether or not the door is opened. > The reason for this distinction is that computer decisions have to be > enforced. no they don't, any more than KEEP OUT signs have to be enforced. and even if these rules are enforced, different parties may choose different levels of enforcement, depending on their needs. some do spot checks, others post a guard. some chase off trespassers, others shoot them on sight. > For example, if it's not okay for a non-root user to > scribble in /etc, you make sure that /etc is protected so that only > root processes can write to it. It doesn't make sense to tell the > computer program "you shouldn't do that" but allow it to do it. It's useful to make a difference between what a computer should do automatically and what a computer is able to do with explicit human input. It's like an unlocked gate on a fence with a KEEP OUT sign. It doesn't prevent you from opening the gate and entering, but it does tell you that the mere fact that you can physically open the gate doesn't mean you're authorized to enter. So the network tells the host "you can't have an address". The host reports this to the human - "the network won't give me an address". Human says "override" because he has explicit authorization from elsewhere (maybe he is the network admin, maybe he's the repair guy needing to run diagnostics.) But the human also gets to deal with the consequences. This might mean that if he's caught using the network without authorization he loses his job. Or it might simply mean that he's trying to use the network in a way that its maintainers didn't provide for, so things aren't guaranteed to work. For intance, a host with a LL address might not be able to reach any printers or DNS servers. If you think about it, it's really stupid for a host to automatically assume that an LL address is suitable for *any* purpose in a managed network. If you didn't design the network with LL in mind, if you didn't place essential services where LL-only hosts could reach them, what good is it for the host to acquire an LL address? > Likewise, with network access, if the network administrator wishes to > control access to the link, s/he must actually control access to the > link using some mechanism that can't be defeated simply by ignoring it. bull. I've seen DHCP used in this way, and it's largely effective at forcing most people to get their laptops' addresses registered. It's not for us to determine whether a particular site's policy enforcement mechanism is adequate to their needs, any more than it's for us to determine how strong a lock is needed on the network closet door. > If there is a reason to have a DHCP message that stops link-local > addresses from being used, it should be for a protocol reason, not > because of some mechanism that is called an access control mechanism > but that does not actually control access. I've been trying to call it a way to communicate policy. And what is a protocol if not a way to communicate something? From owner-zeroconf@merit.edu Thu Jan 23 22:52:31 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29487 for ; Thu, 23 Jan 2003 22:52:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DE5C79123C; Thu, 23 Jan 2003 22:55:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC2A891428; Thu, 23 Jan 2003 22:55: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 A40C89123C for ; Thu, 23 Jan 2003 22:55:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8C1145DF62; Thu, 23 Jan 2003 22:55:49 -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 95DF75DDE0 for ; Thu, 23 Jan 2003 22:55:48 -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 h0O3tcjf026896; Fri, 24 Jan 2003 13:55:39 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id h0O3tbf33831; Fri, 24 Jan 2003 13:55:37 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Fri, 24 Jan 2003 13:55:36 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: Keith Moore Cc: zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: <20030123224759.29a97929.moore@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 Thu, 23 Jan 2003, Keith Moore wrote: >If you think about it, it's really stupid for a host to automatically assume >that an LL address is suitable for *any* purpose in a managed network. If you >didn't design the network with LL in mind, if you didn't place essential >services where LL-only hosts could reach them, what good is it for the host to >acquire an LL address? It might not be useful for anything, but it's really stupid for a host to automatically assume that a LL address is *not* suitable for anything just because the DHCP server doesn't want to give it a global address. Ian From owner-zeroconf@merit.edu Thu Jan 23 23:03:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29615 for ; Thu, 23 Jan 2003 23:03:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4508D91428; Thu, 23 Jan 2003 23:07:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06B8291429; Thu, 23 Jan 2003 23:07: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 0AB0791428 for ; Thu, 23 Jan 2003 23:07:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id ED0B45DDE0; Thu, 23 Jan 2003 23:07:13 -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 81C015DDDF for ; Thu, 23 Jan 2003 23:07:13 -0500 (EST) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h0O47CD5004520 for ; Thu, 23 Jan 2003 20:07:12 -0800 (PST) Received: from mac.com ([200.67.17.194]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id H97A4000.SD2 for ; Thu, 23 Jan 2003 20:07:12 -0800 Date: Thu, 23 Jan 2003 22:07:11 -0600 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Rod To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030123224759.29a97929.moore@cs.utk.edu> Message-Id: <4FF1B63B-2F51-11D7-A99F-003065A87BBE@mac.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, January 23, 2003, at 09:47 PM, Keith Moore wrote: > no. the decision to plug a wire into a network is not the same as a > decision > to use it, any more than the decision to knock on a door is the same > as a > decision to enter whether or not the door is opened. The decision to configure an IP address when it's plugged in is not the same as the decision to use it then. > If you think about it, it's really stupid for a host to automatically > assume > that an LL address is suitable for *any* purpose in a managed network. > If you > didn't design the network with LL in mind, if you didn't place > essential > services where LL-only hosts could reach them, what good is it for the > host to > acquire an LL address? You might just want to transfer a file between two laptops. > It's not for us to determine whether a particular site's policy > enforcement mechanism is adequate > to their needs Exactly. So why do you want to do this? Let them determine that DHCP is not adequate to their needs if what they want to do is completely restrict access to the link. >> If there is a reason to have a DHCP message that stops link-local >> addresses from being used, it should be for a protocol reason, not >> because of some mechanism that is called an access control mechanism >> but that does not actually control access. > > I've been trying to call it a way to communicate policy. And what is a > protocol if not a way to communicate something? Something, not everything. -Rod Lopez From owner-zeroconf@merit.edu Thu Jan 23 23:23:36 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29914 for ; Thu, 23 Jan 2003 23:23:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0D1339123D; Thu, 23 Jan 2003 23:26:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCFEA91429; Thu, 23 Jan 2003 23:26: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 C8EE59123D for ; Thu, 23 Jan 2003 23:26:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id B73B45DF1D; Thu, 23 Jan 2003 23:26:54 -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 4DC725DD9B for ; Thu, 23 Jan 2003 23:26: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 XAA10680 for ; Thu, 23 Jan 2003 23:26: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 XAA16039 for ; Thu, 23 Jan 2003 23:26: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 XAA09102 for ; Thu, 23 Jan 2003 23:26:52 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 23 Jan 2003 23:26:51 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <20030123182813.2f57dffe.moore@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 01/23/2003 18:28, "Keith Moore" wrote: >> By the same token, if they want it on, then it should be on, *regardless* of >> the alternate config method. If the admin wants it on, then DHCP shouldn't >> be able to override this, because no on here knows everything about every >> network need until the end of v4. > > I find myself imagining that in the DHC working group someone is saying about > now "if the admin wants to use DHCP to specify whether and how the network is > to be used by a host, then LL shouldn't be able to override this..." Hence my previous paragraph in that email agreeing with you in this. The admin should decide on how and when LL is used, not random DHCP servers. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Jan 23 23:24:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29943 for ; Thu, 23 Jan 2003 23:24:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3F47891429; Thu, 23 Jan 2003 23:27:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D4E79142A; Thu, 23 Jan 2003 23:27: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 F306F91429 for ; Thu, 23 Jan 2003 23:27:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id D995F5DF1D; Thu, 23 Jan 2003 23:27:57 -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 70C395DDDF for ; Thu, 23 Jan 2003 23:27:57 -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 XAA11092 for ; Thu, 23 Jan 2003 23:27:56 -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 XAA16099 for ; Thu, 23 Jan 2003 23:27: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 XAA09240 for ; Thu, 23 Jan 2003 23:27:56 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 23 Jan 2003 23:27:55 -0500 Subject: Re: LL-only devices [was Re: Turning off link-locals?] From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <0820F1C3-2F2C-11D7-B72A-00039317663C@nominum.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 01/23/2003 18:40, "Ted Lemon" wrote: > you might see an ipv4ll-only iPod, but you're not > going to see an ipv4ll-only printer, and you're definitely not going > to see an ipv4ll-only desktop or laptop computer. I'll give you even odds on the printer. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Jan 23 23:25:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29963 for ; Thu, 23 Jan 2003 23:25:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BFDC79142A; Thu, 23 Jan 2003 23:29:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 87C3D9142B; Thu, 23 Jan 2003 23:29: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 19F629142A for ; Thu, 23 Jan 2003 23:28:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 00B6E5E018; Thu, 23 Jan 2003 23:28:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from avocet.mail.pas.earthlink.net (avocet.mail.pas.earthlink.net [207.217.120.50]) by segue.merit.edu (Postfix) with ESMTP id 923D55DF1D for ; Thu, 23 Jan 2003 23:28:58 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bvSY-0002mv-00; Thu, 23 Jan 2003 20:28:55 -0800 Date: Thu, 23 Jan 2003 23:27:20 -0500 From: Keith Moore To: Rod Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030123232720.396d852d.moore@cs.utk.edu> In-Reply-To: References: <20030123202625.3c8b024b.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > I can understand your points Keith, I just don't think it should be up > to -each- protocol to disable itself according to whatever the network > admin's policies are. See below. Perhaps not. But different protocols have different impacts, and IP is more fundamental than most. Furthermore, discussion of ways to disable other protocols are not in scope for the zeroconf WG. If we needed a way for the network to tell hosts to not use DHCP we'd be discussing it in the DHC working group. We're talking about providing a mechanism which can circumvent measures that are already in place to communicate policy. Given that mechanisms to communicate policy about how to use a network are already in place, I don't think we should tell implementors that it's okay to ignore them. If we were talking about a completely new facility for configuring addresses on hosts (where no facility existed before), backward compatibility would not be an issue. > > Like it or not, use of DHCP for this purpose is common. > > It's use is common to restrict access to the routed network, not to the > local link. Perhaps. But the assumption is that, having failed to get an address, the host will not try to access the link (at least not with IP) in the absence of explicit configuration by a human. (and the human typically doesn't know what address to use - so this can be an sufficiently effective access control mechanism for some purposes.) > > The protocol should be designed to let the host communicate what it > > needs and the network communicate what the host gets, and also to allow > > communication between hosts in the absence of an engine that assigns > > addresses on the network. > > The host might not need anything from the network other than physical > access. that's silly. what's the purpose of a network if not to communicate with other hosts? layer 1 is useless to a host without at least layer 2. > Hosts might not need an address, netmask, routes, from the network. The > introduction of DHCP to make things easier doesn't mean it's a link > restriction mechanism because all hosts depend on it. They don't. If there are no other resources on a net than IP-accessible resources, it's pretty difficult to do anything with those resources (or the net) without an IP address. > >> DHCP was never designed or intended to restrict access to all kinds of > >> communication on a link. > > > > True. But it's not being used to restrict. It's being used to > > communicate policy, which is more subtle. Arguably DHCP wasn't designed > > for this either, but the fact that it's being widely used to do this means > > that there's a need for it. > > And that need is being addressed by mechanisms to restrict access on a > link and 'communicate policy', not by each and every protocol that may > be used on it once you have access. The 'every protocol' argument is specious. We're not talking about 'every protocol', 'every protocol' is not in scope for this working group, and there are unique characteristics of LL that do not apply to 'every protocol'. > And using FTP or HTTP might be against my network's policy, yet no one > is asking for these protocols to specify a way to disable themselves. Various means to disable these already exist. The needs for disabling them are different than the needs for disabling LL. And they're not the problem of this working group. > >> Must every single protocol the IETF endorses have an OFF switch? > > > > Ask the question in another way. Given that large numbers of networks > > already have demonstrated the need to communicate certain kinds of > > policies to hosts - like which addresses the hosts will use - and chosen > > DHCP to do that, should IETF then standardize the practice of ignoring > > such communication? > > No, it should suggest appropiate ways of communicating (and/or > enforcing) this policy. I submit that DHCP is within epsilon of an appropriate way of communicating the policy of which address to use, which netmask to use, which default route to use, or whether no address should be used by a host. If it needs tweaks to accomodate LL, let's tweak it. But when we've got existing networks using DHCP as a means of saying "you don't have access to this network", let's not tell vendors that it's okay to program hosts to access the network anyway using LL. Or let's at least give network admins a way to less ambiguously say "no access", and expect the vendors to adhere to *that*. (note that backward compatibilty with current practice is highly desirable) > > Actually you might put a "no tresspassing" sign on the fence outside > > your house, even if the gate is unlocked. It's useful to have an unlocked > > > > gate; it's also useful to put passers-by on notice that they're not > > welcome to pass through the gate without permission. > > Yes, but you can't rely on that to be certain no one will come in, > intentionally or unintentionally. If you really wanted to be certain of that, you'd have bricked your doors and windows shut. The purpose in putting up a no trespassing sign next to an unlocked gate is *not* to be certain that nobody can come in, but to put people on notice that by default, they're not welcome. The sign doesn't mean you want the fireman to stay outside when the house is on fire. Neither does the absence of a lock mean that neighboorhood kids are welcome to come in the house and rummage through your closets. Ambiguity and appeals to human judgement are useful, when dealing with humans. > And you also can't expect people who > design cars to implement some way to disable their cars if that sign is > present, just because you or other people choose that as their way of > communicating policy. In fact people designing autonomous vehicles have worked on having those vehicles respect various kinds of road markings (like solid center lines), while allowing humans to override the vehicles. > > Why do we rely on hosts to obey protocols at all, then? Why don't we > > see large numbers of hosts violating TCP timer or window specs so they can > > > > get more bandwidth? Should we expect the network to prevent that, too? > > That's why I tried to make a distinction between what a protocol needs > and what a network (in the sense of the word we're using) needs. If the > network wants to disable its usage in some way, it should do so without > relying on a protocol having an off switch or disabling itself. no. It's expensive, and often unnecessary, to have every network access port be able to filter traffic. I shouldn't have to replace all of my dumb hubs with remotely controllable ones, and implement network monitors, just to deal with vendors who insist on being agressive about imposing LL on my networks. Or at least, IETF shouldn't be endorsing such practices. > On Thursday, January 23, 2003, at 07:28 PM, Keith Moore wrote: > > > even assuming that you have the right to access the Link is a stretch. > > especially if you've been told (by DHCP) that you don't have that > > right. > > I think it's unreasonable to assume DHCP should or can be used to tell > someone they don't have the right to access a -link-. Like it or not, that's how it's being used today. You may think that only access to the network beyond the link is being restricted, but that is not necessarily what the admins intend. > You always argue about how horrendous NAT is, and about how it's not > standarized and so it's wrong to consider it as an example or > justification for doing things, yet thousands of people and networks > use NAT. Yes, and I've also argued that standard protocols should not assume that they have the right to subvert NAT when NAT is used as a firewall. > And, as I stated previously, I > don't think a lot of admins will tell you they use DHCP to > "communicate" to a person or host that access to that link is not > authorized. They'll tell you they use it to "communicate" that access > to that "managed/routed" network is not authorized. I assure you that our admins treat it as access control to the entire network, not just the portion beyond the link. They do not want unregistered hosts on the network, period. Keith From owner-zeroconf@merit.edu Thu Jan 23 23:26:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29981 for ; Thu, 23 Jan 2003 23:26:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5412C9142B; Thu, 23 Jan 2003 23:29:26 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E0AE9142C; Thu, 23 Jan 2003 23: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 1BC9A9142B for ; Thu, 23 Jan 2003 23:29:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 061245E017; Thu, 23 Jan 2003 23:29:25 -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 90DF25DF1D for ; Thu, 23 Jan 2003 23:29:24 -0500 (EST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id XAA11451 for ; Thu, 23 Jan 2003 23:29:24 -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 XAA16144 for ; Thu, 23 Jan 2003 23:29:23 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id XAA09387 for ; Thu, 23 Jan 2003 23:29:23 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Thu, 23 Jan 2003 23:29:22 -0500 Subject: Re: Turning off link-locals? 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 01/23/2003 19:42, "Rod" wrote: > If the network admin -gives- physical access to a host, the host can > use that link in pretty much whichever way it pleases. It is up to the > administrator to enforce access policies on the network. Ways to turn > off every single protocol are not the answer. That's why we don't have > ways of turning off TCP/IP. Ifconfig en0 off john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Thu Jan 23 23:32:18 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00055 for ; Thu, 23 Jan 2003 23:32:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 722D09123E; Thu, 23 Jan 2003 23:35:38 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2FFD69142C; Thu, 23 Jan 2003 23:35: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 E0E4D9123E for ; Thu, 23 Jan 2003 23:35:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id CF17A5DDFC; Thu, 23 Jan 2003 23:35:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by segue.merit.edu (Postfix) with ESMTP id AE43B5DD9B for ; Thu, 23 Jan 2003 23:35:36 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18bvYz-0006mM-00; Thu, 23 Jan 2003 20:35:33 -0800 Date: Thu, 23 Jan 2003 23:33:59 -0500 From: Keith Moore To: Rod Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030123233359.2a05f88b.moore@cs.utk.edu> In-Reply-To: <4FF1B63B-2F51-11D7-A99F-003065A87BBE@mac.com> References: <20030123224759.29a97929.moore@cs.utk.edu> <4FF1B63B-2F51-11D7-A99F-003065A87BBE@mac.com> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > no. the decision to plug a wire into a network is not the same as a > > decision to use it, any more than the decision to knock on a door is the > > same as a decision to enter whether or not the door is opened. > > The decision to configure an IP address when it's plugged in is not the > same as the decision to use it then. it depends. does the computer have any processes running on it that periodically try to do things on the network? > > If you think about it, it's really stupid for a host to automatically > > assume that an LL address is suitable for *any* purpose in a managed > > network. If you didn't design the network with LL in mind, if you didn't > > place essential services where LL-only hosts could reach them, what good > > is it for the host to acquire an LL address? > > You might just want to transfer a file between two laptops. and you just might not want your network to be used by unauthorized hosts. > > It's not for us to determine whether a particular site's policy > > enforcement mechanism is adequate to their needs > > Exactly. So why do you want to do this? Let them determine that DHCP is > not adequate to their needs if what they want to do is completely > restrict access to the link. they've determined that it's good enough for now. people in this group are essentially proposing to change the meaning of a DHCP server's refusal to assign an address. Keith From owner-zeroconf@merit.edu Fri Jan 24 00:53:36 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01116 for ; Fri, 24 Jan 2003 00:53:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 77B4C9142E; Fri, 24 Jan 2003 00:56:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 45B4A9142F; Fri, 24 Jan 2003 00:56: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 0895F9142E for ; Fri, 24 Jan 2003 00:56:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id DE39A5DDE3; Fri, 24 Jan 2003 00:56:52 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.85]) by segue.merit.edu (Postfix) with ESMTP id 6ECA35DD9B for ; Fri, 24 Jan 2003 00:56:52 -0500 (EST) Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h0O5upbD007635 for ; Thu, 23 Jan 2003 21:56:51 -0800 (PST) Received: from mac.com ([200.67.17.194]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id H97F6Q00.CZF for ; Thu, 23 Jan 2003 21:56:50 -0800 Date: Thu, 23 Jan 2003 23:56:49 -0600 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Rod To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030123232720.396d852d.moore@cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, January 23, 2003, at 10:27 PM, Keith Moore wrote: >> I can understand your points Keith, I just don't think it should be up >> to -each- protocol to disable itself according to whatever the network >> admin's policies are. See below. > > Perhaps not. But different protocols have different impacts, and IP > is more > fundamental than most. Furthermore, discussion of ways to disable > other > protocols are not in scope for the zeroconf WG. If we needed a way > for the > network to tell hosts to not use DHCP we'd be discussing it in the DHC > working > group. The consideration of mechanisms that other protocols use to do things as examples is not out of the scope of this WG. > But the assumption is that, having failed to get an address, the > host will not try to access the link (at least not with IP) in the > absence of > explicit configuration by a human. (and the human typically doesn't > know what > address to use - so this can be an sufficiently effective access > control > mechanism for some purposes.) Whose assumption? Should we proceed according to assumptions? Even if they are wrong? Why would anyone assume that being denied a DHCP address, the host will not try to access the link anyway, if Appletalk, NetBIOS, IPX, etc. have been in existance for decades and are widely used, not to mention shipping with all major desktop operating systems? >> The host might not need anything from the network other than physical >> access. > > that's silly. what's the purpose of a network if not to communicate > with > other hosts? layer 1 is useless to a host without at least layer 2. I meant physical access to the network, not access to the physical layer only. >> Hosts might not need an address, netmask, routes, from the network. >> The >> introduction of DHCP to make things easier doesn't mean it's a link >> restriction mechanism because all hosts depend on it. They don't. > > If there are no other resources on a net than IP-accessible resources, > it's > pretty difficult to do anything with those resources (or the net) > without an > IP address. My point was that the host might not need to ask the network for an IP address, so nobody should assume it will. >> And that need is being addressed by mechanisms to restrict access on a >> link and 'communicate policy', not by each and every protocol that may >> be used on it once you have access. > > The 'every protocol' argument is specious. We're not talking about > 'every > protocol', 'every protocol' is not in scope for this working group, > and there > are unique characteristics of LL that do not apply to 'every protocol'. The consideration of mechanisms that other protocols use to do things as examples is not out of the scope of this WG. There are unique characteristics of LL that do not apply to every protocol, but the characteristic of "the admin might want to restrict it" does apply to most. >> And using FTP or HTTP might be against my network's policy, yet no one >> is asking for these protocols to specify a way to disable themselves. > > Various means to disable these already exist. The needs for disabling > them > are different than the needs for disabling LL. And they're not the > problem of > this working group. And the means to disable them are not a part of the protocols themselves, which was my point. Taking this as an example is not out of the scope of this working group. >> No, it should suggest appropiate ways of communicating (and/or >> enforcing) this policy. > > I submit that DHCP is within epsilon of an appropriate way of > communicating > the policy of which address to use, which netmask to use, which > default route > to use, or whether no address should be used by a host. If it needs > tweaks to > accomodate LL, let's tweak it. I disagree, because nobody ever said that DHCP is the only way to use IP and the only way to configure an IP address, and nobody ever said that if you don't get an IP address from DHCP then IP ceases to work, or the local link ceases to work. I also don't think anyone assumes this. It's ok with me if you submit an idea for DHCP to be able to restrict what IP addresses can be used on a link, but I don't think that's related to this WG. > But when we've got existing networks using > DHCP as a means of saying "you don't have access to this network", > let's not > tell vendors that it's okay to program hosts to access the network > anyway > using LL. Or let's at least give network admins a way to less > ambiguously say > "no access", and expect the vendors to adhere to *that*. (note that > backward > compatibilty with current practice is highly desirable) 1) I really don't think anyone is using DHCP as a means of saying "you don't have access to this network" while implying "you don't have access to this link." To assume this would be very unreasonable. 2) There are ways for network admins to say "no access to this link." DHCP is not one of them and never has been. If you want to work on new ways to do so (including using DHCP to restrict access and/or what IP's can be used) you are welcome to do so under the appropriate WG. > In fact people designing autonomous vehicles have worked on having > those > vehicles respect various kinds of road markings (like solid center > lines), > while allowing humans to override the vehicles. It's ok with me if people use DHCP to communicate "I don't want to give you an IP." But I refuse to accept that this is also supposed to tell people/machines "you can't use this link at all." > no. It's expensive, and often unnecessary, to have every network > access port > be able to filter traffic. I shouldn't have to replace all of my dumb > hubs > with remotely controllable ones, and implement network monitors, just > to deal > with vendors who insist on being agressive about imposing LL on my > networks. > Or at least, IETF shouldn't be endorsing such practices. You have to anyway if you want to completely restrict access to a link or communicate that it shouldn't be used. When you bought those hubs you knew that they would not be useful in controlling access to the local link. This doesn't change at all with the introduction of IPv4LL. >> On Thursday, January 23, 2003, at 07:28 PM, Keith Moore wrote: >> >> I think it's unreasonable to assume DHCP should or can be used to tell >> someone they don't have the right to access a -link-. > > Like it or not, that's how it's being used today. No, it's being used to deny IP addresses on a network, not to tell people they don't have the right to access a link. > You may think that only > access to the network beyond the link is being restricted, but that is > not > necessarily what the admins intend. They should do what they intend then, and not expect users or protocols to try to interpret, guess, or figure out what they intend to do and what their policies are. Also, we should not design protocols based on assumptions of these things. We should base them on facts and how things really work, not how admins believe they work, or what admins believe will be communicated by the ways they decide to use them. > I assure you that our admins treat it as access control to the entire > network, > not just the portion beyond the link. They do not want unregistered > hosts on > the network, period. They are not using the appropriate methods then. Not because this group dictates it, but because they are not accomplishing their goal if anyone can come in and share files via Appletalk or a manual IP. IPv4LL won't change this either. -Rod Lopez From owner-zeroconf@merit.edu Fri Jan 24 01:06:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01357 for ; Fri, 24 Jan 2003 01:06:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 383569142F; Fri, 24 Jan 2003 01:10:09 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0434B91430; Fri, 24 Jan 2003 01:10: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 060379142F for ; Fri, 24 Jan 2003 01:10:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id DEE6A5DDE3; Fri, 24 Jan 2003 01:10:07 -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 A46165DD9B for ; Fri, 24 Jan 2003 01:10:07 -0500 (EST) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id h0O6A6wU010450 for ; Thu, 23 Jan 2003 22:10:07 -0800 (PST) Received: from mac.com ([200.67.17.194]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id H97FSU00.SHT for ; Thu, 23 Jan 2003 22:10:06 -0800 Date: Fri, 24 Jan 2003 00:10:05 -0600 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Rod To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <7B616705-2F62-11D7-8363-003065A87BBE@mac.com> X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, January 23, 2003, at 10:29 PM, John C. Welch wrote: > On 01/23/2003 19:42, "Rod" wrote: > >> If the network admin -gives- physical access to a host, the host can >> use that link in pretty much whichever way it pleases. It is up to the >> administrator to enforce access policies on the network. Ways to turn >> off every single protocol are not the answer. That's why we don't have >> ways of turning off TCP/IP. > > Ifconfig en0 off Nice try John, but no, that's not turning TCP/IP off via a mechanism defined in its specs, that's turning the ethernet interface off. You can do that to disable IPv4LL as well, yet you are still asking for a switch to disable it aren't you? :-) You're actually backing up my point, that the way to block/disable a protocol should not be the job of the protocol itself. -Rod Lopez From owner-zeroconf@merit.edu Fri Jan 24 02:00:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02655 for ; Fri, 24 Jan 2003 02:00:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6853C91240; Fri, 24 Jan 2003 02:01:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC53C91241; Fri, 24 Jan 2003 02: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 E20E291240 for ; Fri, 24 Jan 2003 02:01:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id A649F5E03E; Fri, 24 Jan 2003 02:01: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 561B45E02C for ; Fri, 24 Jan 2003 02:01:14 -0500 (EST) Received: from nominum.com (dsl081-073-044.sfo1.dsl.speakeasy.net [64.81.73.44]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0O6uZP12518; Fri, 24 Jan 2003 00:56:35 -0600 (CST) Date: Thu, 23 Jan 2003 23:01:28 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: rdroms@cisco.com, zeroconf@merit.edu To: Keith Moore From: Ted Lemon In-Reply-To: <20030123221559.3db565bc.moore@cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > well, you've heard several people ask for similar functionality here. Right, and zero of them have sent a patch to the ISC. And even if they did, there would still be the small matter of deploying this to all the existing ipv4ll implementations, and getting it into new ones. There is no business case for this - no customers are requesting it. So it won't happen. From owner-zeroconf@merit.edu Fri Jan 24 02:37:26 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12118 for ; Fri, 24 Jan 2003 02:37:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EE43B91430; Fri, 24 Jan 2003 02:40:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B634091431; Fri, 24 Jan 2003 02:40: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 8D61D91430 for ; Fri, 24 Jan 2003 02:40:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 750515E02B; Fri, 24 Jan 2003 02:40:42 -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 356E85DFBD for ; Fri, 24 Jan 2003 02:40:42 -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); Thu, 23 Jan 2003 23:40:41 -0800 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 23 Jan 2003 23:40:41 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3718.0); Thu, 23 Jan 2003 23:40:41 -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); Thu, 23 Jan 2003 23:40:40 -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.3718.0); Thu, 23 Jan 2003 23:40:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Turning off link-locals? Date: Thu, 23 Jan 2003 23:40:39 -0800 Message-ID: Thread-Topic: Turning off link-locals? Thread-Index: AcLDdsOIY4cTL0PtS4GLdf6rFHZDXQAA4Kgv From: "Christian Huitema" To: "Ted Lemon" , "Keith Moore" Cc: , X-OriginalArrivalTime: 24 Jan 2003 07:40:40.0380 (UTC) FILETIME=[E49EC7C0:01C2C37B] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA12118 The discussion on "turning off link local" is a little weird. As Keith noted, a DHCP option would be at best the moral equivalent of a "don't trespass" sign; this will not actually prevent a host of configuring whatever address it pleases. However, that does not mean that the administrator is powerless. If the administrator configures all the other hosts on the network to not reply to LL addresses, then the no-trespass sign gets some teeth: an isolated host will indeed be able to configure itself with an LL address, but that will be pretty much useless; it will not be able to interact with the local hosts. So, in practice, the "turn off LL" option would really be an instruction to all hosts to stop using any LL address and stop responding to these addresses. If conforming hosts do that, then the visiting host will in practice be forced to configure an address using DHCP, not LL. In fact, this is pretty much the current behavior of the windows stack: once it has obtained an address, it does not consider that the 169.254/16 prefix is on line, and thus in practice stops interacting with LL addresses. Obviously, there are two options, and these are really two options for conformant hosts: continue interacting with LL addresses after being configured with a routable address, or don't. In sake of the robustness principle, I clearly see the case for continuing interacting. However, Keith also made the point for giving some control to the local admin. The reasonable option would thus be to define an explict DHCP option to "ignore LL", and have that option affect the behavior of the configured hosts. -- Christian Huitema From owner-zeroconf@merit.edu Fri Jan 24 05:01:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14612 for ; Fri, 24 Jan 2003 05:01:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5D3B391242; Fri, 24 Jan 2003 05:04:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C92191243; Fri, 24 Jan 2003 05:04:40 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E44F391242 for ; Fri, 24 Jan 2003 05:04:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id BE1325DE1D; Fri, 24 Jan 2003 05:04:39 -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 51D2F5DDCA for ; Fri, 24 Jan 2003 05:04:39 -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 DAA03870; Fri, 24 Jan 2003 03:04:37 -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 h0OA4Yl01233; Fri, 24 Jan 2003 11:04:35 +0100 (MET) Date: Fri, 24 Jan 2003 11:04:33 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Scott Lawrence Cc: Keith Moore , Joshua Graessley , zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On 23 Jan 2003, Scott Lawrence wrote: > > what if there were a DHCP message that said "you don't have permission > > to talk to this network"? would you ignore that also? > > Yes. As has been pointed out, such a message would be a perfect DOS > tool, and since systems that don't know about it (including such > common protocols as Netbios and Appletalk) will disregard it anyway, I > don't think it would actually be valuable as a management tool. > > If a network owner really wants to control what packets are on the > network, only monitors with alarms and filters can hope to work. If a host fails to get an address configured with DHCP, it will stop using IPv4LL according to the current proposal, right? (The host sends a series of DHCPREQUEST and gets only DHCPNAK replies, for example.) This means that a host will neither have a DHCP assigned address, nor a IPv4LL address. It will be unable to communicate. There was concern that home gateway / cable modem vendors would abuse this option to make home networking impossible unless managed by the network service provider. It should be possible, the argument goes, to do home networking irregardless of the provider's policy. It is *very strange* that Internet Standardization Veterans are arguing that stronger central administration and control of LANs should be mandatory, while network administrators from 2 universities and consumer client networking computer vendors continue to argue that this is neither desirable nor necessary. It *is desirable* for hosts to be required to reconfigure to using global instead of LL addresses when DHCP, etc makes the global address available because this offers *architectural advantages,* as it simplifies - source address selection - application interoperability with the rest of the network This reconfiguration comes at a significant cost of autonomy for the consumer. It means that if a DHCP server is present on the link (due to an attacker, an incompetent, greedy or intolerant service provider, etc) networking can be made impossible. There are even disadvantages for local administrators: In conditions where DHCP fails (due to misconfiguration, for example) it will be impossible to reach hosts on a LAN to administer them except by a serial cable, an out-of-band IP network or some other expensive and improbable mechanism. Erik From owner-zeroconf@merit.edu Fri Jan 24 05:17:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14913 for ; Fri, 24 Jan 2003 05:17:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8A09791243; Fri, 24 Jan 2003 05:20:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57BE491432; Fri, 24 Jan 2003 05:20: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 1781C91243 for ; Fri, 24 Jan 2003 05:20:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 481635E03E; Fri, 24 Jan 2003 05:20:52 -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 7F2465E03D for ; Fri, 24 Jan 2003 05:20:51 -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 8675C59891 for ; Fri, 24 Jan 2003 10:20:52 +0000 (GMT) Message-ID: <01d701c2c392$4515bfd0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: Subject: Re: Turning off link-locals? Date: Fri, 24 Jan 2003 10:20:50 -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 There seems to be a problem of perspective. rfc2563 is an option which requires some configuration on the part of the network administrator. By far the most common case is probably that DHCP either gives you an address so you don't need a LL one, or it doesn't reply (because its not present or does not recognise your identifier), in which case you are quite welcome to self assign a v4LL address. If the network admin has gone to the trouble of configuring a rfc2563 option then this is probably signalling a positive intention, but even then the option may well be to go ahead and autoconfigure. In the case of a small device which doen't have a user interface, the solution is not to hard code that device to ignore network policy, the solution is ultimately to change network policy. On the other hand, if the device has a user interface which lets you the user override network policy then that is your responsibility. DoS: Any DHCP option is subject to attack and this one option doesn't make v4LL especially vulnerable - the way some on this list are talking its a wonder anyone uses DHCP at all! If I maliciously wanted to stop clients getting a LL address, why would I do it by setting up a DHCP server? I would simply defend all their claims. If somebody sets up a bogus DHCP server, that is a problem for the network as a whole (or for the DHC wg) and not one which requires an special v4LL solution. If the extra DHCP server is an acident rather than malicious, then perhaps rfc2563 should be ammended to mention this and say that the default state in the absence of explicit management action must be "autoconfigure". However, the huge take up of rfc2563 since 1999 (has anyone implemented it ever?) indicates either that the network community is not interested in this way of doing things - or that it needs something like the IPv4-LL spec to raise it from obscurity. Philip From owner-zeroconf@merit.edu Fri Jan 24 05:20:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14995 for ; Fri, 24 Jan 2003 05:20:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 34FA791432; Fri, 24 Jan 2003 05:23:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0504691433; Fri, 24 Jan 2003 05: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 0CEA091432 for ; Fri, 24 Jan 2003 05:23:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id E64A65E03E; Fri, 24 Jan 2003 05:23:40 -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 99AFB5E03D for ; Fri, 24 Jan 2003 05:23:40 -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 DAA14567; Fri, 24 Jan 2003 03:23: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 h0OANal01753; Fri, 24 Jan 2003 11:23:36 +0100 (MET) Date: Fri, 24 Jan 2003 11:23:35 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Rod Cc: zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Thu, 23 Jan 2003, Rod wrote: > Whose assumption? Should we proceed according to assumptions? Even if > they are wrong? Why would anyone assume that being denied a DHCP > address, the host will not try to access the link anyway, if Appletalk, > NetBIOS, IPX, etc. have been in existance for decades and are widely > used, not to mention shipping with all major desktop operating systems? It is very likely that by requiring IPv4LL to be turned off in the presence of DHCP we will prolong the life of AppleTalk and NetBIOS. Users will be unwilling to give up their ability to do local area networking on whatever link they are attached to, irrespective of whether DHCP can or will grant them an address. Note well: I have been to the IETF terminal room in several cities where the only users who could print were those with Macs running appletalk. Aren't there emerging IEEE protocols for granting access to networks? I know of some universities which require users to register their mac addresses or the switches will simply refuse to grant them access to the network. If administrators want to prevent access to the link, why not use L2 access control. I submit it is reasonable for a host to continue using a v4LL address *until it has been assigned a global address* by DHCP or some other means. We still get the advantages of removing the complexity of source address selection and application interoperability simplification. Erik From owner-zeroconf@merit.edu Fri Jan 24 05:46:14 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15345 for ; Fri, 24 Jan 2003 05:46:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E5E6E91435; Fri, 24 Jan 2003 05:49:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5EBCA91436; Fri, 24 Jan 2003 05:49: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 0B10491435 for ; Fri, 24 Jan 2003 05:49:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF0FA5DE75; Fri, 24 Jan 2003 05:49:07 -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 A17715DE1D for ; Fri, 24 Jan 2003 05:49:07 -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 B7B96598CD; Fri, 24 Jan 2003 10:49:08 +0000 (GMT) Message-ID: <01e301c2c396$38256240$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , "Scott Lawrence" Cc: "Keith Moore" , "Joshua Graessley" , References: Subject: Re: Turning off link-locals? Date: Fri, 24 Jan 2003 10:49:06 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Erik Guttman" > > If a host fails to get an address configured with DHCP, it will stop > using IPv4LL according to the current proposal, right? rfc2563 is rather more explicit - the DHCP server has to actively reply "Address=0 AND dont autoconfigure either". Simply not granting an address would not be enough. However despite rfc2563 saying autoconfiguring hosts MUST implement and honor this option I don't think any do. > There was concern that home gateway / cable modem vendors would abuse > this option to make home networking impossible unless managed by the > network service provider. > It should be possible, the argument goes, to > do home networking irregardless of the provider's policy. The answer to this issue is entirely political and has no technical content. Ultimately it will be resolved by commercial decisions - see above. Is this working group going to make a difference or is it simply deciding which horse to back? Philip From owner-zeroconf@merit.edu Fri Jan 24 07:01:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16490 for ; Fri, 24 Jan 2003 07:01:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 43D9191438; Fri, 24 Jan 2003 07:04:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09C7F91439; Fri, 24 Jan 2003 07:04: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 EA23591438 for ; Fri, 24 Jan 2003 07:04:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id A948A5E03F; Fri, 24 Jan 2003 07:04:17 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by segue.merit.edu (Postfix) with ESMTP id 88C3B5DEF5 for ; Fri, 24 Jan 2003 07:04:17 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18c2Z5-0004Df-00; Fri, 24 Jan 2003 04:04:08 -0800 Date: Fri, 24 Jan 2003 07:02:32 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, rdroms@cisco.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030124070232.58b51fcf.moore@cs.utk.edu> In-Reply-To: References: <20030123221559.3db565bc.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 is no business case for this - no customers are requesting it. that might change if LL finds wider use. From owner-zeroconf@merit.edu Fri Jan 24 07:01:20 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16503 for ; Fri, 24 Jan 2003 07:01:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 66E6691437; Fri, 24 Jan 2003 07:04:12 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1227B9143A; Fri, 24 Jan 2003 07:04:04 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7062F91437 for ; Fri, 24 Jan 2003 07:02:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 515CF5DEF5; Fri, 24 Jan 2003 07:02:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by segue.merit.edu (Postfix) with ESMTP id 30B7D5DE09 for ; Fri, 24 Jan 2003 07:02:25 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18c2XK-0007Gg-00; Fri, 24 Jan 2003 04:02:18 -0800 Date: Fri, 24 Jan 2003 07:00:42 -0500 From: Keith Moore To: Rod Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030124070042.110e40e9.moore@cs.utk.edu> In-Reply-To: References: <20030123232720.396d852d.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Rod, The arguments are getting circular, and we're not resolving anything, so we're simply going to have to disagree on this. I've seen several examples of cases where DHCP was used as the means to specify (and in some sense control, though not in a strict sense) whether a host had access to a network (effectively including the link). Maybe the mechanisms were imperfect, and maybe they didn't do anything to stop or even influence use of other protocols besides IP, but they are still found to be useful. And I don't think it's useful to pretend that LL is a separate protocol than IP and not subject to the controls present for IP. Keith (trying to minimize use of bandwidth!) From owner-zeroconf@merit.edu Fri Jan 24 07:56:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17216 for ; Fri, 24 Jan 2003 07:56:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 971B691205; Fri, 24 Jan 2003 07:59:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 68F879143A; Fri, 24 Jan 2003 07:59: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 388A591205 for ; Fri, 24 Jan 2003 07:59:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 20C625E00B; Fri, 24 Jan 2003 07:59:33 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by segue.merit.edu (Postfix) with ESMTP id 006D05DE0F for ; Fri, 24 Jan 2003 07:59:32 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18c3Qb-0006sM-00; Fri, 24 Jan 2003 04:59:25 -0800 Date: Fri, 24 Jan 2003 07:57:49 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, lawrence@world.std.com, jgraessley@apple.com, zeroconf@merit.edu Subject: Re: Turning off link-locals? Message-Id: <20030124075749.20c5112d.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > This reconfiguration comes at a significant cost of autonomy for the > consumer. It means that if a DHCP server is present on the link (due to > an attacker, an incompetent, greedy or intolerant service provider, etc) > networking can be made impossible. No, not impossible. It just requires a human user to say "do it anyway". what is being asked for is a way for DHCP to set the automatic behavior, not a way for DHCP to prevent a host from connecting. Personally I don't want my computer to go around attempting to connect to any random network that it can talk to. I want to specify explicitly when to connect. If it's a wired network then media sense is probably sufficient. But if it's a wireless network then I want to say "yes, connect" and I probably want to specify which network I'm connecting to (since there can be more than one). Just because it's an ad hoc network doesn't mean that everybody wants to connect, or for that matter, that anybody who wants to connect is welcome to do so. If I plug my computer into a hub on a table top, or if I tell it to connect to some group of hosts with wireless interfaces, I'm making a decision to do that based on whether I think it is useful for me to do so and whether I trust the other people on that network. If anybody is allowed to join without being noticed, the trust level goes way down. The whole concern about attacking an ad hoc network seems to be misplaced. It's not that ad hoc networks can't be attacked (they certainly can); it's the idea that preventing a DoS attack via DHCP reduces the threat at all. Or more generally, that it is feasible for ad hoc networks to resist attack. (Is the attacker really going to say, "well since the hosts will ignore a DCHP message telling them not to use the network, I'll just give up", or is he going to say "I think I'll foil any attempt to claim a new IP address"?) In a managed network, when you can't connect because DHCP won't assign you an address, you call tech support. In an ad hoc network, when you can't connect because a DHCP server says "don't use LL", you look at the other folks using the network and ask "which one of you idiots has a DHCP server running?" From owner-zeroconf@merit.edu Fri Jan 24 07:56:36 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17298 for ; Fri, 24 Jan 2003 07:56:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 533719143C; Fri, 24 Jan 2003 07:59:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10FCF9143B; Fri, 24 Jan 2003 07:59: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 775879143A for ; Fri, 24 Jan 2003 07:59:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6596F5DE0F; Fri, 24 Jan 2003 07:59:47 -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 E09E45E00B for ; Fri, 24 Jan 2003 07:59:46 -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 HAA15388 for ; Fri, 24 Jan 2003 07:59:46 -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 HAA28743 for ; Fri, 24 Jan 2003 07:57:05 -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 HAA10233 for ; Fri, 24 Jan 2003 07:52:19 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 24 Jan 2003 07:52:19 -0500 Subject: Re: Turning off link-locals? 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 01/24/2003 02:40, "Christian Huitema" wrote: > The reasonable option would thus be to define an explict DHCP option to > "ignore LL", and have that option affect the behavior of the configured hosts. So now we redefine DHCP? john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Jan 24 07:56:58 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17400 for ; Fri, 24 Jan 2003 07:56:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7987A9143A; Fri, 24 Jan 2003 07:59:54 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4AD669143B; Fri, 24 Jan 2003 07:59: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 3FA679143A for ; Fri, 24 Jan 2003 07:59:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 114B25E00B; Fri, 24 Jan 2003 07:59:50 -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 9D7DC5DE0F for ; Fri, 24 Jan 2003 07:59:49 -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 HAA15409 for ; Fri, 24 Jan 2003 07:59:49 -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 HAA28767 for ; Fri, 24 Jan 2003 07:57:07 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id HAA10104 for ; Fri, 24 Jan 2003 07:51:15 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 24 Jan 2003 07:51:15 -0500 Subject: Re: Turning off link-locals? From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <7B616705-2F62-11D7-8363-003065A87BBE@mac.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 01/24/2003 01:10, "Rod" wrote: >> Ifconfig en0 off > > Nice try John, but no, that's not turning TCP/IP off via a mechanism > defined in its specs, that's turning the ethernet interface off. You > can do that to disable IPv4LL as well, yet you are still asking for a > switch to disable it aren't you? :-) I am, because there are clear needs to have that level of control in a high security environment where every packet has to be accounted for. This is not a maybe, those environments exist today. They existed years ago when I worked in them. > > You're actually backing up my point, that the way to block/disable a > protocol should not be the job of the protocol itself. I don't actually *care* where the switch is. I even suggested it *be* a new option for ifconfig, i.e. ifconfig en0 nov4LL But there is a need to have an explicit off switch. DHCP killing addressing while allowing communication isn't going to be enough, and a manual switch here allows for far more flexibility in controlling v4LL if you need to. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Jan 24 08:08:12 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17664 for ; Fri, 24 Jan 2003 08:08:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 995CE9143D; Fri, 24 Jan 2003 08:11:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F4539143E; Fri, 24 Jan 2003 08:11: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 201EF9143D for ; Fri, 24 Jan 2003 08:11:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 026D15E045; Fri, 24 Jan 2003 08:11:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 8E7305DDA8 for ; Fri, 24 Jan 2003 08:11:27 -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 IAA18084 for ; Fri, 24 Jan 2003 08:11: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 IAA20515 for ; Fri, 24 Jan 2003 08:07:07 -0500 (EST) Received: from [10.0.0.14] (cpe-66-189-8-245.ma.charter.com [66.189.8.245]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id IAA11398 for ; Fri, 24 Jan 2003 08:01:57 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 24 Jan 2003 08:01:57 -0500 Subject: Re: Turning off link-locals? 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 01/24/2003 05:04, "Erik Guttman" wrote: > It is *very strange* that Internet Standardization Veterans are arguing > that stronger central administration and control of LANs should be > mandatory, while network administrators from 2 universities and consumer > client networking computer vendors continue to argue that this is > neither desirable nor necessary. I'm arguing for real control, as you illustrate very neatly below why the DHCP option *alone* has real problems that aren't theoretical. > > It *is desirable* for hosts to be required to reconfigure to using > global instead of LL addresses when DHCP, etc makes the global address > available because this offers *architectural advantages,* as it > simplifies > > - source address selection > - application interoperability with the rest of the network > > This reconfiguration comes at a significant cost of autonomy for the > consumer. It means that if a DHCP server is present on the link (due to > an attacker, an incompetent, greedy or intolerant service provider, etc) > networking can be made impossible. There are even disadvantages for > local administrators: In conditions where DHCP fails (due to > misconfiguration, for example) it will be impossible to reach hosts on a > LAN to administer them except by a serial cable, an out-of-band IP > network or some other expensive and improbable mechanism. Right...without some manual override, grammy is royally screwed, and most likely, going to not be happy with her computer vendor. There actually is a very clear example of what happens when you totally rely on automatic systems: The F-16 It's one of the only planes, civilian or military with a fly-by-wire *only* system. If the plane loses its electrical systems, or total power, there is no way to control it and you eject. The f-16 has a three-level power backup system, and still the things crash regularly because if the power goes, it's an uncontrollable brick. With other aircraft, such as the B-1B, (pardon the military focus, I have experience here.), you have a cable/manual backup. You don't normally use it, but when it is needed, it's there. You need a manual backup. Even Appletalk allowed for manual addressing. You didn't always use it, in fact, it was pretty silly *to* normally use it. But when you needed it, it was there. We cannot assume that an automatic system such as DHCP control over v4LL will always work. So a manual backup is needed. Making it a required part of the spec is responsible. Note that I am not saying we dictate implementation. That would be dumb. If the vendor wants to modify something like ifconfig, include a button on an embedded web config, make it a physical button on the back of the device, *whatever*, as long as it is there. I would prefer a non-physical method, but if enough customers complain, the vendor will change it. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Fri Jan 24 08:37:33 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18898 for ; Fri, 24 Jan 2003 08:37:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA94E9143F; Fri, 24 Jan 2003 08:40:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC9B991440; Fri, 24 Jan 2003 08:40: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 BAA179143F for ; Fri, 24 Jan 2003 08:40:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9EFAB5E04F; Fri, 24 Jan 2003 08:40:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id 353E15E045 for ; Fri, 24 Jan 2003 08:40:49 -0500 (EST) Received: from jschnizl-w2k.cisco.com (rtp-vpn1-30.cisco.com [10.82.224.30]) by sj-msg-core-3.cisco.com (8.12.2/8.12.6) with ESMTP id h0ODecB9002004; Fri, 24 Jan 2003 05:40:45 -0800 (PST) Message-Id: <4.3.2.7.2.20030124083411.01f49978@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Jan 2003 08:40:39 -0500 To: "John C. Welch" From: John Schnizlein Subject: Re: Turning off link-locals? Cc: Zeroconf In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk At 07:52 AM 1/24/2003, John C. Welch wrote: >On 01/24/2003 02:40, "Christian Huitema" >wrote: > >> The reasonable option would thus be to define an explict DHCP option >> to "ignore LL", and have that option affect the behavior of the >> configured hosts. > >So now we redefine DHCP? Of course not. It might be that Christian's suggestion implies revision of RFC 2563, for which Ralph has already written a draft. In any case, defining an option, or redefining that one, it is just an option, not DHCP that needs fixing. Options are the deliberately extensible part of DHCP. John Maybe you missed Philip's email: At 10:44 AM 1/23/2003, Philip Nye wrote: >Digging around in DHCP I found RFC2563 From owner-zeroconf@merit.edu Fri Jan 24 09:43:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21065 for ; Fri, 24 Jan 2003 09:43:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8125A91244; Fri, 24 Jan 2003 09:46:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D32891441; Fri, 24 Jan 2003 09:46: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 5C3EB91244 for ; Fri, 24 Jan 2003 09:46:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id A6C3A5E05B; Fri, 24 Jan 2003 09:45:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 9880E5E05C for ; Fri, 24 Jan 2003 09:45:45 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0OEjDR21570; Fri, 24 Jan 2003 21:45:13 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0OEjA823260; Sat, 25 Jan 2003 01:45:12 +1100 (EST) From: Robert Elz To: Ted Lemon Cc: "Zeroconf" Subject: Re: Turning off link-locals? In-Reply-To: <81BA292B-2F1E-11D7-B72A-00039317663C@nominum.com> References: <81BA292B-2F1E-11D7-B72A-00039317663C@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Jan 2003 21:45:10 +0700 Message-ID: <23258.1043419510@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 23 Jan 2003 14:03:30 -0800 From: Ted Lemon Message-ID: <81BA292B-2F1E-11D7-B72A-00039317663C@nominum.com> | Does the mDNS spec say that this is what should happen? Does the | IPv4ll spec say it? :'} What they say now, and what they will say before they're completed, is part of what is being worked on here... kre From owner-zeroconf@merit.edu Fri Jan 24 09:44:21 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21101 for ; Fri, 24 Jan 2003 09:44:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3379491469; Fri, 24 Jan 2003 09:47:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA7099146C; Fri, 24 Jan 2003 09:47: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 7930391469 for ; Fri, 24 Jan 2003 09:46:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 27D495E067; Fri, 24 Jan 2003 09:45:50 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 66C555DFCE for ; Fri, 24 Jan 2003 09:45:20 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0OEiIR21531; Fri, 24 Jan 2003 21:44:21 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0OEiG823250; Sat, 25 Jan 2003 01:44:17 +1100 (EST) From: Robert Elz To: Ralph Droms Cc: zeroconf@merit.edu Subject: Re: Turning off link-locals? In-Reply-To: <4.3.2.7.2.20030123184057.03a69f38@funnel.cisco.com> References: <4.3.2.7.2.20030123184057.03a69f38@funnel.cisco.com> <4.3.2.7.2.20030123181824.039bef58@funnel.cisco.com> <010301c2c2f6$42226950$131010ac@aldebaran> <3450D7C8-2E35-11D7-AFDA-00039317663C@nominum.com> <18535.1043336087@munnari.OZ.AU> <010301c2c2f6$42226950$131010ac@aldebaran> <4.3.2.7.2.20030123181824.039bef58@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Jan 2003 21:44:16 +0700 Message-ID: <23248.1043419456@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 23 Jan 2003 19:09:42 -0500 From: Ralph Droms Message-ID: <4.3.2.7.2.20030123184057.03a69f38@funnel.cisco.com> | So, now the idea is written up as a draft and we can discuss it. Or let it | expire if it's no longer a good idea. Yes, that's fine. I agree with Keith - the draft makes no sense... In addition to what he said, the analysis of the problem in the draft seems incorrect to me. It is absurd for me to explain DHCP to you (or to Ted) but ... How can a rogue DHCP server possibly deny access using the mechanisms in RFC2563 (assuming a rationally constructed client). If there's no other DHCP server, then such a server could prevent a node from assigning itself a LL address, which it would otherwise do in the absence of a DHCP server. But there's no need to go to all the work of emulating a DHCP server to achieve that - all that's needed is to answer ARP requests for LL addresses (either those coming from anyone, or those from a specific MAC address, depending upon the desire). So, in this case (no other DHCP servers) 2563 is no worse than what already exists. [The rogue DHCP server needs to be on the link, or have a rogue relay agent on the link, so ARP attacks work just fine]. If there is another DHCP server, then the client is going to get two (or more) offers. It then chooses the one it wants to use. I know that if I was writing a client, and I got an offer which said "no addresses for you" and another that said "here's an address you can use" (or even "configure yourself a LL address") then I know which offer would be the one I'd be picking. Even a "dumb" client that simply takes the first offer it receives and uses it could easily learn to ignore "no address" offers and wait for something better - if something better arrives, then fine, if not, there's no great harm done, the network isn't going to work anyway. If anything, the problem with RFC2563 is that it allows a rogue DHCP server to enable LL addresses that the "real" DHCP server is attempting to prevent, but as Keith said, this is just a general issue with the use of DHCP (or any other automatic configuration mechanism for that matter) and nothing at all specific to 2563. The justification in the draft for deprecating that RFC is inadequate. On the other hand ... Ted.Lemon@nominum.com said: | As far as I know, nobody's implemented it in all this time, even though | clients using IPv4 link-local addressing have been around for a long time. That would be a much better justification for deleting it. Except that there are only a couple of IPv4 link local implementations (I believe), which have been implemented with little guidance of how they should be done (they don't even agree with each other, or interoperate properly if I have read this list correctly). That's what this WG is trying to fix. If this WG were to say "the right way is to implement RFC2563" then I suspect that you'd start to see implementations. Ted.Lemon@nominum.com quoted Keith Moore and then said: | > well, you've heard several people ask for similar functionality here. | Right, and zero of them have sent a patch to the ISC. Huh? Why would anyone be sending ISC a patch for this? The ISC server already supports the option, all that is needed is option useLL code 116 = boolean; in the dhcpd.conf file, along with option useLL on; or option useLL off; as required. The ISC client doesn't configure LL addresses, last time I looked anyway, so the option is irrelevant to it. If the ISC client starts autoconfiguring LL addresses when it fails to get a DHCP address, you can be sure that you'll get a patch to allow that to be disabled. kre From owner-zeroconf@merit.edu Fri Jan 24 10:00:32 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21651 for ; Fri, 24 Jan 2003 10:00:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EA86D91441; Fri, 24 Jan 2003 10:01:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB9BB91442; Fri, 24 Jan 2003 10:01: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 6EFFE91441 for ; Fri, 24 Jan 2003 10:01:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4D0525DFCE; Fri, 24 Jan 2003 10:01:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id E87145DE71 for ; Fri, 24 Jan 2003 10:01:05 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0OF0xR22130 for ; Fri, 24 Jan 2003 22:01:00 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0OF0h823287 for ; Sat, 25 Jan 2003 02:00:43 +1100 (EST) From: Robert Elz To: zeroconf@merit.edu Subject: Solving the wrong problems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Jan 2003 22:00:43 +0700 Message-ID: <23285.1043420443@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk There's been too much discussion on this list recently which is ignoring the issues that actually matter, and concentrating on chasing red herrings. All of the stuff about what to do with rogue servers, malicious nodes, and illicit network use is irrelevant. Unless something being proposed actually makes one of those issues worse than it would otherwise be, which no-one has been doing I believe (leaving aside the question of whether having LL addresses at all causes such problems). That is, for example, the desire to have a way to disable LL addresses isn't so that the network manager can make sure that no-one can use the net without their permission, or similar, that's ludicrous, the node(s) could just configure themselves with network 10 addresses, or 192.168, or anything else (including addresses from the block that are designated for use on the net in question). The reason is because the net manager knows what will, and won't work properly on their net, and can provide advice to the nodes as to what they should do in order to work well in the local environment. There's also no-one (sane anyway) around here pretending that any kind of protocol message like this can override what the end user of the device actually wants to do - that is, if you manually (however that's defined...) configure the device to generate (or not) a LL address, then of course, that is what it will do (I mean, no-one is suggesting that ifconfig interface LL-address should fail, are they?) I have yet to hear anyone explain why they would want (as a software author, sending code into environments of which they have no knowledge at all) to ignore the desires of the local network and simply do things their own way. If anything, the closest to this was the "because it is simpler" argument, which would actually be a reasonable one if it wasn't simply wrong. So, can we all please ignore the "but I could if I wanted to simply make my box do ..." type nonsense arguments as a justification for "so I may as well do it automatically always" conclusion. It is nonsense. kre From owner-zeroconf@merit.edu Fri Jan 24 11:24:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24058 for ; Fri, 24 Jan 2003 11:24:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7810291232; Fri, 24 Jan 2003 11:27:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49FBD91245; Fri, 24 Jan 2003 11:27: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 43D8F91232 for ; Fri, 24 Jan 2003 11:27:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 26CF05DF0E; Fri, 24 Jan 2003 11:27:33 -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 86D585DDDB for ; Fri, 24 Jan 2003 11:27:32 -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 IAA03536; Fri, 24 Jan 2003 08:27:30 -0800 (PST) Received: from sun.com (vpn-129-159-0-167.EMEA.Sun.COM [129.159.0.167]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h0OGRRl16004; Fri, 24 Jan 2003 17:27:27 +0100 (MET) Message-ID: <3E31672C.2010902@sun.com> Date: Fri, 24 Jan 2003 17:17:48 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Robert Elz Cc: zeroconf@merit.edu Subject: Re: Solving the wrong problems References: <23285.1043420443@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > There's been too much discussion on this list recently which > is ignoring the issues that actually matter, and concentrating > on chasing red herrings. Let's decide this point once and for all then: > I have yet to hear anyone explain why they would want (as a software > author, sending code into environments of which they have no knowledge > at all) to ignore the desires of the local network and simply do things > their own way. Appletalk and NetBIOS still ship. They work *in every LAN environment.* Local networking with IP has not worked for consumers. (By the way, those are people who *cannot* set their IP address manually). This is because there are environments where - there is no DHCP, and no configured address (There is no disagreement here about how things should work.) - there is DHCP (There is some disagreement, but it looks like a rough WG consensus is emerging that when a host gets configuration with DHCP it will no longer use its own v4LL address.) - there is a DHCP server but it will not give the host an address (Here there is more disagreement.) The question is: Is it acceptable that a host which cannot get an address from DHCP should then give up its IPv4LL configuration and effectively shut down? Is this a rare enough event that consumer networking vendors will be satisfied that IP isn't totally unreliable compared to Appletalk, etc? Erik From owner-zeroconf@merit.edu Fri Jan 24 11:30:47 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24223 for ; Fri, 24 Jan 2003 11:30:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AB29A91245; Fri, 24 Jan 2003 11:34:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76D1391247; Fri, 24 Jan 2003 11:34: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 58D9891245 for ; Fri, 24 Jan 2003 11:33:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3A0715DFAF; Fri, 24 Jan 2003 11:33:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 20F965DF5B for ; Fri, 24 Jan 2003 11:33:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id CEE3914010; Fri, 24 Jan 2003 11:33:06 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 03569-10; Fri, 24 Jan 2003 11:33:01 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 8090A1409A; Fri, 24 Jan 2003 11:33:01 -0500 (EST) Date: Fri, 24 Jan 2003 11:33:01 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: Solving the wrong problems Message-Id: <20030124113301.74e60736.moore@cs.utk.edu> In-Reply-To: <3E31672C.2010902@sun.com> References: <23285.1043420443@munnari.OZ.AU> <3E31672C.2010902@sun.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 3f66180dd8d6abed45db6a8e4087491b468e0ac0 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Local networking with IP has not worked for consumers. (By the way, > those are people who *cannot* set their IP address manually). This > is because there are environments where > > - there is no DHCP, and no configured address > (There is no disagreement here about how things should work.) > > - there is DHCP > (There is some disagreement, but it looks like a rough WG > consensus > is emerging that when a host gets configuration with DHCP it will > no longer use its own v4LL address.) > > - there is a DHCP server but it will not give the host an address > (Here there is more disagreement.) > > The question is: Is it acceptable that a host which cannot get > an address from DHCP should then give up its IPv4LL configuration > and effectively shut down? I think the question is slightly different: Is it acceptable that a host which is refused an address from DHCP should not configure an IPv4LL address without explicit user approval? ("refused an address" being different than "DHCP did not answer") Keith p.s. I mean, don't you want user approval anyway before you start accepting packets from and sending packets to a strange network? From owner-zeroconf@merit.edu Fri Jan 24 11:37:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24392 for ; Fri, 24 Jan 2003 11:37:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E36B491247; Fri, 24 Jan 2003 11:40:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B10C691443; Fri, 24 Jan 2003 11:40: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 7A6E891247 for ; Fri, 24 Jan 2003 11:40:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5F6D15DFAF; Fri, 24 Jan 2003 11:40:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id EEDD25DED1 for ; Fri, 24 Jan 2003 11:40:44 -0500 (EST) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id LAA10706; Fri, 24 Jan 2003 11:40:38 -0500 (EST) From: "Subrata Goswami" To: "'Erik Guttman'" Cc: Subject: RE: Solving the wrong problems Date: Fri, 24 Jan 2003 08:34:44 -0800 Message-ID: <00a801c2c3c6$87ca05a0$c900a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3E31672C.2010902@sun.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Is it acceptable that a host which cannot > get an address from DHCP should then give up its IPv4LL > configuration and effectively shut down? Can you please clarify what you mean by this question ? Why are you tying IPv4LL with DHCP ? I would think the following is a more comprehensive list of scenerios. 1. DHCP Server Present, DHCP Client Present Client first tries Manual Then DHCP Then LL 2. DHCP Server Present, DHCP Client Absent Client first tries Manual Then LL 3. DHCP Server Absent, Client first tries Manual Then LL Subrata > -----Original Message----- > From: owner-zeroconf@merit.edu > [mailto:owner-zeroconf@merit.edu] On Behalf Of Erik Guttman > Sent: Friday, January 24, 2003 8:18 AM > To: Robert Elz > Cc: zeroconf@merit.edu > Subject: Re: Solving the wrong problems > > > Robert Elz wrote: > > There's been too much discussion on this list recently which is > > ignoring the issues that actually matter, and concentrating > on chasing > > red herrings. > > Let's decide this point once and for all then: > > > I have yet to hear anyone explain why they would want (as a > software > > author, sending code into environments of which they have > no knowledge > > at all) to ignore the desires of the local network and simply do > > things their own way. > > Appletalk and NetBIOS still ship. They work *in every LAN > environment.* > > Local networking with IP has not worked for consumers. (By > the way, those are people who *cannot* set their IP address > manually). This is because there are environments where > > - there is no DHCP, and no configured address > (There is no disagreement here about how things should work.) > > - there is DHCP > (There is some disagreement, but it looks like a rough WG > consensus > is emerging that when a host gets configuration with DHCP it will > no longer use its own v4LL address.) > > - there is a DHCP server but it will not give the host an address > (Here there is more disagreement.) > > The question is: Is it acceptable that a host which cannot > get an address from DHCP should then give up its IPv4LL > configuration and effectively shut down? Is this a rare > enough event that consumer networking vendors will be > satisfied that IP isn't totally unreliable compared to Appletalk, etc? > > Erik > From owner-zeroconf@merit.edu Fri Jan 24 11:48:32 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24594 for ; Fri, 24 Jan 2003 11:48:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9267491443; Fri, 24 Jan 2003 11:51:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E4C991444; Fri, 24 Jan 2003 11:51: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 2864691443 for ; Fri, 24 Jan 2003 11:51:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 78A785DFAF; Fri, 24 Jan 2003 11:51:42 -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 3754A5DF5B for ; Fri, 24 Jan 2003 11:51:42 -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, 24 Jan 2003 08:51:41 -0800 Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 24 Jan 2003 08:51:41 -0800 Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 24 Jan 2003 08:51:41 -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, 24 Jan 2003 08:51:40 -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.3718.0); Fri, 24 Jan 2003 08:51:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Solving the wrong problems Date: Fri, 24 Jan 2003 08:51:39 -0800 Message-ID: Thread-Topic: Solving the wrong problems Thread-Index: AcLDxYqXn04SbzDFSeuDLJcrcrSnzwAArpUA From: "Christian Huitema" To: "Erik Guttman" , "Robert Elz" Cc: X-OriginalArrivalTime: 24 Jan 2003 16:51:40.0410 (UTC) FILETIME=[DDEF05A0:01C2C3C8] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA24594 > > I have yet to hear anyone explain why they would want (as a software > > author, sending code into environments of which they have no knowledge > > at all) to ignore the desires of the local network and simply do things > > their own way. > > Appletalk and NetBIOS still ship. They work *in every LAN environment.* Kind of. Both require multicast, and multicast is problematic in two types of LAN environment. It is problematic in large networks, because typically too chatty. It is also problematic in wireless network, because of reliability issue; for example, 802.11 includes a low level packet repetition algorithm, but that algorithm is not used for multicast packets. -- Christian Huitema From owner-zeroconf@merit.edu Fri Jan 24 11:49:32 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24659 for ; Fri, 24 Jan 2003 11:49:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2DCD791444; Fri, 24 Jan 2003 11:52:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFD0591445; Fri, 24 Jan 2003 11:52:44 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EBAF691444 for ; Fri, 24 Jan 2003 11:52:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id D5A735E019; Fri, 24 Jan 2003 11:52:43 -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 E36F45DFCE for ; Fri, 24 Jan 2003 11:52:42 -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 h0OGqcjf022163; Sat, 25 Jan 2003 02:52:39 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id h0OGqaN35583; Sat, 25 Jan 2003 02:52:36 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Sat, 25 Jan 2003 02:52:36 +1000 (EST) From: Ian Lister X-X-Sender: ilister@sapporo.home To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: Turning off link-locals? 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: -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, 24 Jan 2003, Erik Guttman wrote: >I submit it is reasonable for a host to continue using a v4LL address >*until it has been assigned a global address* by DHCP or some other >means. We still get the advantages of removing the complexity of source >address selection and application interoperability simplification. I concur. (fwiw) Ian From owner-zeroconf@merit.edu Fri Jan 24 11:56:14 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24753 for ; Fri, 24 Jan 2003 11:56:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6881D9144B; Fri, 24 Jan 2003 11:56:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DDD091448; Fri, 24 Jan 2003 11:56: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 E0FBC91447 for ; Fri, 24 Jan 2003 11:56:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id CE9365E019; Fri, 24 Jan 2003 11:56:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id 69EF15DF5B for ; Fri, 24 Jan 2003 11:56:54 -0500 (EST) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id LAA15639; Fri, 24 Jan 2003 11:56:52 -0500 (EST) From: "Subrata Goswami" To: "'Christian Huitema'" Cc: Subject: RE: Solving the wrong problems Date: Fri, 24 Jan 2003 08:51:09 -0800 Message-ID: <00b401c2c3c8$cc28d9e0$c900a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Question - can you please provide a quatitative idea of large ? In the context of LL, how big a subnet do you think is large enough ? Subrata > -----Original Message----- > From: owner-zeroconf@merit.edu > [mailto:owner-zeroconf@merit.edu] On Behalf Of Christian Huitema > Sent: Friday, January 24, 2003 8:52 AM > To: Erik Guttman; Robert Elz > Cc: zeroconf@merit.edu > Subject: RE: Solving the wrong problems > > > > > I have yet to hear anyone explain why they would want (as > a software > > > author, sending code into environments of which they have no > knowledge > > > at all) to ignore the desires of the local network and simply do > things > > > their own way. > > > > Appletalk and NetBIOS still ship. They work *in every LAN > environment.* > > Kind of. Both require multicast, and multicast is problematic > in two types of LAN environment. It is problematic in large > networks, because typically too chatty. It is also > problematic in wireless network, because of reliability > issue; for example, 802.11 includes a low level packet > repetition algorithm, but that algorithm is not used for > multicast packets. > > -- Christian Huitema > From owner-zeroconf@merit.edu Fri Jan 24 12:03:21 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24986 for ; Fri, 24 Jan 2003 12:03:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 88A9591248; Fri, 24 Jan 2003 12:03:59 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2597F91246; Fri, 24 Jan 2003 12:03:59 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED5BB91447 for ; Fri, 24 Jan 2003 12:03:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id B14CF5DFCE; Fri, 24 Jan 2003 12:03:07 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 458555DF5B for ; Fri, 24 Jan 2003 12:03:07 -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 MAA28759 for ; Fri, 24 Jan 2003 12:03:05 -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 MAA19337 for ; Fri, 24 Jan 2003 12:03:05 -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 MAA18775 for ; Fri, 24 Jan 2003 12:03:04 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Fri, 24 Jan 2003 12:02:59 -0500 Subject: Re: Solving the wrong problems From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <3E31672C.2010902@sun.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 01/24/2003 11:17, "Erik Guttman" wrote: > The question is: Is it acceptable that a host which cannot get > an address from DHCP should then give up its IPv4LL configuration > and effectively shut down? Is this a rare enough event that > consumer networking vendors will be satisfied that IP isn't > totally unreliable compared to Appletalk, etc? No. I can explain why, but I think every POV is well understood by 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 Jan 24 12:13:44 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25184 for ; Fri, 24 Jan 2003 12:13:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 27CF991246; Fri, 24 Jan 2003 12:16:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86F3191447; Fri, 24 Jan 2003 12:16: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 AD0AB91246 for ; Fri, 24 Jan 2003 12:16:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7E21F5DFC8; Fri, 24 Jan 2003 12:16:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by segue.merit.edu (Postfix) with ESMTP id 2FF1F5DFAF for ; Fri, 24 Jan 2003 12:16:41 -0500 (EST) Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 24 Jan 2003 09:16:40 -0800 Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 24 Jan 2003 09:16:40 -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); Fri, 24 Jan 2003 09:16:42 -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); Fri, 24 Jan 2003 09:16:40 -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.3718.0); Fri, 24 Jan 2003 09:16:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Solving the wrong problems Date: Fri, 24 Jan 2003 09:16:39 -0800 Message-ID: Thread-Topic: Solving the wrong problems Thread-Index: AcLDyZ99Vr/5yDZ9RIW8RMf/ow0lAgAAQ+XA From: "Christian Huitema" To: "Subrata Goswami" Cc: X-OriginalArrivalTime: 24 Jan 2003 17:16:39.0769 (UTC) FILETIME=[5B9F0C90:01C2C3CC] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA25184 > Question - can you please provide a quatitative idea of large ? > In the context of LL, how big a subnet do you think is large enough ? How a large can a network be for multicast to become problematic? There are really three parameters: number of hosts N, frequency of multicast operation noted as 1/T where T is the average period, and reasonable frequency of multicast messages. I would say that anything that results in more than 100 multicast per second is unacceptable in most networks; so you get a condition of N/T < 100. Now, you get to estimate T; if you use multicast for name resolution, as basic NetBIOS does, T can be as low as a few tens of seconds; for T = 30 sec, you get a problem if N > 3000. There are also aggravating factors. In some configurations, networks are bridged through point-to-point links; the multicast chat can in some cases congest these links. There are also some situations in which the responses to a multicast packet trigger a "packet storm", a very undesirable event. Note that NetBIOS is mostly used over IP nowadays, and that those large networks that use NetBIOS tend to also use WINS, i.e. a centralized name resolution service for NetBIOS. -- Christian Huitema From owner-zeroconf@merit.edu Fri Jan 24 12:40:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26067 for ; Fri, 24 Jan 2003 12:40:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0AF2B91249; Fri, 24 Jan 2003 12:43:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CEBF591447; Fri, 24 Jan 2003 12:43:43 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8DFDA91249 for ; Fri, 24 Jan 2003 12:43:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 742BB5DFAF; Fri, 24 Jan 2003 12:43:42 -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 E72D05DF34 for ; Fri, 24 Jan 2003 12:43:41 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0OHcqP18650; Fri, 24 Jan 2003 11:38:52 -0600 (CST) Date: Fri, 24 Jan 2003 09:43:51 -0800 Subject: Re: Turning off link-locals? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Keith Moore" , , To: "Christian Huitema" From: Ted Lemon In-Reply-To: Message-Id: <66A99821-2FC3-11D7-B72A-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Obviously, there are two options, and these are really two options for > conformant hosts: continue interacting with LL addresses after being > configured with a routable address, or don't. In sake of the > robustness principle, I clearly see the case for continuing > interacting. However, Keith also made the point for giving some > control to the local admin. The reasonable option would thus be to > define an explict DHCP option to "ignore LL", and have that option > affect the behavior of the configured hosts. I think this is a good compromise, and I don't object to it, but again I question whether or not anybody's going to bother to implement it in a client. From owner-zeroconf@merit.edu Fri Jan 24 12:47:55 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26364 for ; Fri, 24 Jan 2003 12:47:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1282891447; Fri, 24 Jan 2003 12:51:06 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE7A191448; Fri, 24 Jan 2003 12:51: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 C8D3191447 for ; Fri, 24 Jan 2003 12:51:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id B2F5F5E00E; Fri, 24 Jan 2003 12:51:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 87B405DF34 for ; Fri, 24 Jan 2003 12:51:02 -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 JAA04596; Fri, 24 Jan 2003 09:51:00 -0800 (PST) Received: from sun.com (vpn-129-159-0-167.EMEA.Sun.COM [129.159.0.167]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h0OHovl19041; Fri, 24 Jan 2003 18:50:57 +0100 (MET) Message-ID: <3E317AC0.6060700@sun.com> Date: Fri, 24 Jan 2003 18:41:20 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Subrata Goswami Cc: zeroconf@merit.edu Subject: Re: Solving the wrong problems References: <00a801c2c3c6$87ca05a0$c900a8c0@SGOSWAMIPCL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subrata Goswami wrote: >>Is it acceptable that a host which cannot >>get an address from DHCP should then give up its IPv4LL >>configuration and effectively shut down? > > Can you please clarify what you mean by this question ? Why are you > tying IPv4LL with DHCP ? I would think the following is a more > comprehensive list of scenerios. We agree that if the client gets an address somehow (DHCP, manual configuration, whatever) it will use it. What we are not agreement about is the behavior of the host which cannot get address configuration except through the use of IPv4LL. Erik From owner-zeroconf@merit.edu Fri Jan 24 12:55:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26717 for ; Fri, 24 Jan 2003 12:55:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD28491448; Fri, 24 Jan 2003 12:58:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8F6891449; Fri, 24 Jan 2003 12:58: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 AD02A91448 for ; Fri, 24 Jan 2003 12:58:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8A4BD5E01D; Fri, 24 Jan 2003 12:58:56 -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 0CD685DFAF for ; Fri, 24 Jan 2003 12:58:56 -0500 (EST) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05796; Fri, 24 Jan 2003 10:58:54 -0700 (MST) Received: from sun.com (vpn-129-159-0-167.EMEA.Sun.COM [129.159.0.167]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h0OHwol19221; Fri, 24 Jan 2003 18:58:51 +0100 (MET) Message-ID: <3E317C98.2030409@sun.com> Date: Fri, 24 Jan 2003 18:49:12 +0100 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Keith Moore Cc: kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: Solving the wrong problems References: <23285.1043420443@munnari.OZ.AU> <3E31672C.2010902@sun.com> <20030124113301.74e60736.moore@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 > ("refused an address" being different than "DHCP did not answer") DHCPNAK is the way that DHCP can respond to refuse a client an address, right? This could mean the DHCP server has no more addresses to give out. Or it could mean the administrator doesn't know the requester's mac address and doesn't want to give out a routable IP address. Or it could mean something else. Erik From owner-zeroconf@merit.edu Fri Jan 24 13:01:00 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26850 for ; Fri, 24 Jan 2003 13:00:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4BFA491449; Fri, 24 Jan 2003 13:04:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1FE9B9144A; Fri, 24 Jan 2003 13:04:11 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3FB6991449 for ; Fri, 24 Jan 2003 13:04:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 27F015DFAF; Fri, 24 Jan 2003 13:04:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by segue.merit.edu (Postfix) with ESMTP id 933075DF01 for ; Fri, 24 Jan 2003 13:04:04 -0500 (EST) Received: from zektor.gpcc.itd.umich.edu (zektor.gpcc.itd.umich.edu [141.211.2.203]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id NAA16291; Fri, 24 Jan 2003 13:04:04 -0500 (EST) Received: from localhost (sgoswami@localhost) by zektor.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id NAA10595; Fri, 24 Jan 2003 13:04:03 -0500 (EST) Date: Fri, 24 Jan 2003 13:04:03 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@zektor.gpcc.itd.umich.edu To: Christian Huitema Cc: zeroconf@merit.edu Subject: RE: Solving the wrong problems In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Thanks, that certainly is very helpful. So in a nework of N nodes and f (mcast per second) frequencey, there would be Nf mcast messages. If each multicast message has p bytes, then each host would receive traffic of (N-1)fp bytes per second. Substituting 3000 for N, 100 for f, and 1000 bytes for p. We get that each host would need to have a pipe of capacity > 300,000,000 bytes per second. More than what Fast Ethernet (100 Mbps) offers. So we would need to reduce N to 300, f to 1 and p to 100 to get to 30,000 bps. A LL network probably would not be larger than 300 hosts (?). Subrata On Fri, 24 Jan 2003, Christian Huitema wrote: > > Question - can you please provide a quatitative idea of large ? > > In the context of LL, how big a subnet do you think is large enough ? > > How a large can a network be for multicast to become problematic? There > are really three parameters: number of hosts N, frequency of multicast > operation noted as 1/T where T is the average period, and reasonable > frequency of multicast messages. I would say that anything that results > in more than 100 multicast per second is unacceptable in most networks; > so you get a condition of N/T < 100. Now, you get to estimate T; if you > use multicast for name resolution, as basic NetBIOS does, T can be as > low as a few tens of seconds; for T = 30 sec, you get a problem if N > > 3000. > > There are also aggravating factors. In some configurations, networks are > bridged through point-to-point links; the multicast chat can in some > cases congest these links. There are also some situations in which the > responses to a multicast packet trigger a "packet storm", a very > undesirable event. > > Note that NetBIOS is mostly used over IP nowadays, and that those large > networks that use NetBIOS tend to also use WINS, i.e. a centralized name > resolution service for NetBIOS. > > -- Christian Huitema > From owner-zeroconf@merit.edu Fri Jan 24 13:11:19 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27077 for ; Fri, 24 Jan 2003 13:11:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E0AC79144A; Fri, 24 Jan 2003 13:14:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC82C9144C; Fri, 24 Jan 2003 13:14: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 8E0409144A for ; Fri, 24 Jan 2003 13:14:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 69E435E04A; Fri, 24 Jan 2003 13:14:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by segue.merit.edu (Postfix) with ESMTP id 001505E02F for ; Fri, 24 Jan 2003 13:14:33 -0500 (EST) Received: from zektor.gpcc.itd.umich.edu (zektor.gpcc.itd.umich.edu [141.211.2.203]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id NAA17284; Fri, 24 Jan 2003 13:14:32 -0500 (EST) Received: from localhost (sgoswami@localhost) by zektor.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id NAA12033; Fri, 24 Jan 2003 13:14:32 -0500 (EST) Date: Fri, 24 Jan 2003 13:14:32 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@zektor.gpcc.itd.umich.edu To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: <3E317AC0.6060700@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Here is the table again. You are talking about a situation similar to 3 below, as far as the host is concerned DHCP server does not exist when the host does not reply back for its DHCP Request. 1. DHCP Server, DHCP Client Try Manual, if no address Try DHCP, if no address Try LL 2. DHCP Server, No DHCP Client Try Manual Try LL 3. No DHCP Sever Try Manual Try LL On Fri, 24 Jan 2003, Erik Guttman wrote: > Subrata Goswami wrote: > >>Is it acceptable that a host which cannot > >>get an address from DHCP should then give up its IPv4LL > >>configuration and effectively shut down? > > > > Can you please clarify what you mean by this question ? Why are you > > tying IPv4LL with DHCP ? I would think the following is a more > > comprehensive list of scenerios. > > We agree that if the client gets an address somehow (DHCP, manual > configuration, whatever) it will use it. > > What we are not agreement about is the behavior of the host which > cannot get address configuration except through the use of IPv4LL. > > Erik > From owner-zeroconf@merit.edu Fri Jan 24 13:33:01 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27870 for ; Fri, 24 Jan 2003 13:33:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EA1CE9124A; Fri, 24 Jan 2003 13:36:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7BBD9124D; Fri, 24 Jan 2003 13:36: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 852A09124A for ; Fri, 24 Jan 2003 13:36:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5F7AF5DF0D; Fri, 24 Jan 2003 13:36:18 -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 BD1235DDDB for ; Fri, 24 Jan 2003 13:36:17 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0OIVYP19232; Fri, 24 Jan 2003 12:31:34 -0600 (CST) Date: Fri, 24 Jan 2003 10:36:33 -0800 Subject: RFC2563: Threat or Danger? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Ralph Droms , zeroconf@merit.edu, dhcwg@ietf.org To: Robert Elz From: Ted Lemon In-Reply-To: <23248.1043419456@munnari.OZ.AU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I know that if > I was writing a client, and I got an offer which said "no addresses > for you" > and another that said "here's an address you can use" (or even > "configure > yourself a LL address") then I know which offer would be the one I'd be DHCP cant' say "configure yourself an LL address." I've got a couple of problems with what you've said, and agree with other things you've said. The DoS problem is definitely not the only reason to deprecate RFC2563, and I will give some other reasons to deprecate it. I will also point out some reasons why the DoS attack enabled by RFC2563 is easier to do than the a direct IPv4ll DoS attack. Finally, I will point out why the RFC2563 DoS is a more difficult attack from which to recover. 1. Non-DoS reasons to deprecate RFC2563. - It's voluntary, so it doesn't work - if you really want this, RFC2563 isn't the way to get it. - It requires a change to the DHCP protocol state machine - a response is generated by the server according to RFC2563 in a case where no response would be generated according to RFC2131. This requires significant changes to clients and servers, which I think is one reason why nobody has implemented RFC2563 to date. - Customers are not asking for it, and nobody has implemented it, even though the theoretical need for such a mechanism after almost five years of deployment. - RFC2563 demands that the client operate in conflict with the wishes of the owner of the client. So it is difficult for a client vendor (e.g., Microsoft or Apple) to justify implementing RFC2563 - it is likely to cost them business, or generate support calls that will cost them money. I think this is the main reason RFC2563 has not been implemented. 2. RFC2563 enables off-network attacks Having said that, I think you underestimate the value of the DoS attack that RFC2563 enables. RFC2563 enables off-network DoS attacks, whereas without RFC2563 the only possible attacks require that the attacker be attached to the network. There are two kinds of off-network attacks that it enables: - Speculative attacks, where you guess the MAC address and transaction ID of a device and send it DHCP packets in the hopes that it will be in the right state to be disabled by these attacks. - Relay agent-based attacks, where you listen to the relay agent and supply a bogus response that shuts off IPv4ll. This second attack is quite significant, as some folks have mentioned, because we know of ISPs who perform this kind of attack on their customers already. Currently they do it by providing bogus IP addresses rather than by using the RFC2563 mechanism, but if RFC2563 were widely implemented by clients, we have reason to suspect that it would be used to attack and disable legitimate networks. One reason why ISPs may perform this attack is because when you don't respond to a DHCP client, it keeps asking, and never shuts up. If you can send it a "shut up" response, you eliminate all these clients. So if we give ISPs rfc2563, that is, if it becomes widely implemented, it will be used to shut up clients. The effect of this will be to break networks that ought to work. So in fact the DoS argument against RFC2563 3. It is harder to identify and eliminate an RFC2563 attacker Another problem with RFC2563 is that it's easy to use it to deny service. A client pipes up with a DHCPDISCOVER. You tell it to shut up. End of story. With IPv4ll, in order to shut up a client, you have to be constantly listening for ARPs and defending IP addresses. So a DoS attack of this kind would be very easy to track down. By contrast, an RFC2563 attacker can attack at an opportune moment, disable one or more clients, and then go silent for an extended period of time, so there's no easy way to track it down. 4. No automatic recovery from an RFC2563 DoS attack. Once you have identified an attacker that is using the defend-all-addresses attack, you can unplug attacker from the network, and the network immediately starts working again. In comparison, the RFC2563 DoS requires you to physically manipulate every computer on the network - you either have to power cycle them, or if they can detect link state transitions, disconnect and reconnect each device from the network. This is because once the client has been told to shut up, it shuts up, so there's no automatic recovery mechanism. From owner-zeroconf@merit.edu Fri Jan 24 13:34:53 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27939 for ; Fri, 24 Jan 2003 13:34:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E32D99124D; Fri, 24 Jan 2003 13:38:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ACBF19144C; Fri, 24 Jan 2003 13:38: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 782659124D for ; Fri, 24 Jan 2003 13:38:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 56A0A5E049; Fri, 24 Jan 2003 13:38:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 285655E044 for ; Fri, 24 Jan 2003 13:38:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id DC9E314136; Fri, 24 Jan 2003 13:38:09 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 21561-05; Fri, 24 Jan 2003 13:38:04 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 74C921408E; Fri, 24 Jan 2003 13:38:04 -0500 (EST) Date: Fri, 24 Jan 2003 13:38:04 -0500 From: Keith Moore To: Erik Guttman Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: Solving the wrong problems Message-Id: <20030124133804.09f4f40f.moore@cs.utk.edu> In-Reply-To: <3E317C98.2030409@sun.com> References: <23285.1043420443@munnari.OZ.AU> <3E31672C.2010902@sun.com> <20030124113301.74e60736.moore@cs.utk.edu> <3E317C98.2030409@sun.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 02f1f1f64e1f80bede09a02934a289a8b3150637 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > ("refused an address" being different than "DHCP did not answer") > > DHCPNAK is the way that DHCP can respond to refuse a client an > address, right? This could mean the DHCP server has no more addresses > to give out. Or it could mean the administrator doesn't know the > requester's mac address and doesn't want to give out a routable IP > address. Or it could mean something else. Right. And I think this is part of the problem: Sysadmins are currently overloading DHCP to do something it wasn't really designed to do, but it largely works for them. The introduction of LL to IPv4 adds a new state that wasn't anticipated by this use of DHCP. The host's choice is no longer"connect" vs."don't connect"; it's "connect" vs."don't connect" vs."you can't have a routable address but you can use LL". Right now "don't connect" and "you can't have a routable address" essentially mean the same thing (in that they produce the same behavior at the host); what is missing is an indication of whether it's okay for the host to automatically configure LL if it is not given a routable address. (We could argue about the default in the absence of an indication one way of the other. But I think I'm satisfied with either default, as long as such an indication can be made and respecting a definite "don't automatically configure LL" indication is required as part of the LL standard.). Now, I think most network admins would make their lives much easier by giving a routable address to every authorized host and telling the rest to not use LL. But I am not confident enough that this is a good idea for everyone to argue that networks shouldn't be able to allow LL addresses if they want to. Having a definite indication of "LL is okay" vs. "LL is not okay" seems like a good compromise. Keith From owner-zeroconf@merit.edu Fri Jan 24 13:39:21 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28170 for ; Fri, 24 Jan 2003 13:39:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 265519144C; Fri, 24 Jan 2003 13:42:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E64749144D; Fri, 24 Jan 2003 13:42: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 CFEF79144C for ; Fri, 24 Jan 2003 13:42:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id B45F15DF77; Fri, 24 Jan 2003 13:42:37 -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 3450B5DF0D for ; Fri, 24 Jan 2003 13:42:37 -0500 (EST) Received: from nominum.com (dhcp-142.wl.nominum.com [128.177.195.142]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0OIbsP19270; Fri, 24 Jan 2003 12:37:54 -0600 (CST) Date: Fri, 24 Jan 2003 10:42:54 -0800 Subject: Re: Solving the wrong problems Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Erik Guttman From: Ted Lemon In-Reply-To: <3E317C98.2030409@sun.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > DHCPNAK is the way that DHCP can respond to refuse a client an address, > right? This could mean the DHCP server has no more addresses to give > out. Or it could mean the administrator doesn't know the requester's > mac address and doesn't want to give out a routable IP address. Or it > could mean something else. DHCPNAK is only a valid response to DHCPREQUEST, and DHCPREQUEST is only a valid response to DHCPOFFER, which offers an IP address. So no, you can't use DHCPNAK to say "sorry, I'm not giving you an address." From owner-zeroconf@merit.edu Fri Jan 24 13:58:32 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28662 for ; Fri, 24 Jan 2003 13:58:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BDE7F9144D; Fri, 24 Jan 2003 14:01:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8FCD79144E; Fri, 24 Jan 2003 14:01: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 035069144D for ; Fri, 24 Jan 2003 14:01:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 02B7B5E06E; Fri, 24 Jan 2003 14:01:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by segue.merit.edu (Postfix) with ESMTP id 9204A5DF5F for ; Fri, 24 Jan 2003 14:01:08 -0500 (EST) Received: from zektor.gpcc.itd.umich.edu (zektor.gpcc.itd.umich.edu [141.211.2.203]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id OAA04717; Fri, 24 Jan 2003 14:01:08 -0500 (EST) Received: from localhost (sgoswami@localhost) by zektor.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id OAA22191; Fri, 24 Jan 2003 14:01:07 -0500 (EST) Date: Fri, 24 Jan 2003 14:01:07 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@zektor.gpcc.itd.umich.edu To: Ted Lemon Cc: Erik Guttman , Subject: Re: Solving the wrong proble In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk The sequence of messages are as follows. DHCP Client DHCP Server 1. DHCPDISCOVER (broadcast) -> 2. DHCOOFFER (multiple) <- 3. DHCPREQUEST -> 4. DHCPACK/NACK <- What happens if 2 is not received by the client ? How often does the client do DHCPDISCOVER ? When does the client host give up on DHCP ? Does the host do DHCPDISCOVER after it has confiured LL ? What happens when a DHCP server is deployed in an existing LL net? What happens to LL capable host when a DHCP server goes down and comes up? . . Subrata On Fri, 24 Jan 2003, Ted Lemon wrote: > > DHCPNAK is the way that DHCP can respond to refuse a client an address, > > right? This could mean the DHCP server has no more addresses to give > > out. Or it could mean the administrator doesn't know the requester's > > mac address and doesn't want to give out a routable IP address. Or it > > could mean something else. > > DHCPNAK is only a valid response to DHCPREQUEST, and DHCPREQUEST is > only a valid response to DHCPOFFER, which offers an IP address. So > no, you can't use DHCPNAK to say "sorry, I'm not giving you an address." > From owner-zeroconf@merit.edu Fri Jan 24 16:07:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02523 for ; Fri, 24 Jan 2003 16:07:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0282291453; Fri, 24 Jan 2003 16:10:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C07BB91454; Fri, 24 Jan 2003 16:10: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 CAD3891453 for ; Fri, 24 Jan 2003 16:10:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC3C55DFC1; Fri, 24 Jan 2003 16:10:51 -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 6FD6E5DDF9 for ; Fri, 24 Jan 2003 16:10:51 -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 h0OLAoJ06995 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Fri, 24 Jan 2003 16:10:50 -0500 Message-Id: <5.2.0.9.2.20030124155715.032f9788@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 24 Jan 2003 16:00:17 -0500 To: zeroconf@merit.edu From: Daniel Senie Subject: Re: Solving the wrong problems In-Reply-To: <3E317C98.2030409@sun.com> References: <23285.1043420443@munnari.OZ.AU> <3E31672C.2010902@sun.com> <20030124113301.74e60736.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 12:49 PM 1/24/2003, Erik Guttman wrote: >>("refused an address" being different than "DHCP did not answer") > >DHCPNAK is the way that DHCP can respond to refuse a client an address, >right? This could mean the DHCP server has no more addresses to give >out. Or it could mean the administrator doesn't know the requester's >mac address and doesn't want to give out a routable IP address. Or it >could mean something else. It could be you're sitting on a park bench, trying to use LL to sync your laptop with your PDA, and you don't give a damn if there's a public access point present or not, you intend to use 802.11b to talk between your laptop and your PDA. Do you really want the administrator of an ad-hoc public access point, provided out of someone's apartment window, dictating how your laptop and PDA talk to one another? This is, I think, the kind of question to ask when contemplating whether a DHCP server should have ANY standing to tell a client what to do, if that client is not granted an address. From owner-zeroconf@merit.edu Fri Jan 24 16:40:53 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03294 for ; Fri, 24 Jan 2003 16:40:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8339B91454; Fri, 24 Jan 2003 16:44:11 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 570BA91455; Fri, 24 Jan 2003 16:44: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 42D2B91454 for ; Fri, 24 Jan 2003 16:44:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1CDB45DF59; Fri, 24 Jan 2003 16:44:10 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by segue.merit.edu (Postfix) with ESMTP id AC9AE5DE53 for ; Fri, 24 Jan 2003 16:44:09 -0500 (EST) Received: from zektor.gpcc.itd.umich.edu (zektor.gpcc.itd.umich.edu [141.211.2.203]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id QAA24932; Fri, 24 Jan 2003 16:44:08 -0500 (EST) Received: from localhost (sgoswami@localhost) by zektor.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id QAA26822; Fri, 24 Jan 2003 16:44:08 -0500 (EST) Date: Fri, 24 Jan 2003 16:44:08 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@zektor.gpcc.itd.umich.edu To: Daniel Senie Cc: zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: <5.2.0.9.2.20030124155715.032f9788@mail.amaranth.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Great point On Fri, 24 Jan 2003, Daniel Senie wrote: > At 12:49 PM 1/24/2003, Erik Guttman wrote: > > > >>("refused an address" being different than "DHCP did not answer") > > > >DHCPNAK is the way that DHCP can respond to refuse a client an address, > >right? This could mean the DHCP server has no more addresses to give > >out. Or it could mean the administrator doesn't know the requester's > >mac address and doesn't want to give out a routable IP address. Or it > >could mean something else. > > It could be you're sitting on a park bench, trying to use LL to sync your > laptop with your PDA, and you don't give a damn if there's a public access > point present or not, you intend to use 802.11b to talk between your laptop > and your PDA. Do you really want the administrator of an ad-hoc public > access point, provided out of someone's apartment window, dictating how > your laptop and PDA talk to one another? > > This is, I think, the kind of question to ask when contemplating whether a > DHCP server should have ANY standing to tell a client what to do, if that > client is not granted an address. > From owner-zeroconf@merit.edu Fri Jan 24 22:00:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08376 for ; Fri, 24 Jan 2003 22:00:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 205E491255; Fri, 24 Jan 2003 22:04:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E01A091256; Fri, 24 Jan 2003 22:04: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 C3DC791255 for ; Fri, 24 Jan 2003 22:04:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id ADCB65DE33; Fri, 24 Jan 2003 22:04:02 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by segue.merit.edu (Postfix) with ESMTP id 398725DDB0 for ; Fri, 24 Jan 2003 22:04:02 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0P34mYS020038 for ; Fri, 24 Jan 2003 22:04:49 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-39.cisco.com [10.82.224.39]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA22158 for ; Fri, 24 Jan 2003 22:04:00 -0500 (EST) Message-Id: <4.3.2.7.2.20030124215635.03d10df8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Jan 2003 22:03:55 -0500 To: zeroconf@merit.edu From: Ralph Droms Subject: Re: Solving the wrong problems In-Reply-To: <3E317C98.2030409@sun.com> References: <23285.1043420443@munnari.OZ.AU> <3E31672C.2010902@sun.com> <20030124113301.74e60736.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk DHCPNAK generally means that the DHCP server can't fulfill the specific request that the client sent. For example (from RFC2131, section 3.1, Client-server interaction - allocating a network address): If the selected server is unable to satisfy the DHCPREQUEST message (e.g., the requested network address has been allocated), the server SHOULD respond with a DHCPNAK message. The context is that the server has sent an address to the client in a DHCPOFFER, but the server cannot satisfy the request for that address in the subsequent DHCPREQUEST from the client. DHCPNAK can also be sent to indicate to a host that it has moved to a new link and its previously assigned address is no longer valid. DHCPNAK is not used to indicate to the client that the client will not be assigned an address and that the client should not send any more DHCP messages. A server that is unwilling to assign an address simply ignores the messages from the client. DHCPNAK used in the way I described in the first sentence of the previous paragraph could also be used in a DOS attack, I suppose... - Ralph At 06:49 PM 1/24/2003 +0100, Erik Guttman wrote: >>("refused an address" being different than "DHCP did not answer") > >DHCPNAK is the way that DHCP can respond to refuse a client an address, >right? This could mean the DHCP server has no more addresses to give >out. Or it could mean the administrator doesn't know the requester's >mac address and doesn't want to give out a routable IP address. Or it >could mean something else. > >Erik > From owner-zeroconf@merit.edu Fri Jan 24 22:08:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08584 for ; Fri, 24 Jan 2003 22:08:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 548C491256; Fri, 24 Jan 2003 22:12:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2643991456; Fri, 24 Jan 2003 22:12: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 03E8591256 for ; Fri, 24 Jan 2003 22:11:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id D3B7E5DE33; Fri, 24 Jan 2003 22:11:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by segue.merit.edu (Postfix) with ESMTP id 611F15DDB0 for ; Fri, 24 Jan 2003 22:11:59 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0P3CkZC020438 for ; Fri, 24 Jan 2003 22:12:46 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-39.cisco.com [10.82.224.39]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA22412 for ; Fri, 24 Jan 2003 22:11:57 -0500 (EST) Message-Id: <4.3.2.7.2.20030124220554.03cf5258@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Jan 2003 22:11:42 -0500 To: From: Ralph Droms Subject: RE: Solving the wrong problems In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 08:51 AM 1/24/2003 -0800, Christian Huitema wrote: > > > I have yet to hear anyone explain why they would want (as a software > > > author, sending code into environments of which they have no >knowledge > > > at all) to ignore the desires of the local network and simply do >things > > > their own way. > > > > Appletalk and NetBIOS still ship. They work *in every LAN >environment.* > >Kind of. Both require multicast, and multicast is problematic in two >types of LAN environment. It is problematic in large networks, because >typically too chatty. It is also problematic in wireless network, >because of reliability issue; for example, 802.11 includes a low level >packet repetition algorithm, but that algorithm is not used for >multicast packets. > >-- Christian Huitema I know network administrators who would disagree with the statement Appletalk and NetBIOS [...] work *in every LAN environment.* depending on how the words "work" and "LAN environment" are defined. Christian pointed out specific problems with multicast and chattiness. I make this point to illustrate that the statement oversimplifies the situation and can be either true or false, depending on the meaning of "work". Seems to me much of the discussion here has centered around that word "work", because we all have different understandings of what it means to have a network "work". Furthermore, making an observation about AppleTalk and NetBIOS misses a key differentiation - the hard part of making single-link IP work is managing the transition or mixed case where a single-link network becomes a multi-link network or there are some single-link devices interoperating with multi-link devices. - Ralph From owner-zeroconf@merit.edu Sat Jan 25 08:44:19 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24171 for ; Sat, 25 Jan 2003 08:44:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5E624917C4; Sat, 25 Jan 2003 08:36:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0CC9791794; Sat, 25 Jan 2003 06:53: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 105349178B for ; Sat, 25 Jan 2003 06:46:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 113185E06A; Sat, 25 Jan 2003 06:46:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 04FD35E022 for ; Sat, 25 Jan 2003 06:46:22 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0PBjOR09177; Sat, 25 Jan 2003 18:45:24 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0PBjD828922; Sat, 25 Jan 2003 22:45:17 +1100 (EST) From: Robert Elz To: Daniel Senie Cc: zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: <5.2.0.9.2.20030124155715.032f9788@mail.amaranth.net> References: <5.2.0.9.2.20030124155715.032f9788@mail.amaranth.net> <23285.1043420443@munnari.OZ.AU> <3E31672C.2010902@sun.com> <20030124113301.74e60736.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Jan 2003 18:45:13 +0700 Message-ID: <28920.1043495113@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 24 Jan 2003 16:00:17 -0500 From: Daniel Senie Message-ID: <5.2.0.9.2.20030124155715.032f9788@mail.amaranth.net> | Do you really want the administrator of an ad-hoc public | access point, provided out of someone's apartment window, dictating how | your laptop and PDA talk to one another? If I'm going to be using their access point, then yes, of course. If they're also providing a DHCP server, current clients will just use that to configure the addresses they will use, won't they? What's the difference? How can this possibly be stopped? The correct solution, in that situation is not to use the access point. From a private message you sent me, I think that most of your concern is based around the practice of current wireless implementations attempting to be super-automatic, and not tell the user anything about what AP they're actually using, and not allow the user to control that choice. If I'm planning to set up an ad-hoc net on a park bench, then I really want to be in ad-hoc mode, not using anyone else's AP just because it happens to be there, and one of the most minor reasons for this is because they might just happen to tell my node that it isn't allowed a LL address (in fact, if they were to do that, and it stopped my node from functioning, I'd thank them, as they'd be preventing me from sending my packets much further than they would otherwise have gone, or I intended them to travel). kre From owner-zeroconf@merit.edu Sat Jan 25 10:29:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25127 for ; Sat, 25 Jan 2003 10:29:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AF43B91239; Sat, 25 Jan 2003 08:45:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0551991878; Sat, 25 Jan 2003 08:23: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 65F279152E for ; Sat, 25 Jan 2003 06:41:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 55EDC5DDBE; Sat, 25 Jan 2003 06:41:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id CEC625DF49 for ; Sat, 25 Jan 2003 06:41:44 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0PBekR09078; Sat, 25 Jan 2003 18:40:46 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0PBee828911; Sat, 25 Jan 2003 22:40:41 +1100 (EST) From: Robert Elz To: Ted Lemon Cc: Ralph Droms , zeroconf@merit.edu, dhcwg@ietf.org Subject: Re: RFC2563: Threat or Danger? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Jan 2003 18:40:40 +0700 Message-ID: <28909.1043494840@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 24 Jan 2003 10:36:33 -0800 From: Ted Lemon Message-ID: | DHCP cant' say "configure yourself an LL address." That's what 2653 says isn't it - or perhaps more accurately, 2653 assumes that if nothing is said, then not getting an address from DHCP (the DHCP server ignores the DHCPDISCOVER) is implicitly telling the client to go configure a LL address (if it wants to do that of course). | 1. Non-DoS reasons to deprecate RFC2563. | | - It's voluntary, so it doesn't work - if you really want this, RFC2563 | isn't the way to get it. Huh? Everything here is voluntary - I (at the very least) do not mean to imply coercion. It is no different than assuming that clients that are offered an address via DHCP will actually configure the address they're offered, rather that some other address they pick that is on the same network (using the subnet-mask from the DHCPOFFER to work that out). If the client deliberately decides to ignore the advice, that's its choice. If the user has told it to do that, fine. If the vendor has implemented it to always do that, that's their choice, but they wouldn't be able to claim conformance with 2563 obviously, and not with the LL std if that ends up requiring 2563 be implemented (or something like it). | - It requires a change to the DHCP protocol state machine - a response | is generated by the server according to RFC2563 in a case where no | response would be generated according to RFC2131. I am pretty sure that I can make the ISC server generate 2563 responses with no changes at all, but I haven't yet tested it. To work "easily" from the servers point of view, yes, that would require some modifications I suspect. | - RFC2563 demands that the client operate in conflict with the wishes | of the owner of the client. No it doesn't. It can't, nothing the IETF produces can require that. | So it is difficult for a client vendor | (e.g., Microsoft or Apple) to justify implementing RFC2563 - it is | likely to cost them business, or generate support calls that will cost | them money. Only if servers start supplying the option, right? And your thesis above was that none do or ever will. So, how could this possibly cost anything more than the implementation cost (like 50 lines of code, max). On the other hand, if servers do start supplying this option, because their operators want them to, and then the servers are configured to generate the option, and the option says "no LL addresses" when sent, and the clients ignore that, don't you think that would generate support calls ? | 2. RFC2563 enables off-network attacks | | Having said that, I think you underestimate the value of the DoS attack | that RFC2563 enables. RFC2563 enables off-network DoS attacks, | whereas without RFC2563 the only possible attacks require that the | attacker be attached to the network. There are two kinds of | off-network attacks that it enables: | This second attack is quite significant, as some folks have mentioned, | because we know of ISPs who perform this kind of attack on their | customers already. Hmm - this doesn't follow, first you say that 2563 enables these attacks, and then that they're already being carried out, without 2563. | Currently they do it by providing bogus IP | addresses rather than by using the RFC2563 mechanism, but if RFC2563 | were widely implemented by clients, we have reason to suspect that it | would be used to attack and disable legitimate networks. If I were to be subject to such an attack, I'd much rather it was carried out using 2563 than by handing me a bogus IP address. That way at least I could easily see what was happening, my system would tell me (you were refused an IP address), rather than proceeding happily with an IP address that looks to be just fine, but doesn't actually work. So, if this is the threat, then bring on 2563, please! | One reason why ISPs may perform this attack is because when you don't | respond to a DHCP client, it keeps asking, and never shuts up. It doesn't matter why they might choose to do this, if they do it now, and can do it now, and will still be able to do it (in a different way) using 2563 (if clients implemented it) then nothing has really changed, except 2563 makes things more obvious (so if the "attacker"/ISP is trying to be as nice as they can, while keeping down the load on their server, they'd use 2653, if they're really trying to hide what they're doing, they'll keep doing it the way they are now). This is just another aspect of Keith's reply to Ralph's first message on this general thread - the DoS potential of 2563 is really identical to the DoS potential of DHCP without 2563. | 3. It is harder to identify and eliminate an RFC2563 attacker | | Another problem with RFC2563 is that it's easy to use it to deny | service. A client pipes up with a DHCPDISCOVER. You tell it to shut | up. End of story. Until it decides to try again, and assuming there is no other DHCP server that actually offers an address. The story continues... | With IPv4ll, in order to shut up a client, you | have to be constantly listening for ARPs and defending IP addresses. So? You have to keep watching for DHCPDISCOVERS anyway, watching for ARP is not really all that hard to do. | So a DoS attack of this kind would be very easy to track down. By | contrast, an RFC2563 attacker can attack at an opportune moment, | disable one or more clients, and then go silent for an extended period | of time, so there's no easy way to track it down. Huh? You just have the client do a DHCPDISCOVER and watch what happens next time. If the attacker is being silent, then the client goes ahead and gets its LL address after all this time - that's no different from an ARP attack running for a short while, then going silent for a while in the hopes of avoiding detection. You're also assuming that the client is not recording the information about who (mac & IP addr) of the node that sent the "shut down" DHCP message. Why would you assume that? It seems like that would be the obvious thing for a node to record for later analysis. On the other hand, getting a reply to an ARP probe for an address is "normal" - that's what is supposed to happen if you happen to pick an address that is in use already. There's no particular reason for a client to believe it needs to remember anything about where that came from, and without that, it can't tell that all the ARP responses seem to be coming from the same place (even assuming that the ARP attacker isn't just randomising its MAC source address). Once again, the 2563 DoS attack is the one I'd much rather carried out against me, it is the one that is much easier to detect and analyse. | 4. No automatic recovery from an RFC2563 DoS attack. | | Once you have identified an attacker that is using the | defend-all-addresses attack, you can unplug attacker from the network, | and the network immediately starts working again. That's true for any attacker. You have a hidden assumption here that a node wanting a LL address is going to continue ARP'ing (probing) for one, forever, until it eventually is received. I kind of doubt that (and would like the implementors of the current implementations, or those who know about them, to tell us if they just continue forever, or if they give up after a while). | In comparison, the | RFC2563 DoS requires you to physically manipulate every computer on the | network - you either have to power cycle them, or if they can detect | link state transitions, disconnect and reconnect each device from the | network. This is because once the client has been told to shut up, it | shuts up, so there's no automatic recovery mechanism. There's no reason that a client can't try again from time to time, after either of these failures. Explicit try again commands (from some user, perhaps using one of the methods you mention, or something else) might, be required for either of those methods. I see nothing in 2563 that says "never try again without detecting link state changes" or anything like that. In fact, anything of that nature would be very un-DHCP like - it is normal for a DHCP client to re-validate (extend) its lease from time to time, the only control DHCP has over this really is to send back timers that control the max time the address is valid (and the suggested rebind time). There's nothing in 2563 that mentions timers at all, there probably should be. One might assume that the lease validity timer of the yiaddr=0 is intended to be the validity period of the "no autoconfigure", but there's nothing in the doc that says that, nor is there anything anywhere that prevents the client validating its address sooner (as soon as it likes). I use your client Ted (the ISC client that is), and I quite often renew leases very much sooner than the reply from the server would lead me to otherwise do (for all kinds of reasons). Nothing in your message suggests to me that 2563 should be deprecated, nor that the LL doc shouldn't mandate its use in LL clients. kre From owner-zeroconf@merit.edu Sat Jan 25 10:43:46 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25331 for ; Sat, 25 Jan 2003 10:43:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CFE049182D; Sat, 25 Jan 2003 09:07:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9A7291876; Sat, 25 Jan 2003 08:23: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 654E1915A6 for ; Sat, 25 Jan 2003 06:05:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F42B5E057; Sat, 25 Jan 2003 06:05:13 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 9B8C65DDBE for ; Sat, 25 Jan 2003 06:05:11 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0PB4xR07907; Sat, 25 Jan 2003 18:04:59 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0PB4l828849; Sat, 25 Jan 2003 22:04:48 +1100 (EST) From: Robert Elz To: Erik Guttman Cc: zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: <3E31672C.2010902@sun.com> References: <3E31672C.2010902@sun.com> <23285.1043420443@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Jan 2003 18:04:47 +0700 Message-ID: <28847.1043492687@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 24 Jan 2003 17:17:48 +0100 From: Erik Guttman Message-ID: <3E31672C.2010902@sun.com> | Local networking with IP has not worked for consumers. (By the way, | those are people who *cannot* set their IP address manually). Yes, I know, and I fully agree with providing a solution to that. | This is because there are environments where | | - there is no DHCP, and no configured address | (There is no disagreement here about how things should work.) agreed. | - there is DHCP | (There is some disagreement, but it looks like a rough WG consensus | is emerging that when a host gets configuration with DHCP it will | no longer use its own v4LL address.) agreed. | - there is a DHCP server but it will not give the host an address | (Here there is more disagreement.) Yes. | The question is: Is it acceptable that a host which cannot get | an address from DHCP should then give up its IPv4LL configuration | and effectively shut down? Yes, in the case that you can distinguish this from the first case above. Take one possible example. You have a device whose (non-network) interface to the world is a power cord, that can be plugged and unplugged, and a LED (imagine what states you can for how it can use this to indicate "all OK" "no network connected" "no power" ...) Now let that device be connected to a link which has a DHCP server (so we're not in case 1 above) but no address is assigned (which I believe means that 2563 or perhaps a replacement of that, or similar, is in use, otherwise it is indistinguishable from case 1). The DHCP server says "no LL address" because it knows the device has been plugged into a LAN where there are no other devices at all (perhaps this is one of those "unregistered MAC address -> purgatory VLAN type switches configured to put unknown devices on a VLAN that nothing else will be automatically connected to - but to which there is a router, with its dhcp relay etc). Now, if the device just goes and configures itself a LL address, and starts flashing its LED in the "all is functioning" state (just the same as it would if it connected to a net with no DHCP server at all) then how is the user, who is now attempting to contact the device (using mDNS or SLP or something, doesn't matter what here, to find it) to know that they're wasting their time? Isn't it much better for the device to simply disable itself, and flash its "no network" LED pattern, and by doing so, inform the user that there's something wrong with the network connection, so the user can start looking for the correct problem source (pretty much the same way it would do if LL addresses had never been invented, and it was unable to get an address using DHCP) ? What seems to be the problem is that people are imagining that the people who configure DHCP servers are evil bastards, deliverately setting out to do everything in their power to prevent the network from being used. While there may be a few like that around (and remember that they same people usually also get to configure the switches, etc, so have other ways of denying you access if they want), most DHCP people are trying to make the network function, not misfunction. If they are going to deny you what Keith calls a "routable" address, and tell you not to use a LL address either, there's almost certainly a very good reason for that. | Is this a rare enough event that | consumer networking vendors will be satisfied that IP isn't | totally unreliable compared to Appletalk, etc? I agree that it is going to be very rare. But I think it will provide the (truly dumb) devices functionality that appletalk (etc) cannot - an appletalk device in the situation above would simply configure itself an appletalk address and sit waiting for someone to talk to it, believing that the other device(s) are just being slow to be connected. Of course, in all of this, for devices that aren't quite so dumb, there's always the option for a user to explicitly tell the device to override the DHCP option, and go ahead and make a LL address anyway. But this should only happen via explicit user action (perhaps pressing an unbent paper clip into a little hole to depress a switch, or something, for devices with truly primitive user interfaces. kre From owner-zeroconf@merit.edu Sat Jan 25 10:55:14 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25403 for ; Sat, 25 Jan 2003 10:55:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D15FF91948; Sat, 25 Jan 2003 10:18:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E0D7918A5; Sat, 25 Jan 2003 09:34: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 14B51916B6 for ; Sat, 25 Jan 2003 08:39:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE78B5E05D; Sat, 25 Jan 2003 08:39:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id CBA3F5E053 for ; Sat, 25 Jan 2003 08:39:04 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0PDceR12776; Sat, 25 Jan 2003 20:38:41 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0PDSF829713; Sun, 26 Jan 2003 00:29:36 +1100 (EST) From: Robert Elz To: Ted Lemon , Ralph Droms , zeroconf@merit.edu, dhcwg@ietf.org Subject: Re: [dhcwg] Re: RFC2563: Threat or Danger? In-Reply-To: <28909.1043494840@munnari.OZ.AU> References: <28909.1043494840@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Jan 2003 20:28:15 +0700 Message-ID: <29711.1043501295@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sat, 25 Jan 2003 18:40:40 +0700 From: Robert Elz Message-ID: <28909.1043494840@munnari.OZ.AU> | | DHCP cant' say "configure yourself an LL address." | | That's what 2653 says isn't it I meant 2563 (of course). | | - It's voluntary, so it doesn't work - if you really want this, RFC2563 | | isn't the way to get it. And I missed your meaning there at first reading - you mean that clients don't need to include the option, in which case the server won't include it in its reply (it being one of the few "only supply when asked" options). First, that's one thing I would change in the 2563 - there's no reason I see for the server not to send the option any time it feels inclined. There's no more reason this would cause a problem to a random client than if the server should decide to supply the well known impress printer option. Ignoring unknown/unwanted options is easy. Second, even ignoring that, a client that intends to "play by the rules" (assuming the rules and up as "don't configure yourself a LL address if the DHCP server says not to, even if it hasn't given you an address" will include the option in its DISCOVER (and REQUEST) packets, and so get the response (assuming the server wants to send it). Clients that have decided to take no notice, including clients implemented before the LL staandard (or I-D of what it might be eventually) suggest doing this will obviously not send the option, and if the server obeys 2563 as written now, won't get the "no LL option", and so will go ahead and configure a LL address anyway. Once again, I am not wanting to prohibit LL addresses because I think that LL addresses will magically destroy my network. I want the client to not use one (in some cases where I decide) because I know that the client will be better off with no address, than believing it has an address, which will not then work (at all). I want a way to tell the client that. If the client believes it knows better than I do (or is simply too old to know anything at all) then so be it, it won't get the information that I am trying to convey to it. kre From owner-zeroconf@merit.edu Sat Jan 25 12:26:07 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26130 for ; Sat, 25 Jan 2003 12:26:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2EF6891AD9; Sat, 25 Jan 2003 11:54:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4190A91283; Sat, 25 Jan 2003 11:46: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 56BA1917F9 for ; Sat, 25 Jan 2003 11:07:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3D3805E057; Sat, 25 Jan 2003 11:07:17 -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 8C04B5E043 for ; Sat, 25 Jan 2003 11:07:16 -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 h0PG55J04949 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Sat, 25 Jan 2003 11:05:09 -0500 Message-Id: <5.2.0.9.2.20030125104141.02f59db8@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sat, 25 Jan 2003 10:50:33 -0500 To: Robert Elz From: Daniel Senie Subject: Re: Solving the wrong problems Cc: zeroconf@merit.edu In-Reply-To: <28920.1043495113@munnari.OZ.AU> References: <5.2.0.9.2.20030124155715.032f9788@mail.amaranth.net> <5.2.0.9.2.20030124155715.032f9788@mail.amaranth.net> <23285.1043420443@munnari.OZ.AU> <3E31672C.2010902@sun.com> <20030124113301.74e60736.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 06:45 AM 1/25/2003, you wrote: > Date: Fri, 24 Jan 2003 16:00:17 -0500 > From: Daniel Senie > Message-ID: <5.2.0.9.2.20030124155715.032f9788@mail.amaranth.net> > > | Do you really want the administrator of an ad-hoc public > | access point, provided out of someone's apartment window, dictating how > | your laptop and PDA talk to one another? > >If I'm going to be using their access point, then yes, of course. > >If they're also providing a DHCP server, current clients will just use >that to configure the addresses they will use, won't they? What's the >difference? How can this possibly be stopped? > >The correct solution, in that situation is not to use the access point. > > >From a private message you sent me, I think that most of your concern is >based around the practice of current wireless implementations attempting to >be super-automatic, and not tell the user anything about what AP they're >actually using, and not allow the user to control that choice. > >If I'm planning to set up an ad-hoc net on a park bench, then I really >want to be in ad-hoc mode, not using anyone else's AP just because it >happens to be there, and one of the most minor reasons for this is >because they might just happen to tell my node that it isn't allowed >a LL address (in fact, if they were to do that, and it stopped my node >from functioning, I'd thank them, as they'd be preventing me from >sending my packets much further than they would otherwise have gone, >or I intended them to travel). While this is indeed obvious, my hope in sending the note to the list was NOT to focus on the particular weaknesses of 802.11b and many implementations, or the cluelessness of some of its users, but rather to point out the real possibility that someone could cause users harm. Regardless, there's another case with 802.11b in public hot spots that's arguably worse in terms of having a DHCP command to "get the hell off the network": You go to a Starbucks and plan to use the T-Mobile hotspot. In my backpack, I place an AP of my own, using the same SSID, and a laptop acting as DHCP server, sending out a "get off the network" DHCP response to anyone trying to get on the 'net. My AP can match the SSID and Mac address of the hot spot AP, and the DHCP server can spoof its identity to match the router connecting the hotspot to the outside world. The point is the ability to send a message to someone's station to NOT do something can and is nasty. It was also a bad idea in 802.5 token ring. It was entirely possible to set up a station that'd listen for others to come on a token ring, and send them a "get off the ring" message. Stations were required to comply with such messages. Of course there was no authentication. In the name of giving administrators control, bad and dangerous mechanisms can be created. From owner-zeroconf@merit.edu Sat Jan 25 12:41:21 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26254 for ; Sat, 25 Jan 2003 12:41:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C5A5F915F3; Sat, 25 Jan 2003 12:22:23 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7461191A78; Sat, 25 Jan 2003 11:47: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 B815391A94 for ; Sat, 25 Jan 2003 11:47:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9CB1D5DE5D; Sat, 25 Jan 2003 11:47:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id 1A58B5DE2B for ; Sat, 25 Jan 2003 11:47:26 -0500 (EST) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id LAA03733; Sat, 25 Jan 2003 11:47:23 -0500 (EST) From: "Subrata Goswami" To: "'Erik Guttman'" Cc: Subject: RE: Solving the wrong problems Date: Sat, 25 Jan 2003 08:41:42 -0800 Message-ID: <000301c2c490$a47d1230$c900a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <28847.1043492687@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The way Erik is wording the 3 cases implicitly requires that every LL device MUST have a DHCP client. The onus of deciding whether to use LL or DHCP is placed mostly on the device, which in most cases would be very resource limited (not exactly a big bulky server with 4 processor and 2 giga byte of RAM). This I think would makes sure that LL would not be applicable in many situations where it could have played a big part. I my view, DHCP should have NO SAY on where and how a device should use LL. It is better to decouple the two protocols. Subrata From owner-zeroconf@merit.edu Sat Jan 25 13:41:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26867 for ; Sat, 25 Jan 2003 13:41:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CEB6B91AD8; Sat, 25 Jan 2003 12:44:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0376F91874; Sat, 25 Jan 2003 12:22: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 B035F91AB9 for ; Sat, 25 Jan 2003 11:54:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E89B5DEF3; Sat, 25 Jan 2003 11:54:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id 3C64C5DEA0 for ; Sat, 25 Jan 2003 11:54:22 -0500 (EST) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id LAA03738; Sat, 25 Jan 2003 11:47:24 -0500 (EST) From: "Subrata Goswami" To: "'Robert Elz'" , "'Erik Guttman'" Cc: Subject: RE: Solving the wrong problems Date: Sat, 25 Jan 2003 08:41:42 -0800 Message-ID: <000401c2c490$a50220b0$c900a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <28847.1043492687@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit See inline > -----Original Message----- > From: owner-zeroconf@merit.edu > [mailto:owner-zeroconf@merit.edu] On Behalf Of Robert Elz > Sent: Saturday, January 25, 2003 3:05 AM > To: Erik Guttman > Cc: zeroconf@merit.edu > Subject: Re: Solving the wrong problems > > > Date: Fri, 24 Jan 2003 17:17:48 +0100 > From: Erik Guttman > Message-ID: <3E31672C.2010902@sun.com> > > | Local networking with IP has not worked for consumers. > (By the way, > | those are people who *cannot* set their IP address manually). > > Yes, I know, and I fully agree with providing a solution to that. > > | This is because there are environments where > | > | - there is no DHCP, and no configured address > | (There is no disagreement here about how things should work.) > > agreed. > > | - there is DHCP > | (There is some disagreement, but it looks like a > rough WG consensus > | is emerging that when a host gets configuration with > DHCP it will > | no longer use its own v4LL address.) > > agreed. > > | - there is a DHCP server but it will not give the host > an address > | (Here there is more disagreement.) > > Yes. > Actually, it has to be specified how the device figures out that there is a DHCP server. > | The question is: Is it acceptable that a host which cannot get > | an address from DHCP should then give up its IPv4LL configuration > | and effectively shut down? > > Yes, in the case that you can distinguish this from the first > case above. > Not really, if the DHCP server does not send out any DHCPOFFER then the device would not know if there is a DHCP server or not. > Take one possible example. You have a device whose (non-network) > interface to the world is a power cord, that can be plugged > and unplugged, and a LED (imagine what states you can for how > it can use this to indicate "all OK" "no network connected" > "no power" ...) > what happens if the device does not even have an LED, or the LED malfucntions ? > Now let that device be connected to a link which has a DHCP > server (so we're not in case 1 above) but no address is > assigned (which I believe means that 2563 or perhaps a > replacement of that, or similar, is in use, otherwise it is > indistinguishable from case 1). > again, how does the device distinguish if there is no DHCPOFFER ? > The DHCP server says "no LL address" because it knows the > device has been plugged into a LAN where there are no other > devices at all (perhaps this is one of those "unregistered > MAC address -> purgatory VLAN type switches configured to put > unknown devices on a VLAN that nothing else will be > automatically connected to - but to which there is a router, > with its dhcp relay etc). > what happnes if the device received two DHCPOFFERS from two different DHCP servers, one saying can use LL and the other saying do not use LL. > Now, if the device just goes and configures itself a LL > address, and starts flashing its LED in the "all is > functioning" state (just the same as it would if it connected > to a net with no DHCP server at all) then how is the user, > who is now attempting to contact the device (using mDNS or > SLP or something, doesn't matter what here, to find it) to > know that they're wasting their time? > I do not see any problem here. The device would not have a corresponding entry in SLP or mDNS, and the user can easily figure that out from the absence of the entry. > Isn't it much better for the device to simply disable itself, > and flash its "no network" LED pattern, and by doing so, > inform the user that there's something wrong with the network > connection, so the user can start looking for the correct > problem source (pretty much the same way it would do if LL > addresses had never been invented, and it was unable to get > an address using DHCP) ? > No, not all devices that would use LL would have blinking LED's. > What seems to be the problem is that people are imagining > that the people who configure DHCP servers are evil bastards, > deliverately setting out to > do everything in their power to prevent the network from > being used. While > there may be a few like that around (and remember that they > same people usually also get to configure the switches, etc, > so have other ways of denying you access if they want), most > DHCP people are trying to make the > network function, not misfunction. If they are going to > deny you what > Keith calls a "routable" address, and tell you not to use a > LL address either, there's almost certainly a very good > reason for that. > DHCP has its limitations. > | Is this a rare enough event that > | consumer networking vendors will be satisfied that IP isn't > | totally unreliable compared to Appletalk, etc? > > I agree that it is going to be very rare. But I think it > will provide > the (truly dumb) devices functionality that appletalk (etc) > cannot - an appletalk device in the situation above would > simply configure itself an appletalk address and sit waiting > for someone to talk to it, believing that the other device(s) > are just being slow to be connected. > > Of course, in all of this, for devices that aren't quite so > dumb, there's always the option for a user to explicitly tell > the device to override the DHCP option, and go ahead and make > a LL address anyway. But this should only happen via > explicit user action (perhaps pressing an unbent paper clip > into a little hole to depress a switch, or something, for > devices with truly primitive user interfaces. > what happens if you paper clip is confiscated at the airport ? > kre > The way you are wording the 3 cases above implicity requires that every LL device MUST have a DHCP client. The onus of deciding whether to use LL or DHCP is placed mostly on the device, which in most cases would be very resource limited (not exactly a big bulky server with 4 processor and 2 giga byte of RAM). This I think would makes sure that LL would not be applicable in many situations where it could have played a big part. I my view, DHCP should have NO SAY on where and how a device should use LL. It is better to decouple the two prorocols. From owner-zeroconf@merit.edu Sat Jan 25 14:19:17 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27252 for ; Sat, 25 Jan 2003 14:19:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A109391B9D; Sat, 25 Jan 2003 14:07:19 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D59491BA1; Sat, 25 Jan 2003 13:50: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 722F491B28 for ; Sat, 25 Jan 2003 13:03:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 608CB5DEA7; Sat, 25 Jan 2003 13:03:48 -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 0EC5D5DE5D for ; Sat, 25 Jan 2003 13:03:47 -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 h0OI38617262; Fri, 24 Jan 2003 11:03:08 -0700 Date: Sat, 25 Jan 2003 11:03:41 -0700 Subject: Re: Solving the wrong problems Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: , "'Erik Guttman'" To: "Subrata Goswami" From: Alex Karahalios In-Reply-To: <000301c2c490$a47d1230$c900a8c0@SGOSWAMIPCL> Message-Id: <56418C28-308F-11D7-8973-00039377AD70@Outersoft.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Subrata, I agree that DHCP and LL should be orthogonal. Given that, a device could poses both DHCP and LL addresses at a given time. As far as RFC2563 pertains to this, I suppose that a device could have a configuration option which would tell if it were to honor the DHCP auto-config option. This in my view is no different then a device deciding if it should use a manual IP address rather than one assigned by a DHCP server - which is the way most computer OSes currently behave. Alex Karahalios On Saturday, January 25, 2003, at 09:41 AM, Subrata Goswami wrote: > I my view, DHCP should have NO SAY on where and how a device should > use LL. It is better to decouple the two protocols. > From owner-zeroconf@merit.edu Sat Jan 25 14:42:03 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27553 for ; Sat, 25 Jan 2003 14:42:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6038891B65; Sat, 25 Jan 2003 13:45:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0591191A8F; Sat, 25 Jan 2003 13:19: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 86D8D91B08 for ; Sat, 25 Jan 2003 13:10:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6BB815DE02; Sat, 25 Jan 2003 13:10:08 -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 8E9DB5DDC5 for ; Sat, 25 Jan 2003 13:10:07 -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 F032B598ED; Sat, 25 Jan 2003 18:10:08 +0000 (GMT) Message-ID: <028401c2c49c$fde2b2b0$131010ac@aldebaran> From: "Philip Nye" To: "Erik Guttman" , "Ted Lemon" Cc: References: Subject: Re: Solving the wrong problems Date: Sat, 25 Jan 2003 18:10:06 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Ted Lemon" > > > DHCPNAK is the way that DHCP can respond to refuse a client an address, > > right? This could mean the DHCP server has no more addresses to give > > out. Or it could mean the administrator doesn't know the requester's > > mac address and doesn't want to give out a routable IP address. Or it > > could mean something else. > > DHCPNAK is only a valid response to DHCPREQUEST, and DHCPREQUEST is > only a valid response to DHCPOFFER, which offers an IP address. So > no, you can't use DHCPNAK to say "sorry, I'm not giving you an address." RFC2563 effectively does three things: 1. It says that the DHCP server can offer Address=0.0.0.0 as a way of saying "you can't have an address" 2. It defines a boolean option which says "OK to autoconfigure a LL address" or "Don't autoconfigure" 3. It defines some rules about which combinations of the above two must be supported in which circumstances and by which devices. We could probably change/supercede these rules if it suited us. It is therefore clear that using this RFC the DHCP server _could_ dictate ANY of the four possible combinations of DHCP-assigned and v4LL addresses: DHCP v4LL No No No Yes Yes No yes yes So rather than arguing about what DHCP can or can't do we should consider the much harder question of what we think it is appropriate for it to do in the LL context. Most of this hinges on whether it is legitimate for the DHCP server to say "No, No": A. Is the DHCP server the all powerful dictator? or B. Does the individual have complete autonomy? or C. Is there some in between state - and if so how is it defined? RFC2563 is clearly aimed at A. If we want B then there seems little point in supporting a RFC2563 style option at all since getting anything except a valid address from the server is equivalent to getting no answer. The only possibility for C that I have seen is a manual override. Are there any other suggestions? Philip From owner-zeroconf@merit.edu Sat Jan 25 15:48:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28196 for ; Sat, 25 Jan 2003 15:48:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6917191501; Sat, 25 Jan 2003 14:55:15 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D91891612; Sat, 25 Jan 2003 13:51: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 D901691B9E for ; Sat, 25 Jan 2003 13:11:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id C4E035DE5D; Sat, 25 Jan 2003 13:11:45 -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 AAF515DE02 for ; Sat, 25 Jan 2003 13:11:31 -0500 (EST) Received: from nominum.com (dsl081-073-044.sfo1.dsl.speakeasy.net [64.81.73.44]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0PI6ZP28712; Sat, 25 Jan 2003 12:06:35 -0600 (CST) Date: Sat, 25 Jan 2003 10:11:45 -0800 Subject: Re: [dhcwg] Re: RFC2563: Threat or Danger? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: dhcwg@ietf.org, zeroconf@merit.edu, Ralph Droms To: Robert Elz From: Ted Lemon In-Reply-To: <29711.1043501295@munnari.OZ.AU> Message-Id: <7668BE02-3090-11D7-B694-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > First, that's one thing I would change in the 2563 - there's no reason > I > see for the server not to send the option any time it feels inclined. > There's no more reason this would cause a problem to a random client > than > if the server should decide to supply the well known impress printer > option. > Ignoring unknown/unwanted options is easy. The server is generating a bogus DHCPOFFER. Sending this to a non-rfc2563-compliant client would have unpredictable results. q From owner-zeroconf@merit.edu Sat Jan 25 15:55:35 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28220 for ; Sat, 25 Jan 2003 15:55:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7A1D3915A5; Sat, 25 Jan 2003 15:39:49 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BDCA91755; Sat, 25 Jan 2003 15:18: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 29A5D917CD for ; Sat, 25 Jan 2003 14:21:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 06EB95DDE2; Sat, 25 Jan 2003 14:21: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 91B795DDB4 for ; Sat, 25 Jan 2003 14:21:16 -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 OAA01262 for ; Sat, 25 Jan 2003 14:21: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 OAA06948 for ; Sat, 25 Jan 2003 14:17:13 -0500 (EST) Received: from [192.168.1.100] (cpe-66-189-9-93.ma.charter.com [66.189.9.93]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA04079 for ; Sat, 25 Jan 2003 14:06:36 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Sat, 25 Jan 2003 14:06:36 -0500 Subject: Re: Solving the wrong problems From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <000401c2c490$a50220b0$c900a8c0@SGOSWAMIPCL> 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 01/25/2003 11:41, "Subrata Goswami" wrote: >> Take one possible example. You have a device whose (non-network) >> interface to the world is a power cord, that can be plugged >> and unplugged, and a LED (imagine what states you can for how >> it can use this to indicate "all OK" "no network connected" >> "no power" ...) >> > > what happens if the device does not even have an LED, or the LED > malfucntions ? Even if it has one, it does you no good if it's in a different room. For devices like that, you'd only use the LED as a backup in case the network connection was malfunctioning. For example, I just usually chuck base stations in a suspended ceiling. They work just fine, but are out of the way. The LED's of course, are useless. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Sat Jan 25 16:44:30 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28801 for ; Sat, 25 Jan 2003 16:44:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 661A991632; Sat, 25 Jan 2003 16:26:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E01D91B2F; Sat, 25 Jan 2003 16:14: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 960CB918A7 for ; Sat, 25 Jan 2003 15:24:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 87CEC5DE07; Sat, 25 Jan 2003 15:24:05 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id 062DB5DE11 for ; Sat, 25 Jan 2003 15:24:05 -0500 (EST) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id PAA21032; Sat, 25 Jan 2003 15:17:12 -0500 (EST) From: "Subrata Goswami" To: "'Robert Elz'" , "'Daniel Senie'" Cc: Subject: RE: Solving the wrong problems Date: Sat, 25 Jan 2003 12:11:30 -0800 Message-ID: <001901c2c4ad$f394d980$c900a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <28920.1043495113@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit see inline > -----Original Message----- > From: owner-zeroconf@merit.edu > [mailto:owner-zeroconf@merit.edu] On Behalf Of Robert Elz > Sent: Saturday, January 25, 2003 3:45 AM > To: Daniel Senie > Cc: zeroconf@merit.edu > Subject: Re: Solving the wrong problems > > > Date: Fri, 24 Jan 2003 16:00:17 -0500 > From: Daniel Senie > Message-ID: <5.2.0.9.2.20030124155715.032f9788@mail.amaranth.net> > > | Do you really want the administrator of an ad-hoc public > | access point, provided out of someone's apartment window, > dictating how > | your laptop and PDA talk to one another? > > If I'm going to be using their access point, then yes, of course. > > If they're also providing a DHCP server, current clients will just use > that to configure the addresses they will use, won't they? > What's the > difference? How can this possibly be stopped? > > The correct solution, in that situation is not to use the > access point. > > >From a private message you sent me, I think that most of > your concern > >is > based around the practice of current wireless implementations > attempting to be super-automatic, and not tell the user > anything about what AP they're actually using, and not allow > the user to control that choice. > > If I'm planning to set up an ad-hoc net on a park bench, then > I really want to be in ad-hoc mode, not using anyone else's > AP just because it happens to be there, and one of the most > minor reasons for this is because they might just happen to > tell my node that it isn't allowed a LL address (in fact, if > they were to do that, and it stopped my node from > functioning, I'd thank them, as they'd be preventing me from > sending my packets much further than they would otherwise > have gone, or I intended them to travel). > I think I would prefer a working service, rather than being told that I can not use my device because someone nearby is encroaching into the park's property. > kre > From owner-zeroconf@merit.edu Sun Jan 26 03:02:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14922 for ; Sun, 26 Jan 2003 03:02:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5A2F891212; Sun, 26 Jan 2003 03:04:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1FECB9125C; Sun, 26 Jan 2003 03:04: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 11A3E91212 for ; Sun, 26 Jan 2003 03:03:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id E1CCA5DF71; Sun, 26 Jan 2003 03:03:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 783D85DDD5 for ; Sun, 26 Jan 2003 03:03:53 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0Q82sR15151; Sun, 26 Jan 2003 15:02:56 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0Q82i805867; Sun, 26 Jan 2003 19:02:44 +1100 (EST) From: Robert Elz To: Daniel Senie Cc: zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: <5.2.0.9.2.20030125104141.02f59db8@mail.amaranth.net> References: <5.2.0.9.2.20030125104141.02f59db8@mail.amaranth.net> <5.2.0.9.2.20030124155715.032f9788@mail.amaranth.net> <5.2.0.9.2.20030124155715.032f9788@mail.amaranth.net> <23285.1043420443@munnari.OZ.AU> <3E31672C.2010902@sun.com> <20030124113301.74e60736.moore@cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Jan 2003 15:02:44 +0700 Message-ID: <5865.1043568164@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sat, 25 Jan 2003 10:50:33 -0500 From: Daniel Senie Message-ID: <5.2.0.9.2.20030125104141.02f59db8@mail.amaranth.net> | The point is the ability to send a message to someone's station to NOT do | something can and is nasty. My point was that the ability to do that exists already. Nothing is being added that cannot already be done. The sole difference is that a defined (easy to detect) way to achieve results that can already be achieved is being offered. | In the name of giving administrators control, bad and dangerous mechanisms | can be created. Of course. But they're going to take control one way or another anyway. You can't prevent that (other than by not using their network). Isn't it better to have an obvious "the admin says you can't (or shouldn't) do that" technique, than just "it failed" ? kre From owner-zeroconf@merit.edu Sun Jan 26 03:12:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14999 for ; Sun, 26 Jan 2003 03:12:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C64319125F; Sun, 26 Jan 2003 03:15:18 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B11A091262; Sun, 26 Jan 2003 03:15: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 177119125F for ; Sun, 26 Jan 2003 03:15:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id D24F55DF71; Sun, 26 Jan 2003 03:15:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id EC5D15DDD5 for ; Sun, 26 Jan 2003 03:15:03 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0Q8ERR15659; Sun, 26 Jan 2003 15:14:27 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0Q8E3805886; Sun, 26 Jan 2003 19:14:04 +1100 (EST) From: Robert Elz To: "Subrata Goswami" Cc: "'Erik Guttman'" , zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: <000401c2c490$a50220b0$c900a8c0@SGOSWAMIPCL> References: <000401c2c490$a50220b0$c900a8c0@SGOSWAMIPCL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Jan 2003 15:14:03 +0700 Message-ID: <5884.1043568843@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sat, 25 Jan 2003 08:41:42 -0800 From: "Subrata Goswami" Message-ID: <000401c2c490$a50220b0$c900a8c0@SGOSWAMIPCL> | Actually, it has to be specified how the device figures out that | there is a DHCP server. It gets a DHCP reply. That is obvious. The only DHCP reply it can get is a DHCPOFFER. So, it gets one of those. If it doesn't, it can assume there's no DHCP server. | Not really, if the DHCP server does not send out any DHCPOFFER then the | device would not know if there is a DHCP server or not. Exactly, so we are assuming that it does get a DHCPOFFER. | what happens if the device does not even have an LED, or the LED | malfucntions ? What happens if the power supply malfunctions? Let's be reasonable please, if manufacturers want to make devices where it is impossible to work out what kind of problem might exist whenever they don't work perfectly, then it is going to be impossible for anyone to ever work out what is wrong (whether it is a "no address for you" or a broken wire in the drop cable, or too far from base station, or not plugged in properly, or ...) | what happnes if the device received two DHCPOFFERS from two | different DHCP servers, one saying can use LL and the other saying | do not use LL. DHCP says that if you get 2 offers, you can pick whichever you like. I see no reason at all to change that, so the client picks whichever of those 2 it likes. If one of them offers an address, most likely it would pick that one (or one of them if both do). If neither offers an address, and one says "use LL" and the other says "no LL", then I think if I was the client, I'd pick the "use LL" offer, and do it. | I do not see any problem here. The device would not have a corresponding | entry in SLP or mDNS, and the user can easily figure that out from | the absence of the entry. But why does it appear to be missing? Is it the server or the client that isn't working properly? Or the switch/hub/router that is between them? You have to start somewhere when debugging these problems, and starting with "it doesn't work" and nothing more, rarely helps. | No, not all devices that would use LL would have blinking LED's. No, of course not, but any device rational to use (from toasters to air-conditioners, to washing machines, to car alarms, to ...) has some means of "I am working" user feedback. | DHCP has its limitations. of course. And no-one is pretending that a network has to use it, if it is inappropriate. | The way you are wording the 3 cases above implicity requires that | every LL device MUST have a DHCP client. Yes, that's something I would support - either a DHCP client or expect to be manually configured. Nothing else can possibly allow the device to function on the internet. And remember, it is internet standards that the IETF makes. | The onus of deciding whether to use LL or DHCP is placed mostly on the | device, which in most cases would be very resource limited Supporting a DHCP client is one of the easiest things for a device to manage, it takes just about no resources. What are you imaging this client actually doing with so few resources that it can't handle that? kre From owner-zeroconf@merit.edu Sun Jan 26 03:17:58 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15120 for ; Sun, 26 Jan 2003 03:17:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4292291262; Sun, 26 Jan 2003 03:21:16 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 103F891270; Sun, 26 Jan 2003 03:21: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 1676191262 for ; Sun, 26 Jan 2003 03:21:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id EB6585DF71; Sun, 26 Jan 2003 03:21:15 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 9759C5DDDA for ; Sun, 26 Jan 2003 03:21:12 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0Q8ImR15807; Sun, 26 Jan 2003 15:18:49 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0Q8Ih805899; Sun, 26 Jan 2003 19:18:44 +1100 (EST) From: Robert Elz To: Ted Lemon Cc: dhcwg@ietf.org, zeroconf@merit.edu, Ralph Droms Subject: Re: [dhcwg] Re: RFC2563: Threat or Danger? In-Reply-To: <7668BE02-3090-11D7-B694-00039317663C@nominum.com> References: <7668BE02-3090-11D7-B694-00039317663C@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Jan 2003 15:18:43 +0700 Message-ID: <5897.1043569123@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sat, 25 Jan 2003 10:11:45 -0800 From: Ted Lemon Message-ID: <7668BE02-3090-11D7-B694-00039317663C@nominum.com> | The server is generating a bogus DHCPOFFER. Sending this to a | non-rfc2563-compliant client would have unpredictable results. If you mean, sending address 0, then yes, but that wasn't what I meant in the text you quoted. All I meant was that it would do no harm to include option 116 in a DHCPOFFER, no more than any other option the server is configured to send (that is, option 116 along with a normal IP address). But even in the case where the server sends a full 2563 response, with addr=0.0.0.0 and option 116, why would I care what the results are in the client? (Anything from crashing, to thinking it owns address 0, to ...) The only point of sending such a response is when it isn't intended to work on the net in the first place, what happens to it (especially if it has a poor dhcp client implementation with no sanity checking) shouldn't bother anyone overly much. kre From owner-zeroconf@merit.edu Sun Jan 26 03:20:03 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15151 for ; Sun, 26 Jan 2003 03:20:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 76B5791270; Sun, 26 Jan 2003 03:23:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3834E91278; Sun, 26 Jan 2003 03:23: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 3C61391270 for ; Sun, 26 Jan 2003 03:23:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 21B385DF71; Sun, 26 Jan 2003 03:23:20 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 070E95DDDA for ; Sun, 26 Jan 2003 03:23:18 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0Q8N2R15929; Sun, 26 Jan 2003 15:23:03 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0Q8Ms805914; Sun, 26 Jan 2003 19:22:54 +1100 (EST) From: Robert Elz To: "Subrata Goswami" Cc: "'Daniel Senie'" , zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: <001901c2c4ad$f394d980$c900a8c0@SGOSWAMIPCL> References: <001901c2c4ad$f394d980$c900a8c0@SGOSWAMIPCL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 26 Jan 2003 15:22:54 +0700 Message-ID: <5912.1043569374@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sat, 25 Jan 2003 12:11:30 -0800 From: "Subrata Goswami" Message-ID: <001901c2c4ad$f394d980$c900a8c0@SGOSWAMIPCL> | I think I would prefer a working service, rather than being told | that I can not use my device because someone nearby is encroaching | into the park's property. Of course, and you can have that, you just config your systems to use their own private wireless LAN, and ignore what is coming from other places (and do remember that you can't tell the difference between a stranger nearby, and the local council/authority/... who has jurisdiction for the park). The point really is that if you're using someone else's LAN, then can do whatever to you that they want to do, and there's no way at all that you can prevent that - other than avoiding using their LAN. If you somehow believe that just configuring a LL address (assuming they allow to to work) will be a panacea, and then you get to use whatever LAN you like for your private purposes, then you have a shock coming when you actually try it. And so you should have. kre From owner-zeroconf@merit.edu Sun Jan 26 04:53:44 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15742 for ; Sun, 26 Jan 2003 04:53:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 307549127A; Sun, 26 Jan 2003 04:57:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D25369127C; Sun, 26 Jan 2003 04:56: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 540ED9127A for ; Sun, 26 Jan 2003 04:56:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 315FA5DDC2; Sun, 26 Jan 2003 04:56:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id A92E25DDA2 for ; Sun, 26 Jan 2003 04:56:57 -0500 (EST) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id EAA03231 for ; Sun, 26 Jan 2003 04:56:56 -0500 (EST) From: "Subrata Goswami" To: Subject: FW: Solving the wrong problems Date: Sun, 26 Jan 2003 01:51:09 -0800 Message-ID: <008101c2c520$74136a50$c900a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Kre, the park belongs to the public, one can use it as long he/she behaves. I do not want to steal some one else's WLAN connections, I am sure stealing is not encouraged in most countries. LL should serve a different purpose than DHCP, we do not need one more DHCP clone. The plain old DHCP is doing fine. It is possible to tell where the packet originated (using MAC address, triangulation, etc., you can buy this stuff now). Subrata > -----Original Message----- > From: owner-zeroconf@merit.edu [mailto:owner-zeroconf@merit.edu] On > Behalf Of Robert Elz > Sent: Sunday, January 26, 2003 12:23 AM > To: Subrata Goswami > Cc: 'Daniel Senie'; zeroconf@merit.edu > Subject: Re: Solving the wrong problems > > > Date: Sat, 25 Jan 2003 12:11:30 -0800 > From: "Subrata Goswami" > Message-ID: <001901c2c4ad$f394d980$c900a8c0@SGOSWAMIPCL> > > | I think I would prefer a working service, rather than being told > | that I can not use my device because someone nearby is encroaching > | into the park's property. > > Of course, and you can have that, you just config your systems to use > their own private wireless LAN, and ignore what is coming from other > places (and do remember that you can't tell the difference between a > stranger nearby, and the local council/authority/... who has > jurisdiction for the park). > > The point really is that if you're using someone else's LAN, then can > do whatever to you that they want to do, and there's no way at all > that you can prevent that - other than avoiding using their LAN. > > If you somehow believe that just configuring a LL address (assuming > they allow to to work) will be a panacea, and then you get to use > whatever LAN you like for your private purposes, then you have a shock > coming when you actually try it. And so you should have. > > kre > From owner-zeroconf@merit.edu Sun Jan 26 04:54:00 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15761 for ; Sun, 26 Jan 2003 04:53:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 273D29127B; Sun, 26 Jan 2003 04:57:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A13E89127D; Sun, 26 Jan 2003 04:57: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 2AEC09127B for ; Sun, 26 Jan 2003 04:56:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 13C6F5DDC2; Sun, 26 Jan 2003 04:56:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id 866D55DDA2 for ; Sun, 26 Jan 2003 04:56:58 -0500 (EST) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id EAA03234 for ; Sun, 26 Jan 2003 04:56:57 -0500 (EST) From: "Subrata Goswami" To: Subject: FW: Solving the wrong problems Date: Sun, 26 Jan 2003 01:51:09 -0800 Message-ID: <008201c2c520$7476c000$c900a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Kre, you are mandating a DHCP Client for all LL hosts - why ???? LL is not DHCP Next Gen or mini-DHCP, is it ? Subrata > -----Original Message----- > From: owner-zeroconf@merit.edu [mailto:owner-zeroconf@merit.edu] On > Behalf Of Robert Elz > Sent: Sunday, January 26, 2003 12:14 AM > To: Subrata Goswami > Cc: 'Erik Guttman'; zeroconf@merit.edu > Subject: Re: Solving the wrong problems > > > Date: Sat, 25 Jan 2003 08:41:42 -0800 > From: "Subrata Goswami" > Message-ID: <000401c2c490$a50220b0$c900a8c0@SGOSWAMIPCL> > > | Actually, it has to be specified how the device figures out that > | there is a DHCP server. > > It gets a DHCP reply. That is obvious. The only DHCP reply it > can get is a DHCPOFFER. So, it gets one of those. If it doesn't, > it can assume there's no DHCP server. > > | Not really, if the DHCP server does not send out any DHCPOFFER > then the > | device would not know if there is a DHCP server or not. > > Exactly, so we are assuming that it does get a DHCPOFFER. > > | what happens if the device does not even have an LED, or the LED > | malfucntions ? > > What happens if the power supply malfunctions? Let's be reasonable > please, if manufacturers want to make devices where it is impossible > to work out what kind of problem might exist whenever they don't work > perfectly, then it is going to be impossible for anyone to ever work > out what is wrong (whether it is a "no address for you" or a broken > wire in the drop cable, or too far from base station, or not plugged > in properly, or ...) > > | what happnes if the device received two DHCPOFFERS from two > | different DHCP servers, one saying can use LL and the other saying > | do not use LL. > > DHCP says that if you get 2 offers, you can pick whichever you like. I > see no reason at all to change that, so the client picks whichever > of those 2 it likes. If one of them offers an address, most likely > it would pick that one (or one of them if both do). If > neither offers an address, and one says "use LL" and the > other says "no LL", then I think if I was the client, I'd > pick the "use LL" offer, and do it. > > | I do not see any problem here. The device would not have a > corresponding > | entry in SLP or mDNS, and the user can easily figure that out from > | the absence of the entry. > > But why does it appear to be missing? Is it the server or the client > that isn't working properly? Or the switch/hub/router that > is between > them? You have to start somewhere when debugging these problems, > and starting with "it doesn't work" and nothing more, rarely helps. > > | No, not all devices that would use LL would have blinking LED's. > > No, of course not, but any device rational to use (from toasters to > air-conditioners, to washing machines, to car alarms, to ...) has some > means of "I am working" user feedback. > the examples you have given do not LEDS, and infact none of them does have LED: toaster (check for black toast), air-conditionres ( do you even where your air conditioner is ?), washing machine ( check your clothes, are they wet ? ) , car alarm (try to open a door without using your key). > | DHCP has its limitations. > > of course. And no-one is pretending that a network has to use it, if > it is inappropriate. > > | The way you are wording the 3 cases above implicity requires that > | every LL device MUST have a DHCP client. > > Yes, that's something I would support - either a DHCP client or > expect to be manually configured. Nothing else can possibly allow > the device to function on the internet. And remember, it is > internet standards that the IETF makes. > > | The onus of deciding whether to use LL or DHCP is placed mostly on > the > | device, which in most cases would be very resource limited > > Supporting a DHCP client is one of the easiest things for a device > to manage, it takes just about no resources. What are you imaging > this client actually doing with so few resources that it can't handle > that? > what is the minimum resource required ? probably depends on how much of DHCP you want to implement. a full implementation needs to have a full UDP stack + full DHCP state machine, probably 100KB of code + 5 MIPS of CPU + 10KB of RAM. the point is, why does an LL device that knows that it is never going to use DHCP have the DHCP stack in it ? think about a network that does not have DHCP server, even here the LL devices need to carry the DHCP client. > kre > From owner-zeroconf@merit.edu Sun Jan 26 10:46:28 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19297 for ; Sun, 26 Jan 2003 10:46:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DC95191286; Sun, 26 Jan 2003 10:49:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA18391288; Sun, 26 Jan 2003 10:49: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 7055B91286 for ; Sun, 26 Jan 2003 10:49:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 578935DDA5; Sun, 26 Jan 2003 10:49:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id CB4C85DDA4 for ; Sun, 26 Jan 2003 10:49:40 -0500 (EST) Received: from nominum.com (dsl081-073-044.sfo1.dsl.speakeasy.net [64.81.73.44]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0QFiZP08660; Sun, 26 Jan 2003 09:44:36 -0600 (CST) Date: Sun, 26 Jan 2003 07:49:36 -0800 Subject: Re: Solving the wrong problems Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: Daniel Senie , zeroconf@merit.edu To: Robert Elz From: Ted Lemon In-Reply-To: <5865.1043568164@munnari.OZ.AU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Of course. But they're going to take control one way or another > anyway. > You can't prevent that (other than by not using their network). Isn't > it better to have an obvious "the admin says you can't (or shouldn't) > do > that" technique, than just "it failed" ? Like many techniques that can be used to deny service, this one is great in theory. The problem is that because it opens up an easy DoS attack, it's not great in practice. I am not arguing that the administrator being able to send an affirmative message to the client to tell it that it can't use the network is a bad thing. I am arguing that programming the client to obey such a message is a bad thing, not because some legitimate administrator will use it, but because some attacker will use it. (I will admit that I do not believe that the administrator at an ISP is the legitimate administrator of my home network, of course). After this weekend's fiasco, I think we can all dispense with the idea that nobody would do such a thing, so we don't need to worry about it. Mechanisms that massively amplify a miscreant's ability to create havoc can't be left lying around where a miscreant can use them, or they will be used. From owner-zeroconf@merit.edu Sun Jan 26 18:44:50 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23525 for ; Sun, 26 Jan 2003 18:44:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0AA9191263; Sun, 26 Jan 2003 18:47:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A11DC912A4; Sun, 26 Jan 2003 18:47:23 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3841B91263 for ; Sun, 26 Jan 2003 18:47:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 155CF5DFC7; Sun, 26 Jan 2003 18:47:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id 814645DF7D for ; Sun, 26 Jan 2003 18:47:21 -0500 (EST) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id SAA28082; Sun, 26 Jan 2003 18:40:32 -0500 (EST) From: "Subrata Goswami" To: "'Robert Elz'" Cc: Subject: RE: Solving the wrong problems Date: Sun, 26 Jan 2003 15:34:46 -0800 Message-ID: <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <6441.1043576715@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All IPv4 nodes except some should DHCP have clients, right? These some exceptions being the servers whose IP addresses are manually configured. There is all ready a exception for not using DHCP clients and LL would be just another one. In my view an IPv4 node MAY be configured an IP address in any of the following ways: Manual, DHCP, PPP/RADIUS, LL, ... The order of preference SHOULD be Manual, DHCP, LL, ... Why is it that a node that has no manual config or no DHCP is useless ? Networking world has many examples to the contrary (in Ethernet the MAC address is not usually manually configured). Why can not IETF standardize LL independent of DHCP ? Why is a device that does not have DHCP is useless (LL can certainly supply the required IP address in a non-conflicting way) ? Subrata > -----Original Message----- > From: Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: Sunday, January 26, 2003 2:25 AM > To: Subrata Goswami > Subject: Re: Solving the wrong problems > > > Date: Sun, 26 Jan 2003 01:26:09 -0800 > From: "Subrata Goswami" > Message-ID: <008001c2c51c$f6994070$c900a8c0@SGOSWAMIPCL> > > | You are mandating a DHCP Client for all LL hosts - why ???? > > Not all LL hosts, all IPv4 hosts (except those for which > manual configuration alone is adequate, which may mean some > types of servers). > > Hosts using LL are just a subset of that. > > If a host has no DHCP, and no manual configuration, then it > is useless on the internet, and the IETF (in particular) has > no business standardising > that. We want to make standards that work in all environments, for > all users - that's the point of having standards. > > No-one is going to mandate that you use the DHCP that is > there, but if it isn't there, the device is simply useless to > me, and certainly isn't anything useful for the Internet (as > in *I*ETF). > > kre > From owner-zeroconf@merit.edu Sun Jan 26 20:52:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24740 for ; Sun, 26 Jan 2003 20:52:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4EF9D91265; Sun, 26 Jan 2003 20:55:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C9A991269; Sun, 26 Jan 2003 20:55: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 1AC2691265 for ; Sun, 26 Jan 2003 20:55:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0489C5E005; Sun, 26 Jan 2003 20:55:56 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 85F105DF88 for ; Sun, 26 Jan 2003 20:55:53 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0R1tQR18017; Mon, 27 Jan 2003 08:55:27 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0R1sl811600; Mon, 27 Jan 2003 12:54:48 +1100 (EST) From: Robert Elz To: Ted Lemon Cc: Daniel Senie , zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Jan 2003 08:54:47 +0700 Message-ID: <11598.1043632487@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 26 Jan 2003 07:49:36 -0800 From: Ted Lemon Message-ID: | The problem is that because it opens up an easy DoS attack, I am still waiting to learn what this is. Absolutely nothing that has been offered so far looks to me like "opening up" anything. I believe you have even agreed that if an "attacker" can answer your DHCPDISCOVER packets (one way or another) they can already wreak havoc with your network (offer you useless IP addresses, etc). What is really new in this new method? In fact, even convince me that the 2563 method is as bad as what exists already (given that to be effective it requires that legitimate dhcpoffers be blocked, whereas other dhcp attacks do not) and I'll rethink this (which does not necessarily mean that I will arrive at a different conclusion). | I am arguing | that programming the client to obey such a message is a bad thing, not | because some legitimate administrator will use it, but because some | attacker will use it. For that argument to make sense, you'd have to also argue that clients should not obey any dhcp reply, as not only can some legitimate administrator use it, but also because some attacker will use it. In fact, you'd have to require that a client not take any notice of any autoconfiguration methods, as they necessarily can't be authenticated, and hence are open to attacks. In that case, it would be time for zeroconf to shut down wouldn't it? Its whole aim is autoconf. | After this weekend's fiasco, I think we can all dispense with the idea | that nobody would do such a thing, so we don't need to worry about it. Of course they will. On the other hand, we really can't allow the possibility that "evil doers" will do their evil to prevent us from doing what we need to operate, can we? There needs to be a balance. | Mechanisms that massively amplify a miscreant's ability to create | havoc can't be left lying around where a miscreant can use them, or | they will be used. Of course. But what has that got to do with the current topic? What is amplifying anything here? You're assuming that, without, at least so far, being able to demonstrate in any way at all that 2563 is even as bad as DHCP itself in this regard. Where's the amplification? kre From owner-zeroconf@merit.edu Sun Jan 26 21:00:53 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24838 for ; Sun, 26 Jan 2003 21:00:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9FDFB91267; Sun, 26 Jan 2003 21:04:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F57091269; Sun, 26 Jan 2003 21:04: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 7E45891267 for ; Sun, 26 Jan 2003 21:03:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5FC215DF88; Sun, 26 Jan 2003 21:03:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 3EBCA5DE9D for ; Sun, 26 Jan 2003 21:03:36 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0R22lR21142; Mon, 27 Jan 2003 09:02:48 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0R22g811618; Mon, 27 Jan 2003 13:02:42 +1100 (EST) From: Robert Elz To: "Subrata Goswami" Cc: zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL> References: <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Jan 2003 09:02:42 +0700 Message-ID: <11616.1043632962@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 26 Jan 2003 15:34:46 -0800 From: "Subrata Goswami" Message-ID: <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL> | All IPv4 nodes except some should DHCP have clients, right? These some | exceptions | being the servers whose IP addresses are manually configured. There is | all ready a exception for not using DHCP clients and LL would be just | another one. No. LL is not "just another one". DHCP and manual configuration offer exactly the same functionality, just done by different people (in different ways). LL does not. A host with a LL address is useless on the internet. | Why is it that a node that has no manual config or no DHCP is useless ? Because it cannot communicate with the network if all it has is LL. All it can communicate with is the link. If that's all it wants to communicate with, it doesn't need IP at all, it may just as well send raw ethernet (or whatever its link layer is) frames and be done with it. Why even pretend it is using internet protocols, when it is using them in a way that they won't & can't work over the internet? | Networking world has many examples to the contrary (in Ethernet the | MAC address is not usually manually configured). Of course it is, by someone at the factory. If you want to (and can invent a scheme that will actually work with Internet routing) have IP addresses configured at the factory, that would be fine too. | Why can not IETF standardize LL independent of DHCP ? Why | is a device that does not have DHCP is useless (LL can certainly | supply the required IP address in a non-conflicting way) ? No, LL only supplies LL addresses, which are useless on the internet. Read the draft, routers aren't allowed to forward packets containing them. What use (on the internet) is a packet that no router is allowed to forward? Note: I am not saying that there's anything wrong with being able to get a LL address, if that is all available on some particular net, that's fine. What I am saying is that if there's some other address available for the node, which will work better than the LL address, the node has to be able to acquire that other address (via DHCP, manual configuration - or via PPP or similar, though LL addresses and PPP aren't often going to be in conflict). kre From owner-zeroconf@merit.edu Sun Jan 26 23:02:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26258 for ; Sun, 26 Jan 2003 23:02:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 08D0F912A7; Sun, 26 Jan 2003 23:05:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 796BC9126B; Sun, 26 Jan 2003 23:04: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 20C1191269 for ; Sun, 26 Jan 2003 22:57:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 07B575DE56; Sun, 26 Jan 2003 22:57:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 2A9A25DDCF for ; Sun, 26 Jan 2003 22:57:40 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0R3qWP14212; Sun, 26 Jan 2003 21:52:32 -0600 (CST) Date: Sun, 26 Jan 2003 19:57:39 -0800 Subject: Re: Solving the wrong problems Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu, Daniel Senie To: Robert Elz From: Ted Lemon In-Reply-To: <11598.1043632487@munnari.OZ.AU> Message-Id: <7A6E9794-31AB-11D7-B134-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I am still waiting to learn what this is. Absolutely nothing that has > been offered so far looks to me like "opening up" anything. I already explained to you why the RFC2563 attack is more effective than simply giving out a bogus IP address. If you get a bogus IP address you can still do IPv4ll. If you are attacked via RFC2563, and you honor the attack, you can't use the network at all. From owner-zeroconf@merit.edu Sun Jan 26 23:36:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26481 for ; Sun, 26 Jan 2003 23:36:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5A3FA91269; Sun, 26 Jan 2003 23:39:40 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BFF89126A; Sun, 26 Jan 2003 23:39: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 406B591269 for ; Sun, 26 Jan 2003 23:39:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2DEA45DE56; Sun, 26 Jan 2003 23:39:39 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 2689E5DD9C for ; Sun, 26 Jan 2003 23:39:37 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0R4cqR08233; Mon, 27 Jan 2003 11:38:52 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0R4cj812426; Mon, 27 Jan 2003 15:38:47 +1100 (EST) From: Robert Elz To: Ted Lemon Cc: zeroconf@merit.edu, Daniel Senie Subject: Re: Solving the wrong problems In-Reply-To: <7A6E9794-31AB-11D7-B134-00039317663C@nominum.com> References: <7A6E9794-31AB-11D7-B134-00039317663C@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Jan 2003 11:38:45 +0700 Message-ID: <12424.1043642325@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 26 Jan 2003 19:57:39 -0800 From: Ted Lemon Message-ID: <7A6E9794-31AB-11D7-B134-00039317663C@nominum.com> | I already explained to you why the RFC2563 attack is more effective | than simply giving out a bogus IP address. If you get a bogus IP | address you can still do IPv4ll. That isn't what current IPv4LL implementations do (note: "bogus" here is immaterial, the host can't tell what is bogus and what isn't), and isn't the position that this WG seems to be converging upon. See the message from Erik Guttman, Fri 24 Jan (<3E31672C.2010902@sun.com>) The issue being debated has been about whether there can be/should be a mechanism to disable LL even in cases where the DHCP server doesn't want to give out an address (which is why 2563 is relevant of course). So, once again, what is this problem that 2563 causes and doesn't already exist? kre From owner-zeroconf@merit.edu Mon Jan 27 00:51:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27783 for ; Mon, 27 Jan 2003 00:51:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AA1069126B; Mon, 27 Jan 2003 00:55:07 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7BB839126C; Mon, 27 Jan 2003 00: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 3D01D9126B for ; Mon, 27 Jan 2003 00:55:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 241315DD95; Mon, 27 Jan 2003 00:55:06 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id 98C375DDF7 for ; Mon, 27 Jan 2003 00:55:05 -0500 (EST) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id AAA00909; Mon, 27 Jan 2003 00:48:16 -0500 (EST) From: "Subrata Goswami" To: "'Robert Elz'" Cc: Subject: RE: Solving the wrong problems Date: Sun, 26 Jan 2003 21:42:27 -0800 Message-ID: <00bc01c2c5c6$e13cf460$c900a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <11616.1043632962@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit See inline > -----Original Message----- > From: Robert Elz [mailto:kre@munnari.OZ.AU] > Sent: Sunday, January 26, 2003 6:03 PM > To: Subrata Goswami > Cc: zeroconf@merit.edu > Subject: Re: Solving the wrong problems > > > Date: Sun, 26 Jan 2003 15:34:46 -0800 > From: "Subrata Goswami" > Message-ID: <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL> > > | All IPv4 nodes except some should DHCP have clients, > right? These some > | exceptions > | being the servers whose IP addresses are manually > configured. There is > | all ready a exception for not using DHCP clients and LL > would be just > | another one. > > No. LL is not "just another one". DHCP and manual > configuration offer > exactly the same functionality, just done by different people > (in different > ways). LL does not. A host with a LL address is useless > on the internet. > Agreed LL packets are not supposed to be forwarded by a router ( I would say this needs to be changed too), but it is still useful in the link-local internet. Primarily because all application written on IP can still work - there are very few applications that work directly on top of the link layer protocol. > | Why is it that a node that has no manual config or no > DHCP is useless ? > > Because it cannot communicate with the network if all it has is LL. > All it can communicate with is the link. If that's all it wants to > communicate with, it doesn't need IP at all, it may just as > well send raw ethernet (or whatever its link layer is) frames > and be done with it. Why even pretend it is using internet > protocols, when it is using them in a way that they won't & > can't work over the internet? > Not really, as I mentioned previously most applications are IP based and primarily uses the Sockets API. LL would allow these applications to still work within the link (e.g. applications such as HTTP, Telnet, FTP, NetBIOS, NFS, etc.). > | Networking world has many examples to the contrary (in > Ethernet the > | MAC address is not usually manually configured). > > Of course it is, by someone at the factory. If you want to (and can > invent a scheme that will actually work with Internet > routing) have IP addresses configured at the factory, that > would be fine too. > > | Why can not IETF standardize LL independent of DHCP ? Why > | is a device that does not have DHCP is useless (LL can certainly > | supply the required IP address in a non-conflicting way) ? > > No, LL only supplies LL addresses, which are useless on the > internet. Read the draft, routers aren't allowed to forward > packets containing > them. What use (on the internet) is a packet that no router > is allowed > to forward? > Let us address the issue of forwarding packets to the Internet. I guess the draft can allow for a NAT function in the LL link which can be part of the router. The NAT would translate the 169.254/16 address to a routable (locally or globally) address as they do for 192.168/16 or 10/24. Although if a NAT is allowed then there is very little distinction between 169.254 and 192.168. Currently the draft allows a LL node to access the internet through an application level intermediary (i.e. the intermediary can do the required NAT/forward when you type http://www.ietf.org ). I my view the draft can be also be changed by replacing the following statement in several places (this would allow disposing off the intermediary). From "The host MUST NOT send the packet to any router for forwarding" To "The host MAY send the packet to a router for forwarding" The router should be responsible for making the decision to forward/not-forward the 169.254/16 packets. If the router can NAT a 169.254/16 then it MAY forward the 169.254 packet, if the router can not NAT the 169.254 packets it MUST not forward the 169.254 packet. I concur with you that adding the capability to access the global Internet would increase the value of LL. > Note: I am not saying that there's anything wrong with being > able to get a LL address, if that is all available on some > particular net, that's fine. What I am saying is that if > there's some other address available for the node, which will > work better than the LL address, the node has to be able to > acquire that other address (via DHCP, manual configuration - > or via PPP or similar, though LL addresses and PPP aren't > often going to be in conflict). > > kre > From owner-zeroconf@merit.edu Mon Jan 27 02:54:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09275 for ; Mon, 27 Jan 2003 02:54:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 77110912A9; Mon, 27 Jan 2003 02:58:02 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 448DF912AB; Mon, 27 Jan 2003 02: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 40D04912A9 for ; Mon, 27 Jan 2003 02:58:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1CF965DDCE; Mon, 27 Jan 2003 02:58:01 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 6E2E75DDCD for ; Mon, 27 Jan 2003 02:57:51 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0R7uGR16476; Mon, 27 Jan 2003 14:56:19 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0R7tr812878; Mon, 27 Jan 2003 18:55:53 +1100 (EST) From: Robert Elz To: "Subrata Goswami" Cc: zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: <00bc01c2c5c6$e13cf460$c900a8c0@SGOSWAMIPCL> References: <00bc01c2c5c6$e13cf460$c900a8c0@SGOSWAMIPCL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Jan 2003 14:55:53 +0700 Message-ID: <12876.1043654153@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 26 Jan 2003 21:42:27 -0800 From: "Subrata Goswami" Message-ID: <00bc01c2c5c6$e13cf460$c900a8c0@SGOSWAMIPCL> | Agreed LL packets are not supposed to be forwarded by a router ( I | would say this needs to be changed too), OK. you go and design the scheme that makes this work, write it up as an I-D, and it will be considered, I'm sure. In the meantime I'd suggest that we should just continue with what we know can work. | but it is still useful in the link-local | internet. Primarily because all application written on IP can still work | there are very few applications that work directly on top of the link | layer protocol. Of course. No-one is doubting the utility of LL addresses when they're appropriate to use. The question (this particular question) is whether the IETF should be suggesting to people that devices which only work on one link are reaosnable? And all so that the implementors of those devices can avoid adding in a DHCP client (which for an embedded device is likely to take a few hours of effort - the hard part in most DHCP clients is interfacing with the rest of the system, which isn't a problem embedded devices usually have). | Let us address the issue of forwarding packets to the Internet. | I guess the draft can allow for a NAT function in the LL link Hmm - you're mandating NAT exist, and be enabled, in every router, to allow LL devices to exist there. And by inference you're also mandating just one router on any LAN (NAT doesn't work when there are alternate paths traffic can take). I think I'll leave it for someone else to respond to that suggestion. | Although if a NAT is allowed then there is very | little distinction between 169.254 and 192.168. If there's only one LAN, yes, but 1918 addresses work (and are routed) just fine throughout the whole organisation usually - with just one NAT point at the exit from it to the Internet. LL addreses don't work like that. | I concur with you that adding the capability to access the global | Internet would increase the value of LL. That's interesting, as that's not something I have ever said. Devices should be able to access the Internet (in case they are connected in a place where that is possible - they should also be able to use LL, in case they're connected in a place where there is no address management). But the way to access the internet (and even just the rest of the organisation) is to acquire an address of whatever kind is appropriate for use in the organisation (if that happens to be a LL address, with NAT in every router, I personally don't mind that too much, but I am dead certain I am never going to use a net like that, so if the device is to have any utility at all, it had better be able to get some other address instead). kre From owner-zeroconf@merit.edu Mon Jan 27 03:33:38 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09734 for ; Mon, 27 Jan 2003 03:33:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC345912AB; Mon, 27 Jan 2003 03:36:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE608912B2; Mon, 27 Jan 2003 03:36: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 99AB7912AB for ; Mon, 27 Jan 2003 03:35:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7859D5DDCD; Mon, 27 Jan 2003 03:35:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id E5A035DD93 for ; Mon, 27 Jan 2003 03:35:35 -0500 (EST) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id DAA08038; Mon, 27 Jan 2003 03:28:47 -0500 (EST) From: "Subrata Goswami" To: "'Robert Elz'" Cc: Subject: RE: Solving the wrong problems Date: Mon, 27 Jan 2003 00:23:00 -0800 Message-ID: <000601c2c5dd$4ecd5900$c900a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <12876.1043654153@munnari.OZ.AU> x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit see inline > -----Original Message----- > From: owner-zeroconf@merit.edu > [mailto:owner-zeroconf@merit.edu] On Behalf Of Robert Elz > Sent: Sunday, January 26, 2003 11:56 PM > To: Subrata Goswami > Cc: zeroconf@merit.edu > Subject: Re: Solving the wrong problems > > > Date: Sun, 26 Jan 2003 21:42:27 -0800 > From: "Subrata Goswami" > Message-ID: <00bc01c2c5c6$e13cf460$c900a8c0@SGOSWAMIPCL> > > | Agreed LL packets are not supposed to be forwarded by a router ( I > | would say this needs to be changed too), > > OK. you go and design the scheme that makes this work, write it up > as an I-D, and it will be considered, I'm sure. In the meantime > I'd suggest that we should just continue with what we know can work. > > | but it is still useful in the link-local > | internet. Primarily because all application written on IP > can still work > | there are very few applications that work directly on > top of the link > | layer protocol. > > Of course. No-one is doubting the utility of LL addresses > when they're > appropriate to use. > let me reiterate, there are applications such as HTTP, Telnet, FTP, NetBIOS, NFS, which would still work with LL (within the link) without modification. > The question (this particular question) is whether the IETF > should be suggesting to people that devices which only work > on one link are reasonable? And all so that the implementors > of those devices can avoid adding in a DHCP client (which for > an embedded device is likely to take a few hours of effort - > the hard part in most DHCP clients is interfacing with the > rest of the system, which isn't a problem embedded devices > usually have). > It is not time needed to adding DHCP stack to a node, the question is DHCP needed at all in all circumstances ? In my view DHCP is not always needed and an LL node does not need to be DHCP cognizant. > > | Let us address the issue of forwarding packets to the Internet. > | I guess the draft can allow for a NAT function in the LL link > > Hmm - you're mandating NAT exist, and be enabled, in every router, > to allow LL devices to exist there. And by inference you're also > mandating just one router on any LAN (NAT doesn't work when there are > alternate paths traffic can take). I think I'll leave it > for someone > else to respond to that suggestion. > No I am not mandating NAT in every router, only the ones that are willing to forward 169.254 packets. In any case the draft already mandates that every router be aware of 169.254, no harm in extending that notion a little bit more. > | Although if a NAT is allowed then there is very > | little distinction between 169.254 and 192.168. > > If there's only one LAN, yes, but 1918 addresses work (and > are routed) just fine throughout the whole organisation > usually - with just one NAT > point at the exit from it to the Internet. LL addreses don't work > like that. > That is exactly what I meant. Its behavior similar to a packet with TTL of 0. > | I concur with you that adding the capability to access > the global > | Internet would increase the value of LL. > > That's interesting, as that's not something I have ever said. well you mentined accessing the internet, which I assume can include the global Internet too. > Devices > should be able to access the Internet (in case they are > connected in a place where that is possible - they should > also be able to use LL, in case they're connected in a place > where there is no address management). > > But the way to access the internet (and even just the rest of the > organisation) is to acquire an address of whatever kind is > appropriate for use in the organisation (if that happens to > be a LL address, with NAT in every router, I personally don't > mind that too much, but I am dead certain I am never going to > use a net like that, so if the device is to have any utility > at all, it had better be able to get some other address instead). > What happens if you want a network that is not part of an organization (i.e. no central authority etc.) ? There is use for such networks (for instance in defense ). In such a situations you do not care about any node outside the link. > kre > From owner-zeroconf@merit.edu Mon Jan 27 04:45:41 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10876 for ; Mon, 27 Jan 2003 04:45:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A81AA91213; Mon, 27 Jan 2003 04:48:57 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7404A912AF; Mon, 27 Jan 2003 04:48: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 8309391213 for ; Mon, 27 Jan 2003 04:48:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 661EC5DDF1; Mon, 27 Jan 2003 04:48:32 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 5137C5DD8D for ; Mon, 27 Jan 2003 04:47:59 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0R9kgR17124; Mon, 27 Jan 2003 16:46:43 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0R9kX813271; Mon, 27 Jan 2003 20:46:33 +1100 (EST) From: Robert Elz To: "Subrata Goswami" Cc: zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: <000601c2c5dd$4ecd5900$c900a8c0@SGOSWAMIPCL> References: <000601c2c5dd$4ecd5900$c900a8c0@SGOSWAMIPCL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 27 Jan 2003 16:46:32 +0700 Message-ID: <13269.1043660792@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 27 Jan 2003 00:23:00 -0800 From: "Subrata Goswami" Message-ID: <000601c2c5dd$4ecd5900$c900a8c0@SGOSWAMIPCL> | let me reiterate, there are applications such as HTTP, Telnet, | FTP, NetBIOS, NFS, which would still work with LL (within the link) | without modification. Of course, within the link, any IP application will work with LL addresses just fine (the application doesn't need to know they're LL addresses, it probably doesn't know there's just one link, in this particular environment, LL addresses are just addresses). You don't need to keep repeating this, we all understand already. | It is not time needed to adding DHCP stack to a node, the question | is DHCP needed at all in all circumstances ? In my view DHCP | is not always needed To there. I agree with you, DHCP isn't always needed. But ... | and an LL node does not need to be DHCP cognizant. How can the device (MP3 player, toaster, lightbulb, ...) possibly know if it is going to be installed on a net where DHCP is needed, and used, or whether it is not to be? No-one is asking you to use DHCP on your net if you don't want to, and if you don't, LL addresses as they currently seem to be being defined will work for you just fine. But on my net, such devices simply won't work - the system I use to control my light bulbs will not be on the same LAN as the light bulbs themselves. And there will ne no NAT. If the light bulbs are unable to use DHCP to get addresses, they are useless, they'll never turn on (or off perhaps) and so are no better than no lightbulb at all. Why would a light bulb manufacturer even consider making bulbs that can't work for many consumers, when they can trivially be made for everyone? Why would the IETF want to suggest that making such things is an acceptable thing to do? (Of course, no-one can stop a manufacturer manufacturing them if it wants to, if it thinks it can make them that much cheaper, and so attract the consumers for whom LL addresses alone are sufficient, then it will do that, whatever the IETF says). | No I am not mandating NAT in every router, only the ones that are | willing to forward 169.254 packets. OK, but if LL addresses are to be useful outside one LAN, the router on that LAN has to be in that set - which would effectively mean every router has to have it, just in case. After all, you would never be able to tell whether or not someone might just connect one of your proposed LL only devices on that particular LAN. | In any case the draft already mandates that every router be aware | of 169.254, no harm in extending that notion a little bit more. I kind of suspect you won't find many people agreeing that the step between "don't forward LL" and "automatically NAT LL packets" is just "a little bit more". | > | I concur with you that adding the capability to access | > the global | > | Internet would increase the value of LL. | > | > That's interesting, as that's not something I have ever said. | | well you mentined accessing the internet, which I assume can include | the global Internet too. Yes, of course, it was the implication of accessing it from LL addresses that I didn't ever say. | What happens if you want a network that is not part of an organization | (i.e. no central authority etc.) ? Then there'd be no-one to run DHCP, and you'd be using LL addresses. Do remember that "node attempts to use DHCP" (which is what is being requested) does not mean "there must be a server to answer" - if there is none, then the node just reverts to using LL addresses instead. | There is use for such networks (for instance in defense ). The concept of a defence network with no central authority is mind blowing to me, but for your point, that doesn't really matter. | In such a situations you do not care about any node outside the link. Yes, there are lots of times that that will be sufficient. And once again, no-one wants to prevent that from working. Nothing that is being proposed would do that. Such networks are the basic model for zeroconf. The issues that are being raised are all to make sure devices that are planned for use on those networks, also will be able to work properly, without disruption, when connected to other kinds of nets. kre From owner-zeroconf@merit.edu Mon Jan 27 05:35:37 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11578 for ; Mon, 27 Jan 2003 05:35:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 648259129E; Mon, 27 Jan 2003 05:38:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29DD09129F; Mon, 27 Jan 2003 05:38: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 220B89129E for ; Mon, 27 Jan 2003 05:38:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 11FE25DE2F; Mon, 27 Jan 2003 05:38:49 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 9C1635DDF1 for ; Mon, 27 Jan 2003 05:38:48 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id A3F0359938 for ; Mon, 27 Jan 2003 10:38:43 +0000 (GMT) Message-ID: <062901c2c5f0$429be0d0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <000601c2c5dd$4ecd5900$c900a8c0@SGOSWAMIPCL> <13269.1043660792@munnari.OZ.AU> Subject: Re: Solving the wrong problems Date: Mon, 27 Jan 2003 10:38:41 -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 Robert, > How can the device (MP3 player, toaster, lightbulb, ...) possibly know > if it is going to be installed on a net where DHCP is needed, and used, > or whether it is not to be? I agree with you but draw slightly different conclusions. I see the rationale in adding the DHCP client as a commercial one: Add a DHCP client and your device will scale (from tiny to huge networks) without any configuration required (at the device). Omit the client and you will have to answer to disappointed customers. While it is good to point this out (I would be happy with a "SHOULD" clause), I don't see a need to mandate DHCP - the market will decide. If a manufacturer is sufficiently sure that their specialist device will only be used on a single link why shouldn't they omit the DHCP client. The only other reason to _mandate_ DHCP is to make an RFC2563 style option work to allow central administration to turn LL off entirely. Otherwise the draft should just ensure that if a DHCP client is present, the v4LL code interracts with it properly. Philip From owner-zeroconf@merit.edu Mon Jan 27 10:22:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17478 for ; Mon, 27 Jan 2003 10:22:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6394991272; Mon, 27 Jan 2003 10:26:00 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2717C91273; Mon, 27 Jan 2003 10:26: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 06C2B91272 for ; Mon, 27 Jan 2003 10:25:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id E93F55DE5C; Mon, 27 Jan 2003 10:25:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by segue.merit.edu (Postfix) with ESMTP id 80E485DE56 for ; Mon, 27 Jan 2003 10:25:58 -0500 (EST) Received: from funnel.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0RFQku7001312 for ; Mon, 27 Jan 2003 10:26:46 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-116.cisco.com [161.44.150.116]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA10763 for ; Mon, 27 Jan 2003 10:25:56 -0500 (EST) Message-Id: <4.3.2.7.2.20030127093005.00b7e1a8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Jan 2003 10:25:53 -0500 To: "Zeroconf Working Group" From: Ralph Droms Subject: Re: Solving the wrong problems In-Reply-To: <062901c2c5f0$429be0d0$131010ac@aldebaran> References: <000601c2c5dd$4ecd5900$c900a8c0@SGOSWAMIPCL> <13269.1043660792@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk I came to the conclusion while commuting to work this AM that this discussion is mixing zeroconf with zerodesign. That is, we're trying to come up with a protocol that provides zeroconf AND also provides zerodesign - trying to take away the requirement for any design decisions on the part of the device implementer. For example, consider these four cases (please give me a little suspension of disbelief; I've heard each of these scenarios proposed as real scenarios): 1 Bluetooth sensor device - will never connect to off-link device; always uses special-purpose applications for access and management. 2 Printer in home office - will never be used by off-link computer; accessed through existing, standard printing applications 3 Printer in enterprise network - will be used by on-link and off-link computers; accessed through existing, standard printing applications 4 Laptop - will be used in internets and ad hoc networks, will use existing and new applications These cases require different design decisions: 1: LLv4-only, perhaps no connectivity if DHCP admin says "no LLv4"? 2: LLv4-only, no attempt to use global address 3: Perhaps LLv4 and global; perhaps global only if device admin knows device will never be accessed with LLv4-compatible applications 4: Perhaps LLv4 and global; perhaps global only; user may want notification or choice of action if global address assignment fails Maybe the problem is a "mechanism" versus "policy" issue; trying to impose encode a single policy in the protocol rather than providing a mechanism for implementing a variety of policies - both in the client and in the network... So, here's a concrete proposal: We devise mechanisms for obtaining an LLv4 address, recognizing conflicts in address assignment and recovering from conflicts. This standard is independent of DHCP. We devise a mechanism for DHCP through which a network admin can advise cooperating devices that those devices SHOULD NOT obtain or use LLv4 addresses. We write a BCP doc that suggests strategies for using these two mechanisms in different operational scenarios. We let individual device implementers, device admins and network admins make the design decision about how to employ each of these mechanisms. - Ralph From owner-zeroconf@merit.edu Mon Jan 27 10:49:11 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18011 for ; Mon, 27 Jan 2003 10:49:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CD16A91273; Mon, 27 Jan 2003 10:52:32 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9ACE49129F; Mon, 27 Jan 2003 10:52: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 8EBAF91273 for ; Mon, 27 Jan 2003 10:52:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 71F335DE9C; Mon, 27 Jan 2003 10:52:31 -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 DABB05DE72 for ; Mon, 27 Jan 2003 10:52:30 -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 h0QFpu605149; Sun, 26 Jan 2003 08:51:56 -0700 Date: Mon, 27 Jan 2003 08:52:29 -0700 Subject: Re: Solving the wrong problems Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Zeroconf Working Group" To: Ralph Droms From: Alex Karahalios In-Reply-To: <4.3.2.7.2.20030127093005.00b7e1a8@funnel.cisco.com> Message-Id: <56E0E9F0-320F-11D7-BBE1-00039377AD70@Outersoft.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ralph, Your proposal sounds very reasonable. You have a yes vote from me. Alex Karahalios On Monday, January 27, 2003, at 08:25 AM, Ralph Droms wrote: > So, here's a concrete proposal: > > We devise mechanisms for obtaining an LLv4 > address, recognizing conflicts in address assignment > and recovering from conflicts. This standard > is independent of DHCP. > > We devise a mechanism for DHCP through which > a network admin can advise cooperating devices > that those devices SHOULD NOT obtain or > use LLv4 addresses. > > We write a BCP doc that suggests strategies for using > these two mechanisms in different operational > scenarios. > > We let individual device implementers, device admins > and network admins make the design > decision about how to employ each of these > mechanisms. From owner-zeroconf@merit.edu Mon Jan 27 11:33:13 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18908 for ; Mon, 27 Jan 2003 11:33:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0D3F3912B1; Mon, 27 Jan 2003 11:36:33 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCB58912B2; Mon, 27 Jan 2003 11:36: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 8455E912B1 for ; Mon, 27 Jan 2003 11:36:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6734F5DD96; Mon, 27 Jan 2003 11:36: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 DBEB65DD91 for ; Mon, 27 Jan 2003 11:36: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 LAA11857 for ; Mon, 27 Jan 2003 11:36: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 LAA28554 for ; Mon, 27 Jan 2003 11:36:29 -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 LAA07837 for ; Mon, 27 Jan 2003 11:36:28 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Mon, 27 Jan 2003 11:36:26 -0500 Subject: Re: Solving the wrong problems From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <4.3.2.7.2.20030127093005.00b7e1a8@funnel.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 01/27/2003 10:25, "Ralph Droms" wrote: > We devise mechanisms for obtaining an LLv4 > address, recognizing conflicts in address assignment > and recovering from conflicts. This standard > is independent of DHCP. > > We devise a mechanism for DHCP through which > a network admin can advise cooperating devices > that those devices SHOULD NOT obtain or > use LLv4 addresses. I would add a third mechanism independent of DHCP that allows for LL to be turned on or off manually. There is a need. We don't dictate the how, just that it's there. john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Mon Jan 27 11:34:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18930 for ; Mon, 27 Jan 2003 11:34:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 747BD912B2; Mon, 27 Jan 2003 11:37:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A10B912B3; Mon, 27 Jan 2003 11:37: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 98188912B2 for ; Mon, 27 Jan 2003 11:37:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7D40F5DE15; Mon, 27 Jan 2003 11:37:34 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 61C765DD96 for ; Mon, 27 Jan 2003 11:37:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 1D57313FD7; Mon, 27 Jan 2003 11:37:34 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 07132-02; Mon, 27 Jan 2003 11:37:33 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 7B1BA13FD5; Mon, 27 Jan 2003 11:37:33 -0500 (EST) Date: Mon, 27 Jan 2003 11:37:33 -0500 From: Keith Moore To: Ralph Droms Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Solving the wrong problems Message-Id: <20030127113733.67152718.moore@cs.utk.edu> In-Reply-To: <4.3.2.7.2.20030127093005.00b7e1a8@funnel.cisco.com> References: <000601c2c5dd$4ecd5900$c900a8c0@SGOSWAMIPCL> <13269.1043660792@munnari.OZ.AU> <4.3.2.7.2.20030127093005.00b7e1a8@funnel.cisco.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: b52b8d528424e9480738d2cf9ae0be81a8c88005 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit strongly disagree. It's entirely unreasonable for a device to assume that it's okay to run LL on an IP network. It's almost entirely unreasonable for a device to assume that LL will be sufficient for its purposes. I don't care what the mechanism is, but there MUST be some mechanism to allow a network to disable LL, and devices MUST support it. this is a showstopper. Keith > So, here's a concrete proposal: > > We devise mechanisms for obtaining an LLv4 > address, recognizing conflicts in address assignment > and recovering from conflicts. This standard > is independent of DHCP. > > We devise a mechanism for DHCP through which > a network admin can advise cooperating devices > that those devices SHOULD NOT obtain or > use LLv4 addresses. > > We write a BCP doc that suggests strategies for using > these two mechanisms in different operational > scenarios. > > We let individual device implementers, device admins > and network admins make the design > decision about how to employ each of these > mechanisms. > > - Ralph > > From owner-zeroconf@merit.edu Mon Jan 27 12:09:23 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19807 for ; Mon, 27 Jan 2003 12:09:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 032B9912B3; Mon, 27 Jan 2003 12:12:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BEB69912B5; Mon, 27 Jan 2003 12:12: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 98770912B3 for ; Mon, 27 Jan 2003 12:12:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 807EF5DE31; Mon, 27 Jan 2003 12:12: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 436B75DDC6 for ; Mon, 27 Jan 2003 12:12:42 -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 h0RHCeJ23962 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO) for ; Mon, 27 Jan 2003 12:12:41 -0500 Message-Id: <5.2.0.9.2.20030127081455.02808200@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 27 Jan 2003 12:12:29 -0500 To: zeroconf@merit.edu From: Daniel Senie Subject: Re: Solving the wrong problems In-Reply-To: <11616.1043632962@munnari.OZ.AU> References: <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL> <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 09:02 PM 1/26/2003, Robert Elz wrote: > Date: Sun, 26 Jan 2003 15:34:46 -0800 > From: "Subrata Goswami" > Message-ID: <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL> > > | All IPv4 nodes except some should DHCP have clients, right? These some > | exceptions > | being the servers whose IP addresses are manually configured. There is > | all ready a exception for not using DHCP clients and LL would be just > | another one. > >No. LL is not "just another one". DHCP and manual configuration offer >exactly the same functionality, just done by different people (in different >ways). LL does not. A host with a LL address is useless on the internet. And...? So LL addresses are useless on the big-I Internet. They are not useless overall. Is that a problem? > | Why is it that a node that has no manual config or no DHCP is useless ? > >Because it cannot communicate with the network if all it has is LL. >All it can communicate with is the link. If that's all it wants to >communicate with, it doesn't need IP at all, it may just as well send >raw ethernet (or whatever its link layer is) frames and be done with it. >Why even pretend it is using internet protocols, when it is using them in >a way that they won't & can't work over the internet? Because there are USEFUL THINGS to do with the TCP/IP protocol suite OTHER than talking to someone on the far side of the planet. LL can and does provide a communications path for such. > | Networking world has many examples to the contrary (in Ethernet the > | MAC address is not usually manually configured). > >Of course it is, by someone at the factory. I suspect he was implying overriding of the factory value, but cannot be sure. Most people should not mess with this, but there are times when it's useful. > If you want to (and can >invent a scheme that will actually work with Internet routing) have IP >addresses configured at the factory, that would be fine too. That would not be fine. > | Why can not IETF standardize LL independent of DHCP ? Why > | is a device that does not have DHCP is useless (LL can certainly > | supply the required IP address in a non-conflicting way) ? > >No, LL only supplies LL addresses, which are useless on the internet. The fact that the addresses are "useless on the Internet" does not mean they are useless on a local network. I'm not sure whether you're trying to imply this or not. >Read the draft, routers aren't allowed to forward packets containing >them. What use (on the internet) is a packet that no router is allowed >to forward? None. But that does not make such addresses or packets useless. There's more to the world of networking than the big-I Internet. >Note: I am not saying that there's anything wrong with being able to get >a LL address, if that is all available on some particular net, that's fine. OK >What I am saying is that if there's some other address available for the >node, which will work better than the LL address, the node has to be able >to acquire that other address (via DHCP, manual configuration - or via >PPP or similar, though LL addresses and PPP aren't often going to be in >conflict). And this is FINE for a Host. However, if we're talking about a printer or print server, it may not be fine. A printer may do better having both an LL address and a non-LL address. The preference would be to use the non-LL, but if talking with a device that has no non-LL address, having the ability to print might be useful (if that's what the owner of the devices wants). From owner-zeroconf@merit.edu Mon Jan 27 13:58:45 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22850 for ; Mon, 27 Jan 2003 13:58:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 40A20912BA; Mon, 27 Jan 2003 14:01:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02015912BB; Mon, 27 Jan 2003 14:01: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 DCFF1912BA for ; Mon, 27 Jan 2003 14:01:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id C2EB55DD91; Mon, 27 Jan 2003 14:01:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 810635DD8D for ; Mon, 27 Jan 2003 14:01:41 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0RJ1eSR002683 for ; Mon, 27 Jan 2003 11:01:41 -0800 (PST) Date: Mon, 27 Jan 2003 14:01:39 -0500 (EST) From: Ralph Droms To: zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: <20030127113733.67152718.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Keith - I think we are going to disagree on this point...but maybe we're disagreeing about different points. In your second paragraph, what do you mean by "okay to run LL on an IP network"? Do you mean "LL will be sufficient for its purposes" or that LL is something that the network admin wants to allow on the link. IMHO, the assumption that "LL will be sufficient for its purposes" is a design decision by the device/stack/application implementer. - Ralph On Mon, 27 Jan 2003, Keith Moore wrote: > strongly disagree. > > It's entirely unreasonable for a device to assume that it's okay to > run LL on an IP network. It's almost entirely unreasonable for a device > to assume that LL will be sufficient for its purposes. > > I don't care what the mechanism is, but there MUST be some mechanism > to allow a network to disable LL, and devices MUST support it. > > this is a showstopper. > > Keith > > > So, here's a concrete proposal: > > > > We devise mechanisms for obtaining an LLv4 > > address, recognizing conflicts in address assignment > > and recovering from conflicts. This standard > > is independent of DHCP. > > > > We devise a mechanism for DHCP through which > > a network admin can advise cooperating devices > > that those devices SHOULD NOT obtain or > > use LLv4 addresses. > > > > We write a BCP doc that suggests strategies for using > > these two mechanisms in different operational > > scenarios. > > > > We let individual device implementers, device admins > > and network admins make the design > > decision about how to employ each of these > > mechanisms. > > > > - Ralph > > > > > From owner-zeroconf@merit.edu Mon Jan 27 14:25:42 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23562 for ; Mon, 27 Jan 2003 14:25:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C0BB9912BF; Mon, 27 Jan 2003 14:29:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E392912C0; Mon, 27 Jan 2003 14:29:04 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 63E8B912BF for ; Mon, 27 Jan 2003 14:29:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 532BE5DEB4; Mon, 27 Jan 2003 14:29:03 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 3A0B45DE7B for ; Mon, 27 Jan 2003 14:29:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 08D0A14008; Mon, 27 Jan 2003 14:29:03 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 30835-02; Mon, 27 Jan 2003 14:29:02 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 6BF8913FFB; Mon, 27 Jan 2003 14:29:02 -0500 (EST) Date: Mon, 27 Jan 2003 14:29:02 -0500 From: Keith Moore To: Ralph Droms Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Solving the wrong problems Message-Id: <20030127142902.461fc452.moore@cs.utk.edu> In-Reply-To: References: <20030127113733.67152718.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 0d2e43ce2f1a67982e5e7010a4f00621fa0126ae Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > IMHO, the assumption that "LL will be sufficient for its purposes" is > a design decision by the device/stack/application implementer. Strongly disagree. The device/stack/application implementor has no idea about the characteristics of the networks that the device will connect to, and therefore has no idea whether or not the device is going to be able to talk to the other hosts it needs to talk to using only the local link. Or at least, the set of devices for which this is a reasonable assumption is within epsilon of the null set. From owner-zeroconf@merit.edu Mon Jan 27 14:32:00 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23754 for ; Mon, 27 Jan 2003 14:31:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 782D49121B; Mon, 27 Jan 2003 14:34:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 451D4912C9; Mon, 27 Jan 2003 14:34:35 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 694FF9121B for ; Mon, 27 Jan 2003 14:34:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 52CF45DEC5; Mon, 27 Jan 2003 14:34:31 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by segue.merit.edu (Postfix) with ESMTP id E6B6F5DE7B for ; Mon, 27 Jan 2003 14:34:30 -0500 (EST) Received: from mspacman.gpcc.itd.umich.edu (mspacman.gpcc.itd.umich.edu [141.211.2.210]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id OAA18239; Mon, 27 Jan 2003 14:34:30 -0500 (EST) Received: from localhost (sgoswami@localhost) by mspacman.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id OAA17390; Mon, 27 Jan 2003 14:34:29 -0500 (EST) Date: Mon, 27 Jan 2003 14:34:29 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@mspacman.gpcc.itd.umich.edu To: Keith Moore Cc: Ralph Droms , Subject: Re: Solving the wrong problems In-Reply-To: <20030127142902.461fc452.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Mon, 27 Jan 2003, Keith Moore wrote: > > > IMHO, the assumption that "LL will be sufficient for its purposes" is > > a design decision by the device/stack/application implementer. > > Strongly disagree. The device/stack/application implementor has no idea > about the characteristics of the networks that the device will > connect to, and therefore has no idea whether or not the device is going > to be able to talk to the other hosts it needs to talk to using only the > local link. > > Or at least, the set of devices for which this is a reasonable > assumption is within epsilon of the null set. > The device knows who it needs to talk to but does not know what type of network it would be connected to ? I am not even sure I follow the logic. May be an example would help. Subrata From owner-zeroconf@merit.edu Mon Jan 27 14:39:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23990 for ; Mon, 27 Jan 2003 14:39:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7109E912C2; Mon, 27 Jan 2003 14:42:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 467CE912C3; Mon, 27 Jan 2003 14:42: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 2476A912C2 for ; Mon, 27 Jan 2003 14:42:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 117185DECC; Mon, 27 Jan 2003 14:42:19 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id EC65B5DD91 for ; Mon, 27 Jan 2003 14:42:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id B59C213FFB; Mon, 27 Jan 2003 14:42:18 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 31668-09; Mon, 27 Jan 2003 14:42:18 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 1D7D213FCB; Mon, 27 Jan 2003 14:42:18 -0500 (EST) Date: Mon, 27 Jan 2003 14:42:17 -0500 From: Keith Moore To: "s. goswami" Cc: moore@cs.utk.edu, rdroms@cisco.com, zeroconf@merit.edu Subject: Re: Solving the wrong problems Message-Id: <20030127144217.5fb7d51c.moore@cs.utk.edu> In-Reply-To: References: <20030127142902.461fc452.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: faf359fd459a6537277e97c15c515fe557081032 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > The device knows who it needs to talk to but does not know what > type of network it would be connected to ? I am not even sure I follow > the logic. May be an example would help. the device doesn't know either one. do you really expect me give an example of something that doesn't exist? Keith From owner-zeroconf@merit.edu Mon Jan 27 14:45:33 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24136 for ; Mon, 27 Jan 2003 14:45:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F251D91211; Mon, 27 Jan 2003 14:48:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE1FC912C3; Mon, 27 Jan 2003 14:48: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 A5BCC91211 for ; Mon, 27 Jan 2003 14:48:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8C0BB5DE7B; Mon, 27 Jan 2003 14:48:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by segue.merit.edu (Postfix) with ESMTP id 28A7A5DE69 for ; Mon, 27 Jan 2003 14:48:45 -0500 (EST) Received: from mspacman.gpcc.itd.umich.edu (mspacman.gpcc.itd.umich.edu [141.211.2.210]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id OAA20049; Mon, 27 Jan 2003 14:48:44 -0500 (EST) Received: from localhost (sgoswami@localhost) by mspacman.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id OAA27703; Mon, 27 Jan 2003 14:48:43 -0500 (EST) Date: Mon, 27 Jan 2003 14:48:43 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@mspacman.gpcc.itd.umich.edu To: Keith Moore Cc: rdroms@cisco.com, Subject: Re: Solving the wrong problems In-Reply-To: <20030127144217.5fb7d51c.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Mon, 27 Jan 2003, Keith Moore wrote: > > The device knows who it needs to talk to but does not know what > > type of network it would be connected to ? I am not even sure I follow > > the logic. May be an example would help. > > the device doesn't know either one. > > do you really expect me give an example of something that doesn't exist? > > Keith > It would be good if you can, else I am having a hard time imagining the situation. Subrata From owner-zeroconf@merit.edu Mon Jan 27 14:50:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24468 for ; Mon, 27 Jan 2003 14:50:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 484F8912C4; Mon, 27 Jan 2003 14:50:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04337912C8; Mon, 27 Jan 2003 14:50: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 A6FBA912C5 for ; Mon, 27 Jan 2003 14:50:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8EB505DE7B; Mon, 27 Jan 2003 14:50:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 523135DE69 for ; Mon, 27 Jan 2003 14:50:45 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.6) with ESMTP id h0RJoiSR005803 for ; Mon, 27 Jan 2003 11:50:44 -0800 (PST) Date: Mon, 27 Jan 2003 14:50:44 -0500 (EST) From: Ralph Droms To: zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: <20030127142902.461fc452.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Keith, So, I guess we'll agree to disagree on this point. Does the following protocol design requirement capture your argument? Because a device/stack/application cannot know the characteristics of the network that the device/stack/application will use, it is a requirement that there be a mechanism through which a network administrator can disable the use of LLv4 addresses. My requirement might read: The use of LLv4 addresses by a device/stack/application is a design decision of the implementer. It is a requirement that there be a mechanism through which a network administrator can indicate that a device/stack/application should not use LLv4 addresses. - Ralph On Mon, 27 Jan 2003, Keith Moore wrote: > > > IMHO, the assumption that "LL will be sufficient for its purposes" is > > a design decision by the device/stack/application implementer. > > Strongly disagree. The device/stack/application implementor has no idea > about the characteristics of the networks that the device will > connect to, and therefore has no idea whether or not the device is going > to be able to talk to the other hosts it needs to talk to using only the > local link. > > Or at least, the set of devices for which this is a reasonable > assumption is within epsilon of the null set. > From owner-zeroconf@merit.edu Mon Jan 27 14:56:58 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24678 for ; Mon, 27 Jan 2003 14:56:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4A59E912CD; Mon, 27 Jan 2003 14:58:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD4FB912CC; Mon, 27 Jan 2003 14:58: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 E8AB0912CA for ; Mon, 27 Jan 2003 14:57:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id D1B455DEC2; Mon, 27 Jan 2003 14:57:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id B81415DD91 for ; Mon, 27 Jan 2003 14:57:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 7ED2A13FDB; Mon, 27 Jan 2003 14:57:57 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 02011-02; Mon, 27 Jan 2003 14:57:56 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id DB95513FCB; Mon, 27 Jan 2003 14:57:56 -0500 (EST) Date: Mon, 27 Jan 2003 14:57:56 -0500 From: Keith Moore To: "s. goswami" Cc: moore@cs.utk.edu, rdroms@cisco.com, zeroconf@merit.edu Subject: Re: Solving the wrong problems Message-Id: <20030127145756.2d7fea32.moore@cs.utk.edu> In-Reply-To: References: <20030127144217.5fb7d51c.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: cfcc3f56d0c83f11e111032eef778ab340ff621d Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > > The device knows who it needs to talk to but does not know what > > > type of network it would be connected to ? I am not even sure I > > > follow the logic. May be an example would help. > > > > the device doesn't know either one. > > > > do you really expect me give an example of something that doesn't > > exist? > > It would be good if you can, else I am having a hard time imagining > the situation. okay, how about Santa Claus. or the Easter Bunny? Let me put it to you another way. You want to sell a device that performs function X to a customer, and the only way it can get an IP address is via LL. How do you whether that customer's other devices that need to talk to your product are going to be on the same network link as your device? You have no idea. You may think it's useful or desirable to impose that constraint on your product for security reasons, but that's also being naive - you have little or no idea about which threats your customer is concerned about, and no idea about the distribution of those threats relative to the network link your customer is going to use with your device. Keith From owner-zeroconf@merit.edu Mon Jan 27 15:06:17 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25005 for ; Mon, 27 Jan 2003 15:06:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B8C48912D9; Mon, 27 Jan 2003 15:07:50 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 34FB4912D8; Mon, 27 Jan 2003 15:04: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 484B9912DF for ; Mon, 27 Jan 2003 15:04:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F9165DDD9; Mon, 27 Jan 2003 15:04:45 -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 00D875DD91 for ; Mon, 27 Jan 2003 15:04:44 -0500 (EST) Received: from aldebaran (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 8F616598CA for ; Mon, 27 Jan 2003 20:04:48 +0000 (GMT) Message-ID: <070301c2c63f$559dcf00$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <20030127113733.67152718.moore@cs.utk.edu> <20030127142902.461fc452.moore@cs.utk.edu> Subject: Re: Solving the wrong problems Date: Mon, 27 Jan 2003 20:04:43 -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 > > IMHO, the assumption that "LL will be sufficient for its purposes" is > > a design decision by the device/stack/application implementer. > > Strongly disagree. The device/stack/application implementor has no idea > about the characteristics of the networks that the device will > connect to, and therefore has no idea whether or not the device is going > to be able to talk to the other hosts it needs to talk to using only the > local link. I see this purely as a commercial decision. It is clear that the uses of a LL only device will be severely limited. However there may well be applications where those limitations may well be recognised and accepted. Stop thinking of "computers" and think of the IP/Ethernet equivalent of a USB or CAN or GPIB "network" but with some advantages of range and bandwidth scalability. USB doesn't sweat about routability it lives with its restrictions - so could an LL only device. The user probably wouldn't even know that IP was being used. I see this as separate from the issue of whether a network administrator wants to keep such devices off a more general purpose network - for which DHCP option is one way to go. Philip From owner-zeroconf@merit.edu Mon Jan 27 15:09:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25132 for ; Mon, 27 Jan 2003 15:09:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 97DBB912F2; Mon, 27 Jan 2003 15:12:04 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A08DF912F8; Mon, 27 Jan 2003 15:12: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 1A06E912F2 for ; Mon, 27 Jan 2003 15:11:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 06D555DD91; Mon, 27 Jan 2003 15:11:53 -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 6F1375DD8D for ; Mon, 27 Jan 2003 15:11:52 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0RK6cP21327; Mon, 27 Jan 2003 14:06:38 -0600 (CST) Date: Mon, 27 Jan 2003 14:11:49 -0600 Subject: Re: Solving the wrong problems Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu, Daniel Senie To: Robert Elz From: Ted Lemon In-Reply-To: <12424.1043642325@munnari.OZ.AU> Message-Id: <91ABD64A-3233-11D7-9EAD-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > That isn't what current IPv4LL implementations do (note: "bogus" here > is immaterial, the host can't tell what is bogus and what isn't), and > isn't the position that this WG seems to be converging upon. The current draft says that if you are IPv4ll aware, you can interoperate with IPv4ll clients on the local link even if you don't have an IPv4ll address yourself. I agree that the draft needs to be reworded a bit, though - it should state this as the correct behavior, rather than making it optional. > The issue being debated has been about whether there can be/should be > a mechanism to disable LL even in cases where the DHCP server doesn't > want to give out an address (which is why 2563 is relevant of course). The issue some people were debating is whether or not there should be a mechanism for disabling IPv4ll. The mechanism that is actually proposed in the draft, and that most people seem to agree is correct, is that if you get a routable address, you don't need to keep your IPv4ll address. This is _not_ the same thing as disabling IPv4ll. > So, once again, what is this problem that 2563 causes and doesn't > already exist? I think you're being deliberately obtuse here, Robert - you're not a dummy, and I have explained this twice already. If you genuinely do not understand what the problem is, please contact me offline and I'll try to explain it to you. If you don't agree that it's a problem, that's okay, but please specifically say that you don't agree that it's a problem, rather than using rhetorical tricks like this, so that we can just agree to disagree and stop wasting everybody's time. From owner-zeroconf@merit.edu Mon Jan 27 15:20:21 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25338 for ; Mon, 27 Jan 2003 15:20:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 60D95912EF; Mon, 27 Jan 2003 15:20:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95A7E912CB; Mon, 27 Jan 2003 15:12: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 E4A7F912CF for ; Mon, 27 Jan 2003 15:12:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id D2C345DE3C; Mon, 27 Jan 2003 15:12:45 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id AD84B5DD8D for ; Mon, 27 Jan 2003 15:12:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 60DD413FFB; Mon, 27 Jan 2003 15:12:45 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 03941-06; Mon, 27 Jan 2003 15:12:44 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 1090813FDF; Mon, 27 Jan 2003 15:12:44 -0500 (EST) Date: Mon, 27 Jan 2003 15:12:43 -0500 From: Keith Moore To: Ralph Droms Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Solving the wrong problems Message-Id: <20030127151243.505403ab.moore@cs.utk.edu> In-Reply-To: References: <20030127142902.461fc452.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: d5c4f8f17c25da7bc3f88c4d06ca66a45333ec22 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > So, I guess we'll agree to disagree on this point. Does the following > protocol design requirement capture your argument? > > Because a device/stack/application cannot know the characteristics > of the network that the device/stack/application will use, it is a > requirement that there be a mechanism through which a network > administrator can disable the use of LLv4 addresses. It's also a requirement that the device be able to use DHCP addresses. The underlying requirement is that the device be able to interoperate with the address allocation mechanisms (i.e. DHCP) in existing IP networks, when they exist. Being able to function on ad hoc IP networks that use v4LL is fine, as long as the device uses the DHCP-assigned address on networks that use DHCP. > My requirement might read: > > The use of LLv4 addresses by a device/stack/application is a design > decision of the implementer. It is a requirement that there be a > mechanism through which a network administrator can indicate that a > device/stack/application should not use LLv4 addresses. I don't think this is a useful way to state it. *Of course* LLv4 support is optional for the implementor. We've had ~23 years of IPv4 deployment and have done fine without LLv4 support for most of this time. We're not going to start telling vendors that they have to implement LLv4 in order to comply with the internet protocol. But don't expect IETF to write a standard that says that LL-only devices are okay. We know there are problems with such devices, we know that a specification that allowed such devices would not meet 2026 requirements for standards track. We also know that IETF can't stop vendors from shipping such devices if they wish. (and sadly, IETF isn't likely to sue vendors who mislead their customers about how well these devices conform to the standards) So let's not waste our time trying to get IETF to lie, okay? Keith From owner-zeroconf@merit.edu Mon Jan 27 15:23:42 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25459 for ; Mon, 27 Jan 2003 15:23:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 220189130D; Mon, 27 Jan 2003 15:21:42 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2E1D91320; Mon, 27 Jan 2003 15:21: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 7F07B912D2 for ; Mon, 27 Jan 2003 15:17:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6CA055DE9F; Mon, 27 Jan 2003 15:17:10 -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 1D0905DDD9 for ; Mon, 27 Jan 2003 15:17:10 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0RK9NP21382; Mon, 27 Jan 2003 14:09:23 -0600 (CST) Date: Mon, 27 Jan 2003 14:14:35 -0600 Subject: Re: Solving the wrong problems Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "'Robert Elz'" , To: "Subrata Goswami" From: Ted Lemon In-Reply-To: <00bc01c2c5c6$e13cf460$c900a8c0@SGOSWAMIPCL> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > "The host MUST NOT send the packet to any router for forwarding" > > To > > "The host MAY send the packet to a router for forwarding" > > The router should be responsible for making the decision to > forward/not-forward the 169.254/16 packets. If the router can > NAT a 169.254/16 then it MAY forward the 169.254 packet, if the > router can not NAT the 169.254 packets it MUST not forward the > 169.254 packet. IPv4ll doesn't provide a way to discover routers. So it has to be the router's responsibility to block or NAT ipv4ll addresses, because the IPv4ll node doesn't have enough information to do it. From owner-zeroconf@merit.edu Mon Jan 27 15:23:49 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25473 for ; Mon, 27 Jan 2003 15:23:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F1A0B912D0; Mon, 27 Jan 2003 15:21:53 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4EA4F9130B; Mon, 27 Jan 2003 15:21: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 5890091300 for ; Mon, 27 Jan 2003 15:17:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 45D635DDD9; Mon, 27 Jan 2003 15:17:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 857875DEC2 for ; Mon, 27 Jan 2003 15:17:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 3D7E813FF2; Mon, 27 Jan 2003 15:17:57 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 04683-06; Mon, 27 Jan 2003 15:17:56 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id A16D213FDB; Mon, 27 Jan 2003 15:17:56 -0500 (EST) Date: Mon, 27 Jan 2003 15:17:56 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Solving the wrong problems Message-Id: <20030127151756.6186e8a5.moore@cs.utk.edu> In-Reply-To: <070301c2c63f$559dcf00$131010ac@aldebaran> References: <20030127113733.67152718.moore@cs.utk.edu> <20030127142902.461fc452.moore@cs.utk.edu> <070301c2c63f$559dcf00$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 199182b26ecaad13b5acc3558eb47ff05b7e4d0b Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Stop thinking of "computers" and think of the IP/Ethernet equivalent > of a USB or CAN or GPIB "network" but with some advantages of range > and bandwidth scalability. Indeed, this is what I'm thinking about. This reminds me of the original arguments surrouding SCSI-over-IP. The original idea was that you didn't need security because even though these were IP devices they wouldn't be accessed from distant nodes. I note in reading the latest iSCSI draft that this has now been turned completely around. It turns out to be useful to be able to access SCSI devices from very distant nodes. From owner-zeroconf@merit.edu Mon Jan 27 16:20:55 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27220 for ; Mon, 27 Jan 2003 16:20:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D8A98912E3; Mon, 27 Jan 2003 16:21:34 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 774A791320; Mon, 27 Jan 2003 16:18: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 952029131E for ; Mon, 27 Jan 2003 16:17:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7CE4F5DF08; Mon, 27 Jan 2003 16:17:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 553975DEC2 for ; Mon, 27 Jan 2003 16:17:47 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 1ECCC13FF2; Mon, 27 Jan 2003 16:17:47 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 13226-06; Mon, 27 Jan 2003 16:17:46 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 7799E13FC4; Mon, 27 Jan 2003 16:17:46 -0500 (EST) Date: Mon, 27 Jan 2003 16:17:46 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, sgoswami@umich.edu, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: Solving the wrong problems Message-Id: <20030127161746.5355e6a2.moore@cs.utk.edu> In-Reply-To: References: <00bc01c2c5c6$e13cf460$c900a8c0@SGOSWAMIPCL> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 45bc0c6b4fd5556c9c5c0d40415db2200608b9c4 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > IPv4ll doesn't provide a way to discover routers. no, but DHCP does, and all IPv4LL-capable devices need to understand enough of DHCP to know whether they should use a v4LL address or a routable address. IMHO they should also be able to discover a netmask and a default route. v4LL should be for ad hoc networks only. Keith From owner-zeroconf@merit.edu Mon Jan 27 16:36:18 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27708 for ; Mon, 27 Jan 2003 16:36:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1820C9133A; Mon, 27 Jan 2003 16:38:08 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B70289132A; Mon, 27 Jan 2003 16:38: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 21B999133A for ; Mon, 27 Jan 2003 16:36:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0AF675DF21; Mon, 27 Jan 2003 16:36:48 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by segue.merit.edu (Postfix) with ESMTP id A14185DF08 for ; Mon, 27 Jan 2003 16:36:47 -0500 (EST) Received: from mspacman.gpcc.itd.umich.edu (mspacman.gpcc.itd.umich.edu [141.211.2.210]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id QAA21389; Mon, 27 Jan 2003 16:36:47 -0500 (EST) Received: from localhost (sgoswami@localhost) by mspacman.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id QAA13222; Mon, 27 Jan 2003 16:36:46 -0500 (EST) Date: Mon, 27 Jan 2003 16:36:46 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@mspacman.gpcc.itd.umich.edu To: Keith Moore Cc: rdroms@cisco.com, Subject: Re: Solving the wrong problems In-Reply-To: <20030127145756.2d7fea32.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Mon, 27 Jan 2003, Keith Moore wrote: > > > > The device knows who it needs to talk to but does not know what > > > > type of network it would be connected to ? I am not even sure I > > > > follow the logic. May be an example would help. > > > > > > the device doesn't know either one. > > > > > > do you really expect me give an example of something that doesn't > > > exist? > > > > It would be good if you can, else I am having a hard time imagining > > the situation. > > okay, how about Santa Claus. or the Easter Bunny? > > Let me put it to you another way. You want to sell a device that > performs function X to a customer, and the only way it can get an IP > address is via LL. How do you whether that customer's other devices > that need to talk to your product are going to be on the same network > link as your device? You have no idea. You may think it's useful or > desirable to impose that constraint on your product for security > reasons, but that's also being naive - you have little or no idea about > which threats your customer is concerned about, and no idea about the > distribution of those threats relative to the network link your customer > is going to use with your device. > Sorry I still do not see your point, and example seems pretty vague. If you want your device to talk to the gloabl Internet then use DHCP/PPP/BOOTP/manual. But my devices do not give a hoot about the global Internet and they form dynamic networks, why sould I be burdened to support DHCP which I am not going to use ? Subrata > Keith > From owner-zeroconf@merit.edu Mon Jan 27 16:43:09 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28043 for ; Mon, 27 Jan 2003 16:43:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 09CC19120F; Mon, 27 Jan 2003 16:45:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB7DD912CA; Mon, 27 Jan 2003 16:45: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 94EF59120F for ; Mon, 27 Jan 2003 16:45:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 043545DE8B; Mon, 27 Jan 2003 16:45:36 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from berzerk.gpcc.itd.umich.edu (berzerk.gpcc.itd.umich.edu [141.211.2.162]) by segue.merit.edu (Postfix) with ESMTP id 8442D5DD99 for ; Mon, 27 Jan 2003 16:45:35 -0500 (EST) Received: from mspacman.gpcc.itd.umich.edu (mspacman.gpcc.itd.umich.edu [141.211.2.210]) by berzerk.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id QAA22222; Mon, 27 Jan 2003 16:45:35 -0500 (EST) Received: from localhost (sgoswami@localhost) by mspacman.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id QAA19265; Mon, 27 Jan 2003 16:45:34 -0500 (EST) Date: Mon, 27 Jan 2003 16:45:34 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@mspacman.gpcc.itd.umich.edu To: Keith Moore Cc: Ralph Droms , Subject: Re: Solving the wrong problems In-Reply-To: <20030127151243.505403ab.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk see inline On Mon, 27 Jan 2003, Keith Moore wrote: > > > So, I guess we'll agree to disagree on this point. Does the following > > protocol design requirement capture your argument? > > > > Because a device/stack/application cannot know the characteristics > > of the network that the device/stack/application will use, it is a > > requirement that there be a mechanism through which a network > > administrator can disable the use of LLv4 addresses. > > It's also a requirement that the device be able to use DHCP addresses. > I do not agree with this. > The underlying requirement is that the device be able to interoperate > with the address allocation mechanisms (i.e. DHCP) in existing IP > networks, when they exist. Being able to function on ad hoc IP networks > that use v4LL is fine, as long as the device uses the DHCP-assigned > address on networks that use DHCP. > > > My requirement might read: > > > > The use of LLv4 addresses by a device/stack/application is a design > > decision of the implementer. It is a requirement that there be a > > mechanism through which a network administrator can indicate that a > > device/stack/application should not use LLv4 addresses. > I my view the above should read "It may be that there could be a mechanism through which a network adim ..." > I don't think this is a useful way to state it. > > *Of course* LLv4 support is optional for the implementor. We've had ~23 > years of IPv4 deployment and have done fine without LLv4 support for > most of this time. We're not going to start telling vendors that they > have to implement LLv4 in order to comply with the internet protocol. > Well 23 years is a long time and lot of things have changed. If you have forgotten 23 years ago there were no Interent per se, no PC, no cell phone, no PDA, no email, .... Times have changed and IP should evolve too. > But don't expect IETF to write a standard that says that LL-only devices > are okay. We know there are problems with such devices, we know that a > specification that allowed such devices would not meet 2026 requirements > for standards track. We also know that IETF can't stop vendors from > shipping such devices if they wish. (and sadly, IETF isn't likely to > sue vendors who mislead their customers about how well these devices > conform to the standards) > > So let's not waste our time trying to get IETF to lie, okay? IETF has lot of standards which are not exactly popular. > > Keith > > From owner-zeroconf@merit.edu Mon Jan 27 16:51:02 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28267 for ; Mon, 27 Jan 2003 16:51:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 25D1B912CA; Mon, 27 Jan 2003 16:54:21 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E7494912CC; Mon, 27 Jan 2003 16:54: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 DFA75912CA for ; Mon, 27 Jan 2003 16:54:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id CC30A5DED3; Mon, 27 Jan 2003 16:54:19 -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 3D3B05DEC5 for ; Mon, 27 Jan 2003 16:54:19 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0RLn3P22389 for ; Mon, 27 Jan 2003 15:49:05 -0600 (CST) Date: Mon, 27 Jan 2003 15:54:16 -0600 Subject: Re: Solving the wrong problems Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) From: Ted Lemon To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20030127161746.5355e6a2.moore@cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > all IPv4LL-capable devices need to understand > enough of DHCP to know whether they should use a v4LL address or a > routable address. The draft doesn't say this. Further, it's irrelevant, because the DHCP server may not provide a complete list of routers - indeed, there may not *be* a DHCP server. Look, take this as an exercise: write up a draft that completely describes how an IPv4ll client would avoid sending packets through a router. If you can describe an algorithm without any obvious gaping holes, and you really think it's implementable, propose it here. The reason I make this statement is that I just now tried, and wasn't able to do it. E.g., let's say you did a DHCPINFORM and got information about the local routers. Now what? You want to send a packet to 198.45.127.2. You're IPv4ll, so you can't do routing, so you ARP for it. If you don't get an answer, you don't send the packet, so that's not a problem. But what if the router is doing proxy ARPs? Then you get an ARP reply from the router, and you have to compare that to the entry in your ARP table for the IP address of the router, and not send it in that case. But you don't *have* an entry in your routing table, because you're not doing routing, because you're IPv4ll and don't have enough information to do routing. Confused yet? Now, what about routers that are doing proxy ARP but aren't mentioned in the DHCP packet? What about when there is no DHCP packet? I think what the authors intended here was just to say that if you only have an IPv4ll address, you shouldn't try to do IP routing - that is, you shouldn't notice that something's off-subnet somehow and try to send it to a router. You should just ARP for it. And the draft should say this, but perhaps in a way that doesn't lead to a thought process like the one I described above. :'} From owner-zeroconf@merit.edu Mon Jan 27 17:45:48 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29708 for ; Mon, 27 Jan 2003 17:45:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DDCD591221; Mon, 27 Jan 2003 17:49:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1336912CC; Mon, 27 Jan 2003 17: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 8EEAA91221 for ; Mon, 27 Jan 2003 17:49:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6B9C35DE2F; Mon, 27 Jan 2003 17:49:00 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from smtp.covadmail.net (mx03.covadmail.net [63.65.120.63]) by segue.merit.edu (Postfix) with SMTP id 02BEC5DE28 for ; Mon, 27 Jan 2003 17:49:00 -0500 (EST) Received: (covad.net 8995 invoked from network); 27 Jan 2003 22:48:59 -0000 Received: from unknown (HELO STUDY) (66.167.13.36) by sun-qmail13 with SMTP; 27 Jan 2003 22:48:59 -0000 To: Ted Lemon Cc: zeroconf@merit.edu Subject: Re: Solving the wrong problems References: From: Scott Lawrence Date: 27 Jan 2003 17:48:55 -0500 In-Reply-To: Message-ID: Lines: 11 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-zeroconf@merit.edu Precedence: bulk Ted Lemon writes: > You want to send a packet to 198.45.127.2. You're IPv4ll, so you > can't do routing, so you ARP for it. If you don't get an answer, you > don't send the packet, so that's not a problem. But what if the router is > doing proxy ARPs? Then either the router is broken for answering, or will be broken if it does anything other than drop the packet - it can't route it. Either way it isn't the devices problem. From owner-zeroconf@merit.edu Mon Jan 27 23:02:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05172 for ; Mon, 27 Jan 2003 23:02:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5ED35912DC; Mon, 27 Jan 2003 23:06:01 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27DF8912E2; Mon, 27 Jan 2003 23:06: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 EDC62912DC for ; Mon, 27 Jan 2003 23:05:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id D3F7B5DDB7; Mon, 27 Jan 2003 23:05:59 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by segue.merit.edu (Postfix) with ESMTP id B2F8E5DD99 for ; Mon, 27 Jan 2003 23:05:59 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18dN0V-00079V-00; Mon, 27 Jan 2003 20:05:55 -0800 Date: Mon, 27 Jan 2003 23:04:21 -0500 From: Keith Moore To: "s. goswami" Cc: moore@cs.utk.edu, rdroms@cisco.com, zeroconf@merit.edu Subject: Re: Solving the wrong problems Message-Id: <20030127230421.7708e481.moore@cs.utk.edu> In-Reply-To: References: <20030127145756.2d7fea32.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Sorry I still do not see your point, and example seems pretty vague. > If you want your device to talk to the gloabl Internet then use > DHCP/PPP/BOOTP/manual. But my devices do not give a hoot about > the global Internet and they form dynamic networks, why sould I be > burdened to support DHCP which I am not going to use ? there's a big gap between the global Internet and a single link. and you don't know which of your devices will need to operate beyond the local link and which ones won't. Keith From owner-zeroconf@merit.edu Mon Jan 27 23:06:34 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05193 for ; Mon, 27 Jan 2003 23:06:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B2258912E5; Mon, 27 Jan 2003 23:08:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67116912EC; Mon, 27 Jan 2003 23:08: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 69869912E5 for ; Mon, 27 Jan 2003 23:08:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4EF3D5DE70; Mon, 27 Jan 2003 23:08:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from mallard.mail.pas.earthlink.net (mallard.mail.pas.earthlink.net [207.217.120.48]) by segue.merit.edu (Postfix) with ESMTP id 2E4A15DE50 for ; Mon, 27 Jan 2003 23:08:42 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18dN34-00057y-00; Mon, 27 Jan 2003 20:08:34 -0800 Date: Mon, 27 Jan 2003 23:07:00 -0500 From: Keith Moore To: "s. goswami" Cc: moore@cs.utk.edu, rdroms@cisco.com, zeroconf@merit.edu Subject: Re: Solving the wrong problems Message-Id: <20030127230700.55c1510f.moore@cs.utk.edu> In-Reply-To: References: <20030127151243.505403ab.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Well 23 years is a long time and lot of things have changed. If you > have forgotten 23 years ago there were no Interent per se, no PC, > no cell phone, no PDA, no email, .... Times have changed and IP should > evolve too. go read RFC 2026 and its requirements for proposed standard status. and stop insisting that this WG "evolve" IP in a way which not only violates 2026 but is far beyond this group's charter. Keith From owner-zeroconf@merit.edu Mon Jan 27 23:25:19 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05357 for ; Mon, 27 Jan 2003 23:25:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF670912E6; Mon, 27 Jan 2003 23:28:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8CBA4912E9; Mon, 27 Jan 2003 23:28: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 46292912E6 for ; Mon, 27 Jan 2003 23:28:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2CB1B5DE50; Mon, 27 Jan 2003 23:28:40 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by segue.merit.edu (Postfix) with ESMTP id 0C63B5DD99 for ; Mon, 27 Jan 2003 23:28:40 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18dNMU-0006H8-00; Mon, 27 Jan 2003 20:28:38 -0800 Date: Mon, 27 Jan 2003 23:27:04 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Solving the wrong problems Message-Id: <20030127232704.33229228.moore@cs.utk.edu> In-Reply-To: References: <20030127161746.5355e6a2.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 Mon, 27 Jan 2003 15:54:16 -0600 Ted Lemon wrote: > > all IPv4LL-capable devices need to understand > > enough of DHCP to know whether they should use a v4LL address or a > > routable address. > > The draft doesn't say this. the draft is subject to change. and it needs to change. Keith From owner-zeroconf@merit.edu Tue Jan 28 01:43:15 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07652 for ; Tue, 28 Jan 2003 01:43:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3C853912EA; Tue, 28 Jan 2003 01:46:36 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02204912EC; Tue, 28 Jan 2003 01:46: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 C5DDF912EA for ; Tue, 28 Jan 2003 01:46:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id C39B45DF29; Tue, 28 Jan 2003 01:46:28 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id 7D8465DD9E for ; Tue, 28 Jan 2003 01:46:28 -0500 (EST) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id BAA20702; Tue, 28 Jan 2003 01:46:21 -0500 (EST) From: "Subrata Goswami" To: "'Keith Moore'" Cc: , Subject: RE: Solving the wrong problems Date: Mon, 27 Jan 2003 22:40:33 -0800 Message-ID: <003501c2c698$29517c90$c900a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <20030127230421.7708e481.moore@cs.utk.edu> x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yes I do know which device needs global, which needs LL, and which needs both. > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Monday, January 27, 2003 8:04 PM > To: s. goswami > Cc: moore@cs.utk.edu; rdroms@cisco.com; zeroconf@merit.edu > Subject: Re: Solving the wrong problems > > > > Sorry I still do not see your point, and example seems > pretty vague. > > If you want your device to talk to the gloabl Internet then use > > DHCP/PPP/BOOTP/manual. But my devices do not give a hoot about the > > global Internet and they form dynamic networks, why sould I be > > burdened to support DHCP which I am not going to use ? > > there's a big gap between the global Internet and a single > link. and you don't know which of your devices will need to > operate beyond the local link and which ones won't. > > Keith > From owner-zeroconf@merit.edu Tue Jan 28 02:27:56 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18050 for ; Tue, 28 Jan 2003 02:27:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA574912ED; Tue, 28 Jan 2003 02:30:37 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ADBB6912F1; Tue, 28 Jan 2003 02:30: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 5AC95912ED for ; Tue, 28 Jan 2003 02:30:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id DD8F85DED4; Tue, 28 Jan 2003 02:30:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id D6E395DDA1 for ; Tue, 28 Jan 2003 02:30:18 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0S7TOR18263; Tue, 28 Jan 2003 14:29:25 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0S7RNV01534; Tue, 28 Jan 2003 14:27:26 +0700 (ICT) From: Robert Elz To: Ted Lemon Cc: zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: <91ABD64A-3233-11D7-9EAD-00039367340A@nominum.com> References: <91ABD64A-3233-11D7-9EAD-00039367340A@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Jan 2003 14:27:23 +0700 Message-ID: <1532.1043738843@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 27 Jan 2003 14:11:49 -0600 From: Ted Lemon Message-ID: <91ABD64A-3233-11D7-9EAD-00039367340A@nominum.com> | The current draft says that if you are IPv4ll aware, you can | interoperate with IPv4ll clients on the local link even if you don't | have an IPv4ll address yourself. That's fine. | I agree that the draft needs to be | reworded a bit, though - it should state this as the correct behavior, | rather than making it optional. Yes, there are several places where extra clarity would help. | The issue some people were debating is whether or not there should be a | mechanism for disabling IPv4ll. The mechanism that is actually | proposed in the draft, and that most people seem to agree is correct, | is that if you get a routable address, you don't need to keep your | IPv4ll address. This is _not_ the same thing as disabling IPv4ll. It _is_ the same thing as I have been arguing for however. As has been explained on this list before, when we say "disable IPv4LL" what we (most of us anyway) mean is "disable the algorithm by which a node acquires an IPv4 LL address". "Disable IPv4LL" is just a shorter way of saying that. There has been some suggestion that nodes should also have a way to disable communications with other nodes using LL addresses. I agree with that - but in the same context as nodes should have a way to disable communication with any other random set of nodes, I don't see anything so special about LL that it needs special treatment. This one is also one I'd be hesitant about requiring anywhere, as it is clearly one where the maker of the node is likely to know what its requirements are likely to be, and because disabling communications can't possibly be aiding interoperability. With this clarification, do you still have the same problems? | I think you're being deliberately obtuse here, Robert - you're not a | dummy, and I have explained this twice already. No, you attempted to explain twice. I responded twice showing why your explanation was incorrect. I know it is tempting to assume that if any random node can send a packet which causes another node to shut down (or fail to operate in some way) that that *must* be enabling a DoS attack. But that isn't true, it only *enabled* a DoS attack if there isn't already a way to accomplish the same thing (or perhaps if the other way is much harder to execute). While 2563 can certainly be used as a mechanism to carry out a DoS attack, it does not enable one - it adds absolutely nothing that doesn't exist already - more than that, it is a method much easier to defeat than what already exists. | If you genuinely do | not understand what the problem is, please contact me offline and I'll | try to explain it to you. Please explain it to everyone. | If you don't agree that it's a problem, | that's okay, but please specifically say that you don't agree that it's | a problem, I have said that several times. It isn't a problem. Or not unless you can show something that I am currently not seeing (and which no-one else here seems to be seeing either, or I expect that someone else would have sent a message re-wording yours, to make the point clearer). | rather than using rhetorical tricks like this, so that we | can just agree to disagree and stop wasting everybody's time. I didn't use rhetorical tricks, or I don't think I did. I just asked you to explain the problem that is new from 2563 - what is it that 2563 allows that can't already be done (and I think, better, from a DoS attackers point of view). And just disagreeing isn't where this should stop - if there are security problems, they need to be made abundantly clear, so we can make sure to avoid them as best as is possible. But they also need to be subjected to critical appraisal, so we can be sure that we're not just dodging shadows. kre From owner-zeroconf@merit.edu Tue Jan 28 02:45:08 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18422 for ; Tue, 28 Jan 2003 02:45:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 135CE912F1; Tue, 28 Jan 2003 02:48:24 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2D57912F3; Tue, 28 Jan 2003 02:48: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 C1454912F1 for ; Tue, 28 Jan 2003 02:48:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 98EF55DF4F; Tue, 28 Jan 2003 02:48:22 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by segue.merit.edu (Postfix) with ESMTP id 4AF0E5DED4 for ; Tue, 28 Jan 2003 02:48:22 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0S7h3P28621; Tue, 28 Jan 2003 01:43:03 -0600 (CST) Date: Tue, 28 Jan 2003 01:48:19 -0600 Subject: Re: Solving the wrong problems Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: zeroconf@merit.edu To: Robert Elz From: Ted Lemon In-Reply-To: <1532.1043738843@munnari.OZ.AU> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > It _is_ the same thing as I have been arguing for however. As has > been > explained on this list before, when we say "disable IPv4LL" what we > (most > of us anyway) mean is "disable the algorithm by which a node acquires > an > IPv4 LL address". "Disable IPv4LL" is just a shorter way of saying > that. "Disable IPv4LL" means, to me, disable all the behaviors documented in the IPv4ll draft. Not only do you not acquire an IPv4ll address, but you don't communicate with devices that have IPv4ll addresses. If you mean to disable acquisition of IPv4ll addresses, it's best to say that that is what you mean. > No, you attempted to explain twice. I responded twice showing why your > explanation was incorrect. If you had shown why my explanation was incorrect, I would have understood you. What you did was to state that my explanation was incorrect, and give reasons that as far as I can tell do not show that it is incorrect. I seem to be doing the same to you, so perhaps you can at least understand my confusion. > I didn't use rhetorical tricks, or I don't think I did. I just asked > you > to explain the problem that is new from 2563 - what is it that 2563 > allows > that can't already be done (and I think, better, from a DoS attackers > point > of view). Why don't you describe the DoS attack that you think is equivalent to the DoS attack that RFC2563 enables? From owner-zeroconf@merit.edu Tue Jan 28 04:59:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20117 for ; Tue, 28 Jan 2003 04:59:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A796D91214; Tue, 28 Jan 2003 05:03:13 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 731BB912D7; Tue, 28 Jan 2003 05:03: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 7D9E391214 for ; Tue, 28 Jan 2003 05:02:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 618F95DDC5; Tue, 28 Jan 2003 05:02:45 -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 335F55DD8E for ; Tue, 28 Jan 2003 05:02:45 -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 68CA259959 for ; Tue, 28 Jan 2003 10:02:46 +0000 (GMT) Message-ID: <001801c2c6b4$66efa6f0$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <91ABD64A-3233-11D7-9EAD-00039367340A@nominum.com> <1532.1043738843@munnari.OZ.AU> Subject: Disabling LL on the link Date: Tue, 28 Jan 2003 10:02:43 -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: "Robert Elz" > > | The issue some people were debating is whether or not there should be a > | mechanism for disabling IPv4ll. The mechanism that is actually > | proposed in the draft, and that most people seem to agree is correct, > | is that if you get a routable address, you don't need to keep your > | IPv4ll address. This is _not_ the same thing as disabling IPv4ll. > > It _is_ the same thing as I have been arguing for however. As has been > explained on this list before, when we say "disable IPv4LL" what we (most > of us anyway) mean is "disable the algorithm by which a node acquires an > IPv4 LL address". "Disable IPv4LL" is just a shorter way of saying that. There are actually three definitions of "Disable LL" flying around which are causing confusion. 1. Disabling IPv4LL *on a link" must mean to to prevent any traffic on that link using LL addresses (source or destination). Disabling IPv4LL *in a host* whether manually or by remote means (e.g. DHCP) could mean two things: 2. Simply to prevent that host acquiring a LL address. 3. To prevent that host acquiring a LL address and also to prevent it from communicating with other LL hosts. It is clear that disabling LL *on a link* requires much tougher measures than either of the others - and 2 and 3 are both possible steps towards achieving 1. I think that if we could reach consensus on 1 then the others could be discussed more clearly. This is the question: Should a mechanism be mandated or recommended whereby all LL communication *on a link* can be stopped - even if this means that some hosts can then not communicate on that link at all? Philip From owner-zeroconf@merit.edu Tue Jan 28 05:32:00 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20428 for ; Tue, 28 Jan 2003 05:31:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7BE18912D7; Tue, 28 Jan 2003 05:35:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F538912F3; Tue, 28 Jan 2003 05:35: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 459F8912D7 for ; Tue, 28 Jan 2003 05:35:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2E1105DE48; Tue, 28 Jan 2003 05:35:19 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id A8C145DF69 for ; Tue, 28 Jan 2003 05:35:17 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0SAYGR06966; Tue, 28 Jan 2003 17:34:21 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0SATOV02324; Tue, 28 Jan 2003 17:29:30 +0700 (ICT) From: Robert Elz To: Ted Lemon Cc: zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Jan 2003 17:29:24 +0700 Message-ID: <2322.1043749764@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 28 Jan 2003 01:48:19 -0600 From: Ted Lemon Message-ID: | "Disable IPv4LL" means, to me, disable all the behaviors documented in | the IPv4ll draft. This confusion has existed before, I believe. So, yes, it would be better to be more precise. I will try in future. | If you had shown why my explanation was incorrect, I would have | understood you. I thought I did that. You didn't ever say why you thought my analysis was wrong, or question any of it, or even ask for an explanation. You just repeated your claim, so I just repeated myself as well... | What you did was to state that my explanation was | incorrect, and give reasons that as far as I can tell do not show that | it is incorrect. What about my reasons was lacking? You questioned none of them. | Why don't you describe the DoS attack that you think is equivalent to | the DoS attack that RFC2563 enables? OK. We both assume that somehow a "rogue" DHCP server can answer someone's DHCPDISCOVER. Since we're both assuming that, how it gets done is immaterial (that is, how the rogue server finds the correct transaction ID and knows when is the right time to send its bogus reply - this is obviously trivial if the server is on the same link as the client, and relatively harder if it is elsewhere). Your rogue server (using 2563) sends yiaddr=0.0.0.0 opt 116=0, which will cause the client to fail to configure an IP address, and not configure a LL address either. That's the apparent problem, right? My rogue server (not using 2563) sends yiaddr=10.11.12.13 and probably subnet mask = 255.255.255.240 default gateway=10.11.12.1 (or something). The host configures the address given (which no-one else knows, being essentially a random number) and no LL address (as DHCP has delivered it another address to use). At this point it cannot communicate over the net with anyone, as anyone else attempting to reach 10.11.12.13 will send packets to the local router (which will either drop them or forward them away). The node in question will ARP for 10.11.12.1, which does not exist on the local link, before sending packets to any address it wants to locate, either not get an answer, or (perhaps) get a proxy-arp reply from the router, which will then sends its packets to oblivion or nowhwere. (One may assume that the rogue DHCP server knows what addresses will not work, and assigns those to the node). In both cases, the node is essentially isolated from the network. Now let's look at the differences between the two cases. In the 2563 case, if the real DHCP server, assuming there is one, sends a reply as well, any rational client would use that reply instead of the one from your rogue server - it is easy to tell the two of them apart. On the other hand, in the "can already do it without 2563" case, if there's a real DHCP server, sending a good address, at best it will be up to chance as to which reply the client chooses - perhaps the first to arrive. If it helps its case here, the rogue server can send dozens of (different) bogus replies, appearing to all have come from different DHCP servers. What's more, as it isn't having to do any real lease allocation, it can most likely reply more quickly (or more slowly if it prefers, or both) than the genuine server. So, here, the 2563 case is less effective than what exists already, right? Next, in the 2563 case, since the node has been given no lease, it has no lease time either, and it is free to try again, to obtain a lease (or to be permitted to config a LL address) reasonably soon - the node may wait a few minutes, on the assumption that conditions are unlikely to have changed more rapidly than that, but waiting more than 10 mins or so would seem pointless. On the other hand, in the "no 2563 case" the node believes it has a valid lease, which may have been sent with the timers indicating that the first renewal attempts should start in a year from now (with the lease valid for 2 years or more). Since it has no reason at all to believe its lease to be invalid, it has no reason to do anything more with DHCP for a year, so it won't recover anytime soon. Third, in the 2563 case, the node knows it has been denied network access, so it can use whatever non-network mechanisms it might have to make this clear to anyone who might be investigating why it isn't functioning. In the non-2563 case, the node believes it is configured and functioning perfectly (though not getting responses from anyone - which is actually a normal operating state for many devices), and so would be indicating via whatever means it has "all is OK". The only difference that weighs against the 2563 case that I can see, is that in the non 2563 case, the device's network stack still believes it is working, so if you can somehow guess what address it was allocated, you could configure some other device on the same LAN to be able to communicate with it (how you figure out which of the ~ 2^32 possible IP addresses it was given, especially for a relatively passive device, I have no idea though - and if it happened to be given 127.1.2.3 and had a DHCP client that didn't recognise that such things are bogus (which is likely) and a network stack that does know that 127.0.0.0/8 packets are not to be sent off the local node (also likely) then it would be completely off the net, even if you could guess its address. Even without the latter part, the fact that you can't mount a 2563 attack unless you can silence a genuine DHCP server (because nodes would simply take the offer which says "here's an address" over one which says "no address for you") makes it such an unlikely means of attack that I don't think it is worth much effort (in comparison to how easy it is to fake a "genuine" DHCP reply). kre From owner-zeroconf@merit.edu Tue Jan 28 06:12:50 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21011 for ; Tue, 28 Jan 2003 06:12:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F27AD91218; Tue, 28 Jan 2003 06:15:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7DCBF912F5; Tue, 28 Jan 2003 06:15: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 604A091218 for ; Tue, 28 Jan 2003 06:15:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8AC785DF3E; Tue, 28 Jan 2003 06:15:16 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 8FD655DE32 for ; Tue, 28 Jan 2003 06:15:14 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0SBF2R08777; Tue, 28 Jan 2003 18:15:04 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0SB9bV02560; Tue, 28 Jan 2003 18:09:43 +0700 (ICT) From: Robert Elz To: "Philip Nye" Cc: "Zeroconf Working Group" Subject: Re: Disabling LL on the link In-Reply-To: <001801c2c6b4$66efa6f0$131010ac@aldebaran> References: <001801c2c6b4$66efa6f0$131010ac@aldebaran> <91ABD64A-3233-11D7-9EAD-00039367340A@nominum.com> <1532.1043738843@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Jan 2003 18:09:37 +0700 Message-ID: <2558.1043752177@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 28 Jan 2003 10:02:43 -0000 From: "Philip Nye" Message-ID: <001801c2c6b4$66efa6f0$131010ac@aldebaran> | Should a mechanism be mandated or recommended whereby all LL communication | *on a link* can be stopped - even if this means that some hosts can then not | communicate on that link at all? Regardless of the desirable answer to this question, it is pointless to ask it here. The only way to prevent any communication on a link, is for the link itself to somehow block it. I can't even imagine how you'd manage to get an old style fat orange ethernet cable (or even one of the slightly newer, but still obsolete, thinner black ones) to prevent anything at all. And even where it might be possible, making this happen would be someone else's problem, nothing to do with this WG. The very most that this WG can possibly hope to be involved in are your other two questions - should a node configure a LL address for itself (or perhaps better, when should a node ...) which is clearly in scope (along with how it should be done, when it should), and perhaps the other, of whether a node should communicate with other nodes that have LL addresses - which I presume would really be better rephrased as whether a node should take special measures to enable communication with LL addresses knowing they are local to the link, and when it should not (as even my node, which has never heard of a LL address, will communicate with 169.254.x.y (or whatever the magic number is) if I tell it to, and the nearby router forwards packets for that address to somewhere where it lives). kre From owner-zeroconf@merit.edu Tue Jan 28 07:03:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22616 for ; Tue, 28 Jan 2003 07:03:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 79AF4912F7; Tue, 28 Jan 2003 07:05:30 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B91E9912F8; Tue, 28 Jan 2003 07:05: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 C5EE0912F7 for ; Tue, 28 Jan 2003 07:05:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9AF725E00F; Tue, 28 Jan 2003 07:05: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 6B8045DE32 for ; Tue, 28 Jan 2003 07:05: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 C792759898 for ; Tue, 28 Jan 2003 12:05:22 +0000 (GMT) Message-ID: <006c01c2c6c5$8779d240$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <001801c2c6b4$66efa6f0$131010ac@aldebaran> <91ABD64A-3233-11D7-9EAD-00039367340A@nominum.com> <1532.1043738843@munnari.OZ.AU> <2558.1043752177@munnari.OZ.AU> Subject: Re: Disabling LL on the link Date: Tue, 28 Jan 2003 12:05:20 -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: "Robert Elz" > > | Should a mechanism be mandated or recommended whereby all LL communication > | *on a link* can be stopped - even if this means that some hosts can then not > | communicate on that link at all? > > Regardless of the desirable answer to this question, it is > pointless to ask it here. The only way to prevent any > communication on a link, is for the link itself to somehow block it. I should have qualified the question by saying "between compliant hosts": Should a mechanism be mandated or recommended whereby all LL communication between compliant hosts *on a link* can be stopped - even if this means that some of those hosts can then not communicate on that link at all? There are those here who plainly want this and I see no reason that this is beyond the scope of the WG. You appear to be arguing that such a mechanism is impractical because hosts would not comply (or not enough of them to make it useful). Others are arguing that this is undesirable in principle. (Personally I am undecided but tending to one of the latter two positions). However, we seem incapable of framing a question, let alone an answer! Philip From owner-zeroconf@merit.edu Tue Jan 28 07:17:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23231 for ; Tue, 28 Jan 2003 07:17:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 873EE912F8; Tue, 28 Jan 2003 07:18:58 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 091D3912F9; Tue, 28 Jan 2003 07:18: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 A9188912F8 for ; Tue, 28 Jan 2003 07:18:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F2AC5DEB3; Tue, 28 Jan 2003 07:18:19 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 0B0DA5DE32 for ; Tue, 28 Jan 2003 07:18:18 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0SCI7R11590; Tue, 28 Jan 2003 19:18:07 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0SCBTV02977; Tue, 28 Jan 2003 19:11:30 +0700 (ICT) From: Robert Elz To: "Philip Nye" Cc: "Zeroconf Working Group" Subject: Re: Disabling LL on the link In-Reply-To: <006c01c2c6c5$8779d240$131010ac@aldebaran> References: <006c01c2c6c5$8779d240$131010ac@aldebaran> <001801c2c6b4$66efa6f0$131010ac@aldebaran> <91ABD64A-3233-11D7-9EAD-00039367340A@nominum.com> <1532.1043738843@munnari.OZ.AU> <2558.1043752177@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Jan 2003 19:11:29 +0700 Message-ID: <2975.1043755889@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 28 Jan 2003 12:05:20 -0000 From: "Philip Nye" Message-ID: <006c01c2c6c5$8779d240$131010ac@aldebaran> | I should have qualified the question by saying "between compliant hosts": In that case, I don't see the difference between this question and #3. If a host is prevented from communicating with hosts with LL addresses, all you need to do is repeat that for all the other hosts on the link. If you can assume they're all compliant, there would be no LL communications left. | You appear to be arguing that such a mechanism is impractical because hosts | would not comply (or not enough of them to make it useful). No, it was impractical because the initial question seemed to be aimed at what the link would allow, not what the hosts would do (or not do). Now I just see it as a variation on question 3, which I have ignored for now (having said enough on these issues already, I believe). kre From owner-zeroconf@merit.edu Tue Jan 28 07:32:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23430 for ; Tue, 28 Jan 2003 07:32:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C1BB5912F9; Tue, 28 Jan 2003 07:33:51 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C7AA912FD; Tue, 28 Jan 2003 07:33: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 06BB4912F9 for ; Tue, 28 Jan 2003 07:31:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 99A455DE32; Tue, 28 Jan 2003 07:31:35 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id DB3115DE22 for ; Tue, 28 Jan 2003 07:31:33 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0SCVFR12198 for ; Tue, 28 Jan 2003 19:31:21 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0SCG2V02994; Tue, 28 Jan 2003 19:16:02 +0700 (ICT) From: Robert Elz To: "Philip Nye" Cc: "Zeroconf Working Group" Subject: Re: Solving the wrong problems In-Reply-To: <062901c2c5f0$429be0d0$131010ac@aldebaran> References: <062901c2c5f0$429be0d0$131010ac@aldebaran> <000601c2c5dd$4ecd5900$c900a8c0@SGOSWAMIPCL> <13269.1043660792@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Jan 2003 19:16:02 +0700 Message-ID: <2992.1043756162@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 27 Jan 2003 10:38:41 -0000 From: "Philip Nye" Message-ID: <062901c2c5f0$429be0d0$131010ac@aldebaran> | I agree with you but draw slightly different conclusions. I see the | rationale in adding the DHCP client as a commercial one: Add a DHCP client | and your device will scale (from tiny to huge networks) without any | configuration required (at the device). Omit the client and you will have to | answer to disappointed customers. Yes, as I said, nothing can stop manufacturers doing what they want. Our question is what the IETF should say is acceptable. In the context of your comment - do you think it acceptable if the device manufacturer can answer the disappointed customers by saying "What I did is correct, see, the IETF says that implementing DHCP clients is optional, if the device doesn't work for you, there must be something wrong with your network" ? kre From owner-zeroconf@merit.edu Tue Jan 28 07:36:39 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23729 for ; Tue, 28 Jan 2003 07:36:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 919B5912FD; Tue, 28 Jan 2003 07:39:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58E11912FE; Tue, 28 Jan 2003 07:39: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 49173912FD for ; Tue, 28 Jan 2003 07:39:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3A6315DE4A; Tue, 28 Jan 2003 07:39:54 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id B82185DE32 for ; Tue, 28 Jan 2003 07:39:52 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0SCdiR12732; Tue, 28 Jan 2003 19:39:44 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0SCX8V03016; Tue, 28 Jan 2003 19:33:09 +0700 (ICT) From: Robert Elz To: Daniel Senie Cc: zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: <5.2.0.9.2.20030127081455.02808200@mail.amaranth.net> References: <5.2.0.9.2.20030127081455.02808200@mail.amaranth.net> <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL> <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 28 Jan 2003 19:33:08 +0700 Message-ID: <3014.1043757188@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 27 Jan 2003 12:12:29 -0500 From: Daniel Senie Message-ID: <5.2.0.9.2.20030127081455.02808200@mail.amaranth.net> | Because there are USEFUL THINGS to do with the TCP/IP protocol suite OTHER | than talking to someone on the far side of the planet. LL can and does | provide a communications path for such. Of course. You seem to think I am arguing against the existence of LL addresses. I am not. The point you're missing here however, is that you (as the manufacturer of a device) cannot possibly know whether the someone I want the device to talk to is on the same LAN, on an adjacent LAN just the other side of that nearby router, or on the other side of the world. You might find it peculiar to imagine that someone on the other side of the world should want to communicate with it, and that the owner of the device might want exactly that (given that they may be the same person), but peculiar or not, we should not be recommending to anyone that they prevent such things. Not being able to assign anything but a LL address (which is what this particular sub-thread was about) means they prevent such things. That isn't something we should be endorsing, regardless of whether or not such things may one day get (inappropriately INMNSHO) get built. | I suspect he was implying overriding of the factory value, no, I think he was trying to give an example of an address that wasn't manually configured - just picked a bad one. | > If you want to (and can | >invent a scheme that will actually work with Internet routing) have IP | >addresses configured at the factory, that would be fine too. | | That would not be fine. I assume you mean that it wouldn't work, and I agree (see the parenthetical remark), but if it could work (somehow I cannot imagine) then it would be fine. | However, if we're talking about a printer or | print server, it may not be fine. A printer may do better having both an LL | address and a non-LL address. No, it makes no sense. All you ever *need* to talk IP is one address. With one (of sufficient scope anyway) you can talk with anyone and everyone. Having two (other than in situations where you want to seem to be two disjoint entities, which isn't the issue here) is of no benefit whatever. | The preference would be to use the non-LL, | but if talking with a device that has no non-LL address, having the ability | to print might be useful (if that's what the owner of the devices wants). Of course. But you *do not need* a LL address (in the printer) to make that work. I thought that misconception had been beaten to death already. What you need is for the printer to know about LL addresses and how they work. But of course, if the printer were to ever have an LL address, that would be a pre-requisite. (This also has nothing to do with what the rest of this message, and the previous one, were about, which related to whether the device should attempt to obtain the non-LL address in the first place, or whether devices should be perpared to simply settle for having a LL address and desire nothing else.) kre From owner-zeroconf@merit.edu Tue Jan 28 08:41:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25683 for ; Tue, 28 Jan 2003 08:41:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9A6D691303; Tue, 28 Jan 2003 08:44:48 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 69B3391305; Tue, 28 Jan 2003 08:44: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 5E14E91303 for ; Tue, 28 Jan 2003 08:44:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A58A5DE4F; Tue, 28 Jan 2003 08:44:47 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by segue.merit.edu (Postfix) with ESMTP id 2A00D5DE40 for ; Tue, 28 Jan 2003 08:44:47 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 18dW2Z-0007ed-00; Tue, 28 Jan 2003 05:44:39 -0800 Date: Tue, 28 Jan 2003 08:43:04 -0500 From: Keith Moore To: "Subrata Goswami" Cc: moore@cs.utk.edu, rdroms@cisco.com, zeroconf@merit.edu Subject: Re: Solving the wrong problems Message-Id: <20030128084304.76007417.moore@cs.utk.edu> In-Reply-To: <003501c2c698$29517c90$c900a8c0@SGOSWAMIPCL> References: <20030127230421.7708e481.moore@cs.utk.edu> <003501c2c698$29517c90$c900a8c0@SGOSWAMIPCL> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Yes I do know which device needs global, which needs LL, and which needs > both. no you do not, unless you also control the networks to which your devices are attached. From owner-zeroconf@merit.edu Tue Jan 28 09:02:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26037 for ; Tue, 28 Jan 2003 09:02:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 089F191305; Tue, 28 Jan 2003 09:03:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 773F791307; Tue, 28 Jan 2003 09:03: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 AD0D291305 for ; Tue, 28 Jan 2003 09:01:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 846895DE22; Tue, 28 Jan 2003 09:01:25 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from albatross.mail.pas.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by segue.merit.edu (Postfix) with ESMTP id 6298B5DDD4 for ; Tue, 28 Jan 2003 09:01:25 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by albatross.prod.itd.earthlink.net with smtp (Exim 3.33 #1) id 18dWIk-0001Og-00; Tue, 28 Jan 2003 06:01:23 -0800 Date: Tue, 28 Jan 2003 08:59:48 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Disabling LL on the link Message-Id: <20030128085948.2d96bf2b.moore@cs.utk.edu> In-Reply-To: <001801c2c6b4$66efa6f0$131010ac@aldebaran> References: <91ABD64A-3233-11D7-9EAD-00039367340A@nominum.com> <1532.1043738843@munnari.OZ.AU> <001801c2c6b4$66efa6f0$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > Should a mechanism be mandated or recommended whereby all LL communication > *on a link* can be stopped - even if this means that some hosts can then not > communicate on that link at all? yes. but this should not prevent any hosts from communicating on that link, unless they are prohibited as a matter of policy, because there should be no LL-only hosts. From owner-zeroconf@merit.edu Tue Jan 28 09:04:01 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26068 for ; Tue, 28 Jan 2003 09:04:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BAC5891307; Tue, 28 Jan 2003 09:04:03 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73CF391309; Tue, 28 Jan 2003 09:04: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 E19B891307 for ; Tue, 28 Jan 2003 09:03:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id CA4D65DE40; Tue, 28 Jan 2003 09:03:58 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from grebe.mail.pas.earthlink.net (grebe.mail.pas.earthlink.net [207.217.120.46]) by segue.merit.edu (Postfix) with ESMTP id A990D5DE22 for ; Tue, 28 Jan 2003 09:03:58 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18dWKP-0004Yf-00; Tue, 28 Jan 2003 06:03:06 -0800 Date: Tue, 28 Jan 2003 09:01:31 -0500 From: Keith Moore To: Robert Elz Cc: moore@cs.utk.edu, philip@engarts.com, zeroconf@merit.edu Subject: Re: Disabling LL on the link Message-Id: <20030128090131.4233dc4a.moore@cs.utk.edu> In-Reply-To: <2975.1043755889@munnari.OZ.AU> References: <006c01c2c6c5$8779d240$131010ac@aldebaran> <001801c2c6b4$66efa6f0$131010ac@aldebaran> <91ABD64A-3233-11D7-9EAD-00039367340A@nominum.com> <1532.1043738843@munnari.OZ.AU> <2558.1043752177@munnari.OZ.AU> <2975.1043755889@munnari.OZ.AU> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > In that case, I don't see the difference between this question and #3. > If a host is prevented from communicating with hosts with LL addresses, > all you need to do is repeat that for all the other hosts on the link. > If you can assume they're all compliant, there would be no LL communications > left. true. the question is whether compliance should compel hosts to enforce that rule even when talking to non-compliant hosts. I say yes. From owner-zeroconf@merit.edu Tue Jan 28 09:06:05 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26096 for ; Tue, 28 Jan 2003 09:06:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EFD0C91276; Tue, 28 Jan 2003 09:09:29 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C190791309; Tue, 28 Jan 2003 09: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 4256C91276 for ; Tue, 28 Jan 2003 09:09:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2BD995DEEC; Tue, 28 Jan 2003 09:09:26 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id D10495DDD4 for ; Tue, 28 Jan 2003 09:09:25 -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 HAA10018; Tue, 28 Jan 2003 07:09:23 -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 h0SE9Jl13481; Tue, 28 Jan 2003 15:09:20 +0100 (MET) Date: Tue, 28 Jan 2003 15:09:18 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: zeroconf@merit.edu Cc: Thomas Narten , erik.nordmark@sun.com Subject: resolving the 'mechanism to disable' discussion In-Reply-To: <20030128084304.76007417.moore@cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk By now we have heard from certain contributors enough to know where they stand. Those of you who are posting several times a day, **please restrain yourself.** Those of you who have not responded to Thomas Narten's plea for input, please do so. Some of you have not expressed your opinion on the matter of whether the IPv4LL specification has to specify a mechanism whereby a host who *cannot obtain* an address configuration parameter (whether from DHCP, manual, etc) MUST unconfigure its IPv4LL interface and stop using IPv4LL as its source address. Whether this mechanism is that a host can discover a DHCP server which will not hand out an address, or whether the DHCP server will then send the host a RFC2563 or RFC2563-like message is interesting, but not the fundamental question. The question is *Should there should be* an explicit policy and mechanism for administrative disabling of IPv4LL configuration included as mandatory to implement in the IPv4LL spec? Let's take input on this for another week (till Feb 4) then assess the positions taken. This document is currently in the IESG's hands, having gone through several WG last calls and two IETF last calls. We leave it to Thomas and Erik to determine the next step. Thanks, Erik From owner-zeroconf@merit.edu Tue Jan 28 09:59:06 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27175 for ; Tue, 28 Jan 2003 09:59:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 802199130C; Tue, 28 Jan 2003 10:00:44 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 623CC91312; Tue, 28 Jan 2003 10:00: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 6470E9130C for ; Tue, 28 Jan 2003 10:00:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id D9A1C5DE4F; Tue, 28 Jan 2003 10:00:32 -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 651FC5DDC3 for ; Tue, 28 Jan 2003 10:00:32 -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 7C5405989F for ; Tue, 28 Jan 2003 15:00:34 +0000 (GMT) Message-ID: <007a01c2c6de$00a13740$131010ac@aldebaran> From: "Philip Nye" To: "Zeroconf Working Group" References: <20030127230421.7708e481.moore@cs.utk.edu><003501c2c698$29517c90$c900a8c0@SGOSWAMIPCL> <20030128084304.76007417.moore@cs.utk.edu> Subject: Re: Solving the wrong problems Date: Tue, 28 Jan 2003 15:00:31 -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: "Keith Moore" > > > Yes I do know which device needs global, which needs LL, and which needs > > both. > > no you do not, unless you also control the networks to which your devices are > attached. In the embedded world, controlling (or specifying) the network as well as the devices is not such an uncommon scenario. Philip From owner-zeroconf@merit.edu Tue Jan 28 10:10:22 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27392 for ; Tue, 28 Jan 2003 10:10:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 41E799130E; Tue, 28 Jan 2003 10:13:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0CFDA91310; Tue, 28 Jan 2003 10:13: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 EF8E39130E for ; Tue, 28 Jan 2003 10:13:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id D5B275DF44; Tue, 28 Jan 2003 10:13:41 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by segue.merit.edu (Postfix) with ESMTP id 056CC5DEEC for ; Tue, 28 Jan 2003 10:13:41 -0500 (EST) Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) with ESMTP id h0SFDdiC029893 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 28 Jan 2003 17:13:39 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.12.3/8.12.3/Debian -4) id h0SFDdhL029889; Tue, 28 Jan 2003 17:13:39 +0200 Date: Tue, 28 Jan 2003 17:13:39 +0200 Message-Id: <200301281513.h0SFDdhL029889@burp.tkv.asdf.org> From: Markku Savela To: zeroconf@merit.edu In-reply-to: (message from Erik Guttman on Tue, 28 Jan 2003 15:09:18 +0100 (CET)) Subject: Re: resolving the 'mechanism to disable' discussion References: Sender: owner-zeroconf@merit.edu Precedence: bulk > Some of you have not expressed your opinion on the matter of whether the > IPv4LL specification has to specify > > a mechanism whereby a host who *cannot obtain* an address > configuration parameter (whether from DHCP, manual, etc) MUST > unconfigure its IPv4LL interface and stop using IPv4LL as its source > address. I don't have direct answer, but let me explain how it is implemented in the dual IPv4/IPv6 stack which I've been involved with. - there is configuration flag for LL. When enabled, it will install 169.254/16 as onlink for the interface and generate LL address for itself. - interface can also have simultaneous any number of other addresses and netmasks configured (from manual configuration, DHCP etc). - if a destination address is LL, then system will use LL source address. If destination is global address, system will require global source address (LL address won't do -- I suppose this is against the LL draft, but as this is actually an IPv6 stack supporting scoped addressing, it applies the same source address selection rules as for IPv6 addresses) I cannot see what the big fuss is about, if a node configures itself for LL? It does not hurt any other nodes. Link is no worse by it, sees only few ARP's which go unanswered. And if THERE are more than one LL node, what harm does it do if they manage to communicate with LL's? And, if a LL node has some applications that get confused by LL, then again this only hurts the node itself, and I'm perhaps willing to take my chanches, that there are no such thing. I don't see any need for 'mechanism to disable', at least not mandatory. From owner-zeroconf@merit.edu Tue Jan 28 10:20:16 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27651 for ; Tue, 28 Jan 2003 10:20:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2DB9791310; Tue, 28 Jan 2003 10:23:39 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF0BA91311; Tue, 28 Jan 2003 10:23: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 D74D691310 for ; Tue, 28 Jan 2003 10:23:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id C34745DF38; Tue, 28 Jan 2003 10:23:37 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by segue.merit.edu (Postfix) with ESMTP id A2A465DEE6 for ; Tue, 28 Jan 2003 10:23:37 -0500 (EST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18dXaI-0001aq-00; Tue, 28 Jan 2003 07:23:35 -0800 Date: Tue, 28 Jan 2003 10:21:59 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: Solving the wrong problems Message-Id: <20030128102159.6c093d5d.moore@cs.utk.edu> In-Reply-To: <007a01c2c6de$00a13740$131010ac@aldebaran> References: <20030127230421.7708e481.moore@cs.utk.edu> <003501c2c698$29517c90$c900a8c0@SGOSWAMIPCL> <20030128084304.76007417.moore@cs.utk.edu> <007a01c2c6de$00a13740$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > > no you do not, unless you also control the networks to which your devices > > are attached. > > In the embedded world, controlling (or specifying) the network as well as > the devices is not such an uncommon scenario. You can do whatever you want on your own network that you control. You don't need to follow IETF's standards if you don't wish to do so, and you don't need IETF's blessing to do whatever it is you want to do. You are then responsible for, and the victim or beneficiary of, whatever mess or marvel you create. The purpose of IETF's standards is to allow things to interoperate when that degree of control does not exist. If you implement IPv4, you're supposed to be able to exchange packets with other devices that implement IPv4. It defeats IETF's purposes to say that it's okay for some devices to implement a special kind of IPv4 that doesn't interoperate with normal IPv4, or which does so only under some narrow set of conditions. From owner-zeroconf@merit.edu Tue Jan 28 11:04:03 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29277 for ; Tue, 28 Jan 2003 11:04:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E389591316; Tue, 28 Jan 2003 11:05:46 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFB929131E; Tue, 28 Jan 2003 11:05:42 -0500 (EST) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1922291319 for ; Tue, 28 Jan 2003 11:04:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id ECF885DF44; Tue, 28 Jan 2003 11:04:24 -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 827DA5DEFB for ; Tue, 28 Jan 2003 11:04:24 -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 h0SG3IJ07376 (using TLSv1/SSLv3 with cipher DES-CBC3-SHA (168 bits) verified NO); Tue, 28 Jan 2003 11:03:19 -0500 Message-Id: <5.2.0.9.2.20030128104057.02aca570@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Jan 2003 10:51:04 -0500 To: Robert Elz From: Daniel Senie Subject: Re: Solving the wrong problems Cc: zeroconf@merit.edu In-Reply-To: <3014.1043757188@munnari.OZ.AU> References: <5.2.0.9.2.20030127081455.02808200@mail.amaranth.net> <5.2.0.9.2.20030127081455.02808200@mail.amaranth.net> <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL> <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-zeroconf@merit.edu Precedence: bulk At 07:33 AM 1/28/2003, Robert Elz wrote: > Date: Mon, 27 Jan 2003 12:12:29 -0500 > From: Daniel Senie > Message-ID: <5.2.0.9.2.20030127081455.02808200@mail.amaranth.net> > > | Because there are USEFUL THINGS to do with the TCP/IP protocol suite > OTHER > | than talking to someone on the far side of the planet. LL can and does > | provide a communications path for such. > >Of course. You seem to think I am arguing against the existence of >LL addresses. I am not. You did give that impression. I am sorry I misinterpreted your words. >The point you're missing here however, is that you (as the manufacturer >of a device) cannot possibly know whether the someone I want the device >to talk to is on the same LAN, on an adjacent LAN just the other side >of that nearby router, or on the other side of the world. While that's fine, it's NOT an issue for this draft. If I decide to build a device that only talks LL, and you don't want such a device, you won't buy it. It's a marketplace matter, NOT a standards matter. > You might >find it peculiar to imagine that someone on the other side of the world >should want to communicate with it, and that the owner of the device might >want exactly that (given that they may be the same person), but peculiar >or not, we should not be recommending to anyone that they prevent such things. And we should NOT be dictating how manufacturers design product at that level. If a manufacturer wants to build a device that does LL, and does MANUAL configuration of IP addresses, but not DHCP, is that really your problem, or theirs? >Not being able to assign anything but a LL address (which is what this >particular sub-thread was about) means they prevent such things. That >isn't something we should be endorsing, regardless of whether or not >such things may one day get (inappropriately INMNSHO) get built. I don't know that we're endorsing it by permitting the particular scenario. I guess we just disagree on this point. > | I suspect he was implying overriding of the factory value, > >no, I think he was trying to give an example of an address that wasn't >manually configured - just picked a bad one. > > | > If you want to (and can > | >invent a scheme that will actually work with Internet routing) have IP > | >addresses configured at the factory, that would be fine too. > | > | That would not be fine. > >I assume you mean that it wouldn't work, and I agree (see the >parenthetical remark), but if it could work (somehow I cannot >imagine) then it would be fine. Let's avoid items in the discussion that couldn't possibly work, and stick to the specific issues. > | However, if we're talking about a printer or > | print server, it may not be fine. A printer may do better having both > an LL > | address and a non-LL address. > >No, it makes no sense. All you ever *need* to talk IP is one address. >With one (of sufficient scope anyway) you can talk with anyone and >everyone. Having two (other than in situations where you want to >seem to be two disjoint entities, which isn't the issue here) is of >no benefit whatever. I look forward to seeing running code. > | The preference would be to use the non-LL, > | but if talking with a device that has no non-LL address, having the > ability > | to print might be useful (if that's what the owner of the devices wants). > >Of course. But you *do not need* a LL address (in the printer) to make >that work. I thought that misconception had been beaten to death already. From one end, yes, but let's explore it for a moment longer. >What you need is for the printer to know about LL addresses and how they work. >But of course, if the printer were to ever have an LL address, that would be >a pre-requisite. The laptop will have ONLY a route for 169.254/16. So when it gets an answer from 192.168.23.34/24, for example, how does it know to get a packet back? If we're saying LL implementations MUST ARP for ALL addresses via the local LAN, even those outside 169.254/16, then yes it would work. Is that how you're suggesting it work? I'm not sure we've sufficiently said that in the draft if it's the case. Without such a route, the LL-only machine would have no route to where the printer is. A host which does have LL-only address and transitions off would also need to REMOVE this "default route everything to the local wire" route. If that's the intention, then fine. That's not how the stacks I've worked with have operated, but it's entirely possible everyone is happy with this approach. Looking forward to seeing running code. >(This also has nothing to do with what the rest of this message, and the >previous one, were about, which related to whether the device should >attempt to obtain the non-LL address in the first place, or whether devices >should be perpared to simply settle for having a LL address and desire nothing >else.) > >kre From owner-zeroconf@merit.edu Tue Jan 28 11:28:26 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29926 for ; Tue, 28 Jan 2003 11:28:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 926E691317; Tue, 28 Jan 2003 11:28:45 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 598B891335; Tue, 28 Jan 2003 11:28: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 3DA8491317 for ; Tue, 28 Jan 2003 11:27:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2CCEA5DF8C; Tue, 28 Jan 2003 11:27:30 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id B2C725DF8B for ; Tue, 28 Jan 2003 11:27:29 -0500 (EST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA27883 for ; Tue, 28 Jan 2003 11:27: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 LAA29987 for ; Tue, 28 Jan 2003 11:12: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 LAA21170 for ; Tue, 28 Jan 2003 11:08:03 -0500 (EST) User-Agent: Microsoft-Entourage/10.1.0.2418 Date: Tue, 28 Jan 2003 11:08:01 -0500 Subject: Re: Solving the wrong problems From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <2992.1043756162@munnari.OZ.AU> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 01/28/2003 07:16, "Robert Elz" wrote: > Our question is what the IETF should say is acceptable. In the context > of your comment - do you think it acceptable if the device manufacturer > can answer the disappointed customers by saying "What I did is correct, > see, the IETF says that implementing DHCP clients is optional, if the > device doesn't work for you, there must be something wrong with your > network" ? That won't happen more than once...the customer then says, "This other vendor does what I want with 40% less sass-mouth, so buh-bye" john -- John C. Welch Consultant III Administrative Computing (617) 253 - 1368 work (508) 579 - 7380 cell bynkii2 AIM From owner-zeroconf@merit.edu Tue Jan 28 11:43:20 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00748 for ; Tue, 28 Jan 2003 11:43:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F2F7191368; Tue, 28 Jan 2003 11:45:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55C0091369; Tue, 28 Jan 2003 11:45: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 AFE3D91368 for ; Tue, 28 Jan 2003 11:45:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id AA1575DF8C; Tue, 28 Jan 2003 11:45:09 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 2D7BB5DF51 for ; Tue, 28 Jan 2003 11:45:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id DF54114055; Tue, 28 Jan 2003 11:45:04 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 16557-08; Tue, 28 Jan 2003 11:45:04 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 49F1B13FE0; Tue, 28 Jan 2003 11:45:04 -0500 (EST) Date: Tue, 28 Jan 2003 11:45:04 -0500 From: Keith Moore To: Daniel Senie Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, zeroconf@merit.edu Subject: Re: Solving the wrong problems Message-Id: <20030128114504.54aabd88.moore@cs.utk.edu> In-Reply-To: <5.2.0.9.2.20030128104057.02aca570@mail.amaranth.net> References: <5.2.0.9.2.20030127081455.02808200@mail.amaranth.net> <5.2.0.9.2.20030127081455.02808200@mail.amaranth.net> <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL> <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL> <5.2.0.9.2.20030128104057.02aca570@mail.amaranth.net> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: 200b98206b8012aecbf5cd9b8b273cc648af81dd Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > While that's fine, it's NOT an issue for this draft. If I decide to > build a device that only talks LL, and you don't want such a device, > you won't buy it. It's a marketplace matter, NOT a standards matter. The current draft has problems which prevent implementations from interoperating with existing IP hosts and networks and which cause cause implementations to violate policies of existing networks. It is inconsistent with long-established IETF standardization criteria to say that those problems are for the marketplace to sort out. Such tactics only serve further delay this group's producing a useful solution for ad hoc networks. From owner-zeroconf@merit.edu Tue Jan 28 11:44:51 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00795 for ; Tue, 28 Jan 2003 11:44:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C96CE91323; Tue, 28 Jan 2003 11:47:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A336F91325; Tue, 28 Jan 2003 11:47: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 6012791323 for ; Tue, 28 Jan 2003 11:47:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A7C65DF8C; Tue, 28 Jan 2003 11:47:37 -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 05EE25DEC0 for ; Tue, 28 Jan 2003 11:47:37 -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); Tue, 28 Jan 2003 08:47:36 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 28 Jan 2003 08:47:36 -0800 Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 28 Jan 2003 08:47:34 -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); Tue, 28 Jan 2003 08:47:33 -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.3718.0); Tue, 28 Jan 2003 08:47:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6830.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: resolving the 'mechanism to disable' discussion Date: Tue, 28 Jan 2003 08:47:39 -0800 Message-ID: Thread-Topic: resolving the 'mechanism to disable' discussion Thread-Index: AcLG1u+ikaSiNL4RQQudTRVl42BohwAEpyvQ From: "Christian Huitema" To: "Erik Guttman" , Cc: "Thomas Narten" , X-OriginalArrivalTime: 28 Jan 2003 16:47:35.0528 (UTC) FILETIME=[F59FFE80:01C2C6EC] Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA00795 > Some of you have not expressed your opinion on the matter of whether the > IPv4LL specification has to specify > > a mechanism whereby a host who *cannot obtain* an address > configuration parameter (whether from DHCP, manual, etc) MUST > unconfigure its IPv4LL interface and stop using IPv4LL as its source > address. As I mentioned in a previous message, this configuration parameter should really mean that "the hosts on this link have been configured to not accept packets from an IPv4LL address, so configuring one is futile." My opinion is that if we define this option, its configuration should be explicit, i.e. it should not be a side effect of the mere discovery of a DHCP server. The default behavior, in the absence of the option, should be to authorize use of IPv4LL. The security section of the draft should include a discussion of the denial of service potential of this option: a rogue DHCP client could potentially use it to disrupt IPv4LL based operation. However, we should note that to implement a rogue DHCP client requires access to the local link, and that an attacker with link access already has several other means of disrupting IPv4LL operation, for example simulating address collision or spoofing ARP packets. It is not clear that defining the DHCP option would make IPv4LL any more insecure than it already is. It is debatable whether the actual refusal of communication with IPv4LL should be a side effect of the "no IPv4LL parameter", or whether it should be explicitly configured in the local hosts, e.g. by programming their "personal firewall". Given the ease with which DHCP packets can be forged, I would personally prefer the latter, i.e. that IPv4LL aware hosts will only refuse to communicate with IPv4LL addresses if explicitly configured to do so. > Whether this mechanism is that a host can discover a DHCP server which > will not hand out an address, or whether the DHCP server will then send > the host a RFC2563 or RFC2563-like message is interesting, but not the > fundamental question. The question is *Should there should be* an > explicit policy and mechanism for administrative disabling of IPv4LL > configuration included as mandatory to implement in the IPv4LL spec? I believe there should be one. If we do not provide this option to network managers, we are likely to see uglier alternative develop, e.g. explicit interdiction of IPv4LL by having the DHCP server reply to all ARP probes for IPv4LL addresses. -- Christian Huitema From owner-zeroconf@merit.edu Tue Jan 28 12:11:03 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01395 for ; Tue, 28 Jan 2003 12:11:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3D0F091201; Tue, 28 Jan 2003 12:14:25 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06D4C9121F; Tue, 28 Jan 2003 12:14: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 ABC9391201 for ; Tue, 28 Jan 2003 12:14:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 900D05DF8C; Tue, 28 Jan 2003 12:14:23 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 70D0F5DDA1 for ; Tue, 28 Jan 2003 12:14:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 39BA214055; Tue, 28 Jan 2003 12:14:23 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 20234-09; Tue, 28 Jan 2003 12:14:22 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 786A213FE0; Tue, 28 Jan 2003 12:14:22 -0500 (EST) Date: Tue, 28 Jan 2003 12:14:22 -0500 From: Keith Moore To: "Christian Huitema" Cc: moore@cs.utk.edu, Erik.Guttman@sun.com, zeroconf@merit.edu, narten@us.ibm.com, erik.nordmark@sun.com Subject: Re: resolving the 'mechanism to disable' discussion Message-Id: <20030128121422.5f6f48d0.moore@cs.utk.edu> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: bf65baadcee990e1c7850be7e115dfc624366509 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > My opinion is that if we define this option, its configuration should > be explicit, i.e. it should not be a side effect of the mere discovery > of a DHCP server. The default behavior, in the absence of the option, > should be to authorize use of IPv4LL. I am fine with having the default being that v4LL is authorized as long as networks are given a clear way to say "no automatic configuration of v4LL", and as long as v4LL implementations are expected to honor this as a matter of standards compliance. I'm also fine with hosts having a way to override this by manual configuration. (actually I think it's highly desirable that they be able to do so) > The security section of the draft should include a discussion of the > denial of service potential of this option: a rogue DHCP client could > potentially use it to disrupt IPv4LL based operation. However, we > should note that to implement a rogue DHCP client requires access to > the local link, and that an attacker with link access already has > several other means of disrupting IPv4LL operation, for example > simulating address collision or spoofing ARP packets. It is not clear > that defining the DHCP option would make IPv4LL any more insecure than > it already is. In addition, the security risks of having v4LL be disabled by a rogue DHCP client need to be balanced against the security risks of having v4LL be enabled inappropriately. Anytime an attacker can cause a host to be configured in such a way that it does not gain full functionality from the network, this is a denial of service. One way to do that is to cause a host to fail to use v4LL on an ad hoc network. Another way to do that is to cause a host to use v4LL when it should be using a routable address assigned by DHCP. And there is also the potential for an attacker to coerce a host into violating network policy by interfering with DHCP and causing it to configure a v4LL address. Each of these scenarios needs to be addressed. > It is debatable whether the actual refusal of communication with > IPv4LL should be a side effect of the "no IPv4LL parameter", or > whether it should be explicitly configured in the local hosts, e.g. by > programming their "personal firewall". Given the ease with which DHCP > packets can be forged, I would personally prefer the latter, i.e. that > IPv4LL aware hosts will only refuse to communicate with IPv4LL > addresses if explicitly configured to do so. I think it's very useful to distinguish between automatic and/or default behavior that happens in the absence of explicit configuration, and what is allowable when a host is explicitly configured. > I believe there should be one. If we do not provide this option to > network managers, we are likely to see uglier alternative develop, > e.g. explicit interdiction of IPv4LL by having the DHCP server reply > to all ARP probes for IPv4LL addresses. agree entirely. Keith From owner-zeroconf@merit.edu Tue Jan 28 13:24:27 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02876 for ; Tue, 28 Jan 2003 13:24:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6649D91325; Tue, 28 Jan 2003 13:27:43 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B9D691327; Tue, 28 Jan 2003 13:27: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 4043D91325 for ; Tue, 28 Jan 2003 13:27:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2777B5DE74; Tue, 28 Jan 2003 13:27:42 -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 CC1D85DDEF for ; Tue, 28 Jan 2003 13:27:41 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0SIMIP03983; Tue, 28 Jan 2003 12:22:18 -0600 (CST) Date: Tue, 28 Jan 2003 12:27:37 -0600 Subject: Re: Disabling LL on the link Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Zeroconf Working Group" To: "Philip Nye" From: Ted Lemon In-Reply-To: <001801c2c6b4$66efa6f0$131010ac@aldebaran> Message-Id: <2D66DD9A-32EE-11D7-9EAD-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Should a mechanism be mandated or recommended whereby all LL > communication > *on a link* can be stopped - even if this means that some hosts can > then not > communicate on that link at all? No, because this is a denial of service attack. From owner-zeroconf@merit.edu Tue Jan 28 13:32:57 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03180 for ; Tue, 28 Jan 2003 13:32:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A4F249131D; Tue, 28 Jan 2003 13:34:41 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 290F091327; Tue, 28 Jan 2003 13:34: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 0732C9131D for ; Tue, 28 Jan 2003 13:33:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id D5F295DE9B; Tue, 28 Jan 2003 13:33:37 -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 7A1065DE8E for ; Tue, 28 Jan 2003 13:33:37 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id h0SISCP04046; Tue, 28 Jan 2003 12:28:12 -0600 (CST) Date: Tue, 28 Jan 2003 12:33:33 -0600 Subject: Re: Solving the wrong problems Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Philip Nye" , "Zeroconf Working Group" To: Robert Elz From: Ted Lemon In-Reply-To: <2992.1043756162@munnari.OZ.AU> Message-Id: <01CF74D6-32EF-11D7-9EAD-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > What I did is correct, > see, the IETF says that implementing DHCP clients is optional, if the > device doesn't work for you, there must be something wrong with your > network Erm, AFAIK implementing DHCP clients *is* optional. The manufacturer can *already* say this. From owner-zeroconf@merit.edu Tue Jan 28 13:36:44 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03275 for ; Tue, 28 Jan 2003 13:36:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 89F3291327; Tue, 28 Jan 2003 13:39:56 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 572779132B; Tue, 28 Jan 2003 13:39: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 3744191327 for ; Tue, 28 Jan 2003 13:39:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 265AD5DE9B; Tue, 28 Jan 2003 13:39:55 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from klutz.cs.utk.edu (klutz.cs.utk.edu [160.36.56.50]) by segue.merit.edu (Postfix) with ESMTP id 0D9215DE8A for ; Tue, 28 Jan 2003 13:39:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id ABC7E14055; Tue, 28 Jan 2003 13:39:54 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new) with ESMTP id 05961-08; Tue, 28 Jan 2003 13:39:54 -0000 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with SMTP id 1507F14076; Tue, 28 Jan 2003 13:39:54 -0500 (EST) Date: Tue, 28 Jan 2003 13:39:53 -0500 From: Keith Moore To: Ted Lemon Cc: moore@cs.utk.edu, kre@munnari.OZ.AU, philip@engarts.com, zeroconf@merit.edu Subject: Re: Solving the wrong problems Message-Id: <20030128133953.68427be4.moore@cs.utk.edu> In-Reply-To: <01CF74D6-32EF-11D7-9EAD-00039367340A@nominum.com> References: <2992.1043756162@munnari.OZ.AU> <01CF74D6-32EF-11D7-9EAD-00039367340A@nominum.com> X-Mailer: Sylpheed version 0.8.5claws (GTK+ 1.2.10; ) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new amavisd-new-20020630 with ClamAV X-Razor-id: bf6b045cd32429ae0eb8160f043770116fc47a6a Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Erm, AFAIK implementing DHCP clients *is* optional. The manufacturer > can *already* say this. Indeed, DHCP is optional. However if you don't have DHCP, having a mechanism to explicitly configure an address has always been a practical necessity. A device has never been able to simply allocate any address it wanted and expect to be able to interoperate. This is still the case even if it uses the v4LL discipline for allocating an address. Keith From owner-zeroconf@merit.edu Tue Jan 28 13:59:25 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03684 for ; Tue, 28 Jan 2003 13:59:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C203591330; Tue, 28 Jan 2003 14:00:55 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DEE4C9134E; Tue, 28 Jan 2003 14:00: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 2669C91330 for ; Tue, 28 Jan 2003 14:00:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 171715DF9A; Tue, 28 Jan 2003 14:00:46 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by segue.merit.edu (Postfix) with ESMTP id 5364C5DE9B for ; Tue, 28 Jan 2003 14:00:45 -0500 (EST) Received: from mspacman.gpcc.itd.umich.edu (mspacman.gpcc.itd.umich.edu [141.211.2.210]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id OAA17273; Tue, 28 Jan 2003 14:00:44 -0500 (EST) Received: from localhost (sgoswami@localhost) by mspacman.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id OAA20690; Tue, 28 Jan 2003 14:00:44 -0500 (EST) Date: Tue, 28 Jan 2003 14:00:44 -0500 (EST) From: "s. goswami" X-X-Sender: sgoswami@mspacman.gpcc.itd.umich.edu To: Christian Huitema Cc: zeroconf@merit.edu Subject: RE: resolving the 'mechanism to disable' discussion In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk see inline On Tue, 28 Jan 2003, Christian Huitema wrote: > > Some of you have not expressed your opinion on the matter of whether > the > > IPv4LL specification has to specify > > > > a mechanism whereby a host who *cannot obtain* an address > > configuration parameter (whether from DHCP, manual, etc) MUST > > unconfigure its IPv4LL interface and stop using IPv4LL as its source > > address. > > As I mentioned in a previous message, this configuration parameter > should really mean that "the hosts on this link have been configured to > not accept packets from an IPv4LL address, so configuring one is > futile." > > My opinion is that if we define this option, its configuration should be > explicit, i.e. it should not be a side effect of the mere discovery of a > DHCP server. The default behavior, in the absence of the option, should > be to authorize use of IPv4LL. > > The security section of the draft should include a discussion of the > denial of service potential of this option: a rogue DHCP client could > potentially use it to disrupt IPv4LL based operation. However, we should > note that to implement a rogue DHCP client requires access to the local > link, and that an attacker with link access already has several other > means of disrupting IPv4LL operation, for example simulating address > collision or spoofing ARP packets. It is not clear that defining the > DHCP option would make IPv4LL any more insecure than it already is. > > It is debatable whether the actual refusal of communication with IPv4LL > should be a side effect of the "no IPv4LL parameter", or whether it > should be explicitly configured in the local hosts, e.g. by programming > their "personal firewall". Given the ease with which DHCP packets can be > forged, I would personally prefer the latter, i.e. that IPv4LL aware > hosts will only refuse to communicate with IPv4LL addresses if > explicitly configured to do so. > > > Whether this mechanism is that a host can discover a DHCP server which > > will not hand out an address, or whether the DHCP server will then > send > > the host a RFC2563 or RFC2563-like message is interesting, but not the > > fundamental question. The question is *Should there should be* an > > explicit policy and mechanism for administrative disabling of IPv4LL > > configuration included as mandatory to implement in the IPv4LL spec? > > I believe there should be one. If we do not provide this option to > network managers, we are likely to see uglier alternative develop, e.g. > explicit interdiction of IPv4LL by having the DHCP server reply to all > ARP probes for IPv4LL addresses. even with a specified way of disabling LL this DoS would work. moreover links are usually protected (for 802.11 it is TKIP, for 802.3 it is 802.1x etc.). so in light of these protections a rouge host joining the link is negligible. the administrator (if one exists) of the link would first enforce these layer 2 mechanisms to make sure no unauthorized acess to the network has been made. with a specifed way of turning off LL on a link we have the consequences of someone using that mechanism as DoS. a better mechanism would be for each node to make its own decision about whether it wants to receive/respond to a LL packet or not. > -- Christian Huitema > From owner-zeroconf@merit.edu Tue Jan 28 23:07:59 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15912 for ; Tue, 28 Jan 2003 23:07:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6EEFA91234; Tue, 28 Jan 2003 23:11:20 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3EC5A91235; Tue, 28 Jan 2003 23:11: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 2870C91234 for ; Tue, 28 Jan 2003 23:11:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 131105DF20; Tue, 28 Jan 2003 23:11:19 -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 B98415DEF2 for ; Tue, 28 Jan 2003 23:11:18 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h0T4BI59002491; Tue, 28 Jan 2003 21:11:18 -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 VAA13811; Tue, 28 Jan 2003 21:11:15 -0700 (MST)] Received: from motorola.com (mvp-10-238-2-4.corp.mot.com [10.238.2.4]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id h0T4BBEE020301; Wed, 29 Jan 2003 15:11:12 +1100 (EST) Message-ID: <3E37545F.6070709@motorola.com> Date: Wed, 29 Jan 2003 15:11:11 +1100 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021216 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Guttman Cc: zeroconf@merit.edu, Thomas Narten , erik.nordmark@sun.com Subject: Re: resolving the 'mechanism to disable' discussion 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: > The question is *Should there should be* an > explicit policy and mechanism for administrative disabling of IPv4LL > configuration included as mandatory to implement in the IPv4LL spec? > I think a DHCP option (or similar mechanism) is unnecessary. Text recommending that an IPv4-LL address not be configured only if an address has been acquired via DHCP would be fine with me. It happens to co-incide with what most implementations do already and was suggested less than two weeks ago without any serious objections from people on the list. The sample set of messages I have read in the last few days hasn't turned up any new information that would change my opinion. - aidan From owner-zeroconf@merit.edu Wed Jan 29 03:41:40 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13467 for ; Wed, 29 Jan 2003 03:41:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6E64F9135D; Wed, 29 Jan 2003 03:42:14 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1914A91359; Wed, 29 Jan 2003 03:41: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 22F699135C for ; Wed, 29 Jan 2003 03:40:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE87E5DF66; Wed, 29 Jan 2003 03:40:18 -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 6B1065DEF4 for ; Wed, 29 Jan 2003 03:40:18 -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 BAA26627 for ; Wed, 29 Jan 2003 01:40:17 -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 h0T8eFl19187 for ; Wed, 29 Jan 2003 09:40:15 +0100 (MET) Date: Wed, 29 Jan 2003 09:40:13 +0100 (CET) From: Erik Guttman X-Sender: erikg@field To: Zeroconf Working Group Subject: Re: Solving the wrong problems In-Reply-To: <01CF74D6-32EF-11D7-9EAD-00039367340A@nominum.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Many useful applications of v4LL I have heard of are to allow a user-administrator to access with a no-console device locally to manually configure it. These v4LL devices should not be mimosa that shut down as soon as they are touched with certain DHCP options or lack of them. They should be able to continue using their v4LL configuration at least until they get another address (through DHCP, manual intervention, etc) or else they will *never* get configured with an address. The goal of giving administrators more control over v4LL devices' behavior is frustrated by having those devices shut down completely. Erik From owner-zeroconf@merit.edu Wed Jan 29 04:34:56 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14101 for ; Wed, 29 Jan 2003 04:34:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4F8B091230; Wed, 29 Jan 2003 04:37:35 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED26B91321; Wed, 29 Jan 2003 04:37: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 E7FA091230 for ; Wed, 29 Jan 2003 04:37:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id C9D515DFE9; Wed, 29 Jan 2003 04:37:28 -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 9C74E5DF94 for ; Wed, 29 Jan 2003 04:37:28 -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 CA782598CF; Wed, 29 Jan 2003 09:37:29 +0000 (GMT) Message-ID: <015d01c2c77a$09862900$131010ac@aldebaran> From: "Philip Nye" To: "Ted Lemon" Cc: "Zeroconf Working Group" References: <2D66DD9A-32EE-11D7-9EAD-00039367340A@nominum.com> Subject: Re: Disabling LL on the link Date: Wed, 29 Jan 2003 09:37:27 -0000 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "Ted Lemon" > > > Should a mechanism be mandated or recommended whereby all LL > > communication > > *on a link* can be stopped - even if this means that some hosts can > > then not > > communicate on that link at all? > > No, because this is a denial of service attack. Quite so - but this is precisely what is being proposed by some in saying that there must be a way for the network Administrator to "turn off" LL on the link: denial of service by the network administrator (who of course can do so in other ways anyway). The only exception to this assertion would be if that network administrator accepted that the *only* way to disable LL on the link was to grant all hosts a "better" address AND if the draft mandates DHCP client support or some other address override. We have to examine the motivation for a network admin wanting to deny service in this way. I cannot recall any cases where the mere presence of LL on the link breaks anything except where LL hosts are involved. So what is the justification for the network administrator being able to turn it off on the link entirely? Philip From owner-zeroconf@merit.edu Wed Jan 29 04:49:56 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14268 for ; Wed, 29 Jan 2003 04:49:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 709B791321; Wed, 29 Jan 2003 04:53:05 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1989B9135C; Wed, 29 Jan 2003 04:53: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 C186291321 for ; Wed, 29 Jan 2003 04:52:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9EF7D5DF74; Wed, 29 Jan 2003 04:52:57 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.12.73.3]) by segue.merit.edu (Postfix) with ESMTP id 8934F5DDAD for ; Wed, 29 Jan 2003 04:51:01 -0500 (EST) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h0T9nY021675; Wed, 29 Jan 2003 16:49:35 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h0T9lwV07209; Wed, 29 Jan 2003 16:47:58 +0700 (ICT) From: Robert Elz To: Daniel Senie Cc: zeroconf@merit.edu Subject: Re: Solving the wrong problems In-Reply-To: <5.2.0.9.2.20030128104057.02aca570@mail.amaranth.net> References: <5.2.0.9.2.20030128104057.02aca570@mail.amaranth.net> <5.2.0.9.2.20030127081455.02808200@mail.amaranth.net> <5.2.0.9.2.20030127081455.02808200@mail.amaranth.net> <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL> <00af01c2c593$83160d00$c900a8c0@SGOSWAMIPCL> <01CF74D6-32EF-11D7-9EAD-00039367340A@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 29 Jan 2003 16:47:58 +0700 Message-ID: <7207.1043833678@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 28 Jan 2003 10:51:04 -0500 From: Daniel Senie Message-ID: <5.2.0.9.2.20030128104057.02aca570@mail.amaranth.net> | While that's fine, it's NOT an issue for this draft. If I decide to build a | device that only talks LL, and you don't want such a device, you won't buy | it. It's a marketplace matter, NOT a standards matter. This is a common argument, but follow it through and the only conclusion is that nothing is a standards matter. Why should an implementor put the IP source address in before the IP destination address in IP headers rather than the other way around? If a manufacturer decides to build such a device it will only talk to other similar devices, but that's (apparently) OK, if you don't want such a device you don't buy it. Every standard that exists could be dismissed with such an argument. If you're of the opinion that there shouldn't be standards, and everyone should just do whatever they like, then this should be fine with you, but in that case, I have no idea what you're doing here, as the rest of us are attempting to actually define a standard. The idea is that devices interoperate properly when they obey the standard. On the Internet, using the Internet Protocols, that means that devices can talk to each other over the Internet. If you'd prefer to have devices just talk to each other over a LAN, you're in the wrong place, IEEE define standards for that, the IETF doesn't. | And we should NOT be dictating how manufacturers design product at that | level. No, you're misunderstanding again. No-one is telling the manufacturer what it is allowed to do (or not here anyway, that's for legislatures to do, and we aren't one). What we're doing is saying "If you build a device according to these rules, then it will operate correctly on the Internet". That's our job here, beginning and end (within the limits of the charter as to what kind of specific rules this WG gets to define of course). | If a manufacturer wants to build a device that does LL, and does | MANUAL configuration of IP addresses, but not DHCP, is that really your | problem, or theirs? No-one's problem. I have no problem allowing just manual config. Manual config is fine (not user friendly perhaps, but with (full) manual config available, the host is able to interoperate with the network, assuming it is properly configured). My problem is with devices that have neither manual config, nor DHCP (nor anything else similar). Those devices are the ones that can't interoperate properly. | >No, it makes no sense. All you ever *need* to talk IP is one address. | I look forward to seeing running code. There's plenty of running code now. In fact, I don't know of a single IP stack where this doesn't work (which doesn't mean there aren't any, there are lots of stacks I haven't ever used). | From one end, yes, but let's explore it for a moment longer. Fine, though we have done all this before. | The laptop will have ONLY a route for 169.254/16. So when it gets an answer | from 192.168.23.34/24, for example, how does it know to get a packet back? | If we're saying LL implementations MUST ARP for ALL addresses via the local | LAN, even those outside 169.254/16, then yes it would work. yes, of course. But why "only a route for 169.254/16" - if I was configuring a node to have a LL address, which means I cannot be configuring a router (we have no way to get such a thing), I'd always configure 0/0 on the local link. I have no idea how I'd make a device with 2 (or more) interfaces worth with only LL addreses, but I suspect that no-one else does either. | Is that how you're suggesting it work? Yes, of course. | I'm not sure we've sufficiently said that in the draft if it's the case. Agreed. The draft says "MAY" for doing this. With your philosophy of "manufacturers do what they like and we buy what works for us", you should be happy enough with that.... You just but LL devices which do it "the right way" and don't buy ones that can't talk to devices with no LL address. That's exactly what you were recommending above, right? Personally, I'd prefer to have that MAY turn into a MUST, I see no reason at all why it can possibly benefit anyone to have a device with only a LL address unable to communicate with any other random IP address it sees, and for interoperability, I'd simply require that devices attempt to work. Note, it is much simpler (for everyone) to do it this way, than to add the complication of requiring all the nodes that have non-LL addresses to acquire a LL address, and add the complexities of choosing which address to use, etc, and having to deal with all of that baggage. | A host which does have LL-only address and transitions off | would also need to REMOVE this "default route everything to the local wire" | route. yes, fine. When it is reconfiguring itself, it can do that. | If that's the intention, then fine. Good, we agree. And now, to attempt to keep the number of messages / day / person lower, some replies to some other messages I have seen on the list in the past 24 hours or so (a bit less I think). Apologies if this makes it hard to follow, hard for threading, etc, but keeping the number of messages down was requested. I pretty much agree with all of Christian Huitema's recent message Message-Id: (what a mouthful that is). There is some emphasis there I might change slightly, but nothing fundamental (nothing that matters now). Ted.Lemon@nominum.com said in <01CF74D6-32EF-11D7-9EAD-00039367340A@nominum.com>: | Erm, AFAIK implementing DHCP clients *is* optional. The manufacturer can | *already* say this. Yes, of course. But without LL, what we get is manual config, and that's adequate (not nice, as above, but adequate). Note that for manual config we have some rules (1122, 1123) about what needs to be able to be configured (and what doesn't). So, I have no problems if someone makes a PC operating system which doesn't implement DHCP (even if it defaults to configuring itself a LL address). Such a device I can always get at via its console and alter its config to something that will work. I wouldn't like such a device, and probably wouldn't buy it, but if someone attempts to connect such a thing to my net, I can make it work - it doesn't simply fail to interoperate. It is the "no configuration, no DHCP, LL addresses are good enough to work for everyone" kind of device that I want the standard to say "this is not a standards conforming device". Erik.Guttman@Sun.COM said in : | The goal of giving administrators more control over v4LL devices' behavior is | frustrated by having those devices shut down completely. Huh? Do you know what you're assuming? You're assuming here that the network operator is totally incompetant. He both wants to talk to the device, so he can configure it, and he wants it to fail to communicate. Why would we care? Are you also going to mandate that devices all be able to function with no AC connection (power) because the local administrators might not allow the device to be connected to a power point? DHCP servers will only be configured to tell a device not to use LL addresses if the administrator does *not* want to talk to the device using its LL address to otherwise configure it (or doesn't want to with the device connected to the net it is plugged into now). Take an example of a situation that may easily happen. You have a desk, and on the desk are two RJ-45 jacks. One of those is connected to a "wide open" net, where almost anything can and does happen, all kinds of of hackers hang about (not by desire, there's just nothing preventing them). You might think of that as being outside the network firewall - I usually think if it as being inside the firewall, where all the undregraduate students are doing whatever they feel like playing at... The second jack is connected to your nice secure stable network, where only yourself gets to connect devices, and only you get to use any of the devices that are connected (this may seem too good to be true, but real networks can at least approach this). Now assume you have this new device, unconfigured, that will assign itself a LL address, so you can connect to it and configure the thing. And you plug it into the wrong network by mistake... Now some evil cretin gets in before you do (you're looking for it on the other net of course, and not finding it there - takes a couple of minutes to realise what happened). During that period, they configure the device with a network address, access password, ... of their choosing, and disable LL addresses. Now you find the cable problem, and plug the device into your net, and start to try and find it to configure it. Oops... On the other hand, if out on the evil network, we had a DHCP server that would tell the device "no LL addresses for you", and would simply shut itself off, and remain inert, until you move it to the net it was supposed to be connected to in the first place. No-one gets in, no-one locks you out. This isn't foolproof of course - as an attacker could be running a rogue DHCP server on the open net, announcing that LL addresses are acceptable. Rogue DHCP servers are a general problem, and counter measures against them (which generally amount to detection, and then the application of the big stick) are needed anyway if the net is to function. Doing this also implies some amount of preparation, whereas if the device is just there with a LL address and some simple minded (unconfigured, so no password) configuration server running (http, telnet, snmp, whatever) then an opportunist which just sees the device advertise itself (which it must do for LL addresses to be usable, or you'd never guess the right one) can get in there with no preparation. Is perhaps this one an example that lets people see just why it is that we (some of us anyway) want to define a method to prevent LL addresses being used? (And yes, manual configuration of the device always overrides everything else). kre From owner-zeroconf@merit.edu Wed Jan 29 06:18:10 2003 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15976 for ; Wed, 29 Jan 2003 06:18:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1940191243; Wed, 29 Jan 2003 06:19:47 -0500 (EST) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9CFEC9135E; Wed, 29 Jan 2003 06:19: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 2F2CA91243 for ; Wed, 29 Jan 2003 06:19:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BED55E00F; Wed, 29 Jan 2003 06:19:42 -0500 (EST) Delivered-To: zeroconf@merit.edu Received: from soulshock.mail.pas.earthlink.net (soulshock.mail.pas.earthlink.net [207.217.120.130]) by segue.merit.edu (Postfix) with ESMTP id 852015DF94 for ; Wed, 29 Jan 2003 06:19:41 -0500 (EST) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by soulshock.mail.pas.earthlink.net (8.11.6+Sun/8.11.6) with ESMTP id h0TBFcH08278 for ; Wed, 29 Jan 2003 03:15:38 -0800 (PST) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18dqBF-0007Bi-00; Wed, 29 Jan 2003 03:14:57 -0800 Date: Wed, 29 Jan 2003 06:13:19 -0500 From: Keith Moore To: "Philip Nye" Cc: moore@cs.utk.edu, Ted.Lemon@nominum.com, zeroconf@merit.edu Subject: Re: Disabling LL on the link Message-Id: <20030129061319.302f88eb.moore@cs.utk.edu> In-Reply-To: <015d01c2c77a$09862900$131010ac@aldebaran> References: <2D66DD9A-32EE-11D7-9EAD-00039367340A@nominum.com> <015d01c2c77a$09862900$131010ac@aldebaran> X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) 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 > So what is > the justification for the network administrator being able to turn it off on > the link entirely? network admins have the right to set policies for their networks, including individual links, for whatever reason they see fit. it's not for us to decide whether there is adequate 'justification' or not. existing hosts attempt to get an address by DHCP, and if this is denied, they don't try to talk to the network unless explicitly configured to do so. this has led to DHCP being used by network admins to implement policy.