From owner-zeroconf@merit.edu Sun May 1 15:19:41 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11793 for ; Sun, 1 May 2005 15:19:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 21C44912AC; Sun, 1 May 2005 15:19:42 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D91FA912AD; Sun, 1 May 2005 15:19:41 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C7525912AC for ; Sun, 1 May 2005 15:19:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A844358288; Sun, 1 May 2005 15:19:40 -0400 (EDT) Delivered-To: zeroconf@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 8E0C558281 for ; Sun, 1 May 2005 15:19:40 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 74FF31861; Sun, 1 May 2005 15:19:40 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by testbed9.merit.edu (Postfix) with ESMTP id E8A98185E for ; Sun, 1 May 2005 15:19:39 -0400 (EDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 97E36BC for ; Sun, 1 May 2005 15:19:38 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id F0BD441EA for ; Sun, 1 May 2005 15:19:37 -0400 (EDT) Date: Sun, 01 May 2005 15:19:37 -0400 From: Rob Austein To: zeroconf@merit.edu Subject: Re: Proposed resolution: PTR queries for 254.169.in-addr.arpa In-Reply-To: <200504291439.j3TEd4I5005886@relay4.apple.com> References: <200504291439.j3TEd4I5005886@relay4.apple.com> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050501191937.F0BD441EA@thrintun.hactrn.net> Sender: owner-zeroconf@merit.edu Precedence: bulk Well, I thought we had a compromise, but Stuart appears to be having second thoughts, so I guess we're back to square one. At Fri, 29 Apr 2005 15:39:07 +0100, Stuart Cheshire wrote: > > >Recursive name servers MUST NOT allow these queries to > >escape the local scope. Recursive name servers MAY reply > >with RCODE 3, or they MAY silently discard the request. > > This text I have some reservations about. It suffers from the > all-to-common disease that "we couldn't decide, so we'll agree to > disagree". Yes, it does. It should have just required recursive name servers to reply with RCODE 3 rather than allowing them to drop queries silently, but some of us were trying to be nice and compromise with those who claim that silently dropping queries is better than answering them. > I think we all agree that recursive name servers should not allow these > queries to escape and place a burden on IANA name servers, but all the > arguments about returning RCODE 3 instead of silently dropping them > revolve around the purported burden that retransmitting clients impose on > a recursive name server, and the people making those arguments have > offered NO operational data showing any evidence that this purported > burden is real. We've had 169.254 addresses in Mac and Windows for FIVE > years now, and they are in UPnP devices, every network printer made for > the last couple of years, and other devices. Where is the evidence of an > actual burden on local recursive name servers caused by these devices or > their peers? Not being measured, or not being reported. Do you need every ISP in the world to drop a book in their machine rooms to verify that the law of gravity also applies in their location? > >By default, recursive name server implementations SHOULD be > >configured to act as if they were authoritative for an > >empty 254.169.in-addr.arpa zone and return RCODE 3 for any > >such query. Implementations SHOULD allow this default to > >be overridden. Returning an RCODE 3 is the correct default > >setting because it reduces the query load but also because if > >the site administrator has not set up the reverse tree > >corresponding to IPv4 Link-Local addresses in use, > >returning RCODE 3 is in fact the correct answer." > > This text I profoundly disagree with. It looks like it was written by > someone who knows about DNS, but not about IPv4 Link-Local > addressing, Wrong. > which is a problem. To write about how DNS and IPv4LL interact, you need > to understand both. > > Consider this sentence: > > >... if the site administrator has not set up the reverse tree > >corresponding to IPv4 Link-Local addresses in use, > >returning RCODE 3 is in fact the correct answer. > > What on earth does that mean? Who is the "site administrator"? The whole > point of IPv4LL is for small transient ad-hoc networks where there's no > DHCP server, no DNS server, and definitely no "site administrator"? Fine, so change it to "person who should have set up a DNS reverse zone to handle these bogus queries but didn't do so because somebody sold them on the idea that no expertise is needed to connect to the Internet." It is exactly the absence of a site administrator that makes it necessary to set up a default reverse zone (or behave as if one had been set up, same thing) out of the box. > Returning an authoritative NXDOMAIN error for 254.169.in-addr.arpa names > is not the semantically correct response. The semantically correct > response for a server to give to such a query is, "Why are you asking > me?" Possible semantically correct responses are to ignore the query, or > possibly REFUSED (5), but not an authoritative assertion that no such > name exists. The name does exist; the client just asked the wrong entity. Via the wrong protocol. LLMNR is not the DNS. The name does not exist in the DNS. DNS name servers should say that it does not exist. Unless of course the nonexistant site administrator does set up and populate a DNS reverse zone. You were saying something about needing to understand both IPv4LL and DNS? > Robert Elz suggested this pragmatic solution: > > >to keep the query rate on the in-addr.arpa servers rational, they > >should simply delegate this domain somewhere, with a lengthy TTL. > >It could delegate it to nowhere, one solution might be > > > > 254.169.in-addr.arpa. 2592000 IN NS ns.254.169.in-addr.arpa. > > ns.254.169.in-addr.arpa. 2592000 IN A 169.254.103.76 ; glue > > > >which would get the queries off the in-addr.arpa servers for a month, > >then result in timeouts from anything actually doing lookups - help > >get people to fix implementations or configurations to avoid the lookups > >in the first place. Unless you were planning to endow a fund that will cover the costs of operating the name servers needed to soak up the load for the lifetime of IPv4LL, please stop volunteering to spend other people's money coping with evil side effects of your protocol. From owner-zeroconf@merit.edu Tue May 3 07:54:59 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07656 for ; Tue, 3 May 2005 07:54:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8D6A1912B5; Tue, 3 May 2005 07:54:56 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58AD1912B8; Tue, 3 May 2005 07:54:56 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 69977912B5 for ; Tue, 3 May 2005 07:54:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9C43F58287; Tue, 3 May 2005 07:54:54 -0400 (EDT) Delivered-To: zeroconf@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 807E758282 for ; Tue, 3 May 2005 07:54:54 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 675A0185C; Tue, 3 May 2005 07:54:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by testbed9.merit.edu (Postfix) with ESMTP id 31A221827 for ; Tue, 3 May 2005 07:54:53 -0400 (EDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j43Bso4I620612 for ; Tue, 3 May 2005 07:54:50 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j43Bso5K218398 for ; Tue, 3 May 2005 05:54:50 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j43BsoLa018862 for ; Tue, 3 May 2005 05:54:50 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-202-204.mts.ibm.com [9.65.202.204]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j43Bsm3A018829; Tue, 3 May 2005 05:54:49 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id j43Bs3pj010260; Tue, 3 May 2005 13:54:04 +0200 Message-Id: <200505031154.j43Bs3pj010260@cichlid.raleigh.ibm.com> To: Rob Austein Cc: zeroconf@merit.edu Subject: Re: Proposed resolution: PTR queries for 254.169.in-addr.arpa In-Reply-To: Message from Rob Austein of "Sun, 01 May 2005 15:19:37 EDT." <20050501191937.F0BD441EA@thrintun.hactrn.net> Date: Tue, 03 May 2005 13:54:03 +0200 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Rob Austein writes: > Well, I thought we had a compromise, but Stuart appears to be having > second thoughts, so I guess we're back to square one. > At Fri, 29 Apr 2005 15:39:07 +0100, Stuart Cheshire wrote: > > > > >Recursive name servers MUST NOT allow these queries to > > >escape the local scope. Recursive name servers MAY reply > > >with RCODE 3, or they MAY silently discard the request. > > > > This text I have some reservations about. It suffers from the > > all-to-common disease that "we couldn't decide, so we'll agree to > > disagree". > Yes, it does. It should have just required recursive name servers to > reply with RCODE 3 rather than allowing them to drop queries silently, > but some of us were trying to be nice and compromise with those who > claim that silently dropping queries is better than answering them. I agree. Personally, I think we should just say that recursive servers MUST, by default, respond with RCODE=3. I can live with SHOULD, but if you read what SHOULD means in 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I do not see right off what "valid reason may exist" to do anything other than than RCODE=3 _as_ _a_ _default_. If there is such a reason, please remind me what it is. Thomas From owner-zeroconf@merit.edu Thu May 5 09:42:34 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27342 for ; Thu, 5 May 2005 09:42:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 772F29126E; Thu, 5 May 2005 09:42:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4CC4B91273; Thu, 5 May 2005 09:42:30 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 471A49126E for ; Thu, 5 May 2005 09:42:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 336EF5828D; Thu, 5 May 2005 09:42:29 -0400 (EDT) Delivered-To: zeroconf@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id E359C58282 for ; Thu, 5 May 2005 09:42:28 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id CA1D31853; Thu, 5 May 2005 09:42:28 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by testbed9.merit.edu (Postfix) with ESMTP id 9E73617FE for ; Thu, 5 May 2005 09:42:28 -0400 (EDT) Received: from mailgate2.apple.com (a17-128-100-204.apple.com [17.128.100.204]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j45DgSjY017228 for ; Thu, 5 May 2005 06:42:28 -0700 (PDT) Received: from relay3.apple.com (relay3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 5 May 2005 06:42:27 -0700 Received: from [17.219.197.72] ([17.219.197.72]) by relay3.apple.com (8.12.11/8.12.11) with SMTP id j45DgQc1023886 for ; Thu, 5 May 2005 06:42:27 -0700 (PDT) Message-Id: <200505051342.j45DgQc1023886@relay3.apple.com> Subject: Re: Proposed resolution: PTR queries for 254.169.in-addr.arpa Date: Thu, 5 May 2005 14:42:27 +0100 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 >> This text I have some reservations about. It suffers from the >> all-to-common disease that "we couldn't decide, so we'll agree to >> disagree". > >Yes, it does. It should have just required recursive name servers to >reply with RCODE 3 rather than allowing them to drop queries silently, >but some of us were trying to be nice and compromise with those who >claim that silently dropping queries is better than answering them. Thanks for being nice, but lets not let that get in the way of making a good specification. I'm the last person to want some kind of Pyrrhic victory ("sure the document sucks, but at least I got some of my words in it as one of the options"). The goal of silently dropping queries was to remove the ability for device vendors to use that as a crutch to justify why they don't need to fix their products not to send these bogus queries. (e.g. Customer reports a problem, and vendor replies, "RFC 3927 says that 'Recursive name servers MAY reply with RCODE 3', and the reason our product doesn't work is because you failed to follow the RFC and do that.") Having a MAY serves neither purpose -- we leave the DNS administrator and DNS vendors without clear instruction what to do, we burden the software and the user with yet more configuration options to learn and understand, and we provide a crutch for lazy device vendors who want to point to an alternative way to solve their timeout and delay problems, rather than changing their product. If we're going to allow name servers to return RCODE 3, we may as well require it, since lazy device vendors will. I'd rather have a good specification with parts I disagree with, than a vague waffly specification where everyone can read it a different way and thereby delude themselves into thinking they agree with what it says. Here is some proposed text. I don't like it and I don't agree with it, but at least it's clear and unambiguous, which is better than being vague for the sake of letting everyone think they got their way. A protocol specification is not complete when there are no more choices left to add; it is complete when there are no more choices left to take away. Mapping from IPv4 addresses to host names is conventionally done by issuing DNS queries for names of the form, "x.x.x.x.in-addr.arpa." When used for link-local addresses, which have significance only on the local link, it is inappropriate to send such DNS queries beyond the local link. DNS clients MUST NOT send unicast DNS queries for any name that falls within the "254.169.in-addr.arpa." domain. DNS caching servers receiving queries from non-compliant clients for names within the "254.169.in-addr.arpa." domain MUST return RCODE 3, authoritatively asserting that no such name exists in the unicast Domain Name System. >> Where is the evidence of an actual burden on local recursive >> name servers caused by these devices or their peers? > >Not being measured, or not being reported. Do you need every ISP in >the world to drop a book in their machine rooms to verify that the law >of gravity also applies in their location? Yes, but wouldn't it be nice if someone, somewhere had actually measured it, just once? Stuart Cheshire * Wizard Without Portfolio, Apple Computer, Inc. * www.stuartcheshire.org From owner-zeroconf@merit.edu Sun May 8 19:05:20 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10745 for ; Sun, 8 May 2005 19:05:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DEFAF91210; Sun, 8 May 2005 19:05:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0BBF91237; Sun, 8 May 2005 19:05:14 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B905091210 for ; Sun, 8 May 2005 19:05:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A646358296; Sun, 8 May 2005 19:05:13 -0400 (EDT) Delivered-To: zeroconf@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 8C5AF58295 for ; Sun, 8 May 2005 19:05:13 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 6FD81186D; Sun, 8 May 2005 19:05:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by testbed9.merit.edu (Postfix) with ESMTP id 36DB01869 for ; Sun, 8 May 2005 19:05:12 -0400 (EDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:250:daff:fe82:1c39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id CCC27E5 for ; Sun, 8 May 2005 19:05:11 -0400 (EDT) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 14C5641CE for ; Sun, 8 May 2005 19:05:11 -0400 (EDT) Date: Sun, 08 May 2005 19:05:10 -0400 From: Rob Austein To: zeroconf@merit.edu Subject: Re: Proposed resolution: PTR queries for 254.169.in-addr.arpa In-Reply-To: <200505051342.j45DgQc1023886@relay3.apple.com> References: <200505051342.j45DgQc1023886@relay3.apple.com> MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20050508230511.14C5641CE@thrintun.hactrn.net> Sender: owner-zeroconf@merit.edu Precedence: bulk At Thu, 5 May 2005 14:42:27 +0100, Stuart Cheshire wrote: > > Mapping from IPv4 addresses to host names is conventionally done > by issuing DNS queries for names of the form, > "x.x.x.x.in-addr.arpa." When used for link-local addresses, which > have significance only on the local link, it is inappropriate to > send such DNS queries beyond the local link. Ok. > DNS clients MUST NOT send unicast DNS queries for any name that > falls within the "254.169.in-addr.arpa." domain. Substantive: While I understand why you want to say "unicast" here, it doesn't work. First of all, you're leaving out anycast, which some people use. Secondly, the door you're trying to leave open is presumably for LLMNR (or mDNS if you prefer), which is a different protocol on a different port that just happens to reuse DNS data formats. I think it would be best just to drop "unicast" here; failing that (ie, if we can't agree that LLMNR is a different protocol), we'll have to qualify it by port number or something equally pedantic. > DNS caching servers receiving queries from non-compliant clients > for names within the "254.169.in-addr.arpa." domain MUST return > RCODE 3, authoritatively asserting that no such name exists in > the unicast Domain Name System. Nit: s/DNS caching servers/DNS recursive name servers/ Substantive: s/unicast// (see above). Substantive: s/MUST return RCODE 3/MUST return RCODE 3 by default/ I'd be willing to drop the last point, but in some cases (eg, on a typical corporate network) there most certainly is a site administrator, who might choose to populate a local reverse tree for 254.169.in-addr.arpa for reasons of his or her own -- none of our business, so long as it doesn't escape the local link. From owner-zeroconf@merit.edu Tue May 10 04:48:43 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29301 for ; Tue, 10 May 2005 04:48:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C8EB2912A8; Tue, 10 May 2005 04:46:50 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98392912AC; Tue, 10 May 2005 04:46:50 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7235B912A8 for ; Tue, 10 May 2005 04:46:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 601565828F; Tue, 10 May 2005 04:46:49 -0400 (EDT) Delivered-To: zeroconf@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 488005828A for ; Tue, 10 May 2005 04:46:49 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 2BC08188D; Tue, 10 May 2005 04:46:49 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by testbed9.merit.edu (Postfix) with ESMTP id 1B804188C for ; Tue, 10 May 2005 04:46:48 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.44) id 1DVQO8-000K2F-EJ for zeroconf@merit.edu; Tue, 10 May 2005 04:46:48 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4A8klx15735 for ; Tue, 10 May 2005 01:46:47 -0700 Date: Tue, 10 May 2005 01:46:47 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Re: Proposed resolution: PTR queries for 254.169.in-addr.arpa Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Sender: owner-zeroconf@merit.edu Precedence: bulk I agree with Rob's proposed changes. Here is the modified text: "Mapping from IPv4 addresses to host names is conventionally done by issuing DNS queries for names of the form, "x.x.x.x.in-addr.arpa." When used for link-local addresses, which have significance only on the local link, it is inappropriate to send such DNS queries beyond the local link. DNS clients MUST NOT send DNS queries for any name that falls within the "254.169.in-addr.arpa." domain. DNS recursive name servers receiving queries from non-compliant clients for names within the "254.169.in-addr.arpa." domain MUST by default return RCODE 3, authoritatively asserting that no such name exists in the Domain Name System." From owner-zeroconf@merit.edu Sat May 14 12:45:20 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16796 for ; Sat, 14 May 2005 12:45:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 33AE991207; Sat, 14 May 2005 12:45:02 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C82519123B; Sat, 14 May 2005 12:45:01 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 62D2D91207 for ; Sat, 14 May 2005 12:45:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4F46758296; Sat, 14 May 2005 12:45:00 -0400 (EDT) Delivered-To: zeroconf@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id 304FB58293 for ; Sat, 14 May 2005 12:45:00 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 167B11861; Sat, 14 May 2005 12:45:00 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by testbed9.merit.edu (Postfix) with ESMTP id 06DB71860 for ; Sat, 14 May 2005 12:44:59 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DWzl5-000EbM-4p for zeroconf@merit.edu; Sat, 14 May 2005 12:44:59 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4EGivu14937 for ; Sat, 14 May 2005 09:44:58 -0700 Date: Sat, 14 May 2005 09:44:57 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: Are we done yet? In-Reply-To: <41A7492E.4070801@sun.com> Message-ID: References: <41A7492E.4070801@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Sender: owner-zeroconf@merit.edu Precedence: bulk This is just to confirm that we have consensus on the following text: "Mapping from IPv4 addresses to host names is conventionally done by issuing DNS queries for names of the form, "x.x.x.x.in-addr.arpa." When used for link-local addresses, which have significance only on the local link, it is inappropriate to send such DNS queries beyond the local link. DNS clients MUST NOT send DNS queries for any name that falls within the "254.169.in-addr.arpa." domain. DNS recursive name servers receiving queries from non-compliant clients for names within the "254.169.in-addr.arpa." domain MUST by default return RCODE 3, authoritatively asserting that no such name exists in the Domain Name System." I would propose that this text be added to Section 1.4, as part of the following clause: Change: " To preclude use of IPv4 Link-Local addresses in off-link communication, the following cautionary measures are advised: a. IPv4 Link-Local addresses MUST NOT be configured in the DNS." To: " To preclude use of IPv4 Link-Local addresses in off-link communication, the following cautionary measures are advised: a. IPv4 Link-Local addresses MUST NOT be configured in the DNS. Mapping from IPv4 addresses to host names is conventionally done by issuing DNS queries for names of the form, "x.x.x.x.in-addr.arpa." When used for link-local addresses, which have significance only on the local link, it is inappropriate to send such DNS queries beyond the local link. DNS clients MUST NOT send DNS queries for any name that falls within the "254.169.in-addr.arpa." domain. DNS recursive name servers receiving queries from non-compliant clients for names within the "254.169.in-addr.arpa." domain MUST by default return RCODE 3, authoritatively asserting that no such name exists in the Domain Name System. " From owner-zeroconf@merit.edu Sun May 15 01:20:28 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10820 for ; Sun, 15 May 2005 01:20:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F2D9F91245; Sun, 15 May 2005 01:20:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C268C91263; Sun, 15 May 2005 01:20:26 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D0ED891245 for ; Sun, 15 May 2005 01:20:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BAF2A5828B; Sun, 15 May 2005 01:20:25 -0400 (EDT) Delivered-To: zeroconf@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id A3E705828A for ; Sun, 15 May 2005 01:20:25 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 8A0001883; Sun, 15 May 2005 01:20:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from parsley.amaranth.net (parsley.amaranth.net [204.10.1.23]) by testbed9.merit.edu (Postfix) with ESMTP id 6ED7A1870 for ; Sun, 15 May 2005 01:20:25 -0400 (EDT) Received: from ancho.senie.com (c-24-34-19-2.hsd1.ma.comcast.net [24.34.19.2]) (authenticated bits=0) by parsley.amaranth.net (8.12.11/8.12.11) with ESMTP id j4F5KKn1007482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 May 2005 01:20:21 -0400 Message-Id: <6.2.1.2.2.20050515011932.0504aca8@mail.amaranth.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 15 May 2005 01:20:02 -0400 To: Bernard Aboba , zeroconf@merit.edu From: Daniel Senie Subject: Re: Are we done yet? In-Reply-To: References: <41A7492E.4070801@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV version 0.85, clamav-milter version 0.85 on parsley.amaranth.net X-Virus-Status: Clean Sender: owner-zeroconf@merit.edu Precedence: bulk At 12:44 PM 5/14/2005, Bernard Aboba wrote: >This is just to confirm that we have consensus on the following text: This says it correctly by my reading. >"Mapping from IPv4 addresses to host names is conventionally done >by issuing DNS queries for names of the form, >"x.x.x.x.in-addr.arpa." When used for link-local addresses, which >have significance only on the local link, it is inappropriate to >send such DNS queries beyond the local link. >DNS clients MUST NOT send DNS queries for any name that >falls within the "254.169.in-addr.arpa." domain. > >DNS recursive name servers receiving queries from non-compliant clients >for names within the "254.169.in-addr.arpa." domain MUST by default return >RCODE 3, authoritatively asserting that no such name exists in >the Domain Name System." > >I would propose that this text be added to Section 1.4, as part of the >following clause: > >Change: > >" To preclude use of IPv4 Link-Local addresses in off-link > communication, the following cautionary measures are advised: > > > a. IPv4 Link-Local addresses MUST NOT be configured in the DNS." > >To: > >" To preclude use of IPv4 Link-Local addresses in off-link > communication, the following cautionary measures are advised: > > > a. IPv4 Link-Local addresses MUST NOT be configured in the DNS. > Mapping from IPv4 addresses to host names is conventionally done > by issuing DNS queries for names of the form, > "x.x.x.x.in-addr.arpa." When used for link-local addresses, which > have significance only on the local link, it is inappropriate to > send such DNS queries beyond the local link. > DNS clients MUST NOT send DNS queries for any name that > falls within the "254.169.in-addr.arpa." domain. > > DNS recursive name servers receiving queries from non-compliant > clients for names within the "254.169.in-addr.arpa." domain MUST by > default return RCODE 3, authoritatively asserting that no such name > exists in the Domain Name System. >" From owner-zeroconf@merit.edu Thu May 26 09:28:35 2005 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28212 for ; Thu, 26 May 2005 09:28:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A578C912AA; Thu, 26 May 2005 09:28:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CB23912F4; Thu, 26 May 2005 09:28:31 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4493E912AA for ; Thu, 26 May 2005 09:28:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EB3B65828E; Thu, 26 May 2005 09:28:29 -0400 (EDT) Delivered-To: zeroconf@segue.merit.edu Received: from testbed9.merit.edu (testbed9.merit.edu [198.108.1.10]) by segue.merit.edu (Postfix) with ESMTP id A680A58286 for ; Thu, 26 May 2005 09:28:29 -0400 (EDT) Received: by testbed9.merit.edu (Postfix) id 8C280188C; Thu, 26 May 2005 09:28:29 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by testbed9.merit.edu (Postfix) with ESMTP id 7537A1853 for ; Thu, 26 May 2005 09:28:29 -0400 (EDT) Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1DbIPU-000ERu-IQ for zeroconf@merit.edu; Thu, 26 May 2005 09:28:28 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j4QDSRq31290 for ; Thu, 26 May 2005 06:28:27 -0700 X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Thu, 26 May 2005 06:28:27 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: RFC 3927: now available in online RFC libraries Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk "Now it is done. Now the story ends. And there is no way to tell it. The art of fiction is dead. Reality has strangled invention. Only the utterly impossible, the inexpressibly fantastic, can ever be plausible again." -- Red Smith ----------------------------------------------------------------- RFC 3927 on Dynamic Configuration of IPv4 Link-Local Addresses A new Request for Comments is now available in online RFC libraries. RFC 3927 Title: Dynamic Configuration of IPv4 Link-Local Addresses Author(s): S. Cheshire, B. Aboba, E. Guttman Status: Standards Track Date: May 2005 Mailbox: rfc at stuartcheshire.org, bernarda at microsoft.com, erik at spybeam.org Pages: 33 Characters: 83102 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-zeroconf-ipv4-linklocal-17.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3927.txt To participate in wide-area IP networking, a host needs to be configured with IP addresses for its interfaces, either manually by the user or automatically from a source on the network such as a Dynamic Host Configuration Protocol (DHCP) server. Unfortunately, such address configuration information may not always be available. It is therefore beneficial for a host to be able to depend on a useful subset of IP networking functions even when no address configuration is available. This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link. IPv4 Link-Local addresses are not suitable for communication with devices not directly connected to the same physical (or logical) link, and are only used where stable, routable addresses are not available (such as on ad hoc or isolated networks). This document does not recommend that IPv4 Link-Local addresses and routable addresses be configured simultaneously on the same interface. This document is a product of the Zero Configuration Networking Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs.