From owner-dnsop@cafax.se Thu Jul 3 05:00:44 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02946 for ; Thu, 3 Jul 2003 05:00:43 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h638ahmb003344 for ; Thu, 3 Jul 2003 10:36:43 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h638ahsY003343 for dnsop-outgoing; Thu, 3 Jul 2003 10:36:43 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from mailout1.samsung.com ([203.254.224.24]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h638afmb003335 for ; Thu, 3 Jul 2003 10:36:42 +0200 (MEST) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HHF00401X8CZR@mailout1.samsung.com> for dnsop@cafax.se; Thu, 03 Jul 2003 17:36:12 +0900 (KST) Received: from ep_ms3_bk (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HHF0008VX8CD5@mailout1.samsung.com> for dnsop@cafax.se; Thu, 03 Jul 2003 17:36:12 +0900 (KST) Received: from ep_was16 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HHF00DRYX8B6S@ms3.samsung.com> for dnsop@cafax.se; Thu, 03 Jul 2003 17:36:11 +0900 (KST) Content-return: prohibited Date: Thu, 03 Jul 2003 17:36:09 +0900 From: =?EUC-KR?B?udq89sir?= Subject: When does we can meet the agenda of dnsop To: dnsop@cafax.se, dmm@sprint.net Reply-to: soohong.park@samsung.com Message-id: <0HHF00DRZX8B6S@ms3.samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20030703173609@soohong.park X-MTR: 20030703173609@soohong.park X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT Hi folks When does we can meet the agenda of dnsop ? David, can you let us know about the draft agenda ? Thanks Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics TEL:+82-31-200-4508 FAX:+82-31-200-3147 mailto:soohong.park@samsung.com #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 3 11:30:58 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16280 for ; Thu, 3 Jul 2003 11:30:56 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h63EvWmb007542 for ; Thu, 3 Jul 2003 16:57:32 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h63EvWKJ007541 for dnsop-outgoing; Thu, 3 Jul 2003 16:57:32 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h63EvTmb007536 for ; Thu, 3 Jul 2003 16:57:30 +0200 (MEST) Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h63EvhFN030311; Thu, 3 Jul 2003 07:57:43 -0700 Date: Thu, 3 Jul 2003 07:57:43 -0700 From: David Meyer To: =?iso-8859-1?Q?=B9=DA=BC=F6=C8=AB?= Cc: dnsop@cafax.se Subject: Re: When does we can meet the agenda of dnsop Message-ID: <20030703075743.A30308@1-4-5.net> References: <0HHF00DRZX8B6S@ms3.samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <0HHF00DRZX8B6S@ms3.samsung.com>; from soohong.park@samsung.com on Thu, Jul 03, 2003 at 05:36:09PM +0900 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: owner-dnsop@cafax.se Precedence: bulk >> When does we can meet the agenda of dnsop ? >> >> David, can you let us know about the draft agenda ? We're working on the agenda, hope to have it out early next week. Dave #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 3 18:18:49 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11350 for ; Thu, 3 Jul 2003 18:18:48 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h63Lsrmb012438 for ; Thu, 3 Jul 2003 23:54:53 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h63LsrV0012437 for dnsop-outgoing; Thu, 3 Jul 2003 23:54:53 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h63Lsqmb012432 for ; Thu, 3 Jul 2003 23:54:52 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19YC2U-000DXI-RS for dnsop@cafax.se; Thu, 03 Jul 2003 14:54:50 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 3 Jul 2003 14:54:50 -0700 To: dns op wg Subject: draft-warnicke-network-dns-resolution-02.txt Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit is dnsop tracking this? should the wg take responsibility for it, either as a wg document, if you like it and think it can be worked to become product. or as a "wg has reviewed this document and is in doubt that it is a useful idea." or whatever. randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 3 19:09:46 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21047 for ; Thu, 3 Jul 2003 19:09:45 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h63MpNmb013158 for ; Fri, 4 Jul 2003 00:51:24 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h63MpNbn013157 for dnsop-outgoing; Fri, 4 Jul 2003 00:51:23 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from stoneport.math.uic.edu (stoneport.math.uic.edu [131.193.178.160]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h63MpMmb013149 for ; Fri, 4 Jul 2003 00:51:22 +0200 (MEST) Received: (qmail 58515 invoked by uid 1016); 3 Jul 2003 22:51:53 -0000 Date: 3 Jul 2003 22:51:53 -0000 Message-ID: <20030703225153.58514.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-respsize-00.txt References: <200306191132.HAA09532@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-dnsop@cafax.se Precedence: bulk The notion that we're stuck at 13 servers is silly. For example: com NS a.gtld-servers.com com NS b.gtld-servers.com com NS c.gtld-servers.com com NS d.gtld-servers.com a.gtld-servers.com A ... a.gtld-servers.com A ... a.gtld-servers.com A ... a.gtld-servers.com A ... b.gtld-servers.com A ... b.gtld-servers.com A ... b.gtld-servers.com A ... b.gtld-servers.com A ... c.gtld-servers.com A ... c.gtld-servers.com A ... c.gtld-servers.com A ... c.gtld-servers.com A ... d.gtld-servers.com A ... d.gtld-servers.com A ... d.gtld-servers.com A ... d.gtld-servers.com A ... Another way to spread the load is to vary the IP addresses. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 3 23:14:17 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01477 for ; Thu, 3 Jul 2003 23:14:14 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h642mTmb016131 for ; Fri, 4 Jul 2003 04:48:29 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h642mT17016130 for dnsop-outgoing; Fri, 4 Jul 2003 04:48:29 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h642mRmb016125 for ; Fri, 4 Jul 2003 04:48:28 +0200 (MEST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 949201900 for ; Thu, 3 Jul 2003 22:48:26 -0400 (EDT) Date: Thu, 03 Jul 2003 22:48:26 -0400 From: Rob Austein To: dns op wg Subject: Re: draft-warnicke-network-dns-resolution-02.txt In-Reply-To: References: User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030704024826.949201900@thrintun.hactrn.net> Sender: owner-dnsop@cafax.se Precedence: bulk At Thu, 3 Jul 2003 14:54:50 -0700, Randy Bush wrote: > > is dnsop tracking this? should the wg take responsibility for it, > either as a wg document, if you like it and think it can be worked > to become product. or as a "wg has reviewed this document and is > in doubt that it is a useful idea." or whatever. I'd have to check my notes to be certain, but I think that the WG discussed this in San Francisco and decided not to make it a WG doc. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 3 23:33:17 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01922 for ; Thu, 3 Jul 2003 23:33:14 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h643Cxmb016325 for ; Fri, 4 Jul 2003 05:12:59 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h643Cw0Z016324 for dnsop-outgoing; Fri, 4 Jul 2003 05:12:58 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h643Cvmb016319 for ; Fri, 4 Jul 2003 05:12:58 +0200 (MEST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 134CC18EA for ; Thu, 3 Jul 2003 23:12:57 -0400 (EDT) Date: Thu, 03 Jul 2003 23:12:57 -0400 From: Rob Austein To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-respsize-00.txt In-Reply-To: <20030703225153.58514.qmail@cr.yp.to> References: <200306191132.HAA09532@ietf.org> <20030703225153.58514.qmail@cr.yp.to> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030704031257.134CC18EA@thrintun.hactrn.net> Sender: owner-dnsop@cafax.se Precedence: bulk At 3 Jul 2003 22:51:53 -0000, Daniel J. Bernstein wrote: > > The notion that we're stuck at 13 servers is silly. For example: > > com NS a.gtld-servers.com > com NS b.gtld-servers.com > com NS c.gtld-servers.com > com NS d.gtld-servers.com > a.gtld-servers.com A ... > a.gtld-servers.com A ... > a.gtld-servers.com A ... > a.gtld-servers.com A ... > b.gtld-servers.com A ... > b.gtld-servers.com A ... > b.gtld-servers.com A ... > b.gtld-servers.com A ... > c.gtld-servers.com A ... > c.gtld-servers.com A ... > c.gtld-servers.com A ... > c.gtld-servers.com A ... > d.gtld-servers.com A ... > d.gtld-servers.com A ... > d.gtld-servers.com A ... > d.gtld-servers.com A ... This has been suggested before, and it's an appealing idea, but it assumes that resolvers will try every address of every listed server. RFC 1035 is, unfortunately, not entirely consistant about this: some parts of the resolver description talk about putting all of the addresses of all of the listed name servers into the SLIST, but others talk about removing a "name server" (as opposed to one its addresses) from the SLIST. So there's an open question as to whether a resolver should treat your example as 16 distinct addresses to try, or should treat it as four name servers to try; one could find support for either choice in the spec. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Jul 4 11:41:55 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29943 for ; Fri, 4 Jul 2003 11:41:54 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h64FEEmb022886 for ; Fri, 4 Jul 2003 17:14:14 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h64FEDCo022885 for dnsop-outgoing; Fri, 4 Jul 2003 17:14:13 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from stoneport.math.uic.edu (stoneport.math.uic.edu [131.193.178.160]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h64FE7mb022880 for ; Fri, 4 Jul 2003 17:14:12 +0200 (MEST) Received: (qmail 24721 invoked by uid 1016); 4 Jul 2003 15:14:38 -0000 Date: 4 Jul 2003 15:14:38 -0000 Message-ID: <20030704151438.24720.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: dnsop@cafax.se Subject: Re: I-D ACTION:draft-ietf-dnsop-respsize-00.txt References: <200306191132.HAA09532@ietf.org> <20030703225153.58514.qmail@cr.yp.to> <20030704031257.134CC18EA@thrintun.hactrn.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-dnsop@cafax.se Precedence: bulk Rob Austein writes: > This has been suggested before, and it's an appealing idea, but it > assumes that resolvers will try every address of every listed server. No. No widely deployed program tries _every_ address; there are always limits. But if you try the 4x4 strategy (which still has quite a bit of room in the UDP packet) then you'll see that the load is spread quite evenly across 16 servers. The other strategy can't do better than 13. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sat Jul 5 17:24:24 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16839 for ; Sat, 5 Jul 2003 17:24:23 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h65KrXmb005042 for ; Sat, 5 Jul 2003 22:53:33 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h65KrXFS005041 for dnsop-outgoing; Sat, 5 Jul 2003 22:53:33 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from momotombo.TechFak.Uni-Bielefeld.DE (momotombo.TechFak.Uni-Bielefeld.DE [129.70.136.107]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h65KrWmb005035 for ; Sat, 5 Jul 2003 22:53:32 +0200 (MEST) Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.137.40]) by momotombo.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.11.6/TechFak/2003/04/16/pk) with ESMTP id h65KrQQ17555; Sat, 5 Jul 2003 22:53:26 +0200 (MEST) Received: from localhost (pk@localhost) by grimsvotn.TechFak.Uni-Bielefeld.DE (8.11.7+Sun/8.9.1) with SMTP id h65KrQ025078; Sat, 5 Jul 2003 22:53:26 +0200 (MEST) Message-Id: <200307052053.h65KrQ025078@grimsvotn.TechFak.Uni-Bielefeld.DE> X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk owned process doing -bs X-Authentication-Warning: grimsvotn.TechFak.Uni-Bielefeld.DE: pk@localhost didn't use HELO protocol To: DNSOP WG Cc: Edward Warnicke Subject: Re: draft-warnicke-network-dns-resolution-02.txt In-reply-to: Your message of "Thu, 03 Jul 2003 22:48:26 EDT." <20030704024826.949201900@thrintun.hactrn.net> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25075.1057438399.1@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Sat, 05 Jul 2003 22:53:24 +0200 From: Peter Koch Sender: owner-dnsop@cafax.se Precedence: bulk Rob Austein wrote > I'd have to check my notes to be certain, but I think that the WG > discussed this in San Francisco and decided not to make it a WG doc. not having been in San Francisco I do not know what the decision(oops?) was based upon, but here are some comments and more detailed remarks below: While I'd agree that it would be nice to have an updated version of RFC 1101, i'm not sure I understand the problem the draft really tries to address. From what i guess it does, the solution IMHO seems too complicated to work in practice. Additional information regarding the motivation of this kind of solution would be welcome. As an example: Is the proposed algorithm intended to be processed from inside the particular network or from the outside? If the latter, then why? The proposed method should support the address of the 'first hop router', but there's nothing in the draft that restricts the algorithm to this problem domain. It's broad enough to be applied to other services, which is OK on the one hand, but on the other it means that here's another approach to the service location problem. DNS is not really the best approach to locally scoped service location. So, it's not clear to me why the problem is tried to be solved via DNS in the first place. For the algorithm to work, the asking system needs to contact a resolver, i.e. it needs to know that system's address (unless link local name resolution is used). Also, it needs an IP address and a working interface, usually including a subnet mask (unless the local environment supports proxy ARP). So, why does the system need to determine the/a router's address? And even if it needs that address, why would it have to first find the subnet mask? What about using DHCP? Finally, due to the way the intermediate names are constructed, the suggested algorithm would need too many additional zones, at least domain names, including some, which can only be instantiated with cooperation from upper level zones. IMHO this is affords too much interaction to be used "out there". So, finally, based on the information currently available I'd agree that the draft not be adopted by the WG. An update of RFC 1101 would be interesting, though. Please find more detailed comments below (quoting from the draft). -Peter ............................................................................. > host. It would be useful to have a standard mechanism for such > a host to find the first-hop router(s). If such host could be instructed to contact a particular resolver, why can't it be told the address of it's router? > DNS-based mechanisms have been defined for the resolution of router > addresses for classful networks (RFC 1035 [1]) and of subnets (RFC Is that "A" records? Otherwise I can't see what RFC 1035 does to answer this particular question. > network. This RFC also specifies an extension to the method of RFC > 2317 to support delegation at non-octet boundaries. RFC 2317 doesn't need this extension, because in the case the prefix length is less than 24, you'd just delegate and populate a separate zone per octet. You'll cover a single "network" by multiple zones, but that doesn't matter. And that practice pre-dates RFC 2317. So, the problem is: ``given an IP address, find "the" first hop router for that address'' Who is to ask that question? I guess it's the system itself, but then, why would it be necessary to answer that question by means of DNS instead of, say, DHCP? > networkdomainname = maskedoctet "." *( decimaloctet / maskedoctet ".") > ".in-addr.arpa." That should read "in-addr.arpa". The first "." is already provided by the other rule elements. The last is unnecessary because domain names don't end in dots. > decimaloctet = ( *1("1") DIGIT DIGIT ) / > ( "2" ( "1" / "2" / "3" / "4" ) DIGIT ) / > ( "2" "5" ( "1" / "2" /"3" / "4" / "5" ) ) An element covering a single DIGIT is missing, and this rule would allow a leading zero in e.g. "00". Either the rule would have to be extended or the restrictions could be dealt within a comment (see definition of "IPv4-address-literal" in RFC 2821. > A "-" is used as a delimiter in a maskedoctet instead of a "/" as in > RFC 2317 out of concern about compatibility with existing DNS > servers, many of which do not consider "/" to be a valid character in > a hostname. That's not a matter of the server's opinion. On the other hand, it's only relevant if address records have to be associated with a name (i.e., it's really a hostname). That's not the case in this draft, so "/" could be used (but see below). > In RFC 2317 there is no mechanism for non-octet boundary delegation. And that's not necessary there, see above. > 1. Take the initial IP address x.y.z.w and create a candidate > network by assuming a 24 bit subnet mask. Thus the initial > candidate network is x.y.z.0/24. Why doesn't the system know the subnet mask for this interface? Is it supposed to be multihomed? > 4. If the PTR records returned from looking up the candidate domain > name are of the form of a domain name for a network as defined > previously (Section 2), then for each PTR record reduce that > returned domain name to the canonical form > p1-q1.z1.y1.x1.in-addr.arpa. This represents a network > x1.y1.z.1.p1/q1. ~~~ Delete dot ----/ > 1. If no candidate network PTR lookup for this IP address has > succeeded in the past and the netmask for the last candidate What does the term "in the past" mean in this context? Is the system supposed to keep state across multiple invocations of this algorithm? > 2. If no candidate network PTR lookup for this IP address has > succeeded in the past and the netmask for the last candidate > network was not 24 of 16 bits long, then increase the netmask s/of/or/; > 4.2 Example [...] > 7. Lookup the PTR records for 0-16.15.10.in-addr.arpa. > 8. Lookup returns: > > 1. 0-17.15.10.in-addr.arpa. > 2. 128-18.15.10.in-addr.arpa. > 3. 192-18.15.10.in-addr.arpa. Obviously you need the cooperation of and interaction with the maintainer of the /16 for this to work. That might even be an RIR! > 0-17.15.10.in-addr.arpa. IN NS 10.15.0.50 > 128-18.15.10.in-addr.arpa. IN NS 10.15.128.50 > 192-18.15.10.in-addr.arpa. IN NS 10.15.192.50 The single NS RR per zone is due to brevity, I guess; but IP addresses should not be used in the RDATA. It violates the protocol and although the intention is almost obvious, errors like this are too easily copied. > In entity B's DNS zone files: > > ;; provide entries for the subnets of 10.15.128.0/18 > > 128-18.15.10.in-addr.arpa. IN PTR 128-19.128-18.15.10.in-addr.arpa. > 128-18.15.10.in-addr.arpa. IN PTR 0-25.160.128-18.15.10.in-addr.arpa. > 128-18.15.10.in-addr.arpa. IN PTR \ > 128-25.160.128-18.15.10.in-addr.arpa. > 128-18.15.10.in-addr.arpa. IN PTR 0-24.161.128-18.15.10.in-addr.arpa. > 128-18.15.10.in-addr.arpa. IN PTR 162-23.128-18.15.10.in-addr.arpa. > The list is incomplete. 10.15.128/18 was further split into 10.15.128/19 an others, so you also need entries for "128-19.15.10.in-addr.arpa" and more. So, the /16 reverse maintainer is again to be involved. I'd expect some operational difficulties with this scheme. Instead one could try to make the prefix part of the hierarchy, i.e. "/18.128.15.10.in-addr.arpa". An APL RR might be more efficient than a large PTR RRSet. > ;; provide entries pointing to non in-addr.arpa hostnames for > ;; terminal network > 162-23.128-18.15.10.in-addr.arpa. IN PTR gw1.example.com. > 162-23.128-18.15.10.in-addr.arpa. IN PTR gw2.example.com. Why are these owner names not reduced? _end_ #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sat Jul 5 20:29:20 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20818 for ; Sat, 5 Jul 2003 20:29:19 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6603dmb006488 for ; Sun, 6 Jul 2003 02:03:39 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6603dNr006487 for dnsop-outgoing; Sun, 6 Jul 2003 02:03:39 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6603cmb006482 for ; Sun, 6 Jul 2003 02:03:38 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19Yx0B-000894-8j; Sat, 05 Jul 2003 17:03:35 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 5 Jul 2003 17:03:34 -0700 To: Peter Koch Cc: DNSOP WG , Edward Warnicke Subject: Re: draft-warnicke-network-dns-resolution-02.txt References: <20030704024826.949201900@thrintun.hactrn.net> <200307052053.h65KrQ025078@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit >> I'd have to check my notes to be certain, but I think that the WG >> discussed this in San Francisco and decided not to make it a WG doc. > not having been in San Francisco I do not know what the decision(oops?) > was based upon, but here are some comments and more detailed remarks > below: > ... > So, finally, based on the information currently available I'd agree that > the draft not be adopted by the WG. An update of RFC 1101 would be > interesting, though. what i would most appreciate is one of o a statement by the wg that this is being taken on as a work item o a statement by the wg that this is NOT being taken on as a work item, but the wg has no problem with its publication as info o a statement by the wg that this should not be published for some stated set of reasons, or that it could be published but with a warning (text included). randy, just tryin' to process a document #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 7 18:13:15 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19389 for ; Mon, 7 Jul 2003 18:13:14 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h67Lm5mb028831 for ; Mon, 7 Jul 2003 23:48:05 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h67Lm5OC028830 for dnsop-outgoing; Mon, 7 Jul 2003 23:48:05 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h67Lm4mb028824 for ; Mon, 7 Jul 2003 23:48:04 +0200 (MEST) Received: from esunmail ([129.147.58.120]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h67Lm21J026564 for ; Mon, 7 Jul 2003 15:48:03 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HHO00E6WCK2I9@edgemail1.Central.Sun.COM> for dnsop@cafax.se; Mon, 07 Jul 2003 15:48:02 -0600 (MDT) Received: from sun.com ([129.146.15.19]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HHO00LCYCK1OO@mail.sun.net> for dnsop@cafax.se; Mon, 07 Jul 2003 15:48:02 -0600 (MDT) Date: Mon, 07 Jul 2003 14:48:01 -0700 From: Alain Durand Subject: Re: draft-warnicke-network-dns-resolution-02.txt To: Randy Bush Cc: DNSOP WG , Edward Warnicke Message-id: <3F09EA91.2020203@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <20030704024826.949201900@thrintun.hactrn.net> <200307052053.h65KrQ025078@grimsvotn.TechFak.Uni-Bielefeld.DE> Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT Randy Bush wrote: > > >what i would most appreciate is one of > o a statement by the wg that this is being taken on as a work item > o a statement by the wg that this is NOT being taken on as a work > item, but the wg has no problem with its publication as info > o a statement by the wg that this should not be published for some > stated set of reasons, or that it could be published but with a > warning (text included). > >randy, just tryin' to process a document > >#---------------------------------------------------------------------- ># To unsubscribe, send a message to . > > Speaking as a wg participant: This document only talks about IPv4 and address issues that are key for IPv6 and are beeing addressed by the wg in the general discussion on reverse DNS for IPv6. Thus I would recommend against the publication of this document in its current form. - Alain. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 8 00:05:59 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25978 for ; Tue, 8 Jul 2003 00:05:58 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h683kkmb002530 for ; Tue, 8 Jul 2003 05:46:46 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h683kkdx002529 for dnsop-outgoing; Tue, 8 Jul 2003 05:46:46 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h683kdmb002524 for ; Tue, 8 Jul 2003 05:46:44 +0200 (MEST) Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h683kP7F014556; Mon, 7 Jul 2003 20:46:26 -0700 (PDT) Received: from eaw-u5.cisco.com (eaw-u5.cisco.com [64.102.39.24]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGG73544; Mon, 7 Jul 2003 20:46:24 -0700 (PDT) Date: Mon, 7 Jul 2003 23:46:24 -0400 (EDT) From: Edward Warnicke To: Peter Koch cc: DNSOP WG Subject: Re: draft-warnicke-network-dns-resolution-02.txt In-Reply-To: <200307052053.h65KrQ025078@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: References: <200307052053.h65KrQ025078@grimsvotn.TechFak.Uni-Bielefeld.DE> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk Peter, Would this make more sense if I were to point out that I screwed up the last edit of the last sentence of paragraph 1 in the Introduction. It reads: "It would be useful to have a standard mechanism for such a host to find the first-hop router(s)." The implication is that a host would be using the method of the draft to look up information about itself. This is incorrect. Rather that sentence should be replaced by: "It may be necessary for a third party server in the network to request some service related to the host from the first-hop router(s) for that host. It would be useful to have a standard mechanism for such a server to find the first-hop router(s)" The application I'd originally written the draft to deal with was identification of the first-hop router as the intercept access point for Lawful Intercept ( wiretapping ). The intention is *not* for a host to use this method to discover anything, but rather for *other* servers in the network to use this method to be able to discover the IP address of the first-hop router(s) so that they may request some service from the first-hop router(s) related to the host. Some method of identifying the intercept access point is necessary for Lawful Intercept. Does the above change in language clear up some of the confusion? More comments inline... On Sat, 5 Jul 2003, Peter Koch wrote: > Rob Austein wrote > While I'd agree that it would be nice to have an updated version of RFC 1101, > i'm not sure I understand the problem the draft really tries to address. > From what i guess it does, the solution IMHO seems too complicated to work > in practice. Additional information regarding the motivation of this kind > of solution would be welcome. The initial motivation for this draft was that I encountered some attempts to use RFC 1101 to allow identification of the first-hop router(s) for a host in order to request Lawful Intercept services ( wiretapping ) of the host by the first-hop router(s). > Finally, due to the way the intermediate names are constructed, the > suggested algorithm would need too many additional zones, at least domain > names, including some, which can only be instantiated with cooperation > from upper level zones. IMHO this is affords too much interaction to be > used "out there". Cooperation of the upstream zones will sometimes be necessary, but care has been taken to limit the amount of cooperation needed. > > So, finally, based on the information currently available I'd agree that the > draft not be adopted by the WG. An update of RFC 1101 would be interesting, > though. > > Please find more detailed comments below (quoting from the draft). > > -Peter > > ............................................................................. > > > > host. It would be useful to have a standard mechanism for such > > a host to find the first-hop router(s). > > If such host could be instructed to contact a particular resolver, why > can't it be told the address of it's router? See comment above about this being an error introduced in the most recent edit. This is *not* a method for a host to discover anything about itself, but rather a method for other servers in the network to discover the first-hop router(s) of a host. > > > DNS-based mechanisms have been defined for the resolution of router > > addresses for classful networks (RFC 1035 [1]) and of subnets (RFC > > Is that "A" records? Otherwise I can't see what RFC 1035 does to answer > this particular question. I was mostly refering to RFC 1035 section 3.5 paragraphs 5,6, and 8. > > > network. This RFC also specifies an extension to the method of RFC > > 2317 to support delegation at non-octet boundaries. > > RFC 2317 doesn't need this extension, because in the case the prefix length > is less than 24, you'd just delegate and populate a separate zone per octet. > You'll cover a single "network" by multiple zones, but that doesn't matter. > And that practice pre-dates RFC 2317. You are correct RFC 2317 doesn't need this extension for it's application because it is dealing with using PTR records to map from an IP number to a hostname ( the hostname of that IP address ). For my application I need to be able to cleanly delegate on non-octet boundaries in aggregate. > > So, the problem is: ``given an IP address, find "the" first hop router for > that address'' > Who is to ask that question? I guess it's the system itself, but then, > why would it be necessary to answer that question by means of DNS instead > of, say, DHCP? Some other server in the network is asking this question, like a mediation device seeking to start a tap on a host using the hosts first hop gateway. > > > networkdomainname = maskedoctet "." *( decimaloctet / maskedoctet ".") > > ".in-addr.arpa." > > That should read "in-addr.arpa". The first "." is already provided by the > other rule elements. The last is unnecessary because domain names don't end > in dots. You are correct. I will fix the error. > > > decimaloctet = ( *1("1") DIGIT DIGIT ) / > > ( "2" ( "1" / "2" / "3" / "4" ) DIGIT ) / > > ( "2" "5" ( "1" / "2" /"3" / "4" / "5" ) ) > > An element covering a single DIGIT is missing, and this rule would allow a > leading zero in e.g. "00". Either the rule would have to be extended or > the restrictions could be dealt within a comment (see definition of > "IPv4-address-literal" in RFC 2821. You are correct. I will fix the error ( thanks for the pointer to 2821 :) > > > A "-" is used as a delimiter in a maskedoctet instead of a "/" as in > > RFC 2317 out of concern about compatibility with existing DNS > > servers, many of which do not consider "/" to be a valid character in > > a hostname. > > That's not a matter of the server's opinion. On the other hand, it's only > relevant if address records have to be associated with a name (i.e., it's > really a hostname). That's not the case in this draft, so "/" could be > used (but see below). Browsing lightly through the source for bind 8.3.0 it looks like the rdata associated with ptr records is judged OK or not by ns_nameok as being of context hostname_ctx, which causes it to drop through to res_hnok, which checks the hostname in such a way as to allow allow alphachar, digitchar, and hyphenchar, but not "/". Perhaps I'm misreading ( I only browsed lightly ), but it looks like there is some potential for confusing bind 8.3 with RDATA for a PTR record that contains a "/". Would I rather use the "/" character? Yes. But I wasn't willing to risk issues with DNS implementations over the issue. > > > In RFC 2317 there is no mechanism for non-octet boundary delegation. > > And that's not necessary there, see above. > > > 1. Take the initial IP address x.y.z.w and create a candidate > > network by assuming a 24 bit subnet mask. Thus the initial > > candidate network is x.y.z.0/24. > > Why doesn't the system know the subnet mask for this interface? Is it > supposed to be multihomed? Again, the host knows it's subnet, another server in the network needs to look it up. My fault for causing this confusion. > > > 4. If the PTR records returned from looking up the candidate domain > > name are of the form of a domain name for a network as defined > > previously (Section 2), then for each PTR record reduce that > > returned domain name to the canonical form > > p1-q1.z1.y1.x1.in-addr.arpa. This represents a network > > x1.y1.z.1.p1/q1. > ~~~ > Delete dot ----/ You are correct again, I will correct the error. > > > 1. If no candidate network PTR lookup for this IP address has > > succeeded in the past and the netmask for the last candidate > > What does the term "in the past" mean in this context? Is the system > supposed to keep state across multiple invocations of this algorithm? No. In the past means as part of the same lookup process. The resolution of the IP address of the first-hop router for a host may span multiple DNS lookups. The algorithm *does* require maintaining state across multiple DNS lookups, but not across multiple first-hop router resolutions. > > > 2. If no candidate network PTR lookup for this IP address has > > succeeded in the past and the netmask for the last candidate > > network was not 24 of 16 bits long, then increase the netmask > > s/of/or/; You are correct. I will fix the error. > > > 4.2 Example > > [...] > > > 7. Lookup the PTR records for 0-16.15.10.in-addr.arpa. > > 8. Lookup returns: > > > > 1. 0-17.15.10.in-addr.arpa. > > 2. 128-18.15.10.in-addr.arpa. > > 3. 192-18.15.10.in-addr.arpa. > > Obviously you need the cooperation of and interaction with the maintainer of > the /16 for this to work. That might even be an RIR! Yes, you will need the cooperation of your upstream zone. Care was taken to minimize the number of entries the upstream DNS would need to provide, and to limit the churn of those records. > > > 0-17.15.10.in-addr.arpa. IN NS 10.15.0.50 > > 128-18.15.10.in-addr.arpa. IN NS 10.15.128.50 > > 192-18.15.10.in-addr.arpa. IN NS 10.15.192.50 > > The single NS RR per zone is due to brevity, I guess; but IP addresses > should not be used in the RDATA. It violates the protocol and although > the intention is almost obvious, errors like this are too easily copied. You are correct that the single NS is for brevity. You are correct that I used the incorrect RDATA type for the NS record. I will fix the error. > > > In entity B's DNS zone files: > > > > ;; provide entries for the subnets of 10.15.128.0/18 > > > > 128-18.15.10.in-addr.arpa. IN PTR 128-19.128-18.15.10.in-addr.arpa. > > 128-18.15.10.in-addr.arpa. IN PTR 0-25.160.128-18.15.10.in-addr.arpa. > > 128-18.15.10.in-addr.arpa. IN PTR \ > > 128-25.160.128-18.15.10.in-addr.arpa. > > 128-18.15.10.in-addr.arpa. IN PTR 0-24.161.128-18.15.10.in-addr.arpa. > > 128-18.15.10.in-addr.arpa. IN PTR 162-23.128-18.15.10.in-addr.arpa. > > > > The list is incomplete. 10.15.128/18 was further split into 10.15.128/19 > an others, so you also need entries for "128-19.15.10.in-addr.arpa" and more. > So, the /16 reverse maintainer is again to be involved. I'd expect some > operational difficulties with this scheme. Instead one could try to make the > prefix part of the hierarchy, i.e. "/18.128.15.10.in-addr.arpa". > An APL RR might be more efficient than a large PTR RRSet. Actually... the list is not incomplete here ( although it is further on ). The 10.15.128/19 and others are subnetted from the 10.15.128/18 and therefore are *not* the concern of the owner of the 10.15/16. The 10.15/16 doesn't need to know anything about the way the 10.15.128/18 is subnetted, because any RR for that subnetting will be off of the 128-18.15.10.in-addr.arpa. shim domain. You see this in the entry: 128-18.15.10.in-addr.arpa. IN PTR 128-19.128-18.15.10.in-addr.arpa. where the 10.15.128/19 subnet is represented by the 128-19.128-18.15.10.in-addr.arpa. domain name. For reasons of brevity I did not show the RR for 128-19.128-18.15.10.in-addr.arpa. in entity B's DNS tables as it isn't pursued further in the example. > > > ;; provide entries pointing to non in-addr.arpa hostnames for > > ;; terminal network > > 162-23.128-18.15.10.in-addr.arpa. IN PTR gw1.example.com. > > 162-23.128-18.15.10.in-addr.arpa. IN PTR gw2.example.com. > > Why are these owner names not reduced? The names aren't reduced because that would require more work on behalf of the 10.15/16 owner. 162-23.15.10.in-addr.arpa. would require more RR entries be made by the 10.15/16 owner. As you've pointed out ( correctly ) this is likely to make them grumpy :) That's why the shim zone is used. It also means that if the owner of the 10.15.128/18 owner changes their subnetting it makes no difference in what the upstream provider needs in their DNS tables. I put a fair bit of thought into reducing the number of RR entries the upstream provider would need to provision, and into reducing the need for the upstream provider to change those entries if the subnetting of the delegated network changed. In the current scheme, when an upstream provider delegates a network downstream, they would have to create: 1 PTR record entry for the delegating network ( 0-16.15.10.in-addr.arpa. IN PTR 128-18.15.10.in-addr.arpa. ) 1 or more NS records for the shim domain ( 128-18.15.10.in-addr.arpa. IN NS ns1.example.net ) 0 or more glue records for the NS records So delegating a network requires 1 + n + m where n is the number of NS for the shim domain and m is the number of needed glue records. Thank you very much for taking the time to provide such a detailed critique, it has been quite helpful. Hopefully I've answered ( or acknowledged ) your criticism adequately. If not, let me know. Ed > > _end_ > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 8 04:02:45 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13400 for ; Tue, 8 Jul 2003 04:02:44 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h687btmb004259 for ; Tue, 8 Jul 2003 09:37:55 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h687btDW004258 for dnsop-outgoing; Tue, 8 Jul 2003 09:37:55 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h687bnmb004249 for ; Tue, 8 Jul 2003 09:37:49 +0200 (MEST) Received: from [192.168.0.3] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h687artg023453; Tue, 8 Jul 2003 03:37:45 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: <200307052053.h65KrQ025078@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Tue, 8 Jul 2003 10:35:17 +0300 To: Edward Warnicke From: Brad Knowles Subject: Re: draft-warnicke-network-dns-resolution-02.txt Cc: Peter Koch , DNSOP WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 11:46 PM -0400 2003/07/07, Edward Warnicke wrote: > The application I'd originally written the draft to deal with was > identification of the first-hop router as the intercept access point > for Lawful Intercept ( wiretapping ). The intention is *not* for > a host to use this method to discover anything, but rather for > *other* servers in the network to use this method to be able to > discover the IP address of the first-hop router(s) so that they may > request some service from the first-hop router(s) related to the host. > Some method of identifying the intercept access point is necessary > for Lawful Intercept. For a purely US-only application, or for an application where the source country, target country, and all intervening countries have similar laws, I think that might potentially be a valid use. However, in the modern Internet, I don't think that really has much application. I don't think anyone is about to do anything that would allow anyone else to request that their router provide arbitrary "lawful intercept" services for some unknown party in some other country. Who knows when this kind of information might be used for corporate or gov't espionage, or frequently and casually abused by people with the necessary access, who probably don't even have to be real law enforcement officers, regardless of how corrupt the police department may be? And if you can't get broad adoption of this sort of feature, then what possible use could it serve? I'm sorry. Given what we've learned so far about this, I would argue most vehemently that we should do everything within our power to actively kill this proposal, and not just decide whether or not to passively fail to support it. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 8 09:18:31 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20717 for ; Tue, 8 Jul 2003 09:18:30 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h68Cphmb007223 for ; Tue, 8 Jul 2003 14:51:43 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h68CphFi007222 for dnsop-outgoing; Tue, 8 Jul 2003 14:51:43 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h68Cpamb007217 for ; Tue, 8 Jul 2003 14:51:42 +0200 (MEST) Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h68CpMpp002435; Tue, 8 Jul 2003 05:51:23 -0700 (PDT) Received: from eaw-u5.cisco.com (eaw-u5.cisco.com [64.102.39.24]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGH78536; Tue, 8 Jul 2003 05:51:22 -0700 (PDT) Date: Tue, 8 Jul 2003 08:51:22 -0400 (EDT) From: Edward Warnicke To: Brad Knowles cc: Peter Koch , DNSOP WG Subject: Re: draft-warnicke-network-dns-resolution-02.txt In-Reply-To: Message-ID: References: <200307052053.h65KrQ025078@grimsvotn.TechFak.Uni-Bielefeld.DE> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk I seem to have miscommunicated. I am in no way suggesting that a router provide arbitrary "lawful intercept" services for some unknown party in some other country. Please see http://www.ietf.org/internet-drafts/draft-baker-slem-architecture-01.txt You may also find the previous thread on this draft informative: http://www.cafax.se/dnsop/maillist/2003-02/msg00058.html Ed On Tue, 8 Jul 2003, Brad Knowles wrote: > At 11:46 PM -0400 2003/07/07, Edward Warnicke wrote: > > > The application I'd originally written the draft to deal with was > > identification of the first-hop router as the intercept access point > > for Lawful Intercept ( wiretapping ). The intention is *not* for > > a host to use this method to discover anything, but rather for > > *other* servers in the network to use this method to be able to > > discover the IP address of the first-hop router(s) so that they may > > request some service from the first-hop router(s) related to the host. > > Some method of identifying the intercept access point is necessary > > for Lawful Intercept. > > For a purely US-only application, or for an application where the > source country, target country, and all intervening countries have > similar laws, I think that might potentially be a valid use. > > However, in the modern Internet, I don't think that really has > much application. I don't think anyone is about to do anything that > would allow anyone else to request that their router provide > arbitrary "lawful intercept" services for some unknown party in some > other country. > > Who knows when this kind of information might be used for > corporate or gov't espionage, or frequently and casually abused by > people with the necessary access, who probably don't even have to be > real law enforcement officers, regardless of how corrupt the police > department may be? > > > And if you can't get broad adoption of this sort of feature, then > what possible use could it serve? > > > I'm sorry. Given what we've learned so far about this, I would > argue most vehemently that we should do everything within our power > to actively kill this proposal, and not just decide whether or not to > passively fail to support it. > > -- > Brad Knowles, > > "They that can give up essential liberty to obtain a little temporary > safety deserve neither liberty nor safety." > -Benjamin Franklin, Historical Review of Pennsylvania. > > GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ > !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) > tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 8 12:02:14 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28651 for ; Tue, 8 Jul 2003 12:02:05 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h68FXvmb008914 for ; Tue, 8 Jul 2003 17:33:57 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h68FXv0L008913 for dnsop-outgoing; Tue, 8 Jul 2003 17:33:57 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h68FXumb008908 for ; Tue, 8 Jul 2003 17:33:57 +0200 (MEST) Received: from [192.168.0.3] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h68FXdtW054804; Tue, 8 Jul 2003 11:33:53 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: References: <200307052053.h65KrQ025078@grimsvotn.TechFak.Uni-Bielefeld.DE> Date: Tue, 8 Jul 2003 18:32:58 +0300 To: Edward Warnicke From: Brad Knowles Subject: Re: draft-warnicke-network-dns-resolution-02.txt Cc: Brad Knowles , Peter Koch , DNSOP WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 8:51 AM -0400 2003/07/08, Edward Warnicke wrote: > I seem to have miscommunicated. I am in no way suggesting that a router > provide arbitrary "lawful intercept" services for some unknown > party in some other country. Please see > http://www.ietf.org/internet-drafts/draft-baker-slem-architecture-01.txt Okay, fair enough. But if you want to get wide availability of this feature, you have to give people a reason to actively want to provide this information. Since many sites may not have fully secured their routers, if they identify the first hop router for each netblock they own, then there is the risk that people will make a stronger and more concerted attack on that router, perhaps trying to subvert or abuse features that may have been included and turned on by default. IMO, this is like revisiting the whole WKS idea all over again. In the early days of the Internet, that was good. But in the modern days where publishing any additional information about your system may result in an increased security exposure, I just can't see something like this being broadly useful or widely adopted. Moreover, I see this opening up whole new cans of worms that I don't think we want to even think about. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 8 17:29:02 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11215 for ; Tue, 8 Jul 2003 17:29:01 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h68L08mb012683 for ; Tue, 8 Jul 2003 23:00:08 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h68L08Z7012682 for dnsop-outgoing; Tue, 8 Jul 2003 23:00:08 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h68L05mb012677 for ; Tue, 8 Jul 2003 23:00:06 +0200 (MEST) Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h68L0JO6003963; Tue, 8 Jul 2003 14:00:19 -0700 Date: Tue, 8 Jul 2003 14:00:19 -0700 From: David Meyer To: agenda@ietf.org Cc: dnsop@cafax.se Subject: Domain Name System Operations (dnsop) WG Agenda for IETF 57 (Vienna) Message-ID: <20030708140019.A3954@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: owner-dnsop@cafax.se Precedence: bulk Domain Name System Operations Working Group (dnsop) =================================================== MONDAY, July 14, 2003 1530-1730 (Hall NO) Chairs: David Meyer Rob Austein Draft Agenda ------------ Agenda Bashing 5 minutes Meyer/all Status of outstanding drafts 10 minutes Meyer/Austein (i). Farewell to drafts this WG doesn't need to think about anymore draft-ietf-dnsop-hardie-shared-root-server-07.txt draft-ietf-dnsop-v6-name-space-fragmentation-02.txt draft-ihren-dnsop-interim-signed-root-02.txt draft-ihren-dnsop-v6-name-space-fragment-01.txt (ii). WG drafts which are ready for last call draft-ietf-dnsop-ipv6-transport-guidelines-00.txt draft-ietf-dnsop-serverid-01.txt (?) (iii). Active WG drafts draft-ietf-dnsop-bad-dns-res-01.txt draft-ietf-dnsop-inaddr-required-04.txt draft-ietf-dnsop-interim-signed-root-01.txt draft-ietf-dnsop-ipv6-dns-issues-02.txt draft-ietf-dnsop-ohta-shared-root-server-02.txt draft-ietf-dnsop-respsize-00.txt draft-ietf-dnsop-serverid-01.txt [unless handled in (ii). above] (iv). Expired WG drafts draft-ietf-dnsop-dontpublish-unreachable-03.txt draft-ietf-dnsop-keyhand-04.txt draft-ietf-dnsop-resolver-rollover-00.txt draft-ietf-dnsop-rollover-01.txt (v). Active individual drafts draft-durand-dnsop-dynreverse-00.txt draft-hall-dns-data-03.txt draft-jeong-ipv6-ra-dns-autoconf-00.txt draft-kato-dnsop-local-zones-00.txt draft-morishita-dnsop-misbehavior-against-aaaa-00.txt draft-park-ipv6-extensions-dns-pnp-00.txt draft-warnicke-network-dns-resolution-02.txt draft-yasuhiro-dnsop-increasing-dns-server-00.txt IPv6 DNS Discovery -- Framing the discussion 15 minutes Rob Austein IPv6 DNS Discovery, and why it is important 10 minutes Bob Hinden IPv6 Router Advertisement based DNS Autoconfiguration 10 minutes draft-jeong-ipv6-ra-dns-autoconf-00.txt Jaehoon Jeong IPv6 Router Advertisement DNS resolver Option 10 minutes draft-beloeil-ipv6-dns-resolver-option-01.txt Luc Beloeil Discussion 20 minutes A Suggested Scheme for DNS Resolution of Networks and Gateways 10 minutes draft-warnicke-network-dns-resolution-02.txt Edward Warnicke Considerations for DNS Resource Records 10 minutes draft-hall-dns-data-03.txt Eric Hall IPv6 Extensions for DNS Plug and Play 10 minutes draft-park-ipv6-extensions-dns-pnp-00.txt Syam Madanapalli Outstanding issues in draft-ietf-dnsop-ipv6-dns-issues-02.txt 10 minutes Alain Durand #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 9 14:58:50 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14561 for ; Wed, 9 Jul 2003 14:58:48 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h69IHjmb025834 for ; Wed, 9 Jul 2003 20:17:45 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h69IHj6B025833 for dnsop-outgoing; Wed, 9 Jul 2003 20:17:45 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h69IHhmb025828 for ; Wed, 9 Jul 2003 20:17:43 +0200 (MEST) Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h69IHbro019504; Wed, 9 Jul 2003 11:17:40 -0700 (PDT) Received: from cisco.com (dhcp-64-102-59-70.cisco.com [64.102.59.70]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AGL77433; Wed, 9 Jul 2003 11:17:35 -0700 (PDT) Message-ID: <3F0C5B65.9030109@cisco.com> Date: Wed, 09 Jul 2003 14:13:57 -0400 From: Ed Warnicke User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030618 Debian/1.3.1-3 X-Accept-Language: en MIME-Version: 1.0 To: Brad Knowles CC: Peter Koch , DNSOP WG Subject: Re: draft-warnicke-network-dns-resolution-02.txt References: <200307052053.h65KrQ025078@grimsvotn.TechFak.Uni-Bielefeld.DE> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Brad Knowles wrote: > At 8:51 AM -0400 2003/07/08, Edward Warnicke wrote: > >> I seem to have miscommunicated. I am in no way suggesting that a >> router >> provide arbitrary "lawful intercept" services for some unknown >> party in some other country. Please see >> http://www.ietf.org/internet-drafts/draft-baker-slem-architecture-01.txt > > > Okay, fair enough. But if you want to get wide availability of > this feature, you have to give people a reason to actively want to > provide this information. True. In the Lawful Intercept application there are legal requirements that the network owner provide wire tapping services ( usually when presented with a warrant, your local laws may vary ). This requirement can be fulfilled in a number of ways, but clearly service providers would like to comply with legal requirements in the least expensive possible way. Many of the mediation devices that provide the intelligence behind doing the tapping will be supplied by third party vendors. If these third party vendors must integrate their mediation devices separately to the OSS system of each service provider to obtain information about the first-hop router(s) this could be quite expensive. If the mediation device vendors can integrate against a particular use of the existing DNS system, this should be much less expensive. If it saves service providers money, they will implement it. If it doesn't they won't. Likewise, if other applications arise, if they are compelling to the parties in a position to implement the draft it will be implemented, otherwise it won't. > > Since many sites may not have fully secured their routers, if they > identify the first hop router for each netblock they own, then there > is the risk that people will make a stronger and more concerted attack > on that router, perhaps trying to subvert or abuse features that may > have been included and turned on by default. > This is a good point, and one that has been brought up before. There are ways of controlling the distribution of RR from a particular edge network if the network owner is concerned. I also mentioned this issue in the Security Considerations section of the draft. Ed #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 9 18:52:56 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27687 for ; Wed, 9 Jul 2003 18:52:54 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h69MCMmb028644 for ; Thu, 10 Jul 2003 00:12:22 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h69MCMHs028643 for dnsop-outgoing; Thu, 10 Jul 2003 00:12:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h69MCKmb028638 for ; Thu, 10 Jul 2003 00:12:21 +0200 (MEST) Received: from [192.168.0.3] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h69MBjte001009; Wed, 9 Jul 2003 18:12:17 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <3F0C5B65.9030109@cisco.com> References: <200307052053.h65KrQ025078@grimsvotn.TechFak.Uni-Bielefeld.DE> <3F0C5B65.9030109@cisco.com> Date: Thu, 10 Jul 2003 02:11:03 +0400 To: Ed Warnicke From: Brad Knowles Subject: Re: draft-warnicke-network-dns-resolution-02.txt Cc: Brad Knowles , Peter Koch , DNSOP WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 2:13 PM -0400 2003/07/09, Ed Warnicke wrote: > This requirement > can be fulfilled in a number of ways, but clearly service providers > would like to comply with legal requirements in the least expensive > possible way. Note that there are many facets to the term "expensive" in this context. We can only address a small subset of them, and I believe that there are other factors which are dominant but on which we cannot have any impact. > If the mediation device vendors can > integrate against a particular use of the existing DNS system, > this should be much less expensive. Not true. At least, not entirely true. What you really need is a standard. But that standard doesn't necessarily have to have anything whatsoever to do with the DNS. Until you can convince me that there is no other possible way that this issue can be addressed (other than using the DNS), you're going to have an uphill battle. Moreover, since we're talking about a mechanism that would be pretty much purely dictated by the US gov't, I think you would find very strong opposition to incorporating anything remotely related to it into an International standard protocol, such as the DNS. > This is a good point, and one that has been brought up before. There > are ways of controlling the distribution of RR from a particular edge > network if the network owner is concerned. I also mentioned this issue > in the Security Considerations section of the draft. Sorry, I don't buy this for a moment. There are way, way too many nameservers out there that are public recursive/caching nameservers which could be abused to provide this sort of information to external parties. Moreover, not only are these nameservers configured in such a way as to allow this information to escape, they are also vulnerable to cache pollution and poisoning, which could be far, far worse in the context of anyone actually depending on the information returned by these machines for law enforcement purposes, and where real lives could literally be on the line. You're talking about relying on a "security mechanism" that is leaky enough to allow entire galaxies to pass through, and probably even small universes. You've got to have something better that can't be simply blown out of the water by a single poorly set up nameserver, or a small collection of poorly set up nameservers. Of course, probably something like 99% of all nameservers are public recursive/caching and vulnerable to cache pollution/poisoning. Certainly, my own survey of the gTLD, ccTLD, and root nameservers indicates that over 50% of all the ccTLD, gTLD, and root nameservers are open public recursive/caching nameservers, affecting almost 80% of all the TLDs in the world (see ). And these are supposedly the best-run nameservers in the world. What is the rest of the world like? -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 10 20:49:20 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28518 for ; Thu, 10 Jul 2003 20:49:19 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6B08Wmb015092 for ; Fri, 11 Jul 2003 02:08:32 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6B08WY0015091 for dnsop-outgoing; Fri, 11 Jul 2003 02:08:32 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from mailout3.samsung.com ([203.254.224.33]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6B08Tmb015083 for ; Fri, 11 Jul 2003 02:08:30 +0200 (MEST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HHU0060130D6F@mailout3.samsung.com> for dnsop@cafax.se; Fri, 11 Jul 2003 09:07:25 +0900 (KST) Received: from ep_mmp1 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HHU00IDJ30CGZ@mailout3.samsung.com> for dnsop@cafax.se; Fri, 11 Jul 2003 09:07:24 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HHU00MCZ30CJE@mmp1.samsung.com> for dnsop@cafax.se; Fri, 11 Jul 2003 09:07:24 +0900 (KST) Date: Fri, 11 Jul 2003 09:07:39 +0900 From: Soohong Daniel Park Subject: RE: Domain Name System Operations (dnsop) WG Agenda for IETF 57 (Vienna) In-reply-to: <20030708140019.A3954@1-4-5.net> To: "'David Meyer'" , agenda@ietf.org Cc: dnsop@cafax.se Message-id: <000a01c34740$70c65130$b7cbdba8@daniel7209> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT Hi David The agenda of dnsop looks good. As you made this agenda, dnsop has to discuss DNS autoconfiguration scheme deeply with plenty time at this meeting. Also I believe that dnsop should take some drafts as working item during this meeting. Of course, we should make a consensus at dnsop WG. Thanks and I look forward to meeting you and all attendees on Monday. Daniel (Soohong Daniel Park) Mobile Platform Lab,SAMSUNG Electronics -----Original Message----- From: owner-dnsop@cafax.se [mailto:owner-dnsop@cafax.se] On Behalf Of David Meyer Sent: Wednesday, July 09, 2003 6:00 AM To: agenda@ietf.org Cc: dnsop@cafax.se Subject: Domain Name System Operations (dnsop) WG Agenda for IETF 57 (Vienna) Domain Name System Operations Working Group (dnsop) =================================================== MONDAY, July 14, 2003 1530-1730 (Hall NO) Chairs: David Meyer Rob Austein Draft Agenda ------------ Agenda Bashing 5 minutes Meyer/all Status of outstanding drafts 10 minutes Meyer/Austein (i). Farewell to drafts this WG doesn't need to think about anymore draft-ietf-dnsop-hardie-shared-root-server-07.txt draft-ietf-dnsop-v6-name-space-fragmentation-02.txt draft-ihren-dnsop-interim-signed-root-02.txt draft-ihren-dnsop-v6-name-space-fragment-01.txt (ii). WG drafts which are ready for last call draft-ietf-dnsop-ipv6-transport-guidelines-00.txt draft-ietf-dnsop-serverid-01.txt (?) (iii). Active WG drafts draft-ietf-dnsop-bad-dns-res-01.txt draft-ietf-dnsop-inaddr-required-04.txt draft-ietf-dnsop-interim-signed-root-01.txt draft-ietf-dnsop-ipv6-dns-issues-02.txt draft-ietf-dnsop-ohta-shared-root-server-02.txt draft-ietf-dnsop-respsize-00.txt draft-ietf-dnsop-serverid-01.txt [unless handled in (ii). above] (iv). Expired WG drafts draft-ietf-dnsop-dontpublish-unreachable-03.txt draft-ietf-dnsop-keyhand-04.txt draft-ietf-dnsop-resolver-rollover-00.txt draft-ietf-dnsop-rollover-01.txt (v). Active individual drafts draft-durand-dnsop-dynreverse-00.txt draft-hall-dns-data-03.txt draft-jeong-ipv6-ra-dns-autoconf-00.txt draft-kato-dnsop-local-zones-00.txt draft-morishita-dnsop-misbehavior-against-aaaa-00.txt draft-park-ipv6-extensions-dns-pnp-00.txt draft-warnicke-network-dns-resolution-02.txt draft-yasuhiro-dnsop-increasing-dns-server-00.txt IPv6 DNS Discovery -- Framing the discussion 15 minutes Rob Austein IPv6 DNS Discovery, and why it is important 10 minutes Bob Hinden IPv6 Router Advertisement based DNS Autoconfiguration 10 minutes draft-jeong-ipv6-ra-dns-autoconf-00.txt Jaehoon Jeong IPv6 Router Advertisement DNS resolver Option 10 minutes draft-beloeil-ipv6-dns-resolver-option-01.txt Luc Beloeil Discussion 20 minutes A Suggested Scheme for DNS Resolution of Networks and Gateways 10 minutes draft-warnicke-network-dns-resolution-02.txt Edward Warnicke Considerations for DNS Resource Records 10 minutes draft-hall-dns-data-03.txt Eric Hall IPv6 Extensions for DNS Plug and Play 10 minutes draft-park-ipv6-extensions-dns-pnp-00.txt Syam Madanapalli Outstanding issues in draft-ietf-dnsop-ipv6-dns-issues-02.txt 10 minutes Alain Durand #---------------------------------------------------------------------- # To unsubscribe, send a message to . #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 02:39:11 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28071 for ; Mon, 14 Jul 2003 02:39:09 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6E6Dbmb022997 for ; Mon, 14 Jul 2003 08:13:37 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6E6DbYo022996 for dnsop-outgoing; Mon, 14 Jul 2003 08:13:37 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from sith.maoz.com (sith.maoz.com [205.167.76.10]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6E6DZmb022991 for ; Mon, 14 Jul 2003 08:13:35 +0200 (MEST) Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h6E6Dkhk010266; Sun, 13 Jul 2003 23:13:46 -0700 Date: Sun, 13 Jul 2003 23:13:46 -0700 From: David Meyer To: Soohong Daniel Park Cc: agenda@ietf.org, dnsop@cafax.se Subject: Re: Domain Name System Operations (dnsop) WG Agenda for IETF 57 (Vienna) Message-ID: <20030713231346.A10259@1-4-5.net> References: <20030708140019.A3954@1-4-5.net> <000a01c34740$70c65130$b7cbdba8@daniel7209> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <000a01c34740$70c65130$b7cbdba8@daniel7209>; from soohong.park@samsung.com on Fri, Jul 11, 2003 at 09:07:39AM +0900 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: owner-dnsop@cafax.se Precedence: bulk Thanks Daniel. On Fri, Jul 11, 2003 at 09:07:39AM +0900, Soohong Daniel Park wrote: >> Hi David >> >> The agenda of dnsop looks good. >> As you made this agenda, dnsop has to discuss >> DNS autoconfiguration scheme deeply with plenty time >> at this meeting. Also I believe that dnsop should take >> some drafts as working item during this meeting. >> Of course, we should make a consensus at dnsop WG. >> Thanks and I look forward to meeting you and all attendees >> on Monday. >> >> >> >> Daniel (Soohong Daniel Park) >> Mobile Platform Lab,SAMSUNG Electronics >> >> >> >> >> -----Original Message----- >> From: owner-dnsop@cafax.se [mailto:owner-dnsop@cafax.se] On Behalf Of >> David Meyer >> Sent: Wednesday, July 09, 2003 6:00 AM >> To: agenda@ietf.org >> Cc: dnsop@cafax.se >> Subject: Domain Name System Operations (dnsop) WG Agenda for IETF 57 >> (Vienna) >> >> >> >> Domain Name System Operations Working Group (dnsop) >> =================================================== >> >> MONDAY, July 14, 2003 1530-1730 (Hall NO) >> >> Chairs: David Meyer >> Rob Austein >> >> Draft Agenda >> ------------ >> >> Agenda Bashing 5 >> minutes >> Meyer/all >> >> Status of outstanding drafts 10 >> minutes >> Meyer/Austein >> >> (i). Farewell to drafts this WG doesn't need to think about anymore >> draft-ietf-dnsop-hardie-shared-root-server-07.txt >> draft-ietf-dnsop-v6-name-space-fragmentation-02.txt >> draft-ihren-dnsop-interim-signed-root-02.txt >> draft-ihren-dnsop-v6-name-space-fragment-01.txt >> >> (ii). WG drafts which are ready for last call >> draft-ietf-dnsop-ipv6-transport-guidelines-00.txt >> draft-ietf-dnsop-serverid-01.txt (?) >> >> (iii). Active WG drafts >> draft-ietf-dnsop-bad-dns-res-01.txt >> draft-ietf-dnsop-inaddr-required-04.txt >> draft-ietf-dnsop-interim-signed-root-01.txt >> draft-ietf-dnsop-ipv6-dns-issues-02.txt >> draft-ietf-dnsop-ohta-shared-root-server-02.txt >> draft-ietf-dnsop-respsize-00.txt >> draft-ietf-dnsop-serverid-01.txt [unless handled in (ii). above] >> >> (iv). Expired WG drafts >> draft-ietf-dnsop-dontpublish-unreachable-03.txt >> draft-ietf-dnsop-keyhand-04.txt >> draft-ietf-dnsop-resolver-rollover-00.txt >> draft-ietf-dnsop-rollover-01.txt >> >> (v). Active individual drafts >> draft-durand-dnsop-dynreverse-00.txt >> draft-hall-dns-data-03.txt >> draft-jeong-ipv6-ra-dns-autoconf-00.txt >> draft-kato-dnsop-local-zones-00.txt >> draft-morishita-dnsop-misbehavior-against-aaaa-00.txt >> draft-park-ipv6-extensions-dns-pnp-00.txt >> draft-warnicke-network-dns-resolution-02.txt >> draft-yasuhiro-dnsop-increasing-dns-server-00.txt >> >> IPv6 DNS Discovery -- Framing the discussion 15 >> minutes >> Rob Austein >> >> IPv6 DNS Discovery, and why it is important 10 >> minutes >> Bob Hinden >> >> IPv6 Router Advertisement based DNS Autoconfiguration 10 >> minutes >> draft-jeong-ipv6-ra-dns-autoconf-00.txt >> Jaehoon Jeong >> >> IPv6 Router Advertisement DNS resolver Option 10 >> minutes >> draft-beloeil-ipv6-dns-resolver-option-01.txt >> Luc Beloeil >> >> Discussion 20 >> minutes >> >> A Suggested Scheme for DNS Resolution of Networks and Gateways 10 >> minutes >> draft-warnicke-network-dns-resolution-02.txt >> Edward Warnicke >> >> Considerations for DNS Resource Records 10 >> minutes >> draft-hall-dns-data-03.txt >> Eric Hall >> >> IPv6 Extensions for DNS Plug and Play 10 >> minutes >> draft-park-ipv6-extensions-dns-pnp-00.txt >> Syam Madanapalli >> >> Outstanding issues in draft-ietf-dnsop-ipv6-dns-issues-02.txt 10 >> minutes >> Alain Durand >> >> >> >> #---------------------------------------------------------------------- >> # To unsubscribe, send a message to . #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 05:06:16 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02926 for ; Mon, 14 Jul 2003 05:06:14 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6E8hSmb024403 for ; Mon, 14 Jul 2003 10:43:28 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6E8hSbC024402 for dnsop-outgoing; Mon, 14 Jul 2003 10:43:28 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from web10001.mail.yahoo.com (web10001.mail.yahoo.com [216.136.130.37]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6E8hQmb024397 for ; Mon, 14 Jul 2003 10:43:27 +0200 (MEST) Message-ID: <20030714084325.83736.qmail@web10001.mail.yahoo.com> Received: from [81.160.243.20] by web10001.mail.yahoo.com via HTTP; Mon, 14 Jul 2003 01:43:25 PDT Date: Mon, 14 Jul 2003 01:43:25 -0700 (PDT) From: Jaehoon Jeong Subject: IPv6 DNS Autoconfiguration To: dnsop@cafax.se MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-dnsop@cafax.se Precedence: bulk Hi, DNSOP members! :-) Beforehand, I'd like to summarize my talk for today's discussion about DNS Discovery and Autoconfiguration. I'll present IPv6 DNS autoconfiguration today afternoon. IPv6 DNS autoconfiguration consists of two functions; a) RA-based DNS Discovery and b) Host DNS Name Auto-Registration. Through RA DNS option, IPv6 host can find out DNS information, such as Recursive DNS Servers' addresses and DNS Zone Suffix. It is very simple and necessary mechanism, I think. With the announced DNS zone suffix, IPv6 host can generate its host DNS name based on its preferred user-ID. Also, it can register its DNS name and IPv6 address with the announced DNS server, through DNS dynamic update. The registration is performed by the IPv6 host, not another Registrar. In my scheme, any unidentified host can register its DNS information in advertised DNS server. To minimize the damage of DNS dynamic update, I define a new flag, AR (Auto-Registration), in Header section of DNS dynamic update message. This bit indicates that any host can add its AAAA/PTR resource records in DNS server and modifiy or delete only its resource records, not others' resource records. Therefore, a little extension to DNS Dynamic Update is necessary. You can find my presentation material in the following links; http://www.adhoc.6ants.net/~paul/data/ietf57-dnsop-ipv6-ra-dns-autoconf-00.pdf http://www.adhoc.6ants.net/~paul/data/ietf57-dnsop-ipv6-ra-dns-autoconf-00.ppt I would like to know if DNS autoconfiguration should consider both DNS discovery and Host DNS name auto-registration or not, namely separate documents. In today's talks, I hope, some drafts about DNS autoconfiguration will be accepted as working items. Thanks. /Jaehoon (Paul) __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 05:32:32 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03775 for ; Mon, 14 Jul 2003 05:32:30 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6E9EXmb024703 for ; Mon, 14 Jul 2003 11:14:33 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6E9EXig024702 for dnsop-outgoing; Mon, 14 Jul 2003 11:14:33 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6E9EWmb024697 for ; Mon, 14 Jul 2003 11:14:32 +0200 (MEST) Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA15287 for ; Mon, 14 Jul 2003 10:14:31 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id KAA13098 for ; Mon, 14 Jul 2003 10:14:31 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6E9EVC13850 for dnsop@cafax.se; Mon, 14 Jul 2003 10:14:31 +0100 Date: Mon, 14 Jul 2003 10:14:31 +0100 From: Tim Chown To: dnsop@cafax.se Subject: Re: IPv6 DNS Autoconfiguration Message-ID: <20030714091431.GP12067@login.ecs.soton.ac.uk> Mail-Followup-To: dnsop@cafax.se References: <20030714084325.83736.qmail@web10001.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030714084325.83736.qmail@web10001.mail.yahoo.com> User-Agent: Mutt/1.4i Sender: owner-dnsop@cafax.se Precedence: bulk Hi, It's good to see a DNS discovery method for a statelessly autoconfiguring network back on the table. I think the two functions should be in separate documents. It would be nice to push through the DNS discovery method, and not have it dependent on the registration aspect (which many hosts will not need). Tim On Mon, Jul 14, 2003 at 01:43:25AM -0700, Jaehoon Jeong wrote: > Hi, DNSOP members! :-) > Beforehand, I'd like to summarize my talk for today's > discussion about DNS Discovery and Autoconfiguration. > > I'll present IPv6 DNS autoconfiguration today > afternoon. > IPv6 DNS autoconfiguration consists of two functions; > a) RA-based DNS Discovery and b) Host DNS Name > Auto-Registration. > > Through RA DNS option, IPv6 host can find out DNS > information, such as Recursive DNS Servers' addresses > and DNS Zone Suffix. > It is very simple and necessary mechanism, I think. > With the announced DNS zone suffix, IPv6 host can > generate its host DNS name based on its preferred > user-ID. Also, it can register its DNS name and IPv6 > address with the announced DNS server, through DNS > dynamic update. > The registration is performed by the IPv6 host, not > another Registrar. > In my scheme, any unidentified host can register its > DNS information in advertised DNS server. To minimize > the damage of DNS dynamic update, I define a new flag, > AR (Auto-Registration), in Header section of DNS > dynamic update message. > This bit indicates that any host can add its AAAA/PTR > resource records in DNS server and modifiy or delete > only its resource records, not others' resource > records. Therefore, a little extension to DNS Dynamic > Update is necessary. > You can find my presentation material in the following > links; > > http://www.adhoc.6ants.net/~paul/data/ietf57-dnsop-ipv6-ra-dns-autoconf-00.pdf > > > http://www.adhoc.6ants.net/~paul/data/ietf57-dnsop-ipv6-ra-dns-autoconf-00.ppt > > I would like to know if DNS autoconfiguration should > consider both DNS discovery and Host DNS name > auto-registration or not, namely separate documents. > In today's talks, I hope, some drafts about DNS > autoconfiguration will be accepted as working items. > Thanks. > > /Jaehoon (Paul) > > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 07:10:56 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08602 for ; Mon, 14 Jul 2003 07:10:54 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EAotmb025667 for ; Mon, 14 Jul 2003 12:50:55 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6EAot1L025666 for dnsop-outgoing; Mon, 14 Jul 2003 12:50:55 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from mailout2.samsung.com ([203.254.224.25]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EAormb025661 for ; Mon, 14 Jul 2003 12:50:54 +0200 (MEST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HI00060DGSIX4@mailout2.samsung.com> for dnsop@cafax.se; Mon, 14 Jul 2003 19:50:42 +0900 (KST) Received: from ep_ms3_bk (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HI000MUMGSFFG@mailout2.samsung.com> for dnsop@cafax.se; Mon, 14 Jul 2003 19:50:40 +0900 (KST) Received: from ep_was20 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HI000D4VGSFW7@ms3.samsung.com> for dnsop@cafax.se; Mon, 14 Jul 2003 19:50:39 +0900 (KST) Content-return: prohibited Date: Mon, 14 Jul 2003 19:50:40 +0900 From: =?EUC-KR?B?udq89sir?= Subject: Re: Re: IPv6 DNS Autoconfiguration To: Tim Chown Cc: dnsop@cafax.se Reply-to: soohong.park@samsung.com Message-id: <0HI000D4WGSFW7@ms3.samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20030714195040@soohong.park X-MTR: 20030714195040@soohong.park X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT >Hi, >It's good to see a DNS discovery method for a statelessly autoconfiguring >network back on the table. It will be deeply discussed at today meeting. >I think the two functions should be in separate documents. It would be nice >to push through the DNS discovery method, and not have it dependent on the >registration aspect (which many hosts will not need). So. two kinds of drafts will be discussed such as 1) IPv6 DNS Discovery aspect 2) IPv6 DNS Autoregistration aspect Also above aspects can be merged into one document I guess. Let's discuss at today meeting Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics TEL:+82-31-200-4508 FAX:+82-31-200-3147 mailto:soohong.park@samsung.com #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 09:24:47 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18588 for ; Mon, 14 Jul 2003 09:24:44 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6ECuimb026720 for ; Mon, 14 Jul 2003 14:56:44 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6ECuiiI026719 for dnsop-outgoing; Mon, 14 Jul 2003 14:56:44 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from web10001.mail.yahoo.com (web10001.mail.yahoo.com [216.136.130.37]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6ECugmb026714 for ; Mon, 14 Jul 2003 14:56:43 +0200 (MEST) Message-ID: <20030714125642.32801.qmail@web10001.mail.yahoo.com> Received: from [81.160.243.20] by web10001.mail.yahoo.com via HTTP; Mon, 14 Jul 2003 05:56:42 PDT Date: Mon, 14 Jul 2003 05:56:42 -0700 (PDT) From: Jaehoon Jeong Subject: Re: Re: IPv6 DNS Autoconfiguration To: soohong.park@samsung.com, Tim Chown Cc: dnsop@cafax.se In-Reply-To: <0HI000D4WGSFW7@ms3.samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-dnsop@cafax.se Precedence: bulk I agree with Daniel's thought. DNS Discovery and Auto-registration can be handled either in a single document or two separate documents. The important thing is to decide if RA-based approach for DNS discovery is selected as dnsop item or not. During the open discussion, I believe, it will be decided. :-) /Jaehoon --- Daniel wrote: > > > >Hi, > > >It's good to see a DNS discovery method for a > statelessly autoconfiguring > >network back on the table. > > It will be deeply discussed at today meeting. > > >I think the two functions should be in separate > documents. It would be nice > >to push through the DNS discovery method, and not > have it dependent on the > >registration aspect (which many hosts will not > need). > > So. two kinds of drafts will be discussed such as > > 1) IPv6 DNS Discovery aspect > 2) IPv6 DNS Autoregistration aspect > > Also above aspects can be merged into one document I > guess. > > Let's discuss at today meeting > > > > > > > > Daniel (Soohong Daniel Park) > Mobile Platform Lab. Samsung Electronics > TEL:+82-31-200-4508 FAX:+82-31-200-3147 > mailto:soohong.park@samsung.com > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 09:28:25 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18894 for ; Mon, 14 Jul 2003 09:28:24 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6ED5Smb026861 for ; Mon, 14 Jul 2003 15:05:28 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6ED5SwK026860 for dnsop-outgoing; Mon, 14 Jul 2003 15:05:28 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6ED5Rmb026855 for ; Mon, 14 Jul 2003 15:05:27 +0200 (MEST) Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA21800 for ; Mon, 14 Jul 2003 14:05:27 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id OAA20445 for ; Mon, 14 Jul 2003 14:05:26 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6ED5Qk17530 for dnsop@cafax.se; Mon, 14 Jul 2003 14:05:26 +0100 Date: Mon, 14 Jul 2003 14:05:26 +0100 From: Tim Chown To: dnsop@cafax.se Subject: Re: Re: IPv6 DNS Autoconfiguration Message-ID: <20030714130526.GO15664@login.ecs.soton.ac.uk> Mail-Followup-To: dnsop@cafax.se References: <0HI000D4WGSFW7@ms3.samsung.com> <20030714125642.32801.qmail@web10001.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030714125642.32801.qmail@web10001.mail.yahoo.com> User-Agent: Mutt/1.4i Sender: owner-dnsop@cafax.se Precedence: bulk On Mon, Jul 14, 2003 at 05:56:42AM -0700, Jaehoon Jeong wrote: > I agree with Daniel's thought. > DNS Discovery and Auto-registration can be handled > either in a single document or two separate documents. > The important thing is to decide if RA-based approach > for DNS discovery is selected as dnsop item or not. > During the open discussion, I believe, it will be > decided. :-) Yes, this is key :) Tim #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 10:51:03 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26554 for ; Mon, 14 Jul 2003 10:51:02 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EEScmb027779 for ; Mon, 14 Jul 2003 16:28:38 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6EEScHi027778 for dnsop-outgoing; Mon, 14 Jul 2003 16:28:38 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EESZmb027773 for ; Mon, 14 Jul 2003 16:28:36 +0200 (MEST) From: Masataka Ohta Message-Id: <200307141420.XAA01347@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id XAA01347; Mon, 14 Jul 2003 23:19:58 +0859 Subject: Re: IPv6 DNS Autoconfiguration In-Reply-To: <20030714084325.83736.qmail@web10001.mail.yahoo.com> from Jaehoon Jeong at "Jul 14, 2003 01:43:25 am" To: Jaehoon Jeong Date: Mon, 14 Jul 2003 23:19:57 +0859 () CC: dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk Jaehoon; > Beforehand, I'd like to summarize my talk for today's > discussion about DNS Discovery and Autoconfiguration. Autoconfiguration, as expected by IPv6 folds, is just impossible that it is a pity that DNSOP WG is contaminated. Autoconfiguration is easy on a single link isolated from the Internet. But, that's all. Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 11:33:36 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29030 for ; Mon, 14 Jul 2003 11:33:34 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EFD8mb028295 for ; Mon, 14 Jul 2003 17:13:08 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6EFD8Fd028294 for dnsop-outgoing; Mon, 14 Jul 2003 17:13:08 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EFD6mb028289 for ; Mon, 14 Jul 2003 17:13:07 +0200 (MEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6EFD5B00654 for ; Mon, 14 Jul 2003 18:13:06 +0300 Date: Mon, 14 Jul 2003 18:13:05 +0300 (EEST) From: Pekka Savola To: dnsop@cafax.se Subject: Re: IPv6 DNS Autoconfiguration In-Reply-To: <200307141420.XAA01347@necom830.hpcl.titech.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Mon, 14 Jul 2003, Masataka Ohta wrote: > > Beforehand, I'd like to summarize my talk for today's > > discussion about DNS Discovery and Autoconfiguration. > > Autoconfiguration, as expected by IPv6 folds, is just impossible > that it is a pity that DNSOP WG is contaminated. > > Autoconfiguration is easy on a single link isolated from the > Internet. But, that's all. FWIW, my opinion on the subject; DHCPv6-lite has been proposed as a means how to fix this problem. My issue with DHCPv6-lite is that DHCPv6 spec is some 89 pages, and most options are some 5 (or more) pages more, each. Even though DHCPv6-lite is only a subset of that, it still requires reading, understanding etc. a lot of it. It's much more difficult to get the "big picture" of DHCPv6-lite this way. Now, if we had specified DHCPv6 without address assignment (like I suggested, but that's beside the point), and put all of the stateful stuff ("cruft") in a separate "extension" RFC, we'd be talking about an entirely different issue. I was a very simple to implement, robust mechanism that's easy to understand. Reading 20 selected pieces of a large document fills that requirement, IMHO. I want a spec which is simple and clear, and less than 15-20 pages long. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 13:33:09 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07197 for ; Mon, 14 Jul 2003 13:33:08 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EH8Xmb029561 for ; Mon, 14 Jul 2003 19:08:33 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6EH8XYr029560 for dnsop-outgoing; Mon, 14 Jul 2003 19:08:33 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EH8Wmb029555 for ; Mon, 14 Jul 2003 19:08:32 +0200 (MEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6EH8Vi01520 for ; Mon, 14 Jul 2003 20:08:32 +0300 Date: Mon, 14 Jul 2003 20:08:31 +0300 (EEST) From: Pekka Savola To: dnsop@cafax.se Subject: Re: IPv6 DNS Autoconfiguration In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Mon, 14 Jul 2003, Pekka Savola wrote: > FWIW, my opinion on the subject; > > DHCPv6-lite has been proposed as a means how to fix this problem. > > My issue with DHCPv6-lite is that DHCPv6 spec is some 89 pages, and most > options are some 5 (or more) pages more, each. > > Even though DHCPv6-lite is only a subset of that, it still requires > reading, understanding etc. a lot of it. It's much more difficult to get > the "big picture" of DHCPv6-lite this way. > > Now, if we had specified DHCPv6 without address assignment (like I > suggested, but that's beside the point), and put all of the stateful stuff > ("cruft") in a separate "extension" RFC, we'd be talking about an entirely > different issue. > > I was a very simple to implement, robust mechanism that's easy to ^^^ want, that this :-) > understand. Reading 20 selected pieces of a large document fills that > requirement, IMHO. DOES NOT fill that requiremenent, that is.. I must have been really hurry when writing this, should have proof-read it first.. :/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 15:30:53 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18739 for ; Mon, 14 Jul 2003 15:30:50 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EJ95mb001156 for ; Mon, 14 Jul 2003 21:09:05 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6EJ94cf001154 for dnsop-outgoing; Mon, 14 Jul 2003 21:09:04 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EJ92mb001147 for ; Mon, 14 Jul 2003 21:09:03 +0200 (MEST) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h6EJ8wE12605; Mon, 14 Jul 2003 12:08:58 -0700 (PDT) From: Bill Manning Message-Id: <200307141908.h6EJ8wE12605@boreas.isi.edu> Subject: Re: IPv6 DNS Autoconfiguration In-Reply-To: from Pekka Savola at "Jul 14, 3 06:13:05 pm" To: pekkas@netcore.fi (Pekka Savola) Date: Mon, 14 Jul 2003 12:08:58 -0700 (PDT) Cc: dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit mind, I am very concerned w/ the goofy IPR/Note Well restrictions, so posting/participating is -very- infrequent. but to pose a query to the assembled multitude: BIND, a common DNS implementation has the ability to apply access controls as a local policy matter as to who can and can not use a "recursive resolving nameserver" or what ever it was that Rob said it was. If one uses the RA/ND techniques, how does one expect to extract the local DNS policy information before handing out server info via the RA/ND method? this weakness was not touched on during Bob Hindons presentation and I did not stay for the rest of the sessions festivities % On Mon, 14 Jul 2003, Masataka Ohta wrote: % > > Beforehand, I'd like to summarize my talk for today's % > > discussion about DNS Discovery and Autoconfiguration. % > % > Autoconfiguration, as expected by IPv6 folds, is just impossible % > that it is a pity that DNSOP WG is contaminated. % > % > Autoconfiguration is easy on a single link isolated from the % > Internet. But, that's all. % % FWIW, my opinion on the subject; % % DHCPv6-lite has been proposed as a means how to fix this problem. % % My issue with DHCPv6-lite is that DHCPv6 spec is some 89 pages, and most % options are some 5 (or more) pages more, each. % % Even though DHCPv6-lite is only a subset of that, it still requires % reading, understanding etc. a lot of it. It's much more difficult to get % the "big picture" of DHCPv6-lite this way. % % Now, if we had specified DHCPv6 without address assignment (like I % suggested, but that's beside the point), and put all of the stateful stuff % ("cruft") in a separate "extension" RFC, we'd be talking about an entirely % different issue. % % I was a very simple to implement, robust mechanism that's easy to % understand. Reading 20 selected pieces of a large document fills that % requirement, IMHO. % % I want a spec which is simple and clear, and less than 15-20 pages long. % % -- % Pekka Savola "You each name yourselves king, yet the % Netcore Oy kingdom bleeds." % Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings % % #---------------------------------------------------------------------- % # To unsubscribe, send a message to . % -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 15:41:23 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19703 for ; Mon, 14 Jul 2003 15:41:20 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EJMqmb001316 for ; Mon, 14 Jul 2003 21:22:52 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6EJMqLt001315 for dnsop-outgoing; Mon, 14 Jul 2003 21:22:52 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from web10004.mail.yahoo.com (web10004.mail.yahoo.com [216.136.130.40]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6EJMomb001310 for ; Mon, 14 Jul 2003 21:22:51 +0200 (MEST) Message-ID: <20030714192246.77320.qmail@web10004.mail.yahoo.com> Received: from [81.160.243.20] by web10004.mail.yahoo.com via HTTP; Mon, 14 Jul 2003 12:22:46 PDT Date: Mon, 14 Jul 2003 12:22:46 -0700 (PDT) From: Jaehoon Jeong Subject: Re: IPv6 DNS Autoconfiguration To: Masataka Ohta Cc: dnsop@cafax.se In-Reply-To: <200307141420.XAA01347@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-dnsop@cafax.se Precedence: bulk --- Masataka Ohta wrote: > Jaehoon; > > > Beforehand, I'd like to summarize my talk for > today's > > discussion about DNS Discovery and > Autoconfiguration. > > Autoconfiguration, as expected by IPv6 folds, is > just impossible > that it is a pity that DNSOP WG is contaminated. > > Autoconfiguration is easy on a single link isolated > from the > Internet. But, that's all. > At least, DNS discovery based on RA is easy and necessary in IPv6 wired and wireless networks connected to the Internet, I believe. Especially, in the environments where IPv6 address configuration is performed by IPv6 stateless address autoconf, such as HMIPv6 and NEMO, RA-based DNS Discovery is faster than DHCPv6-based DNS Discovery. IMHO, both DHCPv6-based approach and RA-based approach are necessary, depending on the situations, just like IPv6 address autoconfiguration. /Jaehoon > Masataka Ohta > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 15:45:19 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20027 for ; Mon, 14 Jul 2003 15:45:18 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EJSYmb001384 for ; Mon, 14 Jul 2003 21:28:34 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6EJSYh2001383 for dnsop-outgoing; Mon, 14 Jul 2003 21:28:34 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EJSXmb001378 for ; Mon, 14 Jul 2003 21:28:33 +0200 (MEST) Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3SWDL3S4>; Mon, 14 Jul 2003 20:28:45 +0100 Message-ID: From: matthew.ford@bt.com To: bmanning@ISI.EDU, pekkas@netcore.fi Cc: dnsop@cafax.se Subject: RE: IPv6 DNS Autoconfiguration Date: Mon, 14 Jul 2003 20:28:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-dnsop@cafax.se Precedence: bulk we are all free to fill our /etc/resolv.conf with garbage if we want. mat. > -----Original Message----- > From: Bill Manning [mailto:bmanning@ISI.EDU] > Sent: 14 July 2003 21:09 > To: Pekka Savola > Cc: dnsop@cafax.se > Subject: Re: IPv6 DNS Autoconfiguration > > > mind, I am very concerned w/ the goofy IPR/Note Well restrictions, > so posting/participating is -very- infrequent. but to pose a query > to the assembled multitude: > > BIND, a common DNS implementation has the ability to apply access > controls as a local policy matter as to who can and can not use > a "recursive resolving nameserver" or what ever it was that Rob said > it was. If one uses the RA/ND techniques, how does one expect to > extract the local DNS policy information before handing out server > info via the RA/ND method? > > this weakness was not touched on during Bob Hindons presentation > and I did not stay for the rest of the sessions festivities > > > > > % On Mon, 14 Jul 2003, Masataka Ohta wrote: > % > > Beforehand, I'd like to summarize my talk for today's > % > > discussion about DNS Discovery and Autoconfiguration. > % > > % > Autoconfiguration, as expected by IPv6 folds, is just impossible > % > that it is a pity that DNSOP WG is contaminated. > % > > % > Autoconfiguration is easy on a single link isolated from the > % > Internet. But, that's all. > % > % FWIW, my opinion on the subject; > % > % DHCPv6-lite has been proposed as a means how to fix this problem. > % > % My issue with DHCPv6-lite is that DHCPv6 spec is some 89 > pages, and most > % options are some 5 (or more) pages more, each. > % > % Even though DHCPv6-lite is only a subset of that, it still requires > % reading, understanding etc. a lot of it. It's much more > difficult to get > % the "big picture" of DHCPv6-lite this way. > % > % Now, if we had specified DHCPv6 without address assignment (like I > % suggested, but that's beside the point), and put all of the > stateful stuff > % ("cruft") in a separate "extension" RFC, we'd be talking > about an entirely > % different issue. > % > % I was a very simple to implement, robust mechanism that's easy to > % understand. Reading 20 selected pieces of a large document > fills that > % requirement, IMHO. > % > % I want a spec which is simple and clear, and less than > 15-20 pages long. > % > % -- > % Pekka Savola "You each name yourselves king, yet the > % Netcore Oy kingdom bleeds." > % Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > % > % > #------------------------------------------------------------- > --------- > % # To unsubscribe, send a message to . > % > > > -- > --bill > > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or > otherwise). > > #------------------------------------------------------------- > --------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 15:53:39 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20748 for ; Mon, 14 Jul 2003 15:53:38 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EJZFmb001487 for ; Mon, 14 Jul 2003 21:35:15 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6EJZFld001486 for dnsop-outgoing; Mon, 14 Jul 2003 21:35:15 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from web10001.mail.yahoo.com (web10001.mail.yahoo.com [216.136.130.37]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6EJZEmb001481 for ; Mon, 14 Jul 2003 21:35:14 +0200 (MEST) Message-ID: <20030714193513.41223.qmail@web10001.mail.yahoo.com> Received: from [81.160.243.20] by web10001.mail.yahoo.com via HTTP; Mon, 14 Jul 2003 12:35:13 PDT Date: Mon, 14 Jul 2003 12:35:13 -0700 (PDT) From: Jaehoon Jeong Subject: Re: IPv6 DNS Autoconfiguration To: dnsop@cafax.se In-Reply-To: <200307141420.XAA01347@necom830.hpcl.titech.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-dnsop@cafax.se Precedence: bulk --- Masataka Ohta wrote: > Jaehoon; > > > Beforehand, I'd like to summarize my talk for > today's > > discussion about DNS Discovery and > Autoconfiguration. > > Autoconfiguration, as expected by IPv6 folds, is > just impossible > that it is a pity that DNSOP WG is contaminated. > > Autoconfiguration is easy on a single link isolated > from the > Internet. But, that's all. > At least, DNS discovery based on RA is easy and necessary in IPv6 wired and wireless networks connected to the Internet, I believe. Especially, in the environments where IPv6 address configuration is performed by IPv6 stateless address autoconf, such as HMIPv6 and NEMO, RA-based DNS Discovery is faster than DHCPv6-based DNS Discovery. IMHO, both DHCPv6-based approach and RA-based approach are necessary, depending on the situations, just like IPv6 address autoconfiguration. /Jaehoon > Masataka Ohta > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 16:13:45 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22140 for ; Mon, 14 Jul 2003 16:13:43 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EJwSmb001960 for ; Mon, 14 Jul 2003 21:58:28 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6EJwSxR001959 for dnsop-outgoing; Mon, 14 Jul 2003 21:58:28 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from cbibipnt02.HC.BT.COM (saturn.bt.com [193.113.57.20]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EJwRmb001954 for ; Mon, 14 Jul 2003 21:58:27 +0200 (MEST) Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3SWA550Q>; Mon, 14 Jul 2003 20:58:37 +0100 Message-ID: From: matthew.ford@bt.com To: pekkas@netcore.fi Cc: dnsop@cafax.se Subject: RE: IPv6 DNS Autoconfiguration Date: Mon, 14 Jul 2003 20:58:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-dnsop@cafax.se Precedence: bulk > I want a spec which is simple and clear, and less than 15-20 > pages long. That would certainly be nice, but I don't think we should base our decision on the length of the specifications for the proposed solutions ;-) Benefits of the RA approach I can see are: o no need to implement DHCP clients in all hosts - this could be important for very simple network devices o no need to solicit data explicitly - hosts will either hear an RA with the relevant data, or send an RS and get the name server details as part of the RA response. I don't support the idea of an 'active' mode whereby hosts can explictly request the DNS data. If the router(s) is/are configured with the name server data and are configured to advertise it then they will do so. Explicit requests only make sense if we anticipate explicit requests for other types of data, and I think this should be absolutely out-of-scope. Mat. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 16:31:26 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23552 for ; Mon, 14 Jul 2003 16:31:25 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EKAYmb002193 for ; Mon, 14 Jul 2003 22:10:34 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6EKAYSY002192 for dnsop-outgoing; Mon, 14 Jul 2003 22:10:34 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EKAUmb002187 for ; Mon, 14 Jul 2003 22:10:32 +0200 (MEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6EKAMg03491; Mon, 14 Jul 2003 23:10:22 +0300 Date: Mon, 14 Jul 2003 23:10:21 +0300 (EEST) From: Pekka Savola To: matthew.ford@bt.com cc: dnsop@cafax.se Subject: RE: IPv6 DNS Autoconfiguration In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Mon, 14 Jul 2003 matthew.ford@bt.com wrote: > > I want a spec which is simple and clear, and less than 15-20 > > pages long. > > That would certainly be nice, but I don't think we should base our decision > on the length of the specifications for the proposed solutions ;-) > > Benefits of the RA approach I can see are: > > o no need to implement DHCP clients in all hosts > - this could be important for very simple network devices o no need to run DHCP clients in all scenarios - I certainly would not have any need to run DHCPv6(lite) on IETF WLAN, discovering the recursive DNS is just enough. If you roam a *lot* e.g. with a PDA and use Mobile IPv6, you may not desire all that many functions from your care-of networks. > o no need to solicit data explicitly > - hosts will either hear an RA with the relevant data, or send an RS > and get the name server details as part of the RA response. I don't support > the idea of an 'active' mode whereby hosts can explictly request the DNS > data. If the router(s) is/are configured with the name server data and are > configured to advertise it then they will do so. Explicit requests only make > sense if we anticipate explicit requests for other types of data, and I > think this should be absolutely out-of-scope. I'm not sure I'm 100% sure what's best myself, but there is one advantage to the "active" model (it seems): it may be easier to handle if your RA/RS processing happends in the kernel, but processing DNS info (including rewriting /etc/resolv.conf) would have to be in the userland. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 17:06:49 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22141 for ; Mon, 14 Jul 2003 16:13:43 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EJwamb001974 for ; Mon, 14 Jul 2003 21:58:36 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6EJwa8J001973 for dnsop-outgoing; Mon, 14 Jul 2003 21:58:36 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EJwZmb001968 for ; Mon, 14 Jul 2003 21:58:35 +0200 (MEST) Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3SR168BL>; Mon, 14 Jul 2003 20:58:43 +0100 Message-ID: From: matthew.ford@bt.com To: jaehoon_paul@yahoo.com Cc: dnsop@cafax.se Subject: RE: IPv6 DNS Autoconfiguration Date: Mon, 14 Jul 2003 20:58:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: owner-dnsop@cafax.se Precedence: bulk > At least, DNS discovery based on RA is easy and > necessary in IPv6 wired and wireless networks > connected to the Internet, I believe. > Especially, in the environments where IPv6 address > configuration is performed by IPv6 stateless address > autoconf, such as HMIPv6 and NEMO, RA-based DNS > Discovery is faster than DHCPv6-based DNS Discovery. > IMHO, both DHCPv6-based approach and RA-based approach > are necessary, depending on the situations, just like > IPv6 address autoconfiguration. Having both mechanisms could work: if we assume that routers configured to advertise recursive name server data will always do so when they send an RA (i.e. there is no explicit request mechanism other than standard RS) then if a node doesn't get the recursive name server data when it receives an RA, it can infer it needs to do DHCPv6(lite). Mat. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 17:06:49 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22139 for ; Mon, 14 Jul 2003 16:13:43 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EJtqmb001883 for ; Mon, 14 Jul 2003 21:55:52 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6EJtqkj001882 for dnsop-outgoing; Mon, 14 Jul 2003 21:55:52 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EJtomb001877 for ; Mon, 14 Jul 2003 21:55:51 +0200 (MEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6EJtgp03320; Mon, 14 Jul 2003 22:55:42 +0300 Date: Mon, 14 Jul 2003 22:55:41 +0300 (EEST) From: Pekka Savola To: matthew.ford@bt.com cc: bmanning@ISI.EDU, Subject: RE: IPv6 DNS Autoconfiguration In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Mon, 14 Jul 2003 matthew.ford@bt.com wrote: > we are all free to fill our /etc/resolv.conf with garbage if we want. Moreover, we are all free to (try to) feed our clients/customers garbage if we want. I'm not guaranteeing you'd get popular by doing so, but that's another issue. > > -----Original Message----- > > From: Bill Manning [mailto:bmanning@ISI.EDU] > > Sent: 14 July 2003 21:09 > > To: Pekka Savola > > Cc: dnsop@cafax.se > > Subject: Re: IPv6 DNS Autoconfiguration > > > > > > mind, I am very concerned w/ the goofy IPR/Note Well restrictions, > > so posting/participating is -very- infrequent. but to pose a query > > to the assembled multitude: > > > > BIND, a common DNS implementation has the ability to apply access > > controls as a local policy matter as to who can and can not use > > a "recursive resolving nameserver" or what ever it was that Rob said > > it was. If one uses the RA/ND techniques, how does one expect to > > extract the local DNS policy information before handing out server > > info via the RA/ND method? > > > > this weakness was not touched on during Bob Hindons presentation > > and I did not stay for the rest of the sessions festivities > > > > > > > > > > % On Mon, 14 Jul 2003, Masataka Ohta wrote: > > % > > Beforehand, I'd like to summarize my talk for today's > > % > > discussion about DNS Discovery and Autoconfiguration. > > % > > > % > Autoconfiguration, as expected by IPv6 folds, is just impossible > > % > that it is a pity that DNSOP WG is contaminated. > > % > > > % > Autoconfiguration is easy on a single link isolated from the > > % > Internet. But, that's all. > > % > > % FWIW, my opinion on the subject; > > % > > % DHCPv6-lite has been proposed as a means how to fix this problem. > > % > > % My issue with DHCPv6-lite is that DHCPv6 spec is some 89 > > pages, and most > > % options are some 5 (or more) pages more, each. > > % > > % Even though DHCPv6-lite is only a subset of that, it still requires > > % reading, understanding etc. a lot of it. It's much more > > difficult to get > > % the "big picture" of DHCPv6-lite this way. > > % > > % Now, if we had specified DHCPv6 without address assignment (like I > > % suggested, but that's beside the point), and put all of the > > stateful stuff > > % ("cruft") in a separate "extension" RFC, we'd be talking > > about an entirely > > % different issue. > > % > > % I was a very simple to implement, robust mechanism that's easy to > > % understand. Reading 20 selected pieces of a large document > > fills that > > % requirement, IMHO. > > % > > % I want a spec which is simple and clear, and less than > > 15-20 pages long. > > % > > % -- > > % Pekka Savola "You each name yourselves king, yet the > > % Netcore Oy kingdom bleeds." > > % Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > % > > % > > #------------------------------------------------------------- > > --------- > > % # To unsubscribe, send a message to . > > % > > > > > > -- > > --bill > > > > Opinions expressed may not even be mine by the time you read them, and > > certainly don't reflect those of any other entity (legal or > > otherwise). > > > > #------------------------------------------------------------- > > --------- > > # To unsubscribe, send a message to . > > > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 14 22:49:56 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22464 for ; Mon, 14 Jul 2003 22:49:55 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F2Rdmb007064 for ; Tue, 15 Jul 2003 04:27:39 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6F2RdJV007063 for dnsop-outgoing; Tue, 15 Jul 2003 04:27:39 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from web10001.mail.yahoo.com (web10001.mail.yahoo.com [216.136.130.37]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6F2Rbmb007058 for ; Tue, 15 Jul 2003 04:27:38 +0200 (MEST) Message-ID: <20030715022736.32403.qmail@web10001.mail.yahoo.com> Received: from [80.110.14.123] by web10001.mail.yahoo.com via HTTP; Mon, 14 Jul 2003 19:27:36 PDT Date: Mon, 14 Jul 2003 19:27:36 -0700 (PDT) From: Jaehoon Jeong Subject: RE: IPv6 DNS Autoconfiguration To: dnsop@cafax.se Cc: rdroms@cisco.com, bob.hinden@nokia.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-dnsop@cafax.se Precedence: bulk --- matthew.ford@bt.com wrote: > > At least, DNS discovery based on RA is easy and > > necessary in IPv6 wired and wireless networks > > connected to the Internet, I believe. > > Especially, in the environments where IPv6 address > > configuration is performed by IPv6 stateless > address > > autoconf, such as HMIPv6 and NEMO, RA-based DNS > > Discovery is faster than DHCPv6-based DNS > Discovery. > > IMHO, both DHCPv6-based approach and RA-based > approach > > are necessary, depending on the situations, just > like > > IPv6 address autoconfiguration. > > Having both mechanisms could work: if we assume that > routers configured to > advertise recursive name server data will always do > so when they send an RA > (i.e. there is no explicit request mechanism other > than standard RS) then if > a node doesn't get the recursive name server data > when it receives an RA, it > can infer it needs to do DHCPv6(lite). > IMHO, the RA and DHCPv6 approaches are not hostile, but complentary each other. It is important that IPv6 basic protocol has the complete autoconfiguration, including DNS discovery. It is the time for us to decide RA-based DNS discovery as working item. Four authors (Jaehoon, Daniel, Syam and Luc) agreed that a united draft about RA-based DNS Discovery should be published. If DNSOP wg allows our proposal, we'll write a draft together. How about? /Jaehoon > Mat. __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 03:13:22 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27930 for ; Tue, 15 Jul 2003 03:13:20 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F6rKmb009405 for ; Tue, 15 Jul 2003 08:53:20 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6F6rKCe009404 for dnsop-outgoing; Tue, 15 Jul 2003 08:53:20 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F6rJmb009399 for ; Tue, 15 Jul 2003 08:53:19 +0200 (MEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6F6rB607949; Tue, 15 Jul 2003 09:53:11 +0300 Date: Tue, 15 Jul 2003 09:53:10 +0300 (EEST) From: Pekka Savola To: Bill Manning cc: matthew.ford@bt.com, Subject: Re: IPv6 DNS Autoconfiguration In-Reply-To: <200307150649.h6F6nLY02912@boreas.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Mon, 14 Jul 2003, Bill Manning wrote: > yes, yes... thats not the question. the question is, how do the > good folks who propose this method fo DNS discovery expect to > find/extract the local DNS policy information to try and ensure > garbage is not handed out? Someone is configuring the routers to advertise this information. If it's configured manually, it becomes the responsibility of the configurer to ensure this. If it's configured automatically, it becomes the responsibility if the party who's configuring the source where the router automatically finds this information (e.g. DHCPv6 lite) to see that it's OK. The issue is recursive. > % On Mon, 14 Jul 2003 matthew.ford@bt.com wrote: > % > we are all free to fill our /etc/resolv.conf with garbage if we want. > % > % Moreover, we are all free to (try to) feed our clients/customers garbage > % if we want. > % > % I'm not guaranteeing you'd get popular by doing so, but that's another > % issue. > % > % > > -----Original Message----- > % > > From: Bill Manning [mailto:bmanning@ISI.EDU] > % > > Sent: 14 July 2003 21:09 > % > > To: Pekka Savola > % > > Cc: dnsop@cafax.se > % > > Subject: Re: IPv6 DNS Autoconfiguration > % > > > % > > > % > > mind, I am very concerned w/ the goofy IPR/Note Well restrictions, > % > > so posting/participating is -very- infrequent. but to pose a query > % > > to the assembled multitude: > % > > > % > > BIND, a common DNS implementation has the ability to apply access > % > > controls as a local policy matter as to who can and can not use > % > > a "recursive resolving nameserver" or what ever it was that Rob said > % > > it was. If one uses the RA/ND techniques, how does one expect to > % > > extract the local DNS policy information before handing out server > % > > info via the RA/ND method? > % > > > % > > this weakness was not touched on during Bob Hindons presentation > % > > and I did not stay for the rest of the sessions festivities > % > > > % > > > % > > > % > > > % > > % On Mon, 14 Jul 2003, Masataka Ohta wrote: > % > > % > > Beforehand, I'd like to summarize my talk for today's > % > > % > > discussion about DNS Discovery and Autoconfiguration. > % > > % > > % > > % > Autoconfiguration, as expected by IPv6 folds, is just impossible > % > > % > that it is a pity that DNSOP WG is contaminated. > % > > % > > % > > % > Autoconfiguration is easy on a single link isolated from the > % > > % > Internet. But, that's all. > % > > % > % > > % FWIW, my opinion on the subject; > % > > % > % > > % DHCPv6-lite has been proposed as a means how to fix this problem. > % > > % > % > > % My issue with DHCPv6-lite is that DHCPv6 spec is some 89 > % > > pages, and most > % > > % options are some 5 (or more) pages more, each. > % > > % > % > > % Even though DHCPv6-lite is only a subset of that, it still requires > % > > % reading, understanding etc. a lot of it. It's much more > % > > difficult to get > % > > % the "big picture" of DHCPv6-lite this way. > % > > % > % > > % Now, if we had specified DHCPv6 without address assignment (like I > % > > % suggested, but that's beside the point), and put all of the > % > > stateful stuff > % > > % ("cruft") in a separate "extension" RFC, we'd be talking > % > > about an entirely > % > > % different issue. > % > > % > % > > % I was a very simple to implement, robust mechanism that's easy to > % > > % understand. Reading 20 selected pieces of a large document > % > > fills that > % > > % requirement, IMHO. > % > > % > % > > % I want a spec which is simple and clear, and less than > % > > 15-20 pages long. > % > > % > % > > % -- > % > > % Pekka Savola "You each name yourselves king, yet the > % > > % Netcore Oy kingdom bleeds." > % > > % Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > % > > % > % > > % > % > > #------------------------------------------------------------- > % > > --------- > % > > % # To unsubscribe, send a message to . > % > > % > % > > > % > > > % > > -- > % > > --bill > % > > > % > > Opinions expressed may not even be mine by the time you read them, and > % > > certainly don't reflect those of any other entity (legal or > % > > otherwise). > % > > > % > > #------------------------------------------------------------- > % > > --------- > % > > # To unsubscribe, send a message to . > % > > > % > #---------------------------------------------------------------------- > % > # To unsubscribe, send a message to . > % > > % > % -- > % Pekka Savola "You each name yourselves king, yet the > % Netcore Oy kingdom bleeds." > % Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > % > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 03:37:41 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29498 for ; Tue, 15 Jul 2003 03:37:40 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F7IImb009777 for ; Tue, 15 Jul 2003 09:18:18 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6F7IIR3009776 for dnsop-outgoing; Tue, 15 Jul 2003 09:18:18 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from mailout2.samsung.com ([203.254.224.25]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F7IGmb009768 for ; Tue, 15 Jul 2003 09:18:17 +0200 (MEST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HI2006041LPNL@mailout2.samsung.com> for dnsop@cafax.se; Tue, 15 Jul 2003 16:17:49 +0900 (KST) Received: from ep_ms3_bk (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HI200AET1LOA3@mailout2.samsung.com> for dnsop@cafax.se; Tue, 15 Jul 2003 16:17:49 +0900 (KST) Received: from ep_was18 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HI2001PZ1LO5S@ms3.samsung.com> for dnsop@cafax.se; Tue, 15 Jul 2003 16:17:48 +0900 (KST) Content-return: prohibited Date: Tue, 15 Jul 2003 16:17:49 +0900 From: =?EUC-KR?B?udq89sir?= Subject: Re: IPv6 DNS Autoconfiguration [IPv6 DNS Discovery] To: Bill Manning Cc: Pekka Savola , dnsop@cafax.se Reply-to: soohong.park@samsung.com Message-id: <0HI2001Q01LO5S@ms3.samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20030715161749@soohong.park X-MTR: 20030715161749@soohong.park X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT > this weakness was not touched on during Bob Hindons presentation > and I did not stay for the rest of the sessions festivities Please make sure that the main issue of bob's presentation was not registration but "IPv6 DNS Discovery" Daniel #---------------------------------------------------------------------- # To unsubscribe, send a message to . #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 03:49:21 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00617 for ; Tue, 15 Jul 2003 03:49:19 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F7Tbmb009973 for ; Tue, 15 Jul 2003 09:29:37 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6F7TbBd009972 for dnsop-outgoing; Tue, 15 Jul 2003 09:29:37 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from mailout3.samsung.com ([203.254.224.33]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F7TZmb009967 for ; Tue, 15 Jul 2003 09:29:36 +0200 (MEST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HI200901256MH@mailout3.samsung.com> for dnsop@cafax.se; Tue, 15 Jul 2003 16:29:31 +0900 (KST) Received: from ep_ms3_bk (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HI200LH62564X@mailout3.samsung.com> for dnsop@cafax.se; Tue, 15 Jul 2003 16:29:30 +0900 (KST) Received: from ep_was14 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HI200JN8256U9@ms3.samsung.com> for dnsop@cafax.se; Tue, 15 Jul 2003 16:29:30 +0900 (KST) Content-return: prohibited Date: Tue, 15 Jul 2003 16:29:30 +0900 From: =?EUC-KR?B?udq89sir?= Subject: Re: Re: IPv6 DNS Autoconfiguration [IPv6 DNS Discovery] To: Jaehoon Jeong Cc: dnsop@cafax.se Reply-to: soohong.park@samsung.com Message-id: <0HI200JN9256U9@ms3.samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20030715162930@soohong.park X-MTR: 20030715162930@soohong.park X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT Hi folks At the yesterday dnsop meeting, we had a time for discussion of " IPv6 DNS Discovery based on ND", but we didn't decide any definitely consensus at all. We (Luc,Paul,Syam, and Daniel) will merge our related draft into one draft which will be focused on IPv6 DNS Discovery not autoregistration , since IPv6 autoregistration is not mature state at this time. I believe this approach is not duplicated method with DHCPv6. As bob's presentation, it was not IPv6 Stateless Autoconfiguration without IPv6 DNS Discovery. Please be sure, Even if DHCPv6 has a prefix option, we still use a RA option for IPv6 Prefix. IPv6 must have all required parameters for autoconfiguration including IPv6 DNS Discovery option. Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics TEL:+82-31-200-4508 FAX:+82-31-200-3147 mailto:soohong.park@samsung.com # To unsubscribe, send a message to . #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 03:57:31 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01414 for ; Tue, 15 Jul 2003 03:57:30 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F7eFmb010108 for ; Tue, 15 Jul 2003 09:40:15 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6F7eFuc010107 for dnsop-outgoing; Tue, 15 Jul 2003 09:40:15 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F7e8mb010102 for ; Tue, 15 Jul 2003 09:40:14 +0200 (MEST) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6F7e8Ah028410 for ; Tue, 15 Jul 2003 01:40:08 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HI200LXU2MVZH@edgemail1.Central.Sun.COM> for dnsop@cafax.se; Tue, 15 Jul 2003 01:40:08 -0600 (MDT) Received: from sun.com ([81.160.137.222]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HI2007QG2MTQV@mail.sun.net> for dnsop@cafax.se; Tue, 15 Jul 2003 01:40:07 -0600 (MDT) Date: Tue, 15 Jul 2003 00:40:06 -0700 From: Alain Durand Subject: Stepping back on the DNS discovery discussion To: dnsop@cafax.se Message-id: <8DE727E2-B697-11D7-83E1-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT During yesterday's discussion on DNS discovery we somehow jumped the gun a bit quickly and moved to solution space without really understanding the requirements. Let me step back a little and try to reverse engineer those! A) Rob, in his introduction, pointed at a number a functions a node could do when we talk about DNS autoconfiguration. Basically those are: 1- finding a recursive name server 2- finding a search list 3- updating the forward DNS tree 4- updating the reverse DNS tree 5- finding a NTP source for DNSsec signature verification From this list, it seems to me that 1- is critical, 5- is important and we could leave without 2, 3, and 5, at least for now. Those are important (except maybe 2) but can be taken care of separately. However, it is not clear to me that 1- and 5- need to be addressed by the same mechanism. That is, if there is already a mechanism to broadcast NTP timestamp on the local network, this may be a good enough solution. B) The second major element to study is the desired/required mode of operation. This autoconfiguration is happening mostly at boot time. I'm a bit concerned about the effects of self synchronization in the network and what happen when a very large flat L2 network power cycle. In IPv6 neighbor discovery, there is provision for that, with unsolicited router advertisements that are multicast to all nodes on the link. If we think that DNS discovery (for lack of a better term) is a critical part of stateless autoconfiguration, it may makes sense for it to have the same properties as the rest of the story, e.g. prefix discovery. C) A third element in this discussion is the compatibility with the IPv4 model. I agree it is highly desirable to have the same conceptual _administration_ model in IPv6, that is the information is configured by the network manager in a centralized repository and it then gets propagated to the nodes. This can actually be achieved regardless of the format of the bit pattern on the wire. - Alain. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 04:01:51 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27938 for ; Tue, 15 Jul 2003 03:13:21 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F6nZmb009359 for ; Tue, 15 Jul 2003 08:49:35 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6F6nZqb009358 for dnsop-outgoing; Tue, 15 Jul 2003 08:49:35 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F6nXmb009353 for ; Tue, 15 Jul 2003 08:49:34 +0200 (MEST) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6p2/8.11.2) id h6F6nLY02912; Mon, 14 Jul 2003 23:49:21 -0700 (PDT) From: Bill Manning Message-Id: <200307150649.h6F6nLY02912@boreas.isi.edu> Subject: Re: IPv6 DNS Autoconfiguration In-Reply-To: from Pekka Savola at "Jul 14, 3 10:55:41 pm" To: pekkas@netcore.fi (Pekka Savola) Date: Mon, 14 Jul 2003 23:49:21 -0700 (PDT) Cc: matthew.ford@bt.com, bmanning@ISI.EDU, dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit yes, yes... thats not the question. the question is, how do the good folks who propose this method fo DNS discovery expect to find/extract the local DNS policy information to try and ensure garbage is not handed out? % On Mon, 14 Jul 2003 matthew.ford@bt.com wrote: % > we are all free to fill our /etc/resolv.conf with garbage if we want. % % Moreover, we are all free to (try to) feed our clients/customers garbage % if we want. % % I'm not guaranteeing you'd get popular by doing so, but that's another % issue. % % > > -----Original Message----- % > > From: Bill Manning [mailto:bmanning@ISI.EDU] % > > Sent: 14 July 2003 21:09 % > > To: Pekka Savola % > > Cc: dnsop@cafax.se % > > Subject: Re: IPv6 DNS Autoconfiguration % > > % > > % > > mind, I am very concerned w/ the goofy IPR/Note Well restrictions, % > > so posting/participating is -very- infrequent. but to pose a query % > > to the assembled multitude: % > > % > > BIND, a common DNS implementation has the ability to apply access % > > controls as a local policy matter as to who can and can not use % > > a "recursive resolving nameserver" or what ever it was that Rob said % > > it was. If one uses the RA/ND techniques, how does one expect to % > > extract the local DNS policy information before handing out server % > > info via the RA/ND method? % > > % > > this weakness was not touched on during Bob Hindons presentation % > > and I did not stay for the rest of the sessions festivities % > > % > > % > > % > > % > > % On Mon, 14 Jul 2003, Masataka Ohta wrote: % > > % > > Beforehand, I'd like to summarize my talk for today's % > > % > > discussion about DNS Discovery and Autoconfiguration. % > > % > % > > % > Autoconfiguration, as expected by IPv6 folds, is just impossible % > > % > that it is a pity that DNSOP WG is contaminated. % > > % > % > > % > Autoconfiguration is easy on a single link isolated from the % > > % > Internet. But, that's all. % > > % % > > % FWIW, my opinion on the subject; % > > % % > > % DHCPv6-lite has been proposed as a means how to fix this problem. % > > % % > > % My issue with DHCPv6-lite is that DHCPv6 spec is some 89 % > > pages, and most % > > % options are some 5 (or more) pages more, each. % > > % % > > % Even though DHCPv6-lite is only a subset of that, it still requires % > > % reading, understanding etc. a lot of it. It's much more % > > difficult to get % > > % the "big picture" of DHCPv6-lite this way. % > > % % > > % Now, if we had specified DHCPv6 without address assignment (like I % > > % suggested, but that's beside the point), and put all of the % > > stateful stuff % > > % ("cruft") in a separate "extension" RFC, we'd be talking % > > about an entirely % > > % different issue. % > > % % > > % I was a very simple to implement, robust mechanism that's easy to % > > % understand. Reading 20 selected pieces of a large document % > > fills that % > > % requirement, IMHO. % > > % % > > % I want a spec which is simple and clear, and less than % > > 15-20 pages long. % > > % % > > % -- % > > % Pekka Savola "You each name yourselves king, yet the % > > % Netcore Oy kingdom bleeds." % > > % Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings % > > % % > > % % > > #------------------------------------------------------------- % > > --------- % > > % # To unsubscribe, send a message to . % > > % % > > % > > % > > -- % > > --bill % > > % > > Opinions expressed may not even be mine by the time you read them, and % > > certainly don't reflect those of any other entity (legal or % > > otherwise). % > > % > > #------------------------------------------------------------- % > > --------- % > > # To unsubscribe, send a message to . % > > % > #---------------------------------------------------------------------- % > # To unsubscribe, send a message to . % > % % -- % Pekka Savola "You each name yourselves king, yet the % Netcore Oy kingdom bleeds." % Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings % -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 04:05:06 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02080 for ; Tue, 15 Jul 2003 04:05:06 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F7lpmb010209 for ; Tue, 15 Jul 2003 09:47:51 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6F7lpo7010208 for dnsop-outgoing; Tue, 15 Jul 2003 09:47:51 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F7lomb010203 for ; Tue, 15 Jul 2003 09:47:50 +0200 (MEST) Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3SWDL9YY>; Tue, 15 Jul 2003 08:48:04 +0100 Message-ID: From: matthew.ford@bt.com To: bmanning@ISI.EDU, pekkas@netcore.fi Cc: dnsop@cafax.se Subject: RE: IPv6 DNS Autoconfiguration Date: Tue, 15 Jul 2003 08:47:38 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-dnsop@cafax.se Precedence: bulk In the same way that they find/extract the local DNS policy information before configuring existing DHCP services I expect. Mat. > -----Original Message----- > From: Bill Manning [mailto:bmanning@ISI.EDU] > Sent: 15 July 2003 08:49 > To: Pekka Savola > Cc: Ford,M,Mat,XGH5 FORDM5 R; bmanning@ISI.EDU; dnsop@cafax.se > Subject: Re: IPv6 DNS Autoconfiguration > > > > yes, yes... thats not the question. the question is, how do the > good folks who propose this method fo DNS discovery expect to > find/extract the local DNS policy information to try and ensure > garbage is not handed out? > > > % On Mon, 14 Jul 2003 matthew.ford@bt.com wrote: > % > we are all free to fill our /etc/resolv.conf with garbage > if we want. > % > % Moreover, we are all free to (try to) feed our > clients/customers garbage > % if we want. > % > % I'm not guaranteeing you'd get popular by doing so, but > that's another > % issue. > % > % > > -----Original Message----- > % > > From: Bill Manning [mailto:bmanning@ISI.EDU] > % > > Sent: 14 July 2003 21:09 > % > > To: Pekka Savola > % > > Cc: dnsop@cafax.se > % > > Subject: Re: IPv6 DNS Autoconfiguration > % > > > % > > > % > > mind, I am very concerned w/ the goofy IPR/Note Well > restrictions, > % > > so posting/participating is -very- infrequent. but to > pose a query > % > > to the assembled multitude: > % > > > % > > BIND, a common DNS implementation has the ability to > apply access > % > > controls as a local policy matter as to who can and can not use > % > > a "recursive resolving nameserver" or what ever it was > that Rob said > % > > it was. If one uses the RA/ND techniques, how does > one expect to > % > > extract the local DNS policy information before > handing out server > % > > info via the RA/ND method? > % > > > % > > this weakness was not touched on during Bob Hindons > presentation > % > > and I did not stay for the rest of the sessions festivities > % > > > % > > > % > > > % > > > % > > % On Mon, 14 Jul 2003, Masataka Ohta wrote: > % > > % > > Beforehand, I'd like to summarize my talk for today's > % > > % > > discussion about DNS Discovery and Autoconfiguration. > % > > % > > % > > % > Autoconfiguration, as expected by IPv6 folds, is > just impossible > % > > % > that it is a pity that DNSOP WG is contaminated. > % > > % > > % > > % > Autoconfiguration is easy on a single link isolated from the > % > > % > Internet. But, that's all. > % > > % > % > > % FWIW, my opinion on the subject; > % > > % > % > > % DHCPv6-lite has been proposed as a means how to fix > this problem. > % > > % > % > > % My issue with DHCPv6-lite is that DHCPv6 spec is some 89 > % > > pages, and most > % > > % options are some 5 (or more) pages more, each. > % > > % > % > > % Even though DHCPv6-lite is only a subset of that, it > still requires > % > > % reading, understanding etc. a lot of it. It's much more > % > > difficult to get > % > > % the "big picture" of DHCPv6-lite this way. > % > > % > % > > % Now, if we had specified DHCPv6 without address > assignment (like I > % > > % suggested, but that's beside the point), and put all of the > % > > stateful stuff > % > > % ("cruft") in a separate "extension" RFC, we'd be talking > % > > about an entirely > % > > % different issue. > % > > % > % > > % I was a very simple to implement, robust mechanism > that's easy to > % > > % understand. Reading 20 selected pieces of a large document > % > > fills that > % > > % requirement, IMHO. > % > > % > % > > % I want a spec which is simple and clear, and less than > % > > 15-20 pages long. > % > > % > % > > % -- > % > > % Pekka Savola "You each name > yourselves king, yet the > % > > % Netcore Oy kingdom bleeds." > % > > % Systems. Networks. Security. -- George R.R. Martin: A > Clash of Kings > % > > % > % > > % > % > > #------------------------------------------------------------- > % > > --------- > % > > % # To unsubscribe, send a message to . > % > > % > % > > > % > > > % > > -- > % > > --bill > % > > > % > > Opinions expressed may not even be mine by the time you > read them, and > % > > certainly don't reflect those of any other entity (legal or > % > > otherwise). > % > > > % > > #------------------------------------------------------------- > % > > --------- > % > > # To unsubscribe, send a message to . > % > > > % > > #------------------------------------------------------------- > --------- > % > # To unsubscribe, send a message to . > % > > % > % -- > % Pekka Savola "You each name yourselves king, yet the > % Netcore Oy kingdom bleeds." > % Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > % > > > -- > --bill > > Opinions expressed may not even be mine by the time you read them, and > certainly don't reflect those of any other entity (legal or > otherwise). > > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 04:11:54 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02711 for ; Tue, 15 Jul 2003 04:11:51 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F7rRmb010339 for ; Tue, 15 Jul 2003 09:53:27 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6F7rRTn010338 for dnsop-outgoing; Tue, 15 Jul 2003 09:53:27 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from cbibipnt08.hc.bt.com (saturn.bt.com [193.113.57.20]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F7rLmb010333 for ; Tue, 15 Jul 2003 09:53:21 +0200 (MEST) Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3SRGWY9A>; Tue, 15 Jul 2003 08:53:34 +0100 Message-ID: From: matthew.ford@bt.com To: Alain.Durand@Sun.COM, dnsop@cafax.se Subject: RE: Stepping back on the DNS discovery discussion Date: Tue, 15 Jul 2003 08:53:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: owner-dnsop@cafax.se Precedence: bulk > From this list, it seems to me that 1- is critical, 5- is important > and we could leave without 2, 3, and 5, at least for now. I guess you mean 2, 3 and 4. Mat. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 04:12:20 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02766 for ; Tue, 15 Jul 2003 04:12:18 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F7tdmb010391 for ; Tue, 15 Jul 2003 09:55:39 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6F7tdSg010390 for dnsop-outgoing; Tue, 15 Jul 2003 09:55:39 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from web10010.mail.yahoo.com (web10010.mail.yahoo.com [216.136.128.121]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6F7tbmb010385 for ; Tue, 15 Jul 2003 09:55:38 +0200 (MEST) Message-ID: <20030715075537.87804.qmail@web10010.mail.yahoo.com> Received: from [81.160.243.20] by web10010.mail.yahoo.com via HTTP; Tue, 15 Jul 2003 00:55:37 PDT Date: Tue, 15 Jul 2003 00:55:37 -0700 (PDT) From: Jaehoon Jeong Subject: Re: Re: IPv6 DNS Autoconfiguration [IPv6 DNS Discovery] To: soohong.park@samsung.com Cc: dnsop@cafax.se In-Reply-To: <0HI200JN9256U9@ms3.samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-dnsop@cafax.se Precedence: bulk --- Daniel wrote: > Hi folks > > At the yesterday dnsop meeting, we had a time for > discussion > of " IPv6 DNS Discovery based on ND", but we didn't > decide > any definitely consensus at all. > > We (Luc,Paul,Syam, and Daniel) will merge our > related draft into > one draft which will be focused on IPv6 DNS > Discovery not autoregistration > , since IPv6 autoregistration is not mature state at > this time. > Absolutely, I agree with Daniel. > I believe this approach is not duplicated method > with DHCPv6. As bob's presentation, > it was not IPv6 Stateless Autoconfiguration without > IPv6 DNS Discovery. > Before IPv6 wg is closed, we need to finish IPv6 stateless autoconfiguration, including DNS discovery. Many of IPv6 guys really want to see RA-based DNS discovery used. DHCPv6 and RA-based solutions depend on the selection of network managers or users. Anyone of them is not absolute, I think. As Bob said yesterday, we should finish the recursive argument about DNS discovery and complete the stateless autoconfiguration. Now, I think, DNSOP chairmen should decide if RA-based approach has to be working item or not. I would like to see DNSOP chairmen's opinion. /Jaehoon Paul > Please be sure, Even if DHCPv6 has a prefix option, > we still use a RA option for IPv6 Prefix. > > IPv6 must have all required parameters for > autoconfiguration including IPv6 DNS Discovery > option. > > > Daniel (Soohong Daniel Park) > Mobile Platform Lab. Samsung Electronics > TEL:+82-31-200-4508 FAX:+82-31-200-3147 > mailto:soohong.park@samsung.com > > > > # To unsubscribe, send a message to > . > > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 04:20:34 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03285 for ; Tue, 15 Jul 2003 04:20:34 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F83Mmb010552 for ; Tue, 15 Jul 2003 10:03:22 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6F83M9Y010551 for dnsop-outgoing; Tue, 15 Jul 2003 10:03:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F83Kmb010545 for ; Tue, 15 Jul 2003 10:03:21 +0200 (MEST) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6F83KAh005550 for ; Tue, 15 Jul 2003 02:03:20 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HI200MLD3PJZK@edgemail1.Central.Sun.COM> for dnsop@cafax.se; Tue, 15 Jul 2003 02:03:20 -0600 (MDT) Received: from sun.com ([81.160.137.222]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HI2009NI3PH9Q@mail.sun.net> for dnsop@cafax.se; Tue, 15 Jul 2003 02:03:19 -0600 (MDT) Date: Tue, 15 Jul 2003 01:03:18 -0700 From: Alain Durand Subject: Re: Stepping back on the DNS discovery discussion In-reply-to: To: matthew.ford@bt.com Cc: dnsop@cafax.se Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT On Tuesday, July 15, 2003, at 12:53 AM, matthew.ford@bt.com wrote: >> From this list, it seems to me that 1- is critical, 5- is important >> and we could leave without 2, 3, and 5, at least for now. > > I guess you mean 2, 3 and 4. Yes. I should have taken coffee this morning. Thanks for catching it. - Alain. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 04:27:40 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03978 for ; Tue, 15 Jul 2003 04:27:39 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F88mmb010705 for ; Tue, 15 Jul 2003 10:08:48 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6F88ld2010704 for dnsop-outgoing; Tue, 15 Jul 2003 10:08:47 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F88kmb010699 for ; Tue, 15 Jul 2003 10:08:46 +0200 (MEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6F88bV08672; Tue, 15 Jul 2003 11:08:37 +0300 Date: Tue, 15 Jul 2003 11:08:36 +0300 (EEST) From: Pekka Savola To: BELOEIL Luc FTRD/DMI/CAE cc: Bill Manning , , Subject: Re: RE : IPv6 DNS Autoconfiguration In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8BIT On Tue, 15 Jul 2003, BELOEIL Luc FTRD/DMI/CAE wrote: > I do not catch your point. "DNS resolver IPv6 addresses" must be, > whatever the way, "configured" in the DHCP-lite server (if DHCP is used) > or on the router (if RA-based solution is used). > > This "configuration" shall take care of the "local DNS policy". IMHO, > that is the matter of the DHCP-lite server or the router to advertise no > garbage information. > > Did I missed anything ? Nothing; we're in full agreement here. (compare: routers can use RA's to advertise prefixes they aren't configured to route, but that's no problem IMHO.) > > De : Pekka Savola [mailto:pekkas@netcore.fi] > > Envoyé : mardi 15 juillet 2003 08:53> > > > > On Mon, 14 Jul 2003, Bill Manning wrote: > > > yes, yes... thats not the question. the question is, how do the > > > good folks who propose this method fo DNS discovery expect to > > > find/extract the local DNS policy information to try and ensure > > > garbage is not handed out? > > > > Someone is configuring the routers to advertise this information. > > > > If it's configured manually, it becomes the responsibility of the > > configurer to ensure this. > > > > If it's configured automatically, it becomes the > > responsibility if the > > party who's configuring the source where the router > > automatically finds > > this information (e.g. DHCPv6 lite) to see that it's OK. > > > > The issue is recursive. > > > > > % On Mon, 14 Jul 2003 matthew.ford@bt.com wrote: > > > % > we are all free to fill our /etc/resolv.conf with garbage if we > > > want. % % Moreover, we are all free to (try to) feed our > > > clients/customers garbage % if we want. > > > % > > > % I'm not guaranteeing you'd get popular by doing so, but > > that's another > > > % issue. > > > % > > > % > > -----Original Message----- > > > % > > From: Bill Manning [mailto:bmanning@ISI.EDU] > > > % > > Sent: 14 July 2003 21:09 > > > % > > To: Pekka Savola > > > % > > Cc: dnsop@cafax.se > > > % > > Subject: Re: IPv6 DNS Autoconfiguration > > > % > > > > > % > > > > > % > > mind, I am very concerned w/ the goofy IPR/Note Well > > restrictions, > > > % > > so posting/participating is -very- infrequent. but > > to pose a query > > > % > > to the assembled multitude: > > > % > > > > > % > > BIND, a common DNS implementation has the ability to > > apply access > > > % > > controls as a local policy matter as to who can and > > can not use > > > % > > a "recursive resolving nameserver" or what ever it > > was that Rob said > > > % > > it was. If one uses the RA/ND techniques, how does > > one expect to > > > % > > extract the local DNS policy information before > > handing out server > > > % > > info via the RA/ND method? > > > % > > > > > % > > this weakness was not touched on during Bob Hindons > > presentation > > > % > > and I did not stay for the rest of the sessions festivities > > > % > > > > > % > > > > > % > > > > > % > > > > > % > > % On Mon, 14 Jul 2003, Masataka Ohta wrote: > > > % > > % > > Beforehand, I'd like to summarize my talk for today's > > > % > > % > > discussion about DNS Discovery and Autoconfiguration. > > > % > > % > > > > % > > % > Autoconfiguration, as expected by IPv6 folds, is > > just impossible > > > % > > % > that it is a pity that DNSOP WG is contaminated. > > > % > > % > > > > % > > % > Autoconfiguration is easy on a single link > > isolated from the > > > % > > % > Internet. But, that's all. > > > % > > % > > > % > > % FWIW, my opinion on the subject; > > > % > > % > > > % > > % DHCPv6-lite has been proposed as a means how to fix > > this problem. > > > % > > % > > > % > > % My issue with DHCPv6-lite is that DHCPv6 spec is some 89 > > > % > > pages, and most > > > % > > % options are some 5 (or more) pages more, each. > > > % > > % > > > % > > % Even though DHCPv6-lite is only a subset of that, > > it still requires > > > % > > % reading, understanding etc. a lot of it. It's much more > > > % > > difficult to get > > > % > > % the "big picture" of DHCPv6-lite this way. > > > % > > % > > > % > > % Now, if we had specified DHCPv6 without address > > assignment (like I > > > % > > % suggested, but that's beside the point), and put all of the > > > % > > stateful stuff > > > % > > % ("cruft") in a separate "extension" RFC, we'd be talking > > > % > > about an entirely > > > % > > % different issue. > > > % > > % > > > % > > % I was a very simple to implement, robust mechanism > > that's easy to > > > % > > % understand. Reading 20 selected pieces of a large document > > > % > > fills that > > > % > > % requirement, IMHO. > > > % > > % > > > % > > % I want a spec which is simple and clear, and less than > > > % > > 15-20 pages long. > > > % > > % > > > % > > % -- > > > % > > % Pekka Savola "You each name > > yourselves king, yet the > > > % > > % Netcore Oy kingdom bleeds." > > > % > > % Systems. Networks. Security. -- George R.R. Martin: > > A Clash of Kings > > > % > > % > > > % > > % > > > % > > #------------------------------------------------------------- > > > % > > --------- > > > % > > % # To unsubscribe, send a message to > > . > > > % > > % > > > % > > > > > % > > > > > % > > -- > > > % > > --bill > > > % > > > > > % > > Opinions expressed may not even be mine by the time > > you read them, and > > > % > > certainly don't reflect those of any other entity (legal or > > > % > > otherwise). > > > % > > > > > % > > #------------------------------------------------------------- > > > % > > --------- > > > % > > # To unsubscribe, send a message to . > > > % > > > > > % > > > #------------------------------------------------------------- > > --------- > > > % > # To unsubscribe, send a message to . > > > % > > > > % > > > % -- > > > % Pekka Savola "You each name yourselves > > king, yet the > > > % Netcore Oy kingdom bleeds." > > > % Systems. Networks. Security. -- George R.R. Martin: A > > Clash of Kings > > > % > > > > > > > > > > > > > -- > > Pekka Savola "You each name yourselves king, yet the > > Netcore Oy kingdom bleeds." > > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > #------------------------------------------------------------- > > --------- > > # To unsubscribe, send a message to . > > > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 05:42:21 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10810 for ; Tue, 15 Jul 2003 05:42:20 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F9J8mb011804 for ; Tue, 15 Jul 2003 11:19:08 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6F9J8Pl011803 for dnsop-outgoing; Tue, 15 Jul 2003 11:19:08 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6F9J7mb011798 for ; Tue, 15 Jul 2003 11:19:07 +0200 (MEST) Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA16970 for ; Tue, 15 Jul 2003 10:19:06 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id KAA07073 for ; Tue, 15 Jul 2003 10:19:06 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6F9J6620497 for dnsop@cafax.se; Tue, 15 Jul 2003 10:19:06 +0100 Date: Tue, 15 Jul 2003 10:19:06 +0100 From: Tim Chown To: dnsop@cafax.se Subject: Re: Stepping back on the DNS discovery discussion Message-ID: <20030715091906.GS18608@login.ecs.soton.ac.uk> Mail-Followup-To: dnsop@cafax.se References: <8DE727E2-B697-11D7-83E1-00039358A080@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8DE727E2-B697-11D7-83E1-00039358A080@sun.com> User-Agent: Mutt/1.4i Sender: owner-dnsop@cafax.se Precedence: bulk On Tue, Jul 15, 2003 at 12:40:06AM -0700, Alain Durand wrote: > However, it is not clear to me that 1- and 5- need to be addressed by > the same > mechanism. That is, if there is already a mechanism to broadcast NTP > timestamp on the local network, this may be a good enough solution. Agreed. I think Mat and Pekka's points are also well made. > If we think that DNS discovery (for lack of a better term) is a > critical part of stateless autoconfiguration, > it may makes sense for it to have the same properties as the rest of > the story, e.g. prefix discovery. There was certainly a significant hum in this direction in the meeting. Both DNS Lite and RA discovery methods can exist; each has an application domain/scope. > C) A third element in this discussion is the compatibility with the > IPv4 model. This also links back to the SFO meeting where the WG discussed how answers from (potentially) different DHCP and DHCPv6 servers would be handled in a dual stack environment. But that's the point now - IPv6 stateless DNS discovery is not perceived as "missing" because most people use IPv6 in a dual-stack network where IPv4 DNS resolver info is issued over IPv4 transport by DHCP(v4). As Mat says, in new LCNA devices, isn't DHCP(Lite) client support merely for DNS discovery a little unecessary? Sure, not all LCNA's will need to resolve DNS, but many will. Tim #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 08:05:11 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15680 for ; Tue, 15 Jul 2003 08:05:11 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FBf2mb013235 for ; Tue, 15 Jul 2003 13:41:02 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6FBf2XU013234 for dnsop-outgoing; Tue, 15 Jul 2003 13:41:02 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FBetmb013227 for ; Tue, 15 Jul 2003 13:40:56 +0200 (MEST) From: Masataka Ohta Message-Id: <200307151133.UAA00746@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA00746; Tue, 15 Jul 2003 20:32:52 +0859 Subject: Re: Stepping back on the DNS discovery discussion In-Reply-To: <8DE727E2-B697-11D7-83E1-00039358A080@sun.com> from Alain Durand at "Jul 15, 2003 00:40:06 am" To: Alain Durand Date: Tue, 15 Jul 2003 20:32:51 +0859 () CC: dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk Alain; > During yesterday's discussion on DNS discovery > we somehow jumped the gun a bit quickly and moved > to solution space without really understanding the requirements. OK. What's wrong if microsoft run DNS servers at yourdomain.microsoft.com and preconfigure keys in their OS for dynamic update? > A) Rob, in his introduction, pointed at a number a functions a node > could > do when we talk about DNS autoconfiguration. Basically those are: > 1- finding a recursive name server > 2- finding a search list > 3- updating the forward DNS tree > 4- updating the reverse DNS tree > 5- finding a NTP source for DNSsec signature verification > > From this list, it seems to me that 1- is critical, Well known anycast addresses are more than enough for 1. > 5- is important You should be joking. Where is security? Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 08:17:56 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15981 for ; Tue, 15 Jul 2003 08:17:56 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FBxHmb013467 for ; Tue, 15 Jul 2003 13:59:17 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6FBxH6k013466 for dnsop-outgoing; Tue, 15 Jul 2003 13:59:17 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from mailout2.samsung.com ([203.254.224.25]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FBxFmb013453 for ; Tue, 15 Jul 2003 13:59:16 +0200 (MEST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HI200H07EMHF8@mailout2.samsung.com> for dnsop@cafax.se; Tue, 15 Jul 2003 20:59:05 +0900 (KST) Received: from ep_ms3_bk (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HI200B2MEMGQP@mailout2.samsung.com> for dnsop@cafax.se; Tue, 15 Jul 2003 20:59:04 +0900 (KST) Received: from ep_was15 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HI2001D6EMG5S@ms3.samsung.com> for dnsop@cafax.se; Tue, 15 Jul 2003 20:59:04 +0900 (KST) Content-return: prohibited Date: Tue, 15 Jul 2003 20:59:03 +0900 From: =?EUC-KR?B?udq89sir?= Subject: Re: Re: Stepping back on the DNS discovery discussion To: Tim Chown , hinden@iprg.nokia.com Cc: dnsop@cafax.se Reply-to: soohong.park@samsung.com Message-id: <0HI2001D7EMG5S@ms3.samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20030715205903@soohong.park X-MTR: 20030715205903@soohong.park X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT > If we think that DNS discovery (for lack of a better term) is a > critical part of stateless autoconfiguration, > it may makes sense for it to have the same properties as the rest of > the story, e.g. prefix discovery. >>There was certainly a significant hum in this direction in the meeting. >>Both DNS Lite and RA discovery methods can exist; each has an application >>domain/scope. Exactly... dnsop WG must decide these consensus as soon as possible. Daniel #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 08:38:39 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16441 for ; Tue, 15 Jul 2003 08:38:36 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FCH1mb013691 for ; Tue, 15 Jul 2003 14:17:01 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6FCH119013690 for dnsop-outgoing; Tue, 15 Jul 2003 14:17:01 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FCGtmb013685 for ; Tue, 15 Jul 2003 14:17:00 +0200 (MEST) Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6FCGhO5012355 for ; Tue, 15 Jul 2003 06:16:43 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HI200M12FFUJN@edgemail1.Central.Sun.COM> for dnsop@cafax.se; Tue, 15 Jul 2003 06:16:43 -0600 (MDT) Received: from sun.com ([81.160.137.222]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HI200959FFR9N@mail.sun.net> for dnsop@cafax.se; Tue, 15 Jul 2003 06:16:42 -0600 (MDT) Date: Tue, 15 Jul 2003 05:16:41 -0700 From: Alain Durand Subject: Re: Stepping back on the DNS discovery discussion In-reply-to: <200307151133.UAA00746@necom830.hpcl.titech.ac.jp> To: Masataka Ohta Cc: dnsop@cafax.se Message-id: <31313175-B6BE-11D7-83E1-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT On Tuesday, July 15, 2003, at 04:33 AM, Masataka Ohta wrote: > Alain; > >> During yesterday's discussion on DNS discovery >> we somehow jumped the gun a bit quickly and moved >> to solution space without really understanding the requirements. > > OK. What's wrong if microsoft run DNS servers at > > yourdomain.microsoft.com > > and preconfigure keys in their OS for dynamic update? Not sure I understand how your comment is related to this discussion.... could you please clarify? > >> A) Rob, in his introduction, pointed at a number a functions a node >> could >> do when we talk about DNS autoconfiguration. Basically those are: >> 1- finding a recursive name server >> 2- finding a search list >> 3- updating the forward DNS tree >> 4- updating the reverse DNS tree >> 5- finding a NTP source for DNSsec signature verification >> >> From this list, it seems to me that 1- is critical, > > Well known anycast addresses are more than enough for 1. I agree it works (I wrote the draft ;-). The other suggested solution works too. >> 5- is important > > You should be joking. Where is security? You need a reasonable clock to verify DNSsec signature. - Alain. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 09:40:18 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18196 for ; Tue, 15 Jul 2003 09:40:16 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FDJrmb014702 for ; Tue, 15 Jul 2003 15:19:53 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6FDJqLW014701 for dnsop-outgoing; Tue, 15 Jul 2003 15:19:52 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from naptop.autonomica.net (naptop.autonomica.n [81.160.131.239] (may be forged)) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FDJpmb014696 for ; Tue, 15 Jul 2003 15:19:52 +0200 (MEST) Received: from naptop.autonomica.net (localhost [127.0.0.1]) by naptop.autonomica.net (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FDJKnl007228 for ; Tue, 15 Jul 2003 15:19:20 +0200 (MEST) Received: (from liman@localhost) by naptop.autonomica.net (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6FDJKcX007227 for dnsop@cafax.se; Tue, 15 Jul 2003 15:19:20 +0200 (MEST) Received: from sa.vix.com (sa.vix.com [204.152.187.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6EAMHmb025415 for ; Mon, 14 Jul 2003 12:22:18 +0200 (MEST) Received: from sa.vix.com (localhost [127.0.0.1]) by sa.vix.com (Postfix) with ESMTP id 40D2E1394C for ; Mon, 14 Jul 2003 10:22:16 +0000 (GMT) (envelope-from vixie@sa.vix.com) From: Paul Vixie To: dnsop@cafax.se Subject: regarding the respsize draft: preferring glue of certain types X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1 Date: Mon, 14 Jul 2003 10:22:16 +0000 Message-Id: <20030714102216.40D2E1394C@sa.vix.com> Sender: owner-dnsop@cafax.se Precedence: bulk i may have a conflict during today's meeting in which case i'd like to present my recent thoughts about respsize here and hope that kato or others will represent them in real time. these issues are highly topical since they will drive the policies by which IANA will add, or not add, AAAA RRs for root and tld servers. --- in the event where a delegation response is going to be truncated, it is desireable that glue of the appropriate type be added preferentially. if the query arrived by IPv4, then A RRs ought to be added first; if the query arrived by IPv6, then AAAA RRs ought to be added first. this assumes that a dns client will wish to use the same protocol for reaching the designated servers as it used to reach the delegating server. to prevent pathological starvation, at most one glue rrset of each type should be present even in a truncated response, unless the rrsets are such that the smallest rrset of each glue type would not fit. since truncation must be on rrset boundaries, smaller rrsets should be added before larger ones. if the smallest rrset of any type is still too large to fit, then the delegation response's additional data section will be empty. --- (before anybody suggests that we add a "glue order" option in EDNS, keep in mind that when EDNS is available, truncation will only rarely occur, even with both kinds of glue records and full dns security signatures. this entire discussion has to do with imputing the best interests of dns clients who lack the ability to express either preference or capability.) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 10:03:04 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18902 for ; Tue, 15 Jul 2003 10:03:04 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FDhVmb015020 for ; Tue, 15 Jul 2003 15:43:31 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6FDhVqh015019 for dnsop-outgoing; Tue, 15 Jul 2003 15:43:31 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FDhTmb015008 for ; Tue, 15 Jul 2003 15:43:30 +0200 (MEST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D39FB13; Tue, 15 Jul 2003 22:43:21 +0900 (JST) To: Paul Vixie Cc: dnsop@cafax.se In-reply-to: paul's message of Mon, 14 Jul 2003 10:22:16 GMT. <20030714102216.40D2E1394C@sa.vix.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: regarding the respsize draft: preferring glue of certain types From: itojun@iijlab.net Date: Tue, 15 Jul 2003 22:43:21 +0900 Message-Id: <20030715134321.D39FB13@coconut.itojun.org> Sender: owner-dnsop@cafax.se Precedence: bulk >in the event where a delegation response is going to be truncated, it >is desireable that glue of the appropriate type be added preferentially. >if the query arrived by IPv4, then A RRs ought to be added first; if >the query arrived by IPv6, then AAAA RRs ought to be added first. > >this assumes that a dns client will wish to use the same protocol for >reaching the designated servers as it used to reach the delegating >server. can't we provide like "one A glue, then one AAAA glue, then A glue, then one AAAA glue ..." ? this way dual stack querier would be able to get n A glue records and m AAAA glue records after truncation. itojun #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 10:08:59 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19550 for ; Tue, 15 Jul 2003 10:08:58 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FDnxmb015111 for ; Tue, 15 Jul 2003 15:49:59 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6FDnx3R015110 for dnsop-outgoing; Tue, 15 Jul 2003 15:49:59 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FDnqmb015104 for ; Tue, 15 Jul 2003 15:49:53 +0200 (MEST) From: Masataka Ohta Message-Id: <200307151339.WAA01177@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id WAA01177; Tue, 15 Jul 2003 22:39:25 +0900 Subject: Re: Stepping back on the DNS discovery discussion In-Reply-To: <31313175-B6BE-11D7-83E1-00039358A080@sun.com> from Alain Durand at "Jul 15, 2003 05:16:41 am" To: Alain Durand Date: Tue, 15 Jul 2003 22:39:24 +0859 () CC: dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk Alain; > >> During yesterday's discussion on DNS discovery > >> we somehow jumped the gun a bit quickly and moved > >> to solution space without really understanding the requirements. > > > > OK. What's wrong if microsoft run DNS servers at > > > > yourdomain.microsoft.com > > > > and preconfigure keys in their OS for dynamic update? > > Not sure I understand how your comment is related to this discussion.... > could you please clarify? If the requirement is to be registered under some domain, let vendors provide it. > >> 1- finding a recursive name server > >> 2- finding a search list > >> 3- updating the forward DNS tree > >> 4- updating the reverse DNS tree > >> 5- finding a NTP source for DNSsec signature verification > >> > >> From this list, it seems to me that 1- is critical, > > > > Well known anycast addresses are more than enough for 1. > > I agree it works (I wrote the draft ;-). And, it needs no new protocol. > >> 5- is important > > > > You should be joking. Where is security? > > You need a reasonable clock to verify DNSsec signature. How can you verify the clock reasonable? Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 10:34:41 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21942 for ; Tue, 15 Jul 2003 10:34:36 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FED6mb015442 for ; Tue, 15 Jul 2003 16:13:06 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6FED5n8015441 for dnsop-outgoing; Tue, 15 Jul 2003 16:13:05 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from cbibipnt02.HC.BT.COM (saturn.bt.com [193.113.57.20]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FED0mb015436 for ; Tue, 15 Jul 2003 16:13:00 +0200 (MEST) Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3SWA7RPW>; Tue, 15 Jul 2003 15:13:13 +0100 Message-ID: From: matthew.ford@bt.com To: mohta@necom830.hpcl.titech.ac.jp, Alain.Durand@Sun.COM Cc: dnsop@cafax.se Subject: RE: Stepping back on the DNS discovery discussion Date: Tue, 15 Jul 2003 15:12:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-dnsop@cafax.se Precedence: bulk > > > Well known anycast addresses are more than enough for 1. > > > > I agree it works (I wrote the draft ;-). > > And, it needs no new protocol. Are these site-local scope anycast addresses you're talking about? Mat. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 10:53:37 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22742 for ; Tue, 15 Jul 2003 10:53:31 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FEWMmb015928 for ; Tue, 15 Jul 2003 16:32:22 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6FEWMXl015927 for dnsop-outgoing; Tue, 15 Jul 2003 16:32:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FEWFmb015922 for ; Tue, 15 Jul 2003 16:32:21 +0200 (MEST) Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6FEW5Ri028541 for ; Tue, 15 Jul 2003 08:32:05 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HI200MX8LPGJN@edgemail1.Central.Sun.COM> for dnsop@cafax.se; Tue, 15 Jul 2003 08:32:04 -0600 (MDT) Received: from sun.com ([81.160.137.222]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HI200BY2LPDUN@mail.sun.net> for dnsop@cafax.se; Tue, 15 Jul 2003 08:32:04 -0600 (MDT) Date: Tue, 15 Jul 2003 07:32:03 -0700 From: Alain Durand Subject: Re: Stepping back on the DNS discovery discussion In-reply-to: To: matthew.ford@bt.com Cc: mohta@necom830.hpcl.titech.ac.jp, dnsop@cafax.se Message-id: <1A255A8B-B6D1-11D7-83E1-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT They were designed as such. This approach has lost traction. - Alain. On Tuesday, July 15, 2003, at 07:12 AM, matthew.ford@bt.com wrote: >>>> Well known anycast addresses are more than enough for 1. >>> >>> I agree it works (I wrote the draft ;-). >> >> And, it needs no new protocol. > > Are these site-local scope anycast addresses you're talking about? > > Mat. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 10:55:42 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22848 for ; Tue, 15 Jul 2003 10:55:42 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FEd6mb016124 for ; Tue, 15 Jul 2003 16:39:06 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6FEd6Lg016123 for dnsop-outgoing; Tue, 15 Jul 2003 16:39:06 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FEcxmb016117 for ; Tue, 15 Jul 2003 16:39:00 +0200 (MEST) From: Masataka Ohta Message-Id: <200307151430.XAA01528@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id XAA01528; Tue, 15 Jul 2003 23:30:38 +0900 Subject: Re: Stepping back on the DNS discovery discussion In-Reply-To: from "(env:" "matthew.ford@bt.com)" at "Jul 15, 2003 03:12:50 pm" To: matthew.ford@bt.com Date: Tue, 15 Jul 2003 23:30:36 +0859 () CC: Alain.Durand@Sun.COM, dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk Mat ; > > > > Well known anycast addresses are more than enough for 1. > > > > > > I agree it works (I wrote the draft ;-). > > > > And, it needs no new protocol. > > Are these site-local scope anycast addresses you're talking about? No. It is just anycast. Scope is irrelevant. Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 11:37:00 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24555 for ; Tue, 15 Jul 2003 11:36:59 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FFFBmb016651 for ; Tue, 15 Jul 2003 17:15:11 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6FFFBXT016650 for dnsop-outgoing; Tue, 15 Jul 2003 17:15:11 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from mailout3.samsung.com ([203.254.224.33]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FFF5mb016642 for ; Tue, 15 Jul 2003 17:15:06 +0200 (MEST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HI200201NP1XP@mailout3.samsung.com> for dnsop@cafax.se; Wed, 16 Jul 2003 00:15:01 +0900 (KST) Received: from ep_ms3_bk (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HI200K6DNP0SQ@mailout3.samsung.com> for dnsop@cafax.se; Wed, 16 Jul 2003 00:15:00 +0900 (KST) Received: from ep_was20 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HI20079PNP0TG@ms3.samsung.com> for dnsop@cafax.se; Wed, 16 Jul 2003 00:15:00 +0900 (KST) Content-return: prohibited Date: Wed, 16 Jul 2003 00:15:02 +0900 From: =?EUC-KR?B?udq89sir?= Subject: Re: Re: Stepping back on the DNS discovery discussion To: Alain Durand Cc: matthew.ford@bt.com, mohta@necom830.hpcl.titech.ac.jp, dnsop@cafax.se Reply-to: soohong.park@samsung.com Message-id: <0HI20079QNP0TG@ms3.samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20030716001502@soohong.park X-MTR: 20030716001502@soohong.park X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT >They were designed as such. This approach has lost traction. We have to go to the right direction "IPv6 DNS Discovery based on RA or ND" How long will this discussion last at this WG ? David and Rob, I believe we need it definitely Daniel #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 11:56:00 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25107 for ; Tue, 15 Jul 2003 11:55:59 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FFZ3mb017066 for ; Tue, 15 Jul 2003 17:35:03 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6FFZ31M017065 for dnsop-outgoing; Tue, 15 Jul 2003 17:35:03 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from cbibipnt02.HC.BT.COM (saturn.bt.com [193.113.57.20]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FFZ2mb017060 for ; Tue, 15 Jul 2003 17:35:03 +0200 (MEST) Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3SWA7XV0>; Tue, 15 Jul 2003 16:35:16 +0100 Message-ID: From: matthew.ford@bt.com To: soohong.park@samsung.com, Alain.Durand@Sun.COM Cc: mohta@necom830.hpcl.titech.ac.jp, dnsop@cafax.se Subject: RE: Re: Stepping back on the DNS discovery discussion Date: Tue, 15 Jul 2003 16:34:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="KS_C_5601-1987" Sender: owner-dnsop@cafax.se Precedence: bulk > We have to go to the right direction > "IPv6 DNS Discovery based on RA or ND" You and your colleagues have said numerous times on this list recently that the RA/ND approach is 'right'. It might help if you could say why you believe that, and specifically why you believe that using RA/ND is better than using DHCP. Mat. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 12:00:58 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25302 for ; Tue, 15 Jul 2003 12:00:55 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FFf4mb017241 for ; Tue, 15 Jul 2003 17:41:04 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6FFf4XJ017240 for dnsop-outgoing; Tue, 15 Jul 2003 17:41:04 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FFf2mb017235 for ; Tue, 15 Jul 2003 17:41:03 +0200 (MEST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 33E6013; Wed, 16 Jul 2003 00:41:00 +0900 (JST) To: soohong.park@samsung.com Cc: dnsop@cafax.se In-reply-to: soohong.park's message of Wed, 16 Jul 2003 00:15:02 +0900. <0HI20079QNP0TG@ms3.samsung.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Stepping back on the DNS discovery discussion From: itojun@iijlab.net Date: Wed, 16 Jul 2003 00:41:00 +0900 Message-Id: <20030715154100.33E6013@coconut.itojun.org> Sender: owner-dnsop@cafax.se Precedence: bulk >>They were designed as such. This approach has lost traction. >We have to go to the right direction >"IPv6 DNS Discovery based on RA or ND" who decided that this is the right direction? it is yet to be decided. the above statement is not acceptable. to be clear, in the ietf there are multiple efforts on "service discovery" mechansisms, including DHCP, piggyback on RA, srvloc, DNS SRV record and a lot more. basically we are in confusion state. draft-ietf-ipngwg-dns-discovery-analysis-00.txt tried to clear up the confusion, but it was not enough. itojun #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 12:07:53 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25589 for ; Tue, 15 Jul 2003 12:07:51 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FFjimb017311 for ; Tue, 15 Jul 2003 17:45:44 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6FFji2b017310 for dnsop-outgoing; Tue, 15 Jul 2003 17:45:44 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from cyteen.hactrn.net (dsl092-066-068.bos1.dsl.speakeasy.net [66.92.66.68]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FFjhmb017305 for ; Tue, 15 Jul 2003 17:45:43 +0200 (MEST) Received: from thangorodrim.hactrn.net (unknown [81.160.134.225]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 3B21345F for ; Tue, 15 Jul 2003 11:45:42 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [::1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id BFC502329 for ; Tue, 15 Jul 2003 15:45:37 +0000 (UTC) Date: Tue, 15 Jul 2003 17:45:36 +0200 From: Rob Austein To: dnsop@cafax.se Subject: My slides from Wien DNSOP session User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030715154537.BFC502329@thangorodrim.hactrn.net> Sender: owner-dnsop@cafax.se Precedence: bulk Since there's been a bit of mailing list discussion based on my presentation yesteday, here are the slides. %page Step back a moment Discovery is one aspect of autoconfiguration What data does a DNS-consuming node need when it boots? All DNS consumers need addresses of some name servers Usually recursive name servers But maybe this is an iterative resolver Other things that some DNS consumers might want What search path should I use? What's my own name? How do I publish my name->address data? How do I publish my address->name data? How do I verify signed DNS data? "DNS Discovery" == finding recursive name servers %page Security model Issues differ greatly depending on: Which data one is trying to autoconfigure Degree to which one trusts the local network Recursive name server addresses ("DNS discovery") Issues fairly well understood, we think Consumer is at name server's mercy, unless consumer checks sigs If consumer does check sigs, it needs: DNSSEC policy DNSSEC public key(s) A clock (may require (S)NTP, more key(s), ...) Search path: Danger, Will Robinson Controls what questions a node asks "What's my name?" See "search path", above Default kerberos realm too Other effects unknown and system dependent, but probably scary %page Security model (2) "How do I publish my name->address data?" Relatively well understood (DNS UPDATE) Requires more policy and keying material Autoconfig adds no obvious new vulnerabilities "How do I publish my address->name data?" Superficially similar to name->address, but Very weak trust model for address ownership "How do I verify signed DNS data?" Fairly well understood Issues already discussed, above %page #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 12:28:41 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25977 for ; Tue, 15 Jul 2003 12:28:40 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FG8dmb017800 for ; Tue, 15 Jul 2003 18:08:39 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6FG8c5O017799 for dnsop-outgoing; Tue, 15 Jul 2003 18:08:38 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from stoneport.math.uic.edu (stoneport.math.uic.edu [131.193.178.160]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6FG8bmb017794 for ; Tue, 15 Jul 2003 18:08:37 +0200 (MEST) Received: (qmail 25743 invoked by uid 1016); 15 Jul 2003 16:09:07 -0000 Date: 15 Jul 2003 16:09:07 -0000 Message-ID: <20030715160907.25742.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: dnsop@cafax.se Subject: Re: regarding the respsize draft: preferring glue of certain types References: <20030714102216.40D2E1394C@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-dnsop@cafax.se Precedence: bulk Paul Vixie writes: > to prevent pathological starvation, at most one glue rrset of each type > should be present even in a truncated response, unless the rrsets > are such that the smallest rrset of each glue type would not fit. I found this unnecessarily confusing. Can we please reserve the word ``truncation'' for the TC bit? See RFC 1035. There are three separate issues: (1) the strategy for adding delegation records; (2) the strategy for adding AU+AR to authoritative responses; and (3) how to handle truncation. For example, with tinydns, (1) NS and corresponding A glue is always added to delegations; (2) AU (or AU+AR) is added to authoritative answers only if the entire AU (or AU+AR) ends before the 512-byte boundary; and (3) if truncation is required, all records are eliminated. As for mixing A and AAAA in delegations, I don't understand the benefit to having both in the first place. If a child server provides only one protocol, there's no decision for the parent to make. If a child server provides both protocols, and the query to the parent was made through IPv4, I don't understand the point of including AAAA; and vice versa. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 15 19:06:24 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10666 for ; Tue, 15 Jul 2003 19:06:17 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FMdZmb023438 for ; Wed, 16 Jul 2003 00:39:35 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6FMdZKS023437 for dnsop-outgoing; Wed, 16 Jul 2003 00:39:35 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6FMdTmb023432 for ; Wed, 16 Jul 2003 00:39:29 +0200 (MEST) Received: from [1.142.31.174] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.6p2/8.12.3) with ESMTP id h6FMdHtU046612; Tue, 15 Jul 2003 18:39:25 -0400 (EDT) (envelope-from brad.knowles@skynet.be) Mime-Version: 1.0 X-Sender: bs663385@pop.skynet.be Message-Id: In-Reply-To: <8DE727E2-B697-11D7-83E1-00039358A080@sun.com> References: <8DE727E2-B697-11D7-83E1-00039358A080@sun.com> Date: Tue, 15 Jul 2003 23:53:57 +0200 To: Alain Durand From: Brad Knowles Subject: Re: Stepping back on the DNS discovery discussion Cc: dnsop@cafax.se Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-dnsop@cafax.se Precedence: bulk At 12:40 AM -0700 2003/07/15, Alain Durand wrote: > That is, if there is already a mechanism to broadcast NTP > timestamp on the local network, this may be a good enough solution. NTP can be spoofed. How can you know whether or not to trust it? IMO, that requires some configuration -- either automatic, or manual. If the latter, you look in a file that tells you which servers to trust. Even that can be spoofed, unless you use cryptographic authentication. If automatic, then you have to have a way to get authoritative configuration information that can be trusted. This can be a bit of a chicken-vs-egg problem. DHCP may or may not be the best way to hand out NTP configuration information, but it would seem to be one reasonable approach. I'm sure there are others. However, before going too far down the NTP rathole in a WG supposedly devoted to the DNS, I would encourage involving other contributors from ntp.org in this discussion, especially Harlan Stenn. I'm a contributor myself, but I just run the mail system and the mailing lists, and I'm not that intimate with the internals of NTP itself. -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++) #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 01:38:32 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18798 for ; Wed, 16 Jul 2003 01:38:31 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G5Fsmb028035 for ; Wed, 16 Jul 2003 07:15:54 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6G5Fsu8028034 for dnsop-outgoing; Wed, 16 Jul 2003 07:15:54 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from psg.com (psg.com [147.28.0.62]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G5Fqmb028029 for ; Wed, 16 Jul 2003 07:15:53 +0200 (MEST) Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19cedr-000IPM-T5; Wed, 16 Jul 2003 05:15:52 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19cedq-00077k-Jp; Wed, 16 Jul 2003 07:15:50 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 16 Jul 2003 07:15:50 +0200 To: Paul Vixie Cc: dnsop@cafax.se Subject: Re: regarding the respsize draft: preferring glue of certain types References: <20030714102216.40D2E1394C@sa.vix.com> Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > in the event where a delegation response is going to be truncated, it > is desireable that glue of the appropriate type be added preferentially. > if the query arrived by IPv4, then A RRs ought to be added first; if > the query arrived by IPv6, then AAAA RRs ought to be added first. this assumes that the transport available between the dns resolver and the dns server is correlated to the transport between the application client and the server. i am not sure this assumption holds. randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 02:16:12 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02342 for ; Wed, 16 Jul 2003 02:16:11 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G5uomb028468 for ; Wed, 16 Jul 2003 07:56:50 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6G5uoXC028467 for dnsop-outgoing; Wed, 16 Jul 2003 07:56:50 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from cyteen.hactrn.net (dsl092-066-068.bos1.dsl.speakeasy.net [66.92.66.68]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G5unmb028462 for ; Wed, 16 Jul 2003 07:56:49 +0200 (MEST) Received: from thangorodrim.hactrn.net (thangorodrim.ietf57.telekom.at [81.160.157.176]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 70391215 for ; Wed, 16 Jul 2003 01:56:48 -0400 (EDT) Received: from thangorodrim.hactrn.net (localhost [::1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id E41362329 for ; Wed, 16 Jul 2003 05:56:43 +0000 (UTC) Date: Wed, 16 Jul 2003 07:56:42 +0200 From: Rob Austein To: dnsop@cafax.se Subject: Re: regarding the respsize draft: preferring glue of certain types In-Reply-To: References: <20030714102216.40D2E1394C@sa.vix.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.2 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030716055643.E41362329@thangorodrim.hactrn.net> Sender: owner-dnsop@cafax.se Precedence: bulk > this assumes that the transport available between the dns resolver and > the dns server is correlated to the transport between the application > client and the server. i am not sure this assumption holds. I am fairly certain that there are cases in which we expect this assumption not to hold, since we expect to use dual-stack recursive name servers to avoid the namespace fragmentation problems described in draft-ietf-dnsop-ipv6-transport-guidelines-00.txt. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 02:28:43 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13889 for ; Wed, 16 Jul 2003 02:28:42 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G692mb028680 for ; Wed, 16 Jul 2003 08:09:02 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6G692jS028679 for dnsop-outgoing; Wed, 16 Jul 2003 08:09:02 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from stoneport.math.uic.edu (stoneport.math.uic.edu [131.193.178.160]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6G690mb028674 for ; Wed, 16 Jul 2003 08:09:01 +0200 (MEST) Received: (qmail 46190 invoked by uid 1016); 16 Jul 2003 06:09:31 -0000 Date: 16 Jul 2003 06:09:31 -0000 Message-ID: <20030716060931.46177.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: dnsop@cafax.se Subject: Re: regarding the respsize draft: preferring glue of certain types References: <20030714102216.40D2E1394C@sa.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-dnsop@cafax.se Precedence: bulk Randy Bush writes: > this assumes that the transport available between the dns resolver and > the dns server is correlated to the transport between the application > client and the server. No. The issue is delegations, particularly big delegations such as the DNS root servers' delegation of .com to 13 different DNS servers. Both levels are DNS; there isn't any ``application client'' here. Suppose that a .com DNS server has both A and AAAA. I don't see why the root servers would ever want to provide both addresses. Specifically: * If the query shows up through IPv4, why bother sending the .com server's AAAA address? Obviously the resolver is capable of reaching the A address. * If the query shows up through IPv6, why bother sending the .com server's A address? Obviously the resolver is capable of reaching the AAAA address. Vixie was suggesting omitting AAAA's past the 512-byte limit in the first case, and A's past the 512-byte limit in the second, but I don't see any use of the extra records even if they all fit into 512 bytes. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 03:46:14 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19331 for ; Wed, 16 Jul 2003 03:46:12 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G7LNmb029723 for ; Wed, 16 Jul 2003 09:21:23 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6G7LNQi029722 for dnsop-outgoing; Wed, 16 Jul 2003 09:21:23 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G7LHmb029717 for ; Wed, 16 Jul 2003 09:21:17 +0200 (MEST) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6G7LFAh008480 for ; Wed, 16 Jul 2003 01:21:15 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HI300BD8WFF52@edgemail1.Central.Sun.COM> for dnsop@cafax.se; Wed, 16 Jul 2003 01:21:15 -0600 (MDT) Received: from sun.com ([81.160.173.145]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HI300EDPWFB73@mail.sun.net> for dnsop@cafax.se; Wed, 16 Jul 2003 01:21:15 -0600 (MDT) Date: Wed, 16 Jul 2003 00:21:14 -0700 From: Alain Durand Subject: proposal for a compromise on DNS discovery To: dnsop@cafax.se Cc: rdroms@cisco.com Message-id: <155F1C85-B75E-11D7-9A7A-00039358A080@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT I have circulated this among several people yesterday and it may be time to bring this to the list. Our community is basically divided in two camps, the "conservatives", coming from v4 where the operational practice is to use DHCP for DNS discovery and would like to operate the same way for v6, and the "liberals", coming from v6 where the autoconfiguration story is build on Neighbor Discovery and RA/RS, and who would like to expand on this. As I explain in an earlier mail, the differences in the mode of operation are: - DHCPv6 can also pass the address of the NTP server - RA/RS have the unsolicited multicast provision that helps save bandwidth when a large number of nodes are autoconfiguring at the same time. The compromise solution I'd like to bring forward is to optionally piggy back the unsolicited multicast mode to DHCPv6-lite. More specifically, this would work the following way: At boot time, the client wait a bit (random 0..MAX1 seconds) and listen to unsolicited DHCPv6 DNS recursive server advertisements sent to the link-local-all-node multicast address. If noting comes, it send a DHCPv6 request. The DHCPv6 server answer to the unicast address of the requester and, if configured to do so (this would be optional), send the same thing to the link-local-all-node multicast address. Those multicast responses will be rate limited by the server, that is, if a second request come within MAX2 seconds, only the unicast answer will be sent. I'm sure there would be many details to work out. - Alain. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 05:04:02 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21983 for ; Wed, 16 Jul 2003 05:04:01 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G8f1mb000912 for ; Wed, 16 Jul 2003 10:41:01 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6G8f1th000911 for dnsop-outgoing; Wed, 16 Jul 2003 10:41:01 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from lord.fakat.com (h214n1fls32o264.telia.com [217.208.182.214]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G8f0mb000906 for ; Wed, 16 Jul 2003 10:41:00 +0200 (MEST) Received: from [81.160.147.201] ([81.160.147.201]) by lord.fakat.com (8.12.9/8.12.8) with ESMTP id h6G8hP8F087794; Wed, 16 Jul 2003 10:43:25 +0200 (CEST) (envelope-from jasko@fakat.com) Date: Wed, 16 Jul 2003 10:41:01 +0200 (CEST) From: Jasminko Mulahusic To: matthew.ford@bt.com cc: dnsop@cafax.se Subject: RE: Re: Stepping back on the DNS discovery discussion In-Reply-To: Message-ID: <20030716103828.G270@vagabond.imslab.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Tue, 15 Jul 2003 matthew.ford@bt.com wrote: > the RA/ND approach is 'right'. It might help if you could say why you > believe that, and specifically why you believe that using RA/ND is better > than using DHCP. > one argument that i have heard is that you don't have to have a running dhcp client on you device. jasminko > Mat. > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 05:20:37 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22505 for ; Wed, 16 Jul 2003 05:20:36 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G8wBmb001163 for ; Wed, 16 Jul 2003 10:58:11 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6G8wBkt001162 for dnsop-outgoing; Wed, 16 Jul 2003 10:58:11 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from mailout2.samsung.com ([203.254.224.25]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G8w4mb001154 for ; Wed, 16 Jul 2003 10:58:05 +0200 (MEST) Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HI400I0D0WHIM@mailout2.samsung.com> for dnsop@cafax.se; Wed, 16 Jul 2003 17:57:53 +0900 (KST) Received: from ep_ms3_bk (localhost [127.0.0.1]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HI400FCY0VAK6@mailout2.samsung.com> for dnsop@cafax.se; Wed, 16 Jul 2003 17:57:11 +0900 (KST) Received: from ep_was23 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0HI4005950VA33@ms3.samsung.com> for dnsop@cafax.se; Wed, 16 Jul 2003 17:57:10 +0900 (KST) Content-return: prohibited Date: Wed, 16 Jul 2003 17:57:07 +0900 From: =?EUC-KR?B?udq89sir?= Subject: Re: proposal for a compromise on DNS discovery To: Alain Durand , hinden@iprg.nokia.com Cc: dnsop@cafax.se, rdroms@cisco.com Reply-to: soohong.park@samsung.com Message-id: <0HI4005960VA33@ms3.samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20030716175707@soohong.park X-MTR: 20030716175707@soohong.park X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT Hi Alain Please look into my inline comments >Our community is basically divided in two camps, >the "conservatives", coming from v4 where the operational practice >is to use DHCP for DNS discovery and would like to operate the same way >for v6, and the "liberals", coming from v6 where the autoconfiguration >story is build on Neighbor Discovery and RA/RS, and who would like to >expand on this. agree >As I explain in an earlier mail, the differences in the mode of >operation are: >- DHCPv6 can also pass the address of the NTP server >- RA/RS have the unsolicited multicast provision that helps save >bandwidth when a large number of nodes are autoconfiguring at the same time. agree too >The compromise solution I'd like to bring forward is to optionally >piggy back the >unsolicited multicast mode to DHCPv6-lite. ?... why do you defense a liberty of IPv6 at this point ? >At boot time, the client wait a bit (random 0..MAX1 seconds) and listen >to unsolicited DHCPv6 DNS recursive server advertisements sent to the >link-local-all-node multicast address. As you know, IPv6 is already there >If noting comes, it send a DHCPv6 request. >The DHCPv6 server answer to the unicast address of the requester >and, if configured to do so (this would be optional), send the same >thing to the >link-local-all-node multicast address. >Those multicast responses will be rate limited by the server, >that is, if a second request come within MAX2 seconds, >only the unicast answer will be sent. If IPv6 node has dhcp functions, it can also make use of this procedure without piggy back the unsolicited multicast mode of dhcp. >I'm sure there would be many details to work out. do you want to make a complexity ? Please be sure that both DHCP and RA discovery method have each application domain/scope. In addition, if we don't have DNS discovery into RA, IPv6 can not provide full stateless autoconfiguration. This option is very very simple. If IPv6 host don't have dhcp functions, what is the possible solutions ? manually configure ? Daniel #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 05:24:24 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22709 for ; Wed, 16 Jul 2003 05:24:24 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G97Wmb001323 for ; Wed, 16 Jul 2003 11:07:32 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6G97Wg1001322 for dnsop-outgoing; Wed, 16 Jul 2003 11:07:32 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from cbibipnt08.hc.bt.com (saturn.bt.com [193.113.57.20]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G97Vmb001317 for ; Wed, 16 Jul 2003 11:07:31 +0200 (MEST) Received: by cbibipnt08.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3SRHBK4S>; Wed, 16 Jul 2003 10:07:48 +0100 Message-ID: From: matthew.ford@bt.com To: jasko@fakat.com Cc: dnsop@cafax.se Subject: RE: Re: Stepping back on the DNS discovery discussion Date: Wed, 16 Jul 2003 10:07:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Sender: owner-dnsop@cafax.se Precedence: bulk To replicate only the functionality of the RA/ND approach, the DHCP client required is very minimal indeed. Mat. > -----Original Message----- > From: Jasminko Mulahusic [mailto:jasko@fakat.com] > Sent: 16 July 2003 10:41 > To: Ford,M,Mat,XGH5 FORDM5 R > Cc: dnsop@cafax.se > Subject: RE: Re: Stepping back on the DNS discovery discussion > > > > > On Tue, 15 Jul 2003 matthew.ford@bt.com wrote: > > > the RA/ND approach is 'right'. It might help if you could > say why you > > believe that, and specifically why you believe that using > RA/ND is better > > than using DHCP. > > > > one argument that i have heard is that you don't have to have > a running > dhcp client on you device. > > jasminko > > > Mat. > > > #------------------------------------------------------------- > --------- > > # To unsubscribe, send a message to . > > > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 05:33:35 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23194 for ; Wed, 16 Jul 2003 05:33:34 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G97amb001331 for ; Wed, 16 Jul 2003 11:07:36 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6G97aMQ001330 for dnsop-outgoing; Wed, 16 Jul 2003 11:07:36 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from web20711.mail.yahoo.com (web20711.mail.yahoo.com [66.163.169.152]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6G97Ymb001325 for ; Wed, 16 Jul 2003 11:07:34 +0200 (MEST) Message-ID: <20030716090733.35527.qmail@web20711.mail.yahoo.com> Received: from [81.160.64.93] by web20711.mail.yahoo.com via HTTP; Wed, 16 Jul 2003 02:07:33 PDT Date: Wed, 16 Jul 2003 02:07:33 -0700 (PDT) From: Syam Madanapalli Subject: RE: proposal for a compromise on DNS discovery To: dnsop@cafax.se Cc: smadanaplli@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-dnsop@cafax.se Precedence: bulk I think the following approach probably will yield a better method for DNS Discovery. As DHCP may not be available in all netwokrs especially in small networks like Home Networks, the nodes first should try to get the DNS Resolver addresses from the RA messages, which will be inline with the IPv6 Autoconfiguration. If RA messages does not contain this information, and if DHCPv6 is availbe the nodes can use DHCPv6 to get the DNS Resolver Addresses. In case DHCP is also not available, Well Known Local/Anycast Addresses can be used as Default DNS Resolvers. Hovewer the draft 'draft-ietf-ipv6-dns-discovery-xx.txt' defines Well Known Site Local Addreses may need to be modified as site local addresses are being deprecated. Thank you, Syam __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 05:38:41 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23367 for ; Wed, 16 Jul 2003 05:38:39 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G9E2mb001441 for ; Wed, 16 Jul 2003 11:14:02 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6G9E2WN001440 for dnsop-outgoing; Wed, 16 Jul 2003 11:14:02 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G9Dtmb001435 for ; Wed, 16 Jul 2003 11:13:56 +0200 (MEST) Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6G9DsRi027493 for ; Wed, 16 Jul 2003 03:13:54 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HI400BFJ1N54Y@edgemail1.Central.Sun.COM> for dnsop@cafax.se; Wed, 16 Jul 2003 03:13:54 -0600 (MDT) Received: from sun.com ([81.160.173.145]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HI400CXN1N2VB@mail.sun.net> for dnsop@cafax.se; Wed, 16 Jul 2003 03:13:53 -0600 (MDT) Date: Wed, 16 Jul 2003 02:13:53 -0700 From: Alain Durand Subject: Re: proposal for a compromise on DNS discovery In-reply-to: <0HI4005960VA33@ms3.samsung.com> To: soohong.park@samsung.com Cc: hinden@iprg.nokia.com, dnsop@cafax.se, rdroms@cisco.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: multipart/alternative; boundary="Boundary_(ID_bXb0ejJNdI35w0/ZKo1W6g)" Sender: owner-dnsop@cafax.se Precedence: bulk --Boundary_(ID_bXb0ejJNdI35w0/ZKo1W6g) Content-type: text/plain; charset=ISO-2022-KR; format=flowed Content-Transfer-Encoding: 7BIT On Wednesday, July 16, 2003, at 01:57 AM, 9Z Please be sure that both DHCP and RA discovery method have each > application domain/scope. Having both solutions would be the worst outcome. Think about debugging nightmares. > In addition, if we don't have DNS discovery into RA, IPv6 can not > provide full > stateless autoconfiguration. This statement is at best FUD (Fear, Uncertainty & Doubt for the non english speakers) - Alain. --Boundary_(ID_bXb0ejJNdI35w0/ZKo1W6g) Content-type: text/enriched; charset=ISO-2022-KR Content-Transfer-Encoding: 7BIT On Wednesday, July 16, 2003, at 01:57 AM, AppleGothic9Z wrote: Please be sure that both DHCP and RA discovery method have each application domain/scope. Having both solutions would be the worst outcome. Think about debugging nightmares. In addition, if we don't have DNS discovery into RA, IPv6 can not provide full stateless autoconfiguration. This statement is at best FUD (Fear, Uncertainty & Doubt for the non english speakers) - Alain. --Boundary_(ID_bXb0ejJNdI35w0/ZKo1W6g)-- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 06:00:12 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23686 for ; Wed, 16 Jul 2003 06:00:10 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G9XNmb001799 for ; Wed, 16 Jul 2003 11:33:23 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6G9XM0m001798 for dnsop-outgoing; Wed, 16 Jul 2003 11:33:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from cbibipnt03.HC.BT.COM (saturn.bt.com [193.113.57.20]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6G9XHmb001793 for ; Wed, 16 Jul 2003 11:33:17 +0200 (MEST) Received: by cbibipnt03.hc.bt.com with Internet Mail Service (5.5.2654.89) id <3SWD3711>; Wed, 16 Jul 2003 10:33:33 +0100 Message-ID: From: matthew.ford@bt.com To: soohong.park@samsung.com, Alain.Durand@Sun.COM, hinden@iprg.nokia.com Cc: dnsop@cafax.se, rdroms@cisco.com Subject: RE: proposal for a compromise on DNS discovery Date: Wed, 16 Jul 2003 10:33:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) content-class: urn:content-classes:message Content-Type: text/plain; charset="KS_C_5601-1987" Sender: owner-dnsop@cafax.se Precedence: bulk > -----Original Message----- > From: soohong.park@samsung.com [mailto:soohong.park@samsung.com] > Sent: 16 July 2003 10:57 > > If IPv6 host don't have dhcp functions, what is the possible > solutions ? An IPv6 host needs very minimal dhcp functions to request and receive recursive name server configuration data. Mat. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 06:47:10 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24877 for ; Wed, 16 Jul 2003 06:47:09 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6GAEgmb002500 for ; Wed, 16 Jul 2003 12:14:42 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6GAEgd1002499 for dnsop-outgoing; Wed, 16 Jul 2003 12:14:42 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6GAEfmb002494 for ; Wed, 16 Jul 2003 12:14:41 +0200 (MEST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 25A23137F41; Wed, 16 Jul 2003 03:14:40 -0700 (PDT) To: "D. J. Bernstein" Cc: dnsop@cafax.se Subject: Re: regarding the respsize draft: preferring glue of certain types In-Reply-To: Message from "D. J. Bernstein" of "15 Jul 2003 16:09:07 -0000." <20030715160907.25742.qmail@cr.yp.to> Date: Wed, 16 Jul 2003 03:14:40 -0700 Message-ID: <69788.1058350480@shell.nominum.com> From: Jim Reid Sender: owner-dnsop@cafax.se Precedence: bulk >>>>> "djb" == D J Bernstein writes: djb> As for mixing A and AAAA in delegations, I don't understand djb> the benefit to having both in the first place. If a child djb> server provides only one protocol, there's no decision for djb> the parent to make. If a child server provides both djb> protocols, and the query to the parent was made through IPv4, djb> I don't understand the point of including AAAA; and vice djb> versa. You're making a false assumption that the transport protocol used for querying the server matters to the end client. An authoritative server could well be answering queries over IPv4 from a dual-stack full service resolver that's serving IPv6-only stub resolvers. Those end clients will not be happy to get A records instead of AAAAs. Or that full service resolver may have a (policy) preference for querying over IPv6 and only uses IPv4 as a last resort. These scenarios may well be somewhat hypothetical but they are not unreasonable or unrealistic. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 08:02:54 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26921 for ; Wed, 16 Jul 2003 08:02:53 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6GBafmb003347 for ; Wed, 16 Jul 2003 13:36:41 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6GBaf1b003346 for dnsop-outgoing; Wed, 16 Jul 2003 13:36:41 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from web10006.mail.yahoo.com (web10006.mail.yahoo.com [216.136.130.42]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6GBadmb003341 for ; Wed, 16 Jul 2003 13:36:39 +0200 (MEST) Message-ID: <20030716113638.79925.qmail@web10006.mail.yahoo.com> Received: from [81.160.98.35] by web10006.mail.yahoo.com via HTTP; Wed, 16 Jul 2003 04:36:38 PDT Date: Wed, 16 Jul 2003 04:36:38 -0700 (PDT) From: Jaehoon Jeong Subject: Re: proposal for a compromise on DNS discovery To: Alain Durand Cc: dnsop@cafax.se In-Reply-To: <155F1C85-B75E-11D7-9A7A-00039358A080@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-dnsop@cafax.se Precedence: bulk Thanks for your good proposal. As I said before, I believe, the RA-based and DHCP-based DNS discoveries are complementaty each other. One of them can not be the best. Just like IPv6 address autoconfiguration scenario, the RA-based and DHCP-based DNS discoveries can be used very well together. I think most of IPv6 hosts will have DHCPv6 client. Unless DNS information is piggybacked, IPv6 host just conforms to DHCPv6 procedure for DNS discovery. The approach of DHCP-lite announcing DNS information overrides IPv6 RA advertisement. IMHO, it is enough for one of RA and DHCP to announce IPv6 prefix and DNS information. In wireless networks, such as HMIPv6 and NEMO, MAP or MR announce IPv6 prefix information periodically. If piggybacking DNS information in RA, there is no need of additional delay for finding out DNS information. Your proposal complicates DHCP operation and usage, I think. DHCP is not almighty in all environments, and just one of many solutions. I am also one of non-english speakers. Thanks, Alain. /Jaehoon Paul --- Alain Durand wrote: > I have circulated this among several people > yesterday and it may be time > to bring this to the list. > > Our community is basically divided in two camps, > the "conservatives", coming from v4 where the > operational practice > is to use DHCP for DNS discovery and would like to > operate the same way > for v6, and the "liberals", coming from v6 where the > autoconfiguration > story is build on Neighbor Discovery and RA/RS, and > who would like to > expand on this. > > As I explain in an earlier mail, the differences in > the mode of > operation are: > - DHCPv6 can also pass the address of the NTP server > - RA/RS have the unsolicited multicast provision > that helps save > bandwidth > when a large number of nodes are autoconfiguring > at the same time. > > The compromise solution I'd like to bring forward is > to optionally > piggy back the > unsolicited multicast mode to DHCPv6-lite. > > More specifically, this would work the following > way: > > At boot time, the client wait a bit (random 0..MAX1 > seconds) and listen > to unsolicited DHCPv6 DNS recursive server > advertisements sent to the > link-local-all-node multicast address. > If noting comes, it send a DHCPv6 request. > The DHCPv6 server answer to the unicast address of > the requester > and, if configured to do so (this would be > optional), send the same > thing to the > link-local-all-node multicast address. > Those multicast responses will be rate limited by > the server, > that is, if a second request come within MAX2 > seconds, > only the unicast answer will be sent. > > I'm sure there would be many details to work out. > > - Alain. > > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 09:01:39 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28532 for ; Wed, 16 Jul 2003 09:01:37 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6GCVomb004044 for ; Wed, 16 Jul 2003 14:31:50 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6GCVoBC004043 for dnsop-outgoing; Wed, 16 Jul 2003 14:31:50 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6GCVimb004038 for ; Wed, 16 Jul 2003 14:31:49 +0200 (MEST) Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Jul 2003 14:31:15 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Subject: TR : Stepping back on the DNS discovery discussion Date: Wed, 16 Jul 2003 14:31:14 +0200 Message-ID: Thread-Topic: Stepping back on the DNS discovery discussion Thread-Index: AcNKp3BcGLme/3bGRg6WCQV/zwXXLQAH1pIQADJzKtAAAUnagA== From: "BELOEIL Luc FTRD/DMI/CAE" To: , X-OriginalArrivalTime: 16 Jul 2003 12:31:15.0928 (UTC) FILETIME=[267B0580:01C34B96] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h6GCVnmb004039 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit (sorry it seems I have encountered pb to send messages...) Hi Alain, > -----Message d'origine----- > De : Alain Durand [mailto:Alain.Durand@Sun.COM] > Envoyé : mardi 15 juillet 2003 09:40 I agree, we should first have a clear consensus on requirements for "DNS discovery". > A) Rob, in his introduction, pointed at a number a functions a node > could I agree that point 1- is the most critical requirement for basic services. It's not clear for me how to evaluate criticity of other points. > B) The second major element to study is the desired/required mode of > operation. As far as I know, 3 solutions have been documented: - well-known site-local IPv6 addresses... IMHO, that solution depends on decision of ipv6 wg upon local addresses - DHCPv6 (+ DHCP-lite) - RA-based solution Some guys had also spoken about SLPv6. But at last meeting, Bob pointed that a service discovery protocol should not be used for that (no one answered to that). As DNS is a critical service between "applications world" and "IP layer world", we might be careful on consequences. From application point of view, we might ask in the future to extende that solution to other type of services (NTP, ...). In that way, RA-based solution might not be the good solution, because I do think that RA must not be extended to any sort of service discovery. Any idea about that? > C) A third element in this discussion is the compatibility with the > IPv4 model. I agree that we need an _administrative model_ in IPv6. But I don't really understand that within that discussion. Do you have in mind O-bit et al? Anyway could you clarify? > - Alain. > > #------------------------------------------------------------- > --------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 09:04:08 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28671 for ; Wed, 16 Jul 2003 09:04:08 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6GCdnmb004165 for ; Wed, 16 Jul 2003 14:39:49 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6GCdndO004164 for dnsop-outgoing; Wed, 16 Jul 2003 14:39:49 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6GCdfmb004159 for ; Wed, 16 Jul 2003 14:39:42 +0200 (MEST) From: Masataka Ohta Message-Id: <200307161229.VAA06457@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id VAA06457; Wed, 16 Jul 2003 21:28:47 +0859 Subject: Re: proposal for a compromise on DNS discovery In-Reply-To: <155F1C85-B75E-11D7-9A7A-00039358A080@sun.com> from Alain Durand at "Jul 16, 2003 00:21:14 am" To: Alain Durand Date: Wed, 16 Jul 2003 21:28:45 +0859 () CC: dnsop@cafax.se, rdroms@cisco.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk Alain; Before trying to compromise, can you, at least, clarify your requirement? > - DHCPv6 can also pass the address of the NTP server I think NTP configuration is obsoleted. Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 11:33:52 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06165 for ; Wed, 16 Jul 2003 11:33:49 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6GF2emb009493 for ; Wed, 16 Jul 2003 17:02:40 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6GF2eQx009492 for dnsop-outgoing; Wed, 16 Jul 2003 17:02:40 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6GF2Ymb009481 for ; Wed, 16 Jul 2003 17:02:34 +0200 (MEST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h6GF2CR14745; Wed, 16 Jul 2003 17:02:12 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h6GF0gof045923; Wed, 16 Jul 2003 17:00:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200307161500.h6GF0gof045923@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Masataka Ohta cc: Alain Durand , dnsop@cafax.se, rdroms@cisco.com Subject: Re: proposal for a compromise on DNS discovery In-reply-to: Your message of Wed, 16 Jul 2003 21:28:45 +0859. <200307161229.VAA06457@necom830.hpcl.titech.ac.jp> Date: Wed, 16 Jul 2003 17:00:42 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-dnsop@cafax.se Precedence: bulk In your previous mail you wrote: Alain; Before trying to compromise, can you, at least, clarify your requirement? > - DHCPv6 can also pass the address of the NTP server I think NTP configuration is obsoleted. => all the crypto things I know are valid only at limited amount of time. In fact the military measure of a secret is the duration one can expect it will remain secret. So as soon as there is some kind of security involved in the network (and it should be :-), it is critical to have a good and secure source of the current date. The protocol which provides this is NTP: it synchronizes all boxes (i.e., all boxes have the same time) and with a good reference it can synchronize all boxes to the right time. Therefore NTP is a part of the initial service discovery stuff (IMHO this has nothing to do in the dnsop WG as it can't be restricted to DNS server discovery, but the IPv6 WG already tried to solve the whole issue and failed...). Regards Francis.Dupont@enst-bretagne.fr PS: NTP is very useful for management too, an argument I used many (~10) years ago when I was at the head of the RIPE DNS TF to recommend to make all routers (the active equipments at this time) NTP clients or peers. PPS: Obviously there is a bootstrap problem with secure NTP. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 12:39:37 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08067 for ; Wed, 16 Jul 2003 12:39:36 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6GG9Kmb010401 for ; Wed, 16 Jul 2003 18:09:20 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6GG9KKY010400 for dnsop-outgoing; Wed, 16 Jul 2003 18:09:20 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6GG9Hmb010393 for ; Wed, 16 Jul 2003 18:09:18 +0200 (MEST) From: Masataka Ohta Message-Id: <200307161557.AAA07423@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA07423; Thu, 17 Jul 2003 00:57:13 +0900 Subject: Re: proposal for a compromise on DNS discovery In-Reply-To: <200307161500.h6GF0gof045923@givry.rennes.enst-bretagne.fr> from Francis Dupont at "Jul 16, 2003 05:00:42 pm" To: Francis Dupont Date: Thu, 17 Jul 2003 00:57:12 +0859 () CC: Alain Durand , dnsop@cafax.se, rdroms@cisco.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk Francis.Dupont@enst-bretagne.fr; > > - DHCPv6 can also pass the address of the NTP server > > I think NTP configuration is obsoleted. > > => all the crypto things I know are valid only at limited amount > of time. How many of the crypto things you know can be autoconfigured? > In fact the military measure of a secret is the duration > one can expect it will remain secret. So as soon as there is > some kind of security involved in the network (and it should be :-), So, it should be noted that root keys must also be periodically configured. > DNS server discovery, but the IPv6 WG already tried to solve the whole > issue and failed...). IPv6 WG has been trying to solve so many non-issues and failing. Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 13:29:53 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09355 for ; Wed, 16 Jul 2003 13:29:52 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6GH4Nmb011151 for ; Wed, 16 Jul 2003 19:04:23 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6GH4M8i011150 for dnsop-outgoing; Wed, 16 Jul 2003 19:04:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6GH4Lmb011145 for ; Wed, 16 Jul 2003 19:04:21 +0200 (MEST) Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA01063 for ; Wed, 16 Jul 2003 18:04:20 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id SAA00529 for ; Wed, 16 Jul 2003 18:04:20 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6GH4Ka04747 for dnsop@cafax.se; Wed, 16 Jul 2003 18:04:20 +0100 Date: Wed, 16 Jul 2003 18:04:20 +0100 From: Tim Chown To: dnsop@cafax.se Subject: Re: TR : Stepping back on the DNS discovery discussion Message-ID: <20030716170420.GH3731@login.ecs.soton.ac.uk> Mail-Followup-To: dnsop@cafax.se References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-dnsop@cafax.se Precedence: bulk On Wed, Jul 16, 2003 at 02:31:14PM +0200, BELOEIL Luc FTRD/DMI/CAE wrote: > > As DNS is a critical service between "applications world" and "IP layer world", we might be careful on consequences. From application point of view, we might ask in the future to extende that solution to other type of services (NTP, ...). In that way, RA-based solution might not be the good solution, because I do think that RA must not be extended to any sort of service discovery. Any idea about that? So where do you draw the boundary between "network device autoconfiguration" and "service discovery". For IPv4, you (manually or via DHCP) configure IPv4 address, netmask, gateway and DNS resolver(s) as the "basic" four components to be able to get up and running. In IPv6, when using stateless autoconfiguration, the RA mechanism takes care of the first three (because the stateless mechanism implies the /64 "netmask"), but the DNS resolver address(es) cannot be learnt (although I believe WinXP implements the well-known site local discovery method). So an interesting question is what we mean by "stateless autoconfiguration". I think this term is causing some of the religion in the discussion :) It seems that probably mean "autoconfiguration without servers (i.e. DHCPv6)", since there would have to be state (pre-configuration) in the router (the prefix configuration). The RA camp seems to want the routers to be able to issue DNS resolver information, not a separate full-blown DHCPv6 server. But it's not that clear cut as, for example, my home DSL router includes a DHCP server (as well my DNS server and print server and other stuff). The functionality is combined, all in a very cheap (<100 Euro) commodity box. So are we really concerned as to whether we need a separate DHCPv6 server on our network (and the overhead of that in ad-hoc networks), or that we would like a router to be able to provide DNS resolver information on link (such that we can plumb networks without needing a separate DHCPv6 box)? If the latter, then does it matter if the router does that via RA piggybacks or DHCPv6 Lite? What is the real difference in implementation cost? Of course the mode of operation is also an interesting issue, but it's possible for DHCPv6(Lite) to have an unsolicited response mode added, if that is felt to be important. Something has to configure the prefix information to the router, likewise the DNS information has to be configured. I don't think we've discusse that much, but distributing the DNS resolver information to multiple routers rather than one (or a small number of) DHCPv6 servers may require more thought. But in my home network, it'll all be in my DSL router :) Tim #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 14:35:51 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11728 for ; Wed, 16 Jul 2003 14:35:48 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6GHvomb012130 for ; Wed, 16 Jul 2003 19:57:50 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6GHvo3p012129 for dnsop-outgoing; Wed, 16 Jul 2003 19:57:50 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6GHvnmb012118 for ; Wed, 16 Jul 2003 19:57:49 +0200 (MEST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h6GHvTR17545; Wed, 16 Jul 2003 19:57:29 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h6GHu1of046429; Wed, 16 Jul 2003 19:56:01 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200307161756.h6GHu1of046429@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Masataka Ohta cc: Alain Durand , dnsop@cafax.se, rdroms@cisco.com Subject: Re: proposal for a compromise on DNS discovery In-reply-to: Your message of Thu, 17 Jul 2003 00:57:12 +0859. <200307161557.AAA07423@necom830.hpcl.titech.ac.jp> Date: Wed, 16 Jul 2003 19:56:01 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-dnsop@cafax.se Precedence: bulk In your previous mail you wrote: Francis.Dupont@enst-bretagne.fr; > > - DHCPv6 can also pass the address of the NTP server > > I think NTP configuration is obsoleted. > > => all the crypto things I know are valid only at limited amount > of time. How many of the crypto things you know can be autoconfigured? => my answer to the proper question "how many of devices which can be autoconfigured and don't use any crypto thing I know?" is none for recent (i.e., in this century) devices. > In fact the military measure of a secret is the duration > one can expect it will remain secret. So as soon as there is > some kind of security involved in the network (and it should be :-), So, it should be noted that root keys must also be periodically configured. => do it should be noted than nothing may stay valid forever, even root keys. Regards Francis.Dupont@enst-bretagne.fr #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 16 18:39:37 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21574 for ; Wed, 16 Jul 2003 18:39:36 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6GMC0mb015292 for ; Thu, 17 Jul 2003 00:12:00 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6GMC06b015291 for dnsop-outgoing; Thu, 17 Jul 2003 00:12:00 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from stoneport.math.uic.edu (stoneport.math.uic.edu [131.193.178.160]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6GMBxmb015286 for ; Thu, 17 Jul 2003 00:11:59 +0200 (MEST) Received: (qmail 91128 invoked by uid 1016); 16 Jul 2003 22:12:29 -0000 Date: 16 Jul 2003 22:12:29 -0000 Message-ID: <20030716221229.91127.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: dnsop@cafax.se Subject: Re: regarding the respsize draft: preferring glue of certain types References: <20030715160907.25742.qmail@cr.yp.to> <69788.1058350480@shell.nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-dnsop@cafax.se Precedence: bulk Jim Reid writes: > You're making a false assumption that the transport protocol used for > querying the server matters to the end client. No. We're talking about delegations. A parent DNS server, specifically one of the root DNS servers, provides child DNS server addresses, such as the .com DNS server addresses. The program using the .com DNS server addresses is the same DNS resolver that was talking to the root DNS server. Why is it useful for this DNS resolver to receive _both_ an A record and an AAAA record for a single .com DNS server? If it reached the root DNS server through IPv4, for example, then why would it want AAAA records for the .com DNS servers? ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 08:10:34 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02477 for ; Thu, 17 Jul 2003 08:10:33 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HBgg8W000453 for ; Thu, 17 Jul 2003 13:42:42 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HBgg41000451 for dnsop-outgoing; Thu, 17 Jul 2003 13:42:42 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HBge8W000443 for ; Thu, 17 Jul 2003 13:42:41 +0200 (MEST) Received: from shell.nominum.com (localhost [127.0.0.1]) by shell.nominum.com (Postfix) with ESMTP id 91AB2137F13; Thu, 17 Jul 2003 04:40:14 -0700 (PDT) To: "D. J. Bernstein" Cc: dnsop@cafax.se Subject: Re: regarding the respsize draft: preferring glue of certain types In-Reply-To: Message from "D. J. Bernstein" of "16 Jul 2003 22:12:29 -0000." <20030716221229.91127.qmail@cr.yp.to> Date: Thu, 17 Jul 2003 04:40:14 -0700 Message-ID: <882.1058442014@shell.nominum.com> From: Jim Reid Sender: owner-dnsop@cafax.se Precedence: bulk >>>>> "djb" == D J Bernstein writes: djb> The program using the .com DNS server addresses is the same djb> DNS resolver that was talking to the root DNS server. Why is djb> it useful for this DNS resolver to receive _both_ an A record djb> and an AAAA record for a single .com DNS server? Because this .com server has NO WAY of knowing if the querying server has a preference for IPv6 or IPv4 resource records. Or which of these is "better" for the resolving server. [And, by implication, that resolving server's clients which could include forwarding name servers.] My earlier mail why explained your assumption about using the query's transport protocol to determine this was flawed. I gave two counter examples: four if you swap the IPv6 issues for IPv4 and vice versa. Others have made the same point. I'm sorry if you are unable to understand this. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 08:10:34 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02479 for ; Thu, 17 Jul 2003 08:10:33 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HBg48W000538 for ; Thu, 17 Jul 2003 13:42:04 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HBg4sK000537 for dnsop-outgoing; Thu, 17 Jul 2003 13:42:04 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HBfw8W000530 for ; Thu, 17 Jul 2003 13:42:03 +0200 (MEST) Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Jul 2003 11:29:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE : TR : Stepping back on the DNS discovery discussion Date: Thu, 17 Jul 2003 11:29:19 +0200 Message-ID: Thread-Topic: TR : Stepping back on the DNS discovery discussion Thread-Index: AcNLvqT1Cc3nQwuSR1iqSLnvmW0bSgAgcWcQ From: "BELOEIL Luc FTRD/DMI/CAE" To: "Tim Chown" , X-OriginalArrivalTime: 17 Jul 2003 09:29:21.0706 (UTC) FILETIME=[E782A8A0:01C34C45] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h6HBg38W000533 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Hi Tim, Thanks you to react., My coments below > -----Message d'origine----- > De : Tim Chown [mailto:tjc@ecs.soton.ac.uk] > Envoyé : mercredi 16 juillet 2003 19:04 > À : dnsop@cafax.se > Objet : Re: TR : Stepping back on the DNS discovery discussion > > > On Wed, Jul 16, 2003 at 02:31:14PM +0200, BELOEIL Luc > FTRD/DMI/CAE wrote: > > > > As DNS is a critical service between "applications world" and "IP > > layer world", we might be careful on consequences. From application > > point of view, we might ask in the future to extende that > solution to > > other type of services (NTP, ...). In that way, RA-based solution > > might not be the good solution, because I do think that RA > must not be > > extended to any sort of service discovery. Any idea about that? > > So where do you draw the boundary between "network device > autoconfiguration" > and "service discovery". For IPv4, you (manually or via > DHCP) configure > IPv4 address, netmask, gateway and DNS resolver(s) as the > "basic" four > components to be able to get up and running. In IPv6, when > using stateless > autoconfiguration, the RA mechanism takes care of the first > three (because > the stateless mechanism implies the /64 "netmask"), but the > DNS resolver > address(es) cannot be learnt (although I believe WinXP implements the > well-known site local discovery method). > Yes indeed > So an interesting question is what we mean by "stateless > autoconfiguration". > I think this term is causing some of the religion in the > discussion :) It > seems that probably mean "autoconfiguration without servers > (i.e. DHCPv6)", since there would have to be state > (pre-configuration) in the router (the > prefix configuration). The RA camp seems to want the > routers to be able to > issue DNS resolver information, not a separate full-blown > DHCPv6 server. > Hum as far as I understand DHCP-lite solution,DHCP-lite is also a stateless solution. > But it's not that clear cut as, for example, my home DSL > router includes a DHCP server (as well my DNS server and > print server and other stuff). The functionality is combined, > all in a very cheap (<100 Euro) commodity box. > How much a solution is , is only one side of the issue, not all -it depends so much of the market ;+). I do not discuss that. > So are we really concerned as to whether we need a separate > DHCPv6 server on our network (and the overhead of that in > ad-hoc networks), or that we would > like a router to be able to provide DNS resolver information > on link (such that > we can plumb networks without needing a separate DHCPv6 box)? > If the latter, > then does it matter if the router does that via RA piggybacks > or DHCPv6 Lite? What is the real difference in implementation cost? > Good question, I don't still know. > Of course the mode of operation is also an interesting issue, > but it's possible for DHCPv6(Lite) to have an unsolicited > response mode added, if that is felt to be important. > That solution must be investigate also. > Something has to configure the prefix information to the > router, likewise the DNS information has to be configured. I > don't think we've discusse that much, but distributing the > DNS resolver information to multiple routers rather than one > (or a small number of) DHCPv6 servers may require more > thought. But in my home network, it'll all be in my DSL router :) > Some questions must still be investigated so that I could have a better opinion. - Can DHCP-lite work on the same link were there is a DHCP server, or a DHCP-relay? - is DHCLP-lite with multicast extension is still DHCP? ;+) - is RA-base solution actually much easier to implement? - How RA-based wil be implement, within the kernel, as a separate daemon? ... > Tim Luc > #------------------------------------------------------------- > --------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 08:11:21 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02537 for ; Thu, 17 Jul 2003 08:11:20 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HBoj8W001173 for ; Thu, 17 Jul 2003 13:50:45 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HBojVW001172 for dnsop-outgoing; Thu, 17 Jul 2003 13:50:45 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HBoi8W001162 for ; Thu, 17 Jul 2003 13:50:44 +0200 (MEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6H6EcO01414; Thu, 17 Jul 2003 09:14:38 +0300 Date: Thu, 17 Jul 2003 09:14:38 +0300 (EEST) From: Pekka Savola To: "D. J. Bernstein" cc: dnsop@cafax.se Subject: Re: regarding the respsize draft: preferring glue of certain types In-Reply-To: <20030716221229.91127.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On 16 Jul 2003, D. J. Bernstein wrote: > Jim Reid writes: > > You're making a false assumption that the transport protocol used for > > querying the server matters to the end client. > > No. > > We're talking about delegations. A parent DNS server, specifically one > of the root DNS servers, provides child DNS server addresses, such as > the .com DNS server addresses. > > The program using the .com DNS server addresses is the same DNS resolver > that was talking to the root DNS server. Why is it useful for this DNS > resolver to receive _both_ an A record and an AAAA record for a single > .com DNS server? If it reached the root DNS server through IPv4, for > example, then why would it want AAAA records for the .com DNS servers? Why do you think the resolver moving from parent to child is the *only* one using that information ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 08:13:12 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02640 for ; Thu, 17 Jul 2003 08:13:11 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HBmY8W001084 for ; Thu, 17 Jul 2003 13:48:34 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HBmYmh001083 for dnsop-outgoing; Thu, 17 Jul 2003 13:48:34 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HBmW8W001078 for ; Thu, 17 Jul 2003 13:48:33 +0200 (MEST) From: Masataka Ohta Message-Id: <200307171014.TAA10157@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA10157; Thu, 17 Jul 2003 19:14:26 +0900 Subject: Re: proposal for a compromise on DNS discovery In-Reply-To: <200307161756.h6GHu1of046429@givry.rennes.enst-bretagne.fr> from Francis Dupont at "Jul 16, 2003 07:56:01 pm" To: Francis Dupont Date: Thu, 17 Jul 2003 19:14:25 +0859 () CC: Alain Durand , dnsop@cafax.se, rdroms@cisco.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk Francis.Dupont@enst-bretagne.fr; > > => all the crypto things I know are valid only at limited amount > > of time. > > How many of the crypto things you know can be autoconfigured? > > => my answer to the proper question "how many of devices which > can be autoconfigured and don't use any crypto thing I know?" > is none for recent (i.e., in this century) devices. Yours is an improper question. Using autoconfiguration on non crypt things is fine. However, devices using crypto thing is secure only if they do not use autoconfiguration of the crypto thing. Answer the question. > > In fact the military measure of a secret is the duration > > one can expect it will remain secret. So as soon as there is > > some kind of security involved in the network (and it should be :-), > > So, it should be noted that root keys must also be periodically > configured. > > => do it should be noted than nothing may stay valid forever, even > root keys. > That's how security needs manual configuration. Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 08:14:40 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02725 for ; Thu, 17 Jul 2003 08:14:39 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HBfS8W000314 for ; Thu, 17 Jul 2003 13:41:28 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HBfSAO000313 for dnsop-outgoing; Thu, 17 Jul 2003 13:41:28 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HBfF8W000288 for ; Thu, 17 Jul 2003 13:41:25 +0200 (MEST) Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id h6H7qJNl832018; Thu, 17 Jul 2003 09:52:27 +0200 (CEST) Received: (from souissi@localhost) by kerkenna.nic.fr (8.11.6/8.9.3) id h6H7qC523335; Thu, 17 Jul 2003 09:52:12 +0200 Date: Thu, 17 Jul 2003 09:52:12 +0200 From: Mohsen Souissi To: "D. J. Bernstein" Cc: dnsop@cafax.se Subject: Re: regarding the respsize draft: preferring glue of certain types Message-ID: <20030717095212.A21862@kerkenna.nic.fr> References: <20030714102216.40D2E1394C@sa.vix.com> <20030716060931.46177.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030716060931.46177.qmail@cr.yp.to>; from djb@cr.yp.to on Wed, Jul 16, 2003 at 06:09:31AM -0000 Sender: owner-dnsop@cafax.se Precedence: bulk On 16 Jul, D. J. Bernstein wrote: | Randy Bush writes: | > this assumes that the transport available between the dns resolver and | > the dns server is correlated to the transport between the application | > client and the server. | | No. The issue is delegations, particularly big delegations such as the | DNS root servers' delegation of .com to 13 different DNS servers. Both | levels are DNS; there isn't any ``application client'' here. | | Suppose that a .com DNS server has both A and AAAA. I don't see why the | root servers would ever want to provide both addresses. Specifically: | | * If the query shows up through IPv4, why bother sending the .com | server's AAAA address? Obviously the resolver is capable of | reaching the A address. | | * If the query shows up through IPv6, why bother sending the .com | server's A address? Obviously the resolver is capable of reaching | the AAAA address. ==> You know that the second scenario cannot happen today unless the client can get some IPv6 address for the root server. As far as I know, even if some root servers already run IPv6, their IPv6 address is not present in the root zone. Putting AAAA glue records in the root zone for .COM or whatever TLD is the only way to let iterative resolvers reach TLD servers in both IPv4 and IPv6 as soon as they receive referrals from root servers. Maybe you want to read the IESG recommendation for RC Editor to add explicitely the note below to RFC1886bis (becoming DS) in order to make things very clear: " RFC Editor note: In the Abstract please change: s/Domain Name System/Domain Name System (DNS)/ s/RFC1886/RFC 1886/ Please add this at the end of the Introduction section: The IP protocol version used for querying resource records is independent of the protocol version of the resource records; e.g. IPv4 transport can be used to query IPv6 records and vice versa. " In one word, the parent is not supposed to decide on behalf of the client, which version of IP it has to use to reach the authoritative nameservers for the child. Hope this will help, Mohsen. | | Vixie was suggesting omitting AAAA's past the 512-byte limit in the | first case, and A's past the 512-byte limit in the second, but I don't | see any use of the extra records even if they all fit into 512 bytes. | | ---D. J. Bernstein, Associate Professor, Department of Mathematics, | Statistics, and Computer Science, University of Illinois at Chicago | #---------------------------------------------------------------------- | # To unsubscribe, send a message to . #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 08:36:26 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03889 for ; Thu, 17 Jul 2003 08:36:24 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HC7M8W001785 for ; Thu, 17 Jul 2003 14:07:22 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HC7MuT001784 for dnsop-outgoing; Thu, 17 Jul 2003 14:07:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HC7K8W001775 for ; Thu, 17 Jul 2003 14:07:21 +0200 (MEST) Received: from sandelman.ottawa.on.ca ([2002:51a0:4ea::1]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h6HAq0W26492 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Thu, 17 Jul 2003 06:52:04 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h6HAq0bP002127 for ; Thu, 17 Jul 2003 12:52:00 +0200 To: dnsop@cafax.se Subject: Re: TR : Stepping back on the DNS discovery discussion In-reply-to: Your message of "Wed, 16 Jul 2003 18:04:20 BST." <20030716170420.GH3731@login.ecs.soton.ac.uk> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 17 Jul 2003 12:51:59 +0200 Message-ID: <2125.1058439119@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-dnsop@cafax.se Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tim" == Tim Chown writes: Tim> So where do you draw the boundary between "network device Tim> autoconfiguration" Tim> and "service discovery". For IPv4, you (manually or via DHCP) Tim> configure Tim> IPv4 address, netmask, gateway and DNS resolver(s) as the "basic" Tim> four components to be able to get up and running. In IPv6, when Tim> using stateless That's all you need *TODAY*. Given only those things, you are completely insecure. Anyone can spoof your MAC address or IP address, anyone can feed to bad data, or spoof the MAC of the nexthop router, etc. If you just want IPv6 to be IPv4-with-bigger-addresses, then fine, add DNS info to the RA. But, NATv4 works just as well for many people. While some people feel that the location of the nearest print server isn't critical information - it *is* if you run a print shop, and I arrive in to print things. In fact, the location of the print server might be more important than the gateway!!!! It is all in the eye of the beholder. If you want to be useful, then we need all of the other things that we have been doing with DHCPv4 for years to be available reliably. This means many other things too. Put the address of the DHCPv6 server in the RA, if you want to put anything in the RA. I know that there are ways to address it otherwise as well. ] At IETF57 in Wien, Austria | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] printk("Just another Debian GNU/Linux using, kernel hacking, security guy");[ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPxZ/zoqHRg3pndX9AQGZ2QQAgUD6f2fgKwnVRP+RJoBTrVf1EXtwMEw2 sEZLfj1ucMCKumCtQJgNq5gTTiAJo7waYAezaY6fPgzWISmV9eWlUuVKqIj3Dus6 rrbWy0uZF80PtR935bVyZAw8QKIWzofD4c8eACz4AnH/GX5XWYacLuin4NZ0Z30Z Fkpbhscz+BU= =umqV -----END PGP SIGNATURE----- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 08:44:19 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04126 for ; Thu, 17 Jul 2003 08:44:17 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HCFs8W002144 for ; Thu, 17 Jul 2003 14:15:54 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HCFsJf002143 for dnsop-outgoing; Thu, 17 Jul 2003 14:15:54 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HCFq8W002138 for ; Thu, 17 Jul 2003 14:15:53 +0200 (MEST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h6HBNbR00711; Thu, 17 Jul 2003 13:23:37 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h6HBM4of048786; Thu, 17 Jul 2003 13:22:04 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200307171122.h6HBM4of048786@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Masataka Ohta cc: Alain Durand , dnsop@cafax.se, rdroms@cisco.com Subject: Re: proposal for a compromise on DNS discovery In-reply-to: Your message of Thu, 17 Jul 2003 19:14:25 +0859. <200307171014.TAA10157@necom830.hpcl.titech.ac.jp> Date: Thu, 17 Jul 2003 13:22:04 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-dnsop@cafax.se Precedence: bulk In your previous mail you wrote: > How many of the crypto things you know can be autoconfigured? > > => my answer to the proper question "how many of devices which > can be autoconfigured and don't use any crypto thing I know?" > is none for recent (i.e., in this century) devices. Yours is an improper question. => my argument is that autoconfigurated devices use crypto things, crypto things need a time service, then the question of autoconfiguration of time service is sound. I didn't speak about autoconfiguration of crypto things (i.e., this is a different problem: it should be discussed in another threat and likely in another list). Using autoconfiguration on non crypt things is fine. However, devices using crypto thing is secure only if they do not use autoconfiguration of the crypto thing. => no, my argument is they are not secure if they can't access to a time service. Regards Francis.Dupont@enst-bretagne.fr #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 08:45:35 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04157 for ; Thu, 17 Jul 2003 08:45:34 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HCHD8W002179 for ; Thu, 17 Jul 2003 14:17:13 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HCHD7j002178 for dnsop-outgoing; Thu, 17 Jul 2003 14:17:13 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from web10002.mail.yahoo.com (web10002.mail.yahoo.com [216.136.130.38]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6HCHB8W002173 for ; Thu, 17 Jul 2003 14:17:12 +0200 (MEST) Message-ID: <20030717081710.41184.qmail@web10002.mail.yahoo.com> Received: from [81.160.243.20] by web10002.mail.yahoo.com via HTTP; Thu, 17 Jul 2003 01:17:10 PDT Date: Thu, 17 Jul 2003 01:17:10 -0700 (PDT) From: Jaehoon Jeong Subject: Re: TR : Stepping back on the DNS discovery discussion To: Tim Chown Cc: dnsop@cafax.se, ipng@sunroof.eng.sun.com In-Reply-To: <20030716170420.GH3731@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-dnsop@cafax.se Precedence: bulk In this DNSOP meeting, RA-based DNS discovery has been being discussed in comparison with DHCP-based DNS discovery. As it seems that this discussion is related to IPv6 wg, I send this issue in CC to IPv6 wg for listening to IPv6 members' liberal opinions and comments. > For IPv4, you (manually or via DHCP) configure > IPv4 address, netmask, gateway and DNS resolver(s) > as the "basic" four > components to be able to get up and running. In > IPv6, when using stateless > autoconfiguration, the RA mechanism takes care of > the first three (because > the stateless mechanism implies the /64 "netmask"), > but the DNS resolver > address(es) cannot be learnt (although I believe > WinXP implements the > well-known site local discovery method). > For consistent and time-saving autoconfiguration, I think, we need to adopt one of two alternatives in sequence (stateless and stateful approaches). In IPv4 domain, DHCP is enough for the autoconfiguration. But, in IPv6, we introduced stateless autoconfiguration. Like Tim's opinion, DNS information is missing in the current IPv6 stateless autoconfiguration. Of course, DHCPv6 is a good solution. However, in order to get only DNS information, it is so limited direction for all kinds of IPv6 networks, such as home network, HMIPv6, NEMO and MANET connected to the Internet, to adopt only DHCPv6-based DNS discovery. IMHO, RA-based DNS discovery is a really really good companion with DHCP approach, not enemy or competitor. > So an interesting question is what we mean by > "stateless autoconfiguration". > I think this term is causing some of the religion in > the discussion :) It seems that probably > mean "autoconfiguration without > servers (i.e. DHCPv6)", > since there would have to be state > (pre-configuration) in the router (the > prefix configuration). The RA camp seems to want > the routers to be able to > issue DNS resolver information, not a separate > full-blown DHCPv6 server. > > But it's not that clear cut as, for example, my home > DSL router includes > a DHCP server (as well my DNS server and print > server and other stuff). > The functionality is combined, all in a very cheap > (<100 Euro) commodity box. > > So are we really concerned as to whether we need a > separate DHCPv6 server on > our network (and the overhead of that in ad-hoc > networks), or that we would > like a router to be able to provide DNS resolver > information on link (such that > we can plumb networks without needing a separate > DHCPv6 box)? If the latter, > then does it matter if the router does that via RA > piggybacks or DHCPv6 Lite? > What is the real difference in implementation cost? > I think no great difference. > Of course the mode of operation is also an > interesting issue, but it's possible > for DHCPv6(Lite) to have an unsolicited response > mode added, if that is felt > to be important. > Just in order to announce DNS information, isn't to run DHCPv6(Lite) overactive? RA-piggyback announcement of DNS information with prefix information is efficient in the respect of the amount of announced traffic. > Something has to configure the prefix information to > the router, likewise > the DNS information has to be configured. I don't > think we've discusse that much, Right, let's discuss further. > but distributing the DNS resolver information > to multiple routers rather > than one (or a small number of) DHCPv6 servers may > require more thought. In current Cisco router, we configure the addresses of recursive DNS servers for its own name resolution. Therefore, the DNS servers' addresses have already been configured. We only have to use the information so as to announce DNS information through RA message. How about? /Jaehoon Paul > But > in my home network, it'll all be in my DSL router :) > > Tim > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 08:54:45 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04460 for ; Thu, 17 Jul 2003 08:54:44 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HCTE8W002572 for ; Thu, 17 Jul 2003 14:29:14 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HCTE9b002571 for dnsop-outgoing; Thu, 17 Jul 2003 14:29:14 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from psg.com (psg.com [147.28.0.62]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HCTD8W002566 for ; Thu, 17 Jul 2003 14:29:14 +0200 (MEST) Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19d7sn-00020N-9b; Thu, 17 Jul 2003 12:29:13 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19d7sm-000HKg-7d; Thu, 17 Jul 2003 14:29:12 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 17 Jul 2003 14:29:11 +0200 To: Mohsen Souissi Cc: "D. J. Bernstein" , dnsop@cafax.se Subject: Re: regarding the respsize draft: preferring glue of certain types References: <20030714102216.40D2E1394C@sa.vix.com> <20030716060931.46177.qmail@cr.yp.to> <20030717095212.A21862@kerkenna.nic.fr> Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > You know that the second scenario cannot happen today unless the client > can get some IPv6 address for the root server. not necessarily. i could v4 to root server, v4 to com server, v6 to foo.com server, and so forth. randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 08:58:47 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04651 for ; Thu, 17 Jul 2003 08:58:46 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HCXR8W002698 for ; Thu, 17 Jul 2003 14:33:27 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HCXRRQ002697 for dnsop-outgoing; Thu, 17 Jul 2003 14:33:27 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from maya40.nic.fr (maya40.nic.fr [192.134.4.151]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HCXQ8W002688 for ; Thu, 17 Jul 2003 14:33:26 +0200 (MEST) Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id h6HCXKNl882154; Thu, 17 Jul 2003 14:33:20 +0200 (CEST) Received: (from souissi@localhost) by kerkenna.nic.fr (8.11.6/8.9.3) id h6HCXIF03950; Thu, 17 Jul 2003 14:33:18 +0200 Date: Thu, 17 Jul 2003 14:33:18 +0200 From: Mohsen Souissi To: Randy Bush Cc: dnsop@cafax.se Subject: Re: regarding the respsize draft: preferring glue of certain types Message-ID: <20030717143318.C32648@kerkenna.nic.fr> References: <20030714102216.40D2E1394C@sa.vix.com> <20030716060931.46177.qmail@cr.yp.to> <20030717095212.A21862@kerkenna.nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from randy@psg.com on Thu, Jul 17, 2003 at 02:29:11PM +0200 Sender: owner-dnsop@cafax.se Precedence: bulk On 17 Jul, Randy Bush wrote: | > You know that the second scenario cannot happen today unless the client | > can get some IPv6 address for the root server. | | not necessarily. i could v4 to root server, v4 to com server, v6 | to foo.com server, and so forth. ==> I was talking about querying the root-servers in v6 and having the AAAA for .com as described in the example ;-) Mohsen. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 09:02:15 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02478 for ; Thu, 17 Jul 2003 08:10:33 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HBfR8W000311 for ; Thu, 17 Jul 2003 13:41:27 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HBfRPL000310 for dnsop-outgoing; Thu, 17 Jul 2003 13:41:27 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from maya20.nic.fr (maya20.nic.fr [192.134.4.152]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HBfF8Y000288 for ; Thu, 17 Jul 2003 13:41:25 +0200 (MEST) Received: from kerkenna.nic.fr (kerkenna.nic.fr [192.134.4.98]) by maya40.nic.fr (8.12.4/8.12.4) with ESMTP id h6H81INl831137; Thu, 17 Jul 2003 10:01:18 +0200 (CEST) Received: (from souissi@localhost) by kerkenna.nic.fr (8.11.6/8.9.3) id h6H81FB23869; Thu, 17 Jul 2003 10:01:15 +0200 Date: Thu, 17 Jul 2003 10:01:15 +0200 From: Mohsen Souissi To: Alain Durand Cc: dnsop@cafax.se, rdroms@cisco.com Subject: Re: proposal for a compromise on DNS discovery Message-ID: <20030717100115.B21862@kerkenna.nic.fr> References: <155F1C85-B75E-11D7-9A7A-00039358A080@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5.1i In-Reply-To: <155F1C85-B75E-11D7-9A7A-00039358A080@sun.com>; from Alain.Durand@Sun.COM on Wed, Jul 16, 2003 at 12:21:14AM -0700 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit If this tradeoff proposal can help us move quickly to an operational solution which maybe quickly implemented and shipped in OS's, I fully support it. My concern is that while having this endless religious debate (thanks Tim for the word), people who want to deploy real and credible IPv6 networks still lack this critical feature (recursive name server discovery). Mohsen. On 16 Jul, Alain Durand wrote: | I have circulated this among several people yesterday and it may be time | to bring this to the list. | | Our community is basically divided in two camps, | the "conservatives", coming from v4 where the operational practice | is to use DHCP for DNS discovery and would like to operate the same way | for v6, and the "liberals", coming from v6 where the autoconfiguration | story is build on Neighbor Discovery and RA/RS, and who would like to | expand on this. | | As I explain in an earlier mail, the differences in the mode of | operation are: | - DHCPv6 can also pass the address of the NTP server | - RA/RS have the unsolicited multicast provision that helps save | bandwidth | when a large number of nodes are autoconfiguring at the same time. | | The compromise solution I'd like to bring forward is to optionally | piggy back the | unsolicited multicast mode to DHCPv6-lite. | | More specifically, this would work the following way: | | At boot time, the client wait a bit (random 0..MAX1 seconds) and listen | to unsolicited DHCPv6 DNS recursive server advertisements sent to the | link-local-all-node multicast address. | If noting comes, it send a DHCPv6 request. | The DHCPv6 server answer to the unicast address of the requester | and, if configured to do so (this would be optional), send the same | thing to the | link-local-all-node multicast address. | Those multicast responses will be rate limited by the server, | that is, if a second request come within MAX2 seconds, | only the unicast answer will be sent. | | I'm sure there would be many details to work out. | | - Alain. | | #---------------------------------------------------------------------- | # To unsubscribe, send a message to . | -- Mohsen Souissi *********************************************************************** * AFNIC - http://www.afnic.fr/ * ***************************************+******************************* * mailto:Mohsen.Souissi@nic.fr * * Tél. : +33 1 39 30 83 40 | Fax : +33 1 39 30 83 01 * *--------------------------------+------------------------------------* * Immeuble International - 2, rue Stephenson - Montigny le Bretonneux * * 78181 Saint Quentin en Yvelines Cedex * *********************************************************************** #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 09:34:10 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05931 for ; Thu, 17 Jul 2003 09:34:09 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HD5H8W003591 for ; Thu, 17 Jul 2003 15:05:17 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HD5Hsm003590 for dnsop-outgoing; Thu, 17 Jul 2003 15:05:17 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HD5F8W003585 for ; Thu, 17 Jul 2003 15:05:16 +0200 (MEST) Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Jul 2003 15:05:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE : TR : Stepping back on the DNS discovery discussion Date: Thu, 17 Jul 2003 15:05:13 +0200 Message-ID: Thread-Topic: TR : Stepping back on the DNS discovery discussion Thread-Index: AcNMX1uM9Mw8gKcATeK/vxKMthR0gQABEteQ From: "BELOEIL Luc FTRD/DMI/CAE" To: "Michael Richardson" , X-OriginalArrivalTime: 17 Jul 2003 13:05:14.0720 (UTC) FILETIME=[101BBE00:01C34C64] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h6HD5G8W003586 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Hi Michael, > -----Message d'origine----- > De : Michael Richardson [mailto:mcr@sandelman.ottawa.on.ca] > Envoyé : jeudi 17 juillet 2003 12:52 > À : dnsop@cafax.se > Objet : Re: TR : Stepping back on the DNS discovery discussion > > > -----BEGIN PGP SIGNED MESSAGE----- > > > >>>>> "Tim" == Tim Chown writes: > Tim> So where do you draw the boundary between "network device > Tim> autoconfiguration" > Tim> and "service discovery". For IPv4, you (manually > or via DHCP) > Tim> configure > Tim> IPv4 address, netmask, gateway and DNS resolver(s) > as the "basic" > Tim> four components to be able to get up and running. > In IPv6, when > Tim> using stateless > > That's all you need *TODAY*. > > Given only those things, you are completely insecure. > Anyone can spoof your MAC address or IP address, anyone can > feed to bad data, or spoof the MAC of the nexthop router, etc. > > If you just want IPv6 to be IPv4-with-bigger-addresses, > then fine, add DNS info to the RA. But, NATv4 works just as > well for many people. > > While some people feel that the location of the nearest > print server isn't critical information - it *is* if you run > a print shop, and I arrive in to print things. In fact, the > location of the print server might be more important than the > gateway!!!! It is all in the eye of the beholder. > That is a good example where a STATEFULL architecture for autoconfiguration should be required! ;+) > If you want to be useful, then we need all of the other > things that we have been doing with DHCPv4 for years to be > available reliably. This means many other things too. > I agree on that but that means MANY things that should be clarified. > Put the address of the DHCPv6 server in the RA, if you want > to put anything in the RA. I know that there are ways to > address it otherwise as well. > Funny! ;+) > ] At IETF57 in Wien, Austria > | firewalls [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON > |net architect[ > ] mcr@sandelman.ottawa.on.ca > http://www.sandelman.ottawa.on.ca/ |device > driver[ ] > printk("Just another Debian GNU/Linux using, kernel hacking, > security guy");[ > > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.7 (GNU/Linux) > Comment: Finger me for keys > > iQCVAwUBPxZ/zoqHRg3pndX9AQGZ2QQAgUD6f2fgKwnVRP+RJoBTrVf1EXtwMEw2 > sEZLfj1ucMCKumCtQJgNq5gTTiAJo7waYAezaY6fPgzWISmV9eWlUuVKqIj3Dus6 > rrbWy0uZF80PtR935bVyZAw8QKIWzofD4c8eACz4AnH/GX5XWYacLuin4NZ0Z30Z > Fkpbhscz+BU= > =umqV > -----END PGP SIGNATURE----- > #------------------------------------------------------------- > --------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 14:09:45 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15999 for ; Thu, 17 Jul 2003 14:09:41 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HHSl8W006586 for ; Thu, 17 Jul 2003 19:28:47 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HHSlbD006585 for dnsop-outgoing; Thu, 17 Jul 2003 19:28:47 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HHSi8W006580 for ; Thu, 17 Jul 2003 19:28:45 +0200 (MEST) From: Masataka Ohta Message-Id: <200307171718.CAA12051@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA12051; Fri, 18 Jul 2003 02:18:20 +0900 Subject: Re: RE : TR : Stepping back on the DNS discovery discussion In-Reply-To: from BELOEIL Luc FTRD/DMI/CAE at "Jul 17, 2003 03:05:13 pm" To: BELOEIL Luc FTRD/DMI/CAE Date: Fri, 18 Jul 2003 02:18:19 +0859 () CC: Michael Richardson , dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk > > While some people feel that the location of the nearest > > print server isn't critical information - it *is* if you run > > a print shop, and I arrive in to print things. In fact, the > > location of the print server might be more important than the > > gateway!!!! It is all in the eye of the beholder. > > > > That is a good example where a STATEFULL architecture for autoconfiguration should be required! ;+) And that is one reason, among many, why ND is hopeless. To make IPv6 deployable, we should remove ND ASAP. Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 14:09:48 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15998 for ; Thu, 17 Jul 2003 14:09:41 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HHSw8W006594 for ; Thu, 17 Jul 2003 19:28:58 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HHSvbS006593 for dnsop-outgoing; Thu, 17 Jul 2003 19:28:57 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HHSt8W006588 for ; Thu, 17 Jul 2003 19:28:55 +0200 (MEST) From: Masataka Ohta Message-Id: <200307171713.CAA12023@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id CAA12023; Fri, 18 Jul 2003 02:13:24 +0900 Subject: Re: proposal for a compromise on DNS discovery In-Reply-To: <200307171122.h6HBM4of048786@givry.rennes.enst-bretagne.fr> from Francis Dupont at "Jul 17, 2003 01:22:04 pm" To: Francis Dupont Date: Fri, 18 Jul 2003 02:13:23 +0859 () CC: Alain Durand , dnsop@cafax.se, rdroms@cisco.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk Francis.Dupont; > In your previous mail you wrote: > > > How many of the crypto things you know can be autoconfigured? > > > > => my answer to the proper question "how many of devices which > > can be autoconfigured and don't use any crypto thing I know?" > > is none for recent (i.e., in this century) devices. > > Yours is an improper question. > > => my argument is that autoconfigurated devices use crypto things, > crypto things need a time service, then the question of autoconfiguration > of time service is sound. Wrong. It is insecure. Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 16:13:00 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20863 for ; Thu, 17 Jul 2003 16:12:46 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HI2k8W006955 for ; Thu, 17 Jul 2003 20:02:46 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HI2jmB006954 for dnsop-outgoing; Thu, 17 Jul 2003 20:02:45 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from stoneport.math.uic.edu (stoneport.math.uic.edu [131.193.178.160]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6HI2c8W006946 for ; Thu, 17 Jul 2003 20:02:41 +0200 (MEST) Received: (qmail 21035 invoked by uid 1016); 17 Jul 2003 18:02:51 -0000 Date: 17 Jul 2003 18:02:51 -0000 Message-ID: <20030717180251.21034.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: dnsop@cafax.se Subject: Re: regarding the respsize draft: preferring glue of certain types References: <20030716221229.91127.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-dnsop@cafax.se Precedence: bulk Pekka Savola writes: > Why do you think the resolver moving from parent to child is the *only* > one using that information ? Do you have some other use for the name a.gtld-servers.net? Obviously there's an issue if you (1) want to provide both A and AAAA records for your HTTP server, and (2) use the same name for your HTTP server and your DNS server. But #2 is an administrative error. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 16:16:47 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20990 for ; Thu, 17 Jul 2003 16:16:37 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HIbb8W007312 for ; Thu, 17 Jul 2003 20:37:37 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HIbb8f007311 for dnsop-outgoing; Thu, 17 Jul 2003 20:37:37 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from stoneport.math.uic.edu (stoneport.math.uic.edu [131.193.178.160]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6HIbQ8W007303 for ; Thu, 17 Jul 2003 20:37:33 +0200 (MEST) Received: (qmail 51840 invoked by uid 1016); 17 Jul 2003 18:37:48 -0000 Date: 17 Jul 2003 18:37:48 -0000 Message-ID: <20030717183748.51839.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: dnsop@cafax.se Subject: Re: regarding the respsize draft: preferring glue of certain types References: <20030714102216.40D2E1394C@sa.vix.com> <20030716060931.46177.qmail@cr.yp.to> <20030717095212.A21862@kerkenna.nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-dnsop@cafax.se Precedence: bulk Randy Bush writes: > i could v4 to root server, v4 to com server, v6 to foo.com server Sure. However, if the foo.com server has _both_ v4 and v6 addresses, then you could also reach it through v4. Furthermore, the .com server knows this, because you reached the .com server through v4. So why should the .com DNS server bother giving you _both_ v4 and v6 addresses for the foo.com DNS server? What exactly is the benefit that outweighs the cost of building and sending larger packets? Let me emphasize again that we're talking about DNS server addresses in delegations, not about HTTP server addresses. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 17 16:17:01 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21007 for ; Thu, 17 Jul 2003 16:16:49 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6HIVD8W007253 for ; Thu, 17 Jul 2003 20:31:13 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6HIVDmf007252 for dnsop-outgoing; Thu, 17 Jul 2003 20:31:13 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from stoneport.math.uic.edu (stoneport.math.uic.edu [131.193.178.160]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6HIV58W007246 for ; Thu, 17 Jul 2003 20:31:09 +0200 (MEST) Received: (qmail 45667 invoked by uid 1016); 17 Jul 2003 18:31:31 -0000 Date: 17 Jul 2003 18:31:31 -0000 Message-ID: <20030717183131.45666.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: dnsop@cafax.se Subject: Re: regarding the respsize draft: preferring glue of certain types References: <20030714102216.40D2E1394C@sa.vix.com> <20030716060931.46177.qmail@cr.yp.to> <20030717095212.A21862@kerkenna.nic.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-dnsop@cafax.se Precedence: bulk Mohsen Souissi writes: > As far as I know, even if some root servers already run IPv6, their > IPv6 address is not present in the root zone The resolver is configured with the addresses of the root DNS servers, or of servers that know the root addresses. There are two possibilities at this point: (1) The resolver can't reach IPv6 addresses. This means that the initial addresses have to be A---otherwise they _do not work_. Similarly, all the subsequent DNS server addresses used by that resolver have to be A---otherwise they _do not work_. (2) The resolver can reach IPv6 addresses. In this case, if a DNS server supports both IPv4 and IPv6, why would the resolver be interested in the DNS server's IPv4 address? What's the benefit? The rule I'm suggesting is ``In a delegation, if a child server has only A records, provide those records; if it has only AAAA records, provide those records; if it has both, provide A to clients that asked through IPv4, AAAA to clients that asked through IPv6.'' The records that I'm eliminating are the same ones that Vixie was talking about eliminating. The difference is that he'd provide them if they fit into 512 bytes (which they don't, for the high-level servers), while I would never provide them. The existing AAAA protocol would seem to require them in all circumstances (forcing truncation and TCP for the high-level servers), which is clearly a mistake. Let me emphasize that we are talking about _delegations_. These are DNS server addresses used by the resolver. They are not web server addresses passed through the resolver to browsers with varying connectivity. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Jul 18 04:15:39 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22188 for ; Fri, 18 Jul 2003 04:15:37 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6I7fp8W014287 for ; Fri, 18 Jul 2003 09:41:51 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6I7fpoG014286 for dnsop-outgoing; Fri, 18 Jul 2003 09:41:51 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from smtp.ietf57.telekom.at (smtp.ietf57.telekom.at [81.160.16.8]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6I7fo8W014281 for ; Fri, 18 Jul 2003 09:41:50 +0200 (MEST) Received: from paul2 ([81.160.243.20]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with SMTP id h6I7fbk13454; Fri, 18 Jul 2003 09:41:38 +0200 (MEST) Message-ID: <002e01c34cc5$89501120$14f3a051@etri.re.kr> From: "Jaehoon Jeong" To: "IPv6 WG" Cc: Subject: DNS discovery discussion Date: Fri, 18 Jul 2003 09:42:58 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nic.cafax.se id h6I7fo8W014282 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Hi IPv6 members. As it seems that the discussion of DNS discovery is related to IPv6 wg, I send this issue to IPv6 wg for listening to IPv6 members' liberal opinions and comments. In this DNSOP meeting and mailing list, RA-based DNS discovery has been being discussed in comparison with DHCP-based DNS discovery. You can find the mails related to this issue in the following link; http://www.cafax.se/dnsop/maillist/2003-07/maillist.html For consistent and time-saving autoconfiguration, I think, we need to adopt one of two alternatives in sequence (stateless and stateful approaches). In IPv4 domain, DHCP is enough for the autoconfiguration. But, in IPv6, we introduced stateless autoconfiguration. Like Tim's opinion, DNS information is missing in the current IPv6 stateless autoconfiguration. Of course, DHCPv6 is a good solution. However, in order to get only DNS information, it is so limited direction for all kinds of IPv6 networks, such as home network, HMIPv6, NEMO and MANET connected to the Internet, to adopt only DHCPv6-based DNS discovery. IMHO, RA-based DNS discovery is a really really good companion with DHCP approach, not enemy or competitor. Just in order to announce DNS information, isn't to run DHCPv6(Lite) overactive? RA-piggyback announcement of DNS information with prefix information is efficient in the respect of the amount of announced traffic. In current Cisco router, we configure the addresses of recursive DNS servers for its own name resolution. Therefore, the DNS servers' addresses have already been configured. We only have to use the information so as to announce DNS information through RA message. I think DNS discovery is indispensible in IPv6, as you know. RA camp including me continues to appeal the need of RA-based DNS discovery for IPv6 working more flexibly even in the environment where there is no DHCPv6. If many of IPv6 members think that RA-based DNS discovery is not necessary, there may be no reason to discuss any more and the RA-based DNS discovery should not be suggested forever. I wait for your liberal and frank criticism or opinions. /Jaehoon Paul #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Jul 18 04:15:41 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22213 for ; Fri, 18 Jul 2003 04:15:40 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6I7hL8W014295 for ; Fri, 18 Jul 2003 09:43:21 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6I7hKT1014294 for dnsop-outgoing; Fri, 18 Jul 2003 09:43:20 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6I7hJ8W014289 for ; Fri, 18 Jul 2003 09:43:19 +0200 (MEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6I7hFa16053; Fri, 18 Jul 2003 10:43:15 +0300 Date: Fri, 18 Jul 2003 10:43:14 +0300 (EEST) From: Pekka Savola To: "D. J. Bernstein" cc: dnsop@cafax.se Subject: Re: regarding the respsize draft: preferring glue of certain types In-Reply-To: <20030717183131.45666.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On 17 Jul 2003, D. J. Bernstein wrote: > (1) The resolver can't reach IPv6 addresses. This means that the > initial addresses have to be A---otherwise they _do not work_. > Similarly, all the subsequent DNS server addresses used by that > resolver have to be A---otherwise they _do not work_. You're assuming that if you reach one IPv4 address, you can reach all. > (2) The resolver can reach IPv6 addresses. In this case, if a DNS > server supports both IPv4 and IPv6, why would the resolver be > interested in the DNS server's IPv4 address? What's the benefit? You're assuming that if you reach one IPv6 address, you can reach all (, and that you have no use for IPv4 addresses for fallback). Also, assume the resolver is caching data. Someone else with different transport protocol capabilities asks the resolver about the addresses of these servers -- and get a partial response. Building assumptions like these doesn't sound like the way to ensure the robustness of DNS. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Jul 18 04:41:50 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23219 for ; Fri, 18 Jul 2003 04:41:49 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6I8B18W014595 for ; Fri, 18 Jul 2003 10:11:01 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6I8B1TD014594 for dnsop-outgoing; Fri, 18 Jul 2003 10:11:01 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6I8Ax8W014585 for ; Fri, 18 Jul 2003 10:11:00 +0200 (MEST) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6I8AwsP026622 for ; Fri, 18 Jul 2003 02:10:58 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HI700CJEO2947@edgemail1.Central.Sun.COM> for dnsop@cafax.se; Fri, 18 Jul 2003 02:10:58 -0600 (MDT) Received: from sun.com ([81.160.221.46]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HI700LR7NVQZB@mail.sun.net> for dnsop@cafax.se; Fri, 18 Jul 2003 02:07:05 -0600 (MDT) Date: Fri, 18 Jul 2003 01:07:08 -0700 From: Alain Durand Subject: Re: DNS discovery discussion In-reply-to: <002e01c34cc5$89501120$14f3a051@etri.re.kr> To: Jaehoon Jeong Cc: IPv6 WG , dnsop@cafax.se Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT This discussion has been going on in the v6 wg for a while without success, it is now to dnsop, let's go there and hope we'll make progress. no need to crosspost, IMHO. - Alain. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Jul 18 04:46:11 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23377 for ; Fri, 18 Jul 2003 04:46:11 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6I8J98W014711 for ; Fri, 18 Jul 2003 10:19:09 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6I8J9VL014710 for dnsop-outgoing; Fri, 18 Jul 2003 10:19:09 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from smtp.ietf57.telekom.at (smtp.ietf57.telekom.at [81.160.16.8]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6I8J88W014705 for ; Fri, 18 Jul 2003 10:19:08 +0200 (MEST) Received: from paul2 ([81.160.243.20]) by smtp.ietf57.telekom.at (8.11.7+Sun/8.10.2) with SMTP id h6I8Iqk13512; Fri, 18 Jul 2003 10:18:52 +0200 (MEST) Message-ID: <006401c34cca$bd0e1f70$14f3a051@etri.re.kr> From: "Jaehoon Jeong" To: "Alain Durand" Cc: "IPv6 WG" , References: Subject: Re: DNS discovery discussion Date: Fri, 18 Jul 2003 10:20:12 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nic.cafax.se id h6I8J98W014706 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit That's Okay. I appreciate your previous work related to DNS discovery until now. I really hope we'll solve the issue successfully. Thanks. Jaehoon Paul ----- Original Message ----- From: "Alain Durand" To: "Jaehoon Jeong" Cc: "IPv6 WG" ; Sent: Friday, July 18, 2003 5:07 PM Subject: Re: DNS discovery discussion > > This discussion has been going on in the v6 wg for a while without > success, > it is now to dnsop, let's go there and hope we'll make progress. > no need to crosspost, IMHO. > > - Alain. > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Jul 18 04:46:18 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23393 for ; Fri, 18 Jul 2003 04:46:17 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6I8KK8W014747 for ; Fri, 18 Jul 2003 10:20:20 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6I8KKNM014746 for dnsop-outgoing; Fri, 18 Jul 2003 10:20:20 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6I8KJ8W014741 for ; Fri, 18 Jul 2003 10:20:19 +0200 (MEST) Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6I8KIWv003575 for ; Fri, 18 Jul 2003 02:20:18 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HI700D0EOHTSJ@edgemail1.Central.Sun.COM> for dnsop@cafax.se; Fri, 18 Jul 2003 02:20:18 -0600 (MDT) Received: from sun.com ([81.160.221.46]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HI700LSGOHQZB@mail.sun.net> for dnsop@cafax.se; Fri, 18 Jul 2003 02:20:17 -0600 (MDT) Date: Fri, 18 Jul 2003 01:20:19 -0700 From: Alain Durand Subject: Re: DNS discovery discussion In-reply-to: <002e01c34cc5$89501120$14f3a051@etri.re.kr> To: Jaehoon Jeong Cc: dnsop@cafax.se Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT On Thursday, July 17, 2003, at 05:42 PM, Jaehoon Jeong wrote: > In current Cisco router, we configure the addresses of recursive DNS > servers for its own name resolution. > Therefore, the DNS servers' addresses have already been configured. We > only have to use the information > so as to announce DNS information through RA message. You could do the very same thing using DHCPv6-lite. The information is there, it is flowing from the router to the node downstream, in a push or pull mode. It really is just a question of packet format. Using the multicast extension to DHCPv6-lite I suggested few days ago, there isn't really any difference between the 2 approaches with regard to pass the DNS recursive server address. The advantage of the DHCPv6 approach is that you can pass other configuration information, like the address of the NTP server. > I think DNS discovery is indispensible in IPv6, as you know. RA camp > including me continues to appeal > the need of RA-based DNS discovery for IPv6 working more flexibly even > in the environment > where there is no DHCPv6. The RA camp keeps making the false assumption that using the DHCPv6-lite protocol to do this requires to have a big-iron DHCPv6 server on the network. This simply is not true. - Alain. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Jul 18 05:29:07 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24547 for ; Fri, 18 Jul 2003 05:29:06 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6I8w98W015174 for ; Fri, 18 Jul 2003 10:58:09 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6I8w9ok015173 for dnsop-outgoing; Fri, 18 Jul 2003 10:58:09 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from netcore.fi (netcore.fi [193.94.160.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6I8w78W015168 for ; Fri, 18 Jul 2003 10:58:08 +0200 (MEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h6I8w0616945; Fri, 18 Jul 2003 11:58:00 +0300 Date: Fri, 18 Jul 2003 11:58:00 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: Jaehoon Jeong , Subject: Re: DNS discovery discussion In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Fri, 18 Jul 2003, Alain Durand wrote: > You could do the very same thing using DHCPv6-lite. The information is > there, it is flowing from the router to the node downstream, in a push > or pull mode. It really is just a question of packet format. Using the > multicast extension to DHCPv6-lite I suggested few days ago, there isn't > really any difference between the 2 approaches with regard to pass the > DNS recursive server address. The advantage of the DHCPv6 approach is > that you can pass other configuration information, like the address of > the NTP server. 1) spec complexity 2) implementation complexity (there _may_ not be that huge a difference here, but probably some) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Jul 18 05:37:48 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24999 for ; Fri, 18 Jul 2003 05:37:48 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6I9968W015290 for ; Fri, 18 Jul 2003 11:09:06 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6I996sC015289 for dnsop-outgoing; Fri, 18 Jul 2003 11:09:06 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from stoneport.math.uic.edu (stoneport.math.uic.edu [131.193.178.160]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with SMTP id h6I9958W015284 for ; Fri, 18 Jul 2003 11:09:05 +0200 (MEST) Received: (qmail 4823 invoked by uid 1016); 18 Jul 2003 09:14:36 -0000 Date: 18 Jul 2003 09:14:36 -0000 Message-ID: <20030718091436.4808.qmail@cr.yp.to> Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html. From: "D. J. Bernstein" To: dnsop@cafax.se Subject: Re: regarding the respsize draft: preferring glue of certain types References: <20030717183131.45666.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-dnsop@cafax.se Precedence: bulk Pekka Savola writes: > Someone else with different transport protocol capabilities asks the > resolver about the addresses of these servers -- and get a partial response. So what? Let's focus on what actually works from the user's perspective, not on religious concepts such as ``partial responses.'' Can you give a concrete example showing how the user would encounter a failure? To forestall irrelevant examples, let me emphasize once again that we're talking about DNS server addresses, not HTTP server addresses. > You're assuming that if you reach one IPv4 address, you can reach all. Ever heard of ``global addressing''? Right now, you aren't on the Internet if you can't reach the entire public IPv4 address space. In the future, if everyone with a public IPv4 address acquires a public IPv6 address, you'll be able to deploy a site that doesn't have any IPv4 access. Either way, the assumption is valid. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Jul 18 06:30:19 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26132 for ; Fri, 18 Jul 2003 06:30:17 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6IA2u8W015689 for ; Fri, 18 Jul 2003 12:02:56 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6IA2uJO015688 for dnsop-outgoing; Fri, 18 Jul 2003 12:02:56 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6IA2s8W015683 for ; Fri, 18 Jul 2003 12:02:54 +0200 (MEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id DAA20386; Fri, 18 Jul 2003 03:02:53 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6IA2qZ18814; Fri, 18 Jul 2003 03:02:52 -0700 X-mProtect: <200307181002> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (81.160.151.202, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkGMi3F; Fri, 18 Jul 2003 03:02:50 PDT Message-Id: <4.3.2.7.2.20030718025445.032bf800@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Jul 2003 03:02:03 -0700 To: Tim Chown From: Bob Hinden Subject: Re: Stepping back on the DNS discovery discussion Cc: dnsop@cafax.se In-Reply-To: <20030715091906.GS18608@login.ecs.soton.ac.uk> References: <8DE727E2-B697-11D7-83E1-00039358A080@sun.com> <8DE727E2-B697-11D7-83E1-00039358A080@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dnsop@cafax.se Precedence: bulk Tim, >There was certainly a significant hum in this direction in the meeting. >Both DNS Lite and RA discovery methods can exist; each has an application >domain/scope. I agree with this view. I think we should proceed with the RA approach for learning the address(es) of the recursive DNS servers and optionally a search list. I think the RA approach has advantages in environments where a DNS (-lite) two packet exchanges would be a problem. I suspect that in many cases the addresses of the recursive DNS servers could be in the same RA message that prefixes and other link information were contained. This would be significant reduction in traffic as it would avoid any extra packets. Bob #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Jul 18 06:41:22 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26366 for ; Fri, 18 Jul 2003 06:41:21 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6IABP8W015749 for ; Fri, 18 Jul 2003 12:11:25 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6IABPJL015748 for dnsop-outgoing; Fri, 18 Jul 2003 12:11:25 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6IABN8W015743 for ; Fri, 18 Jul 2003 12:11:24 +0200 (MEST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id DAA21226; Fri, 18 Jul 2003 03:11:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h6IABMi25590; Fri, 18 Jul 2003 03:11:22 -0700 X-mProtect: <200307181011> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (81.160.151.202, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBMQIZ7; Fri, 18 Jul 2003 03:11:19 PDT Message-Id: <4.3.2.7.2.20030718030348.032cda28@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Jul 2003 03:10:36 -0700 To: Alain Durand From: Bob Hinden Subject: Re: DNS discovery discussion Cc: dnsop@cafax.se In-Reply-To: References: <002e01c34cc5$89501120$14f3a051@etri.re.kr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dnsop@cafax.se Precedence: bulk Alain, >You could do the very same thing using DHCPv6-lite. The information is there, >it is flowing from the router to the node downstream, in a push or pull mode. >It really is just a question of packet format. Using the multicast extension >to DHCPv6-lite I suggested few days ago, there isn't really any difference >between the 2 approaches with regard to pass the DNS recursive server address. >The advantage of the DHCPv6 approach is that you can pass other configuration I think you are suggesting extending DHCPv6-lite to have all of the mechanisms that ND currently has for sending multicast advertisements. I don't think this is quite a simple as you suggest. This seems to me like a lot of extra complexity and changes DHCPv6-lite from what I understand to be is a "profile" on the DHCPv6 specification. This would be either a new protocol or a non-trivial change to DHCPv6. This doesn't seem like a good way to proceed to me. Bob #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Jul 18 13:22:12 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05923 for ; Fri, 18 Jul 2003 13:22:11 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6IGgV8W018233 for ; Fri, 18 Jul 2003 18:42:31 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6IGgV27018232 for dnsop-outgoing; Fri, 18 Jul 2003 18:42:31 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6IGgU8W018227 for ; Fri, 18 Jul 2003 18:42:30 +0200 (MEST) Received: from dougbarton.net (12-234-22-23.client.attbi.com[12.234.22.23](untrusted sender)) by comcast.net (sccrmhc11) with SMTP id <2003071816422901100qpvple> (Authid: dougb141); Fri, 18 Jul 2003 16:42:29 +0000 Message-ID: <3F182373.6010708@dougbarton.net> Date: Fri, 18 Jul 2003 09:42:27 -0700 From: Doug Barton Organization: Triborough Bridge & Tunnel Authority User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Hinden CC: Tim Chown , dnsop@cafax.se Subject: Re: Stepping back on the DNS discovery discussion References: <8DE727E2-B697-11D7-83E1-00039358A080@sun.com> <8DE727E2-B697-11D7-83E1-00039358A080@sun.com> <4.3.2.7.2.20030718025445.032bf800@mailhost.iprg.nokia.com> X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Bob Hinden wrote: > Tim, > >> There was certainly a significant hum in this direction in the meeting. >> Both DNS Lite and RA discovery methods can exist; each has an application >> domain/scope. > > > I agree with this view. I think we should proceed with the RA approach > for learning the address(es) of the recursive DNS servers and optionally > a search list. This is exactly the kind of feature creep that bothers me about the RA dns discovery approach. The proponents' argument boils down to, "Well we have 3 things, so it'll be easy to add a 4th (resolver[s])." The logical progression of that is that if you're going to add the 4th anyway, it's not really useful without the 5th (search list), and now I've got everything else I need, can't I please have the 6th (widget) too? Please? Pretty please? Speaking as a client system implementor, I can almost see situations where the RA approach for stateless autoconfiguration of IP mask and gateway would be useful. However, by feature creeping RA you're basically forcing me to implement two autoconfiguration methods for every client, because if RA becomes "just robust enough" there are going to be networks where there is no dhcp. Speaking as a resolving name server/dhcp configurator, I can easily imagine situations where the routers are pointed at one set of resolving name servers, and I want the clients pointed at a different set. This increases the complexity of the RA approach one notch already, and I'm just shooting from the hip here. I'm sure others can think of more complex problems. The dhcp(lite) mechanism already exists to do everything that the RA DNS discovery could ever imagine doing, plus lots more. It's a scalable solution with a known implementation path. I fear that further muddying of the water is detrimental to both the long term goal of robust IPv6 networking, and the short term goal of encouraging IPv6 adoption and deployment. Doug -- Angel: We need you to distract the vampires. Buffy: Right. Xander: What are you going to do? Buffy: I'm going to kill them all. (Walking away) That oughta distract them. "When She Was Bad" - Buffy the Vampire Slayer, Season Two Episode One #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sat Jul 19 02:49:53 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07262 for ; Sat, 19 Jul 2003 02:49:52 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6J6Ib8W024576 for ; Sat, 19 Jul 2003 08:18:37 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6J6IbKR024575 for dnsop-outgoing; Sat, 19 Jul 2003 08:18:37 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6J6IX8W024570 for ; Sat, 19 Jul 2003 08:18:34 +0200 (MEST) From: Masataka Ohta Message-Id: <200307190606.PAA02785@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA02785; Sat, 19 Jul 2003 15:06:44 +0900 Subject: Preconfigured DNS To: dnsop@cafax.se Date: Sat, 19 Jul 2003 15:06:43 +0859 () X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk So, the only reasonable requirement so far is, as Rob Austin has seemingly presented (I was not at the meeting): remove configuration of recursive server addresses at installation and attached memo is a, perhaps the best, solution. Harmful complication caused by stateless/full autoconfiguration, false security and site local scope are removed completely. Masataka Ohta -- INTERNET DRAFT M. Ohta draft-ohta-preconfigured-dns-00.txt Tokyo Institute of Technology July 2003 Preconfigured DNS Server Addresses Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This memo describes how to make addresses of DNS servers preconfigured in clients. Well known anycast addresses, which are assigned to DNS servers, should be preconfigured to resolvers of clients. 1. Introduction The requirement addressed by this memo is to eliminate configuration effort of DNS clients. This memo defines several IP addresses to be used as a well known anycast IP addresses of DNS servers. The addresses are intended to be preconfigured to client resolvers to reduce (or eliminate) initial configuration effort on clients. This memo also describes sever and client operations. 2. Server Operation To serve stub resolvers, preconfigured DNS servers MUST offer M. Ohta Expires on January 20, 2004 [Page 1] INTERNET DRAFT Preconfigured DNS Server Addresses July 2003 recursive service if requested by their clients. While it should be assumed that the clients have no information to validate their identities to the servers, the servers may still limit their services to valid clients based on some (autoconfigured) property of the clients. For (perhaps the only) example, the servers may reply to requests from clients with certain ranges of IP addresses only. 3. Client Operation Clients SHOULD behave as a stub resolver forwarding queries to any of the preconfigured anycast address. Client resolvers SHOULD NOT have SBELT (root server) information, because root servers and their addresses sometimes changes requiring reconfiguration. Client resolvers MAY be able to perform recursive queries. 4. Assigned Addresses The following three IPv4 addresses are assigned as preconfigured DNS server addresses: route information of which should be propagated with a netmask of The following three IPv6 addresses are assigned as preconfigured DNS server addresses: route information of which should be propagated with a netmask of M. Ohta Expires on January 20, 2004 [Page 2] INTERNET DRAFT Preconfigured DNS Server Addresses July 2003 A client resolver can receive a UDP reply from an IP address different from one used to send a corresponding query, that UDP reply may use source address of non-anycast IP address of server. However, such a behavior is not available with TCP and anycast IP addresses MUST be used as source addresses of reply packets of TCP. 4.1. Scope Considerations The assigned anycast addresses are globally well known and have global scopes. On the other hand, servers with the anycast addresses have local scopes, boundaries between them is determined by a routing system. The boundaries many be dynamically determined with routing metric. In addition, route administrators may configure static boundaries. While there may be static boundaries at site boundaries, always requiring them eliminates useful cases, for example, of ISPs providing DNS servers for customer sites. Within a static boundary, there may be a single server for each anycast address, or there may be multiple servers sharing an anycast address, which may be useful for load distribution. Even if identities of the servers changes dynamically between a query and its reply, a simple exchange of UDP packets is not affected and TCP transactions detect sequence number inconsistencies and should attempt new ones. However, having multiple servers sharing an anycast address within a static boundary does not improve redundancy, because a DNS process on a server may die while a route to the server is still alive. Three anycast addresses are provided for the redundancy. 5. Security Considerations Cryptographic security requires some information securely (at least with authentication, even when public key cryptography is used) shared between servers and clients, which requires manual configuration. Thus, no cryptographic security, which makes the protocol complex with no security improvement, should be used by preconfigured client resolvers. M. Ohta Expires on January 20, 2004 [Page 3] INTERNET DRAFT Preconfigured DNS Server Addresses July 2003 The DNS server with the preconfigured addresses are still reasonably reliable, if local environment is reasonably secure, that is, there is no active attackers receiving queries to the anycast addresses of the servers and reply to them. 6. Author's Address Masataka Ohta Graduate School of Information Science and Engineering Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN Phone: +81-3-5734-3299 Fax: +81-3-5734-3299 EMail: mohta@necom830.hpcl.titech.ac.jp M. Ohta Expires on January 20, 2004 [Page 4] #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sun Jul 20 00:36:51 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29334 for ; Sun, 20 Jul 2003 00:36:50 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6K3uS8W002279 for ; Sun, 20 Jul 2003 05:56:28 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6K3uSFx002277 for dnsop-outgoing; Sun, 20 Jul 2003 05:56:28 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6K3uM8W002264 for ; Sun, 20 Jul 2003 05:56:24 +0200 (MEST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h6K3t8C10033 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sat, 19 Jul 2003 23:55:54 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h6IB76de008914 for ; Fri, 18 Jul 2003 13:07:06 +0200 To: dnsop@cafax.se Subject: Re: DNS discovery discussion In-reply-to: Your message of "Fri, 18 Jul 2003 03:10:36 PDT." <4.3.2.7.2.20030718030348.032cda28@mailhost.iprg.nokia.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 18 Jul 2003 13:07:06 +0200 Message-ID: <8912.1058526426@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-dnsop@cafax.se Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bob" == Bob Hinden writes: Bob> I think you are suggesting extending DHCPv6-lite to have all of the Bob> mechanisms that ND currently has for sending multicast Bob> advertisements. I don't think this is quite a simple as you I agree with Bob, this isn't the way to go. If, the IP that you put into the RA is the address of the DHCPv6-lite server, then you can ask *it* about the DNS server. (Getting the local domain name, print server, boot server, etc... that you might need) ] At IETF57 in Wien, Austria | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] printk("Just another Debian GNU/Linux using, kernel hacking, security guy");[ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPxfU2YqHRg3pndX9AQGIcQQAkozAXNkspwC7TQgnCgE5yKnGd8wyY9Ey qwS4yzRls0fq7RRwu62TSk/Nk/i6YHqfsH9II653/TE/XS/ofRioLPNQXPBMj8hf az847TRaaZU6SG+dCPlqEG+o8CnMsOiQIuZSmvIysxOUv4oNt5cxTwjLHs/EjB5K aDNMyAEVjkA= =dbmX -----END PGP SIGNATURE----- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sun Jul 20 00:36:56 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29350 for ; Sun, 20 Jul 2003 00:36:54 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6K3uT8W002280 for ; Sun, 20 Jul 2003 05:56:29 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6K3uSMU002278 for dnsop-outgoing; Sun, 20 Jul 2003 05:56:28 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6K3uM8W002265 for ; Sun, 20 Jul 2003 05:56:24 +0200 (MEST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h6K3t8E10033 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sat, 19 Jul 2003 23:55:54 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h6IB4vTV008865 for ; Fri, 18 Jul 2003 13:04:57 +0200 To: dnsop@cafax.se Subject: Re: Stepping back on the DNS discovery discussion In-reply-to: Your message of "Fri, 18 Jul 2003 03:02:03 PDT." <4.3.2.7.2.20030718025445.032bf800@mailhost.iprg.nokia.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 18 Jul 2003 13:04:57 +0200 Message-ID: <8863.1058526297@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-dnsop@cafax.se Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bob" == Bob Hinden writes: Bob> I think the RA approach has advantages in environments where a DNS Bob> (-lite) two packet exchanges would be a problem. I suspect that in Bob> many cases the addresses of the recursive DNS servers could be in Bob> the same RA message that prefixes and other link information were Bob> contained. This would be significant reduction in traffic as it Bob> would avoid any extra packets. okay, so we have decided that DNS is *so* much more important than any other services, that we will put it into the RA. Hardly surprising for dnsop :-) Do other services out there get space in the RA? Since we have explicitely, no state established, there will be no update to the reverse - unless one of several other proposal is also accepted. ] At IETF57 in Wien, Austria | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] printk("Just another Debian GNU/Linux using, kernel hacking, security guy");[ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPxfUV4qHRg3pndX9AQF2jwQA4qof+CaK3RdbGRupiZ4fRnhmYFY8MEAO 3sGUEJcpI45l3Qe0zb/viKnWMSxyRbUkAmRFJjyUnaZ+GCvUh1YcaR8rfJq2WiIU VhHc9Nbqv+QYxincOvkdCEgGCu0WsIjMzP/6LhrPR9GJm1UObdhiiLJ4UGgo1vZd Iljo6Bv/9GI= =uxdy -----END PGP SIGNATURE----- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sun Jul 20 11:36:04 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21502 for ; Sun, 20 Jul 2003 11:36:03 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6KF708W005499 for ; Sun, 20 Jul 2003 17:07:00 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6KF705Y005498 for dnsop-outgoing; Sun, 20 Jul 2003 17:07:00 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6KF6s8W005493 for ; Sun, 20 Jul 2003 17:06:59 +0200 (MEST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h6KF6GW11660 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 20 Jul 2003 11:06:22 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h6KF6gHx016814 for ; Sun, 20 Jul 2003 11:06:47 -0400 To: dnsop@cafax.se Subject: Re: DNS discovery discussion In-reply-to: Your message of "Fri, 18 Jul 2003 03:10:36 PDT." <4.3.2.7.2.20030718030348.032cda28@mailhost.iprg.nokia.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 20 Jul 2003 11:06:42 -0400 Message-ID: <16813.1058713602@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-dnsop@cafax.se Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bob" == Bob Hinden writes: Bob> I think you are suggesting extending DHCPv6-lite to have all of the Bob> mechanisms that ND currently has for sending multicast Bob> advertisements. I don't think this is quite a simple as you I agree with Bob, this isn't the way to go. If, the IP that you put into the RA is the address of the DHCPv6-lite server, then you can ask *it* about the DNS server. (Getting the local domain name, print server, boot server, etc... that you might need) ] At IETF57 in Wien, Austria | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] printk("Just another Debian GNU/Linux using, kernel hacking, security guy");[ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPxfU2YqHRg3pndX9AQGIcQQAkozAXNkspwC7TQgnCgE5yKnGd8wyY9Ey qwS4yzRls0fq7RRwu62TSk/Nk/i6YHqfsH9II653/TE/XS/ofRioLPNQXPBMj8hf az847TRaaZU6SG+dCPlqEG+o8CnMsOiQIuZSmvIysxOUv4oNt5cxTwjLHs/EjB5K aDNMyAEVjkA= =dbmX -----END PGP SIGNATURE----- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 23 06:13:06 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07439 for ; Wed, 23 Jul 2003 06:13:06 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6N9ZU8W002270 for ; Wed, 23 Jul 2003 11:35:30 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6N9ZUDD002269 for dnsop-outgoing; Wed, 23 Jul 2003 11:35:30 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6N9ZT8W002264 for ; Wed, 23 Jul 2003 11:35:29 +0200 (MEST) Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6N9ZQuG016878 for ; Wed, 23 Jul 2003 02:35:27 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn1-95.cisco.com [10.21.96.95]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAX13674; Wed, 23 Jul 2003 05:35:25 -0400 (EDT) Message-Id: <4.3.2.7.2.20030723053514.00b5ef68@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jul 2003 05:35:22 -0400 To: dnsop@cafax.se From: Ralph Droms Subject: Re: DNS discovery discussion Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dnsop@cafax.se Precedence: bulk Alain wrote: >The RA camp keeps making the false assumption that using the >DHCPv6-lite protocol to do this >requires to have a big-iron DHCPv6 server on the network. This simply >is not true. > > - Alain. Alain is correct - the machinery in a host and a router to exchange DHCPv6 Information-request/Reply messages is nowhere as complex as a full DHCPv6 implementation. We can demonstrate "DHCPv6-lite" in Cisco routers (in IOS). It was developed as a a samll part of a part-time project to implement DHCPv6 prefix delegation by three of us at Cisco (Ole Troan, Jun Xie and myself). - Ralph #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 23 06:27:56 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07743 for ; Wed, 23 Jul 2003 06:27:55 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6N9wt8W002509 for ; Wed, 23 Jul 2003 11:58:55 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6N9wsnP002508 for dnsop-outgoing; Wed, 23 Jul 2003 11:58:54 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6N9wr8W002503 for ; Wed, 23 Jul 2003 11:58:53 +0200 (MEST) Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 23 Jul 2003 03:05:21 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6N9wouD000874 for ; Wed, 23 Jul 2003 02:58:51 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn1-95.cisco.com [10.21.96.95]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AAX14950; Wed, 23 Jul 2003 05:58:48 -0400 (EDT) Message-Id: <4.3.2.7.2.20030723055111.0193d7e8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jul 2003 05:58:45 -0400 To: dnsop@cafax.se From: Ralph Droms Subject: Re: DNS discovery discussion In-Reply-To: <4.3.2.7.2.20030723053514.00b5ef68@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dnsop@cafax.se Precedence: bulk Regarding the development of a mechanism for multicast in DHCPv6-lite... The IPv4 community has been configuring hosts on IPv4 networks with DHCP on large networks for many years, and there has not been, to date, a demand for any mechanism to reduce the amount of DHCP traffic. I don't have specific figures, but I would imagine that - even in the case of synchronized startup of all the hosts on a link - the DHCP traffic would be no more than (and probably significantly less than) ARP and similar traffic. I wonder if the situation would be similar in an IPv6 network? I don't have any operational or measurement experience, so I don't know what the traffic looks like on a link where, say, 10,000 hosts start at the same time? Can someone comment or speculate on what the total traffic might look like and whether multicast DHCPv6 would have a significant impact on that traffic? - Ralph #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 23 22:56:00 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10996 for ; Wed, 23 Jul 2003 22:55:59 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6O2Sh8W010884 for ; Thu, 24 Jul 2003 04:28:43 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6O2Sgfo010883 for dnsop-outgoing; Thu, 24 Jul 2003 04:28:42 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6O2Se8W010878 for ; Thu, 24 Jul 2003 04:28:41 +0200 (MEST) From: Masataka Ohta Message-Id: <200307240213.LAA03407@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA03407; Thu, 24 Jul 2003 11:13:03 +0900 Subject: Re: Preconfigured DNS In-Reply-To: <200307190606.PAA02785@necom830.hpcl.titech.ac.jp> from Masataka Ohta at "Jul 19, 2003 03:06:43 pm" To: dnsop@cafax.se Date: Thu, 24 Jul 2003 11:13:00 +0859 () X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk I have (formally) submitted draft-ohta-preconfigured-dns-00.txt as a new ID. No RA. Not even DHCP(-lite). And it is so DNS centric to spend, though locally, a few routing table entries for DNS. Does it satisfy you? Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 24 01:25:15 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13429 for ; Thu, 24 Jul 2003 01:25:14 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6O4wr8W011973 for ; Thu, 24 Jul 2003 06:58:53 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6O4wr8O011972 for dnsop-outgoing; Thu, 24 Jul 2003 06:58:53 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6O4wo8W011967 for ; Thu, 24 Jul 2003 06:58:51 +0200 (MEST) From: Masataka Ohta Message-Id: <200307240446.NAA04398@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id NAA04398; Thu, 24 Jul 2003 13:46:32 +0900 Subject: Re: DNS discovery discussion In-Reply-To: <4.3.2.7.2.20030723055111.0193d7e8@funnel.cisco.com> from Ralph Droms at "Jul 23, 2003 05:58:45 am" To: Ralph Droms Date: Thu, 24 Jul 2003 13:46:31 +0859 () CC: dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk Ralph; > I wonder if the situation would be similar in an IPv6 > network? I don't have any operational or measurement > experience, so I don't know what the traffic looks > like on a link where, say, 10,000 hosts start at the > same time? Can someone comment or speculate on what > the total traffic might look like and > whether multicast DHCPv6 would have a significant > impact on that traffic? Some protocol such as IPv6 intensively use (link local) multicast. The reason is merely that, at the time such protocols were designed, some people believed, though they have been warned, that the Internet must operate over large clouds of public ATM networks, broadcast over which was impractical, which is true because ATM is impractical, and that ATM were multicast capable. By assuming large link layer, which violates the CATENET model, many protocols, including but not limited to IPv6 and IGMP, are damaged. Now, we can simply say, broadcast. Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 24 01:57:02 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13713 for ; Thu, 24 Jul 2003 01:57:00 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6O5WW8W012141 for ; Thu, 24 Jul 2003 07:32:32 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6O5WWdn012140 for dnsop-outgoing; Thu, 24 Jul 2003 07:32:32 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.114.50]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6O5WT8W012135 for ; Thu, 24 Jul 2003 07:32:30 +0200 (MEST) Received: from paulnb (paul3.etri.re.kr [129.254.112.196]) by pec.etri.re.kr (8.11.3/8.11.3) with SMTP id h6O5jgS09741; Thu, 24 Jul 2003 14:45:42 +0900 (KST) Message-ID: <00e201c351a4$cef190d0$c470fe81@etri.re.kr> From: "Jaehoon Paul Jeong" To: "Ralph Droms" Cc: "DNSOP WG" , , References: <4.3.2.7.2.20030723053514.00b5ef68@funnel.cisco.com> Subject: Re: DNS discovery discussion Date: Thu, 24 Jul 2003 14:31:16 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nic.cafax.se id h6O5WV8W012136 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit I agree partly with Alain and Ralph. However, I think, RA camp including me suggest that RA-based DNS Discovery is indispensible to ND. Of course, I believe that it can be used harmoniously with DHCPv6. Why should both stateless (ND) and stateful (DHCP) mechanisms not be developed and deployed for DNS Discovery? After the last ietf meeting, four authors (Daniel, Luc, Syam and me) has merged three drafts regarding RA-based DNS Discovery to make a new draft as follows. http://www.adhoc.6ants.net/~paul/data/draft-jeong-dnsop-ipv6-dns-discovery-00.txt We would like to propose this draft as DNSOP wg draft for further discussion. As open issues, the following are suggested; o How to optimize bandwidth on the link? o How to implement RA-based DNS discovery? o How to interact with stateful mechanism? o What about several routers on the same link that could advertise distinct parameters? We welcome your comments and suggestions. Thanks. /Jaehoon Paul ----- Original Message ----- From: "Ralph Droms" To: Sent: Wednesday, July 23, 2003 6:35 PM Subject: Re: DNS discovery discussion > > Alain wrote: > > >The RA camp keeps making the false assumption that using the > >DHCPv6-lite protocol to do this > >requires to have a big-iron DHCPv6 server on the network. This simply > >is not true. > > > > - Alain. > > Alain is correct - the machinery in a host and a router > to exchange DHCPv6 Information-request/Reply messages is > nowhere as complex as a full DHCPv6 implementation. > > We can demonstrate "DHCPv6-lite" in Cisco routers (in IOS). > It was developed as a a samll part of a part-time project > to implement DHCPv6 prefix delegation by three of > us at Cisco (Ole Troan, Jun Xie and myself). > > - Ralph > > > #---------------------------------------------------------------------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Jul 25 20:57:53 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04048 for ; Fri, 25 Jul 2003 20:57:52 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6Q0NO8W001130 for ; Sat, 26 Jul 2003 02:23:24 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6Q0NOwJ001129 for dnsop-outgoing; Sat, 26 Jul 2003 02:23:24 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6Q0NH8W001124 for ; Sat, 26 Jul 2003 02:23:21 +0200 (MEST) Received: from sandelman.ottawa.on.ca ([192.139.46.66]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h6Q0Lwg09959 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 25 Jul 2003 20:22:10 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h6PKa1pR005170; Fri, 25 Jul 2003 16:36:01 -0400 To: Syam Madanapalli cc: dnsop@cafax.se Subject: Re: proposal for a compromise on DNS discovery In-reply-to: Your message of "Wed, 16 Jul 2003 02:07:33 PDT." <20030716090733.35527.qmail@web20711.mail.yahoo.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 25 Jul 2003 16:36:01 -0400 Message-ID: <5169.1059165361@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-dnsop@cafax.se Precedence: bulk >>>>> "Syam" == Syam Madanapalli writes: Syam> I think the following approach probably will yield a Syam> better method for DNS Discovery. Syam> As DHCP may not be available in all netwokrs Syam> especially in small networks like Home Networks, But, a DNS server will be? ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Fri Jul 25 23:23:56 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08460 for ; Fri, 25 Jul 2003 23:23:55 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6Q2oO8W002938 for ; Sat, 26 Jul 2003 04:50:24 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6Q2oOvX002937 for dnsop-outgoing; Sat, 26 Jul 2003 04:50:24 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from parsley.amaranth.net (parsley.amaranth.net [208.254.46.23]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6Q2oI8W002932 for ; Sat, 26 Jul 2003 04:50:19 +0200 (MEST) Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.34.18.226]) (authenticated bits=0) by parsley.amaranth.net (8.12.8/8.12.8) with ESMTP id h6Q2jjB6024783 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 25 Jul 2003 22:45:45 -0400 Message-Id: <5.2.1.1.2.20030725224534.01b56ba8@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 25 Jul 2003 22:50:07 -0400 To: Michael Richardson , Syam Madanapalli From: Daniel Senie Subject: Re: proposal for a compromise on DNS discovery Cc: dnsop@cafax.se In-Reply-To: <5169.1059165361@marajade.sandelman.ottawa.on.ca> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dnsop@cafax.se Precedence: bulk At 04:36 PM 7/25/2003, Michael Richardson wrote: > >>>>> "Syam" == Syam Madanapalli writes: > Syam> I think the following approach probably will yield a > Syam> better method for DNS Discovery. > > Syam> As DHCP may not be available in all netwokrs > Syam> especially in small networks like Home Networks, > > But, a DNS server will be? Reality check: home networks are, if connected to the Internet, attached via a gatewaying device. The de vice of choice for a large number of networks is a $60 router from on of any number of vendors. These boxes provide DHCP, DNS forwarding and NAT. Perhaps some other environment would provide a better strawman? DHCP is pretty prevalent in home networks. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sat Jul 26 17:59:09 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19144 for ; Sat, 26 Jul 2003 17:59:07 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6QLUm8W009354 for ; Sat, 26 Jul 2003 23:30:48 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6QLUm8a009353 for dnsop-outgoing; Sat, 26 Jul 2003 23:30:48 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6QLUf8W009347 for ; Sat, 26 Jul 2003 23:30:45 +0200 (MEST) Received: from sandelman.ottawa.on.ca ([192.139.46.66]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h6QLTMW13631 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sat, 26 Jul 2003 17:29:29 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h6QLUUXq012277 for ; Sat, 26 Jul 2003 17:30:31 -0400 To: dnsop@cafax.se Subject: Re: proposal for a compromise on DNS discovery In-reply-to: Your message of "Fri, 25 Jul 2003 22:50:07 EDT." <5.2.1.1.2.20030725224534.01b56ba8@mail.amaranth.net> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 26 Jul 2003 17:30:30 -0400 Message-ID: <12275.1059255030@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-dnsop@cafax.se Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Daniel" == Daniel Senie writes: Daniel> At 04:36 PM 7/25/2003, Michael Richardson wrote: >> >>>>> "Syam" == Syam Madanapalli writes: Syam> I think the following approach probably will yield a Syam> better method for DNS Discovery. >> Syam> As DHCP may not be available in all netwokrs Syam> especially in small networks like Home Networks, >> >> But, a DNS server will be? Daniel> Reality check: home networks are, if connected to the Internet, Daniel> attached via a gatewaying device. The de vice of choice for a Daniel> large number of networks is a $60 router from on of any number of Daniel> vendors. These boxes provide DHCP, DNS forwarding and Daniel> NAT. Perhaps some other environment would provide a better Daniel> strawman? DHCP is pretty prevalent in home networks. Right, exactly. I simply do not believe that there are environments where there will be a local (on wire) DNS server, but not a local DHCP server. The home environment is entirely the opposite - local DHCP server in SOHO router that gets the DNS info from the ISP via DHCP and/or PPP and passes it on via DHCP. ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBPyLy9YqHRg3pndX9AQHy0gP7B3fYZ6pFaPkhbJT2VuHLz25iVwbWztXF 0d3ypeHkg5rmApqmKWpD2Cr1gDOIun1qx3+g4dLWM5bipPsUeDqrsZ/JzjAsT5Qj LIwyJfBjlUMlf8hHX46HylrL0dRmLjtY6wDp3Yo+xgtdxfCUdDRju3OtCru/oG8p L4/KSXLWrik= =+p7V -----END PGP SIGNATURE----- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sun Jul 27 07:45:10 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13783 for ; Sun, 27 Jul 2003 07:45:08 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6RB8r8W014601 for ; Sun, 27 Jul 2003 13:08:53 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6RB8rV7014600 for dnsop-outgoing; Sun, 27 Jul 2003 13:08:53 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6RB8p8W014595 for ; Sun, 27 Jul 2003 13:08:52 +0200 (MEST) From: Masataka Ohta Message-Id: <200307271052.TAA06719@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA06719; Sun, 27 Jul 2003 19:52:30 +0900 Subject: Re: proposal for a compromise on DNS discovery In-Reply-To: <12275.1059255030@marajade.sandelman.ottawa.on.ca> from Michael Richardson at "Jul 26, 2003 05:30:30 pm" To: Michael Richardson Date: Sun, 27 Jul 2003 19:52:29 +0859 () CC: dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk > >> But, a DNS server will be? > > Daniel> Reality check: home networks are, if connected to the Internet, > Daniel> attached via a gatewaying device. The de vice of choice for a > Daniel> large number of networks is a $60 router from on of any number of > Daniel> vendors. These boxes provide DHCP, DNS forwarding and > Daniel> NAT. Perhaps some other environment would provide a better > Daniel> strawman? DHCP is pretty prevalent in home networks. > > Right, exactly. > > I simply do not believe that there are environments where there will be > a local (on wire) DNS server, but not a local DHCP server. The home > environment is entirely the opposite - local DHCP server in SOHO router > that gets the DNS info from the ISP via DHCP and/or PPP and passes it on via > DHCP. Right. Assuming that there is DHCP server even at home, there is no reason to have stateless (nor statefull) autoconfiguration by ND, which is why IPv6 is broken. However, there is still some configuration required at home to let the local DHCP server gets the ISP via DHCP, but definitely not by PPP, because PPP is for dial up over non-IP infrastructure. The simple way for home environment is to to let ISPs offer the DNS servers for their customer sites, which was impossible with addresses with site local scope. Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sun Jul 27 07:57:10 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13954 for ; Sun, 27 Jul 2003 07:57:10 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6RBSp8W014759 for ; Sun, 27 Jul 2003 13:28:51 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6RBSpQA014758 for dnsop-outgoing; Sun, 27 Jul 2003 13:28:51 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6RBSm8W014753 for ; Sun, 27 Jul 2003 13:28:49 +0200 (MEST) From: Masataka Ohta Message-Id: <200307271122.UAA06990@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id UAA06990; Sun, 27 Jul 2003 20:22:01 +0900 Subject: Re: proposal for a compromise on DNS discovery In-Reply-To: <12275.1059255030@marajade.sandelman.ottawa.on.ca> from Michael Richardson at "Jul 26, 2003 05:30:30 pm" To: Michael Richardson Date: Sun, 27 Jul 2003 20:22:00 +0859 () CC: dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk > Daniel> Reality check: home networks are, if connected to the Internet, > Daniel> attached via a gatewaying device. The de vice of choice for a > Daniel> large number of networks is a $60 router from on of any number of > Daniel> vendors. These boxes provide DHCP, DNS forwarding and > Daniel> NAT. Perhaps some other environment would provide a better > Daniel> strawman? DHCP is pretty prevalent in home networks. > > Right, exactly. > > I simply do not believe that there are environments where there will be > a local (on wire) DNS server, but not a local DHCP server. The home > environment is entirely the opposite - local DHCP server in SOHO router > that gets the DNS info from the ISP via DHCP and/or PPP and passes it on via > DHCP. Right. And, having such DHCP servers, there is no role of RA for stateless (nor stateful) autoconfiguration, which is why IPv6 with ND is broken. The remaining problem is configuration on how to let the DHCP server in SOHO router get the info and the solution should be related to anycast. DNS server with anycast addresses does not neet intermediate DHCP. Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Sun Jul 27 09:25:11 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15203 for ; Sun, 27 Jul 2003 09:25:11 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6RD0c8W015372 for ; Sun, 27 Jul 2003 15:00:38 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6RD0cfg015371 for dnsop-outgoing; Sun, 27 Jul 2003 15:00:38 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6RD0a8W015366 for ; Sun, 27 Jul 2003 15:00:36 +0200 (MEST) Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1) with ESMTP-TLS id 410170 for dnsop@cafax.se; Sun, 27 Jul 2003 08:00:27 -0500 Message-ID: <3F23CCFB.7000208@ehsco.com> Date: Sun, 27 Jul 2003 08:00:43 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-US,en MIME-Version: 1.0 To: dnsop@cafax.se Subject: Re: proposal for a compromise on DNS discovery References: <200307271052.TAA06719@necom830.hpcl.titech.ac.jp> In-Reply-To: <200307271052.TAA06719@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit on 7/27/2003 5:53 AM Masataka Ohta wrote: > The simple way for home environment is to to let ISPs offer the DNS > servers for their customer sites, which was impossible with > addresses with site local scope. This entire debate has only convinced me that what we really need is (real) multicast-capable DNS resolvers and protocols (real DNS, not a substitute service). -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 28 11:38:50 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07794 for ; Mon, 28 Jul 2003 11:38:48 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6SF3o8W025718 for ; Mon, 28 Jul 2003 17:03:50 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6SF3oTq025717 for dnsop-outgoing; Mon, 28 Jul 2003 17:03:50 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6SF3m8W025712 for ; Mon, 28 Jul 2003 17:03:48 +0200 (MEST) Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 28 Jul 2003 17:03:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: proposal for a compromise on DNS discovery Date: Mon, 28 Jul 2003 17:03:33 +0200 Message-ID: Thread-Topic: proposal for a compromise on DNS discovery Thread-Index: AcNUM/ArtkAq1MBpQMSdIT8I5CaEGwA3y6zg From: "BELOEIL Luc FTRD/DMI/CAE" To: "Masataka Ohta" , "Michael Richardson" Cc: X-OriginalArrivalTime: 28 Jul 2003 15:03:34.0910 (UTC) FILETIME=[6AB201E0:01C35519] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h6SF3m8W025713 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit > > Daniel> Reality check: home networks are, if connected to the Internet, > > Daniel> attached via a gatewaying device. The de vice of choice for a > > Daniel> large number of networks is a $60 router from on of any number of > > Daniel> vendors. These boxes provide DHCP, DNS forwarding and > > Daniel> NAT. Perhaps some other environment would provide a better > > Daniel> strawman? DHCP is pretty prevalent in home networks. > > > > Right, exactly. > > > > I simply do not believe that there are environments where there will be > > a local (on wire) DNS server, but not a local DHCP server. The home > > environment is entirely the opposite - local DHCP server in SOHO router > > that gets the DNS info from the ISP via DHCP and/or PPP and passes it on via > > DHCP. > > Right. > > And, having such DHCP servers, there is no role of RA for stateless > (nor stateful) autoconfiguration, which is why IPv6 with ND is broken. > > The remaining problem is configuration on how to let the DHCP > server in SOHO router get the info and the solution should be > related to anycast. > > DNS server with anycast addresses does not neet intermediate DHCP. > > Masataka Ohta > Ok DHCP servers are embedded in current IPv4 SOHO router. This is cheap and efficient. But this is not a valid argument to to say that DHCP is THE only valid solution to announce DNS resolver server IPv6 address. SOHO routers, that are currently on market, are using a DHCPv6 client to be configured by the ISP but are using ND-based stateless address autoconfiguration to help local hosts to configure their IPv6 addresses ! Then what is(are) the solution(s): - RA-based - DHCPv6-lite - Anycast Addresses for resolver DNS server - SLP (I also like SLP, which already a RFC - Standards Track - !!! Does anybody have a good point against SLP ?) - well-known link-local addresses (+ DNS proxies...)?... There was a analysis made by the DNS Discovery Design Team in march 2001 (draft-ietf-ipnwg-dns-discovery-01.txt). Wouldn't it be valuable to go on or to restart such a work ? (instead of this no-end battle?) I must have missed something concerning this old work. Could anyone give me some pointers or summary? Luc #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 28 11:38:52 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07809 for ; Mon, 28 Jul 2003 11:38:51 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6SFI18W025968 for ; Mon, 28 Jul 2003 17:18:01 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6SFI1I7025967 for dnsop-outgoing; Mon, 28 Jul 2003 17:18:01 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6SFHx8W025962 for ; Mon, 28 Jul 2003 17:18:00 +0200 (MEST) Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6SFHvuG016459 for ; Mon, 28 Jul 2003 08:17:57 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (sjc-vpn2-225.cisco.com [10.21.112.225]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABA57749; Mon, 28 Jul 2003 11:17:55 -0400 (EDT) Message-Id: <4.3.2.7.2.20030728111711.04332310@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 28 Jul 2003 11:17:52 -0400 To: From: Ralph Droms Subject: RE: proposal for a compromise on DNS discovery In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dnsop@cafax.se Precedence: bulk What was missing in the original DNS discovery work is that it explicitly ruled out DHCPv6 a priori... - Ralph At 05:03 PM 7/28/2003 +0200, BELOEIL Luc FTRD/DMI/CAE wrote: > > > Daniel> Reality check: home networks are, if connected to the >Internet, > > > Daniel> attached via a gatewaying device. The de vice of choice >for a > > > Daniel> large number of networks is a $60 router from on of any >number of > > > Daniel> vendors. These boxes provide DHCP, DNS forwarding and > > > Daniel> NAT. Perhaps some other environment would provide a >better > > > Daniel> strawman? DHCP is pretty prevalent in home networks. > > > > > > Right, exactly. > > > > > > I simply do not believe that there are environments where there >will be > > > a local (on wire) DNS server, but not a local DHCP server. The home > > > environment is entirely the opposite - local DHCP server in SOHO >router > > > that gets the DNS info from the ISP via DHCP and/or PPP and passes >it on via > > > DHCP. > > > > Right. > > > > And, having such DHCP servers, there is no role of RA for stateless > > (nor stateful) autoconfiguration, which is why IPv6 with ND is broken. > > > > The remaining problem is configuration on how to let the DHCP > > server in SOHO router get the info and the solution should be > > related to anycast. > > > > DNS server with anycast addresses does not neet intermediate DHCP. > > > > Masataka Ohta > > > >Ok DHCP servers are embedded in current IPv4 SOHO router. This is cheap >and efficient. But this is not a valid argument to to say that DHCP is >THE only valid solution to announce DNS resolver server IPv6 address. > >SOHO routers, that are currently on market, are using a DHCPv6 client to >be configured by the ISP but are using ND-based stateless address >autoconfiguration to help local hosts to configure their IPv6 addresses >! > >Then what is(are) the solution(s): >- RA-based >- DHCPv6-lite >- Anycast Addresses for resolver DNS server >- SLP (I also like SLP, which already a RFC - Standards Track - !!! Does >anybody have a good point against SLP ?) >- well-known link-local addresses (+ DNS proxies...)?... > >There was a analysis made by the DNS Discovery Design Team in march 2001 >(draft-ietf-ipnwg-dns-discovery-01.txt). Wouldn't it be valuable to go >on or to restart such a work ? (instead of this no-end battle?) I must >have missed something concerning this old work. Could anyone give me >some pointers or summary? > >Luc > >#---------------------------------------------------------------------- ># To unsubscribe, send a message to . #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 28 22:27:00 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27655 for ; Mon, 28 Jul 2003 22:26:58 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6T1ud8W001261 for ; Tue, 29 Jul 2003 03:56:39 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6T1udek001260 for dnsop-outgoing; Tue, 29 Jul 2003 03:56:39 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from mailout3.samsung.com ([203.254.224.33]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6T1ub8W001255 for ; Tue, 29 Jul 2003 03:56:38 +0200 (MEST) Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HIR00601K1OY9@mailout3.samsung.com> for dnsop@cafax.se; Tue, 29 Jul 2003 10:56:12 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HIR00C3KK1NPG@mailout3.samsung.com> for dnsop@cafax.se; Tue, 29 Jul 2003 10:56:12 +0900 (KST) Received: from daniel7209 ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTPA id <0HIR001RKK1N5X@mmp2.samsung.com> for dnsop@cafax.se; Tue, 29 Jul 2003 10:56:11 +0900 (KST) Date: Tue, 29 Jul 2003 10:56:33 +0900 From: Soohong Daniel Park Subject: RE: proposal for a compromise on DNS discovery In-reply-to: <200307271052.TAA06719@necom830.hpcl.titech.ac.jp> To: "'Masataka Ohta'" , "'Michael Richardson'" Cc: dnsop@cafax.se Message-id: <00ce01c35574$a31cd950$b7cbdba8@daniel7209> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT Please be sure that we didn't focus on only SOHO/Homenetwork. I guess RA-based mechanism is more efficient in mobility than any cases. Therefore, I would like say that we need both mechanisms for each application domain. Daniel (Soohong Daniel Park) Mobile Platform Lab,SAMSUNG Electronics > -----Original Message----- > From: owner-dnsop@cafax.se [mailto:owner-dnsop@cafax.se] On > Behalf Of Masataka Ohta > Sent: Sunday, July 27, 2003 7:53 PM > To: Michael Richardson > Cc: dnsop@cafax.se > Subject: Re: proposal for a compromise on DNS discovery > > > > >> But, a DNS server will be? > > > > Daniel> Reality check: home networks are, if connected > to the Internet, > > Daniel> attached via a gatewaying device. The de vice > of choice for a > > Daniel> large number of networks is a $60 router from > on of any number of > > Daniel> vendors. These boxes provide DHCP, DNS forwarding and > > Daniel> NAT. Perhaps some other environment would > provide a better > > Daniel> strawman? DHCP is pretty prevalent in home networks. > > > > Right, exactly. > > > > I simply do not believe that there are environments where > there will > > be a local (on wire) DNS server, but not a local DHCP > server. The home > > environment is entirely the opposite - local DHCP server in SOHO > > router that gets the DNS info from the ISP via DHCP and/or PPP and > > passes it on via DHCP. > > Right. > > Assuming that there is DHCP server even at home, there is no > reason to have stateless (nor statefull) autoconfiguration by > ND, which is why IPv6 is broken. > > However, there is still some configuration required at home > to let the local DHCP server gets the ISP via DHCP, but > definitely not by PPP, because PPP is for dial up over non-IP > infrastructure. > > The simple way for home environment is to to let ISPs offer > the DNS servers for their customer sites, which was > impossible with addresses with site local scope. > > Masataka Ohta > #------------------------------------------------------------- > --------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 28 22:30:12 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27719 for ; Mon, 28 Jul 2003 22:30:10 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6T29A8W001336 for ; Tue, 29 Jul 2003 04:09:10 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6T29ARq001335 for dnsop-outgoing; Tue, 29 Jul 2003 04:09:10 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6T2978W001330 for ; Tue, 29 Jul 2003 04:09:08 +0200 (MEST) From: Masataka Ohta Message-Id: <200307290158.KAA14710@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA14710; Tue, 29 Jul 2003 10:58:15 +0900 Subject: Re: proposal for a compromise on DNS discovery In-Reply-To: <3F23CCFB.7000208@ehsco.com> from "Eric A. Hall" at "Jul 27, 2003 08:00:43 am" To: "Eric A. Hall" Date: Tue, 29 Jul 2003 10:58:14 +0859 () CC: dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk Eric A. Hall; > > The simple way for home environment is to to let ISPs offer the DNS > > servers for their customer sites, which was impossible with > > addresses with site local scope. > > This entire debate has only convinced me that what we really need is > (real) multicast-capable DNS resolvers and protocols (real DNS, not a > substitute service). Huh? Multicast? It's no solution. As I commented to Message-Id: <200307240446.NAA04398@necom830.hpcl.titech.ac.jp> Subject: Re: DNS discovery discussion To: Ralph Droms CC: dnsop@cafax.se Date: Thu, 24 Jul 2003 13:46:31 +0859 () By assuming large link layer, which violates the CATENET model, many protocols, including but not limited to IPv6 and IGMP, are damaged. Now, we can simply say, broadcast. link local multicast is a poor alternative to broadcast. In addition, DNS with link local multicast/broadcast does not solve any configuration problem. Multicast for domains larger than a link beyond routers requires domain wide broadcast (such as that of data broadcast of DVMRP or core/RP selction of CBT/PIM) or static configuration (such as that of core/RP/source of CBT/PIM/SSM). The confdiguraed data is different site by site, unless you use anycast for core/RP/source. But, no one is sure what will happen with this kind of combination of anycast and multicast that this is not the way to go. Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 28 22:41:38 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27873 for ; Mon, 28 Jul 2003 22:41:37 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6T2JB8W001409 for ; Tue, 29 Jul 2003 04:19:11 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6T2JBc7001408 for dnsop-outgoing; Tue, 29 Jul 2003 04:19:11 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6T2J98W001403 for ; Tue, 29 Jul 2003 04:19:10 +0200 (MEST) From: Masataka Ohta Message-Id: <200307290207.LAA14862@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA14862; Tue, 29 Jul 2003 11:07:11 +0900 Subject: Re: proposal for a compromise on DNS discovery In-Reply-To: from BELOEIL Luc FTRD/DMI/CAE at "Jul 28, 2003 05:03:33 pm" To: BELOEIL Luc FTRD/DMI/CAE Date: Tue, 29 Jul 2003 11:07:10 +0859 () CC: Michael Richardson , dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk Luc; > There was a analysis made by the DNS Discovery Design Team in march 2001 > (draft-ietf-ipnwg-dns-discovery-01.txt). Wouldn't it be valuable to go > on or to restart such a work ? (instead of this no-end battle?) I must > have missed something concerning this old work. What has been missing is a clear definition on the requirement. Lacking it, IPv6 WG has been poorly managed that its past work is not only useless but also harmful. Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 28 23:09:47 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28444 for ; Mon, 28 Jul 2003 23:09:46 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6T2n18W001568 for ; Tue, 29 Jul 2003 04:49:01 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6T2n1JM001567 for dnsop-outgoing; Tue, 29 Jul 2003 04:49:01 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6T2mw8W001562 for ; Tue, 29 Jul 2003 04:48:59 +0200 (MEST) From: Masataka Ohta Message-Id: <200307290233.LAA15348@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id LAA15348; Tue, 29 Jul 2003 11:33:34 +0900 Subject: Re: proposal for a compromise on DNS discovery In-Reply-To: <00ce01c35574$a31cd950$b7cbdba8@daniel7209> from Soohong Daniel Park at "Jul 29, 2003 10:56:33 am" To: Soohong Daniel Park Date: Tue, 29 Jul 2003 11:33:33 +0859 () CC: "'Michael Richardson'" , dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk Daniel (Soohong Daniel Park); > Please be sure that we didn't focus on only SOHO/Homenetwork. Then, can you clarify your requirement? > I guess RA-based mechanism is more efficient in mobility than any cases. What kind of autoconfiguration, do you think, is helpful for a mobile host? Remember that the mobile host MUST have *CONFIGURED* relationship and good connectivity with its home agent (or something like that) and environment around the home agent. Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Mon Jul 28 23:41:40 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28857 for ; Mon, 28 Jul 2003 23:41:40 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6T3F88W001810 for ; Tue, 29 Jul 2003 05:15:08 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6T3F8LJ001809 for dnsop-outgoing; Tue, 29 Jul 2003 05:15:08 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6T3F58W001804 for ; Tue, 29 Jul 2003 05:15:06 +0200 (MEST) Received: from 12-234-22-23.client.attbi.com ([12.234.22.23]) by comcast.net (rwcrmhc11) with SMTP id <2003072903145501300orub0e>; Tue, 29 Jul 2003 03:14:56 +0000 Date: Mon, 28 Jul 2003 20:14:54 -0700 (PDT) From: Doug Barton To: BELOEIL Luc FTRD/DMI/CAE cc: dnsop@cafax.se Subject: RE: proposal for a compromise on DNS discovery In-Reply-To: Message-ID: <20030728201052.T39258@12-234-22-23.pyvrag.nggov.pbz> References: Organization: Triborough Bridge & Tunnel Authority X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Mon, 28 Jul 2003, BELOEIL Luc FTRD/DMI/CAE wrote: > Ok DHCP servers are embedded in current IPv4 SOHO router. There, and LOTS of other places. > This is cheap and efficient. But this is not a valid argument to to > say that DHCP is THE only valid solution to announce DNS resolver > server IPv6 address. DHCP in SOHO networks alone isn't, no. However, the fact that just about every network of any size has, or can easily deploy dhcp(lite) is. > There was a analysis made by the DNS Discovery Design Team in march 2001 > (draft-ietf-ipnwg-dns-discovery-01.txt). Wouldn't it be valuable to go > on or to restart such a work ? (instead of this no-end battle?) The "battle" would end if the RA DNS proponents would stop re-proposing it. :) Doug -- Angel: We need you to distract the vampires. Buffy: Right. Xander: What are you going to do? Buffy: I'm going to kill them all. (Walking away) That oughta distract them. "When She Was Bad" - Buffy the Vampire Slayer, Season 2 Episode 1 #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 09:56:19 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22867 for ; Tue, 29 Jul 2003 09:56:19 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TDYY8W005134 for ; Tue, 29 Jul 2003 15:34:34 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TDYYvF005133 for dnsop-outgoing; Tue, 29 Jul 2003 15:34:34 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TDYX8W005128 for ; Tue, 29 Jul 2003 15:34:33 +0200 (MEST) Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Jul 2003 14:31:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: DNS discovery: what about well-known site-local addresses ? Date: Tue, 29 Jul 2003 14:31:31 +0200 Message-ID: Thread-Topic: DNS discovery: what about well-known site-local addresses ? Thread-Index: AcNVzVdLMEo9dbQoTQehfVbqThRrkw== From: "BELOEIL Luc FTRD/DMI/CAE" To: "Dnsop List diff IETF (E-mail)" X-OriginalArrivalTime: 29 Jul 2003 12:31:33.0025 (UTC) FILETIME=[580A9110:01C355CD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h6TDYY8W005129 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Hi all, at last IETF meeting (Vienna), I have understood that Christian Huitema was proposing not to deprecate well-know site-local addresses used for recursive DNS servers. As a consequence, such a solution could also be taken into account in our discussion. I would like to have the opinion of this working group about that point. Luc #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 09:56:20 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22866 for ; Tue, 29 Jul 2003 09:56:19 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TDWA8W005123 for ; Tue, 29 Jul 2003 15:32:10 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TDWAYq005122 for dnsop-outgoing; Tue, 29 Jul 2003 15:32:10 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TDW98W005117 for ; Tue, 29 Jul 2003 15:32:09 +0200 (MEST) Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Jul 2003 13:43:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: proposal for a compromise on DNS discovery Date: Tue, 29 Jul 2003 13:43:33 +0200 Message-ID: Thread-Topic: proposal for a compromise on DNS discovery Thread-Index: AcNVf5sSICUNtCRHQmemVBcdjIwk0AARLKMw From: "BELOEIL Luc FTRD/DMI/CAE" To: "Doug Barton" Cc: X-OriginalArrivalTime: 29 Jul 2003 11:43:34.0574 (UTC) FILETIME=[A459CCE0:01C355C6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h6TDW98W005118 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Hi Doug > -----Message d'origine----- > De : Doug Barton [mailto:DougB@DougBarton.net] > Envoye : mardi 29 juillet 2003 05:15 > > > On Mon, 28 Jul 2003, BELOEIL Luc FTRD/DMI/CAE wrote: > > > Ok DHCP servers are embedded in current IPv4 SOHO router. > > There, and LOTS of other places. > Good point. But "LOTS of other places" should be clarified for the sake of arguments. > > This is cheap and efficient. But this is not a valid argument to to > > say that DHCP is THE only valid solution to announce DNS resolver > > server IPv6 address. > > DHCP in SOHO networks alone isn't, no. However, the fact that > just about > every network of any size has, or can easily deploy dhcp(lite) is. > Don't conclude so quickly please. - "every network of any size" do not always have DHCP. At least one example: DSL access use currently PPP+IPCP so as to configure IPv4 "parameters". - "or can easily deploy dhcp(lite": ok it is not so clear for me. Deployment is one thing, then we should be sure that such a solution would work in a lot of situation. I have the case where several DHCP servers (one stateless, and another statefull for example) could deal a same LAN, and there I still miss the proper engineering rules not to confuse a DHCP client. > > There was a analysis made by the DNS Discovery Design Team > in march 2001 > > (draft-ietf-ipnwg-dns-discovery-01.txt). Wouldn't it be > valuable to go > > on or to restart such a work ? (instead of this no-end battle?) > > The "battle" would end if the RA DNS proponents would stop > re-proposing > it. :) > :) > Doug > Luc #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 10:06:33 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23440 for ; Tue, 29 Jul 2003 10:06:31 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TDmL8W005304 for ; Tue, 29 Jul 2003 15:48:21 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TDmLJl005303 for dnsop-outgoing; Tue, 29 Jul 2003 15:48:21 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TDmK8W005298 for ; Tue, 29 Jul 2003 15:48:20 +0200 (MEST) Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Jul 2003 13:56:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: proposal for a compromise on DNS discovery Date: Tue, 29 Jul 2003 13:56:05 +0200 Message-ID: Thread-Topic: proposal for a compromise on DNS discovery Thread-Index: AcNVHPFupaNgCoTEQSq50pX3dYTWmwAqcQvQ From: "BELOEIL Luc FTRD/DMI/CAE" To: "Ralph Droms" , X-OriginalArrivalTime: 29 Jul 2003 11:56:06.0984 (UTC) FILETIME=[64D27480:01C355C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h6TDmL8W005299 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Hi Raplh, thank you for that precision. draft-ietf-ipngwg-dns-discovery-01.txt had a whole section (6.1 DHCP) concerning DHCP. But It seems some other points could also be added to section 5 (Transport Mechanisms) so as to refer explicitly to DHCP. Do you think it would be valuable to work again on that draft? Luc > -----Message d'origine----- > De : Ralph Droms [mailto:rdroms@cisco.com] > > > What was missing in the original DNS discovery work is that > it explicitly ruled out DHCPv6 a priori... > > - Ralph > > At 05:03 PM 7/28/2003 +0200, BELOEIL Luc FTRD/DMI/CAE wrote: > > > >Then what is(are) the solution(s): > >- RA-based > >- DHCPv6-lite > >- Anycast Addresses for resolver DNS server > >- SLP (I also like SLP, which already a RFC - Standards > Track - !!! Does > >anybody have a good point against SLP ?) > >- well-known link-local addresses (+ DNS proxies...)?... > > > >There was a analysis made by the DNS Discovery Design Team > in march 2001 > >(draft-ietf-ipnwg-dns-discovery-01.txt). Wouldn't it be > valuable to go > >on or to restart such a work ? (instead of this no-end > battle?) I must > >have missed something concerning this old work. Could anyone give me > >some pointers or summary? > > > >Luc > > > >#------------------------------------------------------------ > ---------- > ># To unsubscribe, send a message to . > > #------------------------------------------------------------- > --------- > # To unsubscribe, send a message to . > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 10:15:51 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24403 for ; Tue, 29 Jul 2003 10:15:49 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TDjx8W005266 for ; Tue, 29 Jul 2003 15:45:59 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TDjxTK005265 for dnsop-outgoing; Tue, 29 Jul 2003 15:45:59 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TDjs8W005260 for ; Tue, 29 Jul 2003 15:45:58 +0200 (MEST) Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 29 Jul 2003 14:00:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: proposal for a compromise on DNS discovery Date: Tue, 29 Jul 2003 14:00:08 +0200 Message-ID: Thread-Topic: proposal for a compromise on DNS discovery Thread-Index: AcNVd8fJAxLUL4/pQ7iND9+ogwCX8QAUK3ug From: "BELOEIL Luc FTRD/DMI/CAE" To: "Masataka Ohta" Cc: "Michael Richardson" , X-OriginalArrivalTime: 29 Jul 2003 12:00:10.0770 (UTC) FILETIME=[F6213F20:01C355C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h6TDjx8W005261 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit But there was an explicit section that was concerning "Requirements" (section 2). Perhaps that section should be revised ? To my mind we still do not have a clear statement of what are the requirements. Some were presented by Rob Austein and Bob Hinden, but there has been nor a vote, neither a draft. Luc > -----Message d'origine----- > De : Masataka Ohta [mailto:mohta@necom830.hpcl.titech.ac.jp] > Envoye : mardi 29 juillet 2003 04:08 > A : BELOEIL Luc FTRD/DMI/CAE > Cc : Michael Richardson; dnsop@cafax.se > Objet : Re: proposal for a compromise on DNS discovery > > > Luc; > > > There was a analysis made by the DNS Discovery Design Team > in march 2001 > > (draft-ietf-ipnwg-dns-discovery-01.txt). Wouldn't it be > valuable to go > > on or to restart such a work ? (instead of this no-end > battle?) I must > > have missed something concerning this old work. > > What has been missing is a clear definition on the requirement. > > Lacking it, IPv6 WG has been poorly managed that its past work > is not only useless but also harmful. > > Masataka Ohta > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 10:46:15 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25255 for ; Tue, 29 Jul 2003 10:46:13 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TEMC8W005639 for ; Tue, 29 Jul 2003 16:22:12 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TEMCmt005638 for dnsop-outgoing; Tue, 29 Jul 2003 16:22:12 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TEMB8W005633 for ; Tue, 29 Jul 2003 16:22:11 +0200 (MEST) Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1) with ESMTP-TLS id 410481; Tue, 29 Jul 2003 09:22:03 -0500 Message-ID: <3F26830E.6090703@ehsco.com> Date: Tue, 29 Jul 2003 09:22:06 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Masataka Ohta CC: dnsop@cafax.se Subject: Re: proposal for a compromise on DNS discovery References: <200307290158.KAA14710@necom830.hpcl.titech.ac.jp> In-Reply-To: <200307290158.KAA14710@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit on 7/28/2003 8:59 PM Masataka Ohta wrote: > Huh? Multicast? It's no solution. As I commented to > By assuming large link layer, which violates the CATENET model, > many protocols, including but not limited to IPv6 and IGMP, > are damaged. > > Now, we can simply say, broadcast. > > link local multicast is a poor alternative to broadcast. I don't understand these complaints. ~512 bytes isn't very large, and broadcast is a poor alternative to admin scoped multicast. > In addition, DNS with link local multicast/broadcast does not solve > any configuration problem. Which configuration problem? It wouldn't give a hostname if that's what you mean, but I'm not sure that anybody would expect such. > Multicast for domains larger than a link beyond routers requires > domain wide broadcast (such as that of data broadcast of DVMRP > or core/RP selction of CBT/PIM) or static configuration (such as that > of core/RP/source of CBT/PIM/SSM). It would need static configuration in a non-optimized state. One of the challenges for a multicast DNS would be to keep multiple servers from always replying to every query, and that could be accomplished through numerous methods, any of which may in turn could minimize the need for manual maintenance of the multicast address. It's also possible to limit the use of multicast to DNS discovery, such as having clients issue (periodic) queries to the multicast address to determine the available servers, and to choose the top 3 servers (or whatever) based on certain criteria (RA flag, response time, whatever), and then use unicast after that. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 11:24:06 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26212 for ; Tue, 29 Jul 2003 11:24:01 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TExJ8W005988 for ; Tue, 29 Jul 2003 16:59:19 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TExJqD005987 for dnsop-outgoing; Tue, 29 Jul 2003 16:59:19 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TExD8W005982 for ; Tue, 29 Jul 2003 16:59:18 +0200 (MEST) Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6TExAmn006330; Tue, 29 Jul 2003 07:59:11 -0700 (PDT) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-162.cisco.com [10.82.240.162]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA00974; Tue, 29 Jul 2003 07:59:09 -0700 (PDT) Message-Id: <4.3.2.7.2.20030729101626.01f1cc88@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Jul 2003 10:59:07 -0400 To: "BELOEIL Luc FTRD/DMI/CAE" From: John Schnizlein Subject: Re: DNS discovery: what about well-known site-local addresses ? Cc: "Dnsop List diff IETF (E-mail)" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-dnsop@cafax.se Precedence: bulk At 08:31 AM 7/29/2003, BELOEIL Luc FTRD/DMI/CAE wrote: >at last IETF meeting (Vienna), I have understood that Christian Huitema was proposing not to deprecate well-know site-local addresses used for recursive DNS servers. As a consequence, such a solution could also be taken into account in our discussion. > >I would like to have the opinion of this working group about that point. Why continue this insistent attempt to invent new methods when there is a well-defined method (stateless-DHCP) that has widespread support? First reason why this new alternative is a bad idea: The definition of well-known addresses for each Internet service is not the way the Internet works. A very strong analysis would be expected to embark on such a radical reinvention. Second reason: Site-local addresses are contentious, to say the least. A large fraction, if not rough consensus (see Tony Hain's rebuttal), agrees that site-local addresses cause more trouble than they are worth. Third reason: The number of special site-local addresses would limit the number of DNS servers that could be made available to clients. Fourth reason: For each special site-local address, the local network administration would have to configure appropriate routing - a non-trivial effort. Fifth reason: This approach would not work for the case in which a subscriber uses a DNS server provided by his service provider. The subscriber's site and the provider's site are likely often different. John #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 11:40:55 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26670 for ; Tue, 29 Jul 2003 11:40:55 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TFFc8W006112 for ; Tue, 29 Jul 2003 17:15:38 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TFFcsh006111 for dnsop-outgoing; Tue, 29 Jul 2003 17:15:38 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TFFb8W006106 for ; Tue, 29 Jul 2003 17:15:38 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19hWCN-000HJw-FU; Tue, 29 Jul 2003 08:15:35 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 29 Jul 2003 08:15:34 -0700 To: "BELOEIL Luc FTRD/DMI/CAE" Cc: "Dnsop List diff IETF (E-mail)" Subject: Re: DNS discovery: what about well-known site-local addresses ? References: Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit the set of well-known site local addresses is a subset of all site-local addresses, which is the null set. randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 11:40:56 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26671 for ; Tue, 29 Jul 2003 11:40:55 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TFCL8W006084 for ; Tue, 29 Jul 2003 17:12:21 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TFCL70006083 for dnsop-outgoing; Tue, 29 Jul 2003 17:12:21 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TFCJ8W006078 for ; Tue, 29 Jul 2003 17:12:20 +0200 (MEST) Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p2/8.11.6) with ESMTP id h6TFAaW27694 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Tue, 29 Jul 2003 11:10:42 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id h6TFC7v2023460; Tue, 29 Jul 2003 11:12:10 -0400 To: Soohong Daniel Park cc: dnsop@cafax.se Subject: Re: proposal for a compromise on DNS discovery In-reply-to: Your message of "Tue, 29 Jul 2003 10:56:33 +0900." <00ce01c35574$a31cd950$b7cbdba8@daniel7209> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 29 Jul 2003 11:12:07 -0400 Message-ID: <23459.1059491527@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-dnsop@cafax.se Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Soohong" == Soohong Daniel Park writes: Soohong> Please be sure that we didn't focus on only SOHO/Homenetwork. I Soohong> guess RA-based mechanism is more efficient in mobility than any Soohong> cases. Therefore, I would like say that we need both mechanisms Soohong> for each application domain. Mobility to *where*? It isn't the mobility that is the question, it is what services are present at the location where one is dropping in to. RA is very useful for places where no admission control is present or expected - so no prior configuration is likely or desireable. yet, the network is so small, or so ad-hoc that there really is *ONLY* the router. No printers. No NTP servers. No local SMTP relays. Yet, it is postulated that there is a local DNS server of some kind. One that is not anycast'able. Which networks are these? Not the IETF network. Not my SOHO network. Not most commercial wireless networks nor xDSL or cable networks. (they have admission control) So, which networks need this? ] Out and about in Ottawa. hmmm... beer. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys - custom hacks make this fully PGP2 compat iQCVAwUBPyaOxoqHRg3pndX9AQH5cgQAlF1HmQXPVcJEaGpFAooI9lI51Z49XrA2 R6avbmL53X4HPOjMoHbcu3o3hfqav/Ka9MaRtPx8FBGtTW5famaPGUpllCbAmf/i gHko4apOsTBGP2uukyw+BbP3cXq1gqiQn1SjDK4aozhq9Jwg90CXo5CDPkKJXBUO 1rx4IqsMuwo= =jPc6 -----END PGP SIGNATURE----- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 11:49:34 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26939 for ; Tue, 29 Jul 2003 11:49:34 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TFSD8W006311 for ; Tue, 29 Jul 2003 17:28:13 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TFSDBt006310 for dnsop-outgoing; Tue, 29 Jul 2003 17:28:13 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TFS58W006305 for ; Tue, 29 Jul 2003 17:28:10 +0200 (MEST) Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2003 08:28:04 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6TFS0mp014843; Tue, 29 Jul 2003 08:28:03 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (dhcp-10-86-160-186.cisco.com [10.86.160.186]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ABB48937; Tue, 29 Jul 2003 11:27:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20030729112042.0437c888@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Jul 2003 11:27:48 -0400 To: "BELOEIL Luc FTRD/DMI/CAE" From: Ralph Droms Subject: RE: proposal for a compromise on DNS discovery Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-dnsop@cafax.se Precedence: bulk Luc, At the top of page 2 of draft-ietf-ipngwg-dns-discovery-01.txt is the sentence: There are any number of ways that IPv6 hosts can discover information required to enable name resolution, in the absence of a DHCP server. which I read to mean that the document is explicitly describing mechanisms that do not use DHCP. Section 6.1 simply suggests the use of DHCP message formats in a new protocol for use between a host and a DNS server. draft-ietf-ipngwg-dns-discovery-01.txt expired in September, 2001. The most recent version, draft-ietf-ipv6-dns-discovery-06.txt, which describes the reserved site-local address mechanism, expired in February, 2003. The latter document also, indirectly, assumes that DHCP is not available. - Ralph At 01:56 PM 7/29/2003 +0200, BELOEIL Luc FTRD/DMI/CAE wrote: >Hi Raplh, > >thank you for that precision. > >draft-ietf-ipngwg-dns-discovery-01.txt had a whole section (6.1 DHCP) >concerning DHCP. But It seems some other points could also be added to >section 5 (Transport Mechanisms) so as to refer explicitly to DHCP. > >Do you think it would be valuable to work again on that draft? > >Luc > > > -----Message d'origine----- > > De : Ralph Droms [mailto:rdroms@cisco.com] > > > > > > What was missing in the original DNS discovery work is that > > it explicitly ruled out DHCPv6 a priori... > > > > - Ralph > > > > At 05:03 PM 7/28/2003 +0200, BELOEIL Luc FTRD/DMI/CAE wrote: > > > > > >Then what is(are) the solution(s): > > >- RA-based > > >- DHCPv6-lite > > >- Anycast Addresses for resolver DNS server > > >- SLP (I also like SLP, which already a RFC - Standards > > Track - !!! Does > > >anybody have a good point against SLP ?) > > >- well-known link-local addresses (+ DNS proxies...)?... > > > > > >There was a analysis made by the DNS Discovery Design Team > > in march 2001 > > >(draft-ietf-ipnwg-dns-discovery-01.txt). Wouldn't it be > > valuable to go > > >on or to restart such a work ? (instead of this no-end > > battle?) I must > > >have missed something concerning this old work. Could anyone give me > > >some pointers or summary? > > > > > >Luc > > > > > >#------------------------------------------------------------ > > ---------- > > ># To unsubscribe, send a message to . > > > > #------------------------------------------------------------- > > --------- > > # To unsubscribe, send a message to . > > #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 12:45:02 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29908 for ; Tue, 29 Jul 2003 12:44:57 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TGKJ8W006800 for ; Tue, 29 Jul 2003 18:20:19 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TGKJH8006799 for dnsop-outgoing; Tue, 29 Jul 2003 18:20:19 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TGKH8W006794 for ; Tue, 29 Jul 2003 18:20:18 +0200 (MEST) Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1) with ESMTP-TLS id 410510; Tue, 29 Jul 2003 11:20:10 -0500 Message-ID: <3F269EBE.7060300@ehsco.com> Date: Tue, 29 Jul 2003 11:20:14 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Masataka Ohta CC: dnsop@cafax.se Subject: Re: proposal for a compromise on DNS discovery References: <200307290158.KAA14710@necom830.hpcl.titech.ac.jp> <3F26830E.6090703@ehsco.com> In-Reply-To: <3F26830E.6090703@ehsco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit on 7/29/2003 9:22 AM Eric A. Hall wrote: > It's also possible to limit the use of multicast to DNS discovery, such as > having clients issue (periodic) queries to the multicast address to > determine the available servers, and to choose the top 3 servers (or > whatever) based on certain criteria (RA flag, response time, whatever), > and then use unicast after that. I've submitted an I-D on this in particular, which is also available at http://www.ehsco.com/misc/draft-hall-resolver-config-00.txt -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 14:19:18 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03609 for ; Tue, 29 Jul 2003 14:19:16 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6THtM8W007587 for ; Tue, 29 Jul 2003 19:55:22 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6THtM8S007586 for dnsop-outgoing; Tue, 29 Jul 2003 19:55:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6THtJ8W007578 for ; Tue, 29 Jul 2003 19:55:20 +0200 (MEST) Received: from master.dougb.net (12-234-22-23.client.attbi.com[12.234.22.23](untrusted sender)) by comcast.net (rwcrmhc13) with SMTP id <2003072917551701500qqrg3e>; Tue, 29 Jul 2003 17:55:17 +0000 Date: Tue, 29 Jul 2003 10:55:01 -0700 (PDT) From: Doug Barton To: BELOEIL Luc FTRD/DMI/CAE cc: dnsop@cafax.se Subject: RE: proposal for a compromise on DNS discovery In-Reply-To: Message-ID: <20030729105145.V614@znfgre.qbhto.arg> References: Organization: Triborough Bridge & Tunnel Authority X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Tue, 29 Jul 2003, BELOEIL Luc FTRD/DMI/CAE wrote: > Hi Doug > > > -----Message d'origine----- > > De : Doug Barton [mailto:DougB@DougBarton.net] > > Envoye : mardi 29 juillet 2003 05:15 > > > > > > On Mon, 28 Jul 2003, BELOEIL Luc FTRD/DMI/CAE wrote: > > > > > Ok DHCP servers are embedded in current IPv4 SOHO router. > > > > There, and LOTS of other places. > > > > Good point. But "LOTS of other places" should be clarified for the sake > of arguments. I've already clarified my argument in great detail in a previous post. I should have restrained my urge to comment on this post, but let me make myself clear once again: 1. In every situation where RA DNS announcements are proposed, dhcp is a better solution. 2. RA DNS announcements are an ugly feature creep for RA, and should not be implemented. Is that clear enough for you? :) Doug -- Angel: We need you to distract the vampires. Buffy: Right. Xander: What are you going to do? Buffy: I'm going to kill them all. (Walking away) That oughta distract them. "When She Was Bad" - Buffy the Vampire Slayer, Season 2 Episode 1 #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 15:45:30 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06962 for ; Tue, 29 Jul 2003 15:45:28 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TJHW8W008160 for ; Tue, 29 Jul 2003 21:17:32 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TJHWYD008159 for dnsop-outgoing; Tue, 29 Jul 2003 21:17:32 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TJHV8W008154 for ; Tue, 29 Jul 2003 21:17:31 +0200 (MEST) Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA16878 for ; Tue, 29 Jul 2003 20:17:30 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id UAA09511 for ; Tue, 29 Jul 2003 20:17:30 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6TJHUI31977 for dnsop@cafax.se; Tue, 29 Jul 2003 20:17:30 +0100 Date: Tue, 29 Jul 2003 20:17:30 +0100 From: Tim Chown To: dnsop@cafax.se Subject: Re: proposal for a compromise on DNS discovery Message-ID: <20030729191730.GE31891@login.ecs.soton.ac.uk> Mail-Followup-To: dnsop@cafax.se References: <20030729105145.V614@znfgre.qbhto.arg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030729105145.V614@znfgre.qbhto.arg> User-Agent: Mutt/1.4i Sender: owner-dnsop@cafax.se Precedence: bulk On Tue, Jul 29, 2003 at 10:55:01AM -0700, Doug Barton wrote: > > 1. In every situation where RA DNS announcements are proposed, dhcp is a > better solution. But will every device have a DHCPv6 (or DHCPv6 Lite) server on link? For those that do, one might ask "why bother with stateless autoconf?" and of course many sites will wish to keep using DHCP(v6) as a policy choice. But for networks without DHCP on link, the RA method is an alternative. Perhaps you can elaborate on your view of "better" to help the resolution of this discussion along? :) > 2. RA DNS announcements are an ugly feature creep for RA, and should not > be implemented. The spec for Router Advertisements allows for additional options to be specified, so this was considered possible when the spec was done. Tim #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 16:23:47 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07923 for ; Tue, 29 Jul 2003 16:23:44 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TK2n8W008494 for ; Tue, 29 Jul 2003 22:02:49 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TK2nYL008493 for dnsop-outgoing; Tue, 29 Jul 2003 22:02:49 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TK2l8W008488 for ; Tue, 29 Jul 2003 22:02:48 +0200 (MEST) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19hagI-000Ont-Fp; Tue, 29 Jul 2003 13:02:46 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 29 Jul 2003 13:02:45 -0700 To: Tim Chown Cc: dnsop@cafax.se Subject: Re: proposal for a compromise on DNS discovery References: <20030729105145.V614@znfgre.qbhto.arg> <20030729191730.GE31891@login.ecs.soton.ac.uk> Message-Id: Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit > But will every device have a DHCPv6 (or DHCPv6 Lite) server on link? i remember when this was asked of v4. at the stockholm ietf, which was not all that long ago, folk so disbelieved in it that i had to run the dhcp server on my laptop and leave it on a rather beautiful corner table all week. within a year it was common, two it had become ubiquitous. as someone recently asked, do we really believe that a significant number of nets will have a dns server but not a dhcp server? the $65 home dsl gateways have a dhcp server now, and many have some sort of dns cache or relay. my wristwatch probably has a dhcp server, but i don't know how to access it. randy #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 16:48:02 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08660 for ; Tue, 29 Jul 2003 16:48:01 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TKHV8W008621 for ; Tue, 29 Jul 2003 22:17:31 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TKHVSG008620 for dnsop-outgoing; Tue, 29 Jul 2003 22:17:31 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TKHT8W008615 for ; Tue, 29 Jul 2003 22:17:30 +0200 (MEST) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h6TKHSNN019728 for ; Tue, 29 Jul 2003 14:17:28 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HIS00K4TZ14RA@edgemail1.Central.Sun.COM> for dnsop@cafax.se; Tue, 29 Jul 2003 14:17:28 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPSA id <0HIS00IJHZ13U4@mail.sun.net> for dnsop@cafax.se; Tue, 29 Jul 2003 14:17:28 -0600 (MDT) Date: Tue, 29 Jul 2003 13:19:38 -0700 From: Alain Durand Subject: Re: proposal for a compromise on DNS discovery In-reply-to: <20030729191730.GE31891@login.ecs.soton.ac.uk> To: Tim Chown Cc: dnsop@cafax.se Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7BIT On Tuesday, July 29, 2003, at 12:17 PM, Tim Chown wrote: > On Tue, Jul 29, 2003 at 10:55:01AM -0700, Doug Barton wrote: >> >> 1. In every situation where RA DNS announcements are proposed, dhcp >> is a >> better solution. > > But will every device have a DHCPv6 (or DHCPv6 Lite) server on link? > For > those that do, one might ask "why bother with stateless autoconf?" and > of > course many sites will wish to keep using DHCP(v6) as a policy choice. > But for networks without DHCP on link, the RA method is an alternative. One could very well envision a network where the routers will act as DHCP-lite servers, only passing "stateless configuration" like DNS server, NTP server, .... but NOT allocating IPv6 addresses. >> 2. RA DNS announcements are an ugly feature creep for RA, and should >> not >> be implemented. > > The spec for Router Advertisements allows for additional options to be > specified, so this was considered possible when the spec was done. So the next step would be to define NTP server address in RA, web proxy address in RA, SIP server address in RA,.... RA could be extended to pass anything that could be a DHCP option. This is where feature creep happen. - Alain. #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 18:27:50 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13394 for ; Tue, 29 Jul 2003 18:27:50 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TLxr8W009217 for ; Tue, 29 Jul 2003 23:59:53 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TLxrhL009216 for dnsop-outgoing; Tue, 29 Jul 2003 23:59:53 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TLxq8W009211 for ; Tue, 29 Jul 2003 23:59:52 +0200 (MEST) Received: from master.dougb.net (12-234-22-23.client.attbi.com[12.234.22.23](untrusted sender)) by comcast.net (sccrmhc13) with SMTP id <2003072921595001600b66aae>; Tue, 29 Jul 2003 21:59:50 +0000 Date: Tue, 29 Jul 2003 14:59:49 -0700 (PDT) From: Doug Barton To: Tim Chown cc: dnsop@cafax.se Subject: Re: proposal for a compromise on DNS discovery In-Reply-To: <20030729191730.GE31891@login.ecs.soton.ac.uk> Message-ID: <20030729144750.D614@znfgre.qbhto.arg> References: <20030729105145.V614@znfgre.qbhto.arg> <20030729191730.GE31891@login.ecs.soton.ac.uk> Organization: Triborough Bridge & Tunnel Authority X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-dnsop@cafax.se Precedence: bulk On Tue, 29 Jul 2003, Tim Chown wrote: > On Tue, Jul 29, 2003 at 10:55:01AM -0700, Doug Barton wrote: > > > > 1. In every situation where RA DNS announcements are proposed, dhcp is a > > better solution. > > But will every device have a DHCPv6 (or DHCPv6 Lite) server on link? This has been asked an answered numerous times. In addition to the overly simplistic "yes" that this overly simple question deserves, please note the rather precise way that I've framed my statement. For every situation that you can posit where RA DNS "might be a good idea," my response is, "dhcp is a better idea." The fact that dhcp is already nearly impossible to avoid, even if you wanted to, simply adds strength to my argument. > For those that do, one might ask "why bother with stateless autoconf?" ENONSEQUITUR > and of course many sites will wish to keep using DHCP(v6) as a policy > choice. But for networks without DHCP on link, the RA method is an > alternative. See above. > Perhaps you can elaborate on your view of "better" to help the resolution > of this discussion along? :) I have done this in the past, but the summary is that dhcp already provides the mechanism to do what RA DNS announcements would, plus all the other things that are actually needed to make a client that needs DNS resolution functional. Thus, it's pointless to make an incomplete implementation of something from scratch when a complete implementation of a complete solution already exists. Also, speaking as a client (freebsd) implementor, I don't want to have to fuss with "maybe RA exists, and maybe it doesn't," given that the solutions are already in place for dhcp. > > 2. RA DNS announcements are an ugly feature creep for RA, and should not > > be implemented. > > The spec for Router Advertisements allows for additional options to be > specified, so this was considered possible when the spec was done. I didn't say, "RA should never be added to." I said THIS is an ugly feature creep for RA. Primarily because the IP(s) of the resolver(s) are mostly useless without the search string, and then of course you'll be needing to add the netbios name server IPs, etc. etc. There is no point in starting down this road (and lots of reasons not to). Hope this helps, Doug -- Angel: We need you to distract the vampires. Buffy: Right. Xander: What are you going to do? Buffy: I'm going to kill them all. (Walking away) That oughta distract them. "When She Was Bad" - Buffy the Vampire Slayer, Season 2 Episode 1 #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 18:44:24 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13931 for ; Tue, 29 Jul 2003 18:44:23 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TMN98W009441 for ; Wed, 30 Jul 2003 00:23:09 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TMN9rJ009440 for dnsop-outgoing; Wed, 30 Jul 2003 00:23:09 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TMN78W009435 for ; Wed, 30 Jul 2003 00:23:07 +0200 (MEST) Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h6TMN61C022924 for ; Tue, 29 Jul 2003 18:23:06 -0400 Received: from occlust04evs1.ugd.att.com (135.38.164.12) by attrh5i.attrh.att.com (6.5.032) id 3EE9217C01074620 for dnsop@cafax.se; Tue, 29 Jul 2003 18:22:58 -0400 Received: from mail pickup service by occlust04evs1.ugd.att.com with Microsoft SMTPSVC; Tue, 29 Jul 2003 17:22:09 -0500 Received: from acfe02.ugd.att.com ([135.37.16.17]) by occlust04evs1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 29 Jul 2003 14:24:16 -0500 Received: from attrh2i.attrh.att.com ([135.37.94.56]) by acfe02.ugd.att.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 29 Jul 2003 15:24:13 -0400 Received: from alpmx2.proxy.att.com (192.168.109.105) by attrh2i.attrh.att.com (6.5.032) id 3F25C3E4000270D8 for mattoconnell@ems.att.com; Tue, 29 Jul 2003 15:23:30 -0400 X-PMX-From: ;owner-dnsop@cafax.se; X-PMX-To: 1; Received: from almsi2.proxy.att.com (almsi2.proxy.att.com [192.168.109.69]) by alpmx2.proxy.att.com (AT&T IPNS/PMX-5.0) with ESMTP id h6TJOCwq031634 for ; Tue, 29 Jul 2003 15:24:13 -0400 X-MSI-From: ;owner-dnsop@cafax.se; X-MSI-To: 1; Received: from nic.cafax.se ([192.71.228.17]) by almsi2.proxy.att.com (AT&T IPNS/MSI-5.0) with ESMTP id h6TJNjnW030339 for ; Tue, 29 Jul 2003 15:23:54 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TJHW8W008160 for ; Tue, 29 Jul 2003 21:17:32 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TJHWYD008159 for dnsop-outgoing; Tue, 29 Jul 2003 21:17:32 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TJHV8W008154 for ; Tue, 29 Jul 2003 21:17:31 +0200 (MEST) Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id UAA16878 for ; Tue, 29 Jul 2003 20:17:30 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id UAA09511 for ; Tue, 29 Jul 2003 20:17:30 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6TJHUI31977 for dnsop@cafax.se; Tue, 29 Jul 2003 20:17:30 +0100 Date: Tue, 29 Jul 2003 20:17:30 +0100 From: Tim Chown To: dnsop@cafax.se Subject: Re: proposal for a compromise on DNS discovery Message-ID: <20030729191730.GE31891@login.ecs.soton.ac.uk> Mail-Followup-To: dnsop@cafax.se References: <20030729105145.V614@znfgre.qbhto.arg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030729105145.V614@znfgre.qbhto.arg> User-Agent: Mutt/1.4i X-ATT-Spam: Gauge=II, Probability=2%, Report='__USER_AGENT, __USER_AGENT_MUTT, __EVITE_CTYPE, __IN_REP_TO, __REFERENCES, X_AUTH_WARNING, REFERENCES, IN_REP_TO, TO_BE_REMOVED_REPLY, EMAIL_ATTRIBUTION, QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01' X-OriginalArrivalTime: 29 Jul 2003 19:24:14.0051 (UTC) FILETIME=[FEC34B30:01C35606] Sender: owner-dnsop@cafax.se Precedence: bulk On Tue, Jul 29, 2003 at 10:55:01AM -0700, Doug Barton wrote: > > 1. In every situation where RA DNS announcements are proposed, dhcp is a > better solution. But will every device have a DHCPv6 (or DHCPv6 Lite) server on link? For those that do, one might ask "why bother with stateless autoconf?" and of course many sites will wish to keep using DHCP(v6) as a policy choice. But for networks without DHCP on link, the RA method is an alternative. Perhaps you can elaborate on your view of "better" to help the resolution of this discussion along? :) > 2. RA DNS announcements are an ugly feature creep for RA, and should not > be implemented. The spec for Router Advertisements allows for additional options to be specified, so this was considered possible when the spec was done. Tim #---------------------------------------------------------------------- # To unsubscribe, send a message to . #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Tue Jul 29 19:00:12 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14376 for ; Tue, 29 Jul 2003 19:00:12 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TMca8W009626 for ; Wed, 30 Jul 2003 00:38:36 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6TMca80009625 for dnsop-outgoing; Wed, 30 Jul 2003 00:38:36 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6TMcY8W009620 for ; Wed, 30 Jul 2003 00:38:34 +0200 (MEST) Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h6TMZuPq026883 for ; Tue, 29 Jul 2003 18:38:33 -0400 Received: from occlust04evs1.ugd.att.com (135.38.164.12) by attrh5i.attrh.att.com (6.5.032) id 3EE9217C01076693; Tue, 29 Jul 2003 18:38:24 -0400 Received: from mail pickup service by occlust04evs1.ugd.att.com with Microsoft SMTPSVC; Tue, 29 Jul 2003 17:38:33 -0500 Received: from OCCLUST03EVS1.ugd.att.com ([135.38.164.10]) by occlust04evs1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 29 Jul 2003 14:20:40 -0500 Received: from acfe02.ugd.att.com ([135.37.16.17]) by OCCLUST03EVS1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 29 Jul 2003 14:20:39 -0500 Received: from attrh2i.attrh.att.com ([135.37.94.56]) by acfe02.ugd.att.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 29 Jul 2003 15:20:37 -0400 Received: from alpmx2.proxy.att.com (192.168.109.105) by attrh2i.attrh.att.com (6.5.032) id 3F25C3E400026E5E for mattoconnell@ems.att.com; Tue, 29 Jul 2003 15:19:53 -0400 X-PMX-From: ;owner-dnsop@cafax.se; X-PMX-To: 1; Received: from almsi2.proxy.att.com (almsi2.proxy.att.com [192.168.109.69]) by alpmx2.proxy.att.com (AT&T IPNS/PMX-5.0) with ESMTP id h6TJKYwq029686 for ; Tue, 29 Jul 2003 15:20:35 -0400 X-MSI-From: ;owner-dnsop@cafax.se; X-MSI-To: 1; Received: from nic.cafax.se ([192.71.228.17]) by almsi2.proxy.att.com (AT&T IPNS/MSI-5.0) with ESMTP id h6TJJdnW027722 for ; Tue, 29 Jul 2003 15:19:52 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6THtM8W007587 for ; Tue, 29 Jul 2003 19:55:22 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6THtM8S007586 for dnsop-outgoing; Tue, 29 Jul 2003 19:55:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6THtJ8W007578 for ; Tue, 29 Jul 2003 19:55:20 +0200 (MEST) Received: from master.dougb.net (12-234-22-23.client.attbi.com[12.234.22.23](untrusted sender)) by comcast.net (rwcrmhc13) with SMTP id <2003072917551701500qqrg3e>; Tue, 29 Jul 2003 17:55:17 +0000 Date: Tue, 29 Jul 2003 10:55:01 -0700 (PDT) From: Doug Barton To: BELOEIL Luc FTRD/DMI/CAE cc: dnsop@cafax.se Subject: RE: proposal for a compromise on DNS discovery In-Reply-To: Message-ID: <20030729105145.V614@znfgre.qbhto.arg> References: Organization: Triborough Bridge & Tunnel Authority X-message-flag: Outlook -- Not just for spreading viruses anymore! MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-ATT-Spam: Gauge=I, Probability=1%, Report='__IN_REP_TO, __REFERENCES, NOSPAM_INC, X_AUTH_WARNING, FORGED_RCVD_TRAIL, REFERENCES, IN_REP_TO, TO_BE_REMOVED_REPLY, EMAIL_ATTRIBUTION, QUOTED_EMAIL_TEXT, SPAM_PHRASE_00_01, SIGNATURE_LONG_DENSE' X-OriginalArrivalTime: 29 Jul 2003 19:20:37.0239 (UTC) FILETIME=[7D886870:01C35606] Sender: owner-dnsop@cafax.se Precedence: bulk On Tue, 29 Jul 2003, BELOEIL Luc FTRD/DMI/CAE wrote: > Hi Doug > > > -----Message d'origine----- > > De : Doug Barton [mailto:DougB@DougBarton.net] > > Envoye : mardi 29 juillet 2003 05:15 > > > > > > On Mon, 28 Jul 2003, BELOEIL Luc FTRD/DMI/CAE wrote: > > > > > Ok DHCP servers are embedded in current IPv4 SOHO router. > > > > There, and LOTS of other places. > > > > Good point. But "LOTS of other places" should be clarified for the sake > of arguments. I've already clarified my argument in great detail in a previous post. I should have restrained my urge to comment on this post, but let me make myself clear once again: 1. In every situation where RA DNS announcements are proposed, dhcp is a better solution. 2. RA DNS announcements are an ugly feature creep for RA, and should not be implemented. Is that clear enough for you? :) Doug -- Angel: We need you to distract the vampires. Buffy: Right. Xander: What are you going to do? Buffy: I'm going to kill them all. (Walking away) That oughta distract them. "When She Was Bad" - Buffy the Vampire Slayer, Season 2 Episode 1 #---------------------------------------------------------------------- # To unsubscribe, send a message to . #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 30 02:23:52 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14591 for ; Wed, 30 Jul 2003 02:23:51 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6U5xT8W012708 for ; Wed, 30 Jul 2003 07:59:29 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6U5xTh2012707 for dnsop-outgoing; Wed, 30 Jul 2003 07:59:29 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6U5xQ8W012702 for ; Wed, 30 Jul 2003 07:59:27 +0200 (MEST) From: Masataka Ohta Message-Id: <200307300551.OAA03637@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA03637; Wed, 30 Jul 2003 14:51:12 +0900 Subject: Re: proposal for a compromise on DNS discovery In-Reply-To: <3F269EBE.7060300@ehsco.com> from "Eric A. Hall" at "Jul 29, 2003 11:20:14 am" To: "Eric A. Hall" Date: Wed, 30 Jul 2003 14:51:11 +0859 () CC: dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk Eric A. Hall; > I've submitted an I-D on this in particular, which is also available at > http://www.ehsco.com/misc/draft-hall-resolver-config-00.txt Your draft is excellent to say: This specification is intended to address the narrow scenario where a host needs to determine the DNS servers which are willing to provide DNS resolution services to that host. This document does not define any additional services. Are there anyone who still have more bloated requirements? > > It's also possible to limit the use of multicast to DNS discovery, such as > > having clients issue (periodic) queries to the multicast address to > > determine the available servers, and to choose the top 3 servers (or > > whatever) based on certain criteria (RA flag, response time, whatever), > > and then use unicast after that. And if you specify all the details of protocol changes, the only remaining problem is autoconfiguration of multicast. Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 30 02:27:24 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17784 for ; Wed, 30 Jul 2003 02:27:23 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6U69V8W012838 for ; Wed, 30 Jul 2003 08:09:31 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6U69VVt012837 for dnsop-outgoing; Wed, 30 Jul 2003 08:09:31 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6U69S8W012832 for ; Wed, 30 Jul 2003 08:09:29 +0200 (MEST) From: Masataka Ohta Message-Id: <200307300556.OAA03953@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA03953; Wed, 30 Jul 2003 14:56:15 +0900 Subject: Re: DNS discovery: what about well-known site-local addresses ? In-Reply-To: <4.3.2.7.2.20030729101626.01f1cc88@wells.cisco.com> from John Schnizlein at "Jul 29, 2003 10:59:07 am" To: John Schnizlein Date: Wed, 30 Jul 2003 14:56:15 +0859 () CC: BELOEIL Luc FTRD/DMI/CAE , "Dnsop List diff IETF (E-mail)" X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk John; > First reason why this new alternative is a bad idea: > The definition of well-known addresses for each Internet service is not > the way the Internet works. A very strong analysis would be expected to > embark on such a radical reinvention. Do you remember how whois was implemented? :-) Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 30 10:36:35 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03521 for ; Wed, 30 Jul 2003 10:36:35 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6UE5e8W015671 for ; Wed, 30 Jul 2003 16:05:40 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6UE5dEK015670 for dnsop-outgoing; Wed, 30 Jul 2003 16:05:39 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6UE5c8W015665 for ; Wed, 30 Jul 2003 16:05:38 +0200 (MEST) Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1) with ESMTP-TLS id 410714 for dnsop@cafax.se; Wed, 30 Jul 2003 09:05:31 -0500 Message-ID: <3F27D0AF.7010409@ehsco.com> Date: Wed, 30 Jul 2003 09:05:35 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-US,en MIME-Version: 1.0 To: dnsop@cafax.se Subject: avoiding proxies Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit From my point of view, the problem with mandating the use of either of these solutions is that they would both introduce the use of mandatory proxies to some extent, and would prevent the application-layer DNS from working in their absence. This is a bad idea, in my opinion, as it interferes with several basic design tenets. In the case of RA (as I understand it), the clients and servers couldn't function without a proxy in any event, even if they were on the same subnet. In the case of DHCP, a client and server could function in the absence of a proxy if they were both on the same subnet, but not in other scenarios. Stick the ~discovery capability into the service itself, and this is all avoided. On a related but separate point, generalized configuration services as a whole should still be available as an option, and DHCP should be capable of providing all of the necessary configuration information if that service is already being used. So I'm in favor of adding whatever is necessary to DHCP, but it should not be *required* in the default case. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 30 11:06:54 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04184 for ; Wed, 30 Jul 2003 11:06:52 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6UEjb8W015919 for ; Wed, 30 Jul 2003 16:45:37 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6UEjble015918 for dnsop-outgoing; Wed, 30 Jul 2003 16:45:37 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6UEja8W015913 for ; Wed, 30 Jul 2003 16:45:37 +0200 (MEST) Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA14712 for ; Wed, 30 Jul 2003 15:45:36 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id PAA03361 for ; Wed, 30 Jul 2003 15:45:36 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6UEjZA07492 for dnsop@cafax.se; Wed, 30 Jul 2003 15:45:35 +0100 Date: Wed, 30 Jul 2003 15:45:35 +0100 From: Tim Chown To: dnsop@cafax.se Subject: Re: avoiding proxies Message-ID: <20030730144535.GH6034@login.ecs.soton.ac.uk> Mail-Followup-To: dnsop@cafax.se References: <3F27D0AF.7010409@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F27D0AF.7010409@ehsco.com> User-Agent: Mutt/1.4i Sender: owner-dnsop@cafax.se Precedence: bulk On Wed, Jul 30, 2003 at 09:05:35AM -0500, Eric A. Hall wrote: > > In the case of RA (as I understand it), the clients and servers couldn't > function without a proxy in any event, even if they were on the same > subnet. In the case of DHCP, a client and server could function in the > absence of a proxy if they were both on the same subnet, but not in other > scenarios. Stick the ~discovery capability into the service itself, and > this is all avoided. Wouldn't the RA always be local and on link though, as each link will have at least one router for off-link traffic? Thus there would not need to be an RA proxy as such. There would be a need for DHCP forwarding though, as one would be unlikely to have a DHCP server on every link, unless all routers included DHCPv6 Lite support. I think many enterprise networks now don't have clear L2 and L3 equipment boundaries. Functionality is combined, and to some extent blurred. In our enterprise network, which uses a lot of combined L2/L3 equipment, our core "switch" can forward DHCP requests from routed VLANs. It could equally handle RAs on links too, of course. I note that in many enterprises DHCP is not used. Hosts are manually configured, yet such enterprises have well known DNS resolvers. At our own enterprise (university) where we have DHCP we use it for the basic network config stuff (that is handled in v6 by RAs), plus DNS, DNS search path, NTP, NIS and some boot parameters. I don't know how typical that is in a campus department. The interesting question is how the DNS resolver (and/or other) information is configured to the router, for the RA method to work. Tim #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 30 11:13:53 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04327 for ; Wed, 30 Jul 2003 11:13:52 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6UEtk8W015993 for ; Wed, 30 Jul 2003 16:55:46 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6UEtkhL015992 for dnsop-outgoing; Wed, 30 Jul 2003 16:55:46 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6UEtj8W015987 for ; Wed, 30 Jul 2003 16:55:45 +0200 (MEST) Received: from thrintun.hactrn.net (localhost [::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 6EEB918E3 for ; Wed, 30 Jul 2003 10:55:44 -0400 (EDT) Date: Wed, 30 Jul 2003 10:55:44 -0400 From: Rob Austein To: dnsop@cafax.se Subject: Re: avoiding proxies In-Reply-To: <3F27D0AF.7010409@ehsco.com> References: <3F27D0AF.7010409@ehsco.com> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/20.7 Mule/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Message-Id: <20030730145544.6EEB918E3@thrintun.hactrn.net> Sender: owner-dnsop@cafax.se Precedence: bulk At Wed, 30 Jul 2003 09:05:35 -0500, Eric A. Hall wrote: > > From my point of view, the problem with mandating the use of either of > these solutions is that they would both introduce the use of mandatory > proxies to some extent, and would prevent the application-layer DNS from > working in their absence. This is a bad idea, in my opinion, as it > interferes with several basic design tenets. One can chose to co-locate a DHCP-lite server with the DNS name server, at which point DHCP is no longer a proxy by the definition you appear to be using. There's still some involvment by the router in everything but the single subnet case, but that's unavoidable (in kind, anyway -- one can argue about the degree of router involvement). #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Wed Jul 30 13:41:43 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09946 for ; Wed, 30 Jul 2003 13:41:42 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6UHEC8W017121 for ; Wed, 30 Jul 2003 19:14:12 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6UHECpW017120 for dnsop-outgoing; Wed, 30 Jul 2003 19:14:12 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6UHEA8W017115 for ; Wed, 30 Jul 2003 19:14:11 +0200 (MEST) Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h6UHAFQ7028613 for ; Wed, 30 Jul 2003 13:14:10 -0400 Received: from occlust04evs1.ugd.att.com (135.38.164.12) by attrh5i.attrh.att.com (6.5.032) id 3EE9217C010BF771 for dnsop@cafax.se; Wed, 30 Jul 2003 13:14:02 -0400 Received: from mail pickup service by occlust04evs1.ugd.att.com with Microsoft SMTPSVC; Wed, 30 Jul 2003 12:11:51 -0500 Received: from OCCLUST02EVS1.ugd.att.com ([135.38.164.9]) by occlust04evs1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 30 Jul 2003 09:49:11 -0500 Received: from ocfe02.ugd.att.com ([135.38.164.17]) by OCCLUST02EVS1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 30 Jul 2003 09:49:04 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ocfe02.ugd.att.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 30 Jul 2003 09:49:11 -0500 Received: from ckpmx1.proxy.att.com (192.168.14.105) by attrh5i.attrh.att.com (6.5.032) id 3EE9217C010B06D8 for mattoconnell@ems.att.com; Wed, 30 Jul 2003 10:49:03 -0400 X-PMX-From: ;owner-dnsop@cafax.se; X-PMX-To: 1; Received: from ckmsi1.proxy.att.com (ckmsi1.proxy.att.com [192.168.14.106]) by ckpmx1.proxy.att.com (AT&T IPNS/PMX-5.0) with ESMTP id h6UEn71s027936 for ; Wed, 30 Jul 2003 10:49:09 -0400 X-MSI-From: ;owner-dnsop@cafax.se; X-MSI-To: 1; Received: from nic.cafax.se ([192.71.228.17]) by ckmsi1.proxy.att.com (AT&T IPNS/MSI-5.0) with ESMTP id h6UEmdMc024348 for ; Wed, 30 Jul 2003 10:48:53 -0400 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6UEjb8W015919 for ; Wed, 30 Jul 2003 16:45:37 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6UEjble015918 for dnsop-outgoing; Wed, 30 Jul 2003 16:45:37 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6UEja8W015913 for ; Wed, 30 Jul 2003 16:45:37 +0200 (MEST) Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA14712 for ; Wed, 30 Jul 2003 15:45:36 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id PAA03361 for ; Wed, 30 Jul 2003 15:45:36 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h6UEjZA07492 for dnsop@cafax.se; Wed, 30 Jul 2003 15:45:35 +0100 Date: Wed, 30 Jul 2003 15:45:35 +0100 From: Tim Chown To: dnsop@cafax.se Subject: Re: avoiding proxies Message-ID: <20030730144535.GH6034@login.ecs.soton.ac.uk> Mail-Followup-To: dnsop@cafax.se References: <3F27D0AF.7010409@ehsco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F27D0AF.7010409@ehsco.com> User-Agent: Mutt/1.4i X-ATT-Spam: Gauge=I, Probability=1%, Report='__USER_AGENT, __USER_AGENT_MUTT, __EVITE_CTYPE, __IN_REP_TO, __REFERENCES, X_AUTH_WARNING, REFERENCES, IN_REP_TO, TO_BE_REMOVED_REPLY, EMAIL_ATTRIBUTION, QUOTED_EMAIL_TEXT' X-OriginalArrivalTime: 30 Jul 2003 14:49:12.0078 (UTC) FILETIME=[BD3BCAE0:01C356A9] Sender: owner-dnsop@cafax.se Precedence: bulk On Wed, Jul 30, 2003 at 09:05:35AM -0500, Eric A. Hall wrote: > > In the case of RA (as I understand it), the clients and servers couldn't > function without a proxy in any event, even if they were on the same > subnet. In the case of DHCP, a client and server could function in the > absence of a proxy if they were both on the same subnet, but not in other > scenarios. Stick the ~discovery capability into the service itself, and > this is all avoided. Wouldn't the RA always be local and on link though, as each link will have at least one router for off-link traffic? Thus there would not need to be an RA proxy as such. There would be a need for DHCP forwarding though, as one would be unlikely to have a DHCP server on every link, unless all routers included DHCPv6 Lite support. I think many enterprise networks now don't have clear L2 and L3 equipment boundaries. Functionality is combined, and to some extent blurred. In our enterprise network, which uses a lot of combined L2/L3 equipment, our core "switch" can forward DHCP requests from routed VLANs. It could equally handle RAs on links too, of course. I note that in many enterprises DHCP is not used. Hosts are manually configured, yet such enterprises have well known DNS resolvers. At our own enterprise (university) where we have DHCP we use it for the basic network config stuff (that is handled in v6 by RAs), plus DNS, DNS search path, NTP, NIS and some boot parameters. I don't know how typical that is in a campus department. The interesting question is how the DNS resolver (and/or other) information is configured to the router, for the RA method to work. Tim #---------------------------------------------------------------------- # To unsubscribe, send a message to . #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 31 00:53:06 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29406 for ; Thu, 31 Jul 2003 00:53:05 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6V4JL8W022014 for ; Thu, 31 Jul 2003 06:19:21 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6V4JLCJ022013 for dnsop-outgoing; Thu, 31 Jul 2003 06:19:21 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6V4JI8W022008 for ; Thu, 31 Jul 2003 06:19:19 +0200 (MEST) From: Masataka Ohta Message-Id: <200307310409.NAA09483@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id NAA09483; Thu, 31 Jul 2003 13:09:36 +0900 Subject: Re: avoiding proxies In-Reply-To: <3F27D0AF.7010409@ehsco.com> from "Eric A. Hall" at "Jul 30, 2003 09:05:35 am" To: "Eric A. Hall" Date: Thu, 31 Jul 2003 13:09:36 +0859 () CC: dnsop@cafax.se X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-dnsop@cafax.se Precedence: bulk Eric; > >From my point of view, the problem with mandating the use of either of > these solutions is that they would both introduce the use of mandatory > proxies to some extent, and would prevent the application-layer DNS from > working in their absence. This is a bad idea, in my opinion, as it > interferes with several basic design tenets. I'm not sure what you mean "proxy". But, it is not a business of "discovery" (whatever "discovery" means) protocols to relay service to other subnets if a server for the service is not available link locally. On the Internet, the mechanism to relay requests to servers over multiple links is called routing. The mechanism to propagate relaying directions to the servers over multiple links is called a routing protocol. > In the case of RA (as I understand it), the clients and servers couldn't > function without a proxy in any event, even if they were on the same > subnet. In the case of DHCP, a client and server could function in the > absence of a proxy if they were both on the same subnet, but not in other > scenarios. Stick the ~discovery capability into the service itself, and > this is all avoided. ND can be bloated to poorly perform some aspect of routing, of course. Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 31 01:42:17 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00416 for ; Thu, 31 Jul 2003 01:42:16 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6V5EN8W022320 for ; Thu, 31 Jul 2003 07:14:23 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6V5EMKF022319 for dnsop-outgoing; Thu, 31 Jul 2003 07:14:22 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from goose.ehsco.com (goose.ehsco.com [207.65.203.98]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6V5EL8W022314 for ; Thu, 31 Jul 2003 07:14:21 +0200 (MEST) Received: from [207.65.3.26] (account ehall HELO ehsco.com) by goose.ehsco.com (CommuniGate Pro SMTP 4.1) with ESMTP-TLS id 410829; Thu, 31 Jul 2003 00:14:14 -0500 Message-ID: <3F28A5A9.7080306@ehsco.com> Date: Thu, 31 Jul 2003 00:14:17 -0500 From: "Eric A. Hall" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-US,en MIME-Version: 1.0 To: Masataka Ohta CC: dnsop@cafax.se Subject: Re: avoiding proxies References: <200307310409.NAA09483@necom830.hpcl.titech.ac.jp> In-Reply-To: <200307310409.NAA09483@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit on 7/30/2003 11:10 PM Masataka Ohta wrote: > I'm not sure what you mean "proxy". I mean a third-party agent with knowledge of the application and/or the environment. My examples were poorly formed but are valid in the general sense, since we are still talking about relying upon extraneous agents which have to be managed explicitly and separately from the application end-points themselves. Certainly there are advantages to doing so voluntarily (equitable benefit from the investment in resources), but requiring this model really needs to be avoided. > On the Internet, the mechanism to relay requests to servers over > multiple links is called routing. Exactly, let's let routing do the job it is supposed to be providing already anyway, rather than layering on even more mandatory services. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/ #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 31 10:27:14 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29121 for ; Thu, 31 Jul 2003 10:27:12 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VDwU8W025169 for ; Thu, 31 Jul 2003 15:58:30 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6VDwUkr025168 for dnsop-outgoing; Thu, 31 Jul 2003 15:58:30 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VDwT8W025163 for ; Thu, 31 Jul 2003 15:58:29 +0200 (MEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25972; Thu, 31 Jul 2003 09:58:25 -0400 (EDT) Message-Id: <200307311358.JAA25972@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: dnsop@cafax.se From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-jeong-dnsop-ipv6-dns-discovery-00.txt Date: Thu, 31 Jul 2003 09:58:25 -0400 Sender: owner-dnsop@cafax.se Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 DNS Discovery based on Router Advertisement Author(s) : J. Jeong et al. Filename : draft-jeong-dnsop-ipv6-dns-discovery-00.txt Pages : 10 Date : 2003-7-31 This document specifies the steps a node takes in deciding how to autoconfigure DNS information, such as the address of recursive DNS server and DNS zone suffix. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jeong-dnsop-ipv6-dns-discovery-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-jeong-dnsop-ipv6-dns-discovery-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-jeong-dnsop-ipv6-dns-discovery-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-31101313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-jeong-dnsop-ipv6-dns-discovery-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-jeong-dnsop-ipv6-dns-discovery-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-31101313.I-D@ietf.org> --OtherAccess-- --NextPart-- #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 31 11:52:36 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02440 for ; Thu, 31 Jul 2003 11:52:35 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VFH18W025737 for ; Thu, 31 Jul 2003 17:17:01 +0200 (MEST) Received: by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6VFH1ND025736 for dnsop-outgoing; Thu, 31 Jul 2003 17:17:01 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VFH08W025731 for ; Thu, 31 Jul 2003 17:17:00 +0200 (MEST) Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 31 Jul 2003 17:16:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: avoiding proxies Date: Thu, 31 Jul 2003 17:16:42 +0200 Message-ID: Thread-Topic: avoiding proxies Thread-Index: AcNWqxDZHTbJbFQSRDaaX26FXPtwrwAyrpmA From: "BELOEIL Luc FTRD/DMI/CAE" To: "Tim Chown" , X-OriginalArrivalTime: 31 Jul 2003 15:16:43.0869 (UTC) FILETIME=[C030D8D0:01C35776] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h6VFH18W025732 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Hi Tim, > -----Message d'origine----- > De : Tim Chown [mailto:tjc@ecs.soton.ac.uk] > Envoye : mercredi 30 juillet 2003 16:46 > > On Wed, Jul 30, 2003 at 09:05:35AM -0500, Eric A. Hall wrote: > > > I note that in many enterprises DHCP is not used. Hosts are manually > configured, yet such enterprises have well known DNS resolvers. > > At our own enterprise (university) where we have DHCP we use > it for the > basic network config stuff (that is handled in v6 by RAs), > plus DNS, DNS > search path, NTP, NIS and some boot parameters. I don't > know how typical > that is in a campus department. > At our own entreprise (operator R&D department), we have also DHCP. I do think that is very common in our IPv4 world. > The interesting question is how the DNS resolver (and/or > other) information > is configured to the router, for the RA method to work. > To my mind, recursive DNS resolver information would be acquired through uplink access in a SOHO environment (typically through DHCPv6 over PPP). In a entreprise/university, such information would be configured by network managers on routers where it is needed, in the same manner as the configuration of DHCP-relay are configured. > Tim Luc #---------------------------------------------------------------------- # To unsubscribe, send a message to . From owner-dnsop@cafax.se Thu Jul 31 12:00:33 2003 Received: from nic.cafax.se (nic.cafax.se [192.71.228.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02662 for ; Thu, 31 Jul 2003 12:00:31 -0400 (EDT) Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VFWE8W025820 for ; Thu, 31 Jul 2003 17:32:14 +0200 (MEST) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0/Submit) id h6VFWEaC025819 for dnsop-outgoing; Thu, 31 Jul 2003 17:32:14 +0200 (MEST) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-dnsop@cafax.se using -f Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by nic.cafax.se (8.12.10.Beta0/8.12.10.Beta0) with ESMTP id h6VFWD8W025814 for ; Thu, 31 Jul 2003 17:32:13 +0200 (MEST) Received: from FTRDMEL1.rd.francetelecom.fr ([10.193.117.152]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 31 Jul 2003 17:32:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: avoiding proxies Date: Thu, 31 Jul 2003 17:32:05 +0200 Message-ID: Thread-Topic: avoiding proxies Thread-Index: AcNXJV2QX96dlOcqQ2eO7oysXEfc3wAUWvvA From: "BELOEIL Luc FTRD/DMI/CAE" To: "Eric A. Hall" , "Masataka Ohta" Cc: X-OriginalArrivalTime: 31 Jul 2003 15:32:07.0449 (UTC) FILETIME=[E6AFF890:01C35778] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.cafax.se id h6VFWD8W025815 Sender: owner-dnsop@cafax.se Precedence: bulk Content-Transfer-Encoding: 8bit Hi Eric and Masataka > -----Message d'origine----- > De : Eric A. Hall [mailto:ehall@ehsco.com] > Envoye : jeudi 31 juillet 2003 07:14 > A : Masataka Ohta > > on 7/30/2003 11:10 PM Masataka Ohta wrote: > > > I'm not sure what you mean "proxy". > > I mean a third-party agent with knowledge of the application > and/or the > environment. My examples were poorly formed but are valid in > the general > sense, since we are still talking about relying upon extraneous agents > which have to be managed explicitly and separately from the > application > end-points themselves. Certainly there are advantages to doing so > voluntarily (equitable benefit from the investment in resources), but > requiring this model really needs to be avoided. > > > On the Internet, the mechanism to relay requests to servers over > > multiple links is called routing. > > Exactly, let's let routing do the job it is supposed to be providing > already anyway, rather than layering on even more mandatory services. > Ok I may understand what do you wanna say. 1- we could use multicast to transport DNS requests. But multicast is not easy to deploy within access networks such as xDSL, RTC... (NBMA links) 2- we could use anycast But it is not clear for me how we could use DNSSEC in such scheme. There is still and perhaps a bigger issue there if we need to distribute keys. (I do not argue that RA-based solution is better there ;+) Luc #---------------------------------------------------------------------- # To unsubscribe, send a message to .